RFR(L) 8153224 Monitor deflation prolong safepoints (CR12/v2.12/15-for-jdk15)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Wed May 20 01:05:24 UTC 2020
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