<div dir="ltr"><div dir="ltr"><div><div dir="ltr">> 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.</div><div dir="ltr">> 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.</div><div dir="ltr">> 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.</div><div dir="ltr">> 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?</div></div><div dir="ltr"><br></div><div>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).</div><div>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.</div><div><br></div><div><div dir="ltr">> 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: <a href="https://bugs.openjdk.org/browse/JDK-8321266" target="_blank">https://bugs.openjdk.org/browse/JDK-8321266</a></div><div dir="ltr">> 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?</div></div><div dir="ltr"><br></div><div>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: <a href="https://unix.stackexchange.com/questions/555080/using-cgroup-to-limit-program-memory-as-its-running">https://unix.stackexchange.com/questions/555080/using-cgroup-to-limit-program-memory-as-its-running</a>.</div><div><br></div><div>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:</div><div>1. Description of <a href="https://bugs.openjdk.org/browse/JDK-8321266" target="_blank">https://bugs.openjdk.org/browse/JDK-8321266</a> 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.</div><div>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.</div><div>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).</div><div><br></div><div>It seems that RssLimit is not necessarily easier to use than CurrentMaxHeapSize, but definitely more complicated to implement (due to 1 and 2).</div><div><br></div><div>-Man</div></div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto"><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div><div dir="ltr" class="gmail_signature">
</div>
</div>
</div>
</div>
</div>
</blockquote>
</div>

</blockquote></div></div>