[concurrency-interest] Intel's HLE and Java
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?
More information about the Concurrency-interest