JudoSTM: A Dynamic Binary-Rewriting Approach to Software Transactional Memory

Abstract

With the advent of chip-multiprocessors, we are faced with the challenge of parallelizing performance-critical software. Transactional memory (TM) has emerged as a promising programming model allowing programmers to focus on parallelism rather than maintaining correctness and avoiding deadlock. Many implementations of hardware, software, and hybrid support for TM have been proposed; of these, software-only implementations (STMs) are especially compelling since they can be used with current commodity hardware. However, in addition to higher overheads, many existing STM systems are limited to either managed languages or intrusive APIs. Furthermore, transactions in STMs cannot normally contain calls to unobservable code such as shared libraries or system calls.In this paper we present JudoSTM, a novel dynamic binary-rewriting approach to implementing STM that supports C and C++ code. Furthermore, by using value-based conflict detection, JudoSTM additionally supports the transactional execution of both (i) irreversible system calls and (ii) library functions that may contain locks. We significantly lower overhead through several novel optimizations that improve the quality of rewritten code and reduce the cost of conflict detection and buffering. We show that our approach performs comparably to Rochester's RSTM library-based implementation-demonstrating that a dynamic binary-rewriting approach to implementing STM is an interesting alternative.

Sandboxing transactional memory

“…In a POSIX-compliant C/C++ implementation, such faults are encoded as synchronous signals. Olszewski et al [24] suggest either containing inconsistent signals inside the operating system by making the kernel transaction-aware, or relying on userspace signal handling to suppress inconsistent signals once received. They implemented the first option; we will use the second (Section 3.2).…”

“…Previous systems have instrumented loop back edges with a check to force periodic validation [24,28]. This approach adds overhead that can be expensive for tighter loops, and pollutes hardware resources like branch predictors.…”

“…STM runtimes for managed languages like Java and C# [2,17], as well as systems based on dynamic binary instrumentation [24], validate transactions before they commit, leveraging type safe, just-in-time compilation, and managed exceptions to sandbox speculative transactions and protect the system from the effects of inconsistent execution.…”

Scalable Techniques for Transparent Privatization in Software Transactional Memory

“…Extensions that reduce metadata updates and cache pressure appear in Section III. In Section IV we contrast with approaches based on serialization of both transaction commit and cleanup [3], [9], [16]. We also present a hybrid approach that combines strict ordering and partial visibility to give reasonably good performance for a variety of workloads.…”

“…Working independently, Detlefs et al [3], Olszewski et al [9], and Spear et al [16] have developed STM systems which, while differing in many ways, all share a pair of design choices that together solve the delayed cleanup problem: (1) they buffer updates in a redo log; (2) they ensure that the commit and cleanup order of transactions is the same as their serialization order.…”