RFR: 8328083: degrade virtual thread support for GetObjectMonitorUsage

[Serguei Spitsyn]

On Wed, 1 May 2024 20:30:54 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> The fix is to degrade virtual threads support in the JVM TI `GetObjectMonitorUsage` function so that it is specified to only return an owner when the owner is a platform thread. Also, virtual threads are not listed in the both `waiters` and `notify_waiters` lists returned in the `jvmtiMonitorUsage` structure. Java 19 re-specified a number of JVMTI functions and events for virtual threads, we missed this one.
>> 
>> The main motivation for degrading it now is that the object monitor implementation is being updated to allow virtual threads unmount while owning monitors. It would add overhead to record monitor usage when freezing/unmount, overhead that couldn't be tied to a JVMTI capability as the capability can be enabled at any time.
>> 
>> `GetObjectMonitorUsage` was broken for 20+ years ([8247972](https://bugs.openjdk.org/browse/JDK-8247972)) without bug reports so it seems unlikely that the function is widely used. Degrading it to only return an owner when the owner is a platform thread has no compatibility impact for tooling that uses it in conjunction with `HotSpot` thread dumps or `ThreadMXBean`.
>> 
>> One other point about `GetObjectMonitorUsage` is that it pre-dates j.u.concurrent in Java 5 so it can't be used to get a full picture of the lock usage in a program.
>> 
>> The specs of the impacted `JDWP ObjectReference.MonitorInfo` command and the JDI `ObjectReference` `ownerThread()`, `waitingThreads()` and `entryCount()` methods are updated to match the JVM TI spec.
>> 
>> Also, please, review the related CSR and Release Note:
>> - CSR: [8331422](https://bugs.openjdk.org/browse/JDK-8331422): degrade virtual thread support for GetObjectMonitorUsage
>> - RN: [8331465](https://bugs.openjdk.org/browse/JDK-8331465): Release Note: degrade virtual thread support for GetObjectMonitorUsage
>> 
>> Testing:
>>  - tested impacted and updated tests locally
>>  - tested with mach5 tiers 1-6
>
> src/hotspot/share/prims/jvmti.xml line 8279:
> 
>> 8277:           <description>
>> 8278:             The number of platform threads waiting to be notified by this monitor,
>> 8279:             or <code>0</code> if the monitor is owned by a virtual thread or not owned
> 
> Same consistency issue as with `waiter_count`

Thanks. Let's align it with `waiter_count` solution.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586902737