RFR: 8256265: G1: Improve parallelism in regions that failed evacuation [v2]

[Thomas Schatzl]

On Tue, 13 Sep 2022 08:30:51 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2948:
>> 
>>> 2946: 
>>> 2947: void G1CollectedHeap::clear_bitmap_for_region(HeapRegion* hr, bool update_tams) {
>>> 2948:   concurrent_mark()->clear_bitmap_for_region(hr, update_tams);
>> 
>> Instead of adding one more arg, I wonder if it's clearer to move the operation on `tams` to higher-level caller(s).
>
> I agree with Albert, I think moving `hr->note_end_of_clearing();` out of `G1ConcurrentMark::clear_bitmap_for_region()` and handle it where needed is a cleaner approach.

This is a workaround for now as I intend to make `G1ConcurrentMark` owner of TAMSes (like TARSes) and then remove that clumsy workaround (i.e. `HeapRegion::note_end_of_clearing` will be empty/obsolete and that call removed).

Beginning with that change the TAMS of a region should be part of the bitmap of that region, so the additional parameter for `clear_bitmap_for_region` seems obvious to me. The reason why this parameter is actually needed becomes clear with listing the usage locations.

* `G1ClearBitmapHRClosure` which is a helper of `G1ConcurrentMark´; obviously that one may access TAMSes directly as well as the bitmap.
* `G1RemSet::G1ClearBitmapClosure` which clears bitmaps for to-be-evacuated old regions. Their TAMS needs to be reset obviously as they will be evacuated and freed (in the regular case). Actually also only required because of the bitmap reuse for evacuation failure.
* `ClearRetainedRegionBitmaps::ClearRetainedRegionBitmapsClosure` is that odd-one-out here; as we reuse the bitmap for evacuation failure we need to ask the owner of the bitmap/tams to please not do the usual thing. 

The name `update_tams` for the parameter is probably bad, I'll rename it to `clear_tams`, and `HeapRegion::note_end_of_marking` to something similar while the discussion is ongoing.

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

PR: https://git.openjdk.org/jdk/pull/9980