On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo <pchilanom...@openjdk.org> wrote:
>> 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 > Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to > use for locking" - correct? > Yes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846
