RFR: 8373225: GenShen: More adaptive old-generation growth heuristics [v3]

[Kelvin Nilsen]

On Tue, 9 Dec 2025 03:12:37 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> When old-gen consumes a small percentage of heap size, trigger when old-gen expands by more than ShenandoahMinOldGenGrowthPercent, with default value 50%, from the live data in old at time of previous old-gen mark.
>> 
>> When old-gen consumes a larger percentage of heap size, we trigger when old-gen expands by more than  ShenandoahMinOldGenGrowthRemainingHeapPercent, with default value 25%, of the memory not live in old at the last marking of old.
>
> Kelvin Nilsen 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 12 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers-gh
>  - Add comment to describe behavior of adjust_old_garbage_threshold()
>  - Simplify representation of growth percentages
>  - Change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - make old evac ratio adaptive
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - change default value of ShenandoahMinOldGenGrowthRemainingHeapPercent
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - Adjust test for new defaults
>  - Merge remote-tracking branch 'jdk/master' into more-adaptive-old-triggers
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/08fdfe16...c7c22974

src/hotspot/share/gc/shenandoah/shenandoahOldGeneration.cpp line 249:

> 247:     _live_bytes_after_last_mark + (_live_bytes_after_last_mark * _growth_percent_before_compaction) / 100;
> 248:   size_t threshold_by_growth_into_percent_remaining = (size_t)
> 249:     (_live_bytes_after_last_mark + ((ShenandoahHeap::heap()->soft_max_capacity() - _live_bytes_after_last_mark)

I need to protect against underflow here.  It might be that _live_bytes_after_last_mark is greater than soft_max_capacity().

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28561#discussion_r2604625802