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

Keith McGuigan keith.mcguigan at
Fri Jan 28 09:27:49 PST 2011

Ok, here's my next attempt:

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

More information about the hotspot-runtime-dev mailing list