A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks

1. A Randomized Dynamic Program Analysis Technique for Detecting Real Deadlocks Pallavi Joshi, Chang-Seo Park, KoushikSen and MayurNaik* (UC Berkeley & *ILB) PLDI 2009 Slides by Michelle Goodstein 10/5/10

2. Motivation • Deadlocks difficult to find in testing • Only occur under specific interleavings • Static tools can suffer from high false positives (7/100,000 real) • Annotations incur high overhead • Predictive tools have both false positives and false negatives • “Predictive”: using data from an instrumented execution to predict later executions • Goal: Algorithm that only reports real deadlocks

3. Outline • Motivation • Algorithm/Definitions • Potential Deadlock Detection • Checking Potential Deadlocks • Implementation/Results • Conclusions

4. DeadlockFuzzer • Idea: • Take deadlock detector (like Goodlock) that suffers from both false positives/negatives • For all reported deadlocks, try to schedule threads to ensure deadlock occurs

5. Part 1: Compute Potential Deadlocks • Given an execution, a lock dependency relation D is such that tuple (t, L, l, C)  D iff at some state in the execution, thread t acquires lock l while holding locks in L in context C • t: thread id, C: seq of labels of Acquire() stmts • l: lock about to acquire, L: set of locks held

6. Part 1, continued • Dependency chain: <(t1,L1,l1,C1),…,(tm,Lm,lm,Cm)> is a sequence such that: • For all i  j, ti tj (distinct threads) • For all i  j, li lj (locks to acquire are distinct) • For all i [1,m-1], li Lm+1 (each thread could wait for lock held by next thread) • For all i,j [1, m], i  j, LiLj = (each thread can acquire lockset Lj without waiting

7. Part 1, continued • Lock dependency chains lead to potential deadlock cycles if lm L1 • Purpose of context (C in relation): use to compute unique ID of object • After it is “abstracted”….

8. Calculating Dk (k-length) • Init: D1 = D (where D is lock dependency relation for entire execution)

9. Challenge: Abstractions • During phase 1: Unique ID of object often address • Address changes between iterations! • Need an abstraction, id based only on static info • Two abstraction techniques: • K-object sensitivity (skipping) • Light-weight execution indexing (next example)

10. absk(o): sequence of (…ci,qi,…) s.t. c1 is label of statement that creates o and q1 is # of times statement is executed in call stack (k-deep) Example (k=3, call depth) First object: [11,1,6,1,3,1] Last object:[11,3,7,1,3,5] Light-weight execution indexing 5 1 1 1 1 3

11. Phase 2: Checking for Real Deadlocks • Idea: schedule threads randomly • But want high probability of achieving deadlock! • When thread t is about to acquire lock l in context C and (t,l,C) is part of the cycle we’re testing: • Delay acquiring locks • Gives chance for another thread in potential deadlock cycle to acquire lock first • Biases probability of observing deadlock

13. Abstraction: t1 o2 t2 o1 context context Example

14. Implementation • Instrumenting Java bytecode • Dual socket Intel Xeon 2Ghz quad-server with 8GB RAM • Multiple benchmarks • Includes: Jigsaw, web server platform from W3C

15. Results

16. Performance/Probability

17. Finding new deadlocks Shutdown (orange): lock factory, try to lock csList SocketClient closing (lavender): lock csList, try to lock factory

18. Addressing Imprecision • iGoodlock is incomplete • Cannot tell whether predicted-but-not-produced deadlocks are false positives • Sometimes, happens-before info from lock acquire/release would help (18 cases in Jigsaw) • All others—could not manually decide

19. Conclusion • Deadlock detector that can point out real deadlocks • Interesting combination of deadlock prediction algorithm with thread scheduler • While imprecise, still does well at detecting known deadlocks and finding new ones

20. Extra

21. Calculating relation