RFR 8136924 Vectorized support for array equals/compare/mismatch using Unsafe

[John Rose]

On Nov 25, 2015, at 3:21 AM, Peter Levart <peter.levart at gmail.com> wrote:
> 
> The mentioning of "reference component types" in javadoc for vectorizedMismatch:
> 
>  52     /**
>  53      * Find the relative index of the first mismatching pair of elements in two
>  54      * arrays of the same component type.   For reference component types the
>  55      * reference values (as opposed to what they reference) will be matched.
>  56      * Pairs of elements will be tested in order relative to given offsets into
>  57      * both arrays.
> 
> ... is probably a left-over, since there is no caller of the method using reference arrays (yet?). You should probably mention that doing so is not safe. As you might know, object pointers are a "movable target". GC can rewrite them as it moves objects around and if you "cast" an object pointer (or two of them) into a long value and store it in a long variable, GC can't track that and update the value, so you might be comparing an old address of an object with new address of the same object and get a mismatch.
> 
> I don't know much about intrinsified code. Whether it can be interrupted by GC or not, so it might be able to compare object references directly, but then the bytecode version of the method would have to have a special-case for reference arrays if it is executed in this form anytime.

Here's the scoop on reading references as ints or longs:  Just don't.

Calling Unsafe.getLong or Unsafe.getInt on a reference variable is never a good idea.
The reason is that the GC is allowed to run between the moment the reference is picked up
(as a bit image in a primitive value) and the moment something is done with it.  This is
rare but if it happens, it will cause the bit image to be stale, with unpredictable results.
Can the GC execute if the live interval of the bit image is very, very short?
Probably not if the code was compiled, but remember that the code might
sometimes be interpreted also, even after it is compiled.

In the case of array-mismatch, comparing a broken bit-image of a pointer
against another non-broken one might produce a false equality result.
Very, very rarely.  And won't that be a nice surprise for someone?

— John