[External] : Re: Moving Forward with AHS for G1

[Erik Osterlund]

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?

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?

/Erik

On 11 Apr 2025, at 00:15, Man Cao <manc at google.com> wrote:


> If the custom container app allocates 300 GB native memory with, for example, panama APIs or JNI, what will happen? Is it allowed, or limited?

I suppose the more accurate way to put it is "if an app inside the custom container environment allocates 300 GB native memory ...".  The custom container environment itself is not a Java app.

If the container memory limit is 310GiB, container usage is 305GiB, and the app's current Java heap size is 3GiB, and Xmx is 20GiB, then the app could set CurrentMaxHeapSize=8G  (310 - 305 + 3), or CurrentMaxHeapSize=7G (to give 1GiB head room for growth from other non-heap memory: code cache, thread stack, metaspace, etc.), to prevent running out of container memory limit. Note that the app should actively monitor container usage to adjust CurrentMaxHeapSize, e.g. increasing CurrentMaxHeapSize when container usage drops. If the app keeps allocating more native memory, CurrentMaxHeapSize will further drop, and it will eventually die with Java OutOfMemoryError.

In the above case, the JVM is unaware of the 310G container limit or the 305G container usage.

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