On Thu, 26 Jun 2025 10:17:13 GMT, Albert Mingkun Yang <ay...@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~~ 
>> 26/27 for now. I will update them accordingly before merging.
>> 
>> Test: tier1-8
>
> Albert Mingkun Yang has updated the pull request incrementally with one 
> additional commit since the last revision:
> 
>   remove-young-resize-after-full-gc

Changes requested by iwalulya (Reviewer).

src/hotspot/share/gc/parallel/psYoungGen.cpp line 305:

> 303:                                                eden_space()->top(),
> 304:                                                sizeof(HeapWord));
> 305:     if (word_size > available_word_size) {

Would it be useful to `log_trace` this situaton?

src/hotspot/share/gc/parallel/psYoungGen.cpp line 321:

> 319: }
> 320: 
> 321: void PSYoungGen::compute_desired_sizes(bool is_survivor_overflowing,

Probably subjective, but as suggested on a recent review, is it easier to read 
if you returned the results in a Pair<size_t, size_t>?

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

PR Review: https://git.openjdk.org/jdk/pull/25000#pullrequestreview-2950871762
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169356093
PR Review Comment: https://git.openjdk.org/jdk/pull/25000#discussion_r2169350754

Reply via email to