JDK-6252011 : JVMTI Spec: Versioning
  • Type: Enhancement
  • Component: hotspot
  • Sub-Component: jvmti
  • Affected Version: 6
  • Priority: P4
  • Status: Closed
  • Resolution: Duplicate
  • OS: generic
  • CPU: generic
  • Submitted: 2005-04-07
  • Updated: 2010-04-02
  • Resolved: 2005-05-19
Related Reports
Duplicate :  
Description
Versioning of the JVMTI spec needs to be examined for mustang. Currently the spec is 1.0, and the definition of JVMTI_VERSION in jvmti.h needs to be rev'ed too.

At this time the only way to currently add functions to JVMTI is in conjunction with a new capability. New functions cannot solely be based on existing capabilities. For example, suppose we add a new heap iteration function. A VM should support heap iteration if it provides the can_tag_objects capability but any new heap iteration fcuntion will need an additional capability to avoid calling into a non-existant function on an old JVMTI implementation. Another point is that capabilities should exist for VM functionality that might not exist in all VM implementation or all VM modes. It doesn't really make sense to have capabilities on general functions that should be available in all implementations and modes. For example, suppose we add general functions like the existing GetClassSignature or GetObjectSize - these types of functions shouldn't need a capability but we can't add them in mustang without a new capability. A specific case in point is the AddToSystemClassLoaderSearch - like AddToBootstrapClassLoaderSearch it shouldn't need a capability and furthermore the ability to perform the function depends on the configured system class loader rather than the JVMTI/VM implementation.

One approach to examine is rev'ing the JVMTI_VERSION identifier in jvmti.h. JNI's GetEnv can check the requested version against the version implemented by the VM. If the agent requests a newer version that is available then JNI_EVERSION is returned (we probably need to put this code in irrespective of the outcome of this RFE). One nice thing about rev'ing the version number is that a developer can target a specific version of the JVMTI spec. If an agent relies on a lot of new functions then they can pass in JVMTI_VERSION_2_0 and fail if the VM doesn't support it. This is a lot simpler than checking a lot of individual capabilities for fear that the agent is deployed on a JVMTI 1.0 implementation.
###@###.### 2005-04-07 14:59:07 GMT


It would also be useful to have a "Revised" tag so that we can tag functions that have their specification updated since 1.0 (AddToBootstrapClassLoaderSearch comes to mine and there will be others).


###@###.### 2005-04-20 15:36:49 GMT

Comments
EVALUATION 6263703 has reviewed the spec to 1.1. A "since" attribute has also been added to the function and event tags. ###@###.### 2005-05-19 09:32:13 GMT
19-05-2005