Visible to the public Processor-Oblivious Record and Replay

TitleProcessor-Oblivious Record and Replay
Publication TypeConference Paper
Year of Publication2017
AuthorsUtterback, Robert, Agrawal, Kunal, Lee, I-Ting Angelina, Kulkarni, Milind
Conference NameProceedings of the 22Nd ACM SIGPLAN Symposium on Principles and Practice of Parallel Programming
PublisherACM
Conference LocationNew York, NY, USA
ISBN Number978-1-4503-4493-7
Keywordsdeterministic replay, dynamic program analysis, Human Behavior, pattern locks, pubcrawl, reproducible debugging, resilience, Resiliency, Scalability, work stealing
AbstractRecord-and-replay systems are useful tools for debugging non-deterministic parallel programs by first recording an execution and then replaying that execution to produce the same access pattern. Existing record-and-replay systems generally target thread-based execution models, and record the behaviors and interleavings of individual threads. Dynamic multithreaded languages and libraries, such as the Cilk family, OpenMP, TBB, etc., do not have a notion of threads. Instead, these languages provide a processor-oblivious model of programming, where programs expose task-parallelism using high-level constructs such as spawn/sync without regard to the number of threads/cores available to run the program. Thread-based record-and-replay would violate the processor-oblivious nature of these programs, as they incorporate the number of threads into the recorded information, constraining the replayed execution to the same number of threads. In this paper, we present a processor-oblivious record-and-replay scheme for such languages where record and replay can use different number of processors and both are scheduled using work stealing. We provide theoretical guarantees for our record and replay scheme -- namely that record is optimal for programs with one lock and replay is near-optimal for all cases. In addition, we implemented this scheme in the Cilk Plus runtime system and our evaluation indicates that processor-obliviousness does not cause substantial overheads.
URLhttp://doi.acm.org/10.1145/3018743.3018764
DOI10.1145/3018743.3018764
Citation Keyutterback_processor-oblivious_2017