CMS parallel initial mark; vm thread sneaking in Thread::try_lock()

[David Holmes]

Hi Hiroshi,

On 18/06/2013 8:46 AM, Hiroshi Yamauchi wrote:
> David Holmes wrote:
>     That seems reasonable. But I think you are misunderstanding what
>     sneaking does. It isn't dangerous, you don't get multiple threads
>     inside a critical region or anything strange like that - as long as
>     the other threads using it will stop at safepoints of course! With
>     monitors/mutexes a point is reached where the lock has been claimed
>     but the new owner then blocks at a safepoint. So externally it looks
>     like the lock is owned but the owner has not yet entered the
>     critical region. If the VMThread needed that same lock there would
>     be a deadlock. So the VMThread is allowed to "sneak" the lock,
>     effectively taking ownership of it as-if the real owner blocked just
>     before it could take ownership. The real owner can't wake up and
>     enter the critical section until the safepoint is over and the
>     VMThread will release the lock before it ends the safepoint. Note
>     that any lock needed by the VMThread at a safepoint should not be
>     used to guard critical sections in which other safepoint checks
>     occur, else you would again get a deadlock. (And these locks are not
>     reentrant.)
>
>
> Thanks. If we only call try_lock() and unlock() on a mutex/monitor, then
> no thread will block due to a safepoint synchronization inside that
> mutex/monitor (as I see no ThreadBlockInVM in try_lock()). That is, we
> won't encounter a situation where a VM thread sneak may happen, and we
> don't need to worry about sneaking. Is that right?

If all access to the lock is via try_lock() then no thread will block 
acquiring that lock due to a safepoint. If all other threads using the 
lock are JavaThreads (and obey the safepoint protocol) then the VMThread 
will never sneak it because it will never see it unowned unless it is 
actually unlocked. And of course the VMThread should then only ever see 
it unlocked (it doesn't strictly matter of the VMThread is using 
try_lock, but if the VMThread sees it locked then it means that the lock 
owner has hit a safepoint check while holding the lock [ and blocked] 
and that is generally undesirable.

David

>
> Hiroshi
>