Ownership, Encapsulation and the Disjointness of Type and Effect. Dave Clarke Utrecht University Sophia Drossopoulou Imperial College, London

Transcription

1 Ownership, Encapsulation and the Disjointness of Type and Effect Dave Clarke Utrecht University Sophia Drossopoulou Imperial College, London

2 Overview Review ownership types Describe a problem reasoning about programs Disjointness of types non-aliasing Disjointness of effects noninterference Contribution: The spatial consequences of ownership types.... and much more.

3 Object Spaghetti Here are two disjoint lists (I swear): List Link Main List Link Data Link Link Data Data Link Link Data Data How do we take arms against a sea of objects? I m not bad, I m just drawn that way.

4 Layering Dominance Each List owns its Links. Objects are inside their owners. Owners are dominators. Main Disallowed Data List Links All access paths from the root to an object contain its owner. No references from outside to inside crossing a boundary.

5 Owners form a tree Every object has an owner and is the owner of other objects. All objects are inside their owner and the root: world. world owner(p) p Tree captures nesting of objects we omit references.

6 The Basics of Ownership Typing Ownership types statically enfore the dominators property. Classes are parameterised by owners. class List<owner,other> { Link<this,other> head;... } The owner of the Link object is this. Link objects are not accessible outside of the List instance. Ownership typing provides discipline to object spaghetti. Object Lasagne?

7 Reasoning about Programs Given code such as: List<p,world> list1; List<q,world> list2; for (i = 0; i < 10; i++) { list1.add(new Data<world>(i)); } for (i = 0; i < 10; i++) { list2.add(new Data<world>(i)); } // exp1 // exp2 We want to answer questions such as: Are list1 and list2 aliases? Do expressions exp1 and exp2 interfere?

8 Ownership Typing Guarantees Two key disjointness relations: t # t objects of type t are disjoint from those of type t. Variables/fields with those types are not aliases. (reads... writes...) # (reads... writes...) Expressions producing those effects do not interfere. These are separation logics see Reynolds, O Hearn and others.

9 Preliminaries Disjointness of Owner p # q says that owners p and q are distinct For owners p and q, p + q p # q For (final) variables x and y, x : t and y : t and t # t x # y Once we have some disjointness, we readily obtain more.

10 Disjointness of Type t # t says that types t and t are disjoint no object has both types. If no object can be an instance of both classes c and c, then: c p i 1..n # c q j 1..m For types c p i 1..n and c q i 1..n, if p i # q i for some i 1..n, then c p i 1..n # c q i 1..n

11 Disjoint Types Restrict Aliasing Assume that p # q. List<p,world> list1; List<q,world> list2; We can deduce that List p, world # List q, world. Hence list1 and list2 are not aliases.

12 Disjoint Types Restrict Aliasing Assume that p # q. List<p,world> list1; List<q,world> list2; We can deduce that List p, world # List q, world. Hence list1 and list2 are not aliases. Furthermore, all of list1.head, list1.head.next, list1.head.next.next, are distinct from list2.head, list2.head.next, list2.head.next.next

13 Computational Effects Effects are based on primitive reads of and writes to object fields. The code x.f produces read effect: reads x The code x.f = y produces write effect: writes x Introduce effect shapes to represent collections of objects. Reasoning about disjointness of effect shapes reasoning about disjointness of effects reasoning about noninterference of expressions.

14 Effect shape: an object Syntactically: p p

15 Effect shape: a band of objects Syntactically: p.2 p

16 Effect shape: inside an object Syntactically: under(p) includes p p

17 Effect shape: inside objects of a band Syntactically: under(p.2) p... and of course the empty shape and the union of effect shapes.

18 Disjointness of Shape We need to know when two shapes are disjoint. If a read or write occurs to two disjoint shapes, then they do not effect the same objects. Of course we permit two reads to same object. noninterference of expressions.

19 Disjointness of Shape Example If p p and q p and p # q, then under(p) # under(q). p p q There are no pictures that are true a priori.

20 Disjoint Effects Restrict Interference Returning to our example... assume p # q, p p, and q p. List<p,world> list1; List<q,world> list2; for (i = 0; i < 10; i++) { list1.add(new Data<world>(i)); } for (i = 0; i < 10; i++) { list2.add(new Data<world>(i)); } // exp1 // exp2 If the effect on the add method is writes under(this), we can deduce that under(list1) # under(list2). Thus exp1 and exp2 do not interfere.

21 Loop Fusion Noninterference between exp1 and exp2 enables the loop fusion: List<p,world> list1; List<q,world> list2; for (i = 0; i < 10; i++) { list1.add(new Data<world>(i)); list2.add(new Data<world>(i)); } // exp1 // exp2 Because ownership types enforces the spatial separation of objects.

22 Related Work Greenhouse and Boyland (ECOOP 1999) Object-oriented effects system Effect shapes are orthogonal to ours: Vertical vs horizontal slicing of objects. Based on uniqueness rather than ownership Marrying the two approaches would be useful Boyapati, Lee, Rinard (OOPSLA 2002) Ownership Types for Safe Programming Nice application: Data race & deadlock prevention Different variant of ownership typing + locks effects Aldrich, Kostadinov, Chambers (OOPSLA 2002) Alias Annotations for Program Understanding Next!

23 Conclusion For an ownership types system, we provide: type disjointness test can determine non-aliasing effect disjointness tests can determine noninterference a visual model for reasoning. Ownership types are the driving force.

24 A taste of what s in the paper