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

[serguei.spitsyn at oracle.com]

Ok, thank you for the review!
Serguei

On 5/24/13 3:56 AM, David Holmes wrote:
> 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