JDK-8315969 : compiler/rangechecks/TestRangeCheckHoistingScaledIV.java: make flagless
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19,21,22
  • Priority: P4
  • Status: Resolved
  • Resolution: Fixed
  • OS: linux,windows
  • CPU: x86_64
  • Submitted: 2023-09-10
  • Updated: 2023-11-27
  • Resolved: 2023-11-21
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 22
22 b25Fixed
Related Reports
Relates :  
Relates :  
Relates :  
Relates :  
Sub Tasks
JDK-8316094 :  
Description
==== Outcome ====

The test fails with '-Xcomp' because of the JDK-8316124. Temporarily made 'vm.flagless' to get rid of CI failures. As soon as the blocking issue is fixed, we should remove the vm.flagless requirement (JDK-8320495).

==== Original Description ====

The following test failed in the JDK22 CI:

compiler/rangechecks/TestRangeCheckHoistingScaledIV.java

Here's a snippet from the log file:

rc_predicate 0 <u range
lower bound check if: 239
rc_predicate (limit - 1) <u range
upper bound check if: 239
rc_predicate init <u range
rc_predicate init <u range
Predicate invariant if: 265   Loop: N234/N215  limit_check profile_predicated predicated counted [0,int),+1 (2147483648 iters)  rc  has_call rce sfpts={ 204 }
Predicate invariant if negated: 268   Loop: N234/N215  limit_check profile_predicated predicated counted [0,int),+1 (2147483648 iters)  rc  has_call rce sfpts={ 204 }
Loop Predication Performed:  Loop: N234/N215  limit_check profile_predicated predicated counted [0,int),+1 (2147483648 iters)  rc  has_call rce sfpts={ 204 }
];
 stderr: [WARNING: Using incubator modules: jdk.incubator.vector
]
 exitValue = 0

java.lang.RuntimeException: 'rc_predicate init * 6' missing from stdout
	at jdk.test.lib.process.OutputAnalyzer.stdoutShouldContain(OutputAnalyzer.java:236)
	at compiler.rangechecks.TestRangeCheckHoistingScaledIV.main(TestRangeCheckHoistingScaledIV.java:97)
	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)

JavaTest Message: Test threw exception: java.lang.RuntimeException: 'rc_predicate init * 6' missing from stdout
JavaTest Message: shutting down test

STATUS:Failed.`main' threw exception: java.lang.RuntimeException: 'rc_predicate init * 6' missing from stdout
----------rerun:(45/8851)*----------
Comments
Changeset: 9598ff83 Author: Evgeny Nikitin <enikitin@openjdk.org> Committer: Tobias Hartmann <thartmann@openjdk.org> Date: 2023-11-21 15:12:57 +0000 URL: https://git.openjdk.org/jdk/commit/9598ff83860235281a08091128b5df90a4a76916
21-11-2023

A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/16746 Date: 2023-11-20 19:09:18 +0000
20-11-2023

I'm fine with both, just thought to unproblem list the test again quickly since fixing ciMethod::check_call() might be too low of a priority to be addressed quickly (there is one more issue described in JDK-8316124 that needs to be addressed in check_call() that prevents further inlining).
13-09-2023

I don't see the point in reverting the test to not use the test VM args. If the underlying Xcomp issue is fixed then the test can be unproblem-listed then, and continue to run with the VM flags.
12-09-2023

ILW = Test does not work with Xcomp, single test with Xcomp, no workaround = MLH = P4
12-09-2023

I propose to revert the change done in JDK-8314838 for compiler/rangechecks/TestRangeCheckHoistingScaledIV.java and unproblemlist the test again. I've filed JDK-8316124 to fix ciMethod::call_method() together with another recently discovered issue in the same method. [~enikitin] can you undo the fix for this test done with JDK-8314838?
12-09-2023

Looks like this test is starting to fail after JDK-8314838. We now spawn the test VM with ProcessTools.createTestJvm() instead of ProcessTools.createJavaProcessBuilder() which passes the additional test.vm.opts and test.java.opts to the test VM. I've had a closer look and the test already fails with JDK 19 when passing the additional JTreg options to the test VM. It seems that inlining of the interface method jdk.incubator.vector.AbstractSpecies::vectorByteSize() from jdk.incubator.vector.ByteVector::fromMemorySegment() works with -Xbatch but fails with -Xcomp. The reason is that ciMethod::check_call() (only used with -Xcomp/-XX:-UseInterpreter) cannot handle the invokeinterface bytecode and forbids inlining in such a case (the inlining failure is reported with "failed initial checks"). We only try to resolve the method with either invokestatic or invokevirtual but not with invokeinterface: https://github.com/openjdk/jdk/blob/455c471ee36e26dd1ece61c615b8421d65359d5d/src/hotspot/share/ci/ciMethod.cpp#L1201 However, not being able to handle the invokeinterface bytecode seems to be known and is mentioned in the method comment together with a FIXME hint (added with JDK-8014013): https://github.com/openjdk/jdk/blob/455c471ee36e26dd1ece61c615b8421d65359d5d/src/hotspot/share/ci/ciMethod.cpp#L1191-L1195 So, I guess to fix this test, we should fix ciMethod::check_call() to address the FIXME. We should probably do that regardless. But a temporary solution would be to revert the test back to not pass any JTreg vm and java options to the spawned test VM in order to unproblemlist the test again.
12-09-2023

Test is now problemlisted with JDK-8316094.
12-09-2023

This test is failing 6 times per tier6 and 16 times per tier7. Please ProblemList the test ASAP.
12-09-2023