RFR: 8338977: Parallel: Improve heap resizing heuristics [v2]

[Zhengyu Gu]

On Fri, 16 May 2025 08:36:22 GMT, Albert Mingkun Yang <ayang at openjdk.org> wrote:

>> This patch refines Parallel's sizing strategy to improve overall memory management and performance.
>> 
>> The young generation layout has been reconfigured from the previous `eden-from/to` arrangement to a new `from/to-eden` order. This new layout facilitates young generation resizing, since we perform resizing after a successful young GC when all live objects are located at the beginning of the young generation. Previously, resizing was often inhibited by live objects residing in the middle of the young generation (from-space). The new layout is illustrated in `parallelScavengeHeap.hpp`.
>> 
>> `NumberSeq` is now used to track various runtime metrics, such as minor/major GC pause durations, promoted/survived bytes after a young GC, highest old generation usage, etc. This tracking primarily lives in `AdaptiveSizePolicy` and its subclass `PSAdaptiveSizePolicy`.
>> 
>> GC overhead checking, which was previously entangled with adaptive resizing logic, has been extracted and is now largely encapsulated in `ParallelScavengeHeap::is_gc_overhead_limit_reached`.
>> 
>> ## Performance evaluation
>> 
>> - SPECjvm2008-Compress shows ~8% improvement on Linux/AArch64 and Linux/x64 (restoring the regression reported in [JDK-8332485](https://bugs.openjdk.org/browse/JDK-8332485) and [JDK-8338689](https://bugs.openjdk.org/browse/JDK-8338689)).
>> - Fixes the surprising behavior when using a non-default (smaller) value of `GCTimeRatio` with Heapothesys/Hyperalloc, as discussed in [this thread](https://mail.openjdk.org/pipermail/hotspot-gc-dev/2024-November/050146.html).
>> - Performance is mostly neutral across other tested benchmarks: **DaCapo**, **SPECjbb2005**, **SPECjbb2015**, **SPECjvm2008**, and **CacheStress**. The number of young-gc sometimes goes up a bit and the total heap-size decreases a bit, because promotion-size-to-old-gen goes down with the more effective eden/survivor-space resizing.
>> 
>> PS: I have opportunistically set the obsolete/expired version to 25/26 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - review
>  - Merge branch 'master' into pgc-size-policy
>  - pgc-size-policy

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 51:

> 49: #include "oops/oop.inline.hpp"
> 50: #include "runtime/cpuTimeCounters.hpp"
> 51: #include "runtime/globals_extension.hpp"

Don't see why it is needed.

src/hotspot/share/gc/parallel/parallelScavengeHeap.cpp line 404:

> 402:     collect_at_safepoint(!should_run_young_gc);
> 403: 
> 404:     if (is_gc_overhead_limit_reached()) {

Maybe want to adopt current algorithm, start to clear soft references when approaching gc overhead limit?
Running a full gc and clearing all soft references without retrying allocation and throws OOM, seems a bit harsh.

People still use soft references for caches, reclaim soft references could potentially free large amount of memory.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2087170321
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2087828140