michael bond ohio state milind kulkarni purdue n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
Tracking Conflicting Accesses Efficiently for Software Record & Replay PowerPoint Presentation
Download Presentation
Tracking Conflicting Accesses Efficiently for Software Record & Replay

Loading in 2 Seconds...

play fullscreen
1 / 26
hayfa-phelps

Tracking Conflicting Accesses Efficiently for Software Record & Replay - PowerPoint PPT Presentation

111 Views
Download Presentation
Tracking Conflicting Accesses Efficiently for Software Record & Replay
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. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Michael Bond (Ohio State) MilindKulkarni (Purdue) Tracking Conflicting Accesses Efficiently for Software Record & Replay

  2. Concurrent software is nondeterministic • Record & replay: more important & harder

  3. Record & Replay • Offline replay • Reproduce production bugs • Online replay • Replication-based fault tolerance • Offloading of security events

  4. Why is record & replay hard? • Nondeterministic thread interleavings: • Synchronization • Data races

  5. Prior Work • Detects races  high overhead • [LeBlanc & Mellor-Crummey ’87] • Custom hardware support • [FDR] [Rerun] [Strata] [DeLorean] [MRR] • Doesn’t support offline or online replay • [Respec] [ODR] [PRES] [Weeratunge et al. ’10] • DoublePlay: extra cores; doesn’t scale well

  6. Prior Work • Detects races  high overhead • [LeBlanc & Mellor-Crummey ’87] • Custom hardware support • [FDR] [Rerun] [Strata] [DeLorean] [MRR] • Doesn’t support offline or online replay • [Respec] [ODR] [PRES] [Weeratunge et al. ’10] • DoublePlay: extra cores; doesn’t scale well

  7. Prior Work • Detects races  high overhead • [LeBlanc & Mellor-Crummey ’87] • Custom hardware support • [FDR] [Rerun] [Strata] [DeLorean] [MRR] • Doesn’t support offline or online replay • [Respec] [ODR] [PRES] [Weeratunge et al. ’10] • DoublePlay: extra cores; doesn’t scale well Don’t track conflicting dependences

  8. Tracking Conflicting Dependences • Every access might conflict • Synchronization conflicting access T1 if o.lastAccess != T1 … write o.f T2 if o.lastWrite != T2 … read o.f

  9. Tracking Conflicting Dependences • Every access might conflict: • Need instrumentation at every access • Synchronization conflicting access T1 if o.lastAccess != T1 … o.lastAccess = T1 write o.f T2 if o.lastAccess != T2 … o.lastAccess= T2 read o.f

  10. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • Synchronization conflicting access T1 if o.lastAccess != T1 … o.lastAccess = T1 write o.f T2 if o.lastAccess != T2 … o.lastAccess= T2 read o.f

  11. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • at conflicting accesses only T1 if o.lastAccess != T1 … o.lastAccess = T1 write o.f T2 if o.lastAccess != T2 … o.lastAccess= T2 read o.f

  12. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • at conflicting accesses only T2 if o.lastAccess != T2 … … o.lastAccess= T2 read o.f

  13. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • at conflicting accesses only T1 … … safe point: … T2 if o.lastAccess != T2 … … o.lastAccess= T2 read o.f

  14. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • at conflicting accesses only T1 if o.state != WrExT1 … write o.f T2 if o.state in { WrExT2 , RdExT2 , RdSh} … read o.f

  15. Tracking Conflicting Dependences • Every access might conflict: • Need synchronization at every access • at conflicting accesses only Related to locality & ownership tracking [Shasta] [Biased locking] [von Praun & Gross ’01] [CoreDet?] [IBM’s STM?]

  16. Recording Happens-Before • … • safe point • if o.state = … • … • read o.f Happens-before Record dynamic program location

  17. Replaying Happens-Before • … • safe point • if o.state = … • … • read o.f Happens-before Increment counter Wait for counter

  18. Replaying Happens-Before • sync (o) { • write o.f • } • sync (o) { • read o.f • } Happens-before

  19. Replaying Happens-Before • sync (o) { • write o.f • } • sync (o) { • read o.f • } Happens-before

  20. Performance

  21. Performance

  22. Challenge: Performance • Non-conflicting accesses  very fast • Static analysis • Conflicting accesses  not too slow • Pessimistic concurrency?

  23. Challenge: Replayability • Controlling other sources of nondeterminism: • I/O • Low-level VM concurrency • Timer-based sampling • Record vs. replay

  24. Challenge: Replayability • Controlling other sources of nondeterminism: • I/O • Low-level VM concurrency • Timer-based sampling • Record vs. replay Different heap layouts  different hash codes

  25. Challenge: Replayability • Controlling other sources of nondeterminism: • I/O • Low-level VM concurrency • Timer-based sampling • Record vs. replay Different heap layouts  different hash codes Deterministic hash codes?

  26. Summary • Software record & replay by • tracking conflicting dependences • Optimistic concurrency control • Performance & replayability challenges • Apply concurrency control mechanism • to other problems?