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

[Patricio Chilano Mateo]

On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.
> 
> Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.
>
After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760