G1 AHS [Was: Re: Configurable G1 heap expansion aggressiveness]

[Thomas Schatzl]

Hi,

On 13.02.25 21:36, Jaroslaw Odzga wrote:
> Hi Kirk,
> 
> Thanks for the detailed answer, I appreciate your time on this.
> 
[...]
> 
>> That said, a tuning strategy for G1 is more complicated because the costs of transients is quite different in G1 than it is with the Serial/Parallel collectors. But I believe it is achievable using existing flags/structures and the addition of the SoftMaxHeapSize.
> Can you share more on how SoftMaxHeapSize fits into this strategy?
> Doesn't it require some "controller" that would dynamically adjust
> SoftMaxHeapSize at runtime based on signals like GC CPU usage, VM
> memory pressure etc?

Giving a rough summary about the system envisioned for G1 (warning: 
fixed size font needed ahead):

Inputs:

Min/Max/Initial-
    HeapSize (1)

CPU based heap
    sizing (2)                                       Current committed
                                                          heap size
Min/MaxHeapFree-      ---->    Controller   ---->
     Ratio (3)                                         Current target
                                                          heap size
CurrentMaxHeap-
     Size (4)

SoftMaxHeapSize (5)

    "AHS" (6)


(1) Existing, kept
(2) Improve current CPU based heap sizing; partially done. Largest 
improvement is to size down the heap based on GCTimeRatio. To some 
degree this is JDK-8238687, there is a prototype patch for that.
(3) The current function of the flags will be removed, if not the flags 
themselves. They are just in the way all the time.
(4) New functionality (JDK-8204088; may not be a JEP). Patch from google 
available. Allows the user to control max heap size from outside given 
external direction from outside with information not known (or 
impossible to know) by the VM. (I.e. the VM will OOME if going over 
that, but smaller than real MaxHeapSize). Optional.
(5) New functionality (JDK-8236073). A guide for G1 to try "hard" to 
keep that amount of memory. Will not make the VM go OOME if exceeding 
that. Prototype patch attached to the CR.
(6) "AHS": Similar to ZGC's efforts to be a good citizen within a given 
environment, probing current available memory and adjust committed size 
(https://openjdk.org/jeps/8329758).

There are some other, relatively minor issues that should/could be 
fixed, also collected using the `gc-g1-heap-resizing` label in JIRA 
(https://bugs.openjdk.org/issues/?jql=labels%20%3D%20gc-g1-heap-resizing). 
Some of them deal with the unnecessary aggressive boosting of heap sizing.

I'm not sure whether there should be user control for the response time. 
Even if so, I would rather have a more abstract "inertia" knob than 
directly allowing to control sample length. Maybe "ZGCPressure" as in 
the AHS JEP may also control that.

(Don't let it bother you that most of the CRs are currently assigned to 
me. I should unassign myselves for the time being because I'm working on 
something else right now)

Given all these inputs about what the heap size should be, some 
component, let's call it "controller" will decide current 
committed/target/max heap size.

Hth,
   Thomas