[aarch64-port-dev ] [8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure

[Liu, Xin]

Hi, Andrew, 

Not saying that the patch is incorrect. You are right. After JDK-8224671, it reveals the crash problem of Spring. 
After investigation, it turns out the root cause is JDK-8219006. I have added a label jdk8u-fix-request to it.
 
The patch is almost clean to apply https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot
Here is webrev:  https://bugs.openjdk.java.net/browse/JDK-8219006

Thanks,
--lx

On 6/1/19, 2:42 AM, "aarch64-port-dev on behalf of Andrew Haley" <aarch64-port-dev-bounces at openjdk.java.net on behalf of aph at redhat.com> wrote:

    
    > Subject:
    > [aarch64-port-dev ] [8u] RFR: 8224671: AArch64: mauve System.arraycopy test failure
    > From:
    > "Liu, Xin" <xxinliu at amazon.com>
    > Date:
    > 5/30/19, 6:56 PM
    > 
    > To:
    > Andrew John Hughes <gnu.andrew at redhat.com>, aarch64-port-dev <aarch64-port-dev-bounces at openjdk.java.net>
    > CC:
    > "Hohensee, Paul" <hohensee at amazon.com>
    > 
    > 
    > Hi, Andrew,
    > 
    > I’m confused.  Your commits is not completely same as your webrev.
    > https://hg.openjdk.java.net/aarch64-port/jdk8u-shenandoah/hotspot/rev/1bbf357c0164
    > https://cr.openjdk.java.net/~aph/8224671/jdk-test.changeset
    
    > I understand that there’s duplication for NAME, but the important part is the 2nd NAME.  It can catch the overloaded version of those instructions.
    
    Yes, that's what it's for. However, it causes a compile-time error if
    it is ever referenced: it's not needed otherwise. So, this part of the
    code is not necessary to fix the bug.
    
    > +                                                                        \
    > +  /* These instructions have no immediate form. Provide an overload so  \
    > +     that if anyone does try to use an immediate operand -- this has    \
    > +     happened! -- we'll get a compile-time error. */                    \
    > +  void NAME(Register Rd, Register Rn, unsigned imm,                     \
    > +            enum shift_kind kind = LSL, unsigned shift = 0) {           \
    > +    assert(false, " can't be used with immediate operand");             \
    > +  }
    > +
    > 
    > 
    > Further, I can’t pass two cases of spring on aarch64.  In my understanding, the culprit is very JDK- 8224671.
    > https://github.com/spring-projects/spring-framework
    > ```
    > $./gradlew :spring-context:test
    >> Task :spring-context:test
    > org.springframework.aop.framework.CglibProxyTests > testVarargsWithEnumArray FAILED
    > java.lang.ArrayIndexOutOfBoundsException at CglibProxyTests.java:393
    > org.springframework.aop.framework.JdkDynamicProxyTests > testVarargsWithEnumArray FAILED
    > java.lang.ArrayIndexOutOfBoundsException at JdkDynamicProxyTests.java:147
    > 3236 tests completed, 2 failed, 38 skipped
    >> Task :spring-context:test FAILED
    > ```
    
    > After I patch up JDK-8224671, I ran into crash. To cross verify, I
    > also built jdk8u-shenandoah slowdebug and put it into corretto-8. It
    > seems to have the same problem.  For more details, please refer to
    > hs_err_pid17831.log.
    
    > I am still wrestling gradle and spring to make a standalone
    > repro. Has you guy ever verified spring-framework?
    
    Not me personally.
    
    I'm pretty certain that the 8224671 patch is correct.  However, it is
    possible that fixing this bug revealed a bug elsewhere. We could back
    out the patch and investigate later: all that it seems to fix is
    reporting the wrong kind of exception.
    
    If you can't create a standalone reproducer, I will try to run the
    Spring tests.
    
    -- 
    Andrew Haley
    Java Platform Lead Engineer
    Red Hat UK Ltd. <https://www.redhat.com>
    https://keybase.io/andrewhaley
    EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671