On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo <pchilanom...@openjdk.org> wrote:
>>> Some comments here about the operation would be useful. >>> >> Added a comment. > >> I'm struggling to understand how a thread can already be on this list? >> > With the removal of the _Responsible thread, it's less likely but it could > still happen. One case is when the virtual thread acquires the monitor after > adding itself to `_cxq` in `ObjectMonitor::VThreadMonitorEnter`. The owner > could have released the monitor in `ExitEpilog` and already added the virtual > thread to the waiting list. The virtual thread will continue running and may > face contention on a different monitor. When the owner of this latter monitor > picks the virtual thread as the successor it might still find it on the > waiting list (unblocker thread did not run yet). The same case can happen in > `ObjectMonitor::resume_operation` when acquiring the monitor after clearing > successor. Hmmmm ... I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015
