Cormac Flanagan and Stephen Freund PLDI 2009 Slides by Michelle Goodstein 07/26/10

Eraser/LockSet algorithms are fast but imprecise Suffer from false positives Vector-clock (VC) data race detectors are precise but slow Want: Fast and precise FastTrack

Don’t always need full power of VCs Majority of data: Thread local Lock protected Read shared Common cases: O(1) fast path General case: No loss of precision/correctness

Epoch: (VC, t), t  Tid, x  Var, m  Lock Operations: rd(t,x), wr(t,x), aq(t,m), rel(t,m), fork(t,t’), join(t,t’) Trace of operations: α sequence of ops performed by threads Happens before < α : smallest transitively closed relation such that a < α b holds when a occurs before b in α because of: Program order Locking Fork-join

V 1 < V 2 if V 1 (t) ≤ V 2 (t) for all t (happens-before rltn) Each thread, lock has own vector clock C t Increment own clock on lock release Lock VCs are updated on acquire/release ops Thread t releases lock m: Copy C t to C m Thread t’ acquires lock m: C t’ = max t (C t’ (t), C m (t))  t Each location x gets 2VCs – 1 for reads, 1 for writes R x (t), W x (t) record last read, write to x by thread t Read from x by thread t is race-free if W x ≤ C t All writes happen-before current read

Observation: writes are totally ordered until a data race detected Only guarantee to detect first data race on loc x Detect: Write-Write race No race detected on x so far? Only need clock c and thread t of writer Epoch: : O(1) space for epochs ≤ V iff c ≤ V(t) : O(1) comparison time Detect: Write-Read race Check W x ≤ C t

Detect: Read-Write race Reads not guaranteed ordered in race-free program In practice: thread-local, lock-protected reads ordered Typically, reads only unordered when read-shared Adaptive representation: If read is ordered, record epoch of last read If read not ordered, store entire VC Can still perform epoch-VC comparison in O(1) time

Read-Same-Epoch: x already read this epoch  no work Read-Exclusive: current read happens-after prior read epoch  update read epoch Read-Share: current read may be concurrent with prior read  allocate VC to record epochs of both reads Read-Shared: x already shared (already tracking VC)  update VC

Read-Same-Epoch: (63.4% of reads) x already read this epoch  no work Read-Exclusive: (15.7% of reads) current read happens-after prior read epoch  update read epoch Read-Share: (0.1% of reads) current read may be concurrent with prior read  allocate VC to record epochs of both reads Read-Shared: (20.8% of reads) x already shared (already tracking VC)  update VC

Write-Same-Epoch: x already written this epoch  no change Write-Exclusive: If R x is an epoch, R x,W x ≤ C t  update write epoch Write-Shared: R x is a VC, R x,W x ≤ C t  update write epoch, set R x to “empty” epoch

Write-Same-Epoch: (71% of writes) x already written this epoch  no change Write-Exclusive: (28.9% of writes) If R x is an epoch, R x,W x ≤ C t  update write epoch Write-Shared: (0.1% of writes) R x is a VC, R x,W x ≤ C t  update write epoch, set R x to “empty” epoch

Acquire, Release, Fork, Join: Rare Use full VCs Correct/Precise: FastTrack reports data races iff detects concurrent conflicting accesses

RoadRunner Like DBI but for Java Instruments bytecode at runtime 32 bit epochs 8 bit tid 24 bit clock could also use 64-bit

7 dynamic analyses: Empty RoadRunner overhead FastTrack Eraser (+ barrier synch) DJIT + MultiRace DJIT + lock set Update lock set for locn on first access in epoch Full VC comparisons after lockset empty Imprecision/unsoundness from eraser GoldiLocks Precise race detector Tracks synch devices & threads Requires tight integration with VM, garbage collector BasicVC Read, Write VCs per mem location All implemented on RoadRunner

Benchmarks: 16 Apple Mac Pro Dual-3Ghz quad-core Pentium Xeon Processors 12 GB memory OSX , Java Hotspot 64-bit Server VM v1.6.0 JVM startup time excluded Report at most one race per field in a class or array access in program source

Interesting potential lifeguard Performance of eraser, precision of VC-based algorithm Unclear how will perform on non-Java platform?

Init: empty (bottom) epochs Write-exclusive Read-Exclusive due to fork Read-Share Write-Shared happens-after b/c of join Read-Exclusive