RFR: 8320318: ObjectMonitor Responsible thread [v3]

[Fredrik Bredberg]

On Fri, 20 Sep 2024 13:17:02 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 467:
>> 
>>> 465:   intx _held_monitor_count;  // used by continuations for fast lock detection
>>> 466:   intx _jni_monitor_count;
>>> 467:   ObjectMonitor* _unlocked_inflated_monitor;
>> 
>> At the time we store this the OM is in-use but we have unlocked it and so by the time we go to re-lock it later it may no longer be in-use. What prevents it from being deflated and deallocated? Does it require a safepoint that can't happen on that code path? If so we should add a comment to that affect somewhere.
>
> I asked the GC guys @fisk and @xmas92 about this some time ago, and they assured me that it was ok.
> Unfortunately I forgot about the details, so I re-asked them today and they said: "Since there is no safepoint polling when calling into the VM, so you can be sure that it hasn't been dealocated." I'll add a comment about it `SharedRuntime::monitor_exit_helper()`.

fixed

>> test/micro/org/openjdk/bench/vm/lang/LockUnlock.java line 315:
>> 
>>> 313:      * inflated.
>>> 314:      */
>>> 315:     @Threads(3)
>> 
>> Please explain this change and update the comment.
>
> he reason I increased the number of threads from 2 to 3, was because it enabled me to increase the code coverage, and thereby execute all(?) the corner cases when doing ObjectMonitor locking. I'll update the comment.

fixed

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19454#discussion_r1775316076
PR Review Comment: https://git.openjdk.org/jdk/pull/19454#discussion_r1775319069