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

[Mikael Gerdin]

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