JDK-8235452 : Strip mined loop verification fails with assert(is_OuterStripMinedLoop()) failed: invalid node class
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2019-12-05
  • Updated: 2022-06-27
  • Resolved: 2019-12-11
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 13 JDK 14 JDK 15
11.0.8-oracleFixed 13.0.4Fixed 14 b27Fixed 15Fixed
Related Reports
Relates :  
JDK-8186027 - C2: loop strip mining
Relates :  
JDK-8235584 - UseProfiledLoopPredicate fails with assert(_phase->get_loop(c) == loop) failed: have to be in the same loop
Relates :  
JDK-8220376 - C2: Int >0 not recognized as !=0 for div by 0 check
Description
Generated attached test crashes with 
# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/node.hpp:865
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (open/src/hotspot/share/opto/node.hpp:865), pid=19592, tid=19603
#  assert(is_OuterStripMinedLoop()) failed: invalid node class
#
# JRE version: Java(TM) SE Runtime Environment (14.0) (fastdebug build 14-internal+0-2019-12-03-2213288.lmesnik.ks-apps)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 14-internal+0-2019-12-03-2213288.lmesnik.ks-apps, mixed mode, tiered, compressed oops, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x1186d2c]  LoopNode::verify_strip_mined(int) const+0x3ec
#
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport %p %s %c %d %P" (or dumping to /home/lmesnik/Downloads/r1-101/core.19592)
#
# An error report file with more information is saved as:
# /home/lmesnik/Downloads/r1-101/hs_err_pid19592.log
#
# Compiler replay data is saved as:
# /home/lmesnik/Downloads/r1-101/replay_pid19592.log
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#
Current thread is 19603
Comments
Fix request (13u): The original change applies cleanly, passes tier1 and tier2 tests.
03-06-2020
11u Fix Request: Backporting this patch eliminates a crash in C2 with loop strip mining. Patch applies cleanly to 11u. The new test doesn't fail without the patch: enhancement 8220376 is needed for the test to fail (as an experiment I backported it and the test does fail with it). Anyway, bug exists even if the test doesn't fail so I'd like to proceed with the backport. tier1 and tier2 tests pass with the patch.
18-03-2020
URL: https://hg.openjdk.java.net/jdk/jdk/rev/1a7175456d29 User: thartmann Date: 2019-12-11 09:43:04 +0000
11-12-2019
We crash during loop verification because a strip mined loop lost its OuterStripMined loop counterpart. Removal of the outer loop is triggered by the new optimization added with JDK-8220376 but it can probably happen in other circumstances as well. The strip mined loop also lost its CountedLoopEnd and is therefore malformed. The detailed steps of how this happens are described in the test: http://cr.openjdk.java.net/~thartmann/8235452/webrev.01/test/hotspot/jtreg/compiler/loopstripmining/TestDeadOuterStripMinedLoop.java.html The fix is to not try to verify strip mining if the strip mined loop is malformed. I've added an assert to check that the OuterStripMinedLoop is always removed in this case. http://cr.openjdk.java.net/~thartmann/8235452/webrev.01 The test also triggers a crash in the UseProfiledLoopPredicate code added by JDK-8203197. I've slightly modified the code in loopPredicate.cpp to only execute PathFrequency::to if the projection matches the uncommon trap if pattern and filed JDK-8235584 to investigate in detail.
09-12-2019
Simple test: https://bugs.openjdk.java.net/secure/attachment/85946/Test.java
06-12-2019
ILW = Crash during C2 compilation (regression in JDK 14), reproducible with JavaFuzzer generated test, disable loop strip mining (-XX:LoopStripMiningIter=0) = HMM = P2
06-12-2019
Product build also fails with: # Internal Error (loopPredicate.cpp:979), pid=20069, tid=20080 # Error: ShouldNotReachHere() Current CompileTask: C2: 340 68 % ! 4 Test::mainTest @ 155 (507 bytes) Stack: [0x00007f6739648000,0x00007f6739749000], sp=0x00007f6739743a60, free space=1006k Native frames: (J=compiled Java code, A=aot compiled Java code, j=interpreted, Vv=VM code, C=native code) V [libjvm.so+0xa40a9d] PathFrequency::to(Node*)+0x89d V [libjvm.so+0xa3f08f] PhaseIdealLoop::loop_predication_impl(IdealLoopTree*) [clone .part.72]+0x108f V [libjvm.so+0xa3f91f] IdealLoopTree::loop_predication(PhaseIdealLoop*)+0x5f V [libjvm.so+0xa61203] PhaseIdealLoop::build_and_optimize(LoopOptsMode)+0xd73 V [libjvm.so+0x5c2845] PhaseIdealLoop::optimize(PhaseIterGVN&, LoopOptsMode)+0x1d5 V [libjvm.so+0x5c0dd7] Compile::Optimize()+0xb57 V [libjvm.so+0x5c20bc] Compile::Compile(ciEnv*, C2Compiler*, ciMethod*, int, bool, bool, bool, DirectiveSet*)+0xe7c V [libjvm.so+0x511911] C2Compiler::compile_method(ciEnv*, ciMethod*, int, DirectiveSet*)+0xc1 V [libjvm.so+0x5cb3ac] CompileBroker::invoke_compiler_on_method(CompileTask*)+0x33c V [libjvm.so+0x5cc788] CompileBroker::compiler_thread_loop()+0x4e8 V [libjvm.so+0xd46092] JavaThread::thread_main_inner()+0xe2 V [libjvm.so+0xd4aadd] Thread::call_run()+0x10d V [libjvm.so+0xba7aa7] thread_native_entry(Thread*)+0xe7
06-12-2019
Narrowed it down to fix for JDK-8220376 in jdk-14+25-1170 (probably only triggers the issue).
06-12-2019