<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 Kirk,<br id="lineBreakAtBeginningOfMessage">
<div><br>
<blockquote type="cite">
<div>On 2 May 2024, at 18:59, Kirk Pepperdine <kirk@kodewerk.com> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi Erik,
<div><br>
</div>
<div>Some questions.<br>
<div><br>
</div>
<div>On the question of allocation stalls, couldn’t/shouldn’t one just start the collection cycles sooner?</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>Yes - if nothing unexpected happens, then we will indeed just start earlier. But when unpredicted things happen, such as large unpredicted surges in allocation rate, or sudden increase in residency compared to earlier collections, there is always a risk
of stalling. Just taking some extra memory is typically preferred, instead of stalling.</div>
<br>
<blockquote type="cite">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>On the question of sharing in containers, I’m aware of two different experiments on how to resolve the issue of allowing Java heap to consume more of available memory. Of the two the most interesting is a modification of G1 that uses GC thread CPU overhead
as a signal to decide if Java heap should be expanded or contracted. The idea is to keep GC thread utilization within a band (of ~20%). The other component of this experiment is to fail any attempts to expand should that expansion risk triggering an OOM killer.
In this case the failed expansion will result in a hotter CPU. That said, this a significantly more graceful degredation than having the process terminated. My question is, would you consider taking a similar approach for ZGC?</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>The first part of it sounds indeed quite similar to what I’m planning.</div>
<div><br>
</div>
<div>Regarding reacting to some “dangerously high” watermark, I have thought a bit about that, and have so far decided to stay out of it. Mostly because I haven’t thought of any promising way of doing that without getting strange echo effects where multiple
JVMs are shrinking and expanding continuously based on reactions, and reactions to said reactions, rather than a carefully planned global plan from an external source controlling them.</div>
<div><br>
</div>
<div>What might work reasonably well though, is to compute the GC pressure if it hasn’t been specified, to something like 1.0 / MIN(0.2, memory_left_fraction). This way, the GC pressure is “medium” until you get to the last 20% of memory, and then increases
proportionally, as the last 20% memory on the machine starts getting used up. The nice thing with such an approach, is that all JVMs agree about the GC pressure, and will do their fair share extra work to keep it down, without oscillating up and down or having
a single escape goat JVM that takes all the burden. I’ll try that and see if that can work well.</div>
<br>
<blockquote type="cite">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>Finally, on the flag ZGCPressure, could you speak a little more about how it balances CPU vs memory? Specifically, what does the value 5 represent? I understand if one were to pull on that lever you affect the level of aggressiveness but is this aggressiveness
of how quickly heap would be expanded?</div>
</div>
</div>
</div>
</blockquote>
<div><br>
</div>
<div>I have intentionally been a bit vague here, as I am hoping to be able to change the implementation over time without being tied down to a specific contract that becomes impossible to conform to in the future where this functionality becomes more complex.</div>
<div>Having said that, 5 is a sort of medium level of aggressiveness. Considering CPU utilization alone, if a process is utilizing 100% of the available CPU resources on a machine, then it will use approximately 1/8 of the available CPU, for doing GC. But it
will still perform GC less aggressively, if the frequency seems too high.</div>
<div><br>
</div>
<div>Kind regards,</div>
<div>/Erik</div>
<br>
<blockquote type="cite">
<div>
<div style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
<div>
<div>Kind regards,</div>
<div>Kirk</div>
<div><br>
<div><br>
<blockquote type="cite">
<div>On May 2, 2024, at 7:44 AM, Erik Osterlund <<a href="mailto:erik.osterlund@oracle.com">erik.osterlund@oracle.com</a>> wrote:</div>
<br class="Apple-interchange-newline">
<div>
<div style="overflow-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;">
Hi,
<div><br>
</div>
<div>I have written a draft JEP for a automatic heap sizing when using ZGC.</div>
<div>JEP description is available here: <a href="https://bugs.openjdk.org/browse/JDK-8329758">https://bugs.openjdk.org/browse/JDK-8329758</a></div>
<div><br>
</div>
<div>Comments and feedback are welcome.</div>
<div><br>
</div>
<div>Thanks,</div>
<div>/Erik</div>
</div>
</div>
</blockquote>
</div>
<br>
</div>
</div>
</div>
</div>
</blockquote>
</div>
<br>
</body>
</html>