G1 AHS + Request for Feedback and Testing on G1 Heap Resizing Prototype

[Thomas Schatzl]

Hi Monica,

   thanks for providing more input on this issue.

On 21.05.25 06:09, Monica Beckwith wrote:
> Hello everyone,
> 
> I have created a new sub-task: https://bugs.openjdk.org/browse/ 
> JDK-8357296 <https://bugs.openjdk.org/browse/JDK-8357296> under the 
> umbrella bug JDK-8353716 for G1 AHS.
> 
> This sub-task implements the coordination mechanism that integrates all 
> other AHS components.

Not sure if "implementation" means "code for some API to fill in" here 
because the suggested component seems fairly abstract in nature. 
Obviously I haven't seen that code, but that makes me even more nervous :)

[I tend to be a more bottom-up guy that first prototypes the pieces, 
each providing some value when integrated if possible (with the end goal 
in mind), and think about how to coordinate the currently implemented 
changes as needed.
Iterate often instead of some in-advance top-down architecture. But I 
have no idea what the contents of that implementation are]

> 
> The key aspects of this implementation are:
> 
> 1. Integration Points:
> 
> - Coordinates SoftMax policy (JDK-8236073) with heap sizing decisions
> - Applies GCTimeRatio targets (JDK-8247843) in control loop
> - Triggers shrink decisions (JDK-8238687) based on GC metrics
> - Schedules memory uncommit (JDK-8238686) when appropriate
> 
> 2. Key Files Modified:
>    g1HeapSizingPolicy.{cpp,hpp} - Core control loop implementation
>    g1_globals.hpp              - AHS configuration framework
> 
> 3. Runtime Controls:
> 
> Primary controls:
>    GCTimeRatio           - GC vs application time ratio
>    GCCpuOverheadTarget   - Direct CPU target percentage

To answer Kirk's question in the other thread:

 > How do you anticipate that GCTimeRatio and GCCpuOverheadTarget would
 > work together?

Since they are effectively the same thing, my _current_ initial idea 
would be to when specifying both will make one override the other with 
an appropriate warning. Done.

Since GCCpuOverheadTarget is only a usability issue we might delay its 
introduction a bit, and does not seem urgent. There is probably more to 
be discussed with people maintaining the other GCs too.

>    SoftMaxHeapSize       - Soft maximum heap size limit
> 
> Tuning parameters:
>    G1AHSDampingFactor    - Control loop response damping

Not exactly sure what this means and how this interacts with other known 
to be needed ways to help with issues found during testing.

We tend to be very wary of adding new product options.

One problem with this single option is that it will be a tradeoff: what 
at least came up before multiple times is control about

- extent of heap change (may also depend on situation, e.g. startup boost)
- response time of heap change

for both heap expansion and shrinking (e.g. 
https://bugs.openjdk.org/browse/JDK-8349939, 
https://bugs.openjdk.org/browse/JDK-8349978; abstracting a bit from them).

Recent internal discussion of some test results for JDK-8238687 strongly 
suggested that this control should be dependent on type of heap change. 
Even then, as diagnostic options.

What I wanted to say here is that, _if_ that flag's purpose would be as 
described above, it seems to be insufficient.

There is also the problem of integrating this proposal with the current 
prototype for JDK-8238687. One could only use that as additional factor 
for determining the (iirc currently internal magic constants) above, but 
seems unnecessary at first thought.

>    G1UncommitDelay       - Memory uncommit delay time
The purpose of this parameter is not completely clear to me; what delay 
is supposed to be controlled here? Would be nice to explain this a bit 
more as I could not find anything in that repo. The referenced CR seems 
to be about something different too.

Probably you are envisioning something like ZUncommitDelay here, where 
the GC tracks region usage/access and uncommits regions that have not 
been used for a "long" time.

I think that is one way to attack the issue that JDK-8238687 has: since 
heap size evaluation is on a gc basis, if there are no GCs since the 
application is idle, memory will be kept committed unnecessarily for a 
long time.

Probably I mentioned this issue once or twice somewhere. I tried to sum 
up the problem and provide some background about other similar 
issues/mechanisms in the new "JDK-8357445: G1: Time-based heap size 
re-evaluation".

> 
[...]> I will submit a PR soon. Comments and suggestions are welcome 
either now
> or during the PR review.
> 

It would be great if we main contributors could meet in a video call to 
discuss findings in the recent months, current state, results and 
thoughts in the next time, it seems.

There is also no need to submit a formal PR, before that it would be as 
fine to just initially send a patch (e.g. create a branch on github and 
send a link) here for initial discussion like Ivan provided recently.

Thanks,
   Thomas