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).

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