VarHandles & LMAX Disruptor

Brian Goetz brian.goetz at oracle.com
Sat Jul 25 18:34:56 UTC 2015


Thanks for this valuable data point!

We are very interested in whatever performance data you have.  Obviously
the theory is that VarHandles should be highly optimizable by the JIT --
ideally as fast as Unsafe -- but we are very interested in tracking the
differences between theory and practice.  (We've already found some JIT
performance bugs as a result of this effort, and there may be more --
and the earlier we can get the results, the more we can do with it.)

Also, it would be great if you could summarize the pitfalls you ran into
-- others might be able to benefit from that as well.

> - I think VarHandle.set/get should be called setRelaxed/getRelaxed as
> it> would make it more obvious to a user and a reader what those
> methods are> going to do.  My initial assumption was that they were
> no different from a> normal write/read of a field.

An alternative here is that get/set does whatever the default is for 
that field (so a volatile field would get ordered access) and 
{get,set}Relaxed would force a relaxed access (even for volatile fields.)

On 7/24/2015 10:29 PM, Michael Barker wrote:
> Hi,
>
> I've just ported the Disruptor across from Unsafe to VarHandles[0].
> Initially I ran into a whole bunch of issues, but after some time
> digging realised that they were all of my own making.  All of my unit
> tests pass and the performance tests I've run show very similar
> results.  I think there is a small slowdown (maybe a few %) with
> VarHandles, but my laptop has a high run to run variance so I can't
> really be sure until I do some testing on a more stable platform.
> Even if that is the case, that level is tolerable and I'll most
> likely release and use internally the VarHandles implementation when
> JDK9 is available.
>
> Excellent work, thanks to Paul Sandoz (and anyone else who worked on
> the implementation) and Alesky Shiplev for the sandbox instructions.
>
> Couple of notes:
>
> - The Disruptor is not a heavy (ab)user of the Unsafe - there's no
> off heap stuff there.  The use cases were primarily avoiding the
> additional costs of AtomicIntArray and AtomicLongFieldUpdater. - I'm
> a big fan of the style of the API where the use of a concurrent
> operation is visible at the call site.  I think this improves
> readability and makes it easier to reason about concurrent code.
> Having to jump to the type declaration to figure out if an assignment
> operation can affect the visibility/ordering of the code around it
> increases cognitive load. - I think VarHandle.set/get should be
> called setRelaxed/getRelaxed as it would make it more obvious to a
> user and a reader what those methods are going to do.  My initial
> assumption was that they were no different from a normal write/read
> of a field.
>
> Mike.
>
> [0] https://github.com/LMAX-Exchange/disruptor/tree/jdk9/
>


More information about the valhalla-dev mailing list