RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
Roman Kennke
rkennke at redhat.com
Fri Apr 13 20:08:35 UTC 2018
Hi Per,
I'm late to the party, somehow this totally went below my radar. The
week was a bit hectic here.
I verified that it hasn't broken aarch64. And even though it's already
pushed, I like the change. I'd probably have done it almost 100% the
same ;-)
Thanks for doing it!
Cheers,
Roman
> Hi Martin & Roman,
>
> I just want to highlight that this change touches platform code for
> s390/ppc and aarch64, so please verify that it doesn't break your builds.
>
> cheers,
> Per
>
> On 04/10/2018 01:42 PM, Per Liden wrote:
>> As part of the effort to make GCs more pluggable, the G1-specific data
>> in JavaThread should be moved out into a more appropriate abstraction.
>>
>> This is the second step (building on JDK-8201316), which introduces
>> GCThreadLocalData, an opaque data area in Thread. Each GC is free to
>> decide the internal structure and contents of this area.
>>
>> With this in place, we can remove G1's thread-local SATB queue and
>> dirty card queue from JavaThread and instead let G1 use the data area
>> provided by GCThreadLocalData to store these.
>>
>> Other GCs that wants to store pre-thread information (e.g. ZGC and
>> Shenandoah) are encouraged to look at what G1 is doing here and use
>> that as a template/example.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8201318
>> Webrev: http://cr.openjdk.java.net/~pliden/8201318/webrev.0/
>>
>> Testing: hs-tier{1-3}
>>
>> /Per
>>
More information about the hotspot-dev
mailing list