RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie
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.

Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
WebRev:
http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01

/Magnus
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

David Holmes
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.

> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 

Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow
on cleanups.

Thanks,
David

>
> /Magnus
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie

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.

/Magnus

>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>
>
> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow
> on cleanups.
>
> Thanks,
> David
>
>>
>> /Magnus

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

David Holmes
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 [1] - 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.

David

[1]
http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html

> /Magnus
>
>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>
>>
>>
>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the flow
>> on cleanups.
>>
>> Thanks,
>> David
>>
>>>
>>> /Magnus
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie
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 [1] - 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.)

/Magnus


>
> David
>
> [1]
> http://mail.openjdk.java.net/pipermail/hotspot-dev/2017-December/029474.html
>
>> /Magnus
>>
>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>
>>>
>>>
>>>
>>> Seems okay for the jvm.h/jmm.h changes. I couldn't follow all the
>>> flow on cleanups.
>>>
>>> Thanks,
>>> David
>>>
>>>>
>>>> /Magnus
>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Erik Joelsson
In reply to this post by Magnus Ihse Bursie
Hello Magnus,

The <module>-copy targets are currently only being generated for modules
that have make/copy/Copy-<module>.gmk makefiles present. By removing
make/copy/Copy-jdk.accessibility.gmk and
make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created
so the logic in CopyCommon will not be executed.

This can be solved in two ways. Either generate <module>-copy rules for
all modules or leave the files there with just include CopyCommon.gmk as
the only contents. I would recommend the latter for now. Most modules do
not need to copy anything.

Another minor note, when ordering include directories, I usually put the
most specific dir first, so that any platform specific header file with
the same name would override a more general one. We don't have that
situation in this case, but I still think it's good practice.

Regarding where to push this. IMO, if it depends on a change currently
in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really
matter that much.

/Erik


On 2017-12-04 03:06, 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.
>
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
> WebRev:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>
> /Magnus

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Mandy Chung


On 12/4/17 9:33 AM, Erik Joelsson wrote:

> Hello Magnus,
>
> The <module>-copy targets are currently only being generated for
> modules that have make/copy/Copy-<module>.gmk makefiles present. By
> removing make/copy/Copy-jdk.accessibility.gmk and
> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer created
> so the logic in CopyCommon will not be executed.
>
> This can be solved in two ways. Either generate <module>-copy rules
> for all modules or leave the files there with just include
> CopyCommon.gmk as the only contents. I would recommend the latter for
> now. Most modules do not need to copy anything.

Is it possible to generate <module>-copy rules for module where
src/<module>/{share, $OS}/include directory or
make/copy/Copy-<module>.gmk is present?

>
> Another minor note, when ordering include directories, I usually put
> the most specific dir first, so that any platform specific header file
> with the same name would override a more general one. We don't have
> that situation in this case, but I still think it's good practice.
>
> Regarding where to push this. IMO, if it depends on a change currently
> in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't really
> matter that much.
>

I would love this in JDK 10 if time permits and I am happy to see Coleen
retarget it to 10.  This is a really nice clean up that shows the
benefit from JEP 201 w.r.t. exported native header files.   But this is
not a must for JDK 10 and if it can't make 10, it's okay for 11.

Mandy


> /Erik
>
>
> On 2017-12-04 03:06, 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.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>> WebRev:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>
>> /Magnus
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie
On 2017-12-04 19:17, mandy chung wrote:

>
>
> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>> Hello Magnus,
>>
>> The <module>-copy targets are currently only being generated for
>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>> removing make/copy/Copy-jdk.accessibility.gmk and
>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>> created so the logic in CopyCommon will not be executed.
>>
>> This can be solved in two ways. Either generate <module>-copy rules
>> for all modules or leave the files there with just include
>> CopyCommon.gmk as the only contents. I would recommend the latter for
>> now. Most modules do not need to copy anything.
>
> Is it possible to generate <module>-copy rules for module where
> src/<module>/{share, $OS}/include directory or
> make/copy/Copy-<module>.gmk is present?
Technically, it's of course possible. But it does not fit very well with
the current DeclareRecipesForPhase. I agree with Erik, that for now the
reasonable approach is to have files that only include CopyCommon. We
can consider for future updates if it's worth generalizing this.

Updated webrev that restores the removed Copy-$MODULE.gmk files:
http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02

>>
>> Another minor note, when ordering include directories, I usually put
>> the most specific dir first, so that any platform specific header
>> file with the same name would override a more general one. We don't
>> have that situation in this case, but I still think it's good practice.
>>
>> Regarding where to push this. IMO, if it depends on a change
>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't
>> really matter that much.
>>
>
> I would love this in JDK 10 if time permits and I am happy to see
> Coleen retarget it to 10.  This is a really nice clean up that shows
> the benefit from JEP 201 w.r.t. exported native header files.   But
> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.

Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as
the needed fixes are integrated from jdk/hs.

/Magnus

>
> Mandy
>
>
>> /Erik
>>
>>
>> On 2017-12-04 03:06, 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.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>> WebRev:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>>
>>> /Magnus
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Mandy Chung


On 12/4/17 12:40 PM, Magnus Ihse Bursie wrote:
> Technically, it's of course possible. But it does not fit very well
> with the current DeclareRecipesForPhase. I agree with Erik, that for
> now the reasonable approach is to have files that only include
> CopyCommon. We can consider for future updates if it's worth
> generalizing this.
>

Okay with me.   It'd be good if we can consider this in the future so
that it avoids creating Copy-<module>.gmk for just the include header case.

> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>

Looks good.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon
> as the needed fixes are integrated from jdk/hs.
>

Thank you.

Mandy

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Erik Joelsson
In reply to this post by Magnus Ihse Bursie
Looks good.

/Erik


On 2017-12-04 12:40, Magnus Ihse Bursie wrote:

> On 2017-12-04 19:17, mandy chung wrote:
>>
>>
>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>> Hello Magnus,
>>>
>>> The <module>-copy targets are currently only being generated for
>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>>> removing make/copy/Copy-jdk.accessibility.gmk and
>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>> created so the logic in CopyCommon will not be executed.
>>>
>>> This can be solved in two ways. Either generate <module>-copy rules
>>> for all modules or leave the files there with just include
>>> CopyCommon.gmk as the only contents. I would recommend the latter
>>> for now. Most modules do not need to copy anything.
>>
>> Is it possible to generate <module>-copy rules for module where
>> src/<module>/{share, $OS}/include directory or
>> make/copy/Copy-<module>.gmk is present?
> Technically, it's of course possible. But it does not fit very well
> with the current DeclareRecipesForPhase. I agree with Erik, that for
> now the reasonable approach is to have files that only include
> CopyCommon. We can consider for future updates if it's worth
> generalizing this.
>
> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>
>>>
>>> Another minor note, when ordering include directories, I usually put
>>> the most specific dir first, so that any platform specific header
>>> file with the same name would override a more general one. We don't
>>> have that situation in this case, but I still think it's good practice.
>>>
>>> Regarding where to push this. IMO, if it depends on a change
>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11
>>> doesn't really matter that much.
>>>
>>
>> I would love this in JDK 10 if time permits and I am happy to see
>> Coleen retarget it to 10.  This is a really nice clean up that shows
>> the benefit from JEP 201 w.r.t. exported native header files.   But
>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon
> as the needed fixes are integrated from jdk/hs.
>
> /Magnus
>
>>
>> Mandy
>>
>>
>>> /Erik
>>>
>>>
>>> On 2017-12-04 03:06, 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.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01
>>>>
>>>> /Magnus
>>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

David Holmes
In reply to this post by Magnus Ihse Bursie
Hi Magnus,

There may be a further wart here to resolve. From the "bump the
classfile version to 54" thread on jdk-dev:

---

 >>>> Don't you also need to update:
 >>>>
 >>>> jdk/src/java.base/share/native/include/classfile_constants.h
 >>>>
 >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
 >>>>
 >>> I cannot find any usages for this constant, nor
JVM_CLASSFILE_MINOR_VERSION. I will remove them.
 >>
 >> Okay. I don't know the history or use of this file, other than it
gets included into jvm.h to export the jvm interface to the jdk.
 >>
 >
> And classfile_constants.h is also distributed with the image. I am
> unsure of the intent/history. To play it safe i will just bump the
> number.
Hmmm - that seems wrong. jvm.h is not an exported external interface
AFAIK. And we just moved it so I don't think it will get distributed any
more. Hmm that also suggests that classfile_constants.h may be in the
wrong place ... I'll take this up elsewhere.

---

So is classfile_constants.h also in the wrong place? And should it be in
the image ??

David

On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:

> On 2017-12-04 19:17, mandy chung wrote:
>>
>>
>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>> Hello Magnus,
>>>
>>> The <module>-copy targets are currently only being generated for
>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>>> removing make/copy/Copy-jdk.accessibility.gmk and
>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>> created so the logic in CopyCommon will not be executed.
>>>
>>> This can be solved in two ways. Either generate <module>-copy rules
>>> for all modules or leave the files there with just include
>>> CopyCommon.gmk as the only contents. I would recommend the latter for
>>> now. Most modules do not need to copy anything.
>>
>> Is it possible to generate <module>-copy rules for module where
>> src/<module>/{share, $OS}/include directory or
>> make/copy/Copy-<module>.gmk is present?
> Technically, it's of course possible. But it does not fit very well with
> the current DeclareRecipesForPhase. I agree with Erik, that for now the
> reasonable approach is to have files that only include CopyCommon. We
> can consider for future updates if it's worth generalizing this.
>
> Updated webrev that restores the removed Copy-$MODULE.gmk files:
> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>
>
>>>
>>> Another minor note, when ordering include directories, I usually put
>>> the most specific dir first, so that any platform specific header
>>> file with the same name would override a more general one. We don't
>>> have that situation in this case, but I still think it's good practice.
>>>
>>> Regarding where to push this. IMO, if it depends on a change
>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11 doesn't
>>> really matter that much.
>>>
>>
>> I would love this in JDK 10 if time permits and I am happy to see
>> Coleen retarget it to 10.  This is a really nice clean up that shows
>> the benefit from JEP 201 w.r.t. exported native header files.   But
>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>
> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon as
> the needed fixes are integrated from jdk/hs.
>
> /Magnus
>
>>
>> Mandy
>>
>>
>>> /Erik
>>>
>>>
>>> On 2017-12-04 03:06, 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.
>>>>
>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>> WebRev:
>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>
>>>>
>>>> /Magnus
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie
On 2017-12-05 00:28, David Holmes wrote:
> Hi Magnus,
>
> There may be a further wart here to resolve.
But of course...

> From the "bump the classfile version to 54" thread on jdk-dev:
>
> ---
>
> >>>> Don't you also need to update:
> >>>>
> >>>> jdk/src/java.base/share/native/include/classfile_constants.h
> >>>>
> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
> >>>>
> >>> I cannot find any usages for this constant, nor
> JVM_CLASSFILE_MINOR_VERSION. I will remove them.
> >>
> >> Okay. I don't know the history or use of this file, other than it
> gets included into jvm.h to export the jvm interface to the jdk.
> >>
> >
>> And classfile_constants.h is also distributed with the image. I am
>> unsure of the intent/history. To play it safe i will just bump the
>> number.
> Hmmm - that seems wrong. jvm.h is not an exported external interface
> AFAIK. And we just moved it so I don't think it will get distributed
> any more. Hmm that also suggests that classfile_constants.h may be in
> the wrong place ... I'll take this up elsewhere.
>
> ---
>
> So is classfile_constants.h also in the wrong place? And should it be
> in the image ??

It sounds like it. :( It's only included from jvm.h (and
src/java.base/share/native/libverify/check_code.c) as far as I can tell.
So it should probably move with jvm.h.

The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper
promised me to make sure it ended up in jdk/jdk before RDP1). The good
news is that just moving classfile_constants.h is probably simple, I
assume all include paths are already correct.

Can you open a new bug (and/or handle it all by yourself)?

/Magnus

>
> David
>
> On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:
>> On 2017-12-04 19:17, mandy chung wrote:
>>>
>>>
>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>> Hello Magnus,
>>>>
>>>> The <module>-copy targets are currently only being generated for
>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>>>> removing make/copy/Copy-jdk.accessibility.gmk and
>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>>> created so the logic in CopyCommon will not be executed.
>>>>
>>>> This can be solved in two ways. Either generate <module>-copy rules
>>>> for all modules or leave the files there with just include
>>>> CopyCommon.gmk as the only contents. I would recommend the latter
>>>> for now. Most modules do not need to copy anything.
>>>
>>> Is it possible to generate <module>-copy rules for module where
>>> src/<module>/{share, $OS}/include directory or
>>> make/copy/Copy-<module>.gmk is present?
>> Technically, it's of course possible. But it does not fit very well
>> with the current DeclareRecipesForPhase. I agree with Erik, that for
>> now the reasonable approach is to have files that only include
>> CopyCommon. We can consider for future updates if it's worth
>> generalizing this.
>>
>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>
>>
>>>>
>>>> Another minor note, when ordering include directories, I usually
>>>> put the most specific dir first, so that any platform specific
>>>> header file with the same name would override a more general one.
>>>> We don't have that situation in this case, but I still think it's
>>>> good practice.
>>>>
>>>> Regarding where to push this. IMO, if it depends on a change
>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11
>>>> doesn't really matter that much.
>>>>
>>>
>>> I would love this in JDK 10 if time permits and I am happy to see
>>> Coleen retarget it to 10.  This is a really nice clean up that shows
>>> the benefit from JEP 201 w.r.t. exported native header files.   But
>>> this is not a must for JDK 10 and if it can't make 10, it's okay for
>>> 11.
>>
>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon
>> as the needed fixes are integrated from jdk/hs.
>>
>> /Magnus
>>
>>>
>>> Mandy
>>>
>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-12-04 03:06, 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.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>> WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>
>>>>>
>>>>> /Magnus
>>>>
>>>
>>

Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Mandy Chung


On 12/4/17 3:59 PM, Magnus Ihse Bursie wrote:

>
>>> And classfile_constants.h is also distributed with the image. I am
>>> unsure of the intent/history. To play it safe i will just bump the
>>> number.
>> Hmmm - that seems wrong. jvm.h is not an exported external interface
>> AFAIK. And we just moved it so I don't think it will get distributed
>> any more. Hmm that also suggests that classfile_constants.h may be in
>> the wrong place ... I'll take this up elsewhere.
>>
>> ---
>>
>> So is classfile_constants.h also in the wrong place? And should it be
>> in the image ??
>
> It sounds like it. :( It's only included from jvm.h (and
> src/java.base/share/native/libverify/check_code.c) as far as I can
> tell. So it should probably move with jvm.h.
>
> The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper
> promised me to make sure it ended up in jdk/jdk before RDP1). The good
> news is that just moving classfile_constants.h is probably simple, I
> assume all include paths are already correct.
>
> Can you open a new bug (and/or handle it all by yourself)?
>

classfile_constants.h was added to ${java.home}/include in JDK 6 [1] as
an exported interface.   It was intended for BCI native agent to use. 
With the removal of JVM TI demos, I think we should revisit if
classfile_constants.h should be distributed.

As far as JDK-8190484, the changeset adequately covers the non-exported
header files.

Mandy
[1] https://bugs.openjdk.java.net/browse/JDK-5107600
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

David Holmes
In reply to this post by Magnus Ihse Bursie
On 5/12/2017 9:59 AM, Magnus Ihse Bursie wrote:

> On 2017-12-05 00:28, David Holmes wrote:
>> Hi Magnus,
>>
>> There may be a further wart here to resolve.
> But of course...
>
>> From the "bump the classfile version to 54" thread on jdk-dev:
>>
>> ---
>>
>> >>>> Don't you also need to update:
>> >>>>
>> >>>> jdk/src/java.base/share/native/include/classfile_constants.h
>> >>>>
>> >>>> #define JVM_CLASSFILE_MAJOR_VERSION 53
>> >>>>
>> >>> I cannot find any usages for this constant, nor
>> JVM_CLASSFILE_MINOR_VERSION. I will remove them.
>> >>
>> >> Okay. I don't know the history or use of this file, other than it
>> gets included into jvm.h to export the jvm interface to the jdk.
>> >>
>> >
>>> And classfile_constants.h is also distributed with the image. I am
>>> unsure of the intent/history. To play it safe i will just bump the
>>> number.
>> Hmmm - that seems wrong. jvm.h is not an exported external interface
>> AFAIK. And we just moved it so I don't think it will get distributed
>> any more. Hmm that also suggests that classfile_constants.h may be in
>> the wrong place ... I'll take this up elsewhere.
>>
>> ---
>>
>> So is classfile_constants.h also in the wrong place? And should it be
>> in the image ??
>
> It sounds like it. :( It's only included from jvm.h (and
> src/java.base/share/native/libverify/check_code.c) as far as I can tell.
> So it should probably move with jvm.h.
>
> The bad news is that I just pushed JDK-8190484. (To jdk/hs; Jesper
> promised me to make sure it ended up in jdk/jdk before RDP1). The good
> news is that just moving classfile_constants.h is probably simple, I
> assume all include paths are already correct.
>
> Can you open a new bug (and/or handle it all by yourself)?

No need - Mandy just clarified this:

 > classfile_constants.h was added to ${java.home}/include in JDK 6 [1].
 > It was intended for BCI native agent to use.
 >
 > Mandy
 > [1] https://bugs.openjdk.java.net/browse/JDK-5107600

so that file should be co-located with jni.h and distributed in the image.

Thanks,
David

> /Magnus
>
>>
>> David
>>
>> On 5/12/2017 6:40 AM, Magnus Ihse Bursie wrote:
>>> On 2017-12-04 19:17, mandy chung wrote:
>>>>
>>>>
>>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>>> Hello Magnus,
>>>>>
>>>>> The <module>-copy targets are currently only being generated for
>>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>>>>> removing make/copy/Copy-jdk.accessibility.gmk and
>>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>>>> created so the logic in CopyCommon will not be executed.
>>>>>
>>>>> This can be solved in two ways. Either generate <module>-copy rules
>>>>> for all modules or leave the files there with just include
>>>>> CopyCommon.gmk as the only contents. I would recommend the latter
>>>>> for now. Most modules do not need to copy anything.
>>>>
>>>> Is it possible to generate <module>-copy rules for module where
>>>> src/<module>/{share, $OS}/include directory or
>>>> make/copy/Copy-<module>.gmk is present?
>>> Technically, it's of course possible. But it does not fit very well
>>> with the current DeclareRecipesForPhase. I agree with Erik, that for
>>> now the reasonable approach is to have files that only include
>>> CopyCommon. We can consider for future updates if it's worth
>>> generalizing this.
>>>
>>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>>
>>>
>>>>>
>>>>> Another minor note, when ordering include directories, I usually
>>>>> put the most specific dir first, so that any platform specific
>>>>> header file with the same name would override a more general one.
>>>>> We don't have that situation in this case, but I still think it's
>>>>> good practice.
>>>>>
>>>>> Regarding where to push this. IMO, if it depends on a change
>>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11
>>>>> doesn't really matter that much.
>>>>>
>>>>
>>>> I would love this in JDK 10 if time permits and I am happy to see
>>>> Coleen retarget it to 10.  This is a really nice clean up that shows
>>>> the benefit from JEP 201 w.r.t. exported native header files.   But
>>>> this is not a must for JDK 10 and if it can't make 10, it's okay for
>>>> 11.
>>>
>>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon
>>> as the needed fixes are integrated from jdk/hs.
>>>
>>> /Magnus
>>>
>>>>
>>>> Mandy
>>>>
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-12-04 03:06, 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.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>>> WebRev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

David Holmes
In reply to this post by Erik Joelsson
Magnus,

It seems these changes have broken all Windows builds:

Copying support/modules_include/jdk.accessibility/win32/bridge
/usr/bin/cp -fP
'/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
'/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge'
/usr/bin/cp: omitting directory
'/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
CopyCommon.gmk:62: recipe for target
'/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge'
failed
make[3]: ***
[/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge]
Error 1

David
-----

On 5/12/2017 7:26 AM, Erik Joelsson wrote:

> Looks good.
>
> /Erik
>
>
> On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
>> On 2017-12-04 19:17, mandy chung wrote:
>>>
>>>
>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>> Hello Magnus,
>>>>
>>>> The <module>-copy targets are currently only being generated for
>>>> modules that have make/copy/Copy-<module>.gmk makefiles present. By
>>>> removing make/copy/Copy-jdk.accessibility.gmk and
>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>>> created so the logic in CopyCommon will not be executed.
>>>>
>>>> This can be solved in two ways. Either generate <module>-copy rules
>>>> for all modules or leave the files there with just include
>>>> CopyCommon.gmk as the only contents. I would recommend the latter
>>>> for now. Most modules do not need to copy anything.
>>>
>>> Is it possible to generate <module>-copy rules for module where
>>> src/<module>/{share, $OS}/include directory or
>>> make/copy/Copy-<module>.gmk is present?
>> Technically, it's of course possible. But it does not fit very well
>> with the current DeclareRecipesForPhase. I agree with Erik, that for
>> now the reasonable approach is to have files that only include
>> CopyCommon. We can consider for future updates if it's worth
>> generalizing this.
>>
>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>
>>
>>>>
>>>> Another minor note, when ordering include directories, I usually put
>>>> the most specific dir first, so that any platform specific header
>>>> file with the same name would override a more general one. We don't
>>>> have that situation in this case, but I still think it's good practice.
>>>>
>>>> Regarding where to push this. IMO, if it depends on a change
>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11
>>>> doesn't really matter that much.
>>>>
>>>
>>> I would love this in JDK 10 if time permits and I am happy to see
>>> Coleen retarget it to 10.  This is a really nice clean up that shows
>>> the benefit from JEP 201 w.r.t. exported native header files.   But
>>> this is not a must for JDK 10 and if it can't make 10, it's okay for 11.
>>
>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as soon
>> as the needed fixes are integrated from jdk/hs.
>>
>> /Magnus
>>
>>>
>>> Mandy
>>>
>>>
>>>> /Erik
>>>>
>>>>
>>>> On 2017-12-04 03:06, 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.
>>>>>
>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>> WebRev:
>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>
>>>>>
>>>>> /Magnus
>>>>
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|

Re: RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include

Magnus Ihse Bursie
On 2017-12-05 06:59, David Holmes wrote:
> Magnus,
>
> It seems these changes have broken all Windows builds:
Oh f*ck. :-(

I didn't test my re-addition of the Copy-jdk.accessibility.gmk file
properly. :(

I opened https://bugs.openjdk.java.net/browse/JDK-8193045.

/Magnus

>
> Copying support/modules_include/jdk.accessibility/win32/bridge
> /usr/bin/cp -fP
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge'
>
> /usr/bin/cp: omitting directory
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/open/src/jdk.accessibility/windows/native/include/bridge'
> CopyCommon.gmk:62: recipe for target
> '/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge'
> failed
> make[3]: ***
> [/cygdrive/c/jprt/T/P1/042744.daholme/s/build/windows-x64-debug/support/modules_include/jdk.accessibility/win32/bridge]
> Error 1
>
> David
> -----
>
> On 5/12/2017 7:26 AM, Erik Joelsson wrote:
>> Looks good.
>>
>> /Erik
>>
>>
>> On 2017-12-04 12:40, Magnus Ihse Bursie wrote:
>>> On 2017-12-04 19:17, mandy chung wrote:
>>>>
>>>>
>>>> On 12/4/17 9:33 AM, Erik Joelsson wrote:
>>>>> Hello Magnus,
>>>>>
>>>>> The <module>-copy targets are currently only being generated for
>>>>> modules that have make/copy/Copy-<module>.gmk makefiles present.
>>>>> By removing make/copy/Copy-jdk.accessibility.gmk and
>>>>> make/copy/Copy-jdk.jdwp.agent.gmk, those targets are no longer
>>>>> created so the logic in CopyCommon will not be executed.
>>>>>
>>>>> This can be solved in two ways. Either generate <module>-copy
>>>>> rules for all modules or leave the files there with just include
>>>>> CopyCommon.gmk as the only contents. I would recommend the latter
>>>>> for now. Most modules do not need to copy anything.
>>>>
>>>> Is it possible to generate <module>-copy rules for module where
>>>> src/<module>/{share, $OS}/include directory or
>>>> make/copy/Copy-<module>.gmk is present?
>>> Technically, it's of course possible. But it does not fit very well
>>> with the current DeclareRecipesForPhase. I agree with Erik, that for
>>> now the reasonable approach is to have files that only include
>>> CopyCommon. We can consider for future updates if it's worth
>>> generalizing this.
>>>
>>> Updated webrev that restores the removed Copy-$MODULE.gmk files:
>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.02 
>>>
>>>
>>>>>
>>>>> Another minor note, when ordering include directories, I usually
>>>>> put the most specific dir first, so that any platform specific
>>>>> header file with the same name would override a more general one.
>>>>> We don't have that situation in this case, but I still think it's
>>>>> good practice.
>>>>>
>>>>> Regarding where to push this. IMO, if it depends on a change
>>>>> currently in hs, push it to hs. If it ends up in JDK 10 or 11
>>>>> doesn't really matter that much.
>>>>>
>>>>
>>>> I would love this in JDK 10 if time permits and I am happy to see
>>>> Coleen retarget it to 10.  This is a really nice clean up that
>>>> shows the benefit from JEP 201 w.r.t. exported native header
>>>> files.   But this is not a must for JDK 10 and if it can't make 10,
>>>> it's okay for 11.
>>>
>>> Ok. I'll try to get it into jdk 10. Will push this to jdk/jdk as
>>> soon as the needed fixes are integrated from jdk/hs.
>>>
>>> /Magnus
>>>
>>>>
>>>> Mandy
>>>>
>>>>
>>>>> /Erik
>>>>>
>>>>>
>>>>> On 2017-12-04 03:06, 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.
>>>>>>
>>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8190484
>>>>>> WebRev:
>>>>>> http://cr.openjdk.java.net/~ihse/JDK-8190484-move-hotspot-exported-includes/webrev.01 
>>>>>>
>>>>>>
>>>>>> /Magnus
>>>>>
>>>>
>>>
>>