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

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

Commit messages:
 - Improve condition in OM::has_owner()
 - Fix OM::has_owner()
 - 8295849: Consolidate Threads::owning_thread*

Changes: https://git.openjdk.org/jdk/pull/10849/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10849&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295849
  Stats: 68 lines in 7 files changed: 18 ins; 36 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/10849.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10849/head:pull/10849

PR: https://git.openjdk.org/jdk/pull/10849

Reply via email to