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 attached scatter matrix (dacapo.png) 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.