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

[Robbin Ehn]

Hi Per,

Had quick look, what I saw looked good. (not a full review)
Is there a reason for moving the gc data to 'zero offset' in Thread?

/Robbin

On 2018-04-10 14:51, Per Liden wrote:
> A couple of commits were pushed, which causes conflicts with this change, so here's a rebased version:
> 
> http://cr.openjdk.java.net/~pliden/8201318/webrev.1
> 
> cheers,
> Per
> 
> On 04/10/2018 02:26 PM, Per Liden wrote:
>> 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
>>>