Adaptable Heap Sizing for G1 GC

Jonathan Joo jonathanjoo at google.com
Wed Jun 12 23:32:28 UTC 2024


Hello hotspot-dev and hotspot-gc-dev,

I'd like to reopen discussion on Adaptable Heap Sizing (AHS) for the G1
Garbage Collector, since we now have some time to dedicate to bringing this
effort to the OpenJDK Community. Please see
https://mail.openjdk.org/pipermail/hotspot-gc-dev/2022-September/040096.html
for the original thread.

The bullet points contained in the above link are still largely the same,
and we have made significant improvements to the service over the past few
years, and found success deploying it broadly across jobs internally. Now
that we feel the feature has matured, we'd like to introduce it to the
OpenJDK community in hopes that it can be adopted for broader use.

In short - the goal of Adaptable Heap Sizing is to improve memory usage and
reduce OOMs for Java applications, especially those deployed in
containerized environments. The key insights are as follows:


   1.

   Applications with low memory requirements but configured with high RAM
   often use RAM unnecessarily. We can utilize GC CPU overhead metrics to help
   guide heap sizing, allowing for RAM savings in these scenarios.
   2.

   For Java applications running in containers, we can bound Java heap
   usage based on our knowledge of the current container memory usage as well
   as the current container size, to prevent container OOMs.


The implementation of AHS currently involves some fairly lightweight
changes to the JVM, through the introduction of two new manageable flags.
They are essentially the same as these two (open feature requests):

   -

   https://bugs.openjdk.org/browse/JDK-8236073
   -

   https://bugs.openjdk.org/browse/JDK-8204088


In addition, we have a separate thread (outside of the JVM, in our custom
Java launcher) which reads in GC CPU overhead data and container
information, and calculates appropriate values for these two flags. We call
this the AHS worker thread, and this thread updates frequently (currently
every second). The vast majority of the AHS logic is in this worker thread
- the introduction of the new JVM flags above simply gives AHS a way to
tune GC heuristics given this additional information.

Thomas Schatzl mentioned there is a similar-sounding effort going on in ZGC
<https://bugs.openjdk.org/browse/JDK-8329758>, and also there were folks
outside of Google who expressed interest in this project, so I think it is
an appropriate time to discuss this again on an open forum. Given the
positive results we've had deploying AHS internally at Google, we feel this
is a valuable feature to the broader Java community that should be able to
be leveraged by all to achieve more stable and efficient Java heap behavior
🙂

I'd appreciate hearing peoples' thoughts on this. Thank you!

~ Jonathan

(P.S. For more information, a talk given about this project can be viewed
here <https://www.youtube.com/watch?v=qOt4vOkk49k>, though it is somewhat
dated.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20240612/4e64107a/attachment-0001.htm>


More information about the hotspot-gc-dev mailing list