0wn3rship types john whaley cs343 stanford university may 19, 2004

0wn3rship Types0wn3rship Types

John WhaleyCS343

Stanford University

May 19, 2004

June 10, 2004 Ownership Types 2

j00 got 0wn3d!!!1!


What are ownership types?

• Statically-enforced object encapsulation• An object can own the objects in its

fields* If the pointers to those objects are unique

• Moreorless, owned objects are the ones that could be inlined into their containing objects.


Must go through parent

Mommaobject

Babyobjects

“The Gatekeeper”


Ownership types to prevent data races

• Intuition: a lock that protects an object can protect its encapsulated objects.

• We don’t care about locking for:– Immutable objects– Thread-local objects (owned by

“thisThread”)

• If pointer is unique, the owner can safely be changed.


Where to lock?

CombinedAccount

Checking

Savings

Can lock onparent object

Can lock oneach child object

individually

What are the tradeoffs?


Thread 1Thread 1

Thread 2Thread 2

Thread nThread n

……

Lock 1Lock 1 Lock nLock n

Lock 2Lock 2 Lock 3Lock 3

• Associate a partial order for locks• Acquire locks in that order

Preventing deadlocks

~~~~


Specifying partial order

• Programmers specify lock ordering using:– Static lock levels– Recursive data structures

•Mutable trees•Monotonic DAGs

– Runtime ordering• Type checker statically verifies:

– Locks are acquired in descending order– Specified order is a partial order


Lock Level Based Partial Orders

• Lock levels are partially ordered• Locks belong to lock levels• Threads must acquire locks in descending

order of lock levels


savingsAccount belongs to savingsLevel savingsAccount belongs to savingsLevel checkingAccount belongs to checkingLevelcheckingAccount belongs to checkingLevelclass CombinedAccount {

LockLevel savingsLevel; LockLevel checkingLevel < savingsLevel; final Accountself : savingsLevel savingsAccount = new

Account(); final Accountself : checkingLevel checkingAccount = new

Account();

int balance() locks (savingsLevel) { synchronized (savingsAccount) { synchronized (checkingAccount) { return savingsAccount.balance +

checkingAccount.balance; }}}}

Examplelocks are acquired in descending orderlocks are acquired in descending ordercheckingLevel < savingsLevelcheckingLevel < savingsLevellocks held by callers > savingsLevellocks held by callers > savingsLevelbalance can acquire these locksbalance can acquire these locks


Tree Based Partial Orders

• Locks in a level can be tree-ordered• Using data structures with tree backbones

– Doubly linked lists– Trees with parent/sibling pointers– Threaded trees…


class Nodeself : l { tree Nodeself : l left; tree Nodeself : l right;

synchronized void rotateRight() locks (this) { Node x = this.right; synchronized (x) { Node v = x.left; synchronized (v) {

Node w = v.right; v.right = null; x.left = w; this.right = v; v.right = x; }}}}

xx

thisthis

vv

ww yy

thisthis

vv

xx

yy

uu ww

uu

Tree Based Partial Ordersnodes must be locked in tree ordernodes must be locked in tree ordernodes are locked in tree ordernodes are locked in tree order


DAG Based Partial Orders

• Locks in a level can be DAG-ordered• DAGs cannot be arbitrarily modified• DAGs can be built bottom-up by

– Allocating a new node– Initializing its DAG fields

• Uses a lightweight shape analysis

class Nodeclass Nodeself : lself : l { { dag Nodedag Nodeself : lself : l left; left;

dag Nodedag Nodeself : lself : l right; right;

… …

} }


class Account implements Dynamic { int balance = 0; void deposit(int x) requires (this) { balance += x; } void withdraw(int x) requires (this) { balance -= x; }

}

void transfer(Accountself : v a1, Accountself : v a2, int x) locks(v) {

synchronized (a1, a2) in { a1.withdraw(x); a2.deposit(x); }}

Runtime Ordering of Locks

Account objects are dynamically orderedAccount objects are dynamically orderedlocks are acquired in runtime orderlocks are acquired in runtime order


Questions

• How does this compare to other race detection techniques?– Flanagan & Freund, Type-based Race

Detection– Who can guard objects/fields?

• How does this relate to atomicity?


Another use of ownership

• Use ownership for region-based analysis– Put encapsulated objects in a single region– When parent object becomes unreachable,

all children also become unreachable

• Extend the idea of ownership– Owner can be object or region– Regions are well-nested, so we maintain

tree property


• Programs can create a region• Allocate objects in a region• Delete a region & free all objects in it

Region-Based Memory Management


Type System for Regionsclass Stackclass StackstackOwner, dataOwnerstackOwner, dataOwner { { NodeNodethis, dataOwnerthis, dataOwner head; head;

}}

class Nodeclass NodenodeOwner, dataOwnernodeOwner, dataOwner { { NodeNodenodeOwner, dataOwnernodeOwner, dataOwner next; next;

DataDatadataOwnerdataOwner data; data;

}}

(RegionHandle(RegionHandler1r1 h1) { h1) {

(RegionHandle(RegionHandler2r2 h2) { h2) {

StackStackr1, r1r1, r1 s1; s1;

StackStackr2, r1r2, r1 s2; s2;

StackStackr1, r2r1, r2 s3; s3; // illegal// illegal

}}}}Scoping alone does not ensure safety in presence of subtypingScoping alone does not ensure safety in presence of subtypingFirst owner must be same as or nested in other ownersFirst owner must be same as or nested in other owners


• Special regions:– Garbage collected heap– Immortal region

• Runtime provides:– Region handle of most nested region– Region handle of an object

• Type checker statically infers:– If a region handle is in scope

Other Details


Real-Time Java

• Region types especially useful forReal-Time Java– RT threads cannot use garbage

collected heap– RT threads can use immortal memory– RT threads can use regions– RT threads cannot read heap references– RT threads cannot overwrite heap

references


Real-Time Java

• Uses dynamic checks to check:– No pointers from outer to inner regions– Nesting of regions forms a hierarchy– RT threads do not read heap refs– RT threads do not overwrite heap refs

• This is pretty nasty!• Can use the type system to statically find

bugs, and also prove most checks are unnecessary.


Regions for multithreading

• Use sub-regions within shared regions, to avoid memory leaks.– Subregions can be deallocated e.g.

after each loop iteration• “Typed portal fields” for controlled

inter-thread communication– Wormhole between threads

• Also finds priority inversion bugs.


Programming Overhead# Lines

annotated# Lines of code

Program

24 244Database Server

10 97Game Server

20 603HTTP Server

8 567Image Recognition

53 1011 java.util.Hashtable

35 992java.util.Vector

161850Barnes

311850Water


RTJ Dynamic Checking Overhead

Execution Time (sec)

Static Checks

Speed UpDynamic Checks

Program

13% 19.1 21.6Barnes

24%2.062.55Water

18% 0.617 0.731 save

10% 0.023 0.026 thinning

0.014 0.014 cross

25% 0.667 0.813 load

21%6.708.10Image Recognition


Strengths

• Guarantees that there are no race conditions or deadlocks in the program!– Catches all problems at compile time.– Never have to deal with debugging races!

• Expressive enough for real code.– Handles many common paradigms.

• Intelligent annotations.– Does the smart thing most of the time.

• Basically zero dynamic overhead.


More Strengths• Statically guarantees there will not be

any real-time violations.– Also eliminates most dynamic checks, real

performance improvement.

• Programmer can encode what should happen, and compiler will automatically flag the violations.

• Scalable and modular– Supports separate compilation

• Encapsulation is a good software engineering practice.


Question: Annotation Burden

• Intraprocedural type inference for local variables

• Intelligent defaults for ownership• Users can specify defaults as well• Their experience:

– Annotate one out of thirty lines– Is this good? bad?

• Compare to Flanagan: 20/1000 lines


Weaknesses

• Very ad-hoc approach– Add random features to handle the

problems they happened to run into.– Add features that are easy to implement.

• No indication of what can or cannot be expressed in their system.

• Only intraprocedural type inference.– Requires lots of annotations, most of which

could probably be inferred automatically.• Only handles race conditions, not

atomicity.


Ownership restrictions

• Ownership forces your object graph to be a tree.– How realistic is this?

• What if you want to control access to multiple resources?– Resources must be put under a single

object.– This means for semantic encapsulation you

also forced into structural encapsulation.


Conclusion

• Ownership types give you lots of nice properties.– Can prove encapsulation– Can prove no data races or deadlocks– Can prove correct usage of regions

• But the ownership model is very restrictive.– Single owner, no sharing– Mixes up different notions of encapsulation

0wn3rship types john whaley cs343 stanford university may 19, 2004

Documents