0wn3rship Types John Whaley CS343 Stanford University May 19, 2004

June 10, 2004Ownership Types1 j00 got 0wn3d!!!1!

June 10, 2004Ownership Types2 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.

June 10, 2004Ownership Types3 Must go through parent Momma object Baby objects “ The Gatekeeper ”

June 10, 2004Ownership Types4 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.

June 10, 2004Ownership Types5 Where to lock? Combined Account Checking Savings Can lock on parent object Can lock on each child object individually What are the tradeoffs?

June 10, 2004Ownership Types6 Thread 1 Thread 2 Thread n … Lock 1 Lock n Lock 2 Lock 3 Associate a partial order for locks Acquire locks in that order Preventing deadlocks~ ~

June 10, 2004Ownership Types7 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

June 10, 2004Ownership Types8 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

June 10, 2004Ownership Types9 savingsAccount belongs to savingsLevel checkingAccount belongs to checkingLevel class CombinedAccount { LockLevel savingsLevel; LockLevel checkingLevel < savingsLevel; final Account  self : savingsLevel  savingsAccount = new Account(); final Account  self : checkingLevel  checkingAccount = new Account(); int balance() locks (savingsLevel) { synchronized (savingsAccount) { synchronized (checkingAccount) { return savingsAccount.balance + checkingAccount.balance; }}} } Example locks are acquired in descending order checkingLevel < savingsLevel locks held by callers > savingsLevel balance can acquire these locks

June 10, 2004Ownership Types10 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…

June 10, 2004Ownership Types11 class Node  self : l  { tree Node  self : l  left; tree Node  self : 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; }}} } x this v w y this v x y u w u Tree Based Partial Orders nodes must be locked in tree order nodes are locked in tree order

June 10, 2004Ownership Types12 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 Node  self : l  { dag Node  self : l  left; dag Node  self : l  left; dag Node  self : l  right; dag Node  self : l  right; …}

June 10, 2004Ownership Types13 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(Account  self : v  a1, Account  self : v  a2, int x) locks(v) { synchronized (a1, a2) in { a1.withdraw(x); a2.deposit(x); } } Runtime Ordering of Locks Account objects are dynamically ordered locks are acquired in runtime order

June 10, 2004Ownership Types14 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?

June 10, 2004Ownership Types15 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

June 10, 2004Ownership Types16 Programs can create a region Allocate objects in a region Delete a region & free all objects in it Region-Based Memory Management

June 10, 2004Ownership Types17 Type System for Regions class Stack  stackOwner, dataOwner  { Node  this, dataOwner  head; Node  this, dataOwner  head;} class Node  nodeOwner, dataOwner  { Node  nodeOwner, dataOwner  next; Node  nodeOwner, dataOwner  next; Data  dataOwner  data; Data  dataOwner  data;} (RegionHandle  r1  h1) { (RegionHandle  r2  h2) { (RegionHandle  r2  h2) { Stack  r1, r1  s1; Stack  r1, r1  s1; Stack  r2, r1  s2; Stack  r2, r1  s2; Stack  r1, r2  s3; // illegal Stack  r1, r2  s3; // illegal}} Scoping alone does not ensure safety in presence of subtyping First owner must be same as or nested in other owners

June 10, 2004Ownership Types18 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

June 10, 2004Ownership Types19 Real-Time Java Region types especially useful for Real-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

June 10, 2004Ownership Types20 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.

June 10, 2004Ownership Types21 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.

June 10, 2004Ownership Types22 Programming Overhead # Lines annotated # Lines of code Program Database Server Game Server HTTP Server Image Recognition java.util.Hashtable java.util.Vector Barnes Water

June 10, 2004Ownership Types23 RTJ Dynamic Checking Overhead Execution Time (sec) Static Checks Speed Up Dynamic Checks Program 13% Barnes 24% Water 18% save 10% thinning cross 25% load 21% Image Recognition

June 10, 2004Ownership Types24 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.

June 10, 2004Ownership Types25 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.

June 10, 2004Ownership Types26 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

June 10, 2004Ownership Types27 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.

June 10, 2004Ownership Types28 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.

June 10, 2004Ownership Types29 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