JDK-8294967 : C2 fails with assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 19,20
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2022-10-07
  • Updated: 2022-10-13
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 20
20Unresolved
Related Reports
Relates :  
Relates :  
Description
Running the attached JavaFuzzer-generated Java program (Test.java) on a debug JDK build as follows:

$ java -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test::test Test.java

Results in the following assertion failure:

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (../../src/hotspot/share/opto/loopopts.cpp:1605), pid=439963, tid=439976
#  assert(!n->is_Store() && !n->is_LoadStore()) failed: no node with a side effect
#
# JRE version: OpenJDK Runtime Environment (20.0) (fastdebug build 20-internal-adhoc.rocastan.open)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 20-internal-adhoc.rocastan.open, compiled mode, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x14dbebf]  PhaseIdealLoop::try_sink_out_of_loop(Node*)+0xa0f

Comments
I think this is likely a case of JDK-8288981 where unswitching happens after pre/main/post loop are created. Then pre/main/post and unrolling happens on one of the new main loops. Too much unrolling causes a CastII to become top which in turns causes a store to have no memory phi that keeps it in a loop (and the assert fires). This should be caught by skeleton predicates but isn't because they are lost on the way (they are not copied from the main loop when unswitching happens).
07-10-2022

ILW = assertion failure in debug build; JavaFuzzer-generated test case; disable compilation of affected method = MMM = P3
07-10-2022

[~roland] since you have worked on related assertion failures before, could you have a look? Thanks!
07-10-2022

The failure can be reproduced first on JDK 19 b26.
07-10-2022