Michael bond ohio state milind kulkarni purdue
Download
1 / 26

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


  • 121 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Tracking Conflicting Accesses Efficiently for Software Record & Replay' - marv


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
Michael bond ohio state milind kulkarni purdue

Michael Bond (Ohio State)

MilindKulkarni (Purdue)

Tracking Conflicting Accesses Efficiently for Software Record & Replay



Record replay
Record & Replay

  • Offline replay

  • Reproduce production bugs

  • Online replay

  • Replication-based fault tolerance

  • Offloading of security events


Why is record replay hard
Why is record & replay hard?

  • Nondeterministic thread interleavings:

  • Synchronization

  • Data races


Prior work
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


Prior work1
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


Prior work2
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


Tracking conflicting dependences
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


Tracking conflicting dependences1
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


Tracking conflicting dependences2
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


Tracking conflicting dependences3
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


Tracking conflicting dependences4
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


Tracking conflicting dependences5
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


Tracking conflicting dependences6
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


Tracking conflicting dependences7
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?]


Recording happens before
Recording Happens-Before

  • safe point

  • if o.state = …

  • read o.f

Happens-before

Record dynamic program location


Replaying happens before
Replaying Happens-Before

  • safe point

  • if o.state = …

  • read o.f

Happens-before

Increment counter

Wait for counter


Replaying happens before1
Replaying Happens-Before

  • sync (o) {

  • write o.f

  • }

  • sync (o) {

  • read o.f

  • }

Happens-before


Replaying happens before2
Replaying Happens-Before

  • sync (o) {

  • write o.f

  • }

  • sync (o) {

  • read o.f

  • }

Happens-before




Challenge performance
Challenge: Performance

  • Non-conflicting accesses  very fast

  • Static analysis

  • Conflicting accesses  not too slow

  • Pessimistic concurrency?


Challenge replayability
Challenge: Replayability

  • Controlling other sources of nondeterminism:

  • I/O

  • Low-level VM concurrency

  • Timer-based sampling

  • Record vs. replay


Challenge replayability1
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


Challenge replayability2
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?


Summary
Summary

  • Software record & replay by

  • tracking conflicting dependences

  • Optimistic concurrency control

  • Performance & replayability challenges

  • Apply concurrency control mechanism

  • to other problems?


ad