RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread

[Per Liden]

Hi Roman,

On 04/13/2018 10:08 PM, Roman Kennke wrote:
> 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, I'm happy you like it ;)

/Per

> 
> 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
>>>
> 
>