On Fri, 16 Jan 2026 21:50:07 GMT, Daniel D. Daugherty <[email protected]> wrote:
>> src/hotspot/share/runtime/objectMonitor.cpp line 1950: >> >>> 1948: // as having "-locked" the monitor, but the OS and >>> java.lang.Thread >>> 1949: // states will still report that the thread is blocked trying >>> to >>> 1950: // acquire it. >> >> Q: I have a concern here. Did we have a similar inconsistency before? As I >> see, this can be observable not only by thread dumps but also by JVMTI in >> general (independently of the thread's suspend status). @dcubed-ojdk, could >> you comment on this, please? > > Sorry for the long delay in getting back to this review. > > Hmmmm... I'm wondering if that comment is correct: > - We've creat `ExitOnSuspend eos` on L1961. > - We create `ThreadBlockInVMPreprocess` on L1963 AND we pass `eos`. > - We reenter the monitor on L1964. > - When we run the `ThreadBlockInVMPreprocess` destructor on L1972 below: > - We call the `eos` object on the current thread BEFORE we `call > process_if_requested` > > So it looks to me like we exit the monitor before we block for the safepoint > so we should not > be showing the monitor as "locked" by our "blocked" thread. I think the comment addition on L1974-1976 addresses this review thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2742799060
