<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Man,
<div><br>
</div>
<div>Sorry to butt in. A high level question about the AHS plan for G1… are we interested in the</div>
<div>intermediate functionality (SoftMaxHeapSize and CurrentMaxHeapSize), or is it AHS that</div>
<div>we are interested in?</div>
<div><br>
</div>
<div>The reason I ask is that each incremental feature comes with some baggage due to being</div>
<div>a (somewhat) static and manually set limit, which the AHS solution won’t need to deal with.</div>
<div><br>
</div>
<div>For example, it’s unclear how a *static* SoftMaxHeapSize should behave when the livee set</div>
<div>is larger than the limit. While that can maybe be solved in some reasonable way, it’s worth</div>
<div>noting that AHS won’t need the solution, because there it’s a dynamic limit that the GC simply</div>
<div>won’t set lower than the memory usage after GC. It will however get in the way because the</div>
<div>user can now also set a SoftMaxHeapSize that conflicts with the AHS soft heap size that</div>
<div>the JVM wants to use, and then we gotta deal with that.</div>
<div><br>
</div>
<div>Similarly, the CurrentMaxHeapSize adds another way for users to control (read: mess up)</div>
<div>the JVM behaviour that we need to respect. In the end, AHS will compute this dynamically</div>
<div>instead depending on environment circumstances. I suspect the fact that it can also be</div>
<div>manually set in a way that conflicts with what the JVM wants to do, will end up being a pain.</div>
<div><br>
</div>
<div>I’m not against the plan of building these incremental features, especially if we want them</div>
<div>in isolation. But if it’s AHS we want, then I wonder if it would be easier to go straight for what</div>
<div>we need for AHS without the intermediate user exposed steps, because they might introduce</div>
<div>unnecessary problems along the way.</div>
<div><br>
</div>
<div>My 50c, no strong opinion though.</div>
<div><br>
</div>
<div>/Erik</div>
<div>
<div><br>
<blockquote type="cite">
<div>On 9 Apr 2025, at 09:44, Man Cao <manc@google.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>Hi all,</div>
<div><br>
</div>
<div>Thank you Thomas for creating the umbrella CR at <a href="https://bugs.openjdk.org/browse/JDK-8353716" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8353716</a>.</div>
<div>While waiting a bit on SoftMaxHeapSize PR (<a href="https://github.com/openjdk/jdk/pull/24211">https://github.com/openjdk/jdk/pull/24211</a>) to see if others have feedback, I could start working on CurrentMaxHeapSize (<a href="https://bugs.openjdk.org/browse/JDK-8204088">https://bugs.openjdk.org/browse/JDK-8204088</a>).</div>
<div>I also agree that CurrentMaxHeapSize may not need a JEP due to its small size and low complexity. Should it proceed similarly to how SoftMaxHeapSize was introduced? I.e,
<a href="https://bugs.openjdk.org/browse/JDK-8222145">https://bugs.openjdk.org/browse/JDK-8222145</a>, and creating a CSR (<a href="https://bugs.openjdk.org/browse/JDK-8222181">https://bugs.openjdk.org/browse/JDK-8222181</a>) for it.</div>
<div><br>
</div>
<div>Separately, for removing support for Min/MaxHeapFreeRatio for G1 (mentioned in <a href="https://bugs.openjdk.org/browse/JDK-8353716" rel="noreferrer" target="_blank">https://bugs.openjdk.org/browse/JDK-8353716</a> and <a href="https://bugs.openjdk.org/browse/JDK-8238686">https://bugs.openjdk.org/browse/JDK-8238686</a>),
how do we handle existing users that set these two flags?</div>
<div>(We have very few internal users setting these two flags. But yesterday I ran into a use case that sets -XX:MinHeapFreeRatio=0 -XX:MaxHeapFreeRatio=0 for G1...)</div>
<div><br>
</div>
<div>Best,</div>
<div>Man</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</body>
</html>