<div dir="ltr">> my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application<br>fall into a very low cpu cost state. for example, gc_time = 30, app_time=40，GCTimeRatio is: 30/(30+40)= 0.42, the g1<br>heap size policy will try to extend heap size to scale down GCTimeRatio。But actually the application doesn't care about<br>its performance at all under the state，because there is basically no or merely request for the app. Do you have idea about<br>it?<div><br></div><div>The rationale for <a href="https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633" target="_blank">https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633</a> is that the GCTimeRatio approach is mostly based on pause times, instead of CPU time. The pause-time approach is more stable and less prone to drastic fluctuations. A simplified view for these two approaches is:</div><div>- GCTimeRatio approach: GC_pause_time / total_wall_time</div><div>- GC CPU overhead approach: GC_CPU_time / total_CPU_time</div><div><br></div><div>total_wall_time elapses at a constant rate, so it is a more stable denominator. I experimented with a synthetic workload that exhibits this problem using the GC CPU overhead approach. This problem did not appear with the GCTimeRatio approach. </div><div><br></div><div>For Shaojun's case, the application spends 42% of its wall time inside GC pauses. It's close to GC thrashing, so the JVM expands the heap to prevent that.</div><div>Does this behavior cause large heap size growth in JDK 26, compared to JDK 25? Could you provide a reproducer program or GC logs?</div><div>If the application has a small heap, <a href="https://bugs.openjdk.org/browse/JDK-8349978">https://bugs.openjdk.org/browse/JDK-8349978</a> is a known issue with the GCTimeRatio approach for small heaps.</div><div><br></div><div>Incidentally, we noticed some applications grow to a larger heap with JDK 26 compared to JDK 25. We have not yet examined this issue in depth.</div><div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr">-Man</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Jan 26, 2026 at 12:50 PM Man Cao <<a href="mailto:manc@google.com" target="_blank">manc@google.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Since hotspot-gc-dev does not support pictures/screenshots, here is the context based on a previous email that Shaojun sent to me directly.<div><br></div><div>First screenshot is from <a href="https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994" target="_blank">https://github.com/openjdk/jdk/pull/24211#issuecomment-2777769994</a>:</div><div><br></div>> Somewhat related to above, our experience with our internal algorithm that adjusts SoftMaxHeapSize based on GC CPU overhead, encountered cases that it behaves poorly. The problem is that some workload have large variance in mutator's CPU usage (e.g. peak hours vs off-peak hours), but smaller variance in GC CPU usage. Then it does not make much sense to maintain a constant % for GC CPU overhead, which could cause excessive heap expansion when mutator CPU usage is low. The workaround is to take live size into consideration when calculating SoftMaxHeapSize, which is similar to how Min/MaxHeapFreeRatio works.<br>> I'm not sure if GCTimeRatio using wall time and pause time could run into similar issues. I'm happy to experiment when we make progress on JDK-8238687/JDK-8248324/JDK-8349978.<div><div><br></div><div>Second screenshot is from <a href="https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633" target="_blank">https://bugs.openjdk.org/browse/JDK-8359348?focusedId=14802633#comment-14802633</a>:</div><br>> Regarding to the fluctuating mutator CPU usage issue, upon reviewing <a href="https://github.com/openjdk/jdk/pull/26351" target="_blank">https://github.com/openjdk/jdk/pull/26351</a>, I'm convinced that the proposed approach does not suffer from this issue. This is because the proposed approach does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage.<div><br></div><div><div dir="ltr" class="gmail_signature"><div dir="ltr">-Man</div></div></div><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 23, 2026 at 11:28 PM shaojun wang <<a href="mailto:jeffery.wsj@outlook.com" target="_blank">jeffery.wsj@outlook.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div>




<div dir="ltr">
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
Hi Men Cao</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
I read one openjdk bug which discuss  G1 heap adaptive resizing feature, and I noticed that you mention one question like this:</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<img style="width: 562px; height: 129px; max-width: 894px;" height="129" width="562" alt="image.png" src="https://mail.google.com/mail/u/0?ui=2&ik=6608b5cc4f&attid=0.1&permmsgid=msg-a:r-6477420736395640503&th=19be4ccde98acac8&view=fimg&fur=ip&permmsgid=msg-a:r-6477420736395640503&sz=s0-l75-ft&attbid=ANGjdJ_jNEj_KMV3_ZHCEk7i8wTwfOTFvj06M7VqBYNmzqEwmd_Z1oMt_lcbJpwfMS50dCifqsTnp5EfRYY_yMWSUiCSPZEahk2zjp4vdd29oMO8-hihmpCHPpLZUaU&disp=emb&realattid=ii_mkp6cic00&zw"></div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
and then you mentioned that you were convinced that the proposed approach does not suffer from this issue. This is because the proposed approach </div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
does not rely on the total process CPU usage, and does not measure "GC CPU overhead", i.e., a ratio of GC CPU usage over total CPU usage.</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<img style="width: 562px; height: 118px; max-width: 894px;" height="118" width="562" alt="image.png" src="https://mail.google.com/mail/u/0?ui=2&ik=6608b5cc4f&attid=0.2&permmsgid=msg-a:r-6477420736395640503&th=19be4ccde98acac8&view=fimg&fur=ip&permmsgid=msg-a:r-6477420736395640503&sz=s0-l75-ft&attbid=ANGjdJ8NJyMS1MMi8hjRsdSxUK8Rmbb7u1HQXijYiUvgzwPu5dglo-zREL_Q0m0XhpmSUPB9EIb4k-4655fXVoGRNuZnI080bazEd71s7zbQtrKEclHkNn6T7AnkP4U&disp=emb&realattid=ii_mkp6gwev1&zw"></div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
my question is that even with GCTimeRatio(gc time / (gc time + app time)) , the problem will still exist if the application</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
fall into a very low cpu cost state. for example, gc_time = 30, app_time=40，GCTimeRatio is: 30/(30+40)= 0.42, the g1</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
heap size policy will try to extend heap size to scale down GCTimeRatio。But actually the application doesn't care about</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
its performance at all under the state，because there is basically no or merely request for the app. Do you have idea about</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
it?</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="text-align:left;text-indent:0px;font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(17,85,204)">
<a style="color:rgb(17,85,204)" id="m_-6243168656517805588m_9036033210294792673m_5710840970226757080m_-8525208379942971413OWA5e02980e-74c4-030d-827e-39ff2aa66859" href="https://github.com/openjdk/jdk/pull/24211" target="_blank">https://github.com/openjdk/jdk/pull/24211</a></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(17,85,204)">
<a style="color:rgb(17,85,204);text-align:left" id="m_-6243168656517805588m_9036033210294792673m_5710840970226757080m_-8525208379942971413OWAba641e2d-0b09-d31b-d044-f63693f824f0" href="https://bugs.openjdk.org/browse/JDK-8359348" target="_blank">https://bugs.openjdk.org/browse/JDK-8359348</a></div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
<br>
</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
>From shaojun wang</div>
<div style="font-family:Aptos,Aptos_EmbeddedFont,Aptos_MSFontService,Calibri,Helvetica,sans-serif;font-size:12pt;color:rgb(0,0,0)">
ByteDance</div>
</div>

</div></blockquote></div>
</blockquote></div>