RFR: Expand old on demand [v42]

[Kelvin Nilsen]

On Thu, 11 May 2023 22:25:22 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix whitespace
>
> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 332:
> 
>> 330: 
>> 331: // Return conservative estimate of how much memory can be allocated before we need to start GC
>> 332: size_t ShenandoahAdaptiveHeuristics::evac_slack(size_t young_regions_to_be_reclaimed) {
> 
> I don't understand the dimension of time or allocation rate in this function. The heuristic uses this formula to predict _when_ memory will be exhausted. If you just need to know how much memory is available, less any penalties are spike tolerance, then this could be much simpler.

It's not strictly just the amount of memory available.  It's the amount of memory that can be allocated before the next GC trigger.  The next GC trigger is supposed to happen with enough additional allocation runway that we can finish that GC before the runway is exhausted.  I'm changing the name of the function and adding some comments to hopefully make all of this more clear.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahAdaptiveHeuristics.cpp line 560:
> 
>> 558:                      proper_unit_for_byte_size(promo_in_place_potential));
>> 559:         return true;
>> 560:       } else if (mixed_candidates > 0) {
> 
> This will basically run mixed evacuations back to back until they're finished... is that what we want? It seems aggressive.

Yes.  I think it's what we want.  It's basically our "compensation" for the fact that we do not have a truly concurrent old-gen collector.  If the old-collector threads were concurrent, they would be consuming all available idle cycles to take care of the mixed evacuations.

Certainly, this is an area that we can experiment with and auto-tune if appropriate.  My experiments with Phased-Updates workload suggested that if we have a bunch of mixed evacuation work to be done, we want to get it done as possible.  Otherwise, we can get caught flat footed if mutator demand for new allocations spikes.

> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 411:
> 
>> 409:   if (_cannot_expand_trigger) {
>> 410:     ShenandoahHeap* heap = ShenandoahHeap::heap();
>> 411:     ShenandoahOldGeneration* old_gen = heap->old_generation();
> 
> This class holds a pointer to the old generation in `_old_generation` - can skip the `ShenandoahHeap::heap()->old_generation()` calls.

Thanks.  Replacing throughout.

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

PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1205927683
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1205930119
PR Review Comment: https://git.openjdk.org/shenandoah/pull/248#discussion_r1205934980