1. Light64: Lightweight Hardware Support for Data Race Detection during Systematic Testing of Parallel Programs A. Nistor, D. Marinov and J. Torellas to appear MICRO’09 LBA reading group – 09/29/09 (by Evangelos)

2. Introduction – Context Debugging of parallel applications Even for 1 input  too many interleavings Systematic Testing Execute many times - explore all interleavings Assumptions: Input provided Thread Interleaving only cause of non-determinism Goal: Hardware support for data race detection under Systematic Testing

3. Background of Systematic Testing Serializing of threads (multiplexing) New scheduler implementation Happens-before definition Segment-based interleaving

4. Background of Systematic Testing State: represented by a Serial Log; ordered list of segments

5. Background of Systematic Testing

6. Light64 – The Idea “Two different thread interleavings that have the same happens-before graph but a flipped data race, will very likely have at least a small deviation in the execution history”

7. Corner cases? No false positives; few false negatives Systematic tester environment highly deterministic Extremely improbable for two different streams of values to generate the same hash Cannot identify benign races; races on data that will never be consumed By construction…

8. Design Small hardware modifications CRC logic at the head of ROB ISA extensions; start/stop – save/load hash history Two modes of execution Passive Mode Active Mode Tradeoff between accuracy and performance

9. Passive Mode During step 4 Augment each state with the Execution History Hash. Check if executions with same happens- before have the same hash value (e.g., S2 & S11) No guarantees on coverage Dependable on systematic tester’s exploration strategy and pruning heuristics No practical overhead

10. Active Mode During step 2; While re-executing to reach the selected state ‘S’, flip as many segments as possible. Compare Execution History Hash against original execution Heuristic 1 – efficient segment reordering Smallest-ID Thread first during first run Biggest-ID Thread first during re-execution Heuristic 2 – additional re-executions to increase coverage ActiveFIN – re-execute all final states ActiveFULL – re-execute all states

11. Experimental Setup Used Pin to model a system running a systematic tester Instruction count as a performance metric SPLASH-2 benchmarks (modified & unmodified) 6 versions of a system: Plain, Plain+RD, ActiveNO, ActiveFIN, ActiveFULL, Passive

12. State Space Characterization

13. Race Detection Capability

14. Runtime Overhead

15. Runtime Overhead – Software- based

16. Conclusions Lightweight support for data race detection in a Systematic Tester world Relatively low overhead for S.T. Not a conventional MICRO paper