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

Roland Westrelin roland at openjdk.org
Mon Dec 1 15:50:41 UTC 2025


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    160032         0         0         0         0         0         0         0         0         0         0         0
        regAllocSplit               4189544     32728   4156816         0         0         0         0         0         0         0         0         0         0
        postAllocCopyRemoval          65456         0     65456         0         0         0         0         0         0         0         0         0         0
        fixupSpills                   32728         0     32728         0         0         0         0         0         0         0         0         0         0
        chaitinCoalesce1            1505808    262144   1243664         0         0         0         0         0         0         0         0         0         0
        output                    138300376 138300376         0         0         0         0         0         0         0         0         0         0         0
        shorten branches             360008    196368    163640         0         0         0         0         0         0         0         0         0         0


The noticeable line is:


        idealLoop                 918189632         0  38687056 872824784    392776         0         0         0         0         0   6285016         0         0


A lot of memory (almost 1 GB) gets allocated in the `comp` arena
during `idealLoop`. So even though the compilation goes over the limit
in `Compile::Code_Gen()`, the root cause is what happens earlier,
during `idealLoop`.

`_loop_or_ctrl` and `_body` are both allocated in the `comp`
arena. Accumulated over several loop opts pass, they should not use
that much memory but the test is run with `+VerifyLoopOptimizations`:
calls to `PhaseIdealLoop::verify()` cause new `PhaseIdealLoop` objects
to be allocated and more memory to be used in the `comp` arena. The
fix I propose is to allocate `_loop_or_ctrl` and `_body` in a
dedicated `ResourceArea` so memory can be reclaimed when a pass of
loop opts is over.

With that change:


Total Usage: 227682272 
    --- Arena Usage by Arena Type and compilation phase, at arena usage peak of 227682272 ---
        idealLoop                  52278416         0  38687056   6913568         0    392776         0         0         0         0         0   6285016         0         0


that is ~50MB total for `idealLoop` instead of almost 1GB. Total usage
peaks around 200MB.

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

Commit messages:
 - whitespaces
 - more
 - test case
 - more
 - clean up
 - fix

Changes: https://git.openjdk.org/jdk/pull/28581/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28581&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370519
  Stats: 345 lines in 6 files changed: 341 ins; 1 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28581.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28581/head:pull/28581

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


More information about the hotspot-dev mailing list