review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1

[Vladimir Kozlov]

You did not explain your changes for cb->name().

Why we don't lock nmethod in sweeper during CodeCache walk but lock here?

Thanks,
Vladimir

On 7/1/10 1:58 PM, Tom Rodriguez wrote:
> http://cr.openjdk.java.net/~never/6965671/
>
> 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1
> Reviewed-by:
>
> The jmethodID fix created a deadlock because of lock ordering when
> walking the CodeCache to generate CompiledMethodLoad events.  The walk
> is performed with the CodeCache_lock held but we need to acquire the
> JNIGlobalHandle_lock to make a jmethodID.  I considered switching back
> to collecting the methodOop instead of the jmethodID under the lock
> but inspection of the code made it clear that there's a preexisting
> problem with GC of the methodOops stored into the nmethodDesc.
> Instead I switched to a simpler implementation that holds the
> CodeCache_lock while walking the CodeCache but releases the lock to
> actually perform the notify.  This simplifies the code greatly as well
> as fixing the bug.
>
> Tested with NSK jvmti,jdi,jdb,hprof,jit,regression and JDI_REGRESSION
> tests.