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

[dean.long at oracle.com]

Oh, was there a discussion I missed where it was sorted out?  I was 
expecting a PR at https://github.com/graalvm/mx/pulls, not upstream 
request sent to hotspot-compiler-dev.

dl

On 4/18/18 11:34 PM, Per Liden wrote:
> 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
>>