[aarch64-port-dev ] RFR(S): 8228601: AArch64: Fix interpreter code at JVMCI deoptimization entry

[Pengfei Li (Arm Technology China)]

Hi,

Please help review this AArch64 bug fix.
JBS: https://bugs.openjdk.java.net/browse/JDK-8228601
Webrev: http://cr.openjdk.java.net/~pli/rfr/8228601/webrev.00/

AArch64 HotSpot crashes when a Graal-compiled Java synchronized method is deoptimized and then re-executed in the interpreter. This issue can be reproduced by below Java program with VM options "-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+UseJVMCICompiler -Djvmci.Compiler=graal".

public class Test {
  public static synchronized int hash(Object o) { return o.hashCode(); }
  public static void main(String[] args) throws Exception {
    int sum = 0;
    for (int i = 0; i < 30000; i++) {
      sum += hash(i);
      Thread.sleep(1);
    }
    sum += hash("Shanghai");
    System.out.println(sum);
  }
}

When a JVMCI-compiled Java synchronized method gets deoptimized for some reasons, HotSpot sets the thread local _pending_monitorenter flag in the deoptimization routine.[1] Then in the interpreter mode, the method is locked at the deoptimization entry before being re-executed if this flag is set.[2] But in current AArch64 HotSpot, the generated interpreter code which checks the _pending_monitorenter flag is wrong. It causes synchronized method not being correctly locked. When the method returns in interpreter, HotSpot crashes because it's trying to unlock an invalid lock.

This patch fixes the condition for locking a Java method in interpreter. Below JTreg test failures with AArch64 Graal also get fixed after this patch.
* jdk/java/util/Map/InPlaceOpsCollisions.java
* jdk/sun/security/tools/keytool/KeyToolTest.java
* hotspot/jtreg/serviceability/sa/TestHeapDumpForInvokeDynamic.java

[1] http://hg.openjdk.java.net/jdk/jdk/file/6073b2290c0a/src/hotspot/share/runtime/deoptimization.cpp#l1683
[2] http://hg.openjdk.java.net/jdk/jdk/file/6073b2290c0a/src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp#l522

--
Thanks,
Pengfei