light64: lightweight hardware support for data race detection during systematic testing of parallel...
TRANSCRIPT
Light64: Lightweight Hardware Support for Data Race Detection during Systematic Testing of Parallel Programs
A. Nistor, D. Marinov and J. Torellas
to appear MICRO’09LBA reading group – 09/29/09
(by Evangelos)
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
Background of Systematic Testing
• Serializing of threads (multiplexing)
• New scheduler implementation
• Happens-before definition
• Segment-based interleaving
Background of Systematic Testing
State: represented by a Serial Log; ordered list of segments
Background of Systematic Testing
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”
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…
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
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
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
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
State Space Characterization
Race Detection Capability
Runtime Overhead
Runtime Overhead – Software-based
Conclusions
Lightweight support for data race detection in a Systematic Tester world
Relatively low overhead for S.T. Not a conventional MICRO paper