RFR: 8353115: GenShen: mixed evacuation candidate regions need accurate live_data [v7]

[Kelvin Nilsen]

On Mon, 14 Apr 2025 16:38:03 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> i suspect performance impact is minimal.
>
> I've committed changes that endeavor to implement the suggested refactor.  Performance impact does appear to be minimal.  This broader refactoring does change behavior slightly.  In particular:
> 
> 1. We now have a better understanding of live-memory evacuated during mixed evacuations.  This allows the selection of old-candidates for mixed evacuations to be more conservative.  We'll have fewer old regions in order to honor the intended budget.
> 2. Potentially, this will result in more mixed evacuations, but each mixed evacuation should take less time.
> 3. There should be no impact on behavior of traditional Shenandoah.
> 
> On one recently completed test run, we observed the following impacts compared to tip:
> Shenandoah
> -------------------------------------------------------------------------------------------------------
> +80.69% specjbb2015/trigger_failure p=0.00000
>   Control:     58.250   (+/- 13.48  )        110
>   Test:       105.250   (+/- 33.13  )         30
> 
> 
> Genshen
> -------------------------------------------------------------------------------------------------------
> -19.46% jme/context_switch_count p=0.00176
>   Control:    117.420   (+/- 28.01  )        108
>   Test:        98.292   (+/- 32.76  )         30
> 
> Perhaps we need more data to decide whether this is "significant".

This result seems to be consistent.  The effect on traditional Shenandoah is apparently to reduce the size of traditional Shenandoah collection sets also because certain regions that would have been collected are now rejected due to "better awareness" of how much live data will need to be copied.  The amount of garbage associated with candidate regions for the young collection set is reduced by the amount of allocations above TAMS. 
 Previously, this had been erroneously reported as garbage.  This has the effect of delaying reclamation of some garbage, resulting in an increase in allocation failures on the specjbb 2025 workload.

We might argue that the original behavior was incorrect, in that it was allowing violation of the intended evacuation budget.

We apparently were getting away with this violation because we were able to flip mutator regions to collector space, and/or because evacuation waste was sufficient to accommodate the unbudgeted evacuations.

Now that we have more accurate accounting of live memory, we could perhaps slightly reduce the default evacuation waste budget if we want to claw back the losses in specjbb performance (to enable larger collection sets) as part of this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24319#discussion_r2102870209