On Thu, 13 May 2021 05:22:51 GMT, David Holmes <[email protected]> wrote:
>> Robbin Ehn has updated the pull request incrementally with one additional
>> commit since the last revision:
>>
>> Fixes for Dan
>
> 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.
-------------
PR: https://git.openjdk.java.net/jdk/pull/3875
