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

[David Holmes]

On Mon, 17 May 2021 07:02:30 GMT, Robbin Ehn <rehn at openjdk.org> 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