Compiler and runtime support for efficient software transactional memory

Abstract

Programmers have traditionally used locks to synchronize concurrent access to shared data. Lock-based synchronization, however, has well-known pitfalls: using locks for fine-grain synchronization and composing code that already uses locks are both difficult and prone to deadlock. Transactional memory provides an alternate concurrency control mechanism that avoids these pitfalls and significantly eases concurrent programming. Transactional memory language constructs have recently been proposed as extensions to existing languages or included in new concurrent language specifications, opening the door for new compiler optimizations that target the overheads of transactional memory. This paper presents compiler and runtime optimizations for transactional memory language constructs. We present a highperformance software transactional memory system (STM) integrated into a managed runtime environment. Our system efficiently implements nested transactions that support both composition of transactions and partial roll back. Our JIT compiler is the first to optimize the overheads of STM, and we show novel techniques for enabling JIT optimizations on STM operations. We measure the performance of our optimizations on a 16-way SMP running multi-threaded transactional workloads. Our results show that these techniques enable transactional memory's performance to compete with that of well-tuned synchronization.

STAMP: Stanford Transactional Applications for Multi-Processing

“…Moreover, the only difference among the STM and hybrid versions of the code is linkage against a different TM barrier library. Manual optimizations of read and write barriers for accesses to shared data were performed following the guidelines in [1,18]. Currently, the TM annotations are implemented by C macros, which makes them easy to replace, remove, or port to different systems.…”

Unlocking Concurrency

“…It plots the time it takes to complete a fixed set of insert, delete, and update operations on a 16-way SMP (symmetric multiprocessing) machine. 4 As the numbers show, the performance of coarse-grained locking does not improve as the number of processors increases, so coarse-grained locking does not scale. The performance of fine-grained locking and transactional memory, however, improves as the number of processors increases.…”

McRT-STM

“…For managed environments such as Java, object based conflict detection can be implemented easily [1]. For unmanaged environments such as C, this is more difficult since we need to map an arbitrary interior pointer to the object base.…”

“…With transactions, the programmer marks the regions or operations that should execute atomically; the compiler and runtime system take care of the implementation. There are several proposals related to linguistic constructs for supporting transactional memory [1][4] [9]. This paper concentrates on the underlying runtime primitives and the interface needed to support the various semantics for transactional memory.…”

“…Runtime transactional memory primitives can be provided either by hardware [16] [25][19] [9] (HTM) or by software [1] [9][14] [17] (STM) with both approaches having their pros and cons. An HTM provides a significant performance advantage, and enforces atomicity not only between transactional memory accesses, but also between transactional and non-transactional memory accesses.…”