Moving Forward with AHS for G1

[Man Cao]

> Okay it seems to me that the use case you are describing is wanting a
container with an enforced memory limit. It should quack like a cgroup and
walk like a cgroup but must not actually use cgroups for some reason.
> Cgroups were seemingly built for this use case and has a complete view of
the memory usage in the container due to being an OS feature.
> Conversely, if the custom ad-hoc container environment does not have OS
support for the memory limit, then the app can temporarily exceed the
memory limit, and hence won’t be as effective of a limit.
> But if you want to actually enforce a memory limit such that the app dies
if it exceeds the limit I can’t help but wonder… why not use a cgroup to
declare that limit though?

The custom container has additional features that cgroup does not have.
Enforcing memory limit is only a basic feature. Other features of the
custom container are largely irrelevant to the AHS discussion (and I'm not
sure if I could publicly share those features).
In fact, the custom container is more of an extension or wrapper on top of
cgroup. It is quite likely we have internal patches to the OS kernel to
support the custom container.

> Regardless, I wonder if what you actually want for your use case is a way
to tell AHS what the max memory of the entire JVM should be, similar to the
-XX:RssLimit Thomas Stuefe proposed:
https://bugs.openjdk.org/browse/JDK-8321266
> In other words, letting the JVM know that it has a bound on memory, and
have AHS know about and try to adapt the heap such that the JVM memory
usage is below the limit when native memory goes up and down. In other
words, let the heap heuristics live in the JVM. Perhaps then the limit
would also be static, or do the containers themselves actually grow and
shrink at runtime, or was the dynamic nature of CurrentMaxHeapSize mostly
an artifact of out sourcing the heap heuristics of an otherwise static
custom container limit?

The custom container's memory limit could dynamically change at runtime,
thus -XX:RssLimit or -XX:CurrentMaxHeapSize must be a manageable flag. In
fact, cgroup also supports changing memory limit dynamically:
https://unix.stackexchange.com/questions/555080/using-cgroup-to-limit-program-memory-as-its-running
.

Having a manageable -XX:RssLimit, and making the JVM adjust heap size
according to RssLimit, could in theory replace CurrentMaxHeapSize. However,
I could think of the following issues with the RssLimit approach:
1. Description of https://bugs.openjdk.org/browse/JDK-8321266 indicates
RssLimit is intended for debugging and regression testing, to abort the JVM
when it uses more Rss than expected. It does not involve resizing the heap
to survive the RssLimit. Adding heap resizing seems a significant change to
the original intended use.
2. Calculating an appropriate heap size based on RssLimit seems
challenging. Typically only part of the heap memory mapping contributes to
Rss. The JVM probably has to continuously monitor the total Rss, as well as
Rss from heap memory mappings, then apply a heuristic to compute a target
heap size.
3. Applications still need a mechanism to dynamically adjust values
for RssLimit, just as for CurrentMaxHeapSize. Providing a value for
RssLimit is not really easier than for CurrentMaxHeapSize, e.g. when a Java
process and several non-Java processes run inside the same container (this
is the common case in our deployment).

It seems that RssLimit is not necessarily easier to use than
CurrentMaxHeapSize, but definitely more complicated to implement (due to 1
and 2).

-Man

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