RFR(L) 8153224 Monitor deflation prolong safepoints (CR14/v2.14/17-for-jdk15)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Fri May 29 02:08:15 UTC 2020
On 5/28/20 8:46 PM, David Holmes wrote:
> On 29/05/2020 10:00 am, Daniel D. Daugherty wrote:
>> Greetings,
>>
>> Mark R. has let me know that we do not need to use the JEP for this
>> project so I'm planning to withdraw JDK-8183909 shortly.
>>
>> I'm still hoping for a final re-review from David H. and I'm still
>> hoping
>> to hear from Carsten in this round.
>
> On my to-do pile Dan.
Thanks for the update...
> Still digesting IRIW discussions :)
Understandable.
> Hope to have it re-reviewed by Monday.
As always, I'll keep my eyes open.
Dan
>
> Thanks,
> David
>
>> The rebase to jdk-15+25 went well and those bits are being tested.
>>
>> Mach5 Tier8 testing (on the jdk-15+24 version of
>> CR14/v2.14/17-for-jdk15)
>> is still running and has a way to go...
>>
>> David H.? Carsten? Would be great to hear from you two...
>>
>> Dan
>>
>>
>>
>> On 5/28/20 10:32 AM, Daniel D. Daugherty wrote:
>>> Hi Erik and Robbin,
>>>
>>> Thanks for the re-reviews and approvals.
>>>
>>> Still waiting to hear from David H. and I'm hoping to hear from
>>> Carsten.
>>>
>>> Mach5 Tier[1-7] testing has finished and there are no related failures.
>>> Mach5 Tier8 testing is still running and has a way to go...
>>>
>>> I'm planning to rebase to last night's jdk-15+25 snapshot and do some
>>> more retesting.
>>>
>>> We're also still waiting to hear whether the JEP will be required:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8183909
>>>
>>> I have a request in to Mark Reinhold to clarify whether the JEP is
>>> needed for this project. So far no answer. I've also prepped the JEP
>>> with all the info needed for approval and it is currently in the
>>> submitted state.
>>>
>>> I suppose I could prep everything for the "hg push" and see if one
>>> of my cats will *accidentally* push return... :-)
>>>
>>> Dan
>>>
>>>
>>> On 5/28/20 3:52 AM, Robbin Ehn wrote:
>>>> On 2020-05-28 08:52, Erik Österlund wrote:
>>>>> Hi Dan,
>>>>>
>>>>> This looks great. I think this is ready to land in the JDK now.
>>>>> Quickly - press that push button before anyone finds something
>>>>> else to change!!
>>>>
>>>> +1, "done done"!
>>>>
>>>> Thanks for simplifying!
>>>>
>>>> /Robbin
>>>>
>>>>>
>>>>> Thanks,
>>>>> /Erik
>>>>>
>>>>>> On 27 May 2020, at 19:21, Daniel D. Daugherty
>>>>>> <daniel.daugherty at oracle.com> wrote:
>>>>>>
>>>>>> Greetings,
>>>>>>
>>>>>> Erik O. had an idea for changing the three part async deflation
>>>>>> protocol
>>>>>> into a two part async deflation protocol where the second part
>>>>>> (setting
>>>>>> the contentions field to -max_jint) is a linearization point.
>>>>>> I've taken
>>>>>> Erik's proposal (which was relative to CR12/v2.12/15-for-jdk15),
>>>>>> merged
>>>>>> it with CR13/v2.13/16-for-jdk15, and made a few minor tweaks.
>>>>>>
>>>>>> I have attached the change list from CR13 to CR14 and I've also
>>>>>> added a
>>>>>> link to the CR13-to-CR14-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+24.
>>>>>>
>>>>>> 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.14 full):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/17-for-jdk15+24.v2.14.full/
>>>>>>
>>>>>>
>>>>>> Some folks might want to see just what has changed since the last
>>>>>> review
>>>>>> cycle so here's a webrev for that (v2.14 inc):
>>>>>>
>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/17-for-jdk15+24.v2.14.inc/
>>>>>>
>>>>>>
>>>>>>
>>>>>> The OpenJDK wiki has been updated for v2.14.
>>>>>>
>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>
>>>>>>
>>>>>> The jdk-15+24 based v2.14 version of the patch has gone thru
>>>>>> Mach5 Tier[1-5]
>>>>>> testing with no related failures; Mach5 Tier[67] are running now
>>>>>> and so far
>>>>>> have no related failures. I'll kick off Mach5 Tier8 after the
>>>>>> other tiers
>>>>>> have finished since Mach5 is a bit busy right now.
>>>>>>
>>>>>> I'm also running my usual inflation stress testing on Linux-X64
>>>>>> and macOSX
>>>>>> and so far there are no issues.
>>>>>>
>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>> On 5/21/20 2:53 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>> response to
>>>>>>> the CR12/v2.12/15-for-jdk15 code review cycle. Thanks to David
>>>>>>> H. and
>>>>>>> Erik O. for their OpenJDK reviews in the v2.12 round!
>>>>>>>
>>>>>>> I have attached the change list from CR12 to CR13 and I've also
>>>>>>> added a
>>>>>>> link to the CR12-to-CR13-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+24.
>>>>>>>
>>>>>>> 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.13 full):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/16-for-jdk15%2b24.v2.13.full/
>>>>>>>
>>>>>>>
>>>>>>> Some folks might want to see just what has changed since the
>>>>>>> last review
>>>>>>> cycle so here's a webrev for that (v2.13 inc):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/16-for-jdk15%2b24.v2.13.inc/
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> The OpenJDK wiki is currently at v2.13 and might require minor
>>>>>>> tweaks for v2.12
>>>>>>> and v2.13. Yes, I need to make yet another crawl thru review of
>>>>>>> it...
>>>>>>>
>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>
>>>>>>>
>>>>>>> The jdk-15+24 based v2.13 version of the patch is going thru the
>>>>>>> usual
>>>>>>> Mach5 testing right now. It is also going thru my usual
>>>>>>> inflation stress
>>>>>>> testing on Linux-X64 and macOSX.
>>>>>>>
>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>> On 5/14/20 5:40 PM, 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.
>>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>> <CR13-to-CR14-changes>
>>>>>
>>>
>>
More information about the hotspot-runtime-dev
mailing list