RFR: 8376051: gc/stress/TestStressG1Uncommit.java fails assertLessThan: expected that xxx < xxx
SendaoYan
syan at openjdk.org
Fri Jan 23 01:00:24 UTC 2026
On Thu, 22 Jan 2026 10:42:38 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:
>>> It will re-evaluate and resize the heap at every young gc, based on GC cpu usage.
>>
>> What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC.
>
>> > It will re-evaluate and resize the heap at every young gc, based on GC cpu usage.
>>
>> What I meant is the free heap memory ratio will never greater than 100%, so when the value of MaxHeapFreeRatio is seted to 100, G1 will never give back memory to OS? I am not familiar with GC.
>
> These ratios (actually percentages) only every applied to full gcs, and only for Serial/Parallel/G1 and maybe Shenandoah.
>
> Since JDK 26, G1 will re-evaluate the "best" heap size based on GC cpu usage. So if lots of time, more than the goal, `GCTimeRatio`, is spent in GC activity, G1 will shrink the heap and give back memory to the OS. (Actually, in many applications, G1 is keeping a smaller footprint now).
>
> G1 will re-evaluate and shrink/expand at every young gc (https://bugs.openjdk.org/browse/JDK-8238687), not only full gc/System.gc() based on arbitrary Min/MaxHeapFreeRatio. The [CSR](https://bugs.openjdk.org/browse/JDK-8375300) for the change causing this test failure hopefully explains the reason for this change well enough.
>
> Actually we are not sure how/why this test failure slipped through.
>
>> > I think revert the WhiteBox change also acceptable. Should I do that?
>> Yes, I think System.gc() is still cleaner.
>
> In this case, `System.gc()` and `WhiteBox.fullGC()` act exactly the same so I would also keep `System.gc()` just to keep the code simpler.
Thanks for the suggestions and reviews @tschatzl @shipilev
-------------
PR Comment: https://git.openjdk.org/jdk/pull/29357#issuecomment-3787615943
More information about the hotspot-gc-dev
mailing list