On Fri, 9 Dec 2022 01:16:58 GMT, Chris Plummer <cjplum...@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
