RFR(S): 8236035: refactor ObjectMonitor::set_owner() and _owner field setting
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Dec 17 21:35:04 UTC 2019
Greetings,
I'm extracting another standalone fix from the Async Monitor Deflation
project (JDK-8153224) and sending it out for review (and testing)
separately.
JDK-8236035 refactor ObjectMonitor::set_owner() and _owner field
setting
https://bugs.openjdk.java.net/browse/JDK-8236035
Here's the webrev URL:
http://cr.openjdk.java.net/~dcubed/8236035-webrev/0-for-jdk15/
Folks that have reviewed JDK-8153224 will recognize these changes as
a subset of the _owner field changes from the Async Monitor Deflation
project. It's a subset because the Async Monitor Deflation project
needs one additional simply_set_owner_from() variant.
In this set of changes:
- We replace the one use of set_owner() and the direct _owner field
updates with four distinct functions:
235 // Clear _owner field; current value must match old_value.
236 void release_clear_owner_with_barrier(void* old_value, bool
needs_fence);
237 // Simply set _owner field to new_value; current value must
match old_value.
238 void simply_set_owner_from(void* old_value, void* new_value);
239 // Simply set _owner field to self; current value must match
basic_lock_p.
240 void simply_set_owner_from_BasicLock(void* basic_lock_p,
Thread* self);
241 // Try to set _owner field to new_value if the current value matches
242 // old_value. Otherwise, does not change the _owner field.
243 void* try_set_owner_from(void* old_value, void* new_value);
- Each function has an assert() to verify the pre-condition and has new
log_trace(monitorinflation, owner) calls for logging ownership changes.
- The gory details about necessary memory syncing or why memory syncing
is not needed is now in one place rather than at each call site.
These changes are being tested in a Mach5 Tier[1-3] run that's still
running (JDK14 ATR has priority). I'm also running these changes thru
a set of 10 SPECjbb2015 runs.
Thanks, in advance, for comments, questions or suggestions.
Dan
More information about the hotspot-runtime-dev
mailing list