1 / 21

Adversarial Memory for Detecting Destructive Races

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. Motivation. Multi-threaded programs often contain data races

cera
Download Presentation

Adversarial Memory for Detecting Destructive Races

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. 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

More Related