RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
Magnus Ihse Bursie
magnus.ihse.bursie at oracle.com
Mon Dec 4 15:45:52 UTC 2017
On 2017-12-04 13:56, David Holmes wrote:
> On 4/12/2017 10:44 PM, Magnus Ihse Bursie wrote:
>> On 2017-12-04 12:17, David Holmes wrote:
>>> Hi Magnus,
>>> On 4/12/2017 9:06 PM, Magnus Ihse Bursie wrote:
>>>> JDK-8190484 was created as a follow-up bug to the unification of
>>>> the duplicated jvm.h, jvm_md.h and jmm.h, to determine the proper
>>>> location of these files. This has now been decided to be
>>>> hotspot/share/include and hotspot/os/$OS/include, respectively.
>>>> This patch moves the relevant files there, but since this also
>>>> frees up the src/$MODULE/native/include directories for the
>>>> original purpose, it also unifies and simplifies the build logic
>>>> for these directories, so that common code is executed for all
>>>> modules to just copy any exported header files from these
>>>> directories, should they exist.
>>>> I'm intending to push this to jdk-hs.
>>> Do you want this in 10 or 11? If you want 10 then you need to push
>>> to jdk/jdk as there may not be another snapshot from jdk/hs.
>> It was targeted at 11 in the JBS issue. I don't have a strong opinion
>> on forcing this into JDK 10. Also, one of the fixes it depended on
>> was not yet integrated from jdk/hs to jdk/jdk.
>> But if you think it should go into JDK 10 and jdk/jdk, just let me
>> know and I'll move the changeset there, and await the next jdk/hs ->
>> jdk/jdk integration.
> Things are not quite working that way at the moment - see  - hs has
> potentially taken its last snapshot before JDK 10 is forked. If this
> must go into 10 then it has to be pushed direct to jdk/jdk. If it may
> go in 10 or 11, then it can go into jdk/hs (and it will end up in 10
> if there is a second snapshot, else 11). If it is only intended for 11
> then it must not be pushed until after the Dec 14 fork of JDK 10.
> I have no opinion one way or the other.
This patch requires a fix which is currently only in jdk/hs. I can push
this to jdk/jdk instead, but only after that fix has been pushed from
jdk/hs to jdk/jdk. From the mail you sent, it seems like it can
potentially take all the time up until Dec 14. If that happens, I can't
get this in jdk 10 no matter what I do. But I can hold on for a while
and see if jdk/hs ends up in jdk/jdk in time before Dec 14, and if so,
push this fix there. If it doesn't, well, seems like there's no chance
this can get in jdk 10 whatever.
I don't think it's "intended" for 11 as much as it's a problem if it
goes into 10, more than that someone at some point thought there would
not be time left to fix it in jdk 10 and re-targeted it at 11.
(Something which I didn't notice until after I written the patch.)
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the
>>> flow on cleanups.
More information about the build-dev