RFR (S): 8219023: Investigate syncing JVMTI spec version with JDK version
Chris Plummer
chris.plummer at oracle.com
Thu May 9 02:10:36 UTC 2019
Hi Serguei,
Changes look good. Can you verify that the .jtr file for com/sun/jdi
tests has all the versions updated? For example, you will currently see:
JVM version:13-ea
JDI version: 11.0
JVM description: Java Debug Interface (Reference Implementation) version
11.0
Java Debug Wire Protocol (Reference Implementation) version 11.0
JVM Debug Interface version 11.0
JVM version 13-ea (Java HotSpot(TM) 64-Bit Server VM, mixed mode, sharing)
I think your intent is for all of these to be updated from 11 to 13.
thanks,
Chris
On 5/8/19 3:57 PM, serguei.spitsyn at oracle.com wrote:
> Please, review a fix for the task:
> https://bugs.openjdk.java.net/browse/JDK-8219023
>
> Webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2019/8219023-svc-version.1/
>
> Summary:
>
> By design as we have never bumped the JVMTI version unless
> there were spec changes for that release. Now we want to sync
> the JVMTI version with the JDK version regardless of whether
> or not spec changes have occurred in that release.
> Also, we want it automatically set by the build system so that
> no manual updates are needed for each release.
>
> The jvmti.h and jvmti.html (JVMTI spec) are generated from
> the jvmti.xsl with the XSLT scripts now. So, the fix removes
> hard coded major, minor and micro versions from the jvmti.xml
> and passes major and minor parameters with the -PARAMETER
> to the XSL transformation.
>
> Another part of the fix is in the JDI which starts using JDK
> versions now instead of maintaining its own, and in the JDWP
> agent which is using the JVMTI versions instead of its own.
>
> Testing:
> Generated docs and jvmti.h and checked the versions are correct.
>
> One could ask if we have to use same or similar approach for
> other API's and tools, like JNI, JMX and so on.
> But these are not areas of my expertise or responsibility.
> It just feels like there is some room for unification here.
>
> Thanks,
> Serguei
More information about the serviceability-dev
mailing list