<div dir="ltr"><div dir="ltr"><div dir="ltr"><div>>> Supporting both memory.high and memory.max for AHS sounds great.</div><div>>> 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.<br>> Okay, great. Sounds like AHS + actually using the standardized cgroups memory limits as the way of limiting memory is a viable path forward then?</div><div><br></div><div>Not exactly. It is still impractical to migrate the custom container cases to standard cgroups. Thus those custom container cases cannot use AHS.</div><div>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.</div><div><br></div><div>> 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.</div>> 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.<br>> 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.</div><div dir="ltr"><br></div><div>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 <a href="https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051903.html" target="_blank">previous response</a>: 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):</div><div><br></div><div>1. CRIU (OpenJDK CRaC) from [~rvansa]'s comment on <a href="https://bugs.openjdk.org/browse/JDK-8204088" target="_blank">https://bugs.openjdk.org/browse/JDK-8204088</a>.  This case needs to shrink the Java heap as much as possible before creating the process snapshot. CRaC has implemented <a href="https://bugs.openjdk.org/browse/JDK-8348650" target="_blank">https://bugs.openjdk.org/browse/JDK-8348650</a> for G1. This is almost the same as the use case for setting -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=0 <a href="https://mail.openjdk.org/pipermail/hotspot-gc-dev/2025-April/051900.html" target="_blank">mentioned previously in this thread</a>. Min/MaxHeapFreeRatio only works for G1 and ParallelGC, and will likely stop working for G1 as <a href="https://bugs.openjdk.org/browse/JDK-8353716" target="_blank">https://bugs.openjdk.org/browse/JDK-8353716</a> says. </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div dir="ltr"><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">-Man</div></div></div></div></div>
</div>