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

[serguei.spitsyn at oracle.com]

Mikael,

I like your suggestion, will send new webrev tomorrow.

Thank you for the review!
Serguei

On 5/24/13 3:29 AM, Mikael Gerdin wrote:
> Serguei,
>
> On 2013-05-24 11:29, 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/ 
>>
>
> I agree with the semantic change but I'm not that fond of the 
> duplication.
> Instead of duplicating the code you could have a:
>
> MutexLockerEx ml( ( SafepointSynchronize::is_at_safepoint() ? NULL : 
> MemberNameTable_lock ), Mutex::_no_safepoint_check_flag );
>
> Or maybe
>
> Mutex* mutex_or_null = SafepointSynchronize::is_at_safepoint() ? NULL 
> : MemberNameTable_lock;
> MutexLockerEx ml(mutex_or_null, Mutex::_no_safepoint_check_flag);
>
> MutexLockerEx already has a null-check in both constructor and 
> destructor.
>
> /Mikael
>
>>
>>
>> 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