RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
david.holmes at oracle.com
Mon Dec 4 12:56:02 UTC 2017
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
>>> 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
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.
>>> 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