JVM interface header src location?

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

JVM interface header src location?

Andrew Leonard
Hi, with the new repo consolidation in JDK10+ the JVM interface headers
(jvm.h and jvm_md.h) have moved from under
jdk/src/java.base/share|<OS>/native/include/ to
    src/hotspot/share/include/jvm.h
    src/hotspot/os/windows/include/jvm_md.h
    src/hotspot/os/posix/include/jvm_md.h
This implies these are "hotspot" headers, when they are actually generic
JVM interface definitions. So for example if previously a 3rd party JVM
implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and
now does not clone the hotspot "folder", will now fail to find these
generic headers...

Wouldn't it be better for these headers to be under some generic "jvm" or
"base" include folder?

Thanks
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: [hidden email]

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

David Holmes
Hi Andrew,

On 12/01/2018 1:34 AM, Andrew Leonard wrote:
> Hi, with the new repo consolidation in JDK10+ the JVM interface headers
> (jvm.h and jvm_md.h) have moved from under
> jdk/src/java.base/share|<OS>/native/include/ to
>      src/hotspot/share/include/jvm.h
>      src/hotspot/os/windows/include/jvm_md.h
>      src/hotspot/os/posix/include/jvm_md.h
> This implies these are "hotspot" headers, when they are actually generic

I wouldn't call them generic. They define the API that hotspot provides
for use by the JDK. The JDK in turn is written to use whatever hotspot
exports. Now we can treat that as a de-facto generic definition of what
any VM that works with the JDK needs to provide, but it would be wrong
to pretend/assume that this is somehow some nice clean abstract
interface between the JDK and any VM.

In short any VM you want to plug into the JDK has to impersonate hotspot
from this API perspective.

> JVM interface definitions. So for example if previously a 3rd party JVM
> implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and
> now does not clone the hotspot "folder", will now fail to find these
> generic headers...

Right ... it would have been good to have gotten some feedback on this
when we did the file consolidation work:

https://bugs.openjdk.java.net/browse/JDK-8189610

and then relocation:

https://bugs.openjdk.java.net/browse/JDK-8190484

> Wouldn't it be better for these headers to be under some generic "jvm" or
> "base" include folder?

It would solve your problem. :) And I'm not opposed to moving them as a
convenience to you. My main concern would be that this is not seen as a
supported, exported, external contract between the JDK libraries and any
VM. I would still consider it a private interface between the JDK and
hotspot that changes whenever hotspot (or the JDK) needs it to.

Cheers,
David

> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: [hidden email]
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
>
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

Mandy Chung


On 1/11/18 2:01 PM, David Holmes wrote:

>
>> Wouldn't it be better for these headers to be under some generic
>> "jvm" or
>> "base" include folder?
>
> It would solve your problem. :) And I'm not opposed to moving them as
> a convenience to you. My main concern would be that this is not seen
> as a supported, exported, external contract between the JDK libraries
> and any VM. I would still consider it a private interface between the
> JDK and hotspot that changes whenever hotspot (or the JDK) needs it to.
>

Right.  It's internal interface between JDK and hotspot.
src/java.base/share/include wasn't the desired location for it and hence
the relocation.

Would it be an alternative if the source location of these header files
can be configured at build time so that other JVM implementor can build
JDK with an alternate location?   I would expect that other VM
implementation would have to do some work for any change to jvm.h
regardless of where it's located.  The extra (hopefully minimal) work is
to update its own copy of jvm.h.

Mandy
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

Andrew Leonard
In reply to this post by David Holmes
Thanks for the feedback David. I agree with your point, and understand JVM
implementors are really just hotspot imitators(!) :-)
It would be as a convenience to 3rd party JVM implementors, and ease the
job of extracting just those necessary files...
Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: [hidden email]




From:   David Holmes <[hidden email]>
To:     Andrew Leonard <[hidden email]>,
[hidden email]
Date:   11/01/2018 22:01
Subject:        Re: JVM interface header src location?



Hi Andrew,

On 12/01/2018 1:34 AM, Andrew Leonard wrote:
> Hi, with the new repo consolidation in JDK10+ the JVM interface headers
> (jvm.h and jvm_md.h) have moved from under
> jdk/src/java.base/share|<OS>/native/include/ to
>      src/hotspot/share/include/jvm.h
>      src/hotspot/os/windows/include/jvm_md.h
>      src/hotspot/os/posix/include/jvm_md.h
> This implies these are "hotspot" headers, when they are actually generic

I wouldn't call them generic. They define the API that hotspot provides
for use by the JDK. The JDK in turn is written to use whatever hotspot
exports. Now we can treat that as a de-facto generic definition of what
any VM that works with the JDK needs to provide, but it would be wrong
to pretend/assume that this is somehow some nice clean abstract
interface between the JDK and any VM.

In short any VM you want to plug into the JDK has to impersonate hotspot
from this API perspective.

> JVM interface definitions. So for example if previously a 3rd party JVM
> implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and
> now does not clone the hotspot "folder", will now fail to find these
> generic headers...

Right ... it would have been good to have gotten some feedback on this
when we did the file consolidation work:

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8189610&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=VgwZL88Bpwz77SYajN1T2qt0yfLDzC0WRgTczBJtzSw&e=


and then relocation:

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8190484&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=fED9Yhb2hFGVHbWqOIrtjZsOSvhU7FDmv_SwI5ay3nM&e=


> Wouldn't it be better for these headers to be under some generic "jvm"
or
> "base" include folder?

It would solve your problem. :) And I'm not opposed to moving them as a
convenience to you. My main concern would be that this is not seen as a
supported, exported, external contract between the JDK libraries and any
VM. I would still consider it a private interface between the JDK and
hotspot that changes whenever hotspot (or the JDK) needs it to.

Cheers,
David

> Thanks
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: [hidden email]
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6
3AU
>




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

Andrew Leonard
In reply to this post by Mandy Chung
Eclipse OpenJ9 for example imitates the jvm.h interface without any change
to it, so in essence they treat it as a defined "interface", but as you
say it's really not a "supported" one, so I can understand both sides...


Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: [hidden email]




From:   mandy chung <[hidden email]>
To:     David Holmes <[hidden email]>, Andrew Leonard
<[hidden email]>
Cc:     [hidden email]
Date:   11/01/2018 23:27
Subject:        Re: JVM interface header src location?





On 1/11/18 2:01 PM, David Holmes wrote:

Wouldn't it be better for these headers to be under some generic "jvm" or
"base" include folder?

It would solve your problem. :) And I'm not opposed to moving them as a
convenience to you. My main concern would be that this is not seen as a
supported, exported, external contract between the JDK libraries and any
VM. I would still consider it a private interface between the JDK and
hotspot that changes whenever hotspot (or the JDK) needs it to.


Right.  It's internal interface between JDK and hotspot.  
src/java.base/share/include wasn't the desired location for it and hence
the relocation.

Would it be an alternative if the source location of these header files
can be configured at build time so that other JVM implementor can build
JDK with an alternate location?   I would expect that other VM
implementation would have to do some work for any change to jvm.h
regardless of where it's located.  The extra (hopefully minimal) work is
to update its own copy of jvm.h.

Mandy


Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

Alan Bateman
On 12/01/2018 09:10, Andrew Leonard wrote:
> Eclipse OpenJ9 for example imitates the jvm.h interface without any change
> to it, so in essence they treat it as a defined "interface", but as you
> say it's really not a "supported" one, so I can understand both sides...
>
Does OpenJ9 implement the JDK-internal JMM interface (jmm.h) too?

-Alan
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

David Holmes
In reply to this post by Andrew Leonard
On 12/01/2018 7:03 PM, Andrew Leonard wrote:
> Thanks for the feedback David. I agree with your point, and understand
> JVM implementors are really just hotspot imitators(!) :-)
> It would be as a convenience to 3rd party JVM implementors, and ease the
> job of extracting just those necessary files...

After some further internal discussions it was decided that as jvm*.h is
really the exported hotspot interface (as previously discussed when the
files were combined and relocated) that it belongs in the hotspot src
directory.

David
-----

> Cheers
> Andrew
>
> Andrew Leonard
> Java Runtimes Development
> IBM Hursley
> IBM United Kingdom Ltd
> Phone internal: 245913, external: 01962 815913
> internet email: [hidden email]
>
>
>
>
> From: David Holmes <[hidden email]>
> To: Andrew Leonard <[hidden email]>,
> [hidden email]
> Date: 11/01/2018 22:01
> Subject: Re: JVM interface header src location?
> ------------------------------------------------------------------------
>
>
>
> Hi Andrew,
>
> On 12/01/2018 1:34 AM, Andrew Leonard wrote:
>  > Hi, with the new repo consolidation in JDK10+ the JVM interface headers
>  > (jvm.h and jvm_md.h) have moved from under
>  > jdk/src/java.base/share|<OS>/native/include/ to
>  >      src/hotspot/share/include/jvm.h
>  >      src/hotspot/os/windows/include/jvm_md.h
>  >      src/hotspot/os/posix/include/jvm_md.h
>  > This implies these are "hotspot" headers, when they are actually generic
>
> I wouldn't call them generic. They define the API that hotspot provides
> for use by the JDK. The JDK in turn is written to use whatever hotspot
> exports. Now we can treat that as a de-facto generic definition of what
> any VM that works with the JDK needs to provide, but it would be wrong
> to pretend/assume that this is somehow some nice clean abstract
> interface between the JDK and any VM.
>
> In short any VM you want to plug into the JDK has to impersonate hotspot
> from this API perspective.
>
>  > JVM interface definitions. So for example if previously a 3rd party JVM
>  > implementor (eg.Eclipse OpenJ9) who does not clone the hotspot repo, and
>  > now does not clone the hotspot "folder", will now fail to find these
>  > generic headers...
>
> Right ... it would have been good to have gotten some feedback on this
> when we did the file consolidation work:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8189610&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=VgwZL88Bpwz77SYajN1T2qt0yfLDzC0WRgTczBJtzSw&e=
>
> and then relocation:
>
> https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8190484&d=DwICaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=NaV8Iy8Ld-vjpXZFDdTbgGlRTghGHnwM75wUPd5_NUQ&m=cmDyJIWgzK0nr0h1WHwc0TKtWEAPcz8g_pN-h1eSKEQ&s=fED9Yhb2hFGVHbWqOIrtjZsOSvhU7FDmv_SwI5ay3nM&e=
>
>  > Wouldn't it be better for these headers to be under some generic "jvm" or
>  > "base" include folder?
>
> It would solve your problem. :) And I'm not opposed to moving them as a
> convenience to you. My main concern would be that this is not seen as a
> supported, exported, external contract between the JDK libraries and any
> VM. I would still consider it a private interface between the JDK and
> hotspot that changes whenever hotspot (or the JDK) needs it to.
>
> Cheers,
> David
>
>  > Thanks
>  > Andrew
>  >
>  > Andrew Leonard
>  > Java Runtimes Development
>  > IBM Hursley
>  > IBM United Kingdom Ltd
>  > Phone internal: 245913, external: 01962 815913
>  > internet email: [hidden email]
>  >
>  > Unless stated otherwise above:
>  > IBM United Kingdom Limited - Registered in England and Wales with number
>  > 741598.
>  > Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire
> PO6 3AU
>  >
>
>
>
>
> Unless stated otherwise above:
> IBM United Kingdom Limited - Registered in England and Wales with number
> 741598.
> Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
Reply | Threaded
Open this post in threaded view
|

Re: JVM interface header src location?

Andrew Leonard
In reply to this post by Alan Bateman
Hi Alan,
I don't believe OpenJ9 uses jmm.h, it has it's own "management" interface
impl.
Cheers
Andrew

Andrew Leonard
Java Runtimes Development
IBM Hursley
IBM United Kingdom Ltd
Phone internal: 245913, external: 01962 815913
internet email: [hidden email]




From:   Alan Bateman <[hidden email]>
To:     Andrew Leonard <[hidden email]>, mandy chung
<[hidden email]>
Cc:     [hidden email]
Date:   12/01/2018 19:00
Subject:        Re: JVM interface header src location?



On 12/01/2018 09:10, Andrew Leonard wrote:
> Eclipse OpenJ9 for example imitates the jvm.h interface without any
change
> to it, so in essence they treat it as a defined "interface", but as you
> say it's really not a "supported" one, so I can understand both sides...
>
Does OpenJ9 implement the JDK-internal JMM interface (jmm.h) too?

-Alan




Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number
741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU