VarHandles & LMAX Disruptor

[Michael Barker]

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/