RFR: JDK-8190484 Move jvm.h, jmm.h et al to hotspot/*/include
David Holmes
david.holmes at oracle.com
Mon Dec 4 23:28:47 UTC 2017
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
>>>
>>
>
More information about the build-dev
mailing list