+ All Categories
Home > Documents > Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Accesses Efficiently for Software Record & Replay

Date post: 02-Jan-2016
Category:
Upload: hayfa-phelps
View: 44 times
Download: 1 times
Share this document with a friend
Description:
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 - PowerPoint PPT Presentation
26
Tracking Conflicting Accesses Efficiently for Software Record & Replay Michael Bond (Ohio State) Milind Kulkarni (Purdue)
Transcript
Page 1: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Accesses Efficiently for Software Record & ReplayMichael Bond (Ohio State)Milind Kulkarni (Purdue)

Page 2: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Concurrent software is nondeterministic

Record & replay: more important & harder

Page 3: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Record & Replay

Offline replayReproduce production bugs

Online replay• Replication-based fault tolerance• Offloading of security events

Page 4: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Why is record & replay hard?

Nondeterministic thread interleavings:

• Synchronization• Data races

Page 5: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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

Page 6: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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

Page 7: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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

Page 8: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict

Synchronization conflicting access

T1if o.lastAccess != T1 …write o.f

T2if o.lastWrite != T2 …read o.f

Page 9: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need instrumentation at every accessSynchronization conflicting accessT1if o.lastAccess != T1 … o.lastAccess = T1write o.f

T2if o.lastAccess != T2 … o.lastAccess = T2read o.f

Page 10: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need synchronization at every accessSynchronization conflicting accessT1if o.lastAccess != T1 … o.lastAccess = T1write o.f

T2if o.lastAccess != T2 … o.lastAccess = T2read o.f

Page 11: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need synchronization at every access

at conflicting accesses onlyT1if o.lastAccess != T1 … o.lastAccess = T1write o.f

T2if o.lastAccess != T2 … o.lastAccess = T2read o.f

Page 12: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need synchronization at every access

at conflicting accesses onlyT2if o.lastAccess != T2 … … o.lastAccess = T2read o.f

Page 13: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need synchronization at every access

at conflicting accesses only

T1……safe point:…

T2if o.lastAccess != T2 … … o.lastAccess = T2read o.f

Page 14: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Tracking Conflicting Dependences

Every access might conflict:Need synchronization at every access

at conflicting accesses only

T1if o.state != WrExT1

…write o.f

T2if o.state in { WrExT2 , RdEx T2 , RdSh } …read o.f

Page 15: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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

Page 16: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Recording Happens-Before

…safe point

if o.state = … …read o.f

Record dynamic program location

Happens-before

Page 17: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Replaying Happens-Before

Increment counter Wait for counter

…safe point

if o.state = … …read o.f

Happens-before

Page 18: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Replaying Happens-Before

sync (o) { write o.f}

sync (o) { read o.f}

Happens-before

Page 19: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Replaying Happens-Before

sync (o) { write o.f}

sync (o) { read o.f}

Happens-before

Page 20: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Performance

eclip

se

hsql

db

xala

n

SPEC

jbb2

000

geom

ean

-10%

0%

10%

20%

30%

40%

50%

60%

70%

Track conf depsFast path

Ru

nti

me o

verh

ead

Page 21: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Performance

eclip

se

hsql

db

xala

n

SPEC

jbb2

000

geom

ean

-10%

0%

10%

20%

30%

40%

50%

60%

70%

Record & replayTrack conf depsFast path

Ru

nti

me o

verh

ead

Page 22: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Challenge: Performance

Non-conflicting accesses very fast• Static analysis

Conflicting accesses not too slow• Pessimistic concurrency?

Page 23: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Challenge: Replayability

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

Page 24: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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

Page 25: Tracking Conflicting Accesses Efficiently for Software Record & Replay

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?

Page 26: Tracking Conflicting Accesses Efficiently for Software Record & Replay

Summary

Software record & replay bytracking conflicting dependences• Optimistic concurrency control• Performance & replayability challenges

Apply concurrency control mechanismto other problems?


Recommended