1. SOS: Saving Time in Dynamic Race Detection with Stationary Analysis Du Li, Witawas Srisa-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 1 Thread 1 Thread 2 Release L Acquire L Write Read Race

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

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

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 4 *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 5 *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 6

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 7 *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 Initialization Read/write StationaryNon-Stationary ReadRead/write write lose Lose: write the address of an object to the heap. 8 Thread local, no race. Thread shared but no write, no race. Races can occur

10. Potential Savings Program All Reads (10 6 ) Non- Stationary Reads (10 6 ) Potential Savings (%) All Writes(1 0 6 ) Non- Stationary Writes (10 6 ) avrora25.8520.3721.222.012.00 eclipse63.4140.6535.9118.1318.04 hsqldb12.994.1767.891.901.87 pseudojbb4.082.0649.491.341.33 sunflow9.766.8030.330.2700.269 xalan8.865.4038.971.471.45 9

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 10

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 11

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

14. Two Versions SO = Monitoring state transitions in both baseline and optimizing compilers SO n = Monitoring state transitions only in the baseline compiler –Ignore state transitions in optimizing compiler 13

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

16. Exp 1: Overhead with 100% Sampling 15 Normalized against performance of FastTrack_ Pacer

17. Exp 1: Overhead with 100% Sampling 16 Program FastTrack Pacer SOSO n avrora5.14.54.2 eclipse21.016.88.2 hsqldb12.27.33.8 pseudojbb7.75.14.3 sunflow29.224.113.1 xalan11.67.12.6 Average13.810.35.9 Slowdown Factor (times)

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

19. Exp 2: Controlling Overhead 18

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

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%) 20

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

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

24. Shortcomings 23 Detected Races by FastTrack Detected Races by SO Detected Races by SO n

25. Shortcomings 24 Comparing the number of missed races in SO n 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 25

27. Acknowledgment Supported by NSF CNS-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 26

28. Q & A 27