request for review (S): rev JVMTI version number
Keith McGuigan
keith.mcguigan at oracle.com
Mon Dec 6 09:12:19 PST 2010
On Dec 6, 2010, at 11:29 AM, Daniel D. Daugherty wrote:
> src/share/vm/prims/jvmtiEnv.cpp
> Since JVM/TI version 1.0, 1.1 and (presumably) 1.2 are compatible
> with each other, you don't need to do this check. The relevant
> part of the JVM/TI spec is:
>
> http://download.oracle.com/javase/6/docs/platform/jvmti/jvmti.html#jvmtiEnvAccess
>
> The key sentence is:
>
> > The returned environment may have a different version than the
> > requested version but the returned environment must be compatible.
>
> If a client asks for version 1.0 or version 1.1, then it is okay
> to return version 1.2 as long as the common parts between those
> versions are compatible. If a client running on JDK5 or JDK6 is
> smart enough to ask for JVM/TI version 1.2, then it can be allowed
> to have it.
Understood that the spec allows us return a different version, but it
doesn't require it. I'd think we'd want to leave JDK6 alone as much
as possible, but I'll defer to your opinion in this matter.
> src/share/vm/prims/jvmtiExport.cpp
> I don't think you need these changes either.
Right - unless we do want to keep the version constant in jdk6 (and
jdk5 maybe someday).
> src/share/vm/prims/jvmtiH.xsl
> This change just adds JVMTI_VERSION_1_2. It does not change the
> JVMTI_VERSION value to the 1.2 version, but it should.
That macro gets created using the major/minor fields. Excerpt from
the generated jvmti.hpp:
enum {
JVMTI_VERSION_1 = 0x30010000,
JVMTI_VERSION_1_0 = 0x30010000,
JVMTI_VERSION_1_1 = 0x30010100,
JVMTI_VERSION_1_2 = 0x30010200,
JVMTI_VERSION = 0x30000000 + (1 * 0x10000) + (2 * 0x100) + 1 /*
version: 1.
2.1 */
};
> src/share/vm/prims/jvmtiEnvBase.hpp
> You should add JDK17_JVMTI_VERSION to the enum set here. You should
> also add a declaration for JvmtiEnvBase::use_version_1_2_semantics()
> here.
>
> src/share/vm/prims/jvmtiEnvBase.cpp
> You should add a definition for
> JvmtiEnvBase::use_version_1_2_semantics()
> here.
I'll do these.
> If a JVM/TI version simply adds new functions, then nothing needs to
> be done. An older agent that asks for JVM/TI version 1.0 or JVM/TI
> version 1.1 won't know about or try to use the new function.
>
> However, if a new JVM/TI version changes semantics of an existing
> function,
> then a little more hoop jumping is needed.
What kind of hoop-jumping, exactly? I may have to find these hoops
and jump through them in the near future for a different fix.
--
- Keith
More information about the serviceability-dev
mailing list