RFR: Coalesce and fill old, pinned regions after old gen final mark

[William Kemper]

On Tue, 5 Jul 2022 22:37:34 GMT, Y. Srinivas Ramakrishna <ysr at openjdk.org> wrote:

>> 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?

I think I explained the remembered set scanning protocol poorly. It doesn't distinguish regions that are in the collection set. Rather, if there are mixed evacuations pending it "knows" the mark bitmap data is stable (i.e., marking of old regions is complete). The rset scan must use the bitmap here precisely because it _does not_ fill dead objects in old regions which are candidates for the mixed collection set. It expects these regions to eventually be reclaimed, so the effort of filling in the garbage would be wasted. Certainly, the code would be simpler if we always used the mark bitmap or always filled dead objects, but this hybrid approach has performance advantages:
 * It doesn't require a secondary bitmap during concurrent marking of old.
 * We don't fill in dead objects for regions that are destined to be reclaimed.
 
There is some discussion in [this comment from shenandoahScanRemembered]( https://github.com/openjdk/shenandoah/blob/master/src/hotspot/share/gc/shenandoah/shenandoahScanRemembered.inline.hpp#L501).

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

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