FastTrack : Efficient and Precise Dynamic Race Detection

1. FastTrack: Efficient and Precise Dynamic Race Detection Cormac Flanagan and Stephen Freund PLDI 2009 Slides by Michelle Goodstein 07/26/10

2. Motivation • 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

3. Intuition • 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

4. Notation • 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

5. Review of vector clocks (DJIT+alg) • V1 < V2 if V1(t) ≤ V2(t) for all t (happens-before rltn) • Each thread, lock has own vector clock Ct • Increment own clock on lock release • Lock VCs are updated on acquire/release ops • Thread t releases lock m: Copy Ct to Cm • Thread t’ acquires lock m: Ct’ = maxt (Ct’ (t), Cm(t)) t • Each location x gets 2VCs – 1 for reads, 1 for writes • Rx(t), Wx(t) record last read, write to x by thread t • Read from x by thread t is race-free if Wx ≤ Ct • All writes happen-before current read

6. DJIT+

7. Intuition: Detecting races • 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: c@t : O(1) space for epochs • c@t ≤ V iff c ≤ V(t) : O(1) comparison time • Detect: Write-Read race • Check Wx ≤ Ct

8. FastTrack

9. Intuition: Detecting Races • 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

10. Read Rules • 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

11. Read Rules (82.3% of ops) • 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

12. Write Rules: • Write-Same-Epoch: • x already written this epochno change • Write-Exclusive: • If Rx is an epoch, Rx ,Wx≤ Ct update write epoch • Write-Shared: • Rx is a VC, Rx ,Wx≤ Ct update write epoch, set Rx to “empty” epoch

13. Write Rules: (14.5% of ops) • Write-Same-Epoch: (71% of writes) • x already written this epochno change • Write-Exclusive: (28.9% of writes) • If Rx is an epoch, Rx ,Wx≤ Ct update write epoch • Write-Shared: (0.1% of writes) • Rx is a VC, Rx ,Wx≤ Ct update write epoch, set Rx to “empty” epoch

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

15. FastTrack in Action

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

17. Evaluation • 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

18. Evaluation • Benchmarks: 16 • Apple Mac Pro • Dual-3Ghz quad-core Pentium Xeon Processors • 12 GB memory • OSX 10.5.6, 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

19. Results: Precision and Efficiency

20. Results: VCs allocated/benchmark

21. Results: Fine vs Coarse Grain Analysis

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

23. Junk

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