JDK-8362394 : C2: Repeated stacked string concatenation fails with "Hit MemLimit" and other resourcing errors
  • Type: Bug
  • Component: hotspot
  • Sub-Component: compiler
  • Affected Version: 17,25
  • Priority: P3
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2025-07-16
  • Updated: 2025-08-12
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 26
26Unresolved
Related Reports
Relates :  
Description
C2: String concatenation optimization fails with "Hit MemLimit". If we disable this limit, it hits another error: "assert(req < Compile::current()->max_node_limit() - NodeLimitFudgeFactor) failed: Input limit exceeded"

In product, the test seems to hang.

Code pattern:
[...]
        s = new StringBuilder().append(s).append(s).toString();
        s = new StringBuilder().append(s).append(s).toString();
        s = new StringBuilder().append(s).append(s).toString();
        s = new StringBuilder().append(s).append(s).toString();
[..]

===

In TestStackedConcatsMany.java, a string of large size 2^24 is built. But even if half of those concats are removed resulting in a more reasonably sized 2^12 string, there's a later crash:

78          assert(C->live_nodes() <= C->max_node_limit(), "Live Node limit exceeded limit");

#0  src/hotspot/share/opto/node.cpp:78 in Node::verify_construction
[...]
# 7 src/hotspot/share/opto/stringopts.cpp:1558 in PhaseStringOpts::copy_string
# 8 src/hotspot/share/opto/stringopts.cpp:1612 in PhaseStringOpts::replace_string_concat

Less than 1000 live nodes before the call to replace_string_concat turns into 80000+ after.

===

Maybe the optimization needs to be bounded somehow.
Comments
A pull request was submitted for review. Branch: master URL: https://git.openjdk.org/jdk/pull/26685 Date: 2025-08-08 06:10:56 +0000
08-08-2025

The added test triggers another assert JDK-8328078 on aarch64. Can we temporarily disable that assert? Or add the test to problem list on this platform.
07-08-2025

I assume the problem exists since JDK 8 as well since this is not changed that much since JDK 8. I will try to replicate there as well. ==== The problem is in StringConcat::merge method [1] that produces a merged string concatenation link of size (sc size) * (other size). In the attached tests case, this rapidly grows to create concats of size 2 * 2, 2 * 4, ..., 16 * 64, ... and the compilation runs out of memory. The final code produced even without the compilation memory problems is also of poor quality. There will be back to back StoreB -> optimized to StoreL links of arbitrary size -- one or a few for each character in the input string. The pattern from before_itergvn.png is essentially retained until code generation. === The proposed solution in [2] might be pragmatic. [1] https://github.com/openjdk/jdk/blob/9609f57cef684d2f44d3e12a3522811a3c0776f4/src/hotspot/share/opto/stringopts.cpp#L682 [2] https://github.com/openjdk/jdk/compare/master...danielogh:jdk:stringopts-long-compile?expand=1
21-07-2025

Reproduces since JDK-8219555 in JDK 17 for me but I think by adjusting the test it should be easily possible to reproduce with earlier versions as well.
17-07-2025

One approach: https://github.com/openjdk/jdk/compare/master...danielogh:jdk:stringopts-long-compile?expand=1 I'd need to understand the failure case better to have confidence there aren't other failure modes though.
17-07-2025

ILW = Long running / resource exzessive compilation in C2, easy to reproduce but edge case, -XX:-OptimizeStringConcat or exclude method from compilation = HLM = P3
17-07-2025

Also, stringopts time is reported as "parse": C2 Compile Time: 4.205 s Parse: 3.904 s Optimize: 0.064 s Escape Analysis: 0.001 s Conn Graph: 0.001 s Macro Eliminate: 0.001 s Maybe it should be a separate category (could be considered as part of solving this bug, or JDK-8362118)
17-07-2025

For example, <...>/linux-x64-debug/jdk/bin/java -XX:+CITime -Xcomp -XX:CompileOnly=TestStackedConcatsMany::* TestStackedConcatsMany.java
16-07-2025

No problem seen with -XX:-OptimizeStringConcat or C1 compilation There seems to be some algorithmic problems here with repeated stacked string concat and the strings growing quite large. https://github.com/openjdk/jdk/blob/5e4a2ead714814cb4eb90ca88debc226f9c75864/src/hotspot/share/opto/stringopts.cpp#L682 https://github.com/openjdk/jdk/blob/5e4a2ead714814cb4eb90ca88debc226f9c75864/src/hotspot/share/opto/stringopts.cpp#L714 === One possibility is to cancel the compilation or optimization on unreasonably sized inputs.
16-07-2025