JVM interface header src location?

[Andrew Leonard]

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: andrew_m_leonard at uk.ibm.com 




From:   David Holmes <david.holmes at oracle.com>
To:     Andrew Leonard <andrew_m_leonard at uk.ibm.com>, 
hotspot-dev at openjdk.java.net
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: andrew_m_leonard at uk.ibm.com
> 
> 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