View
216
Download
1
Embed Size (px)
Citation preview
0wn3rship Types0wn3rship Types
John WhaleyCS343
Stanford University
May 19, 2004
June 10, 2004 Ownership Types 2
j00 got 0wn3d!!!1!
June 10, 2004 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.
June 10, 2004 Ownership Types 4
Must go through parent
Mommaobject
Babyobjects
“The Gatekeeper”
June 10, 2004 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.
June 10, 2004 Ownership Types 6
Where to lock?
CombinedAccount
Checking
Savings
Can lock onparent object
Can lock oneach child object
individually
What are the tradeoffs?
June 10, 2004 Ownership Types 7
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
~~~~
June 10, 2004 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
June 10, 2004 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
June 10, 2004 Ownership Types 10
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
June 10, 2004 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…
June 10, 2004 Ownership Types 12
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
June 10, 2004 Ownership Types 13
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;
… …
} }
June 10, 2004 Ownership Types 14
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
June 10, 2004 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?
June 10, 2004 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
June 10, 2004 Ownership Types 17
• Programs can create a region• Allocate objects in a region• Delete a region & free all objects in it
Region-Based Memory Management
June 10, 2004 Ownership Types 18
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
June 10, 2004 Ownership Types 19
• 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, 2004 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
June 10, 2004 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.
June 10, 2004 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.
June 10, 2004 Ownership Types 23
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
June 10, 2004 Ownership Types 24
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
June 10, 2004 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.
June 10, 2004 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.
June 10, 2004 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
June 10, 2004 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.
June 10, 2004 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.
June 10, 2004 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