On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes <dhol...@openjdk.org> wrote:
>> 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. > > If the virtual thread is un-mounting from the carrier, why do we need to set > the "lock id" back to the virtual thread's id? Sorry I'm finding this quite > confusing. > > Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id > to use for locking" - correct? Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back. We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos. [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450
