RFR: 8201318: Introduce GCThreadLocalData to abstract GC-specific data belonging to a thread
dean.long at oracle.com
dean.long at oracle.com
Thu Apr 19 06:41:45 UTC 2018
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.
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.
> 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.
>> 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
>>>>>> 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 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.
>>>> Andrew Haley
>>>> Java Platform Lead Engineer
>>>> Red Hat UK Ltd.
>>>> EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671
More information about the graal-dev