JDK-8237950 : C2 compilation fails with "Live Node limit exceeded limit" during ConvI2L::Ideal optimization
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 11,12,13,14,15
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2020-01-28
  • Updated: 2024-10-17
  • Resolved: 2020-06-19
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 15 JDK 16
11.0.10-oracleFixed 13.0.7Fixed 15 b29Fixed 16Fixed
Related Reports
Relates :  
JDK-8254317 - C2: Resource consumption of ConvI2LNode::Ideal() grows exponentially
Relates :  
JDK-8253404 - C2: assert(C->live_nodes() <= C->max_node_limit()) failed: Live Node limit exceeded limit
Relates :  
JDK-8244724 - CTW: C2 compilation fails with "Live Node limit exceeded limit"
Description
$ cd test/hotspot/jtreg/testlibrary/ctw
$ make
$ cd dist
$ wget https://repo1.maven.org/maven2/com/sun/xml/bind/jaxb1-impl/2.2-promoted-b9/jaxb1-impl-2.2-promoted-b9.jar
$ ./ctw.sh jaxb1-impl-2.2-promoted-b9.jar 

# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/shade/trunks/jdk-jdk/src/hotspot/share/opto/node.cpp:83), pid=15739, tid=15773
#  assert(Compile::current()->live_nodes() < Compile::current()->max_node_limit()) failed: Live Node limit exceeded limit
#
# JRE version: OpenJDK Runtime Environment (15.0) (fastdebug build 15-internal+0-adhoc.shade.jdk-jdk)
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 15-internal+0-adhoc.shade.jdk-jdk, mixed mode, sharing, tiered, compressed oops, g1 gc, linux-amd64)
Comments
Fix request (13u) on behalf of Ilarion Nakonechnyy: I'd like to port it to 13u, too. Applies clean, tier1 and specific test runs OK.
19-03-2021
Fix request (11u) -- will label after testing completed. I would like to downport this for parity with 11.0.10-oracle. Applies clean.
01-09-2020
Changeset: 326ba317 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-06-19 11:32:51 +0000 URL: https://git.openjdk.java.net/lanai/commit/326ba317
02-07-2020
Changeset: 326ba317 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-06-19 11:32:51 +0000 URL: https://git.openjdk.java.net/panama-foreign/commit/326ba317
02-07-2020
Changeset: 326ba317 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-06-19 11:32:51 +0000 URL: https://git.openjdk.java.net/amber/commit/326ba317
02-07-2020
Changeset: 326ba317 Author: Tobias Hartmann <thartmann@openjdk.org> Date: 2020-06-19 11:32:51 +0000 URL: https://git.openjdk.java.net/mobile/commit/326ba317
02-07-2020
URL: https://hg.openjdk.java.net/jdk/jdk15/rev/6132f62c131d User: thartmann Date: 2020-06-19 09:33:34 +0000
19-06-2020
http://cr.openjdk.java.net/~thartmann/8237950/webrev.01/
18-06-2020
A long chain of StringBuffer.append calls is optimized by C2's string concatenation optimization which emits direct stores into the String internal byte array. GraphKit::array_element_address emits ConvI2L nodes for the array index (see Compile::conv_I2X_index) without any range check dependent CastII nodes because the bounds are known. As a result, the ConvI2L ideal optimization jumps in and creates over 34000 new ConvI2L nodes while pushing them through the long chain of AddNodes. We hit the node limit because during GVN, dead nodes are not removed. I propose to simply postpone that optimization to IGVN. This only affects array accesses emitted for the string concat optimizations because "normal" array accesses have a range check dependent CastII which blocks that ConvI2L optimization during parsing: http://cr.openjdk.java.net/~thartmann/8237950/webrev.00/
15-06-2020
From the log this looks like an infinite loop. V [libjvm.so+0x1219cb4] Node::verify_construction()+0x144 V [libjvm.so+0x121e7fd] Node::Node(Node*, Node*, Node*)+0x3d V [libjvm.so+0x8c7d11] ConvI2LNode::Ideal(PhaseGVN*, bool)+0x10b1 V [libjvm.so+0x132623c] PhaseGVN::transform_no_reclaim(Node*)+0x7c V [libjvm.so+0x8c7186] ConvI2LNode::Ideal(PhaseGVN*, bool)+0x526 V [libjvm.so+0x132623c] PhaseGVN::transform_no_reclaim(Node*)+0x7c Possible suspects in JDK-8177095 and JDK-8217359. A quick look in the debugger says it's not an endless loop, but bunch of very large expression trees from StringOpts (that have not been constant folded). The above mentioned patches adds to the "node explosion" (but don't seem to be the root of the problem).
27-05-2020