RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

Alan Bateman alanb at openjdk.org
Wed Nov 6 17:40:10 UTC 2024


On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>>  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.

Just to add that the 2 extension events (VirtualThreadMount and  VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code).

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

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


More information about the core-libs-dev mailing list