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-compiler-dev
mailing list