[concurrency-interest] Intel's HLE and Java

Andrew Haley aph at redhat.com
Wed Apr 25 07:35:25 EDT 2012

I've been thinking about what to do with Intel's Hardware Lock Elision
(HLE), if anything.

Briefly, HLE allows locked regions to proceed transactionally,
so something like Hashtable's

    public synchronized V put(K key, V value) {

could proceed in parallel with other cores accessing the same
Hashtable, as long as there were no conflict with the same hash slot.
If any unsafe instructions (interrupts, I/O, etc.) were executed or if
there were a conflict with another thread, the hardware would abort the
transaction (i.e. discard all pending memory updates and automagically
fall back to locking).  If there were no conflict, all threads would
proceed in parallel, and all accesses to the lock would be elided.

In theory this could be used for Java.  There is, as far as I can see,
one significant downside: if conflicts are highly probable, there will
be a performance degradation because speculation on transactions that
will abort wastes CPU cycles.

Also, I was worried that this might not actually respect the JMM
because on the x86, a StoreLoad barrier requires some sort of fence,
such as MFENCE.  However, according to the Intel documentation MFENCE
is allowed in a transaction and will not abort, so I think we're OK.

To handle the performance worry, a JIT could use some kind of cost
measure (length, number of memory accesses, etc.) to determine whether
to use HLE, on the assumption that short transactions are unlikely to
abort.  But this doesn't actually tell us what we need to know, which
is whether a conflict is likely.  Only the programmer knows that, and
even short transactions might abort if they are very frequent.

We could create a family of HLE-enabled locks and leave it all to the
programmer, but this seems like a lot of work and means that this
potentially very useful option will be wasted.  It also means a lot
of bloat in j.u.c.

Thoughts welcome...


Intel® Architecture Instruction Set Extensions Programming Reference

More information about the Concurrency-interest mailing list