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

[Mandy Chung]

  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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20101216/82a3db8b/attachment.html