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

[Keith McGuigan]

Ok, here's my next attempt:  http://cr.openjdk.java.net/~kamg/6766644/webrev.02

This enqueues the compiled-method-unloaded events so that they the  
posting of load/unload will be in order.  Other changes include  
locking the nmethod until after the compiled-method-load event is  
posted, and an alternate mechanism for enqueuing the compiled-method- 
unload events that are generated at safepoint.

--
- Keith

On Jan 26, 2011, at 5:07 PM, Daniel D. Daugherty wrote:

> On 1/26/2011 2:52 PM, Tom Rodriguez wrote:
>>
>> On Jan 26, 2011, at 1:39 PM, Daniel D. Daugherty wrote:
>>
>>> It also looks like there must be order between the load and unload  
>>> events:
>>>
>>>     CompiledMethodLoad for foo
>>>     CompiledMethodUnload for foo
>>>     CompiledMethodLoad for foo (again)
>>>
>>
>> Do you mean we can't have multiple versions of compiled code for  
>> the same method?  I don't think that's true or should be required.   
>> nmethod freeing is very lazy and there's no guarantee that we will  
>> have completed unloading of an nmethod before we've created a new  
>> variation of it.  It would also be completely ok for a JVM to have  
>> multiple versions of the compiled code for a method.  Obviously the  
>> load and unload for a particular nmethod must be properly ordered.
>>
>
> That last sentence is what I meant; load and unload for a specific
> compiled version of foo (nmethod) must be in order.
>
> Dan
>
>
>
>>
>>> which is going to mean coordination between the mechanisms for  
>>> posting
>>> of both CompiledMethodLoad and CompiledMethodUnload events.
>>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/serviceability-dev/attachments/20110128/171357d6/attachment.html