Request for review, 6766644: Redefinition of compiled method fails with assertion "Can not load classes with the Compiler thread"
keith.mcguigan at oracle.com
Fri Jan 28 09:27:49 PST 2011
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.
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
>>> 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.
>>> which is going to mean coordination between the mechanisms for
>>> of both CompiledMethodLoad and CompiledMethodUnload events.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the hotspot-runtime-dev