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

[Guoxiong Li]

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/psAdaptiveSizePolicy.cpp line 232:

> 230:     // Major times are too long, so we want less promotion.
> 231:     incr_tenuring_threshold = true;
> 232:   }

You keep the condition `minor_cost > major_cost * _threshold_tolerance_percent` of the previous code. But it will be strange when we only read the new code (in the future). What about removing the condition `minor_cost > major_cost * _threshold_tolerance_percent` and moving the comment `we prefer young-gc over full-gc` to another place?

src/hotspot/share/gc/parallel/psAdaptiveSizePolicy.cpp line 254:

> 252:     // survived is an underestimate
> 253:     _survived_bytes.add(survived + promoted);
> 254:   }

The parameter `is_survivor_overflow` seems unnecessary. When `is_survivor_overflow` is `false`, the `promoted` is `0`. What about using `_survived_bytes.add(survived + promoted)` only and removing parameter `is_survivor_overflow` (and the related conditional code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094533246
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2094536061