[concurrency-interest] Experimental Transactional Lock Elision with Hotspot

Stephan Diestelhorst stephan.diestelhorst at gmail.com
Sun Aug 4 18:16:34 EDT 2013

Dear all,
  I have worked on a few changes to the JDK7 Hotspot JVM that are a
first start for eliding Java's monitors with an HTM (AMD's Advanced
Synchronization Facility [1]).  The code is pretty much a proof of
concept right now and does not contain any tuning etc.  Sadly, I also
have not found the time (yet) to do a full characterisation.

Please find this on top of the latest JDK7 code here:


I hope this is interesting to the wider parallel and transactional
communities, as it highlights the points where elision should come into
play.  I have modified both the fast- and slow-path logic, and
(hopefully) squeezed out all the code paths where the locks check their
own value (which under transactional elision is still FREE).

Another interesting take-away is the amazing (crazy?) locking on 32 bit
x86, where the fast-path code changes the lock from FREE -> TAKEN1, and
then slow-path logic changes that from TAKEN1 -> TAKEN2, whith TAKEN1 a
more easily available value in fast-path assembly and TAKEN2 a more
useful value for later inspection.

In any case, if you are brave enough, this *should* work with my newly
ported ASF simulator [2].

If this is useful, feel free to send me a postcard and / or please cite
our ASF-related papers.


Disclaimer: Not a product, and not supported / endorsed by any company.

[1] http://developer.amd.com/assets/45432-ASF_Spec_2.1.pdf
    Dave Christie, Jae-Woong Chung, Stephan Diestelhorst, Michael
    Hohmuth, Martin Pohlack, Christof Fetzer, Martin Nowack, Torvald
    Riegel, Pascal Felber, Patrick Marlier, Etienne Riviere: Evaluation
    of AMD's advanced synchronization facility within a complete
    transactional memory stack. EuroSys 2010: 27-40

[2] https://bitbucket.org/stephand/marss86-asf/commits/branch/asf_ptlsim_merge

More information about the Concurrency-interest mailing list