<div dir="ltr"><div dir="ltr"><div>Re Eric's comments:</div><div><br></div><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Sorry to butt in. A high level question about the AHS plan for G1… are we interested in the<br>intermediate functionality (SoftMaxHeapSize and CurrentMaxHeapSize), or is it AHS that<br>we are interested in?</blockquote><br class="gmail-Apple-interchange-newline"></div><div>No worries, and I appreciate the comment.</div><div>The high-level rationale is that JVM should provide at least one of SoftMaxHeapSize or CurrentMaxHeapSize as a high-precedence, manageable flag, so that the JVM could take customized input signal for heap sizing decisions.</div><div>Even with fully-developed AHS algorithm, it cannot satisfy all deployment environments. E.g. custom container system or custom OS, in which the JVM cannot detect system memory pressure via standard approaches. So these flags are not necessarily intermediate solutions, and they could allow more deployment environments to use AHS.</div><div><br></div><div>For SoftMaxHeapSize for G1, based on discussion in <a href="https://github.com/openjdk/jdk/pull/24211">https://github.com/openjdk/jdk/pull/24211</a>, it will likely become just hint to trigger concurrent marks, which will be unlikely to interfere with other parts of G1 AHS.</div><div>For my original proposal of high-precedence SoftMaxHeapSize (as currently implemented in the PR), the guidance for users is that they should either provide a mechanism to adjust SoftMaxHeapSize dynamically to prevent GC thrashing, or only set it temporarily and accept the risk of GC thrashing. It is not intended as a static value that the user "sets and forgets".</div><div>For CurrentMaxHeapSize, it has similar issues as high-precedence SoftMaxHeapSize, that it is not "sets and forgets". However, I can see that clearly-specified OutOfMemoryError behavior from CurrentMaxHeapSize could be more favorable than hard-to-define potential GC thrashing condition that a high-precedence SoftMaxHeapSize could cause.</div><div><br></div><div>Re Kirk's comments:</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Might I suggest that an entirely new (experimental?) adaptive size policy be introduced that makes use of current flags in a manner that is appropriate to the new policy. That policy would calculate a size of Eden to control GC frequency, a size of survivor to limit promotion of transients, and a tenured large enough to accommodate the live set as well as manage the expected number of humongous allocations. If global heap pressure won’t support the ensuing max heap size, then the cost could be smaller eden implying higher GC overhead due to increased frequency.<br>Metrics to support eden sizing would be allocation rate. The age table with premature promotion rates would be used to estimate the size of survivor. Live set size with a recent history of humongous allocations would be used for tenured.<br>There will need to be a dampening strategy in play. My current (dumb) idea for Serial is to set an overhead threshold delta that needs to be exceeded to trigger a resize.</blockquote><div><div><br></div></div><div>I don't quite understand how this adaptive size policy (ASP) solves the problems AHS tries to solve.</div><div>AHS tries solve the problem of reaching an appropriate target <b>total</b> heap size, based on multiple inputs (JVM flags, environment circumstances). Once a total heap size is determined, G1 uses existing algorithms to determine young-gen and old-gen sizes. However, the ASP seems to focus on determining young-gen and old-gen sizes using a new algorithm.</div><div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">-Man</div></div></div></div></div>