Review Request (S) 8013945: CMS fatal error: must own lock MemberNameTable_lock

David Holmes david.holmes at oracle.com
Fri May 24 03:56:08 PDT 2013


Sorry just saw Mikael already suggested this. :)

David

On 24/05/2013 8:54 PM, David Holmes wrote:
> Hi Serguei,
>
> You can avoid the code duplication if you use the safepoint check to
> assign either the MemberNameTable_lock or NULL to a Mutex variable:
>
> Mutex* lock = (atsafepoint ? NULL : MemberNameTable_lock);
> {
>     MutexLockerEx ml(lock, ...);
>     ...
> }
>
> David
>
> On 24/05/2013 7:29 PM, serguei.spitsyn at oracle.com wrote:
>> Please, review the fix for:
>>    bug: http://bugs.sun.com/view_bug.do?bug_id=8013945
>>    jbs: https://jbs.oracle.com/bugs/browse/JDK-8013945
>>
>> Open webrev:
>> http://cr.openjdk.java.net/~sspitsyn/webrevs/2013/hotspot/8013945-JVMTI-JSR292.1/
>>
>>
>>
>> Summary:
>>    CMS calls InstanceKlass::release_C_heap_structures() concurrently.
>>    The "delete mnt" needs to take MemberNameTable_lock if
>> !SafepointSynchronize::is_at_safepoint().
>>
>> Testing:
>>    The vm/mlvm and Nashorn tests, the tests listed in the bug report
>>
>> Thanks,
>> Serguei


More information about the serviceability-dev mailing list