RFR: 8287812: Cleanup JDWP agent GetEnv initialization [v2]

[Daniel D. Daugherty]

On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> 3 things to cleanup in this area:
>> 
>> (1) The JDWP agent uses `JNI GetEnv(JVMTI_VERSION_1)` to get a JVMTI environment. If `GetEnv` fails the JDWP agent prints this:
>> 
>> `ERROR: JDWP unable to access JVMTI Version 1 (0x30010000), is your J2SE a 1.5 or newer version? JNIEnv's GetEnv() returned -3`
>> 
>> The text "is your J2SE a 1.5 or newer version?" dates from JDK 5 when JVMTI was introduced and doesn't make sense now.
>> 
>> (2) `JVMTI_VERSION_1` suggests that the JDWP agent is looking for a JVMTI v1 environment when it really wants the latest. `GetEnv` should request `JVMTI_VERSION` so that it always requests the current version.
>> 
>> (3) There is some outdated compatibility checking between runtime and compile time versions of JVMTI that date back to the 1.0, 1.1, and 1.2 era, and are no longer needed.
>
> Chris Plummer has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Get rid of some structs and statics that are no longer needed.

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

Here's where things get gnarly:
- if you asked for JVMTI_VERSION_1, could you get back JVMTI_VERSION_1_2 or JVMTI_VERSION_9 or
  JVMTI_VERSION_11 if the JVM in question supported each of those versions (and no higher)?
  - the assumption that I've always made is that each of JVMTI_VERSION_1_N are all considered
    compatible so asked for JVMTI_VERSION_1, you would get the highest compatible version in
    the JVMTI_VERSION_1_N set that is supported by the JVM on which you ask the question.
  - if you ask for JVMTI_VERSION_1 on a JVM that supports JVMTI_VERSION_1_N and JVMTI_VERSION_9
    then I would expect you to get back JVMTI_VERSION_1_2 and not JVMTI_VERSION_9. Why?
  - My assumption is that you only change major version numbers when you make incompatible
    changes. Adding a new API is a compatible change because the older agent doesn't know how
    to use the new API. Changing the semantics of an existing API is NOT a compatible change so
    you bump the major number.

So I'm assuming that JVMTI_VERSION_9 has incompatible changes relative to JVMTI_VERSION_1_N.
Similarly I'm assuming that JVMTI_VERSION_11 has incompatible changes relative to JVMTI_VERSION_9
and JVMTI_VERSION_1_N.

-------------

PR: https://git.openjdk.org/jdk/pull/11602