On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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` ? We could rename it to timedWaitSeqNo if needed. >> 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? Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier. setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648 PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960
