RFR: 8265753: Remove manual JavaThread transitions to blocked [v3]

[Robbin Ehn]

On Thu, 13 May 2021 05:22:51 GMT, David Holmes <dholmes at 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.
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