1. ADVERSARIAL MEMORY FOR DETECTING DESTRUCTIVE RACES Cormac Flanagan & Stephen Freund UC Santa Cruz Williams College PLDI 2010 Slides by Michelle Goodstein LBA Reading Group, June 2 2010

2. Motivation  Multi-threaded programs often contain data races  Hardware with relaxed memory consistency models may still behave like SC most of the time  Hard to classify data races as benign or destructive  New dynamic analysis technique:  Adversarial Memory

3. Outline  Motivation  Review of Memory Models  High-level idea of adversarial memory  Will be skipping the formalisms; they are in the paper  Results

4. Memory Models  Sequential Consistency (SC): Once x is non-null, the conditional in Thread 2 will evaluate to true  Java Relaxed Memory Model (JMM): Each of thread 2’s reads of x is independently null/non-null  Initially: T2 reads x non-null, passes conditional  Then x appears null, and x.draw() throws exception

5. Memory Models  Trace: sequence of ops performed by threads  Happens-Before Memory Model (HB):  A read(x) operation A in a trace can return the value written by any write(x) operation B so long as B is either concurrent or happens before A (B doesn’t occur after A) no write C exists such that B < C < A in the trace (< :happens-before)  Progressive Java Memory Model (PJ):  A read(x) operation A in a trace can return the value written by any write(x) operation B so long as B executes before A in the trace No intervening write(x) C exists where B < C < A  JMM: Happens-Before + Causality

6. Memory Models  JMM, HBMM allow a potential future value to be read. PJMM only allows values def. in past to be read

7. Adversarial Memory  Hardware is often SC-like even when it doesn’t guarantee SC  Hard to see where races can truly be problematic  Stress-test racy Java code  Return old but still valid values (according to consistency model)  Maintain write buffer to each shared variables involved in races  On read  Compute set of visible values that do not violate consistency model  Return “worst case” according to heuristic

8. Adversarial Memory

9.  Authors provide operational semantics  Skipping here  On reads, looks within write buffers for any write that could still be visible  Only one write will be returned  Use heuristics to choose  “Most recent” write—very SC-like  “Oldest” write—further from SC

10. Adversarial Memory Example per-thread vector clocks lock’s vector clock write buffer for location x: @ list “t0 writes value 13 to x at clock ” Available : 42@, 13@, 0@  Available : 42@

11. Adversarial Memory Heuristics  Sequentially Consistent: Return most recent write  Oldest: Return oldest value  Intuition: staler the value, the likelier to cause problems  Oldest-but-different  Consider if(x != null) {x.draw();}  What if x always reads null ?  Gets out of infinite loop  Random  Random-but-different

12. Implementation  JUMBLE: Java-based implementation, on RoadRunner framework  Use precise race detector to discover racy shared vars  Focus on one location at a time  Special Cases  Arrays: Sample indices, and only jumble accesses to a few indices  Long/Double: Treat 8B as 2 non-atomic 4B accesses

13. Experimental Setup  Examined 10 race conditions discovered by FASTTRACK  Compared performance under 6 different memory implementations:  No Jumble  SC  Oldest  Oldest-but-different  Random  Random-but-different

14. Experimental Setup  For each race & configuration  100 tests to detect how frequently race caused error  Race on fields: jumbled reads from all instances of field  Race on arrays: jumbled reads from all arrays at indices 0 & 1

15. Custom Benchmarks

16. Experimental Results: Efficacy

17. Some Discussion (More in Paper)  montecarlo: Writes same value to global  mtrt: threadcounter is incremented by parent, decremented by child. Never used elsewhere, so corruption of this variable does not matter.

18.  Figure 8: null-ptr exception generated, since both null and non-null are available for x. Oldest fails due to infinite loop  Figure 2: p can be initialized before p.x becomes non-zero, causing a divide-by-zero at line 17

19. Performance Results  Performance of other heuristics similar to SC, except in degenerate cases  EMPTY: 1.2x-1.5x (instrumentation)  JUMBLE slowdown similar to EMPTY except:  tsp, sor, moldyn  Compression can greatly shrink size needed for write buffer

20. Eclipse Results  FASTTRACK found 27 races  Ran Jumble once/race  4 races: null ptr exceptions  4 races: non-deterministic reads, no bug  Remaining fields: no non-deterministic reads detected  Races on fields where the same value is written

21. Conclusions  Data races are problematic  Novel dynamic analysis to expose destructive data races  Complements statically checking all valid SC interleavings