[10] RFR(S): 8182036: Load from initializing arraycopy uses wrong memory state

Roland Westrelin rwestrel at redhat.com
Tue Jun 13 09:23:41 UTC 2017


static int test1() {
    int[] src = new int[10];
    test_dummy = src;
    int[] dst = new int[10];
    src[1] = 0x42;
    System.arraycopy(src, 1, dst, 1, 9);
    return dst[1];

Initialization of dst is performed by the
arraycopy. PhaseMacroExpand::generate_block_arraycopy() generates a
load/store pair to copy the element at offset 1 so it can bulk copy the
elements starting at offset 2. Both the load and store are on the same
slice which for an initializing arraycopy is raw memory. So the src[1]
load and the src[1] = 0x42 store are not on the same slice and the load
can happen before the store resulting in an incorrect execution.

The fix I propose is for the load to be from the src's slice.

This affects 8 (where it always fail), 9 and 10 (where it fails once in
a few iterations when run with StressGCM/StressLCM). I haven't checked
older releases. As I understand, as this affects 8, it's too late for a
fix in 9 but I suppose we'll want it backported.

When the source and destination address types differ, the code used to
fallback to raw memory as the memory slice used in the arraycopy code. I
think it should use the destination's address type: all stores are to
that slice and the only load that I can be generated now has the correct
memory address type.


More information about the hotspot-compiler-dev mailing list