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

[Hiroshi Yamauchi]

> 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.
>

Thanks, David.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/attachments/20130619/47558ab1/attachment.html