request for review (S): rev JVMTI version number
Daniel D. Daugherty
daniel.daugherty at oracle.com
Mon Dec 6 09:21:14 PST 2010
On 12/6/2010 10:09 AM, Alan Bateman wrote:
> Daniel D. Daugherty wrote:
>> Then the agent would be wrong. :-)
>> If the agent is smart enough to ask the new version, then it should
>> be allowed to use that new version. By restricting JDK6 to version 1.1,
>> you would be precluding a tool vendor from having a single binary that
>> could work on JDK5, JDK6 and JDK7 where HSX is in place.
> The only concern may be the agent that asks for 1.1 and gets 1.1 today
> but now gets a 1.2 environment.
The version 1.2 that it gets back will be semantically equivalent
to the version 1.1 that it got back before. The function table
may contain new functions, but an agent written for version 1.1
won't know about them so it can't/won't call them.
If version 1.2 happens to change the semantics of an existing
function, then the logic that I posted earlier will have to be
used. The VM will have to account for the version that was
requested and behave accordingly. I already did this work for
an HSX VM being dropped into a JDK5 release so we have a proof
of concept that this works.
It is possible for an agent to ask for version 1.1, observe that
version 1.2 is returned and have heartburn. However, as I said
earlier, that agent would be wrong according to the spec section
that I quoted earlier.
It is much more important to enable a properly written agent to
function in JDK5, JDK6 and JDK7 than it is to avoid surprising
an incorrectly written agent.
More information about the serviceability-dev