JDK-8204347 : [Graal] compiler/stable/* tests fail with java.lang.AssertionError
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14,15
  • Priority: P4
  • Status: Resolved
  • Resolution: Duplicate
  • OS: os_x
  • CPU: x86_64
  • Submitted: 2018-06-05
  • Updated: 2020-07-09
  • Resolved: 2020-07-09
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 15
15Resolved
Related Reports
Duplicate :  
JDK-8207267 - Enable tests which currently do not run with Java Graal to run with libgraal
Duplicate :  
JDK-8204346 - compiler/stable/TestStableUByte.java throws java.lang.AssertionError
Duplicate :  
JDK-8204841 - compiler/stable/TestStableObject.java fails with java.lang.AssertionError: B != A
Duplicate :  
JDK-8204274 - [GRAAL] compiler/stable/TestStableShort.java test failed
Relates :  
JDK-8205074 - [Graal] Add rest of compiler/stable tests into ProblemList-graal.txt
Relates :  
JDK-8204694 - Add failed compiler/stable tests into ProblemList-graal.txt
Description
Test: compiler/stable/TestStableUShort.java

compiler.stable.TestStableUShort$UShortStable: FAILED
java.lang.AssertionError: 1 != 65535
	at compiler.stable.TestStableUShort.assertEquals(TestStableUShort.java:123)
	at compiler.stable.TestStableUShort$UShortStable.test(TestStableUShort.java:95)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at compiler.stable.TestStableUShort.run(TestStableUShort.java:132)
	at compiler.stable.TestStableUShort.main(TestStableUShort.java:71)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:832)
compiler.stable.TestStableUShort$UShortArrayDim1: PASSED
----------System.err:(13/764)----------
java.lang.Error: TEST FAILED
	at compiler.stable.TestStableUShort.main(TestStableUShort.java:75)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.base/java.lang.reflect.Method.invoke(Method.java:566)
	at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:115)
	at java.base/java.lang.Thread.run(Thread.java:832)

JavaTest Message: Test threw exception: java.lang.Error: TEST FAILED
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.Error: TEST FAILED
Comments
Expect the test work with libgraal.
09-07-2020
[~epavlova], since you were working on cleaning up Graal testing and consolidation of known failures under umbrella bugs, I'm assigning this and some other unassigned Graal (alleged) test bugs to you.
02-07-2020
As hinted in the sources[1], it can happen that an application thread holds a lock that a JVMCI compiler thread needs. This will lead to deadlock if the application thread waits forever for a synchronous compilation. We've seen this occur in the past when both the application thread and JVMCI thread are doing class loading where they contend on some zip file lock. [1] http://hg.openjdk.java.net/jdk/jdk/file/83aec1d357d4/src/hotspot/share/compiler/compileBroker.cpp#l1506
24-01-2019
[~dnsimon] Doug, could you please explain why blocking tests are handled differently in case of JVMCI compilations? as an end-user, I'd expect Xbatch/Xcomp works the same way independently of the used compiler.
24-01-2019
Thanks Doug. Re-adding testbug label.
26-09-2018
Yes, the test is assuming something that is simply not guaranteed to be true in the case of Graal.
26-09-2018
I think the testbug label is still valid because according to Doug's comment above, the test should be modified to check if the test method is compiled.
26-09-2018
the tests are in graal's problem-list, removing testbug.
24-09-2018
Another instance of the same problem with TestStableObject.java JDK-8204841. [~epavlova], I think it should be added to the problem list as well (we should probably add all the stable/* tests that specify -XX:-TieredCompilation).
12-06-2018
I have filed JDK-8204694
11-06-2018
Yes. Tests fix is not simple so we can delay it until 12 unless someone have time to fix it in 11.
11-06-2018
[~kvn] then perhaps we should create new bug for putting these tests into ProblemList-graal.txt and target current bug for 12?
11-06-2018
I think we should put these tests on Graal's problem list until we fix them.
11-06-2018
compiler/stable/TestStableShort.java failed the same way JDK-8204274. Note, all these 'stable' tests switch off tiered compilation in their @run commands: -Xcomp -XX:-TieredCompilation As result Graal compilation significantly delayed since it is executed in Interpreter mode until it compiles itself (no C1 to compile it).
11-06-2018
Thanks Doug! Updated ILW = Test fails because compilation times out (test bug), two tests with Graal as JIT, use C2 = MLM = P4
07-06-2018
The problem is that UShortStable::test expects only the compiled version of UShortStable::get to be executed under -Xcomp. However, when Graal is used under -Xcomp, the compilation can time out ( http://hg.openjdk.java.net/jdk/jdk/file/83aec1d357d4/src/hotspot/share/compiler/compileBroker.cpp#l1516). I saw this while enabling IGV dumping while running this test: 15377 73 b compiler.stable.TestStableUShort$UShortStable::get (10 bytes) wait for blocking compilation timed out The solution is to probably use the WhiteBox.isMethodCompiled API for tests that expect a method to be compiled.
06-06-2018
This looks like a Graal bug. [~dnsimon], could you please have a look or re-assign?
06-06-2018
ILW = Incorrect result of compiled code (very intermittent), single test with Graal as JIT, use C2 = HLM = P3
06-06-2018
compiler/stable/TestStableUByte.java also failed similar way: compiler.stable.TestStableUByte$UByteStable: FAILED java.lang.AssertionError: 1 != 255 at compiler.stable.TestStableUByte.assertEquals(TestStableUByte.java:123) at compiler.stable.TestStableUByte$UByteStable.test(TestStableUByte.java:95)
05-06-2018
I should say that I see these failure from time to time but I never was able to reproduce it on my linux. It could be the test fails only on some specific machines only.
05-06-2018
The test failed running when running with Graal: -XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal To run the test with Graal do: > jtreg -jdk:build/linux-x64/images/jdk -vmoptions:"-XX:+UnlockExperimentalVMOptions -XX:+EnableJVMCI -XX:+TieredCompilation -XX:+UseJVMCICompiler -Djvmci.Compiler=graal" compiler/stable/TestStableUShort.java
05-06-2018