1 / 26

Tracking Conflicting Accesses Efficiently for Software Record & Replay

Michael Bond (Ohio State) Milind Kulkarni (Purdue). Tracking Conflicting Accesses Efficiently for Software Record & Replay. Concurrent software is nondeterministic Record & replay : more important & harder. Record & Replay. Offline replay Reproduce production bugs Online replay

marv
Télécharger la présentation

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. 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. 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?

More Related