We have recently described and evaluated a research prototype system (called XJ, for transactional Java) that allows execution of Java programs extended with transactional memory (TM) abstractions (Chapman et al. 2014, 2016). The system allows mixed execution of these abstractions using both software (STM) and hardware (HTM) transactional memory. The prototype system, based on OpenJDK, suffers a number of roadblocks impeding production use, including: (i) Per-object metadata in support of manipulation of objects by transactions is inserted via bytecode rewriting at load time, in the form of a new word-sized instance field placed at the beginning of each object; (ii) The HotSpot optimizing compilers (C1 and C2) require gentle coaxing to compile both the STM and HTM versions of methods via alternating execution in a warm-up phase. Here we explore possible changes to OpenJDK that would allow for more integrated support for TM in HotSpot, as needed to support hybrid STM/HTM. These changes include encoding per-object transactional metadata in the synchronization word carried by all OpenJDK objects, and integrating more effectively with the profiling and compilation mechanisms of the HotSpot interpreter and compilers. We believe that the proposed changes are incremental, though we also expect that a deeper re-engineering would yield somewhat better ability to tune synchronization hot-paths for performance.
Mon 31 OctDisplayed time zone: Amsterdam, Berlin, Bern, Rome, Stockholm, Vienna change
08:30 - 10:00
Tony Hosking Australian National University, Data61, and Purdue University
|Keynote: The good, the good enough, and some things we wish we had done differently: runtime design lessons from a production JVM|
K: Mark Stoodley IBM CanadaLink to publication Media Attached
|Extending OpenJDK To Support Hybrid STM/HTM|
Keith Chapman Purdue University, Tony Hosking Australian National University, Data61, and Purdue University, Eliot Moss University of Massachusetts AmherstDOI Pre-print Media Attached