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

[David Holmes]

On 17/05/2021 5:05 pm, Robbin Ehn wrote:
> 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.

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
>