1 / 44

A Type System for Preventing Data Races and Deadlocks in the Java Virtual Machine Language

A Type System for Preventing Data Races and Deadlocks in the Java Virtual Machine Language. Pratibha Permandla Michael Roberson Chandrasekhar Boyapati. University of Michigan. Outline. Motivation Data Races Deadlocks Object Encapsulation Type System Related Work.

tanith
Download Presentation

A Type System for Preventing Data Races and Deadlocks in the Java Virtual Machine Language

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. A Type System for Preventing Data Races and Deadlocks in the Java Virtual Machine Language Pratibha Permandla Michael Roberson Chandrasekhar Boyapati University of Michigan

  2. Outline • Motivation • Data Races • Deadlocks • Object Encapsulation • Type System • Related Work

  3. Data Races in Multithreaded Programs • Two threads access the same data • At least one access is a write • No synchronization to separate accesses Thread 1: x = x + 1; Thread 2: x = x + 2;

  4. Why Data Races are a Problem • Some correct programs contain data races • But most races are programming errors • Code intended to execute atomically • Synchronization omitted by mistake • Consequences can be severe • Nondeterministic timing-dependent bugs • Difficult to detect, reproduce, eliminate

  5. Avoiding Data Races Thread 1: x = x + 1; Thread 2: x = x + 2;

  6. Avoiding Data Races • Associate locks with shared mutable data • Acquire lock before data access • Release lock after data access Thread 1: lock(l); x = x + 1; unlock(l); Thread 2: lock(l); x = x + 2; unlock(l);

  7. Avoiding Data Races Problem: Locking is not enforced! Inadvertent programming errors… Thread 1: lock(l); x = x + 1; unlock(l); Thread 2: lock(l); x = x + 2; unlock(l);

  8. Avoiding Deadlocks Thread n Lock 1 Lock n Thread 1 … Lock 3 Lock 2 Thread 2

  9. Avoiding Deadlocks • Associate a partial order among locks • Acquire locks in order ~ ~ Thread n Lock 1 Lock n Thread 1 … Lock 3 Lock 2 Thread 2

  10. Avoiding Deadlocks ~ ~ Thread n Lock 1 Lock n Thread 1 … Lock 3 Lock 2 Thread 2 Problem: Lock ordering is not enforced! Inadvertent programming errors…

  11. Object Encapsulation • Stack s is implemented with a linked list • Outside objects must not access list nodes s o ~ ~ • Enables local reasoning

  12. Object Encapsulation • Stack s is implemented with a linked list • Outside objects must not access list nodes s o ~ ~ Problem: Encapsulation is not enforced! Inadvertent programming errors…

  13. Solution • Type system for object-oriented languages • Statically prevents errors • data races, deadlocks, representation exposure • Programmers write simple annotations • how objects are synchronized • partial ordering on locks to prevent deadlocks • encapsulation hierarchy • Type checker statically verifies program • Objects are used only as specified

  14. Ownership Types • Every object is owned by • Another object, or • A thread, or • A special global owner called world • Ownership forms a tree rooted at world world Thread1 Thread2 Potentially shared objects Thread1 objects Thread2 objects

  15. Ownership Types • Prevent representation exposure • No references from outside object o to objects owned by o • No references from outside thread t to objects owned by t world  Thread1 Thread2 Potentially shared objects Thread1 objects Thread2 objects

  16. Ownership Types • Prevent races • For race free access to an object not owned by a thread • The lock on its outermost containing object must be held • For race free access to an object owned by a thread • No lock needs to be held Acquire Locks world Thread1 Thread2 Potentially shared objects Thread1 objects Thread2 objects

  17. Ownership Types • Prevent Deadlocks • Locks must be ordered according to a partial order • Locks must be acquired in descending order Acquire Locks world Thread1 Thread2 1 2 Potentially shared objects Thread1 objects Thread2 objects

  18. next next next value value value TStack Example class TStack { TNode head; void push(T value) {…} T pop() {…} } class TNode { TNode next; T value; … } class T {…} TStack head TNode T … … …

  19. TStack Example class TStackstackOwner, TOwner { TNodethis, TOwner head; … } class TNodenodeOwner, TOwner { TNodenodeOwner, TOwner next; TTOwner value; … } TStack TNode T

  20. TStack Example class TStackstackOwner, TOwner { TNodethis, TOwner head; … } class TNodenodeOwner, TOwner { TNodenodeOwner, TOwner next; TTOwner value; … } world Thread1 TStack T TStackthisThread, thisThread s1; TStackthisThread, world s2; TStackworld, world s3;

  21. Checking Programs Bytecodes Java Type checker Compiler + Extra types Virtual Machine • Previous work was on SafeJava

  22. Our Approach Bytecodes Java Type checker Compiler + Extra types + Extra types on interfaces Bytecode Verifier Intraprocedural Type Inference • Previous work was on SafeJava • We extend to SafeJVML • Verifies Java bytecodes Virtual Machine

  23. Example static void transfer(Account, Account, int); class Account { private int balance; static void transfer(Account from, Account to, int x) { synchronized (to) { synchronized (from) { if (from.balance != 0) { to.balance += x; from.balance -= x; } } } } } • No block structure • No types on stack or local variables • Requires alias analysis

  24. Example Fi[n] : Type of local variable n at instruction i Si : Types of elements of the stack at instruction i LSi : Types of locks held at instruction i Problem: Can’t tell which object is locked based on the type

  25. Indexed Types • Solution: Use indexed types • Laneve and Bigliardi (TIC ’00) • Example : Object3 • Objects with identical indexed types are equal • Otherwise, unknown

  26. Example

  27. Static Semantics

  28. Static Semantics  

  29. Static Semantics   

  30. Static Semantics    

  31. Static Semantics

  32. Properties of SafeJVML • SafeJVML programs are free of data races • SafeJVML programs are free of deadlocks • SafeJVML programs are free of encapsulation errors • Need a proof of these properties • Need a formalization of dynamic semantics

  33. o1 o3 o2 o4 o5 a : o3 f : o3 v : 2 a : o5 n : 1 o1 4 o4 o1 o1 Dynamic Semantics Thread1 Thread2 Heap Thread3 Thread4 First Activation Record Second Activation Record Current Activation Record M : foo pc : 6 Local Variables: Stack: 0 1 2 o3 7 o1 Locks:

  34. o4 o2 o1 o5 o3 a : o5 a : o3 f : o3 v : 2 n : 1 o1 4 o1 Dynamic Semantics Thread1 Thread2 Heap Thread3 Thread4 First Activation Record Second Activation Record Current Activation Record M : foo pc : 7 pc : 6 Local Variables: Stack: 2 0 1 2 o3 7 o1 Locks: o4 o1

  35. o2 o1 o5 o3 o4 f : o3 v : 2 a : o3 n : 1 a : o5 2 4 o1 Dynamic Semantics Thread1 Thread2 Heap Thread3 Thread4 First Activation Record Second Activation Record Current Activation Record M : foo pc : 8 pc : 7 Local Variables: Stack: 0 1 2 o3 7 o1 6 Locks: o4 o1

  36. o1 o2 o4 o5 o3 n : 1 f : o3 v : 2 a : o3 a : o5 6 o1 Dynamic Semantics Thread1 Thread2 Heap Thread3 Thread4 First Activation Record Second Activation Record Current Activation Record M : foo pc : 9 pc : 8 Local Variables: Stack: 0 1 2 o3 6 7 o1 Locks: o4 o1

  37. o1 o2 o4 o5 o3 a : o5 n : 1 f : o3 v : 2 a : o3 o1 Dynamic Semantics Thread1 Thread2 Heap Thread3 Thread4 First Activation Record Second Activation Record Current Activation Record M : foo pc : 10 pc : 9 Local Variables: Stack: 0 1 2 6 7 o1 Locks: o4 o1

  38. Dynamic Semantics

  39. Proof Sketch • Identify runtime invariants • Relating static and dynamic semantics • States satisfying invariants are well-typed • Prove that invariants always hold

  40. Proof Sketch • Preservation Theorem • A well-typed state only transitions to other well-typed states • Progress Theorem • A well-typed program state: • transitions to another state, or • terminates normally, or • has a null dereference

  41. Proof Sketch • Identify runtime invariants • Relating static and dynamic semantics • States satisfying invariants are well-typed • Prove that invariants always hold • Use invariants to prove properties • There are no data races • There are no deadlocks • Encapsulation is never violated

  42. Related Work • Preventing Data Races and Deadlocks in Java • Flanagan and Freund (PLDI ’00) • Bacon, Strom, and Tarafdar (OOPSLA ’00) • Boyapati and Rinard (OOPSLA ’01) • Boyapati, Lee, Rinard (OOPSLA ’02) • Grossman (TLDI ’03) • Enforcing Encapsulation in Java • Clarke, Potter, and Noble (OOPSLA ’98) • Clarke and Drossopoulou (OOPSLA ’02) • Aldrich, Kostadinov, and Chambers (OOPSLA ’02) • Boyapati, Liskov, Shiria (POPL ’03) • Krishnaswamy and Aldrich (PLDI ’05)

  43. Related Work • Formalizing JVML • Freund and Mitchell (OOPSLA ’98) • Bertelsen (WPAM ’98) • Qian (FSSJ ’99) • Formalizing subroutines in JVML • Stata and Abadi (POPL ’98) • Callahan (POPL ’99) • Klein and Wildmoser (JAR ’03) • Tracking aliases in JVML • Laneve and Bigliardi (TIC ’00) • Iwama and Kobayashi (ASIA-PEPM ’02)

  44. A Type System for Preventing Data Races and Deadlocks in the Java Virtual Machine Language Pratibha Permandla Michael Roberson Chandrasekhar Boyapati University of Michigan

More Related