This is an umbrella CR collecting useful information/plans on the work.

[1] gives a rough summary ("braindump") about the system envisioned for G1 (warning: fixed size font use ahead for some ASCII art):
```
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).

I.e. react better to some inputs ("pressure" sources), given some controller, generate current target and current committed heap size, and act on these.

Summarizing, the following "new" functionality may be required to be implemented:

* CPU based heap sizing may need defaults tuned down, the existing 8% allowance is quite high for modern G1 (JDK-8247843)
  * GCTimeRatio is a bit awkward to use as it is the inverse of allowed GC cpu usage. G1 actually internally first just translates the former to the latter. Maybe better to provide GCCPUPercentage or something in the future and phase out GCTimeRatio
* (Maybe) some external knob using "CurrentMaxHeapSize" flag to directly influence the hard current committed maximum size (JDK-8204088)
* "SoftMaxHeapSize" as an external knob to influence current target heap size better when CPU based heap sizing does not do the correct thing due to having more knowledge about what the user intends to do (JDK-8247843)
* other incomplete or missing AHS related functionality that the ZGC JEP (JDK-8329758) touches:
  * detect and react on neighbouring processes' native memory pressure
  * a `ZGCPressure` or similar that changes extent to react on native memory pressure (or in general, any "pressure")
  * startup heap size expansion boost revised - there currently is such a mechanism in G1 already (e.g. JDK-8349978).
  * concurrent heap (un-)commit - that means, regularly (in a more periodic sense than GCs which can be spaced quite irregularly apart) revise heap targets, may help with general stability/consistency/timeliness of the results

These current thoughts leave open timeliness issues of reaction on any kind of pressure.

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.

References:
[1] https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-February/051079.html
[2] https://bugs.openjdk.org/secure/attachment/114105/ahs-google-revised-20241022.pdf