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

[Per Liden]

Hi Dean,

Sorry for the delay. There was some confusion around how to deal with 
this, but that has now been sorted out. I just sent the Graal upstream 
request to hotspot-compiler-dev. Feel free to pick it up.

cheers,
Per

On 04/19/2018 07:20 AM, dean.long at oracle.com wrote:
> I don't see a PR to get this upstream to Graal.  Is someone working on 
> it?  If not I can do it.
> 
> dl
> 
> On 4/15/18 2:27 PM, Doug Simon wrote:
>>
>>> On 15 Apr 2018, at 12:03, Andrew Haley <aph at redhat.com> wrote:
>>>
>>> On 04/14/2018 01:29 PM, Doug Simon wrote:
>>>>> In the meantime, be aware that Graal development on JDK11 is broken
>>>>> until this change is pushed to Graal.  As far as I know, Graal changes
>>>>> are supposed to be reviewed by Graal developers.
>>>> Changes like this one can be reviewed by anyone in the HotSpot
>>>> compiler team or Graal team.
>>> That's good to know.  The change is obviously correct, but it needs to
>>> be handled correctly.
>> Right. The GitHub Graal code base needs to work from JDK 8 (with a 
>> JVMCI patch) onwards. We have just recently switched to using 
>> multi-release jars to make this process saner and avoid the use of 
>> reflection to access version dependent API. When GitHub Graal 
>> snapshots are taken for syncing the code into OpenJDK, the versioned 
>> directories are flattened to the non-versioned root directory 
>> following the same logic that would be applied when resolving a 
>> versioned class at runtime. The flattenmultireleasesources command[1] 
>> was added to mx to facilitate this flattening.
>>
>> The particular change in this webrev is a good opportunity to make 
>> GraalHotSpotVMConfig versioned in this way. I'll make the necessary 
>> changes for this in GitHub Graal. Normally, no manual change should be 
>> made to OpenJDK Graal but in this case I think it's necessary so that 
>> OpenJDK testing of Graal won't break.
>>
>>> For my information, though, I presume "changes like this" means simple
>>> changes to JVMCI.  That right?
>> Sorry for my ambiguity. I meant that this is a simple change to both 
>> JVMCI and Graal and by now most HotSpot compiler developers should be 
>> able to review it. Of course, having a Graal developer look at it as 
>> well is recommended. The preferred way to do this is to open a PR at 
>> https://github.com/graalvm/mx/pulls.
>>
>> -Doug
>>
>> [1] 
>> https://github.com/graalvm/mx/commit/bad56c1101db758c3f8c6560fc62012c15be39e4 
>>
>>
>>> -- 
>>> Andrew Haley
>>> Java Platform Lead Engineer
>>> Red Hat UK Ltd. 
>>> <https://urldefense.proofpoint.com/v2/url?u=https-3A__www.redhat.com&d=DwICaQ&c=RoP1YumCXCgaWHvlZYR8PZh8Bv7qIrMUB65eapI_JnE&r=BmNY5KuefACTr_P43s8fXOXgNDkDiqlviyafeiVaP18&m=4ZggofCo53X0nV2fk4nYuyBqw3xG4MZTeRDFqVH-pnI&s=4mmTmtLnlPEwCZErTwYIz3N2z1cw2_X5GqZs0GCBYA8&e=> 
>>>
>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
>