JDK-8270307 : C2: assert(false) failed: bad AD file after JDK-8267687
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,18
  • Priority: P2
  • Status: Closed
  • Resolution: Fixed
  • Submitted: 2021-07-12
  • Updated: 2021-09-07
  • Resolved: 2021-07-20
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 17 JDK 18
17 b32Fixed 18Fixed
Related Reports
Relates :  
JDK-8267687 - ModXNode::Ideal optimization is better than Parse::do_irem
Relates :  
JDK-8252372 - Check if cloning is required to move loads out of loops in PhaseIdealLoop::split_if_with_blocks_post()
Description
Bisection shows that the attached Fuzzer test starts to fail after JDK-8267687. Note it reproduces even with JDK-8268883 that is both in JDK 17 and already merged to JDK 18 master. 

Unpack and run:
$ ../build/linux-x86_64-server-fastdebug/images/jdk/bin/java -Xmx512m -Xcomp -XX:-TieredCompilation -XX:CompileOnly=Test Test

Default case invoked for: 
   opcode  = 114, "Con"
o1  Con  === o0  [[]]  #top

--N: o1  Con  === o0  [[]]  #top

# To suppress the following error report, specify this argument
# after -XX: or in .hotspotrc:  SuppressErrorAt=/matcher.cpp:1681
#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk/src/hotspot/share/opto/matcher.cpp:1681), pid=999395, tid=999408
#  assert(false) failed: bad AD file
Comments
Changeset: 0cec11d3 Author: Yi Yang <yyang@openjdk.org> Date: 2021-07-20 06:10:58 +0000 URL: https://git.openjdk.java.net/jdk17/commit/0cec11d3eb7393b76dbe1fbfe55a5f363824c1c4
20-07-2021
Fix request for JDK 17 is approved.
19-07-2021
[~yyang] My comment about JDK-8252372 was only for information purpose to where I could trace this bug back to (JDK-8252372) because you mentioned it fails even before JDK-8267687.
19-07-2021
I've created a PR that targeting to JDK 17. Thanks [~kvn] for the kind reminder.
19-07-2021
[~yyang] You don't need to show fix in request. Instead, please file PR for JDK 17. Usually request is done after changes are reviewed already. I added label with "nmi” = “needs more information” to wait PR reviews. Based on the fix the issue is old. And fix is simple and safe. I will approve it after PT for JDK 17 is filed and reviewed.
19-07-2021
Well, do you mean TestCMoveHasTopInput can not pass with JDK-8252372? I tested it locally and it passed w/o any problems after applying the proposed fix(linux_x64_slowdebug and linux_x64_release). TestCMoveHasTopInput is extracted from generated fuzzer test, they behave the same, and hit the same assertions. So they should point to the same problem.
19-07-2021
Attached test to the review starts to fail after JDK-8252372 but it seems to have just revealed a missing case.
16-07-2021
Fix Request: I think this is irrelevant to JDK-8267687, the following minimal test crashed in same assertion regardless of whether applying JDK-8267687 or not: public class TestCMoveHasTopInput { public static boolean arr[] = new boolean[20]; public void vMeth(long l) { for (int a = 2; a < 155; a++) { for (int b = 1; b < 10; ++b) { for (int c = 1; c < 2; c++) { l += 3 * l; arr[b - 1] = false; switch (a) { case 14: case 17: l -= b; break; } } } } } public static void main(String... args) { TestCMoveHasTopInput test = new TestCMoveHasTopInput(); for (int i = 0; i < 10; i++) { test.vMeth(i); } } } As [~chagedorn] evaluated, this is a P2 bug, which is somewhat important. We'd better fix it if we can.. As far as I see, the reason is that one input of ConvI2L becomes Top, which causes all nodes in the chain becoming Top, but this CMoveLNode does not change, only its input becomes Top. This CMoveLNode(CMove Binary(.. ..) (Binary .. Con#Top)) can not match any rules in the instruction selection phase and finally hits the assert. Proposed fix is: diff --git a/src/hotspot/share/opto/movenode.cpp b/src/hotspot/share/opto/movenode.cpp index f9b887c3173e..d7b445ea7687 100644 --- a/src/hotspot/share/opto/movenode.cpp +++ b/src/hotspot/share/opto/movenode.cpp @@ -155,6 +155,9 @@ const Type* CMoveNode::Value(PhaseGVN* phase) const { if (phase->type(in(Condition)) == Type::TOP) { return Type::TOP; } + if (phase->type(in(IfTrue)) == Type::TOP || phase->type(in(IfFalse)) == Type::TOP) { + return Type::TOP; + } const Type* t = phase->type(in(IfFalse))->meet_speculative(phase->type(in(IfTrue))); return t->filter(_type); } This fix should not bring too much risk since it disables further optimizations if inputs of CMoveNode are type of Top. Test passed under: - test/hotspot/jtreg/compiler/c2 - github presubmit tests - attached fuzzer test - TestCMoveHasTopInput I'm new to C2, not sure if it's a reasonable fix, looking forward to having more experts' comments about this.
16-07-2021
Hi [~yyang], please also provide a risk estimate and what testing you performed. You also need to add the jdk17-fix-request label as stated in https://openjdk.java.net/jeps/3#Fix-Request-Process.
16-07-2021
Okay, thanks for your quick response and the analysis! You still got time to fix it in RDP 2 with approval as it's a P2 (so you can enjoy your day off). Just wanted to give you a heads-up :-)
13-07-2021
Hi [~chagedorn], I've started it just now (I'm on vacation today). It seems that -XX:-SuperWordLoopUnrollAnalysis could suppress this crash, but it's a workaround. I just give a quick investigation, it looks that one input of CMoveL(created(cloned) within PhaseIdealLoop::insert_post_loop) is transformed to Con#Top during IGVN after loop unrolling, which finally leads to a crash.
13-07-2021
Hi [~yyang], I know it was only filed/assigned to you yesterday but do you already have an update about this bug? I just wanted to let you know that RDP 2 starts on Thursday. This means that you require an approval to fix it during that phase [1]. If you plan to defer it, it already requires an approval in the current RDP 1 phase since it's a P2 [2]. [1] https://openjdk.java.net/jeps/3#rdp-2 [2] https://openjdk.java.net/jeps/3#rdp-1
13-07-2021
ILW = C2 assertion in matcher (recent regression in JDK 17 b26), with single Java Fuzzer test only, disable compilation of affected method = HMM = P2 [~yyang] can you take a look at it? Is this somehow related to JDK-8268883?
12-07-2021