RFR: 8348595: GenShen: Fix generational free-memory no-progress check [v2]

Kelvin Nilsen kdnilsen at openjdk.org
Fri Feb 7 23:59:52 UTC 2025


On Tue, 4 Feb 2025 15:50:59 GMT, Paul Hohensee <phh at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to reviewer feedback
>>   
>>   In testing suggested refinements, I discovered a bug in original
>>   implementation.  ShenandoahFreeSet::capacity() does not represent the
>>   size of young generation.  It represents the total size of the young
>>   regions that had available memory at the time we most recently rebuilt
>>   the ShenandoahFreeSet.
>>   
>>   I am rerunning the performance tests following this suggested change.
>
> 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.

ShenandoahCriticalFreeThreshold represents a percentage of the "total size".  To calculate N% of the young generation size, we divide the generation size by 100 and then multiply by ShenandoahCriticalFreeThreshold.  This code is a bit different in the most recent revision.  Do you think it needs a comment?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/23306#discussion_r1947335561


More information about the shenandoah-dev mailing list