On Dec 15, 2010, at 4:44 AM, Alan Bateman wrote:
Keith McGuigan wrote:
:
Yeah I missed that check too. I'm very much in favor of being able
to use an older (or newer) JVM in the JDK7 image. Triage is one
important reason but another is the non-synchronous putback
schedules of the jdk and hotspot workspaces. There will be a
period of QA time when the JDK uses an older VM (or vice-versa)
just because of the way our process works.
I think the jdk code should probe the JVMTI version and use
whatever is available. I'm in favor of modifying the code in
debugInit.c to verify only 1.1 and then dynamically probe before
using any 1.2 features (and so on in the future).
In the past I don't think we've done this. Instead we've usually
just kept back the jdk changes until the hotspot changes made it
into a promoted build.
One other thing is the regression test. The debugger tests are in
jdk/test/com/sun/jdi and it is important to add a new test, or add
to an existing test. If you are pushing the jdk changes before the
VM changes have made it into a promoted build then I guess you'll
need to hold off pushing the test (or add it with the @ignore tag,
removing it later via a different bugID).
-Alan
Ok, here's a new webrev: http://cr.openjdk.java.net/~kamg/6436034/webrev.01/
I added a regression test and modified the code in debugInit.cpp to
explicitly allow running with JVMTI 1.1 if that's what the JVM
supports. The regression test is setup to pass when run with a JVM
less than version 20 build 05 (where the new JVMTI function is added),
so it should run and pass in either situation and won't require a
later update.
--
- Keith
