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

[Alan Bateman]

On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
>
> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
> 
> RUNNING -> BLOCKING -> BLOCKED
> BLOCKED -> UNBLOCKING -> RUNNABLE
> 
> I'm just trying to get a better sense of what we can infer if we see these "transition" states.

We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

>> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.
>
> Thanks for the explanation but that needs to be documented somewhere.

The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

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

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