RFR: Enforce max regions [v3]

Kelvin Nilsen kdnilsen at openjdk.org
Wed Dec 7 21:23:06 UTC 2022


On Wed, 7 Dec 2022 18:36:39 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> Kelvin Nilsen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix white space and add an assertion
>
> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 986:
> 
>> 984: }
>> 985: 
>> 986: size_t ShenandoahGeneration::adjusted_unaffiliated_regions() {
> 
> You can const this method too.

Thanks.  I'll change this.

> src/hotspot/share/gc/shenandoah/shenandoahGeneration.cpp line 988:
> 
>> 986: size_t ShenandoahGeneration::adjusted_unaffiliated_regions() {
>> 987:   assert(adjusted_capacity() > used_regions_size(), "adjusted_unaffiliated_regions() cannot return negative");
>> 988:   return (adjusted_capacity() - used_regions_size()) / ShenandoahHeapRegion::region_size_bytes();
> 
> So, just to be clear, this is the number of unaffiliated regions that can _potentially_ be affiliated with this region. I assume it isn't the case that that number of unaffiliated free regions actually exist?
> 
> If the answer is "no, that number of unaffiliated free regions do exist" would it be worth asserting that invariant here (or may be because this is all concurrent with allocations, no such guarantees will ever hold anyway, so it's futile to assert such invariants?).
> 
> Indeed this question ties in with my comment further up where you do a "<=" comparison with 0 on the return value from here.

Yes.  That is accurate.  This is the number of regions that are currently affiliated with FREE, which are eligible to be affiliated as part of this generation if we have reason to do so.  If this value is zero, then the entire adjusted_capacity is consumed by the regions already affiliated with this generation, and we are not allowed to move any more FREE regions into this generation.

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

PR: https://git.openjdk.org/shenandoah/pull/179


More information about the shenandoah-dev mailing list