VarHandles & LMAX Disruptor

[Michael Barker]

Hi,

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.)
>

No problem, I'll dig into some of the assembly on the hot paths too.

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


The main difficulty was figuring out which classes to use in the
MethodHandles.lookup.  The main concurrent class (Sequence [0]) has some
slightly funky inheritance in order to support cache line padding, so the
actual field that gets modified is not in the Sequence class, but in the
superclass.  Just using the class that passed as the first argument seemed
to work fine.

[0]
https://github.com/LMAX-Exchange/disruptor/blob/jdk9/src/main/java/com/lmax/disruptor/Sequence.java

 - 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.)


That would make sense, however it would preclude the ability to apply a
normal load/store to volatile field.  Given that a load/stores to volatile
fields can have weaker ordering semantics of relaxed or acquire/release via
a VarHandle, why not support normal load/stores?  It would bring a level of
completeness to the API.  Or the API could support a setNormal/getNormal.

A small comment on the naming.  I'm wondering why the name VarHandle?  It
feels like FieldHandle would be a better name.  VarHandle suggests that it
would be able to apply it to stack variable, parameters etc?

Mike.