<div dir="ltr"><div dir="ltr"><div>Re Thomas's comments:</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">I think this is the best way forward. There is no need for a JEP from me<br>either.<br>Exact behavior in various situations needs to be defined in the CSR.</blockquote></div><div dir="ltr"><br></div><div dir="ltr">Thanks. Should I edit <a href="https://bugs.openjdk.org/browse/JDK-8204088">https://bugs.openjdk.org/browse/JDK-8204088</a> in place to change it to a CSR, or do you prefer creating a separate issue?</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">One option is to translate these options into other values impacting<br>heap size "similarly". E.g. have Min/MaxHeapFreeRatio translate to<br>internal pressure at the time the changes are noticed, but that is just<br>a potential solution that hand-waves away the effort for that.</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>Then start deprecating and remove; depends a little on how useful (or<br>how much in the way) they are for Serial and Parallel GC (other<br>collectors don't support them). It is unlikely that ZGC and Shenandoah<br>will adopt these.</blockquote><div><br></div><div>I feel like both approaches have additional problems:</div><div>For the first approach, even with a translation mechanism, it still has the problem of GCTimeRatio and Min/MaxHeapFreeRatio overriding each other. I think the only solution is to translate Min/MaxHeapFreeRatio directly to a value for GCTimeRatio, as well as making GCTimeRatio a manageable flag. Agree that the effort to implement this approach is nontrivial.</div><div>For the second approach, Min/MaxHeapFreeRatio are pretty popular flags for Parallel GC, so it could be difficult to remove them for Parallel GC.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Even already in JDK-8238687 Min/MaxHeapFreeRatio happily work to counter<br>the cpu based sizing, so some solution needs to be found there already.</blockquote><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">That change will already be quite disruptive in terms of impact on heap<br>sizing, so another option is to remove support in G1.</blockquote></div><div><br></div><div>I think removing support for Min/MaxHeapFreeRatio only for G1 is feasible, as long as we provide a replacement approach. Some high-level guidance like "if you set Min/MaxHeapFreeRatio to small values such as XX, try lowering GCTimeRatio to YY" may be acceptable. The downside is that it requires users of Min/MaxHeapFreeRatio to re-tune JVM parameters.</div><div>One unresolved use case is dynamically changing Min/MaxHeapFreeRatio due to them being manageable. Perhaps we could make GCTimeRatio manageable? But Parallel GC and Shenandoah also use GCTimeRatio, so it could be difficult.</div><div dir="ltr">Or if we reconsider the high-precedence SoftMaxHeapSize implementation (<a href="https://github.com/openjdk/jdk/pull/24211">https://github.com/openjdk/jdk/pull/24211</a>), perhaps users who dynamically set Min/MaxHeapFreeRatio could move to set SoftMaxHeapSize instead.</div><div dir="ltr"><br></div><div dir="ltr"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)">> (We have very few internal users setting these two flags. But yesterday<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> I ran into a use case that sets -XX:MinHeapFreeRatio=0 -<br></span><span class="gmail-im" style="color:rgb(80,0,80)">> XX:MaxHeapFreeRatio=0 for G1...)</span></blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="gmail-im" style="color:rgb(80,0,80)"><br></span>What would be the use case for setting it to these values?</blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">There seem to be little upside and lots of downside for this choice,<br>because it likely causes a lot of GC activity since the VM will need GC<br>to expand the heap little by little all the time, and full gc/Remark<br>will immediately reset these expansion efforts.</blockquote><div><br></div>The use case is to create a process snapshot image via CRIU (checkpoint/restore), like what <a href="https://openjdk.org/projects/crac">https://openjdk.org/projects/crac</a> does.</div><div dir="ltr">The application wants G1 to shrink the heap as much as possible, to reduce the size of the snapshot. It sets both flags to zero, performs several System.gc(), then sets both flags back to previous values, then creates the snapshot.<br><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">-Man</div></div></div></div></div>