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

[Vladimir Kozlov]

Yes, that was discussion I mentioned on our meeting with Labs. I proposed to send such request to our group with [Graal 
upstream] in subject.

My proposal was for compiler group to sponsor small upstream Graal changes from other groups after they pushed it into 
OpenJDK. We will create PR and handle review process (I think we need to include original author in PR review too).

Changes should be pushed upstream before next "Graal update" pushed into OpenJDK. Changes could be modified after review 
- it is fine since we overwrite Graal code in OpenJDK anyway with each sync.

That is only way I see we can keep code in OpenJDK working all time and let changes from other groups move forward faster.

The only issue I see is we have to handle Graal support for JDK 8 when we change VM structures in current JDK which 
other group usually don't include in their changes. We have to teach them eventually.

I think this will happen not frequently and we can handle it.

Note, this only applies for small changes like current one. For big Graal changes authors have to prepare PR review them 
self before pushing into Graal and OpenJDK (we can help them to prepare and learn process) because they know changes the 
best.

Regards,
Vladimir

On 4/18/18 11:41 PM, 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
>>>
>