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