RFR: 8328083: degrade virtual thread support for GetObjectMonitorUsage [v3]

Serguei Spitsyn sspitsyn at openjdk.org
Tue May 14 23:52:07 UTC 2024


On Thu, 2 May 2024 21:50:26 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> src/java.se/share/data/jdwp/jdwp.spec line 1622:
>> 
>>> 1620:             (threadObject owner "The platform thread owning this monitor, or <code>nullptr</code> "
>>> 1621:                                 "if owned` by a virtual thread or not owned.")
>>> 1622:             (int entryCount "The number of times the owning platform thread has entered the monitor.")
>> 
>> See the comment I left for the JVMTI spec. We should be more complete in the explanation here, explaining how it is 0 for virtual threads.
>
> I don't think this has been resolved.

Okay, thanks! Fixed now. The update is:

--- a/src/java.se/share/data/jdwp/jdwp.spec
+++ b/src/java.se/share/data/jdwp/jdwp.spec
@@ -1619,9 +1619,11 @@ JDWP "Java(tm) Debug Wire Protocol"
         (Reply
             (threadObject owner "The platform thread owning this monitor, or null "
                                 "if owned by a virtual thread or not owned.")
-            (int entryCount "The number of times the owning platform thread has entered the monitor.")
+            (int entryCount "The number of times the owning platform thread has entered the monitor, "
+                            "or 0 if owned by a virtual thread or not owned.")
             (Repeat waiters "The total number of platform threads that are waiting to enter or re-enter "
-                            "the monitor, or waiting to be notified by the monitor."
+                            "the monitor, or waiting to be notified by the monitor, or 0 if "
+                            "only virtual threads are waiting or no threads are waiting."
                 (threadObject thread "A platform thread waiting for this monitor.")
             )
         )

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

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


More information about the serviceability-dev mailing list