JDK-8346316 : Test compiler/rangechecks/TestLongRangeCheck.java failed with AOTClassLinking enabled
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2024-12-17
  • Updated: 2025-12-04
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 27
27Unresolved
Related Reports
Duplicate :  
JDK-8366489 - Test compiler/rangechecks/TestLongRangeCheck.java failed: should have been deoptimized
Relates :  
JDK-8331497 - Implement JEP 483: Ahead-of-Time Class Loading & Linking
Description
----------messages:(7/791)----------
command: main -ea -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=5000 -XX:PerMethodTrapLimit=100 TestLongRangeCheck
reason: User specified action: run main/othervm -ea -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:+UnlockExperimentalVMOptions -XX:PerMethodSpecTrapLimit=5000 -XX:PerMethodTrapLimit=100 TestLongRangeCheck 
started: Mon Dec 16 11:44:40 UTC 2024
Mode: othervm [/othervm specified]
Additional options from @modules: --add-modules java.base --add-exports java.base/jdk.internal.util=ALL-UNNAMED
finished: Mon Dec 16 11:44:43 UTC 2024
elapsed time (seconds): 3.904
----------configuration:(4/111)----------
Boot Layer
  add modules: java.base                   
  add exports: java.base/jdk.internal.util ALL-UNNAMED

----------System.out:(1/120)----------
[0.029s][error][cds] CDS archive has aot-linked classes. It cannot be used when archived full module graph is not used.
----------System.err:(12/720)----------
java.lang.RuntimeException: should have been deoptimized
	at TestLongRangeCheck.assertIsNotCompiled(TestLongRangeCheck.java:62)
	at TestLongRangeCheck.main(TestLongRangeCheck.java:329)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

It looks like the test is run in an AOT configuration:

-XX:+AOTClassLinking -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+DeoptimizeALot

 but the exec'd VM is not passed the AOT flag(s).
Comments
Note parse predicate for loops uses (see PhaseIdealLoop::add_parse_predicate()): int trap_request = Deoptimization::make_trap_request(reason, Deoptimization::Action_maybe_recompile); Which means after hitting uncommon trap we may not deoptimize code. I suggest someone more familiar with predicates and testing to look on this. This part of the test was added by Roland in JDK-8276116 changes.
04-12-2025
My assumption is AOT may affect timing or something of test execution. We don't generate AOT code in mainline yet. Only classes are preloaded. The failed test `testStridePosScalePosInIntLoopOverflow()` executed 4 times. Based on code it does throw `IndexOutOfBoundsException` otherwise it would failed at lines 324 or 326. It seems we inlined the throw into nmethod instead of uncommon trap since it was not deoptimized. Note, we don't deoptimize for Action_maybe_recompile or Action_none. There is also PerBytecodeTrapLimit = 4 limit when we keep nmethod instead of deoptimizing it.
04-12-2025
Happened again, see JDK-8366489. There are also some failures without -XX:+AOTClassLinking but only in personal runs, so it's unclear if those were caused by other changes.
01-09-2025
Agree to close. We can reopen later if needed.
11-06-2025
Ah right, should we close this as Cannot Reproduce then?
11-06-2025
The test uses -Dtest.modules=java.base/jdk.internal.util --add-modules java.base --add-exports java.base/jdk.internal.util=ALL-UNNAMED which may affected loading AOT archive. There were several AOT/CDS fixed in JDK 25 since beginning of May to address handling modules.
10-06-2025
It did not fail since May 2nd 2025. Last June's failures are different.
10-06-2025
I think this is a test bug, we assume that testStridePosScalePosInIntLoopOverflow would be deopted when Preconditions.checkIndex fails but apparently that does not happen. Not sure if this is really due to AOTCLassLinking or rather due to -XX:+DeoptimizeALot which might have triggered an earlier deopt and recompilation without a trap. Marking as test bug for now.
05-06-2025
Failing in every tier 8 run. 11 linked failures
19-01-2025
Initial ILW = Test failure due to missing deoptimization with AOTClassLinking, single test, no workaround = MLH = P4
06-01-2025