VarHandles & LMAX Disruptor

[Vitaly Davidovich]

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


If Vladimir Ivanov's research into constant folding finals works out, then
presumably at JIT time compiler can look at the values of array.length and
the mask and handle the 2^n cases, assuming both the array and mask are
final (not always the case, but would cover a good number of use cases).
However, there will always be things the compiler cannot/doesn't do, and in
those cases it's nice to have things like Unsafe to fall back on.


On Wed, Aug 5, 2015 at 10:12 AM, 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
>
>
>