multiple ownership nicholas cameron sophia drossopoulou james noble matthew smith
TRANSCRIPT
Multiple Ownership
Nicholas CameronSophia Drossopoulou
James NobleMatthew Smith
• Background – Ownership Types
• Multiple Ownership• Objects in Boxes• Variance - ?• MOJO
• Effects
Ownership Types
class Project<o> { Task<this> t1; Task<this> t2; List<this, o> clients;}
Objects in Boxes
• Single owner interpretation:
• An object is in its owner’s box
One Owner is not Enough
• 75% of ownership structures require multiple ownership• [34] Mitchell, ECOOP, ’06
• Trees can not describe non-hierarchical structures
Objects in Boxes
• Multiple Ownership: objects may be in more than one box
• An object with multiple owners is in the intersection of their boxes:
MOJO
• Class declarations have the usual, formal ownership parameters:
class C<o, d> …
MOJO
• Class declarations have the usual, formal ownership parameters:
class C<o, d> …• Types may have multiple corresponding
actual owner parameters:
C<b, c>
MOJO
• Class declarations have the usual, formal ownership parameters:
class C<o, d> …• Types may have multiple corresponding
actual owner parameters:
C<b, c>
C<a & b, c >
MOJO
• Class declarations have the usual, formal ownership parameters:
class C<o, d> …• Types may have multiple corresponding
actual owner parameters:
C<b, c>
C<a & b, c >
C<a & b & ?, c & a>
MOJO
class Connection<o> { … }
class Client<o, s> { Connection<this & s> c;}
class Server<o> { Connection<this & ?> c;}
Variance
• Connection<this & ?>• Some box
• May be the intersection of several boxes
• Variance in the number of owners
Subtyping
• Subtyping with wildcards is variant with respect to owners:
C<a> <: C<?>
Subtyping
• Subtyping with wildcards is variant with respect to owners:
C<a> <: C<?>
C<a> <: C<a & ?>
Subtyping
• Subtyping with wildcards is variant with respect to owners:
C<a> <: C<?>
C<a> <: C<a & ?>
C<a & b & ?> <: C<a & ?>
Subtyping
• Subtyping with wildcards is variant with respect to owners:
C<a> <: C<?>
C<a> <: C<a & ?>
C<a & b & ?> <: C<a & ?>
C<?> </: C<a>
C<a> </: C<a & b>
Constraintsclass D<a, b> a intersects b { D<a, b>
}
class E<a, b> a disjoint b { }
Constraintsclass D<a, b> a intersects b { D<a, b> }
class E<a, b> a disjoint b { D<a, b> }
Constraintsclass D<a, b> a intersects b { D<a, b> Object<a & b> }
class E<a, b> a disjoint b { D<a, b> }
Typing - strict
• Strict method sends and assignments to deal with variance of owners:class C<o> { C<o> f;}
C<a> ca; C<a & ?> c1; C<a & ?> c2;
ca.f = ca;
Typing - strict
• Strict method sends and assignments to deal with variance of owners:class C<o> { C<o> f;}
C<a> ca; C<a & ?> c1; C<a & ?> c2;
ca.f = ca; c1.f = c2;
Effects
Task<x> t1;Task<y> t2;…t1.f; // reads x / writes εt1.f = t2.f; // reads x,y / writes x
Effects with Multiple Owners
Task<x & ?> t1;Task<y & z> t2;…t1.f; // reads x & ? / writes ε
Effects with Multiple Owners
Task<x & ?> t1;Task<y & z> t2;…t1.f; // reads x & ? / writes εt1.f = t2.f; // reads x & ?,y & z/ writes x & ?
Disjointness
• Two expressions are disjoint if their effects do not overlap
• Complicated by ? – but & = intersection
Future Work
• Explore variant owners using existential types
class TaskList<o, d> { Task<d & ?> datum; TaskList<o, d> next;}
Future Work
• Constraints• Topology - inside• Unary - may read, may write• Binary – may point to, may modify
Summary
• Ownership Types• Multiple Ownership
• Objects in Boxes• Variance• MOJO
• Effects
• Thank you!• Any questions?