On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> src/java.base/share/classes/java/lang/VirtualThread.java line 115: >> >>> 113: * RUNNING -> WAITING // transitional state during wait >>> on monitor >>> 114: * WAITING -> WAITED // waiting on monitor >>> 115: * WAITED -> BLOCKED // notified, waiting to be >>> unblocked by monitor owner >> >> Waiting to re-enter the monitor? > > yes Okay so should it say that? >> src/java.base/share/classes/java/lang/VirtualThread.java line 178: >> >>> 176: // timed-wait support >>> 177: private long waitTimeout; >>> 178: private byte timedWaitNonce; >> >> Strange name - what does this mean? > > Sequence number, nouce, anything will work here as it's just to deal with the > scenario where the timeout task for a previous wait may run concurrently with > a subsequent wait. Suggestion: `timedWaitCounter` ? >> src/java.base/share/classes/java/lang/VirtualThread.java line 530: >> >>> 528: && carrier == Thread.currentCarrierThread(); >>> 529: carrier.setCurrentThread(carrier); >>> 530: Thread.setCurrentLockId(this.threadId()); // keep lock ID of >>> virtual thread >> >> I'm struggling to understand the different threads in play when this is >> called and what the method actual does to which threads. ?? > > A virtual thread is mounted but doing a timed-park that requires temporarily > switching to the identity of the carrier (identity = Therad.currentThread) > when queuing the timer task. As mentioned in a reply to Axel, we are close to > the point of removing this (nothing to do with object monitors of course, > we've had the complexity with temporary transitions since JDK 19). > > More context here is that there isn't support yet for a carrier to own a > monitor before a virtual thread is mounted, and same thing during these > temporary transitions. If support for custom schedulers is exposed then that > issue will need to be addressed as you don't want some entries on the lock > stack owned by the carrier and the others by the mounted virtual thread. > Patricio has mentioned inflating any held monitors before mount. There are a > couple of efforts in this area going on now, all would need that issue fixed > before anything is exposed. Okay but .... 1. We have the current virtual thread 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473
