JDK-8214093 : [Graal] jck:vm/jvmti/ForceEarlyReturn tests intermittently and randomly fail with Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 12
  • Priority: P2
  • Status: Closed
  • Resolution: Duplicate
  • Submitted: 2018-11-20
  • Updated: 2024-01-29
  • Resolved: 2018-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 12
12Resolved
Related Reports
Relates :  
JDK-8218025 - disable pop_frame and force_early_return caps for Graal
Relates :  
JDK-8207013 - [Graal] vmTestbase/nsk/jvmti/PopFrame tests fail with Graal
Description
Running jck:vm/jvmti/ForceEarlyReturn* tests in Graal as JIT mode intermittently and randomly fail.
Here the list of tests which failed with latest jdk12 bits:
 vm/jvmti/ForceEarlyReturnVoid/ferv001/ferv00102/ferv00102.html
  Uncaught exception while adjusting compilation level: java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5

 vm/jvmti/ForceEarlyReturnInt/feri001/feri00104/feri00104.html
  Trying to acquire a lock on 'testLock' object ... Uncaught exception while adjusting compilation level: java.lang.NullPointerException

 vm/jvmti/ForceEarlyReturnInt/feri001/feri00103/feri00103.html
  Uncaught exception while adjusting compilation level: java.lang.NullPointerException

 vm/jvmti/ForceEarlyReturnDouble/ferd001/ferd00105/ferd00105.html
  Uncaught exception while adjusting compilation level: java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5

The issue is not new and is seen in previous builds.

The issue Graal specific. No issue if Graal is not used.

A little bit more detailed output is:
Uncaught exception while adjusting compilation level: java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5
java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5
	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@12-internal/HotSpotJVMCIRuntime.java:503)
	at javasoft.sqe.tests.vm.jvmti.ferd001.ferd00105.TestThread.testedMethod(ferd00105.java:133)
	at javasoft.sqe.tests.vm.jvmti.ferd001.ferd00105.TestThread.run(ferd00105.java:152)
Unexpected returned value after ForceEarlyReturnDouble() successful call:
	retValue=1.0
	lockReleased=false
. . .

Uncaught exception while adjusting compilation level: java.lang.NullPointerException
java.lang.NullPointerException
	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@12-internal/HotSpotJVMCIRuntime.java:503)
	at javasoft.sqe.tests.vm.jvmti.feri001.feri00103.TestThread.testedMethod(feri00103.java:128)
	at javasoft.sqe.tests.vm.jvmti.feri001.feri00103.TestThread.run(feri00103.java:147)
Trying to acquire a lock ... acquired.
Unexpected returned value after ForceEarlyReturnInt() successful call: 1
. . .

Trying to acquire a lock on 'testLock' object ... Uncaught exception while adjusting compilation level: java.lang.NullPointerException
java.lang.NullPointerException
	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@12-internal/HotSpotJVMCIRuntime.java:503)
	at javasoft.sqe.tests.vm.jvmti.feri001.feri00104.TestThread.testedMethod(feri00104.java:131)
	at javasoft.sqe.tests.vm.jvmti.feri001.feri00104.TestThread.run(feri00104.java:151)
lock acquired.
Unexpected returned value after ForceEarlyReturnInt() successful call: 1
. . .

Uncaught exception while adjusting compilation level: java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5
java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5
	at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@12-internal/HotSpotJVMCIRuntime.java:503)
	at javasoft.sqe.tests.vm.jvmti.ferv001.ferv00102.TestThread.testedMethod(ferv00102.java:134)
	at javasoft.sqe.tests.vm.jvmti.ferv001.ferv00102.TestThread.run(ferv00102.java:156)
Unexpected returned value after successful ForceEarlyReturnVoid() call:
	 thread.a: 2
	thread.b: 2
. . .

So that, it is failing in the JIT compiler function:
  jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel()
Comments
Closing this issue as a dup of JDK-8195635. Also, I've added the tck-red label to JDK-8195635.
07-12-2018
There are two problems here. One is on the VM side that will be fixed as a part of JDK-8195635. Another problem is on the test side. These JCK tests need to be changed to ensure that the test thread is suspended at a right place where the top frame executes the test method rather than JVMCI code triggered by invocation counter overflow. Otherwise, calling JVMTI ForceEarlyReturnXXX makes early return for a wrong method. The new issue JCK-7311061 is created to cover JCK test changes.
03-12-2018
I agree with Dean. It looks as a duplicate of JDK-8195635. When the tests suspend the tested thread the top frame belongs to the test but when after that the tests do early return the top-frame is a JVMCI frame.
27-11-2018
Sometimes the same tests fail with different errors e.g.: "Trying to acquire a lock ... acquired. (ForceEarlyReturnVoid) Unexpected error: JVMTI_ERROR_TYPE_MISMATCH result: Failed. test failed" http://java.se.oracle.com:10060/api/v1/results/loc0IkB3r-4/log or do crash with "assert(false) failed: compilation level out of bounds" ( the same as JDK-8195635) http://java.se.oracle.com:10060/api/v1/results/datitov-jdk-hs-20181127-0134-11743-jck_vm_jvmti_ForceEarlyReturnVoid-linux-x64-debug-91-2/log
27-11-2018
I was able to reproduce the issue with mach5 build: http://java.se.oracle.com:10065/mdash/jobs/datitov-jdk-hs-20181127-0134-11743?search=result.status:EXECUTED_WITH_FAILURE The suggested fix http://cr.openjdk.java.net/~amenkov/popframe009/webrev.01/ from JDK-8195639 doesn't help. The same exceptions still cause some tests to fail: Uncaught exception while adjusting compilation level: java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5 java.lang.ArrayIndexOutOfBoundsException: Index -263862456 out of bounds for length 5 at jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel(jdk.internal.vm.ci@12-internal/HotSpotJVMCIRuntime.java:503) at javasoft.sqe.tests.vm.jvmti.ferv001.ferv00102.TestThread.testedMethod(ferv00102.java:134) at javasoft.sqe.tests.vm.jvmti.ferv001.ferv00102.TestThread.run(ferv00102.java:156) Unexpected returned value after successful ForceEarlyReturnVoid() call: thread.a: 2 thread.b: 2 result: Failed. test failed http://java.se.oracle.com:10060/api/v1/results/datitov-jdk-hs-20181127-0307-11757-jck_vm_jvmti_ForceEarlyReturnVoid-linux-x64-debug-35-2/log http://java.se.oracle.com:10065/mdash/jobs/datitov-jdk-hs-20181127-0307-11757?search=result.status%3AEXECUTED_WITH_FAILURE
27-11-2018
All four tests are failed in the JVMCI function: jdk.vm.ci.hotspot.HotSpotJVMCIRuntime.adjustCompilationLevel() The message "Uncaught exception while adjusting compilation level" is printed in the function JVMCIRuntime::adjust_comp_level_inner(). The JVMCIRuntime::adjust_comp_level_inner() is called from the JVMCIRuntime::adjust_comp_level(). The JVMCIRuntime::adjust_comp_level() is called in the contexts: TieredThresholdPolicy::event => TieredThresholdPolicy::method_invocation_event => TieredThresholdPolicy::call_event() TieredThresholdPolicy::event => TieredThresholdPolicy::method_back_branch_event => TieredThresholdPolicy::loop_event() So that, I think, there is a big chance that the following patch from Alex for JDK-8195639 is going to fix this issue as well: @@ -379,12 +379,11 @@ } } nmethod* TieredThresholdPolicy::event(const methodHandle& method, const methodHandle& inlinee, int branch_bci, int bci, CompLevel comp_level, CompiledMethod* nm, JavaThread* thread) { - if (comp_level == CompLevel_none && - JvmtiExport::can_post_interpreter_events() && + if (JvmtiExport::can_post_interpreter_events() && thread->is_interp_only_mode()) { return NULL; } if (CompileTheWorld || ReplayCompiles) { // Don't trigger other compiles in testing mode This issue is most likely a dup of JDK-8195639.
26-11-2018
There is some probability, it is a dup of the JDK-8195639. Current suggested fix for JDK-8195639 from Alex is: http://cr.openjdk.java.net/~amenkov/popframe009/webrev.01/ If this bug can be reproduced then we could check if the fix for JDK-8195639 will stop its reproduction.
26-11-2018
[~sspitsyn] The issue is not new and is seen in previous builds. But perhaps it started to reproduce more often in latest builds.
26-11-2018
Katya, Is it a regression, or it is always failing with Graal compiler?
26-11-2018
Seems to be related to JDK-8210358 and JDK-8195635. Moving to hotspot/jvmti.
22-11-2018