JDK-8291597 : [BACKOUT] JDK-8289996: Fix array range check hoisting for some scaled loop iv
Type:Sub-task
Component:hotspot
Sub-Component:compiler
Affected Version:20
Priority:P3
Status:Resolved
Resolution:Fixed
OS:generic
CPU:generic
Submitted:2022-08-01
Updated:2022-08-09
Resolved:2022-08-02
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.
[~dlong] Just now I find JDK-8291466 still fails (with lower probability) after my backout. Now I have a very small case to reproduce. So it's indeed another hidden issue. I will attach the test case and re-open JDK-8291466.
05-08-2022
[~pli], I think all the reported failures are from before your backout.
05-08-2022
[~dcubed] Does this igvn dead loop issue still exist after the BACKOUT? It should be the same to JDK-8291466 - a hidden issue exposed by my previous patch. MulINode calls swap_edge() to move constant input to the right hand side. Its parent node class MulNode also does this. But they have different critiera for constant. It leads to the two inputs of multiply are swapped back and forth, and eventually causes the assert failure of igvn dead loop. I cannot reproduce the issue after my patch is backed out. Can you reproduce that?
05-08-2022
Here's hs_err_pid file snippets from the jdk-20+9-468-tier8 sighting:
applications/javafuzzer/BigTest.java
# Internal Error (c:\sb\prod\1659145763\workspace\open\src\hotspot\share\opto\phaseX.cpp:1162), pid=2936, tid=9016
# assert(false) failed: infinite loop in PhaseIterGVN::transform_old
#
# JRE version: Java(TM) SE Runtime Environment (20.0+9) (fastdebug build 20-ea+9-468)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 20-ea+9-468, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, windows-amd64)
<snip>
--------------- T H R E A D ---------------
Current thread (0x000002330138da60): JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=9016, stack(0x000000f581e00000,0x000000f581f00000)]
Current CompileTask:
C2: 298 9 !b Test::mainTest (629 bytes)
Stack: [0x000000f581e00000,0x000000f581f00000]
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V [jvm.dll+0xc72d81] os::platform_print_native_stack+0xf1 (os_windows_x86.cpp:234)
V [jvm.dll+0xed0a94] VMError::report+0x10e4 (vmError.cpp:839)
V [jvm.dll+0xed25ce] VMError::report_and_die+0x7fe (vmError.cpp:1691)
V [jvm.dll+0xed2d54] VMError::report_and_die+0x64 (vmError.cpp:1472)
V [jvm.dll+0x5ac337] report_vm_error+0xb7 (debug.cpp:284)
V [jvm.dll+0xcb6132] PhaseIterGVN::transform_old+0x1b2 (phaseX.cpp:1266)
V [jvm.dll+0xcb3329] PhaseIterGVN::optimize+0x2c9 (phaseX.cpp:1204)
V [jvm.dll+0x548486] PhaseIdealLoop::optimize+0x166 (loopnode.hpp:1171)
V [jvm.dll+0x53c068] Compile::Optimize+0xb68 (compile.cpp:2359)
V [jvm.dll+0x539392] Compile::Compile+0x14e2 (compile.cpp:824)
V [jvm.dll+0x45c9d5] C2Compiler::compile_method+0x145 (c2compiler.cpp:115)
V [jvm.dll+0x553781] CompileBroker::invoke_compiler_on_method+0x791 (compileBroker.cpp:2314)
V [jvm.dll+0x550e09] CompileBroker::compiler_thread_loop+0x279 (compileBroker.cpp:1982)
V [jvm.dll+0x821464] JavaThread::thread_main_inner+0x2a4 (javaThread.cpp:700)
V [jvm.dll+0xe48099] Thread::call_run+0x269 (thread.cpp:229)
V [jvm.dll+0xc71699] thread_native_entry+0xb9 (os_windows.cpp:546)
C [ucrtbase.dll+0x2268a]
C [KERNEL32.DLL+0x17974]
C [ntdll.dll+0x5a0b1]