RFR: Generation resizing [v3]

[Y. Srinivas Ramakrishna]

On Thu, 8 Dec 2022 09:17:51 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> William Kemper has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove vestigial lock, do not enroll periodic task while holding threads_lock
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 980:
> 
>> 978: }
>> 979: 
>> 980: void ShenandoahGeneration::increase_capacity(size_t increment) {
> 
> is there some sanity check done on this elsewhere to make sure the increase/decrease make sense? Perhaps I'll see it in the caller(s) when I get to it.

I see now that you do. Would it still be worthwhile asserting here as well that bounds are respected. Might make the code more maintainable in the face of changes.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 1095:
> 
>> 1093: }
>> 1094: 
>> 1095: bool ShenandoahHeap::adjust_generation_sizes() {
> 
> Is this method idempotent? I guess it depends on the method of the same name in the MMU Tracker. I guess my question will be answered when I get to it.

Left a related comment in `MmuTracker::adjust_generational_size()`.

> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.hpp line 37:
> 
>> 35:  * This class is responsible for tracking and adjusting the minimum mutator
>> 36:  * utilization (MMU). MMU is defined as the percentage of CPU time available
>> 37:  * to mutator threads over an arbitrary, fixed interval of time. MMU is measured
> 
> Where do we specify the fixed interval used as the basis for the MMU?

I'd mention the interval `GCPauseIntervalMillis` here for clarity. (I'd say it's a curious naming of the interval, but it's already used in that sense, so we leave it as is.)

> src/hotspot/share/gc/shenandoah/shenandoahMmuTracker.hpp line 90:
> 
>> 88:   // allocators by taking the heap lock). The amount of capacity to move
>> 89:   // from one generation to another is controlled by YoungGenerationSizeIncrement
>> 90:   // and defaults to 20% of the heap. The minimum and maximum sizes of the
> 
> Is the transfer delta always 20%? Wouldn't that cause oscillations about an equilibrium point at steady load? But I should read on to see how this works.

I think the way you use it, it's not 20% of the heap but rather 20% of the free space in the generation that will provide the transfer delta. May be reword for clarity?

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

PR: https://git.openjdk.org/shenandoah/pull/177