1 / 22

LBA Reading Group 9/15/09 Presented by: Michelle Goodstein

PRES: Probabilistic Replay with Execution Sketching on Multiprocessors Soyeon Park and Yuanyuan Zhou (UCSD) Weiwei Xiong, Zuoning Yin, Rini Kaushik, Kyu H.Lee and Shan Lu (UIUC) SOSP 2009. LBA Reading Group 9/15/09 Presented by: Michelle Goodstein. Outline. Motivation PRES Architecture

kasen
Download Presentation

LBA Reading Group 9/15/09 Presented by: Michelle Goodstein

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. PRES: Probabilistic Replay with Execution Sketching on MultiprocessorsSoyeon Park and Yuanyuan Zhou (UCSD)Weiwei Xiong, Zuoning Yin, Rini Kaushik, Kyu H.Leeand Shan Lu (UIUC)SOSP 2009 LBA Reading Group 9/15/09 Presented by: Michelle Goodstein

  2. Outline • Motivation • PRES Architecture • Capturing Sketches • Replaying Intelligently • Evaluation • Conclusion

  3. Motivation Concurrency bugs are hard… Deterministic Replay can help, but… Deterministic Replay can be expensive What if only record partial information? • Good enough to reproduce bug vs actual execution • Reproduce bug in small (5-50) number of replays rather than first attempt?

  4. PRES • Probabilistic Replay via Execution Sketching • Records partial ordering during production run • Intelligently explores space of partial orderings • Use feedback from failed attempts to reproduce bug in subsequent explorations

  5. PRES Architecture • Sketch Recorders • Partial Information based Replayer (PI-Replayer) • Replay Recorder • Monitor • Feedback Generator

  6. PRES Architecture • Sketch Recorders • During production run • Captures partial ordering of events • Balance of efficiency and usefulness in replay

  7. PRES Architecture • Partial Information based Replayer (PI-Replayer) • During bug reproduction phase • Consults with sketch, feedback from attempts to reproduce bug • Sketch specifies ordering  do what sketch proscribes • Feedback says ordering did not produce bug  do something else • No info available – execute however desired

  8. PRES Architecture • Replay Recorder • Deterministic replay recorder • Necessary to produce feedback • When bug reproduced, have a deterministic record of how to repeat with 100% probability

  9. PRES Architecture • Monitor: • Tracks replays and detects: • Deviations from sketch (new replay necessary) • Bug reproduced (success!)

  10. PRES Architecture • Feedback Generator • Uses info from recorder to provide feedback for future replay attempts • Try to figure out why bug not discovered

  11. Sketch Recorders • Baseline (Base) • Everything necessary for det. replay on uniprocessor • Synchronization recorder (Sync) • Above + global order at high-level synch ops • System call recorder (Sys) • Above + global order of syscalls • Function call recorder (Func) • Global order of all function calls (Michelle: also + above???) • Nth-Basic block recorder (BB-n) • Records the nth basic block executed, (count is global) • Basic Block recorder (BB) • Global order of all basic blocks • Shared reads/writes (RW) • Standard deterministic replay

  12. Sketch Recorders

  13. Replaying Intelligently • Monitor observes currently replay • Compares current replay to sketch to notice when to abort • Inconsistent or off-sketch • Bug reproduced • Operates only on visible events • Exceptions, timer signals, outputs

  14. Replaying Intelligently • Unsuccessful replays • Sketches that are not RW miss some shared memory data races • If race occurs in certain orders, bug may not manifest • Idea: use info (feedback) from prior runs to guide choice of ordering in next replay attempt

  15. Replaying Intelligently: Generating Feedback • Need to do full RW recording of replay attempt • Using failed replay recordings, identify data races • Filter out data races where sketch implies ordering • Select a data race to invert ordering of • Heuristic, chooses a replay recording and then the race closest to fault • On next replay, execute deterministically until data race encountered, flip order • Then, default PI-Replayer behavior takes over

  16. Evaluation

  17. Evaluation

  18. Evaluation

  19. Evaluation

  20. Evaluation

  21. Evaluation

  22. Conclusion • Interesting use of partial orders as compromise between efficiency and replay • Partial information often sufficient to recover buggy ordering • Similarities to the CHESS paper presented earlier

More Related