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

[Y. Srinivas Ramakrishna]

On Tue, 5 Jul 2022 22:58:12 GMT, William Kemper <wkemper at openjdk.org> wrote:

>> 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).

OK thanks for the patient explanation! The performance advantage of the hybrid scheme that you point out seems plausible for regions that are dominated by garbage.

The change looks good to me; reviewed!

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

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