VarHandles & LMAX Disruptor

[Brian Goetz]

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/
>