RFR: 8229044: G1RedirtyCardsQueueSet should be local to a collection

sangheon.kim at oracle.com sangheon.kim at oracle.com
Wed Aug 14 22:17:34 UTC 2019

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. :)



More information about the hotspot-gc-dev mailing list