Michael bond ohio state milind kulkarni purdue
Download
1 / 26

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


  • 122 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


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?