On 17/05/2021 5:05 pm, Robbin Ehn wrote:
On Thu, 13 May 2021 05:22:51 GMT, David Holmes <dhol...@openjdk.org> 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.
Only if the VMThread executes code that uses the same RM - which should
be a rare occurrence.
David
-----
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
