RFR: 8247972: incorrect implementation of JVM TI GetObjectMonitorUsage [v5]

[David Holmes]

On Wed, 14 Feb 2024 12:16:38 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> src/hotspot/share/runtime/threads.cpp line 1200:
>> 
>>> 1198:     if (pending == monitor ||
>>> 1199:         (waiting == monitor && JavaThreadStatus::BLOCKED_ON_MONITOR_ENTER ==
>>> 1200:          java_lang_Thread::get_thread_status(p->vthread_or_thread()))
>> 
>> This code seems extremely racy. Is there anything that is stopping the target thread from running while we attempt this inspection of the oop state? If it was waiting and was interrupted or timed-out then we could mistakenly think it was still pending entry to this monitor when in fact it is not.
>> It is also a shame that we have to reach up into the oop thread state to figure out if if it is blocked on re-entry ...
>
> The function `get_pending_threads()` is executed only by the VM_GetObjectMonitorUsage operation.
> I've added this assert there: 
>     `assert(Thread::current()->is_VM_thread(), "Must be the VM thread");`
> Does it address your concern?

Yes thanks. Didn't realize we were in a safepoint VM op.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1490510763