On Nov 25, 2015, at 3:21 AM, Peter Levart <peter.lev...@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
