Integrated: 8360701: Add bailout when the register allocator interference graph grows unreasonably large

[Daniel Lundén]

On Thu, 3 Jul 2025 18:13:13 GMT, Daniel Lundén <dlunden at openjdk.org> wrote:

> The changeset for JDK-8325467 (https://git.openjdk.org/jdk/pull/20404) enables compilation of methods with many parameters, which C2 previously bailed out on. As a side effect, the tests `BigArityTest.java`, `TestCatchExceptionWithVarargs.java`, and `VarargsArrayTest.java` compile more methods than before, and additionally these methods are designed, for stress testing purposes, to have a large number of parameters (at or close to the maximum of 255 parameters allowed by the JVM spec).
> 
> Compiling such methods takes a very long time and >99% of the time is spent in the C2 phase Coalesce 2 (part of register allocation). The problem is that the interference graph becomes huge after the initial round of spilling (just before Coalesce 2), and that we do not check for this and bail out if necessary. We do already bail out if the number of IR nodes grows too large, but the interference graph can become huge even if we have a small number of nodes. In fact, the interference graph may (in the worst case) hava a size that is quadratic in the number of nodes. In the problematic tests, we have interference graphs with approximately 100 000 nodes and over 55 000 000 (!) IFG edges. For comparison, the IFG edge count in worst-case realistic scenarios caps out at around 40 000 nodes and 800 000 edges. For example, see the scatter matrix below from running the DaCapo benchmark. It displays, for each time an IFG was built, the number of current IR nodes, the number of live ranges (
 the actual nodes in the IFG), and the number of IFG edges.
> 
> ![dacapo](https://github.com/user-attachments/assets/7a070768-50da-42e4-b5ed-9958e1362673)
> 
> ### Changeset
> 
> - Add a new diagnostic flag `IFGEdgesLimit` and bail out whenever we reach the number of edges specified by the flag during IFG construction. The default is a very generous 10 000 000 edges, that still filters out the most degenerate compilations we have seen.
> - Add tracking of edges in `PhaseIFG` to permit the new flag.
> 
> It is worth noting that it is perhaps preferable to use a lower default than 10 000 000 edges. For example, in standard benchmarks such as DaCapo (see the scatter matrix above), Renaissance, SPECjvm, and SPECjbb, we never go over 1 000 000 edges (I verified this). The reason I went with the generous 10 000 000 limit is that I saw a fair amount of bailouts in testing with the flag set at 1 000 000 edges. Such bailouts are likely motivated, but I do not want to take any chances. Even at 10 000 000 edges, a few tests s...

This pull request has now been integrated.

Changeset: 820263e4
Author:    Daniel Lundén <dlunden at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/820263e48abf3ddce9506eb19872871aa3ea8b50
Stats:     38 lines in 4 files changed: 37 ins; 0 del; 1 mod

8360701: Add bailout when the register allocator interference graph grows unreasonably large

Reviewed-by: mhaessig, thartmann

-------------

PR: https://git.openjdk.org/jdk/pull/26118