RFR: 8348595: GenShen: Fix generational free-memory no-progress check
Paul Hohensee
phh at openjdk.org
Tue Feb 4 15:53:13 UTC 2025
On Fri, 24 Jan 2025 18:30:02 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
> At the end of a degenerated GC, we check whether sufficient progress has been made in replenishing the memory available to the mutator. The test for good progress is implemented as a ratio of free memory against the total heap size.
>
> For generational Shenandoah, the ratio should be computed against the size of the young generation. Note that the size of the generational collection set is based on young generation size rather than total heap size.
>
> This issue first identified in GenShen GC logs, where a large number of degenerated cycles were upgrading to full GC because the free-set progress was short of desired by 10-25%.
src/hotspot/share/gc/shenandoah/shenandoahMetrics.cpp line 52:
> 50: size_t free_actual = free_set->available();
> 51: // The sum of free_set->capacity() and ->reserved represents capacity of young in generational, heap in non-generational.
> 52: size_t free_expected = ((free_set->capacity() + free_set->reserved()) / 100) * ShenandoahCriticalFreeThreshold;
As an outsider, the units involved and what exactly is being calculated is pretty opaque. Why would we divide by 100 to compute free_expected and not do the same for free_actual? Do we care about integer division truncation? The default value of ShenandoahCriticalFreeThreshold is 1, so multiplying by it is a nop by default, which seems strange.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/23306#discussion_r1941436272
More information about the shenandoah-dev
mailing list