RFR (XS) 6976636: JVM/TI test ex03t001 fails assertion

Daniel D. Daugherty daniel.daugherty at oracle.com
Fri Mar 14 20:52:24 UTC 2014


On 3/13/14 3:24 PM, serguei.spitsyn at oracle.com wrote:
> Please, review the fix for:
>   https://bugs.openjdk.java.net/browse/JDK-6976636
>
>
> Open webrev:
> http://cr.openjdk.java.net/~sspitsyn/webrevs/2014/hotspot/6976636-JVMTI-unload.1 
>

Thumbs up.

src/share/vm/prims/jvmtiExport.cpp
     No comments.

As for the extension call back stuff, I think the idea
is to pass a little more info about which thread motivated
the class unload. An agent might be interested in such a
statistic.

 > The class unload event is implemented as a source debug extension

Not "source debug extension", but "JVM/TI extension event". The
source debug extension is a different thing (see JDI).

 > As a consequence of this fix the failing nsk.jvmti test ex03t001
 > must be tweeked as well.

Since you are changing an assert here, I'm curious why the test
needs to change. Does the test presume the jthread refers to
a real JavaThread?


Dan



>
> Summary:
>
>   This is a Nightly Stabilization issue.
>   The class unload event post in the JvmtiExport.cpp fails at the assert
>   assuming the proxy thread causing the class unload must be a 
> JavaThread.
>   It is not the case when the proxy thread is a CMS ConcurrentGCThread.
>
>   This fix is to relax this check allowing this case.
>   The downside of this approach is that the jthread parameter passed 
> to the
>   even handler callback is NULL for the CMS thread.
>   This must be Ok as it would indicates that the proxy thread is a CMS 
> thread.
>
>   In fact, I have a doubt this parameter is needed at all.
>   So that an alternative approach could be to remove it from the event 
> callback.
>   My preference is to leave the jthread parameter as it is as it does 
> not impact anything.
>   The class unload event is implemented as a source debug extension 
> for the
>   sake of testing the extension functionality. The JDWP agent does not 
> use it.
>   The class unload events are not expected to be used by any external 
> tool.
>
>   As a consequence of this fix the failing nsk.jvmti test ex03t001 
> must be tweeked as well.
>   If review is positive then I'll file a bug and proceed with the test 
> fix.
>
> Testing:
>   Running the failing test: nsk/jvmti/scenarios/extension/EX03/ex03t001
>
>
> Thanks,
> Serguei



More information about the serviceability-dev mailing list