RFR: 8370519: C2: Hit MemLimit when running with +VerifyLoopOptimizations

[Manuel Hässig]

On Mon, 1 Dec 2025 15:40:00 GMT, Roland Westrelin <roland at openjdk.org> wrote:

> For this failure memory stats are:
> 
> 
> Total Usage: 1095525816 
>     --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 1095525816 ---
>         Phase                         Total        ra      node      comp      type    states   reglive  regsplit   regmask superword     cienv        ha     other
>         none                        5976032    331560   5402064    197512     33712     10200         0         0       984         0         0         0         0
>         parse                       2716464     65456   1145480    196408   1112752         0         0         0         0         0    196368         0         0
>         optimizer                     98184         0     32728         0     65456         0         0         0         0         0         0         0         0
>         connectionGraph               32728         0         0     32728         0         0         0         0         0         0         0         0         0
>         iterGVN                       32728         0     32728         0         0         0         0         0         0         0         0         0         0
>         idealLoop                 918189632         0  38687056 872824784    392776         0         0         0         0         0   6285016         0         0
>         idealLoopVerify             2228144         0         0   2228144         0         0         0         0         0         0         0         0         0
>         macroExpand                   32728         0     32728         0         0         0         0         0         0         0         0         0         0
>         graphReshape                  32728         0     32728         0         0         0         0         0         0         0         0         0         0
>         matcher                    20135944   3369848   9033208   7536400     65456    131032         0         0         0         0         0         0         0
>         postselect_cleanup           294872    294872         0         0         0         0         0         0         0         0         0         0         0
>         scheduler                    752944    196488    556456         0         0         0         0         0         0         0         0         0         0
>         regalloc                     388736    388736         0         0         0         0         0         0         0         0         0         0         0
>         ctorChaitin                  160032    ...

Thank you for fixing this, @rwestrel. Your fix looks good to me. I merely have two nitpicky suggestions.
I will kick off a run of testing and report back with the results.

src/hotspot/share/opto/compile.hpp line 374:

> 372:   // Compilation environment.
> 373:   Arena                 _comp_arena;            // Arena with lifetime equivalent to Compile
> 374:   ResourceArea          _idealloop_arena;       // For data whose lifetime is a pass of loop optimizations

Suggestion:

  ResourceArea          _idealloop_arena;       // For data whose lifetime is a single pass of loop optimizations
``` 
Nit: This makes it abundantly clear that the data is freed after one pass.

test/hotspot/jtreg/compiler/c2/TestVerifyLoopOptimizationsHighMemUsage.java line 27:

> 25:  * @test
> 26:  * @bug 8370519
> 27:  * @summary C2: Hit MemLimit when running with +VerifyLoopOptimizations

Unsure, but would this test qualify for `@key stress`?

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

PR Review: https://git.openjdk.org/jdk/pull/28581#pullrequestreview-3525793585
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577699466
PR Review Comment: https://git.openjdk.org/jdk/pull/28581#discussion_r2577714828