RFR: 8328083: degrade virtual thread support for GetObjectMonitorUsage
Serguei Spitsyn
sspitsyn at openjdk.org
Thu May 2 06:48:53 UTC 2024
On Wed, 1 May 2024 21:11:36 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/serviceability/jvmti/ObjectMonitorUsage/ObjectMonitorUsage.java line 257:
>
>> 255: // Correct the expected values for the virtual thread case.
>> 256: int expEnteringCount = isVirtual ? 0 : NUMBER_OF_ENTERING_THREADS;
>> 257: int expWaitingCount = isVirtual ? 0 : NUMBER_OF_WAITING_THREADS;
>
> There are comments below that still reference NUMBER_OF_ENTERING_THREADS and NUMBER_OF_WAITING_THREADS.
Thank you for the comment. In fact, I don't know how to fix it.
Replacing with `expEnteringCount/expWaitingCount` does not make sense to me.
The comments are about the tested pattern, not about the real values.
Please, let me know if you have any suggestion on fixing.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/19030#discussion_r1587142283
More information about the serviceability-dev
mailing list