On Fri, 28 Oct 2022 15:28:42 GMT, Roman Kennke <rken...@openjdk.org> wrote:
>> There are several users and even mostly-identical implementations of >> Threads::owning_thread_from_monitor_owner(), which I would like to >> consolidate a little in preparation of JDK-8291555: >> - JvmtiEnvBase::get_monitor_usage(): As the comment in >> ObjectSynchronizer::get_lock_owner() suggests, the JVMTI code should call >> the ObjectSynchronizer method. The only real difference is that JVMTI loads >> the object header directly while OS spins to avoid INFLATING. This is >> harmless, because JVMTI calls from safepoint, where INFLATING does not >> occur, and would just do a simple load of the header. A little care must be >> taken to fetch the monitor if exists a few lines below, to fill in monitor >> info. >> - Two ThreadService methods call >> Threads::owning_thread_from_monitor_owner(), but always only ever from a >> monitor. I would like to extract that special case because with fast-locking >> this can be treated differently (with fast-locking, monitor owners can only >> be JavaThread* or 'anonynmous'). It's also a little cleaner IMO. >> >> Testing: >> - [x] GHA (x86 and x-compile failures look like infra glitch) >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> - [x] tier4 > > Roman Kennke has updated the pull request with a new target base due to a > merge or a rebase. The incremental webrev excludes the unrelated changes > brought in by the merge/rebase. The pull request contains five additional > commits since the last revision: > > - Merge branch 'master' into JDK-8295849 > - Fix has_owner() condition > - Improve condition in OM::has_owner() > - Fix OM::has_owner() > - 8295849: Consolidate Threads::owning_thread* I wasn't expecting this PR to integrate until after I posted the latest test results... ------------- PR: https://git.openjdk.org/jdk/pull/10849
