Tobias Wrigstad

Ownership types: a survey

Ownership types were devised nearly 15 years ago to provide a stronger notion of protection to object-oriented programming languages. Rather than simply protecting the fields of an object from external access, ownership types protect also the objects stored in the fields, thereby enabling an object to claim (exclusive) ownership of and access to other objects. Furthermore, this notion is statically enforced by now-standard type-checking techniques. n nOriginating as the formalisation of the core of Flexible Alias Protection, ownership types have since been extended and adapted in many ways, and the notion of protection provided has been refined into topological and encapsulation dimensions. This article surveys the various flavours of ownership types that have been developed over the years, along with the many applications and other developments. The chapter concludes by suggesting some directions for future work.

Parallel Objects for Multicores: A Glimpse at the Parallel Language Encore

The age of multi-core computers is upon us, yet current programming languages, typically designed for single-core computers and adapted post hoc for multi-cores, remain tied to the constraints of a sequential mindset and are thus in many ways inadequate. New programming language designs are required that break away from this old-fashioned mindset. To address this need, we have been developing a new programming language called Encore, in the context of the European Project UpScale. The paper presents a motivation for the Encore language, examples of its main constructs, several larger programs, a formalisation of its core, and a discussion of some future directions our work will take. The work is ongoing and we started more or less from scratch. That means that a lot of work has to be done, but also that we need not be tied to decisions made for sequential language designs. Any design decision can be made in favour of good performance and scalability. For this reason, Encore offers an interesting platform for future exploration into object-oriented parallel programming.

Tribal ownership

Tribal Ownership unifies class nesting and object ownership. Tribal Ownership is based on Tribe, a language with nested classes and object families. In Tribal Ownership, a programs runtime object ownership structure is characterised by the lexical nesting structure of its classes. We build on a variant of Tribe to present a descriptive ownership system, using object nesting to describe heap partitions, but without imposing any restrictions on programming disciplines. We then demonstrate how a range of different prescriptive ownership policies can be supported on top of the descriptive Tribal Ownership mechanism; including a novel owners-as-local-dominators policy. We formalise our type system and prove soundness and several ownership invariants. The resulting system requires strikingly few annotations, and uses well-understood encapsulation techniques to create ownership systems that should be intuitive for programmers.

Tracing dynamic features in python programs

Recent years have seen a number of proposals for adding (retrofitting) static typing to dynamic programming languages, a natural consequence of their growing popularity for non-toy applications across a multitude of domains. These proposals often make assumptions about how programmers write code, and in many cases restrict the way the languages can be used. In the context of Python, this paper describes early results from trace-based collection of run-time data about the use of built-in language features which are inherently hard to type, such as dynamic code generation. The end goal of this work is to facilitate static validation tooling for Python, in particular retrofitting of type systems.

Aliasing in Object-Oriented Programming: types, analysis, and verification

Ownership types were devised nearly 15 years ago to provide a stronger notion of protection to object-oriented programming languages. Rather than simply protecting the fields of an object from external access, ownership types protect also the objects stored in the fields, thereby enabling an object to claim (exclusive) ownership of and access to other objects. Furthermore, this notion is statically enforced by now-standard type-checking techniques. Originating as the formalisation of the core of Flexible Alias Protection, ownership types have since been extended and adapted in many ways, and the notion of protection provided has been refined into topological and encapsulation dimensions. This article surveys the various flavours of ownership types that have been developed over the years, along with the many applications and other developments. The chapter concludes by suggesting some directions for future work. Aliasing is endemic in object-oriented programming. Noble, Vitek, Potter [112].

Measuring polymorphism in python programs

Following the increased popularity of dynamic languages and their increased use in critical software, there have been many proposals to retrofit static type system to these languages to improve possibilities to catch bugs and improve performance. A key question for any type system is whether the types should be structural, for more expressiveness, or nominal, to carry more meaning for the programmer. For retrofitted type systems, it seems the current trend is using structural types. This paper attempts to answer the question to what extent this extra expressiveness is needed, and how the possible polymorphism in dynamic code is used in practise. We study polymorphism in 36 real-world open source Python programs and approximate to what extent nominal and structural types could be used to type these programs. The study is based on collecting traces from multiple runs of the programs and analysing the polymorphic degrees of targets at more than 7 million call-sites. Our results show that while polymorphism is used in all programs, the programs are to a great extent monomorphic. The polymorphism found is evenly distributed across libraries and program-specific code and occur both during program start-up and normal execution. Most programs contain a few ``megamorphic call-sites where receiver types vary widely. The non-monomorphic parts of the programs can to some extent be typed with nominal or structural types, but none of the approaches can type entire programs.

Multiple aggregate entry points for ownership types

Deep ownership types gives a strong notion of aggregate by enforcing the so-called owners-as-dominators property: every path from a system root to an object must pass through its owner. Consequently, encapsulated aggregates must have a single bridge object that mediates all external interaction with its internal objects. n nIn this paper, we present an extension of deep ownership that relaxes the single bridge object constraint and allows several bridge objects to collectively define an aggregate with a shared representation. We call such bridge objects ombudsmen to emphasise their benevolent nature; ombudsmen-sharing is explicit and all ombudsmen are created internal to the aggregate, purposely. n nThe resulting system brings the aggregate notion close to the component notion found in e.g., UML by clearly separating aggregation from the stronger composition, and further allows expressing common programming patterns such as iterators without resorting to systems that give unclear or unprincipled guarantees, or require additional complex machinery such as read-only references.

Orca: GC and type system co-design for actor languages

ORCA is a concurrent and parallel garbage collector for actor programs, which does not require any STW steps, or synchronization mechanisms, and that has been designed to support zero-copy message passing and sharing of mutable data. ORCA is part of a runtime for actor-based languages, which was co-designed with the Pony programming language, and in particular, with its data race free type system. By co-designing an actor language with its runtime, it was possible to exploit certain language properties in order to optimize performance of garbage collection. Namely, ORCA relies on the guarantees of absence of race conditions in order to avoid read/write barriers, and it leverages the actor message passing, for synchronization among actors. In this paper we briefly describe Pony and its type system. We use pseudo-code in order to introduce how ORCA allocates and deallocates objects, how it shares mutable data without requiring barriers upon data mutation, and how can immutability be used to further optimize garbage collection. Moreover, we discuss the advantages of co-designing an actor language with its runtime, and we demonstrate that ORCA can be implemented in a performant and scalable way through a set of micro-benchmarks, including a comparison with other well-known collectors.

You can have it all: abstraction and good cache performance

On current architectures, the optimisation of an applications performance often involves data being stored according to access affinity --- what is accessed together should be stored together, rather than logical affinity --- what belongs together logically stays together. Such low level techniques lead to faster, but more error prone code, and end up tangling the programs logic with low-level data layout details. Our vision, which we call SHAPES --- Safe, High-level, Abstractions for oPtimisation of mEmory cacheS --- is that the layout of a data structure should be defined only once, upon instantiation, and the remainder of the code should be layout agnostic. This enables performance improvements while also guaranteeing memory safety, and supports the separation of program logic from low level concerns. In this paper we investigate how this vision can be supported by extending a programming language. We describe the core language features supporting this vision: classes can be customized to support different layouts, and layout information is carried around in types; the remaining source code is layout-unaware and the compiler emits layout-aware code. We then discuss our SHAPES implementation through a prototype library, which we also used for preliminary evaluations. Finally, we discuss how the core could be expanded so as to deliver SHAPESs full potential: the incorporation of compacting garbage collection, ad hoc polymorphism and late binding, synchronization of representations of different collections, support for dynamic change of representation, etc.

Type-assisted automatic garbage collection for lock-free data structures

We introduce Isolde, an automatic garbage collection scheme designed specifically for managing memory in lock-free data structures, such as stacks, lists, maps and queues. Isolde exists as a plug-in memory manager, designed to sit on-top of another memory manager, and use its allocator and reclaimer (if exists). Isolde treats a lock-free data structure as a logical heap, isolated from the rest of the program. This allows garbage collection outside of Isolde to take place without affecting the lock-free data structure. Isolde further manages objects allocated on a Isolde heap in a fully concurrent manner, allowing garbage collection to incrementally remove garbage without stopping other threads doing work.