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).
In order to test this, we need to have JDI events generated from a non-
static native frame. It's not really possible to add native code to a
jtreg regression test, is it? Maybe i can find some existing library
native code that can generate an event. Any suggestions?
--
- Keith
