RFR(L) 8153224 Monitor deflation prolong safepoints (CR9/v2.09/12-for-jdk14)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Thu Feb 20 13:54:32 UTC 2020
Hi Erik,
Thanks for the review!
This is just the updated webrevs for CR9/v2.09/12-for-jdk14 with the
three most recent fixes extracted (8235931, 8236035, and 8235795). So
this is really just v2.09 -> v2.09b which exists solely for comparision
with v2.09 to see what changed in the Async Monitor Deflation project
when {8235931,8236035,8235795} were extracted.
The next set of changes that we discussed are coming in v2.10.
Dan
On 2/20/20 7:58 AM, erik.osterlund at oracle.com wrote:
> Hi Dan,
>
> This looks great in general. I think we agreed to remove the
> HandshakeAfterDeflateIdleMonitors flag though,
> and instead always use handshakes (and remove all code dealing with
> -XX:-HandshakeAfterDeflateIdleMonitors).
> That is still the case, and will soon be reflected in a new webrev,
> right? Just sanity checking that we are
> on the same page.
>
> Thanks,
> /Erik
>
> On 2/4/20 3:41 PM, 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