VarHandles & LMAX Disruptor

[Doug Lea]

On 08/04/2015 05:25 PM, Michael Barker wrote:

> Thanks, I'll give that approach a try.  While it retains the padding on the
> array entries it is lost for entries.length, so while it won't share a
> cache line with the array entries it could share it with some other random
> unknown thing.  I still have to run some more tests to see what the actual
> costs end up being.  I suspect that I'll just suck up the cost of the
> bounds checking,

That's what I've ended up doing in similar cases in java.util.concurrent.
It does add variance depending on placement across runs of
programs as well as within runs when GC moves things. But not
much more variance than you see from other memory placement
effects and JVM noise.

It's worth reminding everyone that the need to do this
stems from compiler limitations that in principle could
be addressed someday. "Unsafe" access just means that
the compiler cannot prove that an address is legal.
It is frustrating that some cases that are obvious
to their programmers cannot be proven -- as in an array
that is only ever allocated with power-of-two size and
accessed with masked indexing, but the allocation is outside
the scope of compiler analysis.

High-quality bounds-check optimizations generally require
internal type systems and static analyses that are too
expensive for JITs. (See for example the work done in the
ahead-of-time X10 compiler.) But with the planned demise
of Unsafe, perhaps some people interested in optimization
will be more motivated to try to invent some more effective
JIT-friendly approximations.

-Doug