Configurable G1 heap expansion aggressiveness

[Thomas Schatzl]

Hi,

On 13.02.25 21:36, Jaroslaw Odzga wrote:
> Hi Kirk,

[...]

>> If I might add, in large homogenous deployments, you’d think you’d see a 1 size fits all optimal GC configuration. Unfortunately my look into this has shown that there are often multiple optimal configurations. The only way to combat this is  with smarter ergonomics in the runtime.
> Thanks for the insight. I believe this to be true. My claim is that
> for the majority of applications in certain domains (e.g. backend
> services in multi-tenant environments running in the cloud) the
> existing default G1 configuration and ergonomics work well only if the
> max heap size is correctly sized (because of the greedy heap
> expansion).
> Sizing heaps is challenging at scale and the most common result is
> setting max heap too high. This leads to a lot of resource waste that
> is hard to detect and realize for many because "the heap is used".
> 
> I guess the question boils down to: is it worth exposing two more
> internal G1 parameters in a "short term" as experimental tunnables to
> allow some high leverage optimizations.
> I think we agree on the cost of doing it (although it might be hard to
> quantify): maintenance, potential misuse, additional complexity.

We (in the Oracle GC team) have had really really bad experience with 
haphazardly exposing functionality using flags. They tend to live longer 
than expected, and due to a responsibility for backwards compatibility 
they just hinder progress (E.g. in this area: Min/MaxHeapFreeRatio).

Further complicating matters is that you seem to expect this to be 
backported all the way back to JDK 17 ("On the plus side, the change 
itself is tiny, very localized and could be trivially backported e.g. 
all the way to jdk17."), which is an even much greater ask.

 > On a benefit side, the initial results suggest we could significantly
 > increase bin-packing of JVMs per VM because, when bin-packing, we have
 > to account for memory usage spikes due to temporary aggressive heap
 > expansions. Rough estimates suggest 30%-60% smaller memory spikes. At
 > large scale this could lead to big cost savings with a little effort.

At this time it is only you asking for this, although the general 
problem has been known for a long time.

Given that, and that a lot of the issues related to that were filed 
around 2020 by me 
(https://bugs.openjdk.org/issues/?jql=labels%20%3D%20gc-g1-heap-resizing), 
after first concerns having been voiced in 2018, it tells me that it is 
not/has not been that great of an itch to invest effort into this until now.

Thanks go to Google and MS who are looking into this in some capacity at 
this time :)

 > Taking into account that the additional flags do not change existing
 > default behavior, so they would be completely transparent unless
 > someone decides to go down the rabbit hole of tuning experimental GC
 > flags, maybe it is something worth considering?

We at Oracle currently think it is better to invest the time and effort, 
as little as may be, in a proper solution than band-aiding heap sizing 
another time.

So yeah, barring other compelling supportive input/opinions/data, we at 
Oracle would reject this proposal for jdk 25 (and even more backporting 
this to jdk17).

Hth,
   Thomas