RFR: 8306541: Refactor collection set candidate handling to prepare for JDK-8140326 [v11]

Albert Mingkun Yang ayang at openjdk.org
Thu May 11 14:55:51 UTC 2023


On Wed, 10 May 2023 10:44:46 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> Hi all,
>> 
>>   please review this refactoring of collection set candidate set handling.
>> 
>> The idea is to improve the interface to collection set candidates and prepare for having collection set candidates available at any time to evacuate them at any young collection.
>> 
>> These preparations to allow for multiple sources for these candidates (from the marking, as now, and from retained regions, i.e. evacuation failed regions as per [JDK-8140326](https://bugs.openjdk.org/browse/JDK-8140326)).
>> 
>> This patch only uses candidates from marking at this time.
>>  
>> Also moves gc efficiency out of HeapRegion and associate it to the list element as it's not used otherwise.
>>     
>> In detail:
>>     * the collection set candidates set is not temporarily allocated any more, but the candidate collection set object is available all the time.
>>     
>>     * G1CollectionSetCandidates is the main class, representing the current candidates. Contains the "from marking" candidate list only (at this point).
>>     
>>     * there are several additional helper sets/lists
>>       * G1CollectionSetRegionList: list of HeapRegion*, typically sorted by efficiency (but not necessarily). Also does not contain gc efficiences.
>>       * G1CollectionCandidateList: list of candidates, i.e. HeapRegion* with their gc efficiency. Building block for the actual collection set candidates list.
>>     
>> All these sets implement C++ iterators for simpler use in various places.
>>     
>> Testing:
>>  - this patch only: tier1-3, gha
>>  - with JDK-8140326 tier1-7 (or 8?)
>> 
>> Thanks,
>>   Thomas
>
> Thomas Schatzl has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed assert that is useless for now

src/hotspot/share/gc/g1/g1CollectionSet.hpp line 152:

> 150:   uint _survivor_region_length;
> 151: 
> 152:   G1CollectionSetRegionList _initial_old_regions;

Why is the whole list saved in the field? I'd expect initial-old-regions is a transient list used to move regions from candidate list to cset (live only inside `G1CollectionSet::finalize_old_part`).

`_initial_old_regions` and `_optional_old_regions` share some similarity on  the name, but semantically, it's closer to eden/survior regions, so sth like `uint _initial_old_region_length;`.

src/hotspot/share/gc/g1/g1CollectionSetCandidates.hpp line 173:

> 171: 
> 172:   // The number of regions from the last merge of candidates from the marking.
> 173:   uint _last_marking_candidates_length;

Looking at how it is used, I wonder if we can record `min_old_cset_length`, which is what is actually needed.

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 65:

> 63:                                            G1EvacFailureRegions* evac_failure_regions)
> 64:   : _g1h(g1h),
> 65:     _collection_set(collection_set),

Why is this needed?

src/hotspot/share/gc/g1/g1ParScanThreadState.cpp line 697:

> 695:                                                  G1EvacFailureRegions* evac_failure_regions) :
> 696:     _g1h(g1h),
> 697:     _collection_set(collection_set),

Can't find where this field is used.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/13666#discussion_r1191266212
PR Review Comment: https://git.openjdk.org/jdk/pull/13666#discussion_r1191258730
PR Review Comment: https://git.openjdk.org/jdk/pull/13666#discussion_r1191292905
PR Review Comment: https://git.openjdk.org/jdk/pull/13666#discussion_r1191293906


More information about the hotspot-dev mailing list