request for review: 6436034: Instance filter doesn't filter event if it occurs in native method

[Keith McGuigan]

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