RFR(L) 8153224 Monitor deflation prolong safepoints (CR12/v2.12/15-for-jdk15)
Erik Österlund
erik.osterlund at oracle.com
Wed May 20 17:10:16 UTC 2020
On 2020-05-20 18:39, Daniel D. Daugherty wrote:
> You're talking about additional fencing for nMCA machines and IRIW
> considerations right?
>
> You're not talking about additional fencing for TSO?
Correct. TSO only ever needs storeload(), all other fencing is for
non-TSO machines.
/Erik
> Please clarify.
>
> Dan
>
>
> On 5/20/20 12:13 PM, Erik Österlund wrote:
>> Hi Dan,
>>
>> I’m okay with your solution without linearization points. But I
>> honestly haven’t figured out yet what fencing it needs, after
>> thinking about it for half a day. It is very complicated. Let’s hope
>> we figure that out early next week, if you want to go down that route.
>>
>> Thanks,
>> /Erik
>>
>>> On 20 May 2020, at 18:01, Daniel D. Daugherty
>>> <daniel.daugherty at oracle.com> wrote:
>>>
>>> Hi Erik,
>>>
>>>> On 5/20/20 7:28 AM, Erik Österlund wrote:
>>>> Hi Dan,
>>>>
>>>> I'm glad we are in agreement about the problem domain. I will focus
>>>> my reply on the solution domain.
>>>>
>>>> On 2020-05-20 03:05, Daniel D. Daugherty wrote:
>>>>>> 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().
>>>> First of all, a linearization point is when a single atomic write
>>>> logically commits a whole operation, such that all concurrent
>>>> threads that observe this write, will know that the operation has
>>>> logically been committed.
>>> Okay thanks for the clarification. Async monitor deflation does not
>>> have
>>> a linearization point by that definition.
>>>
>>>
>>>> A correct concurrent algorithm may or may not have a linearization
>>>> point. What you are proposing does not have a linearization point,
>>>> while the change I proposed did have a linearization point, (the
>>>> write of _contentions to -max_jint). In my proposed changes, anyone
>>>> observing that store making _contentions < 0 knows that deflation
>>>> has been logically committed. In what you are proposing it's more
>>>> of a dance where you check for the owner, check for contentions,
>>>> and then check owners again, assuming a total order, and reasoning
>>>> about what could happen between these events.
>>> That's accurate and the async deflation protocol has been this way from
>>> the very beginning. The three part check is key and always has been.
>>>
>>>
>>>> That doesn't automatically mean that it's bad to not have a
>>>> linearization point. I'd just like to point out that in what you
>>>> are proposing, there is indeed no linearization point for deflating
>>>> the monitor.
>>> We're in agreement. This review thread is the first time I've heard the
>>> phrase "linearization point" and I won't use it again w.r.t. the three
>>> part async deflation protocol.
>>>
>>>
>>>> No individual write publishes that now deflation is a fact. We can
>>>> live with that though, but I find it less intuitive to reason
>>>> about, and would prefer to have a linearization point.
>>> I'm glad you can live with that. I understand your preference, but
>>> that's
>>> not what we have today and that's not a change that I would like to vet
>>> at this point in the Async Monitor Deflation project.
>>>
>>>
>>>>> 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!).
>>>> I agree that what you propose will probably fix the issue on TSO
>>>> machines.
>>> I'll accept the grudging, half-hearted agreement. Thank you.
>>>
>>>
>>> Most of what follows is about non-TSO machines and I don't think
>>> we're ready
>>> to do that discussion so I'm going to hold off on commenting for now.
>>>
>>>> But naturally it won't on non-TSO machines, which is where things
>>>> get messy. In fact the reason I did not propose the same solution
>>>> is that it's quite tricky to reason about what fencing is required.
>>>> In this case, the _owner and _contentions are written by different
>>>> threads, but we need to observe them in a total order, requiring at
>>>> least a loadload(). That also makes it seem like an IRIW scenario,
>>>> but it's not that "simple". The threads that writes _owner and
>>>> _contentions know about each other through causality. Causality is
>>>> when a write on one thread is read on a second thread, before a
>>>> write on that thread, which is observed on a third thread. The
>>>> third thread is guaranteed to be able to subsequently observe the
>>>> write from the first thread if it observed the write of the second
>>>> thread, iff it supports causality of accesses.
>>>>
>>>> Managing to flip _contentions to negative implies knowledge about
>>>> the subsequent counter decrement from a JT that aborted the
>>>> deflation. Therefore, if a third observer thread can read the
>>>> negative counter, their memory should be sufficiently up to date to
>>>> guarantee the subsequent load of the owner can't have a value
>>>> written before the counter transitioned to negative. This works
>>>> with causality rules.
>>>>
>>>> Unfortunately, causality is not ensured on PPC. So unless there is
>>>> more to it and causality is otherwise ensured with fencing in the
>>>> causality chain, there is an IRIW situation again. The causality
>>>> link we rely on is only ensured if the read that observes the
>>>> _contentions == 0 value written by the aborting java thread, and
>>>> the write that makes it negative are interleaved with a full fence.
>>>> This causality link is inside of the guts of the CAS that flips
>>>> contentions from 0 to negative. The implementation of the CAS on
>>>> PPC in pseudo code is:
>>>>
>>>> fence()
>>>> for (;;)
>>>> temp = load_link(addr);
>>>> if (temp != expected_value) return false;
>>>> if (store_conditional(addr, new_value)) {
>>>> break;
>>>> }
>>>> fence()
>>>> return true;
>>>>
>>>> This load_link and store_conditional is the weak link in our
>>>> causality chain. There is no full fence between them, and that
>>>> unfortunately means that causality is not ensured in our algorithm.
>>>> And because the causality chain is not respected, we find ourselves
>>>> in yet another IRIW situation, but this time even more tricky to
>>>> reason about, due to its existence being conditional on a lack of
>>>> causality, which is very implicit and tricky to see here and reason
>>>> about.
>>>>
>>>> Comparision of your approach to my approch:
>>>>
>>>> 1) We get into even more tricky fencing decision. It's an IRIW
>>>> situation iff causality is not ensured by the HW memory model,
>>>> which it is not on PPC. Not sure what to make out of that, and how
>>>> easy others will find it to reason about the correctness of the
>>>> algorithm. In my solution, the fencing is straight forward.
>>>> 2) There is still no intuitive linearization point. We are
>>>> reasoning about reading two atomic variables in different orders,
>>>> trying to figure out what has happened. Neither of the two atomic
>>>> variables transition monotonically. It is rather unintuitive, and
>>>> could be more intuitive like my solution (with a linearization
>>>> point). By making the key transition of the _contentions counter to
>>>> negative a monotonic transition that will never flip back, it
>>>> becomes easier to reason about correctness. That becomes the only
>>>> transition that observers need to care about, and it can't be
>>>> undone. I definitely find that more intuitive and simple to reason
>>>> about, compared to reasoning about all the ways that the two
>>>> non-monotonic variables can have their state flip back and forth in
>>>> different interleavings with other threads, in different skewed
>>>> local versions of different total orders of events.
>>>> 3) The is_async_deflated() function becomes more heavy weight,
>>>> especially on nMCA machines. It could be a single load, as it is in
>>>> my solution.
>>>>
>>>> I have included a patch so that you can see what my solution might
>>>> look like, for your consideration:
>>>>
>>>> http://cr.openjdk.java.net/~eosterlund/monitors/webrev.00/
>>>>
>>>> Do you still find your solution easier to reason about?
>>> As always, thanks for the webrev!
>>>
>>> I've lived with this three part async deflation algorithm for more than
>>> a year so saying that I know it like the back of my hand is not an
>>> exaggeration. Your proposed solution, nMCA machines and IRIW
>>> considerations
>>> are all new to me. So no I don't find your proposed solution easier to
>>> reason about. There is much to think about and discuss as evidenced
>>> by the
>>> 16 off list emails (as of this AM) on the "MCA vs nMCA" sidebar that we
>>> have going.
>>>
>>> For now, it looks like we have a solution that works for TSO which
>>> is what
>>> my revised goal is for this week's discussion. I don't have my head
>>> wrapped
>>> around the nMCA machine or IRIW considerations yet so I'm not ready to
>>> change directions yet.
>>>
>>>
>>>>>> 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.
>>>> Okay.
>>>>
>>>> Thanks,
>>>> /Erik
>>> Thanks again.
>>>
>>> Dan
>>>
>>>
>>>>>> 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