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.
