Unbounded Transactional Memory

Abstract

Hardware transactional memory should support unbounded transactions: transactions of arbitrary size and duration. We describe a hardware implementation of unbounded transactional memory, called UTM, which exploits the common case for performance without sacrificing correctness on transactions whose footprint can be nearly as large as virtual memory. We performed a cycleaccurate simulation of a simplified architecture, called LTM. LTM is based on UTM but is easier to implement, because it does not change the memory subsystem outside of the processor. LTM allows nearly unbounded transactions, whose footprint is limited only by physical memory size and whose duration by the length of a timeslice. We assess UTM and LTM through microbenchmarking and by automatically converting the SPECjvm98 Java benchmarks and the Linux 2.4.19 kernel to use transactions instead of locks. We use both cycle-accurate simulation and instrumentation to understand benchmark behavior. Our studies show that the common case is small transactions that commit, even when contention is high, but that some applications contain very large transactions. For example, although 99.9% of transactions in the Linux study touch 54 cache lines or fewer, some transactions touch over 8000 cache lines. Our studies also indicate that hardware support is required, because some applications spend over half their time in critical regions. Finally, they suggest that hardware support for transactions can make Java programs run faster than when run using locks and can increase the concurrency of the Linux kernel by as much as a factor of 4 with no additional programming work.

Distributed speculative execution for reliability and fault tolerance: an operational semantics

“…Most of them set a limit on the size of the operations inside each transaction. Ananian et al [1] introduce an architecture for supporting unbounded transactional memory. Their approach addresses the issue of having transactions that are larger than the CPU cache, for which they devise special mechanisms to enable rollback.…”

“…It also illustrates how the speculative programming model simplifies the program by eliminating the recovery code and highlights the computation, as compared to the traditional approach. It is important to mention that, unlike 1 Atomic transfer of the amount sum from account Acc1 to Acc2 software transactional memory, speculations do not try to replace existing synchronization mechanisms. For example, each account accessed by the transfer function can be protected by a global lock to serialize concurrent accesses to it.…”

“…1 The reduction trace of a distributed system is defined as the sequence of distributed system states given by the reduction rules that are applied during the execution of the programs. The states need not be distinct.…”

Formal Reasoning About Lazy-STM Programs

“…There have been several proposals for hardware-based (HTM) [1][2][3][4] , software-based (STM) [5][6][7][8][9][10] and hybrid [11] TM implementations. But these TM systems mainly focus on the performance issues and suggest different tradeoffs in the mechanisms used to track transactional state, buffer size, and the overheads associated with basic operations.…”

Hardware Transactional Memory Supporting I/O Operations within Transactions

“…size of a transaction); also the architecture of processors is needed to be modified. Current HTMs include TCC [2] , UTM/LTM [3] , LogTM [5] , etc. Compared to HTM, STM supports atomicity of transactions by software, and achieves benefits such as flexibility of transactions and various enhanced functions; moreover, STM can be implemented on current processors without hardware modifications.…”