Adversarial Memory for Detecting Destructive Races - PowerPoint PPT Presentation

cera
adversarial memory for detecting destructive races n.
Skip this Video
Loading SlideShow in 5 Seconds..
Adversarial Memory for Detecting Destructive Races PowerPoint Presentation
Download Presentation
Adversarial Memory for Detecting Destructive Races

play fullscreen
1 / 21
Download Presentation
Adversarial Memory for Detecting Destructive Races
139 Views
Download Presentation

Adversarial Memory for Detecting Destructive Races

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  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. Adversarial Memory • 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 lock’s vector clock per-thread vector clocks write buffer for location x: <value>@<clock> list “t0 writes value 13 to x at clock <4,0>” Available : 42@<4,0>, 13@<4,0>, 0@ Available : 42@<4,0>

  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