RFR: 8357471: GenShen: Share collector reserves between young and old

[Kelvin Nilsen]

On Wed, 21 May 2025 17:54:12 GMT, William Kemper <wkemper 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...
>
> src/hotspot/share/gc/shenandoah/shenandoahGenerationSizer.cpp line 206:
> 
>> 204:   old_gen->decrease_capacity(bytes_to_transfer);
>> 205:   const size_t new_size = young_gen->max_capacity();
>> 206:   log_info(gc)("Forcing transfer of %zu region(s) from %s to %s, yielding increased size: " PROPERFMT,
> 
> Can this be `gc, ergo` like the method to transfer regions to old?

Agreed.  Making this change.

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

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