On Fri, 9 Dec 2022 19:39:16 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
> I have a memory of the following concerning JVM/TI versions: > > * if you asked for JVMTI_VERSION, then you got the highest version supported > by the JVM. JVMTI_VERSION is defined in jvmti.h so its value depends on which JDK include directory was used when compiling the agent. If the JDK supports that version then it is required to return a JVMTI env that is compatible or fail with EVERSION. If the agent calls GetVersionNumber to see what version it got then it may be a newer (but compatible) version, which is what our implementation does. It may be that the agent was compiled with JVMTI_VERSION for a newer JDK release, in which case GetEnv must fail with EVERSION as an older JDK release doesn't know about new JVMTI versions. In any case, there should be no mix'ing and matching with the JDWP agent so GetEnv asking for JVMTI_VERSION should be okay. For a JDK build, the JVMTI version at build time will match run-time. A hash of the jdk.jdwp.agent module is generated at build/packaging time to prevent accidental linking with modules from different JDK builds. If someone does attempt to run jlink and use java.base from one build and jdk.jdwp.agent from another build then they will get an error that the hashes don't match. It is of course possible that someone does a slight of hand and copy a libjdwp/libdt_socket from one JDK build into a build from a different JDK release but I don't think we need to spend too much time on that as it's just not supported to do that. Also, as Chris says, the version compatibility check should catch it too. > * if you asked for JVMTI_VERSION_1, then you got the highest compatible > version to VERSION_1. > * if you asked for JVMTI_VERSION_1_1, then you got JVMTI_VERSION_1_1, no > more, no less if the JVM supports it. If you run on JDK 19 then you'll get a JVMTI_VERSION_19 in both cases. It might be in the future that we need to do some incompatible changes to JVMTI, like remove the deprecated heap functions, in which case it might have to return EVERSION for both cases. The is a bridge that we haven't got to yet but I expect it will require discussing JVMTI capabilities at the same time. In passing, I see that JvmtiExport::get_jvmti_interface doesn't reject 19.minor, I guess it should. ------------- PR: https://git.openjdk.org/jdk/pull/11602
