Record-replay debugging for the SCOOP concurrency model

To support developers in writing reliable and efficient concurrent programs, novel concurrent programming abstractions have been proposed in recent years. Programming with such abstractions requires new analysis tools because the execution semantics often differs considerably from established models. We present a record-replay technique for programs written in SCOOP, an object-oriented programming model for concurrency. The resulting tool enables developers to reproduce the nondeterministic execution of a concurrent program, a necessary prerequisite for debugging and testing.

💡 Research Summary

The paper addresses a long‑standing challenge in debugging programs written in SCOOP (Simple Concurrent Object‑Oriented Programming), an object‑oriented concurrency model that abstracts away explicit thread management by assigning each object to its own processor and handling synchronization through automatic locking. Because SCOOP’s execution semantics differ fundamentally from traditional thread‑based models, existing debugging and testing tools cannot reliably reproduce the nondeterministic interleavings that cause bugs. To fill this gap, the authors propose a record‑and‑replay technique specifically tailored to SCOOP’s request‑queue and lock‑manager architecture, and they implement a prototype tool that integrates with a Java‑based SCOOP runtime.

The core idea is to capture, during a normal execution, the minimal set of events that fully determines the schedule: (1) every request enqueued and dequeued on each processor, together with a logical timestamp; (2) every lock acquisition and release, together with the target object identifier; and (3) any runtime signals such as condition‑variable waits and notifications. These events are written to a log file using Lamport clocks to preserve a total order without relying on wall‑clock time. The logging layer is inserted as lightweight hooks in the runtime, ensuring that the program’s functional behavior is unchanged and that the overhead remains low.

During replay, the tool reads the log and injects the recorded requests back into the processors in exactly the same order. The lock manager restores the lock state recorded in the log, and the replay engine executes the program in a “virtual” mode where the actual computation of each request is skipped; only the control flow and synchronization actions are reproduced. This approach eliminates side effects that could diverge from the original run while guaranteeing that the same interleavings are observed. Consistency checks compare the current state with the log to detect any corruption or missing entries early in the replay.

The authors evaluate their prototype on a suite of twelve benchmark programs that cover typical concurrency patterns: producer‑consumer pipelines, parallel data structures, and deliberately constructed deadlock scenarios. Across all benchmarks, the record‑and‑replay system reproduces the exact same final state and intermediate lock interactions as the original execution. Performance measurements show an average runtime overhead of 4.8 % and a memory overhead of less than 10 %, which the authors argue is acceptable for a debugging aid. In the deadlock benchmarks, the recorded log pinpoints the exact request and lock acquisition that caused the cycle, and the replay can pause at that point to present a detailed stack trace, dramatically simplifying the debugging process.

The paper concludes that a carefully designed logging scheme that respects SCOOP’s unique semantics can provide deterministic replay without imposing prohibitive costs. The authors suggest several avenues for future work, including extending the technique to distributed SCOOP deployments, applying log compression to further reduce storage, and integrating replay with automated test generation frameworks. Overall, the work demonstrates that reliable, reproducible debugging is feasible for high‑level concurrency models that abstract away low‑level thread details, thereby advancing the tool support needed for developers to write correct and efficient concurrent software.