On Mon, 17 May 2021 07:02:30 GMT, Robbin Ehn <[email protected]> wrote:
>> src/hotspot/share/prims/jvmtiRawMonitor.hpp line 48:
>>
>>> 46: // The rules are:
>>> 47: // - We must never safepoint poll if raw monitor is owned.
>>> 48: // - We may safepoint poll before it is owned and after it has been
>>> released.
>>
>> I'm not sure exactly what this is trying to say because user code can
>> acquire a RawMonitor, then call into Java while holding the RawMonitor. That
>> external use of RawMonitors should never cause any deadlock with the
>> VMThread of course.
>
> This comment applies to the RawMonitor code, where the typical use-case that
> otherwise can deadlock is:
> JavaThread:
> -lock RM
> LOOP {
> -wait RM
> -do stufff with data from VM thread
> }
> -unlock RM
>
> The user do not call into the VM/Java.
>
> VM Thread:
> -safepoint
> -lock RM
> -notify RM
> -unlock RM
>
> If we in this case safepoint between the lock and the unlock in wait() we
> deadlock with VM thread.
>
> If the user would call into the VM/Java while holding the RM he obviously
> could deadlock with VM thread.
> But he would also deadlock if he used a pthread mutex because that code would
> be buggy.
Okay I understand what you are referring to now - thanks. It is a bit
concerning that Raw Monitor wait is specified to be callback safe as that means
we can legitimately block the VMThread indefinitely!
-------------
PR: https://git.openjdk.java.net/jdk/pull/3875
