RFR: 8367708: GenShen: Reduce total evacuation burden [v3]

[Y. Srinivas Ramakrishna]

On Tue, 16 Sep 2025 19:41:47 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> This PR provides several improvements that cumulatively reduce the amount of evacuation performed by GenShen compared to traditional Shenandoah. Specifically:
>> 
>> 1. Do not promote humongous arrays of primitive data.  Leaving these regions in the young generation allows them to be reclaimed more quickly when they become garbage.  There is no disadvantage to leaving these regions in the young generation as their contents does not need to be scanned by the garbage collector.
>> 2. Change the default value of ShenandoahOldGarbageThreshold from 15% to 25%.  This results in smaller sets of candidate regions for mixed evacuation, less aggressive compaction of old generation.  This also increases the likelihood that a region will be promoted in place instead of promoted by evacuation.
>> 3. Only promote regions in place if the used within a region exceeds ShenandoahGenerationalMinPIPUsage (default 30) percent of the heap region size.  This is enforced in combination with the preexisting requirement that the garbage within the region be less than ShenandoahOldGarbageThreshold (new default 25) percent of the heap region size.  This causes regions with very low utilization to be promoted by evacuation rather than promoted in place.  While the immediate effect of this change is to perform more copying when the region is promoted, the secondary effect is that this region does not need to be evacuated at a later time, after it has accumulated more live data, as part of an effort to defragment old-gen memory.
>> 4. Only defragment old-gen memory if the command-line has requested non-zero reserves for humongous objects (ShenandoahGenerationalHumongousReserves).  Previously, we would invest in defragmenting old-gen memory every time we finished old-generation marking, even if ShenandoahGenerationalHumongousReserves equals zero.
>
> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert changes to trash_humongous_region_at()

src/hotspot/share/gc/shenandoah/shenandoah_globals.hpp line 37:

> 35:                             constraint)                                     \
> 36:                                                                             \
> 37:   product(uintx, ShenandoahGenerationalMinPIPUsage, 30, EXPERIMENTAL,       \

Looking at this quite late, but thought I'd leave these comments here nonetheless.

While I agree that copying takes up cycle time and cpu, there is a potential space cost to promoting in place regions with substantial garbage. Why was 30% used (i.e. 70% garbage) considered reasonable? I'd have expected something like 50 or a tad higher used (i.e. less than 50% garbage) to be eligible for PIP.

Did higher values not work well for specific benchmarks that were used to pick this threshold?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27278#discussion_r2361276332