JDK-8319448 : Some !vm.graal.enabled tests fail with Graal
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2023-11-05
  • Updated: 2024-06-24
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.
Other
tbdUnresolved
Related Reports
Relates :  
Description
Even though these tests are marked with:

 * @requires !vm.graal.enabled & vm.opt.final.UseVtableBasedCHA == true

they are run in tier5 and fail with:

----------System.err:(27/1681)----------
Java HotSpot(TM) 64-Bit Server VM warning: dependency logging results may be inflated by VerifyDependencies
java.lang.Error: java.lang.reflect.InvocationTargetException
        at compiler.cha.Utils.run(Utils.java:197)
        at compiler.cha.Utils.run(Utils.java:202)
        at compiler.cha.StrengthReduceInterfaceCall.main(StrengthReduceInterfaceCall.java:61)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1570)
Caused by: java.lang.reflect.InvocationTargetException
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:118)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at compiler.cha.Utils.run(Utils.java:193)
        ... 6 more
Caused by: java.lang.RuntimeException: assertTrue: expected true, was false
        at jdk.test.lib.Asserts.fail(Asserts.java:594)
        at jdk.test.lib.Asserts.assertTrue(Asserts.java:486)
        at jdk.test.lib.Asserts.assertTrue(Asserts.java:472)
        at compiler.cha.Utils$ATest.assertCompiled(Utils.java:156)
        at compiler.cha.StrengthReduceInterfaceCall$ObjectToString.testMono(StrengthReduceInterfaceCall.java:100)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        ... 8 more

Should be reproducible with the following in a galahad-ee workspace:

make LOG=info CONF=linux-x64-debug TEST="compiler/cha compiler/intrinsics/klass/CastNullCheckDroppingsTest.java compiler/c2/cr7200264/TestSSE4IntVect.java compiler/c2/cr7200264/TestSSE2IntVect.java" JTREG_JAVA_OPTIONS="-XX:+UnlockDiagnosticVMOptions -XX:TieredStopAtLevel=3 -XX:+StressLoopInvariantCodeMotion -XX:+StressRangeCheckElimination -XX:+StressLinearScan -XX:+UnlockExperimentalVMOptions -XX:+UseJVMCICompiler" test
Comments
The problem is that vm.graal.enabled is false because -XX:TieredStopAtLevel=3 is set but then @run disables TieredCompilation which leads to TieredStopAtLevel=3 having no effect and essentially re-enabling Graal. I think '& (vm.opt.TieredStopAtLevel == null | vm.opt.TieredStopAtLevel==4)' should be added to these tests. We already have that in test/hotspot/jtreg/runtime/exceptionMsgs/IncompatibleClassChangeError/IncompatibleClassChangeErrorTest.java
06-11-2023

ILW = Tests fail (test bugs), several tests with Graal on tier5, no workaround = MMH = P3
06-11-2023