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

[Per Liden]

For small/trivial changes like this, Vladimir K informed me that I can 
send an upstream request, with subject [Graal upstream] and the 
patch/webrev to hotspot-compiler-dev.

/Per

On 04/19/2018 08:41 AM, dean.long at oracle.com wrote:
> 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
>>>
>