ADVERSARIAL MEMORY FOR DETECTING DESTRUCTIVE RACES

Cormac Flanagan & Stephen FreundUC Santa Cruz Williams College

PLDI 2010

Slides by Michelle Goodstein

LBA Reading Group, June 2 2010

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

Outline

Motivation Review of Memory Models High-level idea of adversarial memory

Will be skipping the formalisms; they are in the paper

Results

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

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

Memory Models

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

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

Adversarial Memory

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

Adversarial Memory Exampleper-thread vector clocks

lock’s vector clock

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>

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

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

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

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

Custom Benchmarks

Experimental Results: Efficacy

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.

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

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

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

Conclusions

Data races are problematic Novel dynamic analysis to expose

destructive data races Complements statically checking all

valid SC interleavings