review (S) for 6965671: fatal error: acquiring lock JNIGlobalHandle_lock/16 out of order with lock CodeCache_lock/1
Vladimir Kozlov
vladimir.kozlov at oracle.com
Thu Jul 1 14:39:57 PDT 2010
On 7/1/10 2:36 PM, Vladimir Kozlov wrote:
> You did not explain your changes for cb->name().
>
> Why we don't lock nmethod in sweeper during CodeCache walk but lock here?
Because only one (compiler) thread do walking and free nmethods. Right?
Vladimir
>
> 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.
More information about the hotspot-compiler-dev
mailing list