JDK-8229483 : Sinking load out of loop may trigger: assert(found_sfpt) failed: no node in loop that's not input to safepoint
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,14
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2019-08-13
  • Updated: 2021-04-09
  • Resolved: 2019-09-25
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
11.0.6Fixed 13.0.4Fixed 14 b16Fixed
Related Reports
Duplicate :  
Relates :  
Relates :  
Relates :  
Relates :  
Description
(synopsis is provisional, please change as you see fit)

Found with fuzzing, the bundle is attached. Reproduces with Shenandoah, not with G1.

$ jdk-jdk/build/linux-x86_64-server-fastdebug/images/jdk/bin/java -XX:+UnlockExperimentalVMOptions -XX:+UseShenandoahGC Test

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/loopnode.cpp:992
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/opto/loopnode.cpp:992), pid=12041, tid=12050
#  assert(found_sfpt) failed: no node in loop that's not input to safepoint
#
# JRE version: OpenJDK Runtime Environment (14.0) (fastdebug build 14-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 14-internal+0-adhoc.shade.jdk-jdk, mixed mode, sharing, tiered, compressed oops, shenandoah gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x11f2cb8]  LoopNode::verify_strip_mined(int) const+0x5f8

Comments
13u Fix Request Backporting this patch fixes a c2 crash. Patch applies cleanly to 13u. tier1 tests pass with the patch.
27-05-2020

I believe this does not affect 8-shenandoah, because LSM is not there. Neither new test nor the fuzzer test case fails in sh/jdk8. Dropping relevant affected version.
30-10-2019

11u Fix Request Backporting this patch fixes a c2 crash. Patch applies cleanly to 11u. New test fails without the product patch, and passes with it. tier1 tests pass with the patch.
02-10-2019

URL: https://hg.openjdk.java.net/jdk/jdk/rev/88fce7eea1f6 User: roland Date: 2019-09-25 07:35:36 +0000
25-09-2019

Test case that reproduces without Shenandoah attached. Run with: java -XX:-TieredCompilation -XX:-BackgroundCompilation -XX:-UseOnStackReplacement -XX:+PrintCompilation -XX:PrintIdealGraphFile=graph.xml -XX:PrintIdealGraphLevel=2 -XX:CompileOnly=AntiDependentLoadInOuterStripMinedLoop::test -XX:LoopMaxUnroll=0 AntiDependentLoadInOuterStripMinedLoop Prototype fix: diff -r 2227a0cfd6b3 -r 5f4af4e56160 src/hotspot/share/opto/loopopts.cpp --- a/src/hotspot/share/opto/loopopts.cpp Thu Aug 22 13:47:14 2019 +0200 +++ b/src/hotspot/share/opto/loopopts.cpp Thu Aug 22 16:31:20 2019 +0200 @@ -1418,6 +1418,11 @@ // Such nodes should only have ProjNodes as outs, e.g. IfNode // should only have IfTrueNode and IfFalseNode (4985384). x_ctrl = find_non_split_ctrl(x_ctrl); + + IdealLoopTree* x_loop = get_loop(x_ctrl); + if (x_loop->_head->is_OuterStripMinedLoop() && is_dominator(n_ctrl, x_loop->_head)) { + x_ctrl = x_loop->_head->in(LoopNode::EntryControl); + } assert(dom_depth(n_ctrl) <= dom_depth(x_ctrl), "n is later than its clone"); x->set_req(0, x_ctrl);
23-08-2019

The tests does pass with -XX:-SplitIfBlocks. But it reproduces only with Shenandoah, not G1, not Serial, not Parallel, not ZGC. So, this might still be Shenandoah-specific. I linked the bugs, though.
13-08-2019

both Shenandoah and G1 set LoopStripMiningIter to 1000, so both of them should do loop strip-mining.
13-08-2019

Can you pass it with -XX:-SplitIfBlocks? If you can, probably it's same as JDK-8229450.
13-08-2019