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