JDK-8350208 : CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 22,25,26
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-02-17
  • Updated: 2025-05-14
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 26
26Unresolved
Related Reports
Duplicate :  
Relates :  
Description
Reliably reproduces in current mainline (as more code is exposed to compilation after JDK-8348570):

$ export JAVA_HOME=<point to fastdebug build>
$ export PATH=$JAVA_HOME/bin:$PATH
$ cd test/hotspot/jtreg/testlibrary/ctw
$ make
$ cd dist
$ wget https://repo.maven.apache.org/maven2/org/apache/openejb/openejb-itests-standalone-client/3.1/openejb-itests-standalone-client-3.1.jar
$ ./ctwrunner.sh openejb-itests-standalone-client-3.1.jar

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/opto/graphKit.cpp:929), pid=103406, tid=103426
#  assert(out_jvms->sp() >= (uint)inputs) failed: not enough operands for reexecution
#

Current CompileTask:
C2:73131 77219   !b  4       edu.emory.mathcs.backport.java.util.concurrent.LinkedBlockingQueue$Itr::remove (207 bytes)

Stack: [0x000077187dc00000,0x000077187dd00000],  sp=0x000077187dcfc4c0,  free space=1009k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0xe727bb]  GraphKit::add_safepoint_edges(SafePointNode*, bool)+0x177b  (graphKit.cpp:929)
V  [libjvm.so+0x161a09e]  Parse::add_safepoint()+0x22e  (parse1.cpp:2278)
V  [libjvm.so+0xc52458]  Parse::catch_inline_exceptions(SafePointNode*)+0x1938  (parse.hpp:515)
V  [libjvm.so+0x160f690]  Parse::do_exceptions()+0xe0  (parse1.cpp:943)
V  [libjvm.so+0x1616eb9]  Parse::do_one_block()+0x419  (parse1.cpp:1592)
V  [libjvm.so+0x1617e58]  Parse::do_all_blocks()+0x138  (parse1.cpp:724)
V  [libjvm.so+0x161b182]  Parse::Parse(JVMState*, ciMethod*, float)+0xac2  (parse1.cpp:628)
V  [libjvm.so+0x8f09e4]  ParseGenerator::generate(JVMState*)+0x154  (callGenerator.cpp:97)
V  [libjvm.so+0xaa2852]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1542  (compile.cpp:793)
V  [libjvm.so+0x8edd27]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1b7  (c2compiler.cpp:141)
V  [libjvm.so+0xab0370]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xad0  (compileBroker.cpp:2331)
V  [libjvm.so+0xab1168]  CompileBroker::compiler_thread_loop()+0x5c8  (compileBroker.cpp:1975)
V  [libjvm.so+0xf9ab8e]  JavaThread::thread_main_inner()+0xee  (javaThread.cpp:776)
V  [libjvm.so+0x1ab728e]  Thread::call_run()+0xbe  (thread.cpp:231)
V  [libjvm.so+0x15ce5db]  thread_native_entry(Thread*)+0x12b  (os_linux.cpp:877)

Comments
Datapoint: It looks like it is the only assert we are currently catching in extended CTW testing in current mainline. So when we fix this, CTW would likely be sequaky clean :)
14-05-2025

[~thartmann] Thanks for noticing, I will try to submit a fix this week.
13-05-2025

Since this is an old issue and we are getting closer to RDP 1 for JDK 25 (June 05, 2025), I'm tentatively deferring this to JDK 26. Feel free to still fix this in JDK 25 if there's time left.
13-05-2025

Quickly checked with the replay file and it works since JDK 22 (replay fails with JDK 21).
13-05-2025

Also, since this does not look like a regression in JDK 25, it would be good to set the appropriate affects versions once we know the root cause.
06-05-2025

[~qamai] Any updates on this? Just asking because we're getting close to the fork of JDK 25 :) Thanks!
06-05-2025

ILW - assert in debug build; debug build only, reproduces reliably; no workaround = MMM = P3
18-02-2025

Cool, would you like to take this fix to mainline then?
18-02-2025

Seems to be the same as JDK-8349068
18-02-2025