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.
> 
> Would you mind sharing more details on the work you are referring to
> (Serial collector changes, the ongoing G1 work) so I could learn more
> about it?
> It sounds like the "hibernation" feature you are talking about is
> different from Azul's CRaC that uses CRIU? Can you elaborate?
> 
>> 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?
> 

Some rough outline of the structure of heap sizing and what is 
envisioned for the G1 work; it's fairly straightforward, given some 
input a "controller" mashes all of them together and produces output.

Some ascii-art with a bit more detail:

Min/MaxInitialHeap-
      size (1)
                                              Current max heap size
GC CPU based heap
     sizing (2)                               Current committed
                                                   size
Min/MaxHeapFree-     ----> Controller ---->
    Ratio (3)                                 Current target heap
                                                   size
CurrentMaxHeapSize
       (4)

SoftMaxHeapSize (5)

AHS (6)

Comments:

(1) will stay
(2) Partially implemented, the main part that is missing is somehow 
giving feedback on shrinking the heap. JDK-8238687 mostly covers that, 
there is a (fairly old now) prototype.
(3) Their functionality will be fairly reduced if not completely 
scrapped. They get in the way all the time at least given their current 
definition.
(4) Set a current MaxHeapSize, i.e. a maximum heap size after which the 
VM will OOME. Allows setting max heap size according to input that the 
VM can't detect. Prototype from Google available, JDK-8204088 contains a 
link to some mail thread containing another prototype
(5) End user guiding a current target heap size, i.e. a heap size that 
g1 tries "hard" to follow, but will allow allocation above that. 
JDK-8236073 contains an old prototype.
(6) "AHS": be a nice citizen to other memory consumers in the same 
environment, similar to ZGC's JEP (JDK-8329758):
   - tiny initial heap size, large max heap size
   - startup boost for heap sizing
   - taking into account available memory in the environment
   - "ZGCPressure" - some knob to tune weights between all these inputs 
(i.e. memory/performance, response time/inertia).


More (minor) items in this area are collected using the 
"gc-g1-heap-resizing" label 
(https://bugs.openjdk.org/issues/?jql=labels%20%3D%20gc-g1-heap-resizing).

(That most of these CRs are assigned is misleading. That's historical, 
I'm working on something else for the foreseeable future)

The ZGCPressure equivalent should cover all the capabilities covered by 
your changes, both extent of response as well as response time itself.

Hth,
   Thomas

P.S: I'll respond to the other part of your email(s) in a bit.