VarHandles & LMAX Disruptor

[Michael Barker]

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