On Thu, 8 Feb 2024 15:29:47 GMT, Daniel D. Daugherty <dcu...@openjdk.org> wrote:
>> Yes, I've figured this out now. Thank you for pointing to it. >> It feels, the counts can be calculated correctly without touching the >> implementation of `current_pending_monitor()`, `current_waiting_monitor()`, >> `_contensions` and `_waiters`. >> At least, I'll try to fix it locally in the >> `JvmtiEnvBase::get_object_monitor_usage()`. >> Please, let me know what do you prefer. > > I don't have a preference (yet). Like what David suggested, I think we need to > determine the list of thread and monitor interaction scenarios that want to > exercise with this API. Once we're happy that those scenarios represent the > complete list of possible combinations we should double check that against the > API spec to make sure that those scenarios cover the API spec. Finally, we > need > to make sure that we have a test that covers all those scenarios. > > It has been a long, long time since I've looked at those NSK tests... :-( Thank you, Dan! I have a fix and will push it after the mach5 tiers testing. I've extended the test `test/hotspot/jtreg/vmTestbase/nsk/jvmti/GetObjectMonitorUsage/objmonusage003` to have all combinations that David suggested but it was a little bit tricky to make it stable. It feels that an update of the current_pending_monitor() to report the re-entered monitors would make it more elegant. But I'm not sure how to do it correctly yet. Also, I've noticed we do not post the JVMTI events `MonitorContendedEnter` and `MonitorContendedEntered` for the re-enter case. It looks like a bug to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/17680#discussion_r1484843163
