VarHandles & LMAX Disruptor

[Vitaly Davidovich]

>
> Therefore even I use separate field to store the indexMask (entries.length
> - 1) to avoid false sharing, the bounds check will effectively undo that
> effort?


Yes, anything that touches array.length can induce false sharing -- I
mentioned this earlier in this thread :) :

I think any approach that requires reading the length of an array, whether
> user or compiler inserted, is going to run afoul of possible false sharing;
> only approach #3 would work since the mask field could be isolated to its
> own cacheline.

The approach #3 you mentioned in the initial email could work *iff* JIT
started const propagating final fields and then seeing that your mask
guarantees an index < array.length *and* constant propagating the final
field holding the array and knowing its length > 0 (assuming we're talking
about a class with a final field array, which is true for typical
ringbuffers).  Right now, only Unsafe can help avoiding range checks and
false sharing.

On Fri, Aug 7, 2015 at 4:41 PM, Michael Barker <mikeb01 at gmail.com> wrote:

> Hi Doug,
>
> Thank you for that info. I've just realised something but want to check my
> reasoning.  The bounds check is effectively doing:
>
> if (index >= entries.length)
>     throw ArrayOutOfBoundsException();
>
> Therefore even I use separate field to store the indexMask (entries.length
> - 1) to avoid false sharing, the bounds check will effectively undo that
> effort?
>
> Mike.
>
>
> On 6 August 2015 at 02:12, Doug Lea <dl at cs.oswego.edu> wrote:
>
> > 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
> >
> >
> >
>