SOS: Saving Time in Dynamic Race Detection with Stationary Analysis

1. SOS: Saving Time in Dynamic Race Detection with StationaryAnalysis Du Li, WitawasSrisa-an, Matthew B. Dwyer

2. Data Race • Two concurrent accesses to the same data, and at least one access is a write • One of the most common concurrency bugs Thread 1 Thread 2 Release L Acquire L Race Write Read

3. Dynamic Race Detection • Lockset based approaches • Imprecise (false positive) • Eraser • Vector-clock based approaches • Precise • FastTrack

4. Vector Clock & Race Detection Thread 1 Thread 2 (2, 3) (1, 4) Release L (1, 5) Require L (2, 4) (2,0) does not happen before (1,5) Write (2, 4) (0, 0) Read (2, 0) (1, 5) Race

5. Overhead of Vector Clock Based Race Detection • Compare and update vector clocks • Greatly reduced by FastTrack* • Reduce comparison cost by replacing vector clock with epoch, O(n) to O(1) • Still suffers 8.5X slowdown • Monitor read/write operations • A dominating cost • Monitor lock operations • Not a major factor due to small number of locks *Flanagan and Freund. FastTrack: Efficient and Precise Dynamic Race Detection (PLDI '09)

6. Reducing R/W Monitors • Race detection in deployed software??? • Pacer*: “get what you pay for” • Based on FastTrack, precise • Use random sampling to reduce monitoring efforts • 3% sampling rate yields 86% overhead • 100% sampling rate yields 13.8x slowdown • Detection rate = Sampling rate • *Bond, Coons, and McKinley. PACER: Proportional Detection of Data Races (PLDI '10).

7. Reducing R/W Monitors Focus of our Work Monitor only objects that can race and ignore those that cannot race while maintaining precision

8. Stationary Analysis • Final fields • Fields: written only once during execution • Stationary fields* • Fields: all writes occur before all reads • Stationary objects • Objects: read-only after thread escaping *Unkel and Lam. Automatic Inference of Stationary Fields: A Generalization of Java's Final Fields. (POPL '08)

9. Stationary Analysis • Object lifecycle • Only monitor reads/writes to objects in non-stationary state Read/write Read Read/write Thread local, no race. Thread shared but no write, no race. Races can occur write lose Initialization Stationary Non-Stationary Lose: write the address of an object to the heap.

10. Potential Savings

11. Implementation • Built on Pacer code base, which is on top of Jikes RVM 3.1.0 • Instrument R/W barriers to monitor object state transitions

12. Main Features • Enable/disable monitoring at run time on a per object basis • Efficient dynamic analysis to detect stationary objects • Optimistically assume all thread shared objects are stationary until a write is observed

13. Further Optimization • Insights: • Races tend to occur in cold region of code* • Most races occur repeatedly; some of them occur thousands of times in a run • Reduce monitoring for hot code • Ignore object state transitions from stationary to non-stationary in hot code * Marino, Musuvathi, and Narayanasamy. LiteRace: Effective Sampling for Lightweight Data-race Detection. (PLDI '09).

14. Two Versions • SO = Monitoring state transitions in both baseline and optimizing compilers • SOn= Monitoring state transitions only in the baseline compiler • Ignore state transitions in optimizing compiler

15. Two Types of Evaluations • Experiment 1: Turn on sampling at 100% and measure overhead between Pacer, SO, and SOn • Experiment 2: Control the amount of overheads then measure the number of detected races (unique) between SOn and Pacer for each overhead value.

16. Exp 1: Overhead with 100% Sampling Normalized against performance of FastTrack_Pacer

17. Exp 1: Overhead with 100% Sampling Slowdown Factor (times)

18. Two Types of Evaluations • Experiment 1: Turn on sampling at 100% and measure overhead between Pacer, SO, and Son • Experiment 2: Control the overheads via sampling then measure the number of detected races (unique) between SOn and Pacer for each overhead value

19. Exp 2: Controlling Overhead

20. Exp 2: Controlling Overhead Comparing race detection effectiveness (average) between SOn and Pacer

21. Summary of Evaluation • Average overhead with 100% sampling is 45% of a FastTrack implementation in Pacer • Up to a factor of 6 times more races than Pacer with tight overhead budget (100%)

22. Shortcomings • SOS misses races due to • Optimistic stationary analysis Thread 1 Thread 2 Still Stationary No monitor Now non-stationary read write missed —— Stationary —— Non-stationary

23. Shortcomings • When compare to 100% sampling, SOS misses races due to • Optimistic stationary analysis • Further optimization (SOn) • No monitoring of state change in the optimizing compiler

24. Shortcomings Detected Races by SO Detected Races by SOn Detected Races by FastTrack

25. Shortcomings Comparing the number of missed races in SOn with that of SO normalizing with the number of races detected by FastTrack.

26. Conclusions • Dynamic stationary analysis • Implemented inside a JVM to support per object monitoring • Reduce the overhead of monitoring R/W operations in vector-clock based race detection • Applicable to general race detection approaches • When combining with sampling, increase the detection effectiveness while maintaining low overhead • Make race detection in deployed systems more feasible

27. Acknowledgment • Supported by NSFCNS-0720757 and CCF-0912566, NASA NNX08AV20A, AFOSR FA9550-09-1-0129 and FA9550-09-1-0687 • Many thanks to Stephen Blackburn for Psedujbb2005 and authors of Pacer for their making their implementation available and insightful discussions

28. Q & A