RFR: Coalesce and fill old, pinned regions after old gen final mark
Y. Srinivas Ramakrishna
ysr at openjdk.org
Tue Jul 5 22:40:38 UTC 2022
On Tue, 5 Jul 2022 22:16:22 GMT, William Kemper <wkemper at openjdk.org> wrote:
>> src/hotspot/share/gc/shenandoah/heuristics/shenandoahOldHeuristics.cpp line 215:
>>
>>> 213: region->begin_preemptible_coalesce_and_fill();
>>> 214: candidates[cand_idx]._region = region;
>>> 215: candidates[cand_idx]._garbage = 0;
>>
>> Newbie question:
>>
>> Assume that the object gets unpinned prior to the next marking, and assume hypothetically that the region in question had mostly garbage (let's pick 99% garbage for the sake of argument). At region unpinning, do we sort it into the right position of the garbage first list after recomputing its garbage field?
>>
>> In other words, I am wondering if we make the `_garbage` field indicate the correct value, but skip adding a pinned region to the collection set when the collection set is built? It looks like the protocol for meaning of the state `_cset_pinned`already accounts for regions being in the collection set while being pinned, so won't that protocol handle this already without having to sort pinned regions to the bottom of the garbage-first list or avoiding adding them to the collection set?
>
> Those are good questions and I thought about letting the pinned region sort naturally on the amount of actual garbage, but I rejected that for two reasons:
> * Shenandoah only updates the pin/unpinned status during a collection cycle. Once we have "candidates" for mixed collection, we won't run another old cycle before mixed collections are complete. This behavior could be changed, but it would be a much bigger change.
> * It's critical that we fill in the dead objects for regions that are not candidates for mixed collections. The remembered set scan will use the mark bit map to avoid dead objects only _while_ there are mixed collection candidates. We could make a change to fill dead objects when pinned regions are rejected from the mixed collection set, but that would add complexity to the mixed collection cycle. Sorting the pinned regions as though they had no garbage lumps them in nicely with other regions that need to be filled.
Re first bullet: fair enough; one can perhaps revisit later, in the fullness of time, to see if the collection set can be more dynamic even in the presence of pinning -- which might arguably help certain adversarial pinning scenarios.
Re second bullet, I didn't realize that for old regions in the (mixed) collection set we run a special scanning protocol that examines live objects only. Why make the distinction between members of the collection set vs those not in the collection set? I might have either always used the liveness information (whenever valid and available) for all regions, or (my preference) never do that and always use the fillers for dead objects which latter would therefore never produce cross-generation pointers (on account of being primitive arrays). May be there are advantages to making this distinction that I am missing.
If not already documented somewhere in the RS scanning code, this might be worth documenting, may be?
-------------
PR: https://git.openjdk.org/shenandoah/pull/149
More information about the shenandoah-dev
mailing list