RFR: 8308103: Massive (up to ~30x) increase in C2 compilation time since JDK 17

[Christian Hagedorn]

On Fri, 30 Jun 2023 13:23:38 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> A long chain of nodes are sunk out of a loop. Every time a node is
> moved out of the loop, a cast is created to pin the node out of the
> loop. When its input is next sunk, the cast is removed (the cast is
> replaced by its input) and a new cast is created. Some nodes on the
> chain have 2 other nodes in the chain as uses. When such a node is
> sunk, 2 cast nodes are created, one for each use. So as the compiler
> moves forward in the chain, the number of cast to remove grows. From
> some profiling, removing those casts is what takes a lot of time.
> 
> The fix I propose is, when a node is processed, to check whether a
> cast at the out of loop control was already created for that node and
> to reuse it.
> 
> The test case takes 6 minutes when I run it without the fix and 3
> seconds with it.

test/hotspot/jtreg/compiler/loopopts/TestSinkingNodesCausesLongCompilation.java line 28:

> 26:  * @bug 8308103
> 27:  * @summary Massive (up to ~30x) increase in C2 compilation time since JDK 17
> 28:  * @run main/othervm -Xcomp -XX:CompileOnly=TestSinkingNodesCausesLongCompilation::mainTest -XX:RepeatCompilation=30 TestSinkingNodesCausesLongCompilation

You should add `-XX:+UnlockDiagnosticVMOptions` since `RepeatCompilation` is diagnostic.

test/hotspot/jtreg/compiler/loopopts/TestSinkingNodesCausesLongCompilation.java line 58:

> 56:     public static void main(String[] strArr) {
> 57:         TestSinkingNodesCausesLongCompilation _instance = new TestSinkingNodesCausesLongCompilation();
> 58:         for (int i = 0; i < 10; i++ ) {

Suggestion:

        for (int i = 0; i < 10; i++) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14732#discussion_r1250290774
PR Review Comment: https://git.openjdk.org/jdk/pull/14732#discussion_r1250291448