Evaluating HTM for pauseless garbage collectors in Java

Dave Dice
Senior Research Scientist
Evaluating HTM for pauseless garbage collectors in Java by Maria Carpen-Amarie, Dave Dice, Patrick Marlier, Gaël Thomas and Pascal Felber appeared in The 13th IEEE International Symposium on Parallel and Distributed Processing with Applications (IEEE ISPA-15).
While garbage collectors (GCs) significantly simplify programmers’ tasks by transparently handling memory management, they also introduce various overheads and sources of unpredictability. Most importantly, GCs typically block the application while reclaiming free memory, which makes them unfit for environments where responsiveness is crucial, such as real- time systems. There have been several approaches for developing concurrent GCs that can exploit the processing capabilities of multi-core architectures, but at the expense of a synchronization overhead between the application and the collector. In this paper, we investigate a novel approach to implementing pauseless moving garbage collection using hardware transactional memory (HTM). We describe the design of a moving GC algorithm that can operate concurrently with the application threads. We study the overheads resulting from using transactional barriers in the Java virtual machine (JVM) and discuss various optimizations. Our findings show that, while the cost of these barriers can be minimized by carefully restricting them to volatile accesses when executing within the interpreter, the actual performance degradation becomes unacceptably high with the just-in-time compiler. The results tend to indicate that current HTM mechanisms cannot be readily used to implement a pauseless GC in Java that can compete with state-of-the-art concurrent GCs.
See also:US9208081.

Join the discussion

Comments ( 1 )
  • Roman Kennke Tuesday, October 6, 2015

    Interesting paper! I think you made a mistake though. Read barriers are not only needed on volatile reads, but on all reads. You need to ensure you're reading newest values after sync-events, that includes preceding volatile ops and monitorenter/exit. Also, maybe more importantly, you need to ensure you're reading to-space values after a possibly dependent store (including write-barrier), otherwise you're reading inkonsistent values, even single-threaded. Unless your write-barrier somehow magically also updates all local vars? Regards, Roman

Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha

Integrated Cloud Applications & Platform Services