On Tue, 22 Oct 2024 12:05:43 GMT, Alan Bateman <al...@openjdk.org> wrote:
>> 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_r1810615473
