JDK-8268882 : C2: assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,16,17,18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-06-16
  • Updated: 2021-11-30
  • Resolved: 2021-11-09
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 11 JDK 17 JDK 18
11.0.15-oracleFixed 17.0.2Fixed 18 b23Fixed
Related Reports
Duplicate :  
Relates :  
Description
The attached Java Fuzzer test starts to fail after JDK-8264649 (but seems to just reveal an existing issue) with the following assertion failure:

To reproduce:
$ java -Xmx1G -Xcomp -XX:CompileOnly=Test -XX:-TieredCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:StressSeed=568109485 Test.java 
$ java -Xmx1G -Xcomp -XX:CompileOnly=Reduced -XX:-TieredCompilation -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:StressSeed=568109485 Reduced.java

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/opt/mach5/mesos/work_dir/slaves/3c846bae-ce30-4a97-93ee-9fef4497ccb6-S79067/frameworks/1735e8a2-a1db-478c-8104-60c8b0af87dd-0196/executors/be546687-12db-4ded-a96b-86062b189919/runs/56ca4e2d-638a-4f38-8b25-3d968f5f0d09/workspace/open/src/hotspot/share/opto/chaitin.cpp:1670), pid=32679, tid=32692
#  assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc
#
# JRE version: Java(TM) SE Runtime Environment (17.0+26) (fastdebug build 17-ea+26-LTS-2439)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 17-ea+26-LTS-2439, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x8b17b3]  PhaseChaitin::fixup_spills()+0x133
...........
Command Line: -Xmx1G -Xcomp -Xbatch -XX:CompileOnly=Test -XX:CompileCommand=quiet -XX:-TieredCompilation -XX:+IgnoreUnrecognizedVMOptions -XX:+UnlockDiagnosticVMOptions -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:StressSeed=568109485 Test
...........
Current thread (0x00007fda10480150):  JavaThread "C2 CompilerThread0" daemon [_thread_in_native, id=32692, stack(0x00007fda001c7000,0x00007fda002c8000)]


Current CompileTask:
C2:    407    3   !b        Test::mainTest (682 bytes)

Stack: [0x00007fda001c7000,0x00007fda002c8000],  sp=0x00007fda002c2eb0,  free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x8b17b3]  PhaseChaitin::fixup_spills()+0x133
V  [libjvm.so+0x8bca86]  PhaseChaitin::Register_Allocate()+0xa66
V  [libjvm.so+0xa1cc77]  Compile::Code_Gen()+0x317
V  [libjvm.so+0xa2818f]  Compile::Compile(ciEnv*, ciMethod*, int, bool, bool, bool, bool, DirectiveSet*)+0x164f
V  [libjvm.so+0x84959a]  C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x1ea
V  [libjvm.so+0xa38a89]  CompileBroker::invoke_compiler_on_method(CompileTask*)+0xfb9
V  [libjvm.so+0xa397f8]  CompileBroker::compiler_thread_loop()+0x5a8
V  [libjvm.so+0x18b2e91]  JavaThread::thread_main_inner()+0x271
V  [libjvm.so+0x18baa90]  Thread::call_run()+0x100
V  [libjvm.so+0x15872b4]  thread_native_entry(Thread*)+0x104
Comments
Many tests were already executed in 18, 17u and 11u and we still have a lot of testing time until January Update shipment. I think this is sufficient for such a tiny fix. Not yanking dead nodes is a bigger risk than doing it IMHO. So, I don't see any good reason for delaying it.
17-11-2021

11u notice Hi Martin, I am not sure whether we should bring this to 11.0.14, I think 11.0.15 would be better. The change is new in head, and the bug is not new in 11 as I understand, so that there should not be a hurry. We had to backout an 11.0.15 change just last week. What do you think?
17-11-2021

Fix Request (17u): 17u is affected, too. Not yanking out dead nodes may confuse C2. Fix is trivial and applies cleanly.
15-11-2021

Hi, [~mdoerr], before approving this for 11u, it needs to be backported to 17u.
15-11-2021

Fix Request (11u): 11u is affected. Not yanking out dead nodes may confuse C2. Fix is trivial and applies cleanly.
15-11-2021

Hi [~rbackman], I assume the test case could not be transformed into a JTreg test to reliably trigger this bug without fix. If so, please add a "noreg-*" label accordingly to this bug, thanks!
10-11-2021

Changeset: 06992208 Author: Rickard Bäckman <rbackman@openjdk.org> Date: 2021-11-09 21:38:12 +0000 URL: https://git.openjdk.java.net/jdk/commit/0699220830a457959b784b35af125b70f43fa3b0
09-11-2021

Hi [~rbackman], JDK-8275328 found the same assertion failure. I closed it as a dup of this one. Can you verify if it is indeed the same issue before integration? If it's unrelated, please reopen it again, thanks!
15-10-2021

Deferring to JDK 18 as this bug is a P3 and RDP 2 is starting today.
15-07-2021

Couldn't help but do some quick debugging when reproducing this on Friday. I think the problem is a dead loadConUL32 that in turn creates dead Phis during spilling in the register allocator. The loadConUL32 dies because the dead "Kill cr" MachProj is removed by PhaseChaitin::remove_node_if_not_used: 222 loadConUL32 === 1 [[ 221 965 ]] #4/0x0000000000000004 221 subL_rReg === _ 222 224 [[ 223 220 963 964 969 ]] 223 MachProj === 221 [[]] #1 Hope that helps.
12-07-2021

I can still reproduce this with latest JDK 18: java -Xcomp -XX:CompileOnly=Reduced -XX:-TieredCompilation -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:RepeatCompilation=1000 Reduced.java CompileCommand: compileonly Reduced.* bool compileonly = true # To suppress the following error report, specify this argument # after -XX: or in .hotspotrc: SuppressErrorAt=/chaitin.cpp:1670 # # A fatal error has been detected by the Java Runtime Environment: # # Internal Error (...workspace/open/src/hotspot/share/opto/chaitin.cpp:1670), pid=580304, tid=580317 # assert(n->outcnt() != 0 || C->top() == n || n->is_Proj()) failed: No dead instructions after post-alloc # # JRE version: Java(TM) SE Runtime Environment (18.0+6) (fastdebug build 18-ea+6-203) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 18-ea+6-203, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0x898dc3] PhaseChaitin::fixup_spills()+0x133 Also reproduces with JDK 16 and 17.
09-07-2021

This no longer reproduces after JDK-8268405 was fixed.
29-06-2021

Targeting it to JDK 17 for now as it is not clear, yet, if this issue was introduced in JDK 17 or not without further analysis.
16-06-2021

ILW = C2 assertion failure in register allocator, only fails with single Java Fuzzer test, disable compilation of affected method = HLM = P3
16-06-2021