RFR: 8253600: G1: Fully support pinned regions for full gc [v3]

[Stefan Johansson]

On Thu, 29 Oct 2020 19:51:55 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   can I get reviews for this change that implements "proper" support for pinned regions in the G1 full collector?
>> 
>> By proper I mean that at the end of gc, pinned regions contain the correct TAMS and bitmap markings under the TAMS so that dead objects within them are supported?
>> 
>> Currently all (pinned) regions have their TAMS set to bottom() and their bitmap above TAMS cleared (at least logically :) ). This works as long objects within these regions can't be dead as it is the case now:
>> - humongous regions are either live or fully reclaimed.
>> - all other pinned regions are archive regions at the moment that are always treated as fully live (and do not contain dead objects).
>> 
>> This change is a requirement for fixing JDK-8253081 as some earlier change made it possible to have dead objects within open archive regions. It also enables supporting removal of gclocker use for g1, i.e. using region pinning.
>> 
>> Based on the PR#808 (https://github.com/openjdk/jdk/pull/808).
>> 
>> Testing: tier1-8, testing with prototype for region pinning, testing with prototype for JDK-8253081.
>> Performance testing: no regressions
>> 
>> Some comments for questions that might come up during review:
>> 
>> - how does this work with the bitmaps now:
>>   - at start of full gc the next bitmap is cleared
>>   - full gc marks the next bitmap
>>   - for all pinned regions, keep TAMS and top() (*), otherwise set TAMS to bottom
>>   - swap bitmaps
>>   - clear next bitmap for next marking
>> 
>> (*) this means that from a usage POV pinned regions are considered full. This is inaccurate, but sufficient: full gc clears all remembered sets anyway, so we do not need that information for gc efficiency purposes anyway to evacuate later. The next marking before old gen evacuation will update it to the correct values anyway. G1 does not support allocation into "holes" in pinned regions that can be open archive only at this time too, so there is no need to be more exact.
>> 
>> - use of a region attribute table for phase 2+ only: compared to before we need fast access to information whether a given reference goes into a pinned region (as opposed to an archive region) wrt to adjusting that pointer to avoid doing work for these references.
>> 
>> Phase 1 marking could have used this information for the do-we-need-to-preserve-the-mark check too: however this would have required g1 to add an extra another pass over all regions to update that. This seemed slower than just checking this information "more slowly" for the objects that need mark preservation. Tests showed that this is the case for <0.00% (yeah, these references that need mark preservation are rounding errors in cases it matters) of overall references, so I did not add that pass.
>> (Additionally g1 full gc is a last-ditch effort, and while marking takes a significant time, it does not completely dominate it).
>> 
>> I.e. the second clause in the condition of this hunk is intentionally slower than could be:
>> @@ -52,7 +52,9 @@ inline bool G1FullGCMarker::mark_object(oop obj) {
>>   // Marked by us, preserve if needed.
>>   markWord mark = obj->mark();
>>   if (obj->mark_must_be_preserved(mark) &&
>>       // It is not necessary to preserve marks for objects in pinned regions because
>>       // we do not change their headers (i.e. forward them).
>>       !G1CollectedHeap::heap()->heap_region_containing(obj)->is_pinned()) {
>>     preserved_stack()->push(obj, mark);
>>   }
>> - there is no code yet that checks for empty pinned regions yet. Only JDK-8253081 introduces that because still all contents of all archive regions are live forever.
>> 
>> Also please note that the 51b297b change is from the #808 change.
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into 8253600-full-gc-pinned-region-support
>  - Merge branch 'master' into 8253600-full-gc-pinned-region-support
>  - sjohanss review
>    
>    Also remove _archive_allocator_map et al as the new attribute table
>    implements the same functionality also suggested by sjohanss in
>    private.
>  - Initial import
>  - Initial import

Thanks Thomas for addressing my concerns around the archive-map and the new region-attr overlap. I think this looks much better. 

Just a few additional comments.

src/hotspot/share/gc/g1/g1FullCollector.cpp line 169:

> 167:   PrepareRegionsClosure cl(this);
> 168:   _heap->heap_region_iterate(&cl);
> 169: 

I know the old iteration tearing down the region sets was also done by a single thread, but I wonder if it would make sense to do it in parallel here. I guess we could file a CR to investigate if it would be worth doing.

src/hotspot/share/gc/g1/g1FullGCMarker.inline.hpp line 57:

> 55:       // It is not necessary to preserve marks for objects in pinned regions because
> 56:       // we do not change their headers (i.e. forward them).
> 57:       !_collector->is_in_pinned_or_closed(obj)) {

Even if it's correct, I think we should add a `is_in_pinned(obj)` and use it here, since we early out for objects in closed above.

src/hotspot/share/gc/shared/collectedHeap.hpp line 515:

> 513:   // Is the given object inside a CDS archive area?
> 514:   virtual bool is_archived_object(oop object) const { return false; }
> 515: 

I think this is a good addition, but to be consistent with the other functions, I think the implementation should be moved to the cpp-file.

src/hotspot/share/gc/g1/g1FullCollector.hpp line 101:

> 99:   bool is_in_pinned_or_closed(oop obj) const { return _region_attr_table.is_pinned_or_closed(cast_from_oop<HeapWord*>(obj)); }
> 100:   bool is_in_closed(oop obj) const { return _region_attr_table.is_closed_archive(cast_from_oop<HeapWord*>(obj)); }
> 101: 

Can't decide if it's worth adding a inline.hpp for those. Just throwing it out there in case you thought about it as well :)

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

PR: https://git.openjdk.java.net/jdk/pull/824