Unsafe for array access

John Rose john.r.rose at oracle.com
Tue May 6 18:38:48 UTC 2014


Paul, this is a reasonable request.  Please file a P3 bug against the hotspot compiler.

Our iteration range splitting transform is gated by a pattern match on a loop body (after inlining).  One of the pattern conditions is that there is an array reference (incl. range check) in the body of the loop.  (Not surprising.)

1. The user-written code should be an alias for a JVM-issued range check.  (The signed/unsigned identities are tricky, and some parts are probably broken.)

2. We should extend our pattern match to allow code like yours to trigger range splitting.

I don't think the above points require deep cuts.

Some background is here:  https://wiki.openjdk.java.net/display/HotSpot/RangeCheckElimination

— John

On May 5, 2014, at 8:20 AM, Paul Sandoz <paul.sandoz at oracle.com> wrote:

> Hi,
> 
> As part of some investigatory work for JEP 193: Enhanced Volatiles i have been looking at how enhanced (and safe) access to array elements could be implemented.
> 
> The obvious and simple choice is to reach for unsafe with a few safety checks, for example:
> 
>    @ForceInline
>    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
>            Object value) {
>        if (index < 0 || index >= array.length) // bounds and null check
>            throw new ArrayIndexOutOfBoundsException();
>        UNSAFE.putObjectVolatile(array,
>                                 (((long) index) << handle.ashift) + handle.abase,
>                                 castReference(handle.componentType, value));
>    }
> 
> The problem is the compiler does fully recognize an array access is going on and so certain optimizations tend not to kick in, such as removing or strength reducing bounds checks, or treating "index" as a signed value rather than unsigned.
> 
> Any clues/pointers on how i can hack things so that hotspot knows that an array access is going on in the above code, and views it as almost equivalent to following in terms of optimizations?
> 
>    @ForceInline
>    static void setVolatile(ArrayRefHandle handle, Object[] array, int index,
>            Object value) {
>        if (index < 0 || index >= array.length) // bounds and null check
>            throw new ArrayIndexOutOfBoundsException();
>        array[i] = castReference(handle.componentType, value);
>    }
> 
> 
> Some context: ForkJoinPool is peppered with code like the following:
> 
>                            int i = (((a.length - 1) & b) << ASHIFT) + ABASE;
>                            ForkJoinTask<?> t =
>                                (ForkJoinTask<?>)U.getObjectVolatile(a, i);
> 
> Any viable replacement for direct Unsafe usages in that code will want those strength reducing optimizations to kick in.
> 
> Paul.



More information about the hotspot-compiler-dev mailing list