Up

The RoadRunner Dynamic Analysis Framework for Concurrent Programs

The RoadRunner Dynamic Analysis Framework for Concurrent Programs
1 · 2 · 3 · 4 · 5 · 6

1 Concurrency defects: (1) race conditions, (2) deadlocks, (3) violations of desired atomicity, (4) violations of determinism properties. Event is operation of interest: accessing memory, acquiring a lock, forking a new thread, etc. RoadRunner is written entirely in Java, with no modifications to the underlying JVM. It adds instrumentation code to the target program's bytecode at load time. Writing back-end only requires defining methods to handle various events of interest.

2 Tools can be composed into a tool chain. Oh! They implement Eraser with tool chain: ThreadLocal, ReadOnly, and LockSet. They said their HappensBefore is slow and filters like ThreadOnly and ReadOnly can significantly improve it. RoadRunner has pipe-and-filter architecture. 3 It has ShadowThread object for each Thread JVM object. And ShadowLock. Decoration class contains user-defined fields for tool-specific information associated with threads and locks. And ShadowVarshadow location for each memory location. For each memory access access method is called. I think it is too slow, AddressSanitizer should be faster. 4 They have single shadow location for each memory location for all tools in tool chain.

5 Instrumentator works at classes loading and is build using ASM. 6 It has shadow for fields, replaces all gets and sets by own methods, has shadow arrays for arrays. Optimizations lies on JIT's aggressive inlining. They use HotSpot. They compare themselves with SOOT, Sofya (has its own JVM), CalFuzzer, ATOM (Eraser built on top of ATOM), and Valgrind.

Seems like it is very slow but easy-to-use.

Sergey Vartanov, 2007–2020