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. :)
Thanks,
Sangheon
>
More information about the hotspot-gc-dev
mailing list