Hybrid STM/HTM for nested transactions on OpenJDK

Abstract

Transactional memory (TM) has long been advocated as a promising pathway to more automated concurrency control for scaling concurrent programs running on parallel hardware. Software TM (STM) has the benefit of being able to run general transactional programs, but at the significant cost of overheads imposed to log memory accesses, mediate access conflicts, and maintain other transaction metadata. Recently, hardware manufacturers have begun to offer commodity hardware TM (HTM) support in their processors wherein the transaction metadata is maintained "for free" in hardware. However, HTM approaches are only best-effort: they cannot successfully run all transactional programs, whether because of hardware capacity issues (causing large transactions to fail), or compatibility restrictions on the processor instructions permitted within hardware transactions (causing transactions that execute those instructions to fail). In such cases, programs must include failure-handling code to attempt the computation by some other software means, since retrying the transaction would be futile. Thus, a canonical use of HTM is lock elision: replacing lock regions with transactions, retrying some number of times in the case of conflicts, but falling back to locking when HTM fails for other reasons. Here, we describe how software and hardware schemes can combine seamlessly into a hybrid system in support of transactional programs, allowing use of low-cost HTM when it works, but reverting to STM when it doesn't. We describe heuristics used to make this choice dynamically and automatically, but allowing the transition back to HTM opportunistically. Our implementation is for an extension of Java having syntax for both open and closed nested transactions, and boosting, running on the OpenJDK, with dynamic injection of STM mechanisms (into code variants used under STM) and HTM instructions (into code variants used under HTM). Both schemes are compatible to allow different threads to run concurrently with either mechanism, while preserving transaction safety. Using a standard synthetic benchmark we demonstrate that HTM offers significant acceleration of both closed and open nested transactions, while yielding parallel scaling up to the limits of the hardware, whereupon scaling in software continues but with the penalty to throughput imposed by software mechanisms.

A speculation‐friendly binary search tree

“…16 Such improvements rely on explicit calls or user-defined abstract locks that require genuine refactoring to work with HTM. 35 To make sure that the obtained results are not biased by the underlying TM algorithm, we evaluated the trees on top of ℰ -STM, 21 another TM library (on a 2 16 sized tree where ℰ -STM proved efficient), on top of a different TM design from the one used so far, ie, with eager acquirement, as well as on Intel's restricted HTM.…”

“…It fulfills the TM interface standardized by the industrials and academics, and thus does not require the presence of explicit escape mechanisms like early release or snap to avoid extra TM bookkeeping (our uread optimization being optional), nor does it require high‐level conflict detection, like open nesting and transactional boosting . Such improvements rely on explicit calls or user‐defined abstract locks that require genuine refactoring to work with HTM . To make sure that the obtained results are not biased by the underlying TM algorithm, we evaluated the trees on top of ‐STM, another TM library (on a 2 16 sized tree where ‐STM proved efficient), on top of a different TM design from the one used so far, ie, with eager acquirement, as well as on Intel's restricted HTM.…”

Extending OpenJDK to support hybrid STM/HTM: preliminary design

“…We have recently built and evaluated a research prototype system called XJ for execution of Java programs augmented with transactional memory abstractions (Chapman et al 2016). That system relies on somewhat heavyweight mechanisms to support transactional memory mechanisms on a mostly unmodified OpenJDK platform.…”