[concurrency-interest] Intel's HLE and Java

Andrew Haley aph at redhat.com
Thu Apr 26 05:50:11 EDT 2012


On 04/25/2012 08:27 PM, Nathan Reynolds wrote:
> TSX seems like another type of lock to be added to the current 
> bias/thin/fat synchronized design.
> 
> I guess RTM could fit somewhere between thin and fat (experience and 
> performance data will tell).  If the thin lock is too contented (i.e. 
> too much spinning), then the JVM will switch the lock to an RTM lock.  
> If too many aborts happen per transaction, then the JVM will switch to 
> fat.  Or maybe RTM locks would be tried first and then switch to thin locks.

I was thinking more of the latter; it could reduce the pinging of
cache lines between caches in a NUMA system, for example, in cases
where transactions can run in parallel.

> HLE seems like it could be added to thin locks.  If the transaction 
> fails, then the thread will have to execute CAS instruction to acquire 
> the lock.  If the CAS fails too many times per transaction, then we know 
> that HLE won't work here and the lock will be changed to a regular thin 
> lock.  If threads timeout while spinning, then the lock will be 
> converted to a fat lock.

That sounds like thee sort of thing that I was thinking of.

> It doesn't seem like we need both RTM and HLE.  It seems like one or the 
> other will be better.  HLE has the advantage of providing transactions 
> in all cases but at the cost of failed transactions (hence performance 
> loss).  RTM is very explicit and gives power to the JVM to decide if 
> transactions are working.

OK.  I'll kick this around a bit.  Do you know of any suitable
benchmark suite that I could use?

Andrew.


More information about the Concurrency-interest mailing list