490 likes | 723 Views
Multiple Ownership. Nicholas Cameron Sophia Drossopoulou James Noble Matthew Smith. Background – Ownership Types Multiple Ownership Objects in Boxes Variance - ? MOJO Effects. Background. Ownership Types. The heap is messy:. Ownership Types. Organise it:. Ownership Types.
E N D
Multiple Ownership Nicholas CameronSophia DrossopoulouJames NobleMatthew Smith
Background – Ownership Types • Multiple Ownership • Objects in Boxes • Variance - ? • MOJO • Effects ncameron@doc.ic.ac.uk
Background ncameron@doc.ic.ac.uk
Ownership Types • The heap is messy: ncameron@doc.ic.ac.uk
Ownership Types • Organise it: ncameron@doc.ic.ac.uk
Ownership Types • Give each object an owner: ncameron@doc.ic.ac.uk
Ownership Types class Project<o> { Task<this> t1; Task<this> t2; List<this, o> clients; } ncameron@doc.ic.ac.uk
Our Work ncameron@doc.ic.ac.uk
The Objects In Boxes Model ncameron@doc.ic.ac.uk
A Box is a Set of Objects ncameron@doc.ic.ac.uk
Objects in Boxes • Single owner interpretation: • An object is in its owner’s box ncameron@doc.ic.ac.uk
Programs are not Trees ncameron@doc.ic.ac.uk
One Owner is not Enough • 75% of ownership structures require multiple ownership • [34] Mitchell, ECOOP, ’06 • Trees can not describe non-hierarchical structures ncameron@doc.ic.ac.uk
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: ncameron@doc.ic.ac.uk
Objects in Boxes ncameron@doc.ic.ac.uk
A Descriptive System • Describes the heap • Does not restrict references etc. ncameron@doc.ic.ac.uk
MOJO ncameron@doc.ic.ac.uk
MOJO • Class declarations have the usual, formal ownership parameters: class C<o, d> … ncameron@doc.ic.ac.uk
MOJO • Class declarations have the usual, formal ownership parameters: class C<o, d> … • Types may have multiple corresponding actual owner parameters: C<b, c> ncameron@doc.ic.ac.uk
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> ncameron@doc.ic.ac.uk
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> ncameron@doc.ic.ac.uk
MOJO class Connection<o> { … } class Client<o, s> { Connection<this & s> c; } class Server<o> { Connection<this & ?> c; } ncameron@doc.ic.ac.uk
Variance ncameron@doc.ic.ac.uk
Variance • Connection<this & ?> • Some owner ncameron@doc.ic.ac.uk
Variance • Connection<this & ?> • Some box • May be the intersection of several boxes • Variance in the number of owners ncameron@doc.ic.ac.uk
Subtyping • Subtyping with wildcards is variant with respect to owners: C<a> <: C<?> ncameron@doc.ic.ac.uk
Subtyping • Subtyping with wildcards is variant with respect to owners: C<a> <: C<?> C<a> <: C<a & ?> ncameron@doc.ic.ac.uk
Subtyping • Subtyping with wildcards is variant with respect to owners: C<a> <: C<?> C<a> <: C<a & ?> C<a & b & ?> <: C<a & ?> ncameron@doc.ic.ac.uk
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> ncameron@doc.ic.ac.uk
Constraints class C<a, b, c> a intersects b, b disjoint c { … } ncameron@doc.ic.ac.uk
Constraints class D<a, b> a intersects b { D<a, b> } class E<a, b> a disjoint b { } ncameron@doc.ic.ac.uk
Constraints class D<a, b> a intersects b { D<a, b> } class E<a, b> a disjoint b { D<a, b> } ncameron@doc.ic.ac.uk
Constraints class D<a, b> a intersects b { D<a, b> Object<a & b> } class E<a, b> a disjoint b { D<a, b> } ncameron@doc.ic.ac.uk
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; ncameron@doc.ic.ac.uk
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; ncameron@doc.ic.ac.uk
Typing - strict ncameron@doc.ic.ac.uk
Effects ncameron@doc.ic.ac.uk
Effects ncameron@doc.ic.ac.uk
Effects Task<x> t1; Task<y> t2; … t1.f; // reads x / writes ε ncameron@doc.ic.ac.uk
Effects Task<x> t1; Task<y> t2; … t1.f; // reads x / writes ε t1.f = t2.f; // reads x,y / writes x ncameron@doc.ic.ac.uk
Effects with Multiple Owners Task<x & ?> t1; Task<y & z> t2; … t1.f; // reads x & ? / writes ε ncameron@doc.ic.ac.uk
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 & ? ncameron@doc.ic.ac.uk
Effects with Multiple Owners t1.f = t2.f; // reads x & ?,y & z/ writes x & ? ncameron@doc.ic.ac.uk
Disjointness • Two expressions are disjoint if their effects do not overlap • Complicated by ? – but & = intersection ncameron@doc.ic.ac.uk
Future Work ncameron@doc.ic.ac.uk
Future Work • Explore variant owners using existential types class TaskList<o, d> { Task<d & ?> datum; TaskList<o, d> next; } ncameron@doc.ic.ac.uk
Future Work • Reference and modification control ncameron@doc.ic.ac.uk
Future Work • Constraints • Topology - inside • Unary - may read, may write • Binary – may point to, may modify ncameron@doc.ic.ac.uk
Summary • Ownership Types • Multiple Ownership • Objects in Boxes • Variance • MOJO • Effects • Thank you! • Any questions? ncameron@doc.ic.ac.uk