RFR: Usage tracking cleanup
William Kemper
wkemper at openjdk.org
Tue Apr 18 00:25:26 UTC 2023
On Mon, 17 Apr 2023 23:25:54 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 732:
>>
>>> 730: // * There are three sources of waste:
>>> 731: // * The padding used to align a PLAB on card size
>>> 732: // * Region's free is less than minimum TLAB size and is retired
>>
>> I think there are two notions "retirement" in existing code. There is a temporary retirement that applies only until we rebuild the free set (at end of this gc, or start of next evac). And there is a permanent retirement that places a fill object into the remnant of free memory so that the memory is no longer free. (maybe this distinction is not on the master branch.) The permanent retirement lasts until this region is collected. The accounting is different. In both cases, we increase ShenandoahFreeSet::used. In the permanent case, we also increase the relevant generation:used.
>
> I'm not sure that we really need both approaches. The rationale for permanent retirement is that we don't want to repeatedly discover and re-retire old-gen regions that are scattered throughout the heap. This is less of a problem with young-gen regions, because regions that are retired once will either soon be promoted or they will be collected.
I'm not familiar with the 'permanent' retirement - I don't think that is on `master`. We do fill in LABs with objects when they are retired, but that memory was already 'used' as soon as the LAB was allocated. These changes don't actually touch how the freeset tracks its own usage. What's been hoisted out is only the accounting for generation/heap usage, allocation rate and what the pacer uses. If the 'permanent' retirement includes the filler object in the `actual_size` of the allocation then this new function will account for it as expected. It _should_ do this so that sum of region::used equals the used for a generation/heap.
-------------
PR Review Comment: https://git.openjdk.org/shenandoah/pull/260#discussion_r1169373120
More information about the shenandoah-dev
mailing list