6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1
Reviewed-by: kvn, dcubed
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