RFR: 8357471: GenShen: Share collector reserves between young and old [v29]

[William Kemper]

On Sun, 11 Jan 2026 03:08:48 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Genshen independently reserves memory to hold evacuations into young and old generations.  We have found that under duress, it is sometimes difficult for mixed evacuations to make progress because the reserves in old are too small and we cannot expand old because young is running so frequently that it does not have the excess memory required to justify expansion of old (and shrinking of young).
>> 
>> This PR exploits the fact that the reserves in young are often much larger than young requires to carry out its anticipated next GC cycle.  In this case, we can share the young collector reserves with the old generation.  This allows much more effective operation of mixed evacuations when GC is running at or near its full capacity.
>> 
>> The following spreadsheet snapshots highlight the benefits of this change.  In control with 6G heap size, we perform large numbers of mixed evacuations, but each mixed evacuation has very low productivity (e.g. one region at a time).  This causes excessive delays in reclaiming the garbage from old, which is required to shrink old and expand young.  This is why we see the large number of unproductive GC cycles, many of which degenerate and a few of which upgrade to full GC.  In the experiment with 6G heap size, there are far fewer mixed cycles, but they are each much more productive.  The total number of GC cycles decreases significantly.
>> 
>> ![image](https://github.com/user-attachments/assets/782f7285-2b26-4f3b-ba3e-58465abb2c3a)
>> 
>> With 7G heap size, the benefits of this PR manifest as a decrease in mixed evacuations, which also allows us to decrease total GC cycles.  By more quickly reclaiming old garbage, we are able to more quickly expand young, which decreases the number of young GC cycles.  This reduces CPU load.  The impact on response times is not as significant as with the 6G heap size.  We see slight improvement at p50-p99.9, with slight degradation at p99.99 through p100.
>> 
>> ![image](https://github.com/user-attachments/assets/54fb5eae-2ae8-4679-ac78-c88bc5c16c2f)
>> 
>> At 8G heap size, the GC is not at all stressed.  We see approximately the same numbers of GC cycles, slight degradation of response times at p50-p99, slight improvement in response times at p99.9-p100.
>> 
>> ![image](https://github.com/user-attachments/assets/50a48564-7f32-4c48-80e9-78e9a3a3d63c)
>> 
>> The command line for these comparisons follows:
>> 
>> 
>>             ~/github/jdk.share-collector-reserves/build/linux-x86_64-server-release/images/jd...
>
> Kelvin Nilsen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 86 commits:
> 
>  - Merge remote-tracking branch 'jdk/master' into share-collector-reserves
>  - Move rebuild free set earlier in an abbreviated GC cycle
>  - Restore deleted assert statement
>  - Move special handling into ShenandoahYoungHeuristics::choose_collection_set_from_regiondata()
>  - fix another typo
>  - Fix typo
>  - Fix confusing comment
>  - Add comment
>  - Merge remote-tracking branch 'jdk/master' into share-collector-reserves
>  - Fix whitespace and comment
>  - ... and 76 more: https://git.openjdk.org/jdk/compare/659b53fe...27ece3e8

src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 71:

> 69: ShenandoahAdaptiveHeuristics::~ShenandoahAdaptiveHeuristics() {}
> 70: 
> 71: size_t ShenandoahAdaptiveHeuristics::choose_collection_set_from_regiondata(ShenandoahCollectionSet* cset,

It would be nice if we didn't need to change this API for every heuristic just to support the mixed evacuation case. It is perhaps not in scope for an already huge PR, but I think we should move `ShenandoahGeneration::compute_evacuation_budgets` and `ShenandoahGeneration::adjust_evacuation_budgets` into `ShenandoahGenerationalHeuristic`. Logically, both these methods are involved in choosing the collection set and both are only used in the generational mode. I think it's fine to defer this refactoring to another PR. It's hard for me to accept that a change such as this would touch 41 files. It seems we do not have the right abstractions or encapsulations here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25357#discussion_r2688445439