1 / 30

0wn3rship Types

0wn3rship Types. John Whaley CS343 Stanford University. May 19, 2004. 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

inez
Download Presentation

0wn3rship Types

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. j00 got 0wn3d!!!1! Ownership Types

  3. 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. Ownership Types

  4. Must go through parent “The Gatekeeper” Momma object Baby objects Ownership Types

  5. 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. Ownership Types

  6. Where to lock? Checking CombinedAccount Savings Can lock onparent object Can lock oneach child objectindividually What are the tradeoffs? Ownership Types

  7. Preventing deadlocks ~ ~ Thread n Lock 1 Lock n • Associate a partial order for locks • Acquire locks in that order Thread 1 … Lock 3 Lock 2 Thread 2 Ownership Types

  8. 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 Ownership Types

  9. 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 Ownership Types

  10. Example savingsAccount belongs to savingsLevel checkingAccount belongs to checkingLevel locks are acquired in descending order locks held by callers > savingsLevel balance can acquire these locks checkingLevel < savingsLevel 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; }}} } Ownership Types

  11. 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… Ownership Types

  12. Tree Based Partial Orders nodes are locked in tree order nodes must be locked in tree order 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; }}} } this this x v y u v x w y u w Ownership Types

  13. DAG Based Partial Orders class Nodeself : l { dag Nodeself : l left; dag Nodeself : l right; … } • 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 Ownership Types

  14. Runtime Ordering of Locks Account objects are dynamically ordered locks are acquired in runtime order class Accountimplements 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); } } Ownership Types

  15. 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? Ownership Types

  16. 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 Ownership Types

  17. Region-Based Memory Management • Programs can create a region • Allocate objects in a region • Delete a region & free all objects in it Ownership Types

  18. Type System for Regions class StackstackOwner, dataOwner { Nodethis, dataOwner head; } class NodenodeOwner, dataOwner { NodenodeOwner, dataOwner next; DatadataOwner data; } (RegionHandler1 h1) { (RegionHandler2 h2) { Stackr1, r1 s1; Stackr2, r1 s2; 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 Ownership Types

  19. Other Details • 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 Ownership Types

  20. 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 Ownership Types

  21. 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. Ownership Types

  22. 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. Ownership Types

  23. Programming Overhead Program # Lines of code # Lines annotated HTTP Server 603 20 Game Server 97 10 Database Server 244 24 java.util.Vector 992 35 java.util.Hashtable 1011 53 Image Recognition 567 8 Water 1850 31 Barnes 1850 16 Ownership Types

  24. RTJ Dynamic Checking Overhead Program Execution Time (sec) Speed Up Dynamic Checks Static Checks Water 2.55 2.06 24% Barnes 21.6 19.1 13% Image Recognition 8.10 6.70 21% load 0.813 0.667 25% cross 0.014 0.014 thinning 0.026 0.023 10% save 0.731 0.617 18% Ownership Types

  25. 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. Ownership Types

  26. 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. Ownership Types

  27. 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 Ownership Types

  28. 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 Types

  29. 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. Ownership Types

  30. 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 Ownership Types

More Related