RFR(L) 8153224 Monitor deflation prolong safepoints (CR12/v2.12/15-for-jdk15)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed May 20 13:42:39 UTC 2020
David H. pointed out that the spreadsheet attachment was stripped from
the mailing list email...
It can be downloaded via wget from:
http://cr.openjdk.java.net/~dcubed/8153224-webrev/A-B-A_with_is_being_async_deflated.ods
Sorry for any confusion.
Dan
On 5/19/20 9:05 PM, Daniel D. Daugherty wrote:
> Hi Eric,
>
> On 5/18/20 9:18 AM, Erik Österlund wrote:
>> Hi Dan,
>>
>> Looks better now.
>
> Thanks!
>
>
>> I would like to comment on some further correctness problems I
>> discovered though,
>> as a continuation of some discussions we had before
>> CR12/v2.12/15-for-jdk15
>
> Thank you for switching to this thread (CR12/v2.12/15-for-jdk15) That
> will
> help me keep things straight in my head...
>
>> First of all, I misremembered that deflation had a linearization
>> point. You were right; _contentions
>> transitioning to a negative value, is not definitive, and not a
>> linearization point where the whole
>> operation logically commits, with no going back. This explains my
>> confusion why is_async_deflated()
>> both loads the _owner and the _contentions field.
>
> Just for context and clarity: is_being_async_deflated() is a wrapper
> function that I added in v2.11. Prior to that, we were checking the
> owner field and the ref_count field directly to determine whether it
> was safe to complete async monitor deflation (what you call the
> linearization point). So we've _always_ been checking two independent
> fields. The difference between the various versions is which two fields
> and, as of v2.11, we now have a wrapper: is_being_async_deflated().
>
>
>> Unfortunately, it seems like it is still wrong.
>> Because now we are in a situation where we have two separate atomic
>> variables, and neither one of them
>> transitions monotonically. Two slippery states.
>
> And the algorithm that Carsten came up with accounts for the fact that
> we can't change the two fields atomically. At least in theory... :-)
>
>
>> The two loads do not both happen at one atomic snapshot in time. They
>> can be both reordered and
>> interleaved in unfortunate ways. Let's consider a scenario where JT1
>> performs monitor enter, ST
>> performs concurrent deflation, while JT2 calls is_async_deflated() on
>> the monitor.
>>
>> Consider the following unfortunate interleaving:
>>
>> JT1: increment _contentions
>> ST: install the deflation marker into the _owner
>> JT2: read _owner == deflation marker
>> JT1: try to CAS :owner from NULL to JT1, but fail due to deflation.
>> JT1: try to cancel deflation, by CASing _owner from deflation marker
>> to JT1, succeed.
>> JT1: decrement _contentions
>> ST: CAS _contentions from 0 to -max_jint, succeed.
>> JT2: read _contentions < 0.
>>
>> At this point JT2 has loaded the two values and returns true; it
>> thinks that the monitor is_async_deflated().
>>
>> ST: Read _owner again to see if ABA happened. It did.
>> ST: Increment _contentions again to bail out of async deflation, but
>> it is too late.
>
> Minor correction to the above scenario. The JT1 increment of
> contentions is in the wrong place according to code flow:
>
> ST: install the deflation marker into the _owner
> JT2: read _owner == deflation marker
> JT1: try to CAS :owner from NULL to JT1, but fail due to deflation.
> JT1: increment _contentions
> JT1: try to cancel deflation, by CASing _owner from deflation marker
> to JT1, succeed.
> JT1: decrement _contentions
> ST: CAS _contentions from 0 to -max_jint, succeed.
> JT2: read _contentions < 0.
>
> One source of potential confusion is that there are a number of places
> in the code where this bit is attempted:
>
> JT1: try to CAS :owner from NULL to JT1, ...
>
> I chose the one that would lead to JT1 having to increment contentions.
>
> The minor correction doesn't change the outcome of the above scenario.
>
> At the point that JT2 gets a wrong answer from is_being_async_deflated(),
> the subsequent call to install_displaced_markword_in_object() will
> disconnect the object from the ObjectMonitor and that leaves us with
> JT1 thinking it has the object locked (and owns the ObjectMonitor) AND
> the object is no longer attached to the ObjectMonitor AND the object is
> no longer locked (from the object's point of view).
>
> *********************************************
> * This is definitely a recipe for disaster! *
> * Thanks for catching this Erik!! *
> *********************************************
>
> As is usual for these kinds of races, I've done a complete analysis
> of the code paths involved using a spreadsheet that shows JT1, ST,
> JT2 code paths and their effects on Obj-A and OM-1's fields.
>
> I'm attaching it as A-B-A_with_is_being_async_deflated.ods. A very
> wide screen is useful for looking at the spreadsheet.
>
>
> ************************************************************************
> * The remaining analysis assumes you've looked at the spreadsheet and *
> * understand the code paths and the transactions that modify Obj-A and *
> * the fields in OM-1. *
> ************************************************************************
>
>
> Okay so how did we get into this mess? If we go back to v2.10, there
> were only two calls to install_displaced_markword_in_object():
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.full/src/hotspot/share/runtime/objectMonitor.cpp.frames.html
>
>
> 1) ObjectMonitorHandle::save_om_ptr() called it from this code block:
>
> L2074: ObjectMonitor* om_ptr = mark.monitor();
> L2075: om_ptr->inc_ref_count();
> L2076:
> L2077: if (AsyncDeflateIdleMonitors) {
> L2078: // Race here if monitor is not owned! The above
> ref_count bump
> L2079: // will cause subsequent async deflation to skip it.
> However,
> L2080: // previous or concurrent async deflation is a race.
> L2081: if (om_ptr->owner_is_DEFLATER_MARKER() &&
> om_ptr->ref_count() <= 0) {
> L2082: // Async deflation is in progress and our ref_count
> increment
> L2083: // above lost the race to async deflation. Attempt to
> restore
> L2084: // the header/dmw to the object's header so that we
> only retry
> L2085: // once if the deflater thread happens to be slow.
> L2086: om_ptr->install_displaced_markword_in_object(object);
> L2087: om_ptr->dec_ref_count();
> L2088: return false;
> L2089: }
> L2090: if (om_ptr->ref_count() <= 0) {
> L2091: // Async deflation is in the process of bailing out,
> but has not
> L2092: // yet restored the ref_count field so we return
> false to force
> L2093: // a retry. We want a positive ref_count value for a
> true return.
> L2094: om_ptr->dec_ref_count();
> L2095: return false;
> L2096: }
>
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.full/src/hotspot/share/runtime/synchronizer.cpp.frames.html
>
>
> 2) ObjectSynchronizer::deflate_monitor_using_JT() called it from this
> code block:
>
> L2226: if (mid->try_set_owner_from(NULL, DEFLATER_MARKER) ==
> NULL) {
> <snip>
> L2229: // .............. This is just the first part of the async
> L2230: // deflation dance.
> <snip>
> L2241: if (Atomic::cmpxchg(&mid->_ref_count, (jint)0,
> -max_jint) == 0) {
> <snip>
> L2243: // ...................................... This is the
> second
> L2244: // part of the async deflation dance.
> <snip>
> L2246: if (mid->owner_is_DEFLATER_MARKER()) {
> <snip>
> L2250: // ............ This is the third and final part of
> the async
> L2251: // deflation dance.
> <snip>
> L2276: // Install the old mark word if nobody else has
> already done it.
> L2277: mid->install_displaced_markword_in_object(obj);
> L2278: mid->clear_using_JT();
>
> ************************************************************************************
>
> * The second location defines the three part async deflation protocol.
> While v2.11 *
> * restructured the code and switched us from _ref_count to
> _contentions, the three *
> * part protocol remains intact and is the key to advertising that we
> (the deflater *
> * thread) are committed to finishing the async
> deflation. *
> ************************************************************************************
>
>
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.full/src/hotspot/share/runtime/objectMonitor.cpp.frames.html
>
>
> In v2.11, we got rid of ObjectMonitorHandles and ref_counting. Because
> of this
> the first location in save_om_ptr() was copied to
> ObjectMonitor::enter() and
> adapted to become this block of code:
>
> L296: // Keep track of contention for JVM/TI and M&M queries.
> L297: add_to_contentions((jint)1);
> L298: if (AsyncDeflateIdleMonitors && is_being_async_deflated()) {
> L299: // Async deflation is in progress and our contentions
> increment
> L300: // above lost the race to async deflation. Undo the work
> and
> L301: // force the caller to retry.
> L302: const oop l_object = (oop)object();
> L303: if (l_object != NULL) {
> L304: // Attempt to restore the header/dmw to the object's
> header so that
> L305: // we only retry once if the deflater thread happens
> to be slow.
> L306: install_displaced_markword_in_object(l_object);
> L307: }
> L308: Self->_Stalled = 0;
> L309: Atomic::dec(&_contentions);
> L310: return false;
> L311: }
>
> In v2.12, L298 in ObjectMonitor::enter() became this:
>
> L298 if (is_being_async_deflated()) {
>
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.full/src/hotspot/share/runtime/synchronizer.cpp.frames.html
>
>
> In v2.11, we also added a call to is_being_async_deflated() in
> FastHashCode():
>
> L0988: intptr_t ObjectSynchronizer::FastHashCode(Thread* self, oop
> obj) {
> <snip>
> L1100: if (monitor->is_being_async_deflated()) {
> L1101: // If we detect that async deflation has occurred,
> then we
> L1102: // simply retry so that the hash value can be
> stored in either
> L1103: // the object's header or in the re-inflated
> ObjectMonitor's
> L1104: // header as appropriate.
> L1105: continue;
> L1106: }
>
> Please notice that in v2.11, we did not call
> install_displaced_markword_in_object()
> from FastHashCode(). That's a change that we made in v2.12 and, in
> fact, we added
> two calls:
>
> http://cr.openjdk.java.net/~dcubed/8153224-webrev/15-for-jdk15%2b23.v2.12.full/src/hotspot/share/runtime/synchronizer.cpp.frames.html
>
>
> L0987: intptr_t ObjectSynchronizer::FastHashCode(Thread* self, oop
> obj) {
> <snip>
> L1043: } else if (mark.has_monitor()) {
> <snip>
> L1048: if (hash != 0) {
> <snip>
> L1061: if (monitor->is_being_async_deflated()) {
> L1062: // But we can't safely use the hash if we detect
> that async
> L1063: // deflation has occurred. So we attempt to
> restore the
> L1064: // header/dmw to the object's header so that we
> only retry
> L1065: // once if the deflater thread happens to be slow.
> L1066: monitor->install_displaced_markword_in_object(obj);
> L1067: continue;
> L1068: }
> <snip>
> L1092: // Inflate the monitor to set the hash.
> <snip>
> L1096: monitor = inflate(self, obj, inflate_cause_hash_code);
> <snip>
> L1101: if (hash == 0) { // if it does not
> have a hash
> <snip>
> L1117: if (monitor->is_being_async_deflated()) {
> L1118: // If we detect that async deflation has occurred,
> then we
> L1119: // attempt to restore the header/dmw to the
> object's header
> L1120: // so that we only retry once if the deflater
> thread happens
> L1121: // to be slow.
> L1122: monitor->install_displaced_markword_in_object(obj);
> L1123: continue;
> L1124: }
>
>
> Okay, so that's the long sordid tale of how we got to this bug. Dropping
> ref_counting required that we drop the save_om_ptr() call that we had in
> FastHashCode() and we replaced it with inferior code. At first glance, it
> looks like we put equivalent code in FastHashCode() that we have in
> ObjectMonitor::enter(), but a key piece is missing.
>
> Here's the uncommented v2.12 code block from ObjectMonitor::enter():
>
> L297: add_to_contentions((jint)1);
> L298: if (is_being_async_deflated()) {
> L302: const oop l_object = (oop)object();
> L303: if (l_object != NULL) {
> L306: install_displaced_markword_in_object(l_object);
> L307: }
> L308: Self->_Stalled = 0;
> L309: Atomic::dec(&_contentions);
> L310: return false;
> L311: }
>
> And here's one of the uncommented v2.12 code blocks from FastHashCode():
>
> L1061: if (monitor->is_being_async_deflated()) {
> L1066: monitor->install_displaced_markword_in_object(obj);
> L1067: continue;
> L1068: }
>
> But L298 and L306 for ObjectMonitor::enter() are the same as L1061 and
> L1066 in FastHashCode()! Yes that is true, but ObjectMonitor::enter()
> has two more key lines:
>
> L297: add_to_contentions((jint)1);
> L309: Atomic::dec(&_contentions);
>
> The ObjectMonitor::enter() code path modifies contentions and then
> checks it in the is_being_async_deflated(). That's important because
> the enter() code path changes contentions to indicate that it wants
> to make the ObjectMonitor safe and then it checks to see if the
> ObjectMonitor is safe. If it is not safe, then the enter() code path
> does not use the ObjectMonitor and retries.
>
> The save_om_ptr() function from v2.10 did the same thing. Only when
> save_om_ptr() was sure that the ObjectMonitor was safe did it save
> the ObjectMonitor* in the ObjectMonitorHandle. Since all uses of
> ObjectMonitor* resulted in the creation of an ObjectMonitorHandle
> and a call to save_om_ptr(), no call site was able to slip past the
> safety check. Either deflate_monitor_using_JT() was able to follow
> the three part protocol and all the save_om_ptr() calls retried
> or one or more of the save_om_ptr() calls won the race and
> deflate_monitor_using_JT() bailed.
>
>
> *******************************************************************
> * The v2.11 and v2.12 code blocks in FastHashCode() do not change *
> * anything that would make the ObjectMonitor safe AND in v2.12 we *
> * call install_displaced_markword_in_object() with the assumption *
> * that the deflater thread is committed to the async deflation *
> * protocol. Too bad that assumption is wrong and that results in *
> * Obj-A being disconnected from OM-1. Ouch!! *
> *******************************************************************
>
>
> We could add an increment of the contentions field to FastHashCode().
> I think Erik O. mentioned that in one of the recent RFR emails for this
> project. That would make FastHashCode() follow the same protocol as
> ObjectMonitor::enter() and would solve the race. Unfortunately, the
> increment (and subsequent decrement) would add two write modifications
> to FastHashCode() that weren't there before and that's very likely to
> have performance implications.
>
> *********************************************************************
> * The other alternative is to have is_being_async_deflated() follow *
> * same three part protocol as deflate_monitor_using_JT(). *
> *********************************************************************
>
> Here's the v2.12 version of is_being_async_deflated()
>
> L68: // Returns true if 'this' is being async deflated and false
> otherwise.
> L69: inline bool ObjectMonitor::is_being_async_deflated() {
> L70: return AsyncDeflateIdleMonitors &&
> owner_is_DEFLATER_MARKER() && contentions() < 0;
> L71: }
>
> And here's the proposed new version:
>
> // Returns true if 'this' is being async deflated and false
> otherwise.
> inline bool ObjectMonitor::is_being_async_deflated() {
> if (AsyncDeflateIdleMonitors &&
> // Check first part of the async deflation dance:
> owner_is_DEFLATER_MARKER() &&
> // Check second part of the async deflation dance:
> contentions() < 0 &&
> // Check third part of the async deflation dance, i.e.,
> the
> // owner field is still DEFLATER_MARKER:
> owner_is_DEFLATER_MARKER()
> ) {
> return true;
> }
> return false;
> }
>
>
>> So it seems to me that the two last lines where the ServiceThread
>> checks for ABA and then increments the
>> _contentions counter was supposed to solve some ABA problem. But I
>> don't think it just narrows the window.
>> That code should arguably be removed. The damage was really already
>> done when the counter became negative,
>> despite JT1 signalling an abort.
>> The ServiceThread could get preempted before the ABA checks, and all
>> other threads would have to somehow
>> recognize anyway that the deflation has aborted, despite the counter
>> being negative. So the algorithm really
>> has to work even with that code commented out, AFAICT, which makes
>> that code confusing and redundant.
>
> The key to making async deflation safe is the three part protocol that
> we follow in deflate_idle_monitor_using_JT(). That's the protocol that
> solves the A-B-A problem with an entering thread that has called
> ObjectMonitor::enter() -> ObjectMonitor::EnterI() and managed to CAS
> update the owner field from DEFLATER_MARKER -> Self.
>
> There's a whole subsection in the wiki on the topic:
>
> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation#AsyncMonitorDeflation-T-enterWinsByA-B-A
>
>
> Without the A-B-A check and the logic in ObjectMonitor::EnterI(), when
> the first part of the deflation protocol sets owner to DEFLATER_MARKER,
> then every contending thread that has made it past the increment of the
> contentions field will block in the enter queue, wait for the owner
> field to be reset from DEFLATER_MARKER to NULL, and then wait for a
> successor to be chosen and woken up. Progress will stall.
>
> With the A-B-A check and the logic in ObjectMonitor::EnterI(), when the
> first part of the deflation protocol sets owner to DEFLATER_MARKER, then
> one of the contending threads that has made it past the increment of the
> contentions field will succeed on entering the ObjectMonitor and progress
> will be made. The other contending threads that made it past the
> increment
> of the contentions field will block in the enter queue (as is normal).
>
>
>> In the solution space, I would like to make it so that there really
>> is a linearization point for committing
>> the deflation when the counter is decremented to a negative value.
>
> I've previously said that this line of code defines the linearization
> point:
>
> (owner_is_DEFLATER_MARKER() && contentions() < 0)
>
> After the analysis of this race (thank you for finding it), I have to
> amend
> that to this:
>
> (owner_is_DEFLATER_MARKER() && contentions() < 0 &&
> owner_is_DEFLATER_MARKER())
>
> so that the check for the linearization point matches the logic
> implemented by
> the three part async deflation protocol in deflate_monitor_using_JT().
>
> I think the solution that I'm proposing with the revised version of
> ObjectMonitor::is_being_async_deflated() above is way simpler than what
> is described in the next two paragraphs below. Obviously, this is the
> key piece of this reply and I need to know if you agree that the above
> closes the race (on TSO machines!).
>
>
>> The idea is to let JT1 that aborts the deflation with a successful
>> _owner flip to leave its stake in the
>> _contentions counter there when it exits, so that the linearization
>> point is blocked appropriately. The
>> responsibility to decrement the _contentions counter falls to the
>> ServiceThread. Once it tries to CAS
>> the _contentions from 0 to negative, it is guaranteed to fail if
>> another thread has flipped back the _owner.
>> When the service thread fails to make the counter negative (and hence
>> commit the deflation operation as definitive),
>> it tries to CAS the _owner back to NULL. If that succeeds, then the
>> ServiceThread aborted deflation. If that does not
>> succeed, another thread aborted deflation, and then the ServiceThread
>> decrements _contentions by 1 to
>> balance out the counter (as whichever thread left 1 stake in the
>> _contentions counter).
>>
>> Now we have a real linearization point. If anyone observes a negative
>> counter, the deflation is definitive.
>> If not, it has not yet been decided whether to commit or abort
>> deflation.
>> The is_async_deflated() function then simply becomes: return
>> Atomic::load(&_contentions) < 0.
>>
>> The second issue I would like to highlight is that all places where
>> we help out with installing back
>> the object markWord from the ObjectMonitor if a monitor is found to
>> be deflated, must have more rigorous
>> fencing between the load of _contentions in the is_async_deflated()
>> check and the load of the _header in
>> the install_displaced_markword_in_object() function. This is another
>> place where there exists IRIW issues.
>> Therefore, I propose to put another fancy if (nMCA) loadload else
>> loadload() right before loading the _header
>> in install_displaced_markword_in_object. If we don't do this then the
>> two loads can be reordered w.r.t. the
>> total order. This can result in a racy installation of a new
>> hashCode, that some threads start observing
>> and using, not making it to the deflated object header. This would
>> cause inconsistencies. It is once again a
>> situation where the value of _contentions to negative is updated by
>> one thread, and the update of the _header
>> to have a hashCode is performed by another thread, and all observers
>> must have a total ordering w.r.t. which
>> one happened-before the other, or we are in trouble. I'm okay if you
>> want to wait with commenting on this
>> until after our off-list IRIW discussion has cooled down though.
>
> I'm going to have to mull on the need for a memory barrier (loadload()
> for TSO) in between the is_being_async_deflated() call and the
> install_displaced_markword_in_object() call. If we decide we need it
> for all install_displaced_markword_in_object() calls, then it would
> make sense to put the logic in the function itself rather than in the
> callers.
>
>
>> Otherwise this looks good.
>
> Thanks.
>
>
>> And sorry for more headache.
>
> It's worth discussing this in gory detail before we integrate it than
> trying to hunt down elusive failures due to a race later.
>
> Thanks for your thorough reviews!
>
> Dan
>
>
>>
>> Thanks,
>> /Erik
>>
>> On 2020-05-14 23:40, Daniel D. Daugherty wrote:
>>> Greetings,
>>>
>>> I have made changes to the Async Monitor Deflation code in response to
>>> the CR11/v2.11/14-for-jdk15 code review cycle. Thanks to David H.,
>>> Erik O.,
>>> and Robbin for their OpenJDK reviews in the v2.11 round!
>>>
>>> I have attached the change list from CR11 to CR12 and I've also added a
>>> link to the CR11-to-CR12-changes file to the webrevs so it should be
>>> easy
>>> to find.
>>>
>>> Main bug URL:
>>>
>>> JDK-8153224 Monitor deflation prolong safepoints
>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>
>>> The project is currently baselined on jdk-15+23.
>>>
>>> Here's the full webrev URL for those folks that want to see all of the
>>> current Async Monitor Deflation code in one go (v2.12 full):
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/15-for-jdk15%2b23.v2.12.full/
>>>
>>>
>>> Some folks might want to see just what has changed since the last
>>> review
>>> cycle so here's a webrev for that (v2.12 inc):
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/15-for-jdk15%2b23.v2.12.inc/
>>>
>>>
>>>
>>> The OpenJDK wiki is currently at v2.11 and might require minor
>>> tweaks for v2.12:
>>>
>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>
>>> The jdk-15+23 based v2.12 version of the patch is going thru the usual
>>> Mach5 testing right now.
>>>
>>> Thanks, in advance, for any questions, comments or suggestions.
>>>
>>> Dan
>>>
>>>
>>> On 5/7/20 1:08 PM, Daniel D. Daugherty wrote:
>>>> Greetings,
>>>>
>>>> I have made changes to the Async Monitor Deflation code in response to
>>>> the CR10/v2.10/13-for-jdk15 code review cycle and DaCapo-h2 perf
>>>> testing.
>>>> Thanks to Erik O., Robbin and David H. for their OpenJDK reviews in
>>>> the
>>>> v2.10 round! Thanks to Eric C. for his help in isolating the DaCapo-h2
>>>> performance regression.
>>>>
>>>> With the removal of ref_counting and the ObjectMonitorHandle class,
>>>> the
>>>> Async Monitor Deflation project is now closer to Carsten's original
>>>> prototype. While ref_counting gave us ObjectMonitor* safety
>>>> enforced by
>>>> code, I saw a ~22.8% slow down with -XX:-AsyncDeflateIdleMonitors
>>>> ("off"
>>>> mode). The slow down with "on" mode -XX:+AsyncDeflateIdleMonitors
>>>> is ~17%.
>>>>
>>>> I have attached the change list from CR10 to CR11 instead of
>>>> putting it in
>>>> the body of this email. I've also added a link to the
>>>> CR10-to-CR11-changes
>>>> file to the webrevs so it should be easy to find.
>>>>
>>>> Main bug URL:
>>>>
>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>
>>>> The project is currently baselined on jdk-15+21.
>>>>
>>>> Here's the full webrev URL for those folks that want to see all of the
>>>> current Async Monitor Deflation code in one go (v2.11 full):
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.full/
>>>>
>>>>
>>>> Some folks might want to see just what has changed since the last
>>>> review
>>>> cycle so here's a webrev for that (v2.11 inc):
>>>>
>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.inc/
>>>>
>>>>
>>>> Because of the removal of ref_counting and the ObjectMonitorHandle
>>>> class, the
>>>> incremental webrev is a bit noisier than I would have preferred.
>>>>
>>>>
>>>> The OpenJDK wiki has NOT YET been updated for this round of changes:
>>>>
>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>
>>>> The jdk-15+21 based v2.11 version of the patch has been thru Mach5
>>>> tier[1-6]
>>>> testing on Oracle's usual set of platforms. Mach5 tier[78] are
>>>> still running.
>>>> I'm running the v2.11 patch through my usual set of stress testing on
>>>> Linux-X64 and macOSX.
>>>>
>>>> I'm planning to do a SPECjbb2015, DaCapo-h2 and volano round on the
>>>> CR11/v2.11/14-for-jdk15 bits.
>>>>
>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 2/26/20 5:22 PM, Daniel D. Daugherty wrote:
>>>>> Greetings,
>>>>>
>>>>> I have made changes to the Async Monitor Deflation code in
>>>>> response to
>>>>> the CR9/v2.09/12-for-jdk14 code review cycle. Thanks to Robbin and
>>>>> Erik O.
>>>>> for their comments in this round!
>>>>>
>>>>> With the extraction and push of {8235931,8236035,8235795} to
>>>>> JDK15, the
>>>>> Async Monitor Deflation code is back to "just" async deflation
>>>>> changes!
>>>>>
>>>>> I have attached the change list from CR9 to CR10 instead of
>>>>> putting it in
>>>>> the body of this email. I've also added a link to the
>>>>> CR9-to-CR10-changes
>>>>> file to the webrevs so it should be easy to find.
>>>>>
>>>>> Main bug URL:
>>>>>
>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>
>>>>> The project is currently baselined on jdk-15+11.
>>>>>
>>>>> Here's the full webrev URL for those folks that want to see all of
>>>>> the
>>>>> current Async Monitor Deflation code in one go (v2.10 full):
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.full/
>>>>>
>>>>>
>>>>> Some folks might want to see just what has changed since the last
>>>>> review
>>>>> cycle so here's a webrev for that (v2.10 inc):
>>>>>
>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.inc/
>>>>>
>>>>>
>>>>> Since we backed out the HandshakeAfterDeflateIdleMonitors option
>>>>> and the
>>>>> C2 ref_count changes and updated the copyright years, the "inc"
>>>>> webrev has
>>>>> a bit more noise in it than usual. Sorry about that!
>>>>>
>>>>> The OpenJDK wiki has been updated for this round of changes:
>>>>>
>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>
>>>>> The jdk-15+11 based v2.10 version of the patch has been thru Mach5
>>>>> tier[1-7]
>>>>> testing on Oracle's usual set of platforms. Mach5 tier8 is still
>>>>> running.
>>>>> I'm running the v2.10 patch through my usual set of stress testing on
>>>>> Linux-X64 and macOSX.
>>>>>
>>>>> I'm planning to do a SPECjbb2015 round on the
>>>>> CR10/v2.20/13-for-jdk15 bits.
>>>>>
>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On 2/4/20 9:41 AM, Daniel D. Daugherty wrote:
>>>>>> Greetings,
>>>>>>
>>>>>> This project is no longer targeted to JDK14 so this is NOT an
>>>>>> urgent code
>>>>>> review request.
>>>>>>
>>>>>> I've extracted the following three fixes from the Async Monitor
>>>>>> Deflation
>>>>>> project code:
>>>>>>
>>>>>> JDK-8235931 add OM_CACHE_LINE_SIZE and use smaller size on
>>>>>> SPARCv9 and X64
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235931
>>>>>>
>>>>>> JDK-8236035 refactor ObjectMonitor::set_owner() and _owner
>>>>>> field setting
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8236035
>>>>>>
>>>>>> JDK-8235795 replace monitor list
>>>>>> mux{Acquire,Release}(&gListLock) with spin locks
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235795
>>>>>>
>>>>>> Each of these has been reviewed separately and will be pushed to
>>>>>> JDK15
>>>>>> in the near future (possibly by the end of this week). Of course,
>>>>>> there
>>>>>> were improvements during these review cycles and the purpose of this
>>>>>> e-mail is to provided updated webrevs for this fix
>>>>>> (CR9/v2.09/12-for-jdk14)
>>>>>> within the revised context provided by {8235931, 8236035, 8235795}.
>>>>>>
>>>>>> Main bug URL:
>>>>>>
>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>
>>>>>> The project is currently baselined on jdk-14+34.
>>>>>>
>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>> of the
>>>>>> current Async Monitor Deflation code along with {8235931,
>>>>>> 8236035, 8235795}
>>>>>> in one go (v2.09b full):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09b.full/
>>>>>>
>>>>>>
>>>>>> Compare the open.patch file in 12-for-jdk14.v2.09.full and
>>>>>> 12-for-jdk14.v2.09b.full
>>>>>> using your favorite file comparison/merge tool to see how Async
>>>>>> Monitor Deflation
>>>>>> evolved due to {8235931, 8236035, 8235795}.
>>>>>>
>>>>>> Some folks might want to see just the Async Monitor Deflation
>>>>>> code on top of
>>>>>> {8235931, 8236035, 8235795} so here's a webrev for that (v2.09b
>>>>>> inc):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09b.inc/
>>>>>>
>>>>>>
>>>>>> These webrevs have gone thru several Mach5 Tier[1-8] runs along with
>>>>>> my usual stress testing and SPECjbb2015 testing and there aren't any
>>>>>> surprises relative to CR9/v2.09/12-for-jdk14.
>>>>>>
>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>> On 12/11/19 3:41 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>> response to
>>>>>>> the CR8/v2.08/11-for-jdk14 code review cycle. Thanks to David
>>>>>>> H., Robbin
>>>>>>> and Erik O. for their comments!
>>>>>>>
>>>>>>> This project is no longer targeted to JDK14 so this is NOT an
>>>>>>> urgent code
>>>>>>> review request. The primary purpose of this webrev is simply to
>>>>>>> close the
>>>>>>> CR8/v2.08/11-for-jdk14 code review loop and to let folks see how
>>>>>>> I resolved
>>>>>>> the code review comments from that round.
>>>>>>>
>>>>>>> Most of the comments in the CR8/v2.08/11-for-jdk14 code review
>>>>>>> cycle were
>>>>>>> on the monitor list changes so I'm going to take a look at
>>>>>>> extracting those
>>>>>>> changes into a standalone patch. Switching from
>>>>>>> Thread::muxAcquire(&gListLock)
>>>>>>> and Thread::muxRelease(&gListLock) to finer grained internal
>>>>>>> spin locks needs
>>>>>>> to be thoroughly reviewed and the best way to do that is
>>>>>>> separately from the
>>>>>>> Async Monitor Deflation changes. Thanks to Coleen for suggesting
>>>>>>> doing this
>>>>>>> extraction earlier.
>>>>>>>
>>>>>>> I have attached the change list from CR8 to CR9 instead of
>>>>>>> putting it in
>>>>>>> the body of this email. I've also added a link to the
>>>>>>> CR8-to-CR9-changes
>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>
>>>>>>> Main bug URL:
>>>>>>>
>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>
>>>>>>> The project is currently baselined on jdk-14+26.
>>>>>>>
>>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>>> of the
>>>>>>> current Async Monitor Deflation code in one go (v2.09 full):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09.full/
>>>>>>>
>>>>>>>
>>>>>>> Some folks might want to see just what has changed since the
>>>>>>> last review
>>>>>>> cycle so here's a webrev for that (v2.09 inc):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09.inc/
>>>>>>>
>>>>>>>
>>>>>>> The OpenJDK wiki has NOT yet been updated for this round of
>>>>>>> changes:
>>>>>>>
>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>
>>>>>>>
>>>>>>> The jdk-14+26 based v2.09 version of the patch has been thru
>>>>>>> Mach5 tier[1-7]
>>>>>>> testing on Oracle's usual set of platforms. Mach5 tier8 is still
>>>>>>> running.
>>>>>>> A slightly older version of the v2.09 patch has also been
>>>>>>> through my usual
>>>>>>> set of stress testing on Linux-X64 and macOSX with the addition
>>>>>>> of Robbin's
>>>>>>> "MoCrazy 1024" test running in parallel on Linux-X64 with the
>>>>>>> other tests in
>>>>>>> my lab. The "MoCrazy 1024" has been going for > 5 days and 6700+
>>>>>>> iterations
>>>>>>> without any failures.
>>>>>>>
>>>>>>> I'm planning to do a SPECjbb2015 round on the
>>>>>>> CR9/v2.09/12-for-jdk14 bits.
>>>>>>>
>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 11/4/19 4:03 PM, Daniel D. Daugherty wrote:
>>>>>>>> Greetings,
>>>>>>>>
>>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>>> response to
>>>>>>>> the CR7/v2.07/10-for-jdk14 code review cycle. Thanks to David
>>>>>>>> H., Robbin
>>>>>>>> and Erik O. for their comments!
>>>>>>>>
>>>>>>>> JDK14 Rampdown phase one is coming on Dec. 12, 2019 and the
>>>>>>>> Async Monitor
>>>>>>>> Deflation project needs to push before Nov. 12, 2019 in order
>>>>>>>> to allow
>>>>>>>> for sufficient bake time for such a big change. Nov. 12 is
>>>>>>>> _next_ Tuesday
>>>>>>>> so we have 8 days from today to finish this code review cycle
>>>>>>>> and push
>>>>>>>> this code for JDK14.
>>>>>>>>
>>>>>>>> Carsten and Roman! Time for you guys to chime in again on the
>>>>>>>> code reviews.
>>>>>>>>
>>>>>>>> I have attached the change list from CR7 to CR8 instead of
>>>>>>>> putting it in
>>>>>>>> the body of this email. I've also added a link to the
>>>>>>>> CR7-to-CR8-changes
>>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>>
>>>>>>>> Main bug URL:
>>>>>>>>
>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>
>>>>>>>> The project is currently baselined on jdk-14+21.
>>>>>>>>
>>>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>>>> of the
>>>>>>>> current Async Monitor Deflation code in one go (v2.08 full):
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/11-for-jdk14.v2.08.full
>>>>>>>>
>>>>>>>>
>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>> last review
>>>>>>>> cycle so here's a webrev for that (v2.08 inc):
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/11-for-jdk14.v2.08.inc/
>>>>>>>>
>>>>>>>>
>>>>>>>> The OpenJDK wiki did not need any changes for this round:
>>>>>>>>
>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>
>>>>>>>>
>>>>>>>> The jdk-14+21 based v2.08 version of the patch has been thru
>>>>>>>> Mach5 tier[1-8]
>>>>>>>> testing on Oracle's usual set of platforms. It has also been
>>>>>>>> through my usual
>>>>>>>> set of stress testing on Linux-X64, macOSX and Solaris-X64 with
>>>>>>>> the addition
>>>>>>>> of Robbin's "MoCrazy 1024" test running in parallel with the
>>>>>>>> other tests in
>>>>>>>> my lab. Some testing is still running, but so far there are no
>>>>>>>> new regressions.
>>>>>>>>
>>>>>>>> I have not yet done a SPECjbb2015 round on the
>>>>>>>> CR8/v2.08/11-for-jdk14 bits.
>>>>>>>>
>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 10/17/19 5:50 PM, Daniel D. Daugherty wrote:
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> The Async Monitor Deflation project is reaching the end game.
>>>>>>>>> I have no
>>>>>>>>> changes planned for the project at this time so all that is
>>>>>>>>> left is code
>>>>>>>>> review and any changes that results from those reviews.
>>>>>>>>>
>>>>>>>>> Carsten and Roman! Time for you guys to chime in again on the
>>>>>>>>> code reviews.
>>>>>>>>>
>>>>>>>>> I have attached the list of fixes from CR6 to CR7 instead of
>>>>>>>>> putting it
>>>>>>>>> in the main body of this email.
>>>>>>>>>
>>>>>>>>> Main bug URL:
>>>>>>>>>
>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>
>>>>>>>>> The project is currently baselined on jdk-14+19.
>>>>>>>>>
>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>> all of the
>>>>>>>>> current Async Monitor Deflation code in one go (v2.07 full):
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/10-for-jdk14.v2.07.full
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>>> last review
>>>>>>>>> cycle so here's a webrev for that (v2.07 inc):
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/10-for-jdk14.v2.07.inc/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The OpenJDK wiki has been updated to match the
>>>>>>>>> CR7/v2.07/10-for-jdk14 changes:
>>>>>>>>>
>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> The jdk-14+18 based v2.07 version of the patch has been thru
>>>>>>>>> Mach5 tier[1-8]
>>>>>>>>> testing on Oracle's usual set of platforms. It has also been
>>>>>>>>> through my usual
>>>>>>>>> set of stress testing on Linux-X64, macOSX and Solaris-X64
>>>>>>>>> with the addition
>>>>>>>>> of Robbin's "MoCrazy 1024" test running in parallel with the
>>>>>>>>> other tests in
>>>>>>>>> my lab.
>>>>>>>>>
>>>>>>>>> The jdk-14+19 based v2.07 version of the patch has been thru
>>>>>>>>> Mach5 tier[1-3]
>>>>>>>>> test on Oracle's usual set of platforms. Mach5 tier[4-8] are
>>>>>>>>> in process.
>>>>>>>>>
>>>>>>>>> I did another round of SPECjbb2015 testing in Oracle's Aurora
>>>>>>>>> Performance lab
>>>>>>>>> using using their tuned SPECjbb2015 Linux-X64 G1 configs:
>>>>>>>>>
>>>>>>>>> - "base" is jdk-14+18
>>>>>>>>> - "v2.07" is the latest version and includes C2
>>>>>>>>> inc_om_ref_count() support
>>>>>>>>> on LP64 X64 and the new
>>>>>>>>> HandshakeAfterDeflateIdleMonitors option
>>>>>>>>> - "off" is with -XX:-AsyncDeflateIdleMonitors specified
>>>>>>>>> - "handshake" is with
>>>>>>>>> -XX:+HandshakeAfterDeflateIdleMonitors specified
>>>>>>>>>
>>>>>>>>> hbIR hbIR
>>>>>>>>> (max attempted) (settled) max-jOPS critical-jOPS runtime
>>>>>>>>> --------------- --------- -------- ------------- -------
>>>>>>>>> 34282.00 30635.90 28831.30 20969.20 3841.30 base
>>>>>>>>> 34282.00 30973.00 29345.80 21025.20 3964.10 v2.07
>>>>>>>>> 34282.00 31105.60 29174.30 21074.00 3931.30
>>>>>>>>> v2.07_handshake
>>>>>>>>> 34282.00 30789.70 27151.60 19839.10 3850.20
>>>>>>>>> v2.07_off
>>>>>>>>>
>>>>>>>>> - The Aurora Perf comparison tool reports:
>>>>>>>>>
>>>>>>>>> Comparison max-jOPS critical-jOPS
>>>>>>>>> ---------------------- --------------------
>>>>>>>>> --------------------
>>>>>>>>> base vs 2.07 +1.78% (s, p=0.000) +0.27%
>>>>>>>>> (ns, p=0.790)
>>>>>>>>> base vs 2.07_handshake +1.19% (s, p=0.007) +0.58%
>>>>>>>>> (ns, p=0.536)
>>>>>>>>> base vs 2.07_off -5.83% (ns, p=0.394) -5.39%
>>>>>>>>> (ns, p=0.347)
>>>>>>>>>
>>>>>>>>> (s) - significant (ns) - not-significant
>>>>>>>>>
>>>>>>>>> - For historical comparison, the Aurora Perf comparision tool
>>>>>>>>> reported for v2.06 with a baseline of jdk-13+31:
>>>>>>>>>
>>>>>>>>> Comparison max-jOPS critical-jOPS
>>>>>>>>> ---------------------- --------------------
>>>>>>>>> --------------------
>>>>>>>>> base vs 2.06 -0.32% (ns, p=0.345) +0.71%
>>>>>>>>> (ns, p=0.646)
>>>>>>>>> base vs 2.06_off +0.49% (ns, p=0.292) -1.21%
>>>>>>>>> (ns, p=0.481)
>>>>>>>>>
>>>>>>>>> (s) - significant (ns) - not-significant
>>>>>>>>>
>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 8/28/19 5:02 PM, Daniel D. Daugherty wrote:
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> The Async Monitor Deflation project has rebased to JDK14 so
>>>>>>>>>> it's time
>>>>>>>>>> for our first code review in that new context!!
>>>>>>>>>>
>>>>>>>>>> I've been focused on changing the monitor list management
>>>>>>>>>> code to be
>>>>>>>>>> lock-free in order to make SPECjbb2015 happier. Of course
>>>>>>>>>> with a change
>>>>>>>>>> like that, it takes a while to chase down all the new and
>>>>>>>>>> wonderful
>>>>>>>>>> races. At this point, I have the code back to the same
>>>>>>>>>> stability that
>>>>>>>>>> I had with CR5/v2.05/8-for-jdk13.
>>>>>>>>>>
>>>>>>>>>> To lay the ground work for this round of review, I pushed the
>>>>>>>>>> following
>>>>>>>>>> two fixes to jdk/jdk earlier today:
>>>>>>>>>>
>>>>>>>>>> JDK-8230184 rename, whitespace, indent and comments
>>>>>>>>>> changes in preparation
>>>>>>>>>> for lock free Monitor lists
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230184
>>>>>>>>>>
>>>>>>>>>> JDK-8230317 serviceability/sa/ClhsdbPrintStatics.java
>>>>>>>>>> fails after 8230184
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230317
>>>>>>>>>>
>>>>>>>>>> I have attached the list of fixes from CR5 to CR6 instead of
>>>>>>>>>> putting
>>>>>>>>>> in the main body of this email.
>>>>>>>>>>
>>>>>>>>>> Main bug URL:
>>>>>>>>>>
>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>
>>>>>>>>>> The project is currently baselined on jdk-14+11 plus the
>>>>>>>>>> fixes for
>>>>>>>>>> JDK-8230184 and JDK-8230317.
>>>>>>>>>>
>>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>>> all of the
>>>>>>>>>> current Async Monitor Deflation code in one go (v2.06 full):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.full/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The primary focus of this review cycle is on the lock-free
>>>>>>>>>> Monitor List
>>>>>>>>>> management changes so here's a webrev for just that patch
>>>>>>>>>> (v2.06c):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06c.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The secondary focus of this review cycle is on the bug fixes
>>>>>>>>>> that have
>>>>>>>>>> been made since CR5/v2.05/8-for-jdk13 so here's a webrev for
>>>>>>>>>> just that
>>>>>>>>>> patch (v2.06b):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06b.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The third and final bucket for this review cycle is the
>>>>>>>>>> rename, whitespace,
>>>>>>>>>> indent and comments changes made in preparation for lock free
>>>>>>>>>> Monitor list
>>>>>>>>>> management. Almost all of that was extracted into JDK-8230184
>>>>>>>>>> for the
>>>>>>>>>> baseline so this bucket now has just a few comment changes
>>>>>>>>>> relative to
>>>>>>>>>> CR5/v2.05/8-for-jdk13. Here's a webrev for the remainder
>>>>>>>>>> (v2.06a):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06a.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>>>> last review
>>>>>>>>>> cycle so here's a webrev for that (v2.06 inc):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Last, but not least, some folks might want to see the code
>>>>>>>>>> before the
>>>>>>>>>> addition of lock-free Monitor List management so here's a
>>>>>>>>>> webrev for
>>>>>>>>>> that (v2.00 -> v2.05):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.05.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The OpenJDK wiki will need minor updates to match the CR6
>>>>>>>>>> changes:
>>>>>>>>>>
>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> but that should only be changes to describe per-thread list
>>>>>>>>>> async monitor
>>>>>>>>>> deflation being done by the ServiceThread.
>>>>>>>>>>
>>>>>>>>>> (I did update the OpenJDK wiki for the CR5 changes back on
>>>>>>>>>> 2019.08.14)
>>>>>>>>>>
>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>> testing on
>>>>>>>>>> Oracle's usual set of platforms. It has also been through my
>>>>>>>>>> usual set
>>>>>>>>>> of stress testing on Linux-X64, macOSX and Solaris-X64.
>>>>>>>>>>
>>>>>>>>>> I did a bunch of SPECjbb2015 testing in Oracle's Aurora
>>>>>>>>>> Performance lab
>>>>>>>>>> using using their tuned SPECjbb2015 Linux-X64 G1 configs.
>>>>>>>>>> This was using
>>>>>>>>>> this patch baselined on jdk-13+31 (for stability):
>>>>>>>>>>
>>>>>>>>>> hbIR hbIR
>>>>>>>>>> (max attempted) (settled) max-jOPS critical-jOPS runtime
>>>>>>>>>> --------------- --------- -------- ------------- -------
>>>>>>>>>> 34282.00 28837.20 27905.20 19817.40 3658.10 base
>>>>>>>>>> 34965.70 29798.80 27814.90 19959.00 3514.60
>>>>>>>>>> v2.06d
>>>>>>>>>> 34282.00 29100.70 28042.50 19577.00 3701.90
>>>>>>>>>> v2.06d_off
>>>>>>>>>> 34282.00 29218.50 27562.80 19397.30 3657.60
>>>>>>>>>> v2.06d_ocache
>>>>>>>>>> 34965.70 29838.30 26512.40 19170.60 3569.90 v2.05
>>>>>>>>>> 34282.00 28926.10 27734.00 19835.10 3588.40
>>>>>>>>>> v2.05_off
>>>>>>>>>>
>>>>>>>>>> The "off" configs are with -XX:-AsyncDeflateIdleMonitors
>>>>>>>>>> specified and
>>>>>>>>>> the "ocache" config is with 128 byte cache line sizes instead
>>>>>>>>>> of 64 byte
>>>>>>>>>> cache lines sizes. "v2.06d" is the last set of changes that I
>>>>>>>>>> made before
>>>>>>>>>> those changes were distributed into the "v2.06a", "v2.06b"
>>>>>>>>>> and "v2.06c"
>>>>>>>>>> buckets for this review recycle.
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 7/11/19 3:49 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>> Greetings,
>>>>>>>>>>>
>>>>>>>>>>> I've been focused on chasing down and fixing the rare test
>>>>>>>>>>> failures
>>>>>>>>>>> that only pop up rarely. So this round is primarily fixes
>>>>>>>>>>> for races
>>>>>>>>>>> with a few additional fixes that came from Karen's review of
>>>>>>>>>>> CR4.
>>>>>>>>>>> Thanks Karen!
>>>>>>>>>>>
>>>>>>>>>>> I have attached the list of fixes from CR4 to CR5 instead of
>>>>>>>>>>> putting
>>>>>>>>>>> in the main body of this email.
>>>>>>>>>>>
>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>
>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>
>>>>>>>>>>> The project is currently baselined on jdk-13+29. This will
>>>>>>>>>>> likely be
>>>>>>>>>>> the last JDK13 baseline for this project and I'll roll to
>>>>>>>>>>> the JDK14
>>>>>>>>>>> (jdk/jdk) repo soon...
>>>>>>>>>>>
>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.full/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.inc/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> I have not yet checked the OpenJDK wiki to see if it needs
>>>>>>>>>>> any updates
>>>>>>>>>>> to match the CR5 changes:
>>>>>>>>>>>
>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> (I did update the OpenJDK wiki for the CR4 changes back on
>>>>>>>>>>> 2019.06.26)
>>>>>>>>>>>
>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-3]
>>>>>>>>>>> testing on
>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[4-6] is running
>>>>>>>>>>> now and
>>>>>>>>>>> Mach5 tier[78] will follow. I'll kick off the usual stress
>>>>>>>>>>> testing
>>>>>>>>>>> on Linux-X64, macOSX and Solaris-X64 as those machines
>>>>>>>>>>> become available.
>>>>>>>>>>> Since I haven't made any performance changes in this round,
>>>>>>>>>>> I'll only
>>>>>>>>>>> be running SPECjbb2015 to gather the latest monitorinflation
>>>>>>>>>>> logs.
>>>>>>>>>>>
>>>>>>>>>>> Next up:
>>>>>>>>>>>
>>>>>>>>>>> - We're still seeing 4-5% lower performance with SPECjbb2015 on
>>>>>>>>>>> Linux-X64 and we've determined that some of that comes from
>>>>>>>>>>> contention on the gListLock. So I'm going to investigate
>>>>>>>>>>> removing
>>>>>>>>>>> the gListLock. Yes, another lock free set of changes is
>>>>>>>>>>> coming!
>>>>>>>>>>> - Of course, going lock free often causes new races and new
>>>>>>>>>>> failures
>>>>>>>>>>> so that's a good reason for make those changes isolated in
>>>>>>>>>>> their
>>>>>>>>>>> own round (and not holding up CR5/v2.05/8-for-jdk13 anymore).
>>>>>>>>>>> - I finally have a potential fix for the Win* failure with
>>>>>>>>>>> gc/g1/humongousObjects/TestHumongousClassLoader.java
>>>>>>>>>>> but I haven't run it through Mach5 yet so it'll be in the
>>>>>>>>>>> next round.
>>>>>>>>>>> - Some RTM tests were recently re-enabled in Mach5 and I'm
>>>>>>>>>>> seeing some
>>>>>>>>>>> monitor related failures there. I suspect that I need to
>>>>>>>>>>> go take a
>>>>>>>>>>> look at the C2 RTM macro assembler code and look for
>>>>>>>>>>> things that might
>>>>>>>>>>> conflict if Async Monitor Deflation. If you're interested
>>>>>>>>>>> in that kind
>>>>>>>>>>> of issue, then see the macroAssembler_x86.cpp sanity check
>>>>>>>>>>> that I
>>>>>>>>>>> added in this round!
>>>>>>>>>>>
>>>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 5/26/19 8:30 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>
>>>>>>>>>>>> I have a fix for an issue that came up during performance
>>>>>>>>>>>> testing.
>>>>>>>>>>>> Many thanks to Robbin for diagnosing the issue in his
>>>>>>>>>>>> SPECjbb2015
>>>>>>>>>>>> experiments.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the list of changes from CR3 to CR4. The list is a bit
>>>>>>>>>>>> verbose due to the complexity of the issue, but the changes
>>>>>>>>>>>> themselves are not that big.
>>>>>>>>>>>>
>>>>>>>>>>>> Functional:
>>>>>>>>>>>> - Change SafepointSynchronize::is_cleanup_needed() from
>>>>>>>>>>>> calling
>>>>>>>>>>>> ObjectSynchronizer::is_cleanup_needed() to calling
>>>>>>>>>>>> ObjectSynchronizer::is_safepoint_deflation_needed():
>>>>>>>>>>>> - is_safepoint_deflation_needed() returns the result of
>>>>>>>>>>>> monitors_used_above_threshold() for safepoint based
>>>>>>>>>>>> monitor deflation (!AsyncDeflateIdleMonitors).
>>>>>>>>>>>> - For AsyncDeflateIdleMonitors, it only returns true if
>>>>>>>>>>>> there is a special deflation request, e.g., System.gc()
>>>>>>>>>>>> - This solves a bug where there are a bunch of Cleanup
>>>>>>>>>>>> safepoints that simply request async deflation which
>>>>>>>>>>>> keeps the async JavaThreads from making progress on
>>>>>>>>>>>> their async deflation work.
>>>>>>>>>>>> - Add AsyncDeflationInterval diagnostic option. Description:
>>>>>>>>>>>> Async deflate idle monitors every so many
>>>>>>>>>>>> milliseconds when
>>>>>>>>>>>> MonitorUsedDeflationThreshold is exceeded (0 is off).
>>>>>>>>>>>> - Replace
>>>>>>>>>>>> ObjectSynchronizer::gOmShouldDeflateIdleMonitors() with
>>>>>>>>>>>> ObjectSynchronizer::is_async_deflation_needed():
>>>>>>>>>>>> - is_async_deflation_needed() returns true when
>>>>>>>>>>>> is_async_cleanup_requested() is true or when
>>>>>>>>>>>> monitors_used_above_threshold() is true (but no more
>>>>>>>>>>>> often than
>>>>>>>>>>>> AsyncDeflationInterval).
>>>>>>>>>>>> - if AsyncDeflateIdleMonitors Service_lock->wait() now
>>>>>>>>>>>> waits for
>>>>>>>>>>>> at most GuaranteedSafepointInterval millis:
>>>>>>>>>>>> - This allows is_async_deflation_needed() to be
>>>>>>>>>>>> checked at
>>>>>>>>>>>> the same interval as GuaranteedSafepointInterval.
>>>>>>>>>>>> (default is 1000 millis/1 second)
>>>>>>>>>>>> - Once is_async_deflation_needed() has returned true, it
>>>>>>>>>>>> generally cannot return true for
>>>>>>>>>>>> AsyncDeflationInterval.
>>>>>>>>>>>> This is to prevent async deflation from swamping the
>>>>>>>>>>>> ServiceThread.
>>>>>>>>>>>> - The ServiceThread still handles async deflation of the
>>>>>>>>>>>> global
>>>>>>>>>>>> in-use list and now it also marks JavaThreads for async
>>>>>>>>>>>> deflation
>>>>>>>>>>>> of their in-use lists.
>>>>>>>>>>>> - The ServiceThread will check for async deflation work
>>>>>>>>>>>> every
>>>>>>>>>>>> GuaranteedSafepointInterval.
>>>>>>>>>>>> - A safepoint can still cause the ServiceThread to
>>>>>>>>>>>> check for
>>>>>>>>>>>> async deflation work via is_async_deflation_requested.
>>>>>>>>>>>> - Refactor code from
>>>>>>>>>>>> ObjectSynchronizer::is_cleanup_needed() into
>>>>>>>>>>>> monitors_used_above_threshold() and remove
>>>>>>>>>>>> is_cleanup_needed().
>>>>>>>>>>>> - In addition to System.gc(), the VM_Exit VM op and the
>>>>>>>>>>>> final
>>>>>>>>>>>> VMThread safepoint now set the
>>>>>>>>>>>> is_special_deflation_requested
>>>>>>>>>>>> flag to reduce the in-use monitor population that is
>>>>>>>>>>>> reported by
>>>>>>>>>>>> ObjectSynchronizer::log_in_use_monitor_details() at VM exit.
>>>>>>>>>>>>
>>>>>>>>>>>> Test update:
>>>>>>>>>>>> - test/hotspot/gtest/oops/test_markOop.cpp is updated to
>>>>>>>>>>>> work with
>>>>>>>>>>>> AsyncDeflateIdleMonitors.
>>>>>>>>>>>>
>>>>>>>>>>>> Collateral:
>>>>>>>>>>>> - Add/clarify/update some logging messages.
>>>>>>>>>>>>
>>>>>>>>>>>> Cleanup:
>>>>>>>>>>>> - Updated comments based on Karen's code review.
>>>>>>>>>>>> - Change 'special cleanup' -> 'special deflation' and
>>>>>>>>>>>> 'async cleanup' -> 'async deflation'.
>>>>>>>>>>>> - comment and function name changes
>>>>>>>>>>>> - Clarify MonitorUsedDeflationThreshold description;
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>
>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>
>>>>>>>>>>>> The project is currently baselined on jdk-13+22.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.full/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.inc/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> I have not updated the OpenJDK wiki to reflect the CR4
>>>>>>>>>>>> changes:
>>>>>>>>>>>>
>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The wiki doesn't say a whole lot about the async deflation
>>>>>>>>>>>> invocation
>>>>>>>>>>>> mechanism so I have to figure out how to add that content.
>>>>>>>>>>>>
>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>> testing on
>>>>>>>>>>>> Oracle's usual set of platforms. My Solaris-X64 stress kit
>>>>>>>>>>>> run is
>>>>>>>>>>>> running now. Kitchensink8H on product, fastdebug, and
>>>>>>>>>>>> slowdebug bits
>>>>>>>>>>>> are running on Linux-X64, MacOSX and Solaris-X64. I still
>>>>>>>>>>>> have to run
>>>>>>>>>>>> my stress kit on Linux-X64. I still have to run the
>>>>>>>>>>>> SPECjbb2015
>>>>>>>>>>>> baseline and CR4 runs on Linux-X64, MacOSX and Solaris-X64.
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>> On 5/6/19 11:52 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>
>>>>>>>>>>>>> I had some discussions with Karen about a race that was in
>>>>>>>>>>>>> the
>>>>>>>>>>>>> ObjectMonitor::enter() code in CR2/v2.02/5-for-jdk13. This
>>>>>>>>>>>>> race was
>>>>>>>>>>>>> theoretical and I had no test failures due to it. The fix
>>>>>>>>>>>>> is pretty
>>>>>>>>>>>>> simple: remove the special case code for async deflation
>>>>>>>>>>>>> in the
>>>>>>>>>>>>> ObjectMonitor::enter() function and rely solely on the
>>>>>>>>>>>>> ref_count
>>>>>>>>>>>>> for ObjectMonitor::enter() protection.
>>>>>>>>>>>>>
>>>>>>>>>>>>> During those discussions Karen also floated the idea of
>>>>>>>>>>>>> using the
>>>>>>>>>>>>> ref_count field instead of the contentions field for the
>>>>>>>>>>>>> Async
>>>>>>>>>>>>> Monitor Deflation protocol. I decided to go ahead and code
>>>>>>>>>>>>> up that
>>>>>>>>>>>>> change and I have run it through the usual stress and
>>>>>>>>>>>>> Mach5 testing
>>>>>>>>>>>>> with no issues. It's also known as v2.03 (for those for
>>>>>>>>>>>>> with the
>>>>>>>>>>>>> patches) and as webrev/6-for-jdk13 (for those with webrev
>>>>>>>>>>>>> URLs).
>>>>>>>>>>>>> Sorry for all the names...
>>>>>>>>>>>>>
>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>
>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>
>>>>>>>>>>>>> The project is currently baselined on jdk-13+18.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.full/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have also updated the OpenJDK wiki to reflect the CR3
>>>>>>>>>>>>> changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>>> testing on
>>>>>>>>>>>>> Oracle's usual set of platforms. My Solaris-X64 stress kit
>>>>>>>>>>>>> run had
>>>>>>>>>>>>> no issues. Kitchensink8H on product, fastdebug, and
>>>>>>>>>>>>> slowdebug bits
>>>>>>>>>>>>> had no failures on Linux-X64; MacOSX fastdebug and
>>>>>>>>>>>>> slowdebug and
>>>>>>>>>>>>> Solaris-X64 release had the usual "Too large time diff"
>>>>>>>>>>>>> complaints.
>>>>>>>>>>>>> 12 hour Inflate2 runs on product, fastdebug and slowdebug
>>>>>>>>>>>>> bits on
>>>>>>>>>>>>> Linux-X64, MacOSX and Solaris-X64 had no failures. My
>>>>>>>>>>>>> Linux-X64
>>>>>>>>>>>>> stress kit is running right now.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've done the SPECjbb2015 baseline and CR3 runs. I need to
>>>>>>>>>>>>> gather
>>>>>>>>>>>>> the results and analyze them.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 4/25/19 12:38 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have a small but important bug fix for the Async
>>>>>>>>>>>>>> Monitor Deflation
>>>>>>>>>>>>>> project ready to go. It's also known as v2.02 (for those
>>>>>>>>>>>>>> for with the
>>>>>>>>>>>>>> patches) and as webrev/5-for-jdk13 (for those with webrev
>>>>>>>>>>>>>> URLs). Sorry
>>>>>>>>>>>>>> for all the names...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK-8222295 was pushed to jdk/jdk two days ago so that
>>>>>>>>>>>>>> baseline patch
>>>>>>>>>>>>>> is out of our hair.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The project is currently baselined on jdk-13+17.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.full/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the incremental webrev URL (JDK-8153224):
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.inc/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I still have to update the OpenJDK wiki to reflect the
>>>>>>>>>>>>>> CR2 changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-6]
>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[7-8] is
>>>>>>>>>>>>>> running now.
>>>>>>>>>>>>>> My stress kit is running on Solaris-X64 now.
>>>>>>>>>>>>>> Kitchensink8H is running
>>>>>>>>>>>>>> now on product, fastdebug, and slowdebug bits on
>>>>>>>>>>>>>> Linux-X64, MacOSX
>>>>>>>>>>>>>> and Solaris-X64. 12 hour Inflate2 runs are running now on
>>>>>>>>>>>>>> product,
>>>>>>>>>>>>>> fastdebug and slowdebug bits on Linux-X64, MacOSX and
>>>>>>>>>>>>>> Solaris-X64.
>>>>>>>>>>>>>> I'll start my my stress kit on Linux-X64 sometime on
>>>>>>>>>>>>>> Sunday (after
>>>>>>>>>>>>>> my jdk-13+18 stress run is done).
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I'll do SPECjbb2015 baseline and CR2 runs after all the
>>>>>>>>>>>>>> stress
>>>>>>>>>>>>>> testing is done.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 4/19/19 11:58 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I finally have CR1 for the Async Monitor Deflation
>>>>>>>>>>>>>>> project ready to
>>>>>>>>>>>>>>> go. It's also known as v2.01 (for those for with the
>>>>>>>>>>>>>>> patches) and as
>>>>>>>>>>>>>>> webrev/4-for-jdk13 (for those with webrev URLs). Sorry
>>>>>>>>>>>>>>> for all the
>>>>>>>>>>>>>>> names...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Baseline bug fixes URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JDK-8222295 more baseline cleanups from Async
>>>>>>>>>>>>>>> Monitor Deflation project
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222295
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The project is currently baselined on jdk-13+15.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the webrev for the latest baseline changes
>>>>>>>>>>>>>>> (JDK-8222295):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.8222295
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the full webrev URL (JDK-8153224 only):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.full/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the incremental webrev URL (JDK-8153224):
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.inc/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> So I'm looking for reviews for both JDK-8222295 and the
>>>>>>>>>>>>>>> latest version
>>>>>>>>>>>>>>> of JDK-8153224...
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I still have to update the OpenJDK wiki to reflect the
>>>>>>>>>>>>>>> CR changes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-3]
>>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[4-6] is
>>>>>>>>>>>>>>> running now and
>>>>>>>>>>>>>>> Mach5 tier[78] will be run later today. My stress kit on
>>>>>>>>>>>>>>> Solaris-X64
>>>>>>>>>>>>>>> is running now. Linux-X64 stress testing will start on
>>>>>>>>>>>>>>> Sunday. I'm
>>>>>>>>>>>>>>> planning to do Kitchensink runs, SPECjbb2015 runs and my
>>>>>>>>>>>>>>> monitor
>>>>>>>>>>>>>>> inflation stress tests on Linux-X64, MacOSX and
>>>>>>>>>>>>>>> Solaris-X64.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 3/24/19 9:57 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Welcome to the OpenJDK review thread for my port of
>>>>>>>>>>>>>>>> Carsten's work on:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's a link to the OpenJDK wiki that describes my port:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the webrev URL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/3-for-jdk13/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's a link to Carsten's original webrev:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~cvarming/monitor_deflate_conc/0/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Earlier versions of this patch have been through
>>>>>>>>>>>>>>>> several rounds of
>>>>>>>>>>>>>>>> preliminary review. Many thanks to Carsten, Coleen,
>>>>>>>>>>>>>>>> Robbin, and
>>>>>>>>>>>>>>>> Roman for their preliminary code review comments. A
>>>>>>>>>>>>>>>> very special
>>>>>>>>>>>>>>>> thanks to Robbin and Roman for building and testing the
>>>>>>>>>>>>>>>> patch in
>>>>>>>>>>>>>>>> their own environments (including specJBB2015).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>>>> Oracle's usual set of platforms. Earlier versions have
>>>>>>>>>>>>>>>> been run
>>>>>>>>>>>>>>>> through my stress kit on my Linux-X64 and Solaris-X64
>>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>> (product, fastdebug, slowdebug).Earlier versions have
>>>>>>>>>>>>>>>> run Kitchensink
>>>>>>>>>>>>>>>> for 12 hours on MacOSX, Linux-X64 and Solaris-X64
>>>>>>>>>>>>>>>> (product, fastdebug
>>>>>>>>>>>>>>>> and slowdebug). Earlier versions have run my monitor
>>>>>>>>>>>>>>>> inflation stress
>>>>>>>>>>>>>>>> tests for 12 hours on MacOSX, Linux-X64 and Solaris-X64
>>>>>>>>>>>>>>>> (product,
>>>>>>>>>>>>>>>> fastdebug and slowdebug).
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> All of the testing done on earlier versions will be
>>>>>>>>>>>>>>>> redone on the
>>>>>>>>>>>>>>>> latest version of the patch.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> P.S.
>>>>>>>>>>>>>>>> One subtest in
>>>>>>>>>>>>>>>> gc/g1/humongousObjects/TestHumongousClassLoader.java
>>>>>>>>>>>>>>>> is currently failing in -Xcomp mode on Win* only. I've
>>>>>>>>>>>>>>>> been trying
>>>>>>>>>>>>>>>> to characterize/analyze this failure for more than a
>>>>>>>>>>>>>>>> week now. At
>>>>>>>>>>>>>>>> this point I'm convinced that Async Monitor Deflation
>>>>>>>>>>>>>>>> is aggravating
>>>>>>>>>>>>>>>> an existing bug. However, I plan to have a better
>>>>>>>>>>>>>>>> handle on that
>>>>>>>>>>>>>>>> failure before these bits are pushed to the jdk/jdk repo.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>
More information about the hotspot-runtime-dev
mailing list