Closed and open nested atomic actions for Java

Abstract

We describe the design and prototype implementation of a dialect of Java, XJ, that supports both closed and open nested transactions. As we have previously advocated, open nesting most naturally attaches to the class as the primary abstraction mechanism of Java. The resulting design allows natural expression of layered abstractions for concurrent data structures, while promoting improved concurrency for operations on those abstractions. Moreover, we describe our approach to constructing a prototype implementation of XJ that runs on standard Java virtual machines, by grafting support for transactions onto both application code and library code via load-time bytecode rewriting, for full execution coverage. We rely on extensions to the javac compiler, a JVMTI run-time agent to intercept and rewrite Java classes as they are loaded into the virtual machine, and a run-time library that tracks and manages all transaction meta-data. The resulting prototype will allow further exploration of implementation alternatives for open and closed nested transactions in Java. Our design also addresses the issue of internal deadlock caused by accessing the same data in both closed and open nesting fashion by carefully disallowing such access.

Hybrid STM/HTM for nested transactions on OpenJDK

“…Our implementation extends that of Chapman et al [1], comprising four main components: (1) a compiler front-end based on OpenJDK's javac, (2) a minimally modified version of OpenJDK to support hardware transactional memory using TSX, (3) a Java agent for load-time bytecode rewriting to inject transaction support, and (4) a run-time library to manage the dynamics of transactions and abstract locking. Figure 1 shows how these components fit together.…”

“…However, the more abstract 1 transactions provided by open nesting-which offer increased concurrency because abstract concurrency control captures the essential semantic conflict while read/write level conflict detection over-estimates conflicts-must be built from something, and the individual operations must still appear to execute atomically. More precisely, they must be linearizable [13]: they must appear to occur at a single instant of time.…”

“…We build upon the work of Ni et al [23] and Chapman et al [1] to allow expression of closed nested, open nested, and boosted transactions in Java programs. The overall system is called XJ (for transactional Java), comprising language design, translation framework from syntax to bytecode, and run-time system.…”

“…The overall system is called XJ (for transactional Java), comprising language design, translation framework from syntax to bytecode, and run-time system. In this section, we reprise the language extensions of Chapman et al [1] and describe their current implementation, which differs from Chapman et al [1] in several key aspects.…”

“…Following Chapman et al [1] we allow users to construct rich abstract locking protocols. The locking framework relies on the notions of locks, lock spaces, lock shapes, and lock modes.…”