RFR: 8262295: C2: Out-of-Bounds Array Load from Clone Source [v3]

[Richard Reingruber]

On Tue, 23 Mar 2021 16:19:18 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> 
> 
> > > Looks good to me. Just wondering, is the load still hoisted if the source array is a constant array?
> > 
> > 
> > In the example below the load from clone in L6 was hoisted to SRC.
> > ```java
> >    1	    public static final Integer[] SRC = new Integer[4096];
> >    2	    public static void testMethod_dontinline() throws Exception {
> >    3	        Object[] clone = SRC.clone();
> >    4	        escape1 = new Object();
> >    5	        if (SRC.length > 4) {
> >    6	            escape2 = clone[4]; // Load L
> >    7	        }
> >    8	    }
> > ```
> > 
> > 
> > Actually the allocation + arraycopy in L3 could be eliminated if it wasn't for the possible deoptimization in L4 and the reference in L6. Would be cool to do the cloning lazily during deoptimization. But probably the gain isn't worth the effort/complexity.
> 
> EA already does that - for small arrays (EliminateAllocationArraySizeLimit = 64). The issue is size because we have to put all SRC's elements on stack for reallocation during deoptimization. Changing size `new Integer[16];` allows to eliminate new array allocation:
> 
> ```
> ======== Connection graph for  TestOutOfBoundsArrayLoad::testMethod
> JavaObject NoEscape(NoEscape) [ 87cp 314F [ 76 81 ]]   59  AllocateArray  ===  23  6  24  8  1 ( 57  36  31  42  1  21 ) [[ 60  61  62  74  75  76 ]]  rawptr:NotNull ( int:>=0, java/lang/Object:NotNull *, bool, int ) TestOutOfBoundsArrayLoad::testMethod @ bci:3 (line 98) reexecute !jvms: TestOutOfBoundsArrayLoad::testMethod @ bci:3 (line 98)
> LocalVar [ 59P [ 81 ]]   76  Proj  ===  59  [[ 77  81 ]] #5 !jvms: TestOutOfBoundsArrayLoad::testMethod @ bci:3 (line 98)
> LocalVar [ 76 87cp 59P [ 314b ]]   81  CheckCastPP  ===  78  76  [[ 87  314  314  100 ]]  #narrowoop: java/lang/Integer:exact *[int:16]:NotNull:exact * !jvms: TestOutOfBoundsArrayLoad::testMethod @ bci:3 (line 98)
> ```

Yes, EA does it for small arrays.

I though it could be done for large ones too. What I meant was doing the allocation and then the arraycopy too on deoptimization but my thinking was a little naive of course :) as the src array might get modified before.

Sorry for that and thanks for pointing out that EA can do that for smaller arrays.

-------------

PR: https://git.openjdk.java.net/jdk/pull/2708