Ownership Types: A Survey

Clarke, Dave; Östlund, Johan; Sergey, Ilya; Wrigstad, Tobias

doi:10.1007/978-3-642-36946-9_3

Cited by 52 publications

(52 citation statements)

References 113 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…The type system can prevent such errors by extending techniques found, e.g., in the ownership types literature [Clarke and Drossopoulou 2002;Clarke et al 2013]. …”

Section: Instantiation and Usage Of Data Structuresmentioning

confidence: 99%

You can have it all: abstraction and good cache performance

Franco

Hagelin

Wrigstad

et al. 2017

Proceedings of the 2017 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

Self Cite

View full text Add to dashboard Cite

On current architectures, the optimisation of an application's 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 program's 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 SHAPES's full potential: the incorporation of compacting garbage collection, * Work done while at Uppsala University.

show abstract

“…The type system can prevent such errors by extending techniques found, e.g., in the ownership types literature [Clarke and Drossopoulou 2002;Clarke et al 2013]. …”

Section: Instantiation and Usage Of Data Structuresmentioning

confidence: 99%

You can have it all: abstraction and good cache performance

Franco

Hagelin

Wrigstad

et al. 2017

Proceedings of the 2017 ACM SIGPLAN International Symposium on New Ideas, New Paradigms, and Reflections on Programming and Sof

Self Cite

View full text Add to dashboard Cite

show abstract

“…Some other works utilize ownership types [CPN98,CÖSW13] to place restriction on access to shared objects. Early ownership types are too restrictive and substantially reduce the expressiveness of the language.…”

Section: Multiple Start Of Threadsmentioning

confidence: 99%

Untitled

2017

JOT

View full text Add to dashboard Cite

We present MTMJ, a multithreaded middleweight model language for Java which is strongly typed and prevents multiple run-time start of threads. The key point in designing the language is to balance precision and efficiency by judicious utilization of context information during type checking. While the types are flow-insensitive, the required flowdependent information is collected as type checking progresses. We prove that our type system is sound and guarantees the good behavior of welltyped programs. In particular, the execution of a typable program does not lead to multiple start of threads. We also develop a type checker as part of this research and apply it to several MTMJ programs.

show abstract

“…Ownership Types and its descendants [Clarke et al 2013] are type systems where types are explicitly annotated (or implicitly associated) with owners. These systems enforce topological restrictions on the heap (i.e., they restrict which paths may exist in the heap) and may in addition enforce a form of "encapsulation" (i.e., limit the operations that can be performed through certain references).…”

Section: Annotating Types With Ownersmentioning

confidence: 99%

“…The literature on Ownership Types is too vast for us to survey here; the reader is referred to the comprehensive overview by Clarke et al [2013].…”

mentioning

confidence: 99%

The Design and Formalization of Mezzo, a Permission-Based Programming Language

Balabonski

Pottier

Protzenko

2016

ACM Trans. Program. Lang. Syst.

View full text Add to dashboard Cite

The programming language Mezzo is equipped with a rich type system that controls aliasing and access to mutable memory. We give a comprehensive tutorial overview of the language. Then, we present a modular formalization of Mezzo's core type system, in the form of a concurrent λ-calculus, which we successively extend with references, locks, and adoption and abandon, a novel mechanism that marries Mezzo's static ownership discipline with dynamic ownership tests. We prove that well-typed programs do not go wrong and are data-race free. Our definitions and proofs are machine-checked. XXXX:2 T. Balabonski et al. 1 open woref 2 3 val f (x: frozen int , y: frozen int) : int = 4 get x + get y 5 6 val _ : int = 7 let r = new () in 8 set (r, 3); 9 f (r, r) Fig. 1. Using a write-once ref-erence. The Mezzo type system guarantees that the user must call set before using get, and can call set at most once. and robustness; in return, they offer far greater expressiveness than a simple-minded, purely static discipline could hope to achieve.In this paper, we offer a comprehensive overview of Mezzo, including an informal, user-level presentation of the language and a formal, machine-checked presentation of its meta-theory. This unifies and subsumes the two conference papers cited above. Furthermore, we revisit the theory of adoption and abandon, which was presented informally in the first conference paper, and was absent from the second conference paper. Our new account of adoption and abandon is not only machine-checked, but also simpler and more expressive than that of the conference paper. A few examplesWe begin with two short illustrative examples. The first one concerns a type of writeonce references and shows how Mezzo guarantees that the client follows the intended usage protocol. The second example is a racy program, which the type system rejects. We show how to fix this ill-typed program by introducing a lock.A usage protocol. A write-once reference is a memory cell that can be assigned at most once and cannot be read before it has been initialized. Fig. 1 shows some client code that manipulates a write-once reference. The code refers to the module woref, whose implementation we show later on ( §2.1).At line 7, we create a write-once reference by calling woref::new. (Thanks to the declaration open woref, one can refer to this function by the unqualified name new.) The local variable r denotes the address of this reference. In the eyes of the typechecker, this gives rise to a permission, written r @ writable. This permission has a double reading: it describes the layout of memory (i.e., "the variable r denotes the address of an uninitialized memory cell") and grants exclusive write access to this memory cell. That is, the type constructor writable denotes a uniquely-owned writable reference, and the permission r @ writable is a unique token that one must possess in order to write r.Permissions are tokens that exist at type-checking time only. Many permissions have the form x @ t, where x is a program variable and t is a ty...

show abstract

Ownership Types: A Survey

Cited by 52 publications

References 113 publications

You can have it all: abstraction and good cache performance

You can have it all: abstraction and good cache performance

Untitled

The Design and Formalization of Mezzo, a Permission-Based Programming Language

Contact Info

Product

Resources

About