RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning [v30]

[Patricio Chilano Mateo]

On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>> 
>>> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
>>> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);
>> 
>> We post a JVMTI `MonitorWaited` event here for a virtual thread.
>> A couple of questions on this:
>> - Q1: Is this posted after the `VirtualThreadMount` extension event posted?
>>          Unfortunately, it is not easy to make this conclusion.
>> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
>>           Does it post the `MonitorWaited` event for this virtual thread as well?
>>           If not, then it is not clear how posting for virtual thread is avoided.
>
>>  Is this posted after the VirtualThreadMount extension event posted?
>>
> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

> The JvmtiExport::post_monitor_waited() is called at the line 1801.
> Does it post the MonitorWaited event for this virtual thread as well?
>
That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475