On 12/16/10 14:29, Keith McGuigan wrote:
I understand the benefit of allowing an older VM to run on JDK 7 so
that we can easily verify a hotspot fix and identify hotspot
regression. But I'm not sure if the jdwp agent should support that
and wonder if it's useful in practice. The use case requiring the
jdwp agent to support an older JVMTI version is when a developer
wants to debug a Java application on JDK 7 with a JDK 6 VM. I would
imagine that this is rarely needed. Is there other use case that
suggests this jvmti version check worth doing?
Not a use case that exists right now, but I was imagining someone
wanting to run the JDK with a different underlying JVM altogether (not
Hotspot).
Hmm... that JVM would need to implement the private jvm interface as
hotspot. Anyway, for the JDWP agent discussion, you want to allow
debugging a Java application running on a VM that doesn't support the
latest JVM TI version. The idea sounds fine but I just wanted to point
out that the use case for it seems to be very rare.
Would you consider keeping the jdwp agent in JDK 7 to require JVMTI
version >= 1.2 (i.e. works with JDK 7 or newer VM)?
As you can probably tell, I'd rather not :) But if everyone agrees
that dynamically checking the version is abhorrent I will defer to
you. You guys are the experts, I'm new at this code.
It's more of the maintainence cost and readability (supporting the
latest version vs all existing versions 1.1 and up) that I'd like to
give my feedback so that you (new owner) can make the right judgement
call :)
When we do our engineering build of both jdk and hotspot repositories
(or nightly testing), does the hotspot VM have an internal version
string rather than 20.0-b03? If that's the case, does that mean the
test will just pass even if the hotspot supports JVMTI 1.2? In that
case, you would want the test to actually do the work.
I don't think that the format of that part of the string changes, but
if it does, then when the parsing fails the default is that the test
is "enabled". It will only be neutered when the version parsing
succeeds and the JVM version is less than what is expected.
Can you check what the java.vm.version property is set to for your
engineering build (or jprt build)? I am not concerned with the parsing
logic. I want to make sure that the jvmSupportsJVMTI_1_2() method
returns true for all hotspot builds (not just RE build) if it supports
JVMTI 1.2. Can you double check?
FYI. sun.misc.Version provides several internal methods to return
the version number and build number of the VM that you can use in
these tests to replace the regex.
Ok I'll take a look at at those. Can I access internal classes like
that from a jtreg test? I wasn't sure I could.
Yes, you can use internal API in jtreg test. You need to add a special
javac flag to the test:
@compile -XDignore.symbol.file <classname>
You can reference jdk/test/sun/misc/Version/Version.java.
Mandy
