JDK-8328078 : C2 compilation bailout with "too many D-U pinch points"
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 15,17,21,22,23
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • CPU: aarch64
  • Submitted: 2024-03-13
  • Updated: 2025-08-07
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.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8303951 - Add asserts before record_method_not_compilable where possible
Description
CTW fails on AArch64 with this:

$ export JAVA_HOME=<point to fastdebug build>
$ export PATH=$JAVA_HOME/bin:$PATH
$ cd test/hotspot/jtreg/testlibrary/ctw
$ make
$ cd dist
$ wget https://repo1.maven.org/maven2/com/github/tianjing/tgtools.core/1.1.3/tgtools.core-1.1.3.jar
$ ./ctw.sh tgtools.core-1.1.3.jar

 7611  Node  === _  [[ ]]   [30120000007611]
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shipilev/shipilev-jdk/src/hotspot/share/opto/output.cpp:2974), pid=24734, tid=24748
#  assert(false) failed: too many D-U pinch points: 7611 >= 7611
#       
# JRE version: OpenJDK Runtime Environment (23.0) (fastdebug build 23-internal-adhoc.shipilev.shipilev-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 23-internal-adhoc.shipilev.shipilev-jdk, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64)
# Problematic frame:
# V  [libjvm.so+0x13c5e8c]  Scheduling::anti_do_def(Block*, Node*, int, int) [clone .part.247]+0x4c4
#       
# No core dump will be written. Core dumps have been disabled. To enable core dumping, try "ulimit -c unlimited" before starting Java again
#       

Current CompileTask:
C2:5906 3357   !b  4       tgtools.net.udp.UDPClient::main (294 bytes)

Stack: [0x0000fffc935c0000,0x0000fffc937c0000],  sp=0x0000fffc937bb3c0,  free space=2028k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x13347a8]  Scheduling::anti_do_def(Block*, Node*, int, int) [clone .part.0]+0x8f4  (output.cpp:2974)
V  [libjvm.so+0x133a758]  Scheduling::ComputeRegisterAntidependencies(Block*)+0xc78  (output.cpp:3093)
V  [libjvm.so+0x133acd0]  Scheduling::DoScheduling()+0x350  (output.cpp:2786)
V  [libjvm.so+0x1344790]  PhaseOutput::ScheduleAndBundle() [clone .part.0]+0xa0  (output.cpp:2148)
V  [libjvm.so+0x13453f0]  PhaseOutput::Output()+0xa00  (output.cpp:2137)
V  [libjvm.so+0x8dd11c]  Compile::Code_Gen()+0x3f8  (compile.cpp:3031)
V  [libjvm.so+0x8df2c8]  Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1584  (compile.cpp:894)
V  [libjvm.so+0x739b90]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x17c  (c2compiler.cpp:142)
V  [libjvm.so+0x8eaf4c]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0x7cc  (compileBroker.cpp:2305)
V  [libjvm.so+0x8ebb04]  CompileBroker::compiler_thread_loop()+0x584  (compileBroker.cpp:1964)
V  [libjvm.so+0xd64c3c]  JavaThread::thread_main_inner()+0xcc  (javaThread.cpp:721)
V  [libjvm.so+0x15ae880]  Thread::call_run()+0xac  (thread.cpp:221)
V  [libjvm.so+0x131d524]  thread_native_entry(Thread*)+0x130  (os_linux.cpp:864)
C  [libpthread.so.0+0x7950]  start_thread+0x190
Comments
Reproducible with the suggested test from JDK-8362394
07-08-2025
Reproduces since the assert was added with JDK-8303951 in JDK 21 b16 but with '-XX:+AbortVMOnCompilationFailure' I can reproduce even with the original Oracle AArch64 port in JDK 15. ILW = Assert during C2 compilation (old issue, harmless bailout in product), reproducible with CTW on AArch64, no known workaround = MLH = P4
14-03-2024
I suspect it is is not a recent thing, since I tried a few tags from last year, and they fail the same. Have not done a proper bisect yet. The assert is followed by a clean bailout, so I don't think there is a product risk.
13-03-2024