Moving Forward with AHS for G1

[Man Cao]

>> Supporting both memory.high and memory.max for AHS sounds great.
>> The soft limit for the custom container is only one example. The custom
container also has "strange" use cases where the actual limit is larger
than cgroup's hard memory limit.
> Okay, great. Sounds like AHS + actually using the standardized cgroups
memory limits as the way of limiting memory is a viable path forward then?

Not exactly. It is still impractical to migrate the custom container cases
to standard cgroups. Thus those custom container cases cannot use AHS.
One reason is the "strange" use cases where the actual limit is larger than
cgroup's hard memory limit. There are other reasons that the custom
container cannot migrate to standard cgroups.

> So the main point for introducing CurrentMaxHeapSize, as opposed to going
directly to AHS, would be to support all the people out there that already
built their own adaptive container infrastructure that doesn’t use industry
standard cgroup technology to limit memory. Instead, this group of users
use the very proposed CurrentMaxHeapSize functionality (which obviously
does not exist in mainline yet) to limit memory adaptively instead.
> I have to be honest… this sounds like a niche feature to me with a
ticking clock attached to it. Yet if it gets integrated, we will not be
able to get rid of it for decades and it will cost maintenance overheads
along the way. So I think it would be good to see a prominent use case that
might be interesting for a long time going forward as well, and not just a
way to help you guys stop using the proposed feature in the transition to
AHS, which seems to be where we are going.
> I think what will reach a much broader audience going forward, is AHS.
And if that’s the feature we really want, I can’t help but wonder if
exposing this user configurable stuff along the way is helping towards that
goal rather than slowing us down by inventing yet another set of manually
set handcuffs that the JVM and AHS will have to respect for ages, way past
its best before date.

I'd say the statements above are "overfitting" CurrentMaxHeapSize to the
custom container use case. The main point for the value of
CurrentMaxHeapSize (or a high-precedence SoftMaxHeapSize) is as mentioned
in the previous response
<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051903.html>: a
fully-developed AHS is unlikely to satisfy all use cases and deployment
environments out there. CurrentMaxHeapSize (or a high-precedence
SoftMaxHeapSize) provides additional flexibility and control for AHS and
for non-AHS use cases. The custom container and JVM-external algorithm for
calculating CurrentMaxHeapSize/SoftMaxHeapSize is only one example of such
use cases. I could think of other use cases for CurrentMaxHeapSize (or
high-precedence SoftMaxHeapSize):

1. CRIU (OpenJDK CRaC) from [~rvansa]'s comment on
https://bugs.openjdk.org/browse/JDK-8204088.  This case needs to shrink the
Java heap as much as possible before creating the process snapshot. CRaC
has implemented https://bugs.openjdk.org/browse/JDK-8348650 for G1. This is
almost the same as the use case for setting -XX:MinHeapFreeRatio=0
-XX:MaxHeapFreeRatio=0 mentioned previously in this thread
<https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051900.html>.
Min/MaxHeapFreeRatio only works for G1 and ParallelGC, and will likely stop
working for G1 as https://bugs.openjdk.org/browse/JDK-8353716 says.

2. Multiple Java processes with different priorities. If multiple processes
run inside the same container and memory is running low, users could set a
smaller CurrentMaxHeapSize for low-priority processes, to make more memory
available to high-priority processes.

3. Shrinking container memory limit dynamically. Directly setting
container memory limit to below the container memory usage will likely
fail. However, if user sets a smaller CurrentMaxHeapSize first, the Java
process will shrink the heap, thus reducing container memory usage. Then
lowering the memory limit will succeed.

In addition, these use cases may not want to adopt AHS for various reasons.
Instead, they could use CurrentMaxHeapSize/SoftMaxHeapSize to directly
solve the problems.

-Man
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20250417/aa4ef50e/attachment-0001.htm>