JDK-8346184 : C2: assert(has_node(i)) failed during split thru phi
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 25
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2024-12-13
  • Updated: 2025-11-13
  • Resolved: 2025-01-10
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 25
25 b06Fixed
Related Reports
Causes :  
JDK-8371804 - C2: Tighten up LoadNode::Value comments after JDK-8346184
Duplicate :  
JDK-8347128 - CTW: assert(has_node(i)) failed after JDK-8343148
Duplicate :  
JDK-8347016 - SIGSEGV in PhaseIdealLoop::get_ctrl
Relates :  
JDK-8343148 - C2: Refactor uses of "PhaseValue::*con*() + PhaseIdealLoop::set_ctrl()" into separate method
Description
Reproducible with attached test case:

$ java -XX:-BackgroundCompilation TestLoadSplitThruPhiNull
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/roland/jdk-jdk/src/hotspot/share/opto/loopnode.hpp:1003), pid=420882, tid=420900
#  Error: assert(has_node(i)) failed
#
# JRE version: OpenJDK Runtime Environment (25.0) (fastdebug build 25-internal-adhoc.roland.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 25-internal-adhoc.roland.jdk-jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x139fd2a]  PhaseIdealLoop::get_ctrl(Node const*)+0x3ea
#

call stack:

Stack: [0x00007f9a48cf1000,0x00007f9a48df1000],  sp=0x00007f9a48debd40,  free space=1003k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x139fd2a]  PhaseIdealLoop::get_ctrl(Node const*)+0x3ea  (loopnode.hpp:1003)
V  [libjvm.so+0x13e91ce]  PhaseIdealLoop::split_thru_phi(Node*, Node*, int)+0x53e  (loopopts.cpp:192)
V  [libjvm.so+0x13ee2b3]  PhaseIdealLoop::split_if_with_blocks_pre(Node*)+0x2c3  (loopopts.cpp:1226)
V  [libjvm.so+0x13f33c5]  PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x1f5  (loopopts.cpp:1982)
V  [libjvm.so+0x13e42d5]  PhaseIdealLoop::build_and_optimize()+0x10c5  (loopnode.cpp:4889)
V  [libjvm.so+0xa9f62f]  PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x3cf  (loopnode.hpp:1113)
V  [libjvm.so+0xa985bc]  Compile::optimize_loops(PhaseIterGVN&, LoopOptsMode)+0x5c  (compile.cpp:2183)
V  [libjvm.so+0xa99322]  Compile::Optimize()+0xa92  (compile.cpp:2430)
V  [libjvm.so+0xa9d2cf]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1baf  (compile.cpp:852)
V  [libjvm.so+0x8dba18]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1c8  (c2compiler.cpp:142)
V  [libjvm.so+0xaa9de1]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xad1  (compileBroker.cpp:2319)
V  [libjvm.so+0xaaad48]  CompileBroker::compiler_thread_loop()+0x4e8  (compileBroker.cpp:1977)
V  [libjvm.so+0xfc3f1e]  JavaThread::thread_main_inner()+0xee  (javaThread.cpp:776)
V  [libjvm.so+0x1b09386]  Thread::call_run()+0xb6  (thread.cpp:232)
V  [libjvm.so+0x160f618]  thread_native_entry(Thread*)+0x128  (os_linux.cpp:860)
C  [libc.so.6+0x961b7]  start_thread+0x377

assert added by 8343148 is causing the failure but underlying (minor) issue has likely been present for a while.
Comments
Changeset: 9cf7d42b Branch: master Author: Roland Westrelin <roland@openjdk.org> Date: 2025-01-10 16:47:51 +0000 URL: https://git.openjdk.org/jdk/commit/9cf7d42b65cfecfe27d0267f971acb743c02b675
10-01-2025
Yes, it's out for review: https://github.com/openjdk/jdk/pull/22818
10-01-2025
Dacapo is constantly failing with this crash. Is a fix in progress?
10-01-2025
Some CTW tests are failing similarly, see JDK-8347128. Current fix seems to fix those CTW failures as well!
07-01-2025
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/22818 Date: 2024-12-18 16:57:45 +0000
18-12-2024
ILW = Assert during C2 compilation (probably harmless, old issue but assert was recently added), reproducible with single test, no workaround but disable split if or compilation of affected method = HLM = P3
16-12-2024
Looks like we got the same stack trace in 25-b2 while running Renaissance-FinagleHttp on Ampere: Current thread (0x0000fffc600adf80): JavaThread "C2 CompilerThread5" daemon [_thread_in_native, id=2474017, stack(0x0000fffc8cf70000,0x0000fffc8d170000) (2048K)] Current CompileTask: C2:3367 7141 4 com.fasterxml.jackson.databind.type.TypeFactory::_fromAny (171 bytes) Stack: [0x0000fffc8cf70000,0x0000fffc8d170000], sp=0x0000fffc8d16b120, free space=2028k Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xaae854] PhaseIdealLoop::get_ctrl(Node const*) [clone .isra.0]+0x24 V [libjvm.so+0xab3a68] PhaseIdealLoop::split_if_with_blocks_pre(Node*)+0xe8 V [libjvm.so+0xab66f8] PhaseIdealLoop::split_if_with_blocks(VectorSet&, Node_Stack&)+0x184 V [libjvm.so+0xaad7b0] PhaseIdealLoop::build_and_optimize()+0xc10 V [libjvm.so+0x5a55cc] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x19c V [libjvm.so+0x5a39bc] Compile::Optimize()+0x3dc V [libjvm.so+0x5a4ea8] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0xc18 V [libjvm.so+0x4d2420] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x13c V [libjvm.so+0x5aa948] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x9c8 V [libjvm.so+0x5ad580] CompileBroker::compiler_thread_loop()+0x3fc V [libjvm.so+0x82aae8] JavaThread::thread_main_inner() [clone .part.0]+0xa4 V [libjvm.so+0xd5cff8] Thread::call_run()+0xa8 V [libjvm.so+0xbc0cc0] thread_native_entry(Thread*)+0xdc C [libpthread.so.0+0x7928] start_thread+0x188 We are running the JMH version of Renaissance with options: FinagleHttp -t 1 -i 15 -wi 25 -f 10
13-12-2024