RFR: 8328083: degrade virtual thread support for GetObjectMonitorUsage

[Serguei Spitsyn]

On Wed, 1 May 2024 21:03:31 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
>
> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 65:
> 
>> 63:         }
>> 64:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 65:         // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrapper" is not the proper terminology any more.  It's "Test Thread Factory" (JTREG_TEST_THREAD_FACTORY=Virtual).

Good suggestion, thanks. Then I'd suggest this:

        // Virtual threads are not supported by the GetObjectMonitorUsage.
        // Correct the expected values if the test is executed with the
        // JTREG_TEST_THREAD_FACTORY=Virtual.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage001.java line 158:
> 
>> 156:     public void run() {
>> 157:         // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 158:         // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrapper" again.

Thanks. Same as above.

> test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage004.java line 64:
> 
>> 62:         synchronized (lockCheck) {
>> 63:             // Virtual threads are not supported by the GetObjectMonitorUsage. Correct
>> 64:             // the expected values if the test is executed with MainWrapper=virtual.
> 
> "MainWrappe" again.

Thanks. Same as above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586908764
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586908965
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1586909037