[crac] RFR: 8362418: [CRaC] Leave unused G1 heap regions committed for C/R

[Radim Vansa]

On Wed, 16 Jul 2025 13:56:07 GMT, Timofei Pushkin <tpushkin at openjdk.org> wrote:

> See the JBS issue for the problem statement and the suggested approach to fix it.
> 
> This PR:
> 1. Implements the approach by expanding G1 heap back after shrinking and uncommitting it: shrink+uncommit makes memory in  free regions uncommitted, expand commits it back.
> 2. Removes `CollectedHeap::finish_collection()` added in #93 because it was only used in G1 to synchronize uncommitting with C/R but now uncommitting is performed synchronously during the CRaC-invoked full GC, i.e. it became redundant.
> 3. Renames `CollectedHeap::do_cleanup_unused()` to `CollectedHeap::should_cleanup_unused()` because I find the old name unintuitive: it sounds like the method _does_ the actual work while in reality it just returns whether the work _should_ be done.
> 
> Notes:
> - If `-XX:+AlwaysPreTouch` is used (not the default) the cleaned-up pages will become OS-reserved again immediately which means that if the C/R engine saves such memory into the image the image size will become larger after this change than it was before. This is OK since it is off by default and some engines can handle pre-touched pages without fully saving them into the image.
> - G1 heap still gets shrunk during C/R because of the automatic shrinking. But it is less aggressive as before which is enough not to cause immediate full/mixed GCs in my testing. The user can also set `MaxHeapFreeRatio` to a larger value during C/R to reduce the shrinking (or even disable it completely) if needed — that was not possible before.
> 
> I used a benchmark based on wrk and Helidon's hello-world example to check if there are any performance gains. On JDK 25+14 I saw a 2–3% improvement for the first after-restore iteration performance (before there was a ~4% regression in last-before-checkpoint iteration vs first-after-restore iteration — it became ~1.4%) and a 20% start-up speed-up (100ms vs 80ms). However, between 25+14 and 25+18 there has been some change made that improved the baseline performance to roughly the same level, so the improvement brought by my fix became almost unnoticeable on this particular benchmark on JDK 25+18.
> 
> But in GC logs it is clear that less work is performed on restore so I still believe the change is beneficial:
> 
> <details>
> 
> <summary>W/o the change</summary>
> 
> The heap is shrunk from 252MB to 4MB and preparations for mixed GC are performed. Sometimes (but not this time) mixed GCs themselves occur, on 25+14 there were full GCs even.
> 
> 
> [1752668313926ms] ################# benchmark before C/R start  #####...

LGTM; I also totally agree with the renaming.

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

Marked as reviewed by rvansa (Committer).

PR Review: https://git.openjdk.org/crac/pull/243#pullrequestreview-3032525066