Supporting nested transactional memory in logTM

Abstract

Nested transactional memory (TM) facilitates software composition by letting one module invoke another without either knowing whether the other uses transactions. Closed nested transactions extend isolation of an inner transaction until the toplevel transaction commits. Implementations may flatten nested transactions into the top-level one, resulting in a complete abort on conflict, or allow partial abort of inner transactions. Open nested transactions allow a committing inner transaction to immediately release isolation, which increases parallelism and expressiveness at the cost of both software and hardware complexity. This paper extends the recently-proposed flat Log-based Transactional Memory (LogTM) with nested transactions. Flat LogTM saves pre-transaction values in a log, detects conflicts with read (R) and write (W) bits per cache block, and, on abort, invokes a software handler to unroll the log. Nested LogTM supports nesting by segmenting the log into a stack of activation records and modestly replicating R/W bits. To facilitate composition with nontransactional code, such as language runtime and operating system services, we propose escape actions that allow trusted code to run outside the confines of the transactional memory system.

Understanding transactional memory performance

“…While most memory allocators are mostly implemented at user level, they sometimes need to make system calls to get more memory from the OS (either mmap or sbrk), and they might make other system calls. This problem is well known [37,39], and there are several ways to allow system calls within transactions, including open nesting [21,22] and transactional pause [37,39].…”

Adaptive locks: Combining transactions and locks for efficient concurrency

“…An important trend is to provide hardware support for TM [50][51][52][53][54][55][56][57][58][59][60][61]. With hardware support, the performance trade-offs change-e.g., the transactional overhead of loads and stores may be virtually eliminated.…”

Transactional memory

“…In such systems an abort of an inner transaction may cause a complete abort to the beginning of the outermost transaction, which may result in low performance. A partial abort of only the inner transaction may result in higher performance by avoiding the abortion of the, possibly longer, outermost transaction [71].…”

“…This will potentially result in higher parallelism and expressiveness [71]. However, there is also a higher cost in terms of more complex hardware and software.…”

“…The basic LogTM proposal is extended in [71] to support nested transactions. First, the flat closed nesting of transactions in the basic LogTM is extended to support partial aborts in closed nesting allowing inner transactions to abort without aborting the outer transactions.…”