Bug ID: JDK-8293996 C2: fix and simplify IdealLoopTree::do_remove_empty

Type: Bug
Component: hotspot
Sub-Component: compiler
Affected Version: 10,11,17,18,19,20

Priority: P4
Status: Resolved
Resolution: Fixed

Submitted: 2022-09-15
Updated: 2023-01-09
Resolved: 2022-09-27

JDK 11	JDK 17	JDK 19	JDK 20
11.0.19-oracleFixed	17.0.7-oracleFixed	19.0.2Fixed	20 b17Fixed

ADDITIONAL SYSTEM INFORMATION :
Arch: x86_64
OS: Ubuntu 20.04

java: 
- openjdk version "11.0.17-internal" 2022-10-18
- OpenJDK Runtime Environment (fastdebug build 11.0.17-internal+0-adhoc.congli.jdk11u-dev)
- OpenJDK 64-Bit Server VM (fastdebug build 11.0.17-internal+0-adhoc.congli.jdk11u-dev, mixed mode)

javac: javac 11.0.17-internal


A DESCRIPTION OF THE PROBLEM :
This is a JIT compiler bug which triggers an assertion failure in the C2 compiler:

#  Internal Error (/zdata/congli/hotspot-build-env/jdk11u-dev/src/hotspot/share/opto/loopnode.cpp:1606), pid=2489456, tid=2489469
#  assert(false) failed: should be able to adjust outer loop

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. javac T.java
2. java -Xmx1G -XX:-BackgroundCompilation -XX:-PrintWarnings --illegal-access=deny T

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
NO crash
ACTUAL -
Crashed

---------- BEGIN SOURCE ----------
class T {
  long b;

  void a(double d) {
    int e;
    int w = 43542;
    int o = 11;
    e = w;
    for (int i = 524; i < 19325; i += 1) {
      for (int j = 0; j < 32767; j++) o++;
      for (int k = 0; k < o; k++) e += 7;
    }
  }

  void p(long l, float f, long l1) {
    double z = 83.31189;
    for (; ; ) a(z);
  }

  void f() {
    p(b, 93.934F, b);
  }

  public static void main(String[] q) {
    T t = new T();
    t.f();
  }
}

---------- END SOURCE ----------

FREQUENCY : always

Fix request [11u] I backport this for parity with 11.0.19-oracle. Typical risk of a C2 change. Has verification code but no test. In 20 for a while now. Take to keep up with Oracle. Clean backport except for Copyright. Test passes. SAP nighlty testing passed including Windows.
04-01-2023
A pull request was submitted for review. URL: https://git.openjdk.org/jdk11u-dev/pull/1628 Date: 2023-01-03 16:49:36 +0000
03-01-2023
Fix request [17u] I backport this for parity with 17.0.7-oracle. Typical risk of a C2 change. Has verification code but no test. In 20 for a while now. Take to keep up with Oracle. Clean backport. Test passes. SAP nightly testing passed.
30-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk17u-dev/pull/998 Date: 2022-12-29 12:44:05 +0000
29-12-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk19u/pull/86 Date: 2022-11-22 16:06:43 +0000
22-11-2022
Fix Request (JDK 19u) Fixes an assertion during C2 compilation because an empty loop is not removed. The fix is low risk and applies cleanly. Already tested and backported to Oracle JDK 11u and 17u.
22-11-2022
Changeset: dd51f7e0 Author: Emanuel Peter <epeter@openjdk.org> Date: 2022-09-27 08:52:19 +0000 URL: https://git.openjdk.org/jdk/commit/dd51f7e0b75d3a16403608d89cd206ac0bedf882
27-09-2022
A pull request was submitted for review. URL: https://git.openjdk.org/jdk/pull/10393 Date: 2022-09-22 14:38:33 +0000
26-09-2022
I can make the failure reproduce with this rr ./java -XX:+UseG1GC -XX:CompileCommand=compileonly,T::* -Xbatch -XX:-TieredCompilation T.java If I add -XX:+StressIGVN, the failure becomes intermittent. Analysis: We miss to propagate constant folding for AddI. AddI looks at inputs and inputs of inputs to constant fold. But if only inputs of inputs change, the node is not notified, and IGVN does not call Ideal on it again. This means that in some cases, the condition that is supposed to collapse may not collapse. -XX:+StressIGVN makes the issue intermittent, because randomly that node gets processed after the input of the input turns to a constant, and then all can be folded.
21-09-2022
In adjust_strip_mined_loop, we iterate all Phi nodes of the inner_cl. Turns out that we have an empty loop. So there is no Phi, and we cannot find the iv_phi. Further info: OSR compilation of T::p T::a inlined, and loop stripmined We discover that the loop is empty in IdealLoopTree::do_remove_empty_loop, then remove the Phi, replace the phi with final value, hope the loop collapses because backedge cannot be taken now. Somehow this seems not to have happened yet by the time we assert and crash.
20-09-2022
Just reproduced it like this: ./java -XX:+PrintCompilation -XX:CompileCommand=compileonly,T::* -Xbatch -XX:-TieredCompilation T.java ..... 7897 83 % b T::a @ 27 (70 bytes) 7901 84 b T::a (70 bytes) 7902 83 % T::a @ 27 (70 bytes) made not entrant 7903 85 % b T::a @ 47 (70 bytes) 7907 85 % T::a @ 47 (70 bytes) made not entrant 7907 86 % b T::a @ 27 (70 bytes) 7912 84 T::a (70 bytes) made not entrant 7912 87 % b T::a @ 47 (70 bytes) 7918 88 b T::a (70 bytes) 8164 89 % b T::p @ 5 (14 bytes)# A fatal error has been detected by the Java Runtime Environment: # Internal Error (/home/emanuel/Documents/fork4-jdk/open/src/hotspot/share/opto/loopnode.cpp:2851), pid=152451, tid=152464 # assert(false) failed: should be able to adjust outer loop
20-09-2022
[~roland] This test case fails since the introduction of loop strip mining in JDK 10 (JDK-8186027), could you please have a look? Thanks!
20-09-2022
ILW = assertion failure in debug build (no failure observed in release build); reported once since JDK 10 release; disable loop strip mining (-XX:LoopStripMiningIter=0) or compilation of affected method = MLM = P4
20-09-2022
The assertion fails for this test case since its introduction by JDK-8186027 in JDK 10.
20-09-2022
The failure can also be observed in JDK 18 using -Xbatch -XX:-TieredCompilation to enforce a more deterministic compilation sequence.
19-09-2022
Issue is reproduced on fastdebug builds. Crash is observed on JDK 11,17,19 and 20, however crash is not observed on JDK 18 OS: Windows 10 jdk 11.0.16 : Fail jdk 11.0.16.1 : Fail jdk 18ea10 : Fail jdk 18ea11 : Pass jdk 18.0.2.1 : Pass jdk 19ea36 : Fail jdk 19.0.1 : Fail jdk 20ea15 : Fail ILW = assertion failure in debug JDK(regression in 19,20), reproducible with single test , no workaround available = HLM = P3 Moving it to dev team for further analysis.
19-09-2022