Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"

[Kelly O'Hair]

On Jan 25, 2011, at 11:00 AM, Tom Rodriguez wrote:

>
> On Jan 25, 2011, at 8:49 AM, Keith McGuigan wrote:
>
>>
>> Hello,
>>
>> This code modifies the way that JVMTI compiled-method-load events  
>> are posted.  Previously, they were posted directly from the  
>> compiler thread, which could cause issues if the JVMTI event  
>> handling code made calls to RedefineClasses, since the compiler  
>> thread is unable to load classes if that is required.  This  
>> solution is to defer the posting of the events to the Service  
>> thread (formerly: LowMemoryDetector
>> thread) which is a Java thread and is able to load classes.
>
> The posting appears to be asynchronous which I don't think will  
> work.  The method could be unloaded or invalidated and freed before  
> the event has been posted.  It has to be done synchronously I think.
>
> I have a vague memory of someone saying that there were restrictions  
> on what a JVMTI client was allowed to do in response to a  
> CompiledMethodLoad but I can't find any evidence of that.  So is  
> that just a bogus memory or is there some restriction like this?
>

It's been a while now, but there are restrictions as to what a JVMTI  
event handler can do, and I'm pretty sure redefining
classes may be on that limitation list, but I'm not seeing it  
explicitly spelled out.

I see this:
   http://download.oracle.com/javase/1.5.0/docs/guide/jvmti/jvmti.html#EventSection
It says "and the JVM TI implementation does not queue events in any  
way".

And these compiled-method-load events can also be generated from this:
   http://download.oracle.com/javase/1.5.0/docs/guide/jvmti/jvmti.html#GenerateEvents
And it mentions some issues with JNI.

Sorry, it's been so long, my serviceability brain cells have not been  
maintained very well. :^(

-kto

> tom
>
>>
>> The "Service thread" now handles both low-memory detection and  
>> JVMTI deferred event posting.   I left the door open for other  
>> types of events to be deferred and posted via this mechanism in  
>> case we find other situations where posting events from a non-Java  
>> thread causes problems.
>>
>> webrev:  http://cr.openjdk.java.net/~kamg/6766644/webrev.01/
>>
>> --
>> - Keith
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20110125/7be49772/attachment.html