Michael bond ohio state milind kulkarni purdue
This presentation is the property of its rightful owner.
Sponsored Links
1 / 26

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


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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

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


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

  • Concurrent software is nondeterministic

  • Record & replay: more important & harder


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


Performance

Performance


Performance1

Performance


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?


  • Login