Effective and Inexpensive(Memory) Race Recording.pptVIP

Effective and Inexpensive(Memory) Race Recording Min Xu Thesis Defense 05/04/2006 Electrical and Computer Engineering Department, UW-Madison Advisors: Mark Hill, Rastislav Bodik Committee: Remzi Arpaci-Dusseau, Mikko Lipasti, Barton Miller, David Wood Overview Increasingly useful to replay multithreaded code Race recording: key to dealing with nondeterminism A Case Study Long recording: 1 byte/kilo-instr Always-on recording: less than 2% overhead Low cost: 24 KB RAM/core Support both SC TSO (x86-like) Thesis Contributions Outline Multithreaded Debugging % gcc hash.c % a.out Segmentation fault % Race Recording Recording for Multithreaded Replay A Good Race Recorder Desired Existing Race Recorders Problem Formulation Log All Conflicts ? Detect conflicts ? Write log Netzer’s Transitive Reduction The Intuition of the New RTR Algorithm Stricter Dependences to Aid Vectorization Compress Vectorized Dependencies Detect Conflicts Use Cache and Cache Coherence Cache Evictions and Writebacks Implement TR and RTR in Hardware Ideal TR requires vector timestamps Too expensive New idea: Pairwise-TR (use scalar timestamp) Enable pairwise transitive reduction Optimal RTR algorithm is likely expensive Implement a greedy RTR algorithm One-pass, online algorithm Keep a sliding window of vectorizable dependencies Hardware Implementation Timestamp Approximation Set/LRU Approximation Hardware Cost of Timestamps Coupled timestamp memory: overhead ? cache size Not flexible 64B line + 64b (24b) timestamp ? 12.5% (4.7%) overhead 192 KB for a 4MB L2 Need to modify cache Decoupled Timestamp Memory Decoupling ? Small timestamp memory (Set/LRU) e.g., 32-set, 64-way ? 99% transitive reduction Timestamps Memory ? 24 KB No need to modify cache Recording with Total Store Order (TSO) Majority of existing MP are non-SC TSO is well defined, x86-like TSO Execution Order-Value-Hybrid Recording Hybrid Recording with TR and RTR Hybrid recording All loads get correct values Hardware similar