On Tue, 18 Nov 2025 00:39:14 GMT, Serguei Spitsyn <[email protected]> wrote:
>> Anton Artemov has updated the pull request incrementally with one additional >> commit since the last revision: >> >> 8366659: Addressed reviewer's comments. > > 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. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27040#discussion_r2700092565
