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

[Vladimir Kozlov]

What if you have a second arraycopy after 0x42 store which also modify 
src[1]?

You did not explain changes in memnode.cpp

I would like to fix it first in JDK 10 and let it be tested before we 
backport into previous releases.

Thanks,
Vladimir

On 6/13/17 2:23 AM, Roland Westrelin wrote:
> 
> http://cr.openjdk.java.net/~roland/8182036/webrev.00/
> 
> 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.
> 
> Roland.
>