VarHandles & LMAX Disruptor

[Paul Sandoz]

On 27 Jul 2015, at 23:35, Michael Barker <mikeb01 at gmail.com> wrote:

> I believe code in RingBuffer was using Unsafe to avoid bounds checks, correct? if so I wonder if the patch in https://bugs.openjdk.java.net/browse/JDK-8003585 would help with strength reducing such checks? I don’t know if that patch also works with a constant offset as used in RingBufferFields, but it should work for MultiProducerSequencer. The patch should apply cleanly to the VarHandles branch in the sandbox if you want to try it out.
> 
> Sounds interesting, I'll have a look.  Bounds checks weren't at the top of the list for using the Unsafe.  We had already started using it for other reasons and made use of that particular optimisation because we could.
> 
> A little bit of history around the Disruptor and Unsafe, the main reason I started using Unsafe wasn't to do with performance, but "observed" stability.  I found on some JVMs APIs like AtomicIntFieldUpdater were less stable on some JVMs than Unsafe.  For example on one JVM the JIT didn't treat accesses through a field updater as volatile and would apply optimisations like hoisting from loops which would broke the code.  The 10% to 20% performance boost was a nice side benefit.
> 

Thanks, that is interesting, and somewhat ironic :-)


> My personal speculation is that most Java licensees reuse the java.util.concurrent library code and provide a decent implementation of Unsafe to make it work, rather than port to their own set of JVM intrinsics.  Because of this Unsafe seems to work pretty well on most JVMs.  I'm hopeful that java.util.concurrent will be ported across to VarHandles too as it will encourage JVM vendors to have an efficient and stable implementation of VarHandles.
> 
> Ideally what you also need is a public equivalent of @Contended that also supports arrays, that would make the code a little cleaner, but would be a separate project :-)
> 
> That would be nice.  One of the other things that is lost with removing the Unsafe is getting the array padding at the ends of array correct.  The stuff that I removed used the Unsafe to determine the size of the object reference, which was used to calculate the number of entries required to pad the real data.  Now I just pick a value and hope.
> 

There are stuff like Unsafe.addressSize/pageSize/unalignedAccess/isBigEndian that could be exposed in a public API (the later already is in ByteOrder but that can be somewhat obscure, there might be some other ways in JMX, i have not checked but IMO that is too heavy for getting such constant information). java.lang.Runtime seems a reasonable dumping ground.

Paul.