RFR: 8229044: G1RedirtyCardsQueueSet should be local to a collection

[Kim Barrett]

> On Aug 14, 2019, at 6:17 PM, sangheon.kim at oracle.com wrote:
> 
> Hi Kim,
> 
> On 8/3/19 12:22 PM, Kim Barrett wrote:
>>> On Aug 3, 2019, at 3:10 PM, Thomas Schatzl <thomas.schatzl at oracle.com> wrote:
>>> 
>>> Hi,
>>> 
>>> On 03.08.19 01:43, Kim Barrett wrote:
>>>> Please review this change to the use of G1RedirtyCardsQueueSet.
>>>> Rather than a singleton instance in the G1CollectedHeap that is reused
>>>> by each collection pause, we now (stack) allocate one for use by the
>>>> current collection pause.
>>>> CR:
>>>> https://bugs.openjdk.java.net/browse/JDK-8229044
>>>> Webrev:
>>>> http://cr.openjdk.java.net/~kbarrett/8229044/open.00/
>>>> Testing:
>>>> mach5 tier1-5
>>>  looks good. Thanks.
>>> 
>>> I was wondering whether at some point we should extract all transient GC state coupled with the actual algorithms applied into a separate class. But that's probably something for the future :)
>>> 
>>> Thomas
>> Thanks.
>> 
>> I thought about putting the redirty set directly in the ParScanThreadStateSet with an
>> accessor and passing that set to more places, but that seemed like it would make it
>> more difficult to understand the usage of the ParScanThreadState[Set].
>> 
>> I also thought about putting it in the EvacuationInfo, but what’s there seems to be
>> accounting stuff and not otherwise interesting data structures.  And again, I’d probably
>> prefer to extract the redirty set to pass into call trees that need it and not all the other
>> stuff.
>> 
>> I think part of the problem is that there’s just a lot of varied state shared between various
>> largish pieces of the collector.  Finding ways to reduce that would be nice, but detangling
>> is often hard work.
> Looks good.
> 
> And it would be really nice if above ideas are accomplished. :)
> 
> Thanks,
> Sangheon

Thanks.