RFR: 8017163: G1: Refactor remembered sets [v11]

[Thomas Schatzl]

On Mon, 14 Jun 2021 10:51:36 GMT, Stefan Johansson <sjohanss at openjdk.org> wrote:

>> Thomas Schatzl has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:
>> 
>>  - Merge branch 'master' into submit/8017163-refactor-remembered-set
>>  - Merge branch 'master' of gh:openjdk/jdk into tschatzl:submit/8017163-refactor-remembered-set
>>  - Always have power-of-2 Howl buckets to avoid memory waste (these entries have never been used before, just taking a small amount of memory)
>>  - Improved documentation
>>  - Improve comment
>>  - Rename G1CardSetContainerOnHeap to G1CardSetContainer on popular demand
>>  - sjohanss-review 3
>>  - Merge branch 'master' of gh:openjdk/jdk into 8017163-refactor-remembered-set
>>  - More cleanup after sjohanss comments
>>  - Rename FOUND
>>  - ... and 6 more: https://git.openjdk.java.net/jdk/compare/4d1cf51b...338b4829
>
> test/hotspot/gtest/gc/g1/test_g1CardSet.cpp line 421:
> 
>> 419:   const uint CardsPerRegion = 16384;
>> 420:   const double FullCardSetThreshold = 1.0;
>> 421:   const uint BitmapCoarsenThreshold = 1.0;
> 
> Would it make sense to run this test with a few different config thresholds? To test the different levels of the card-set. If I understand those thresholds correct this card-set will never consider a region to be coarsend or full. I get that the accounting might turn into everything being "found" rather than added, but might be worth testing.

Since that test randomly adds cards, it is very hard to calculate the expected number of cards for verification if we do not know where the coarsening exactly happens. This is very complicated to test, and other tests already test the coarsening, although not in an MT context, so I would like to not spend the time for either a brittle or useless test.

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

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