RFR(L) 8153224 Monitor deflation prolong safepoints (CR11/v2.11/14-for-jdk15)
David Holmes
david.holmes at oracle.com
Thu May 14 05:27:30 UTC 2020
Hi Dan,
On 14/05/2020 12:44 am, Daniel D. Daugherty wrote:
> Hi Robbin,
>
> On 5/13/20 10:10 AM, Robbin Ehn wrote:
>> Hi Dan,
>>
>> Thanks for the update and rebase!
>
> No problem. Now if those rebased to jdk-15+22 bits would make it thru
> my currently running Mach5 Tier[4-6] I would be happy... Mach5 seems a
> bit overloaded yesterday and today...
>
>
>> src/hotspot/share/runtime/objectMonitor.cpp
>> I think it looks very odd when you have a method, contentions(),
>> to read _contentions, but storing is directly to _contentions in the
>> same context.
>
> Agreed. I've added these inline methods:
>
> jint contentions() const;
> + void add_max_jint_to_contentions();
> + jint cmpxchg_contentions_to_neg_max_jint();
> + void dec_contentions();
> + void inc_contentions();
That seems excessive to me. These should be trivially obvious operations
on the _contentions field and these methods obscure that somewhat to me.
Can the add/dec/inc not all be subsumed by a single add(int value)
function? And the cmpxchg function looks odd because there are no
arguments - what are you comparing it to and exchanging it with ??
Thanks,
David
-----
>
>> src/hotspot/share/runtime/synchronizer.cpp
>> + if (cur_om->is_free()) {
>> + // cur_om was deflated and the allocation state was changed
>> + // to Free while it was locked. We happened to see it just
>> + // after it was unlocked (and added to the free list).
>> + // Refetch the possibly changed next field and try again.
>> + cur_om = unmarked_next(in_use_tail);
>> + continue;
>> }
>>
>> Allocation state used be 'debug' state, e.g. it had no effect on code
>> paths. That is to say if you removed it everything still worked as
>> expected :)
>> Now you add an actual use on this state, not really liking it.
>
> Agreed. You spotted one non-debug use of is_free() and Erik spotted
> another. I've made this change to fix yours:
>
> - if (cur_om->is_free()) {
> - // cur_om was deflated and the allocation state was changed
> - // to Free while it was locked. We happened to see it just
> - // after it was unlocked (and added to the free list).
> - // Refetch the possibly changed next field and try again.
> + if (cur_om->object() == NULL) {
> + // cur_om was deflated and the object ref was cleared while it
> + // was locked. We happened to see it just after it was unlocked
> + // (and added to the free list). Refetch the possibly changed
> + // next field and try again.
>
>
>> It's seem like this is not a problem if om_flush called om_lock since
>> then it can't be moved?
>
> Yes we could use a more complicated locking protocol here and that
> would prevent the possibility of a collision with async deflation.
> However, that would add more om_lock() calls to this function and
> that would slow things down a bit. It's simpler to allow the collision
> with async deflation and recover from it.
>
> Thanks for your review! And thanks for the many other reviews that
> you've done for this project's code and the experiments with the
> code that you've done on the side.
>
> Dan
>
>
>>
>> Thanks, Robbin
>>
>> On 2020-05-11 21:23, Daniel D. Daugherty wrote:
>>> Here's the full webrev URL for the rebase to jdk-15+22 (v2.11 full):
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b22.v2.11.full/
>>>
>>>
>>> Here's the incremental webrev URL for the rebase to jdk-15+22 (v2.11
>>> inc):
>>>
>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b22.v2.11.inc/
>>>
>>>
>>>
>>> I'm running the rebase through Mach5 Tier[1-3]... 24 tasks to go...
>>> so far the
>>> only failure is known for the jdk-15+22 snapshot:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8244495
>>>
>>> Robbin, now that MonitorBound is obsolete, do you have a favorite
>>> value for
>>> -XX:MonitorUsedDeflationThreshold=NN? The default is 90 and I'm
>>> thinking of
>>> using either 25 or 50 with MoCrazy...
>>>
>>> Dan
>>>
>>>
>>>
>>> On 5/11/20 8:58 AM, Daniel D. Daugherty wrote:
>>>> Mentioned in the invite below:
>>>>
>>>> > The project is currently baselined on jdk-15+21.
>>>>
>>>> I'm planning to merge with jdk-15+22 sometime today so I'll have an
>>>> updated webrev at that point.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 5/11/20 5:37 AM, Robbin Ehn wrote:
>>>>> Hi Dan,
>>>>>
>>>>> Do you have a patch for this which applies cleanly on top of your :
>>>>> 8230940: Obsolete MonitorBound
>>>>> That is jdk/jdk ?
>>>>>
>>>>> Thanks, Robbin
>>>>>
>>>>> On 2020-05-09 02:31, Daniel D. Daugherty wrote:
>>>>>>> The OpenJDK wiki has NOT YET been updated for this round of changes:
>>>>>>>
>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>
>>>>>>
>>>>>>
>>>>>> I've finished a first pass at updating the OpenJDK wiki for v2.11.
>>>>>> I'll do a crawl through review/edit pass on Monday, but it should be
>>>>>> very close to matching v2.11.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 5/7/20 1:08 PM, Daniel D. Daugherty wrote:
>>>>>>> Greetings,
>>>>>>>
>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>> response to
>>>>>>> the CR10/v2.10/13-for-jdk15 code review cycle and DaCapo-h2 perf
>>>>>>> testing.
>>>>>>> Thanks to Erik O., Robbin and David H. for their OpenJDK reviews
>>>>>>> in the
>>>>>>> v2.10 round! Thanks to Eric C. for his help in isolating the
>>>>>>> DaCapo-h2
>>>>>>> performance regression.
>>>>>>>
>>>>>>> With the removal of ref_counting and the ObjectMonitorHandle
>>>>>>> class, the
>>>>>>> Async Monitor Deflation project is now closer to Carsten's original
>>>>>>> prototype. While ref_counting gave us ObjectMonitor* safety
>>>>>>> enforced by
>>>>>>> code, I saw a ~22.8% slow down with -XX:-AsyncDeflateIdleMonitors
>>>>>>> ("off"
>>>>>>> mode). The slow down with "on" mode -XX:+AsyncDeflateIdleMonitors
>>>>>>> is ~17%.
>>>>>>>
>>>>>>> I have attached the change list from CR10 to CR11 instead of
>>>>>>> putting it in
>>>>>>> the body of this email. I've also added a link to the
>>>>>>> CR10-to-CR11-changes
>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>
>>>>>>> Main bug URL:
>>>>>>>
>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>
>>>>>>> The project is currently baselined on jdk-15+21.
>>>>>>>
>>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>>> of the
>>>>>>> current Async Monitor Deflation code in one go (v2.11 full):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.full/
>>>>>>>
>>>>>>>
>>>>>>> Some folks might want to see just what has changed since the last
>>>>>>> review
>>>>>>> cycle so here's a webrev for that (v2.11 inc):
>>>>>>>
>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/14-for-jdk15%2b21.v2.11.inc/
>>>>>>>
>>>>>>>
>>>>>>> Because of the removal of ref_counting and the
>>>>>>> ObjectMonitorHandle class, the
>>>>>>> incremental webrev is a bit noisier than I would have preferred.
>>>>>>>
>>>>>>>
>>>>>>> The OpenJDK wiki has NOT YET been updated for this round of changes:
>>>>>>>
>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>
>>>>>>>
>>>>>>> The jdk-15+21 based v2.11 version of the patch has been thru
>>>>>>> Mach5 tier[1-6]
>>>>>>> testing on Oracle's usual set of platforms. Mach5 tier[78] are
>>>>>>> still running.
>>>>>>> I'm running the v2.11 patch through my usual set of stress
>>>>>>> testing on
>>>>>>> Linux-X64 and macOSX.
>>>>>>>
>>>>>>> I'm planning to do a SPECjbb2015, DaCapo-h2 and volano round on the
>>>>>>> CR11/v2.11/14-for-jdk15 bits.
>>>>>>>
>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> On 2/26/20 5:22 PM, Daniel D. Daugherty wrote:
>>>>>>>> Greetings,
>>>>>>>>
>>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>>> response to
>>>>>>>> the CR9/v2.09/12-for-jdk14 code review cycle. Thanks to Robbin
>>>>>>>> and Erik O.
>>>>>>>> for their comments in this round!
>>>>>>>>
>>>>>>>> With the extraction and push of {8235931,8236035,8235795} to
>>>>>>>> JDK15, the
>>>>>>>> Async Monitor Deflation code is back to "just" async deflation
>>>>>>>> changes!
>>>>>>>>
>>>>>>>> I have attached the change list from CR9 to CR10 instead of
>>>>>>>> putting it in
>>>>>>>> the body of this email. I've also added a link to the
>>>>>>>> CR9-to-CR10-changes
>>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>>
>>>>>>>> Main bug URL:
>>>>>>>>
>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>
>>>>>>>> The project is currently baselined on jdk-15+11.
>>>>>>>>
>>>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>>>> of the
>>>>>>>> current Async Monitor Deflation code in one go (v2.10 full):
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.full/
>>>>>>>>
>>>>>>>>
>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>> last review
>>>>>>>> cycle so here's a webrev for that (v2.10 inc):
>>>>>>>>
>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/13-for-jdk15+11.v2.10.inc/
>>>>>>>>
>>>>>>>>
>>>>>>>> Since we backed out the HandshakeAfterDeflateIdleMonitors option
>>>>>>>> and the
>>>>>>>> C2 ref_count changes and updated the copyright years, the "inc"
>>>>>>>> webrev has
>>>>>>>> a bit more noise in it than usual. Sorry about that!
>>>>>>>>
>>>>>>>> The OpenJDK wiki has been updated for this round of changes:
>>>>>>>>
>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>
>>>>>>>>
>>>>>>>> The jdk-15+11 based v2.10 version of the patch has been thru
>>>>>>>> Mach5 tier[1-7]
>>>>>>>> testing on Oracle's usual set of platforms. Mach5 tier8 is still
>>>>>>>> running.
>>>>>>>> I'm running the v2.10 patch through my usual set of stress
>>>>>>>> testing on
>>>>>>>> Linux-X64 and macOSX.
>>>>>>>>
>>>>>>>> I'm planning to do a SPECjbb2015 round on the
>>>>>>>> CR10/v2.20/13-for-jdk15 bits.
>>>>>>>>
>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>
>>>>>>>> Dan
>>>>>>>>
>>>>>>>>
>>>>>>>> On 2/4/20 9:41 AM, Daniel D. Daugherty wrote:
>>>>>>>>> Greetings,
>>>>>>>>>
>>>>>>>>> This project is no longer targeted to JDK14 so this is NOT an
>>>>>>>>> urgent code
>>>>>>>>> review request.
>>>>>>>>>
>>>>>>>>> I've extracted the following three fixes from the Async Monitor
>>>>>>>>> Deflation
>>>>>>>>> project code:
>>>>>>>>>
>>>>>>>>> JDK-8235931 add OM_CACHE_LINE_SIZE and use smaller size on
>>>>>>>>> SPARCv9 and X64
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235931
>>>>>>>>>
>>>>>>>>> JDK-8236035 refactor ObjectMonitor::set_owner() and _owner
>>>>>>>>> field setting
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8236035
>>>>>>>>>
>>>>>>>>> JDK-8235795 replace monitor list
>>>>>>>>> mux{Acquire,Release}(&gListLock) with spin locks
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8235795
>>>>>>>>>
>>>>>>>>> Each of these has been reviewed separately and will be pushed
>>>>>>>>> to JDK15
>>>>>>>>> in the near future (possibly by the end of this week). Of
>>>>>>>>> course, there
>>>>>>>>> were improvements during these review cycles and the purpose of
>>>>>>>>> this
>>>>>>>>> e-mail is to provided updated webrevs for this fix
>>>>>>>>> (CR9/v2.09/12-for-jdk14)
>>>>>>>>> within the revised context provided by {8235931, 8236035,
>>>>>>>>> 8235795}.
>>>>>>>>>
>>>>>>>>> Main bug URL:
>>>>>>>>>
>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>
>>>>>>>>> The project is currently baselined on jdk-14+34.
>>>>>>>>>
>>>>>>>>> Here's the full webrev URL for those folks that want to see all
>>>>>>>>> of the
>>>>>>>>> current Async Monitor Deflation code along with {8235931,
>>>>>>>>> 8236035, 8235795}
>>>>>>>>> in one go (v2.09b full):
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09b.full/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Compare the open.patch file in 12-for-jdk14.v2.09.full and
>>>>>>>>> 12-for-jdk14.v2.09b.full
>>>>>>>>> using your favorite file comparison/merge tool to see how Async
>>>>>>>>> Monitor Deflation
>>>>>>>>> evolved due to {8235931, 8236035, 8235795}.
>>>>>>>>>
>>>>>>>>> Some folks might want to see just the Async Monitor Deflation
>>>>>>>>> code on top of
>>>>>>>>> {8235931, 8236035, 8235795} so here's a webrev for that (v2.09b
>>>>>>>>> inc):
>>>>>>>>>
>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09b.inc/
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> These webrevs have gone thru several Mach5 Tier[1-8] runs along
>>>>>>>>> with
>>>>>>>>> my usual stress testing and SPECjbb2015 testing and there
>>>>>>>>> aren't any
>>>>>>>>> surprises relative to CR9/v2.09/12-for-jdk14.
>>>>>>>>>
>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>
>>>>>>>>> Dan
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 12/11/19 3:41 PM, Daniel D. Daugherty wrote:
>>>>>>>>>> Greetings,
>>>>>>>>>>
>>>>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>>>>> response to
>>>>>>>>>> the CR8/v2.08/11-for-jdk14 code review cycle. Thanks to David
>>>>>>>>>> H., Robbin
>>>>>>>>>> and Erik O. for their comments!
>>>>>>>>>>
>>>>>>>>>> This project is no longer targeted to JDK14 so this is NOT an
>>>>>>>>>> urgent code
>>>>>>>>>> review request. The primary purpose of this webrev is simply
>>>>>>>>>> to close the
>>>>>>>>>> CR8/v2.08/11-for-jdk14 code review loop and to let folks see
>>>>>>>>>> how I resolved
>>>>>>>>>> the code review comments from that round.
>>>>>>>>>>
>>>>>>>>>> Most of the comments in the CR8/v2.08/11-for-jdk14 code review
>>>>>>>>>> cycle were
>>>>>>>>>> on the monitor list changes so I'm going to take a look at
>>>>>>>>>> extracting those
>>>>>>>>>> changes into a standalone patch. Switching from
>>>>>>>>>> Thread::muxAcquire(&gListLock)
>>>>>>>>>> and Thread::muxRelease(&gListLock) to finer grained internal
>>>>>>>>>> spin locks needs
>>>>>>>>>> to be thoroughly reviewed and the best way to do that is
>>>>>>>>>> separately from the
>>>>>>>>>> Async Monitor Deflation changes. Thanks to Coleen for
>>>>>>>>>> suggesting doing this
>>>>>>>>>> extraction earlier.
>>>>>>>>>>
>>>>>>>>>> I have attached the change list from CR8 to CR9 instead of
>>>>>>>>>> putting it in
>>>>>>>>>> the body of this email. I've also added a link to the
>>>>>>>>>> CR8-to-CR9-changes
>>>>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>>>>
>>>>>>>>>> Main bug URL:
>>>>>>>>>>
>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>
>>>>>>>>>> The project is currently baselined on jdk-14+26.
>>>>>>>>>>
>>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>>> all of the
>>>>>>>>>> current Async Monitor Deflation code in one go (v2.09 full):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09.full/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>>>> last review
>>>>>>>>>> cycle so here's a webrev for that (v2.09 inc):
>>>>>>>>>>
>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/12-for-jdk14.v2.09.inc/
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The OpenJDK wiki has NOT yet been updated for this round of
>>>>>>>>>> changes:
>>>>>>>>>>
>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> The jdk-14+26 based v2.09 version of the patch has been thru
>>>>>>>>>> Mach5 tier[1-7]
>>>>>>>>>> testing on Oracle's usual set of platforms. Mach5 tier8 is
>>>>>>>>>> still running.
>>>>>>>>>> A slightly older version of the v2.09 patch has also been
>>>>>>>>>> through my usual
>>>>>>>>>> set of stress testing on Linux-X64 and macOSX with the
>>>>>>>>>> addition of Robbin's
>>>>>>>>>> "MoCrazy 1024" test running in parallel on Linux-X64 with the
>>>>>>>>>> other tests in
>>>>>>>>>> my lab. The "MoCrazy 1024" has been going for > 5 days and
>>>>>>>>>> 6700+ iterations
>>>>>>>>>> without any failures.
>>>>>>>>>>
>>>>>>>>>> I'm planning to do a SPECjbb2015 round on the
>>>>>>>>>> CR9/v2.09/12-for-jdk14 bits.
>>>>>>>>>>
>>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>>
>>>>>>>>>> Dan
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 11/4/19 4:03 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>> Greetings,
>>>>>>>>>>>
>>>>>>>>>>> I have made changes to the Async Monitor Deflation code in
>>>>>>>>>>> response to
>>>>>>>>>>> the CR7/v2.07/10-for-jdk14 code review cycle. Thanks to David
>>>>>>>>>>> H., Robbin
>>>>>>>>>>> and Erik O. for their comments!
>>>>>>>>>>>
>>>>>>>>>>> JDK14 Rampdown phase one is coming on Dec. 12, 2019 and the
>>>>>>>>>>> Async Monitor
>>>>>>>>>>> Deflation project needs to push before Nov. 12, 2019 in order
>>>>>>>>>>> to allow
>>>>>>>>>>> for sufficient bake time for such a big change. Nov. 12 is
>>>>>>>>>>> _next_ Tuesday
>>>>>>>>>>> so we have 8 days from today to finish this code review cycle
>>>>>>>>>>> and push
>>>>>>>>>>> this code for JDK14.
>>>>>>>>>>>
>>>>>>>>>>> Carsten and Roman! Time for you guys to chime in again on the
>>>>>>>>>>> code reviews.
>>>>>>>>>>>
>>>>>>>>>>> I have attached the change list from CR7 to CR8 instead of
>>>>>>>>>>> putting it in
>>>>>>>>>>> the body of this email. I've also added a link to the
>>>>>>>>>>> CR7-to-CR8-changes
>>>>>>>>>>> file to the webrevs so it should be easy to find.
>>>>>>>>>>>
>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>
>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>
>>>>>>>>>>> The project is currently baselined on jdk-14+21.
>>>>>>>>>>>
>>>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>>>> all of the
>>>>>>>>>>> current Async Monitor Deflation code in one go (v2.08 full):
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/11-for-jdk14.v2.08.full
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>>>>> last review
>>>>>>>>>>> cycle so here's a webrev for that (v2.08 inc):
>>>>>>>>>>>
>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/11-for-jdk14.v2.08.inc/
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The OpenJDK wiki did not need any changes for this round:
>>>>>>>>>>>
>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> The jdk-14+21 based v2.08 version of the patch has been thru
>>>>>>>>>>> Mach5 tier[1-8]
>>>>>>>>>>> testing on Oracle's usual set of platforms. It has also been
>>>>>>>>>>> through my usual
>>>>>>>>>>> set of stress testing on Linux-X64, macOSX and Solaris-X64
>>>>>>>>>>> with the addition
>>>>>>>>>>> of Robbin's "MoCrazy 1024" test running in parallel with the
>>>>>>>>>>> other tests in
>>>>>>>>>>> my lab. Some testing is still running, but so far there are
>>>>>>>>>>> no new regressions.
>>>>>>>>>>>
>>>>>>>>>>> I have not yet done a SPECjbb2015 round on the
>>>>>>>>>>> CR8/v2.08/11-for-jdk14 bits.
>>>>>>>>>>>
>>>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>>>
>>>>>>>>>>> Dan
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 10/17/19 5:50 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>
>>>>>>>>>>>> The Async Monitor Deflation project is reaching the end
>>>>>>>>>>>> game. I have no
>>>>>>>>>>>> changes planned for the project at this time so all that is
>>>>>>>>>>>> left is code
>>>>>>>>>>>> review and any changes that results from those reviews.
>>>>>>>>>>>>
>>>>>>>>>>>> Carsten and Roman! Time for you guys to chime in again on
>>>>>>>>>>>> the code reviews.
>>>>>>>>>>>>
>>>>>>>>>>>> I have attached the list of fixes from CR6 to CR7 instead of
>>>>>>>>>>>> putting it
>>>>>>>>>>>> in the main body of this email.
>>>>>>>>>>>>
>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>
>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>
>>>>>>>>>>>> The project is currently baselined on jdk-14+19.
>>>>>>>>>>>>
>>>>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>>>>> all of the
>>>>>>>>>>>> current Async Monitor Deflation code in one go (v2.07 full):
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/10-for-jdk14.v2.07.full
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Some folks might want to see just what has changed since the
>>>>>>>>>>>> last review
>>>>>>>>>>>> cycle so here's a webrev for that (v2.07 inc):
>>>>>>>>>>>>
>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/10-for-jdk14.v2.07.inc/
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The OpenJDK wiki has been updated to match the
>>>>>>>>>>>> CR7/v2.07/10-for-jdk14 changes:
>>>>>>>>>>>>
>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> The jdk-14+18 based v2.07 version of the patch has been thru
>>>>>>>>>>>> Mach5 tier[1-8]
>>>>>>>>>>>> testing on Oracle's usual set of platforms. It has also been
>>>>>>>>>>>> through my usual
>>>>>>>>>>>> set of stress testing on Linux-X64, macOSX and Solaris-X64
>>>>>>>>>>>> with the addition
>>>>>>>>>>>> of Robbin's "MoCrazy 1024" test running in parallel with the
>>>>>>>>>>>> other tests in
>>>>>>>>>>>> my lab.
>>>>>>>>>>>>
>>>>>>>>>>>> The jdk-14+19 based v2.07 version of the patch has been thru
>>>>>>>>>>>> Mach5 tier[1-3]
>>>>>>>>>>>> test on Oracle's usual set of platforms. Mach5 tier[4-8] are
>>>>>>>>>>>> in process.
>>>>>>>>>>>>
>>>>>>>>>>>> I did another round of SPECjbb2015 testing in Oracle's
>>>>>>>>>>>> Aurora Performance lab
>>>>>>>>>>>> using using their tuned SPECjbb2015 Linux-X64 G1 configs:
>>>>>>>>>>>>
>>>>>>>>>>>> - "base" is jdk-14+18
>>>>>>>>>>>> - "v2.07" is the latest version and includes C2
>>>>>>>>>>>> inc_om_ref_count() support
>>>>>>>>>>>> on LP64 X64 and the new
>>>>>>>>>>>> HandshakeAfterDeflateIdleMonitors option
>>>>>>>>>>>> - "off" is with -XX:-AsyncDeflateIdleMonitors specified
>>>>>>>>>>>> - "handshake" is with
>>>>>>>>>>>> -XX:+HandshakeAfterDeflateIdleMonitors specified
>>>>>>>>>>>>
>>>>>>>>>>>> hbIR hbIR
>>>>>>>>>>>> (max attempted) (settled) max-jOPS critical-jOPS runtime
>>>>>>>>>>>> --------------- --------- -------- ------------- -------
>>>>>>>>>>>> 34282.00 30635.90 28831.30 20969.20 3841.30 base
>>>>>>>>>>>> 34282.00 30973.00 29345.80 21025.20 3964.10 v2.07
>>>>>>>>>>>> 34282.00 31105.60 29174.30 21074.00 3931.30
>>>>>>>>>>>> v2.07_handshake
>>>>>>>>>>>> 34282.00 30789.70 27151.60 19839.10 3850.20
>>>>>>>>>>>> v2.07_off
>>>>>>>>>>>>
>>>>>>>>>>>> - The Aurora Perf comparison tool reports:
>>>>>>>>>>>>
>>>>>>>>>>>> Comparison max-jOPS critical-jOPS
>>>>>>>>>>>> ---------------------- --------------------
>>>>>>>>>>>> --------------------
>>>>>>>>>>>> base vs 2.07 +1.78% (s, p=0.000) +0.27%
>>>>>>>>>>>> (ns, p=0.790)
>>>>>>>>>>>> base vs 2.07_handshake +1.19% (s, p=0.007) +0.58%
>>>>>>>>>>>> (ns, p=0.536)
>>>>>>>>>>>> base vs 2.07_off -5.83% (ns, p=0.394) -5.39%
>>>>>>>>>>>> (ns, p=0.347)
>>>>>>>>>>>>
>>>>>>>>>>>> (s) - significant (ns) - not-significant
>>>>>>>>>>>>
>>>>>>>>>>>> - For historical comparison, the Aurora Perf comparision
>>>>>>>>>>>> tool
>>>>>>>>>>>> reported for v2.06 with a baseline of jdk-13+31:
>>>>>>>>>>>>
>>>>>>>>>>>> Comparison max-jOPS critical-jOPS
>>>>>>>>>>>> ---------------------- --------------------
>>>>>>>>>>>> --------------------
>>>>>>>>>>>> base vs 2.06 -0.32% (ns, p=0.345) +0.71%
>>>>>>>>>>>> (ns, p=0.646)
>>>>>>>>>>>> base vs 2.06_off +0.49% (ns, p=0.292) -1.21%
>>>>>>>>>>>> (ns, p=0.481)
>>>>>>>>>>>>
>>>>>>>>>>>> (s) - significant (ns) - not-significant
>>>>>>>>>>>>
>>>>>>>>>>>> Thanks, in advance, for any questions, comments or suggestions.
>>>>>>>>>>>>
>>>>>>>>>>>> Dan
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 8/28/19 5:02 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>
>>>>>>>>>>>>> The Async Monitor Deflation project has rebased to JDK14 so
>>>>>>>>>>>>> it's time
>>>>>>>>>>>>> for our first code review in that new context!!
>>>>>>>>>>>>>
>>>>>>>>>>>>> I've been focused on changing the monitor list management
>>>>>>>>>>>>> code to be
>>>>>>>>>>>>> lock-free in order to make SPECjbb2015 happier. Of course
>>>>>>>>>>>>> with a change
>>>>>>>>>>>>> like that, it takes a while to chase down all the new and
>>>>>>>>>>>>> wonderful
>>>>>>>>>>>>> races. At this point, I have the code back to the same
>>>>>>>>>>>>> stability that
>>>>>>>>>>>>> I had with CR5/v2.05/8-for-jdk13.
>>>>>>>>>>>>>
>>>>>>>>>>>>> To lay the ground work for this round of review, I pushed
>>>>>>>>>>>>> the following
>>>>>>>>>>>>> two fixes to jdk/jdk earlier today:
>>>>>>>>>>>>>
>>>>>>>>>>>>> JDK-8230184 rename, whitespace, indent and comments
>>>>>>>>>>>>> changes in preparation
>>>>>>>>>>>>> for lock free Monitor lists
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230184
>>>>>>>>>>>>>
>>>>>>>>>>>>> JDK-8230317 serviceability/sa/ClhsdbPrintStatics.java
>>>>>>>>>>>>> fails after 8230184
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8230317
>>>>>>>>>>>>>
>>>>>>>>>>>>> I have attached the list of fixes from CR5 to CR6 instead
>>>>>>>>>>>>> of putting
>>>>>>>>>>>>> in the main body of this email.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>
>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>
>>>>>>>>>>>>> The project is currently baselined on jdk-14+11 plus the
>>>>>>>>>>>>> fixes for
>>>>>>>>>>>>> JDK-8230184 and JDK-8230317.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Here's the full webrev URL for those folks that want to see
>>>>>>>>>>>>> all of the
>>>>>>>>>>>>> current Async Monitor Deflation code in one go (v2.06 full):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.full/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The primary focus of this review cycle is on the lock-free
>>>>>>>>>>>>> Monitor List
>>>>>>>>>>>>> management changes so here's a webrev for just that patch
>>>>>>>>>>>>> (v2.06c):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06c.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The secondary focus of this review cycle is on the bug
>>>>>>>>>>>>> fixes that have
>>>>>>>>>>>>> been made since CR5/v2.05/8-for-jdk13 so here's a webrev
>>>>>>>>>>>>> for just that
>>>>>>>>>>>>> patch (v2.06b):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06b.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The third and final bucket for this review cycle is the
>>>>>>>>>>>>> rename, whitespace,
>>>>>>>>>>>>> indent and comments changes made in preparation for lock
>>>>>>>>>>>>> free Monitor list
>>>>>>>>>>>>> management. Almost all of that was extracted into
>>>>>>>>>>>>> JDK-8230184 for the
>>>>>>>>>>>>> baseline so this bucket now has just a few comment changes
>>>>>>>>>>>>> relative to
>>>>>>>>>>>>> CR5/v2.05/8-for-jdk13. Here's a webrev for the remainder
>>>>>>>>>>>>> (v2.06a):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06a.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Some folks might want to see just what has changed since
>>>>>>>>>>>>> the last review
>>>>>>>>>>>>> cycle so here's a webrev for that (v2.06 inc):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.06.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Last, but not least, some folks might want to see the code
>>>>>>>>>>>>> before the
>>>>>>>>>>>>> addition of lock-free Monitor List management so here's a
>>>>>>>>>>>>> webrev for
>>>>>>>>>>>>> that (v2.00 -> v2.05):
>>>>>>>>>>>>>
>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/9-for-jdk14.v2.05.inc/
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> The OpenJDK wiki will need minor updates to match the CR6
>>>>>>>>>>>>> changes:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> but that should only be changes to describe per-thread list
>>>>>>>>>>>>> async monitor
>>>>>>>>>>>>> deflation being done by the ServiceThread.
>>>>>>>>>>>>>
>>>>>>>>>>>>> (I did update the OpenJDK wiki for the CR5 changes back on
>>>>>>>>>>>>> 2019.08.14)
>>>>>>>>>>>>>
>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>>> testing on
>>>>>>>>>>>>> Oracle's usual set of platforms. It has also been through
>>>>>>>>>>>>> my usual set
>>>>>>>>>>>>> of stress testing on Linux-X64, macOSX and Solaris-X64.
>>>>>>>>>>>>>
>>>>>>>>>>>>> I did a bunch of SPECjbb2015 testing in Oracle's Aurora
>>>>>>>>>>>>> Performance lab
>>>>>>>>>>>>> using using their tuned SPECjbb2015 Linux-X64 G1 configs.
>>>>>>>>>>>>> This was using
>>>>>>>>>>>>> this patch baselined on jdk-13+31 (for stability):
>>>>>>>>>>>>>
>>>>>>>>>>>>> hbIR hbIR
>>>>>>>>>>>>> (max attempted) (settled) max-jOPS critical-jOPS
>>>>>>>>>>>>> runtime
>>>>>>>>>>>>> --------------- --------- -------- -------------
>>>>>>>>>>>>> -------
>>>>>>>>>>>>> 34282.00 28837.20 27905.20 19817.40 3658.10
>>>>>>>>>>>>> base
>>>>>>>>>>>>> 34965.70 29798.80 27814.90 19959.00 3514.60
>>>>>>>>>>>>> v2.06d
>>>>>>>>>>>>> 34282.00 29100.70 28042.50 19577.00 3701.90
>>>>>>>>>>>>> v2.06d_off
>>>>>>>>>>>>> 34282.00 29218.50 27562.80 19397.30 3657.60
>>>>>>>>>>>>> v2.06d_ocache
>>>>>>>>>>>>> 34965.70 29838.30 26512.40 19170.60 3569.90
>>>>>>>>>>>>> v2.05
>>>>>>>>>>>>> 34282.00 28926.10 27734.00 19835.10 3588.40
>>>>>>>>>>>>> v2.05_off
>>>>>>>>>>>>>
>>>>>>>>>>>>> The "off" configs are with -XX:-AsyncDeflateIdleMonitors
>>>>>>>>>>>>> specified and
>>>>>>>>>>>>> the "ocache" config is with 128 byte cache line sizes
>>>>>>>>>>>>> instead of 64 byte
>>>>>>>>>>>>> cache lines sizes. "v2.06d" is the last set of changes that
>>>>>>>>>>>>> I made before
>>>>>>>>>>>>> those changes were distributed into the "v2.06a", "v2.06b"
>>>>>>>>>>>>> and "v2.06c"
>>>>>>>>>>>>> buckets for this review recycle.
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>
>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 7/11/19 3:49 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I've been focused on chasing down and fixing the rare test
>>>>>>>>>>>>>> failures
>>>>>>>>>>>>>> that only pop up rarely. So this round is primarily fixes
>>>>>>>>>>>>>> for races
>>>>>>>>>>>>>> with a few additional fixes that came from Karen's review
>>>>>>>>>>>>>> of CR4.
>>>>>>>>>>>>>> Thanks Karen!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have attached the list of fixes from CR4 to CR5 instead
>>>>>>>>>>>>>> of putting
>>>>>>>>>>>>>> in the main body of this email.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> The project is currently baselined on jdk-13+29. This will
>>>>>>>>>>>>>> likely be
>>>>>>>>>>>>>> the last JDK13 baseline for this project and I'll roll to
>>>>>>>>>>>>>> the JDK14
>>>>>>>>>>>>>> (jdk/jdk) repo soon...
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.full/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/8-for-jdk13.inc/
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> I have not yet checked the OpenJDK wiki to see if it needs
>>>>>>>>>>>>>> any updates
>>>>>>>>>>>>>> to match the CR5 changes:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> (I did update the OpenJDK wiki for the CR4 changes back on
>>>>>>>>>>>>>> 2019.06.26)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-3]
>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[4-6] is
>>>>>>>>>>>>>> running now and
>>>>>>>>>>>>>> Mach5 tier[78] will follow. I'll kick off the usual stress
>>>>>>>>>>>>>> testing
>>>>>>>>>>>>>> on Linux-X64, macOSX and Solaris-X64 as those machines
>>>>>>>>>>>>>> become available.
>>>>>>>>>>>>>> Since I haven't made any performance changes in this
>>>>>>>>>>>>>> round, I'll only
>>>>>>>>>>>>>> be running SPECjbb2015 to gather the latest
>>>>>>>>>>>>>> monitorinflation logs.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Next up:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - We're still seeing 4-5% lower performance with
>>>>>>>>>>>>>> SPECjbb2015 on
>>>>>>>>>>>>>> Linux-X64 and we've determined that some of that comes from
>>>>>>>>>>>>>> contention on the gListLock. So I'm going to investigate
>>>>>>>>>>>>>> removing
>>>>>>>>>>>>>> the gListLock. Yes, another lock free set of changes is
>>>>>>>>>>>>>> coming!
>>>>>>>>>>>>>> - Of course, going lock free often causes new races and
>>>>>>>>>>>>>> new failures
>>>>>>>>>>>>>> so that's a good reason for make those changes isolated
>>>>>>>>>>>>>> in their
>>>>>>>>>>>>>> own round (and not holding up CR5/v2.05/8-for-jdk13
>>>>>>>>>>>>>> anymore).
>>>>>>>>>>>>>> - I finally have a potential fix for the Win* failure with
>>>>>>>>>>>>>> gc/g1/humongousObjects/TestHumongousClassLoader.java
>>>>>>>>>>>>>> but I haven't run it through Mach5 yet so it'll be in
>>>>>>>>>>>>>> the next round.
>>>>>>>>>>>>>> - Some RTM tests were recently re-enabled in Mach5 and I'm
>>>>>>>>>>>>>> seeing some
>>>>>>>>>>>>>> monitor related failures there. I suspect that I need to
>>>>>>>>>>>>>> go take a
>>>>>>>>>>>>>> look at the C2 RTM macro assembler code and look for
>>>>>>>>>>>>>> things that might
>>>>>>>>>>>>>> conflict if Async Monitor Deflation. If you're
>>>>>>>>>>>>>> interested in that kind
>>>>>>>>>>>>>> of issue, then see the macroAssembler_x86.cpp sanity
>>>>>>>>>>>>>> check that I
>>>>>>>>>>>>>> added in this round!
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 5/26/19 8:30 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have a fix for an issue that came up during performance
>>>>>>>>>>>>>>> testing.
>>>>>>>>>>>>>>> Many thanks to Robbin for diagnosing the issue in his
>>>>>>>>>>>>>>> SPECjbb2015
>>>>>>>>>>>>>>> experiments.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the list of changes from CR3 to CR4. The list is a
>>>>>>>>>>>>>>> bit
>>>>>>>>>>>>>>> verbose due to the complexity of the issue, but the changes
>>>>>>>>>>>>>>> themselves are not that big.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Functional:
>>>>>>>>>>>>>>> - Change SafepointSynchronize::is_cleanup_needed() from
>>>>>>>>>>>>>>> calling
>>>>>>>>>>>>>>> ObjectSynchronizer::is_cleanup_needed() to calling
>>>>>>>>>>>>>>> ObjectSynchronizer::is_safepoint_deflation_needed():
>>>>>>>>>>>>>>> - is_safepoint_deflation_needed() returns the result of
>>>>>>>>>>>>>>> monitors_used_above_threshold() for safepoint based
>>>>>>>>>>>>>>> monitor deflation (!AsyncDeflateIdleMonitors).
>>>>>>>>>>>>>>> - For AsyncDeflateIdleMonitors, it only returns true if
>>>>>>>>>>>>>>> there is a special deflation request, e.g.,
>>>>>>>>>>>>>>> System.gc()
>>>>>>>>>>>>>>> - This solves a bug where there are a bunch of Cleanup
>>>>>>>>>>>>>>> safepoints that simply request async deflation which
>>>>>>>>>>>>>>> keeps the async JavaThreads from making progress on
>>>>>>>>>>>>>>> their async deflation work.
>>>>>>>>>>>>>>> - Add AsyncDeflationInterval diagnostic option.
>>>>>>>>>>>>>>> Description:
>>>>>>>>>>>>>>> Async deflate idle monitors every so many
>>>>>>>>>>>>>>> milliseconds when
>>>>>>>>>>>>>>> MonitorUsedDeflationThreshold is exceeded (0 is off).
>>>>>>>>>>>>>>> - Replace
>>>>>>>>>>>>>>> ObjectSynchronizer::gOmShouldDeflateIdleMonitors() with
>>>>>>>>>>>>>>> ObjectSynchronizer::is_async_deflation_needed():
>>>>>>>>>>>>>>> - is_async_deflation_needed() returns true when
>>>>>>>>>>>>>>> is_async_cleanup_requested() is true or when
>>>>>>>>>>>>>>> monitors_used_above_threshold() is true (but no
>>>>>>>>>>>>>>> more often than
>>>>>>>>>>>>>>> AsyncDeflationInterval).
>>>>>>>>>>>>>>> - if AsyncDeflateIdleMonitors Service_lock->wait()
>>>>>>>>>>>>>>> now waits for
>>>>>>>>>>>>>>> at most GuaranteedSafepointInterval millis:
>>>>>>>>>>>>>>> - This allows is_async_deflation_needed() to be
>>>>>>>>>>>>>>> checked at
>>>>>>>>>>>>>>> the same interval as GuaranteedSafepointInterval.
>>>>>>>>>>>>>>> (default is 1000 millis/1 second)
>>>>>>>>>>>>>>> - Once is_async_deflation_needed() has returned
>>>>>>>>>>>>>>> true, it
>>>>>>>>>>>>>>> generally cannot return true for
>>>>>>>>>>>>>>> AsyncDeflationInterval.
>>>>>>>>>>>>>>> This is to prevent async deflation from swamping the
>>>>>>>>>>>>>>> ServiceThread.
>>>>>>>>>>>>>>> - The ServiceThread still handles async deflation of
>>>>>>>>>>>>>>> the global
>>>>>>>>>>>>>>> in-use list and now it also marks JavaThreads for
>>>>>>>>>>>>>>> async deflation
>>>>>>>>>>>>>>> of their in-use lists.
>>>>>>>>>>>>>>> - The ServiceThread will check for async deflation
>>>>>>>>>>>>>>> work every
>>>>>>>>>>>>>>> GuaranteedSafepointInterval.
>>>>>>>>>>>>>>> - A safepoint can still cause the ServiceThread to
>>>>>>>>>>>>>>> check for
>>>>>>>>>>>>>>> async deflation work via is_async_deflation_requested.
>>>>>>>>>>>>>>> - Refactor code from
>>>>>>>>>>>>>>> ObjectSynchronizer::is_cleanup_needed() into
>>>>>>>>>>>>>>> monitors_used_above_threshold() and remove
>>>>>>>>>>>>>>> is_cleanup_needed().
>>>>>>>>>>>>>>> - In addition to System.gc(), the VM_Exit VM op and the
>>>>>>>>>>>>>>> final
>>>>>>>>>>>>>>> VMThread safepoint now set the
>>>>>>>>>>>>>>> is_special_deflation_requested
>>>>>>>>>>>>>>> flag to reduce the in-use monitor population that is
>>>>>>>>>>>>>>> reported by
>>>>>>>>>>>>>>> ObjectSynchronizer::log_in_use_monitor_details() at VM exit.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Test update:
>>>>>>>>>>>>>>> - test/hotspot/gtest/oops/test_markOop.cpp is updated
>>>>>>>>>>>>>>> to work with
>>>>>>>>>>>>>>> AsyncDeflateIdleMonitors.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Collateral:
>>>>>>>>>>>>>>> - Add/clarify/update some logging messages.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Cleanup:
>>>>>>>>>>>>>>> - Updated comments based on Karen's code review.
>>>>>>>>>>>>>>> - Change 'special cleanup' -> 'special deflation' and
>>>>>>>>>>>>>>> 'async cleanup' -> 'async deflation'.
>>>>>>>>>>>>>>> - comment and function name changes
>>>>>>>>>>>>>>> - Clarify MonitorUsedDeflationThreshold description;
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The project is currently baselined on jdk-13+22.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.full/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/7-for-jdk13.inc/
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I have not updated the OpenJDK wiki to reflect the CR4
>>>>>>>>>>>>>>> changes:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> The wiki doesn't say a whole lot about the async
>>>>>>>>>>>>>>> deflation invocation
>>>>>>>>>>>>>>> mechanism so I have to figure out how to add that content.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>>> Oracle's usual set of platforms. My Solaris-X64 stress
>>>>>>>>>>>>>>> kit run is
>>>>>>>>>>>>>>> running now. Kitchensink8H on product, fastdebug, and
>>>>>>>>>>>>>>> slowdebug bits
>>>>>>>>>>>>>>> are running on Linux-X64, MacOSX and Solaris-X64. I still
>>>>>>>>>>>>>>> have to run
>>>>>>>>>>>>>>> my stress kit on Linux-X64. I still have to run the
>>>>>>>>>>>>>>> SPECjbb2015
>>>>>>>>>>>>>>> baseline and CR4 runs on Linux-X64, MacOSX and Solaris-X64.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 5/6/19 11:52 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I had some discussions with Karen about a race that was
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>> ObjectMonitor::enter() code in CR2/v2.02/5-for-jdk13.
>>>>>>>>>>>>>>>> This race was
>>>>>>>>>>>>>>>> theoretical and I had no test failures due to it. The
>>>>>>>>>>>>>>>> fix is pretty
>>>>>>>>>>>>>>>> simple: remove the special case code for async deflation
>>>>>>>>>>>>>>>> in the
>>>>>>>>>>>>>>>> ObjectMonitor::enter() function and rely solely on the
>>>>>>>>>>>>>>>> ref_count
>>>>>>>>>>>>>>>> for ObjectMonitor::enter() protection.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> During those discussions Karen also floated the idea of
>>>>>>>>>>>>>>>> using the
>>>>>>>>>>>>>>>> ref_count field instead of the contentions field for the
>>>>>>>>>>>>>>>> Async
>>>>>>>>>>>>>>>> Monitor Deflation protocol. I decided to go ahead and
>>>>>>>>>>>>>>>> code up that
>>>>>>>>>>>>>>>> change and I have run it through the usual stress and
>>>>>>>>>>>>>>>> Mach5 testing
>>>>>>>>>>>>>>>> with no issues. It's also known as v2.03 (for those for
>>>>>>>>>>>>>>>> with the
>>>>>>>>>>>>>>>> patches) and as webrev/6-for-jdk13 (for those with
>>>>>>>>>>>>>>>> webrev URLs).
>>>>>>>>>>>>>>>> Sorry for all the names...
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> The project is currently baselined on jdk-13+18.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.full/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Here's the incremental webrev URL:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/6-for-jdk13.inc/
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I have also updated the OpenJDK wiki to reflect the CR3
>>>>>>>>>>>>>>>> changes:
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-8]
>>>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>>>> Oracle's usual set of platforms. My Solaris-X64 stress
>>>>>>>>>>>>>>>> kit run had
>>>>>>>>>>>>>>>> no issues. Kitchensink8H on product, fastdebug, and
>>>>>>>>>>>>>>>> slowdebug bits
>>>>>>>>>>>>>>>> had no failures on Linux-X64; MacOSX fastdebug and
>>>>>>>>>>>>>>>> slowdebug and
>>>>>>>>>>>>>>>> Solaris-X64 release had the usual "Too large time diff"
>>>>>>>>>>>>>>>> complaints.
>>>>>>>>>>>>>>>> 12 hour Inflate2 runs on product, fastdebug and
>>>>>>>>>>>>>>>> slowdebug bits on
>>>>>>>>>>>>>>>> Linux-X64, MacOSX and Solaris-X64 had no failures. My
>>>>>>>>>>>>>>>> Linux-X64
>>>>>>>>>>>>>>>> stress kit is running right now.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> I've done the SPECjbb2015 baseline and CR3 runs. I need
>>>>>>>>>>>>>>>> to gather
>>>>>>>>>>>>>>>> the results and analyze them.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> On 4/25/19 12:38 PM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I have a small but important bug fix for the Async
>>>>>>>>>>>>>>>>> Monitor Deflation
>>>>>>>>>>>>>>>>> project ready to go. It's also known as v2.02 (for
>>>>>>>>>>>>>>>>> those for with the
>>>>>>>>>>>>>>>>> patches) and as webrev/5-for-jdk13 (for those with
>>>>>>>>>>>>>>>>> webrev URLs). Sorry
>>>>>>>>>>>>>>>>> for all the names...
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JDK-8222295 was pushed to jdk/jdk two days ago so that
>>>>>>>>>>>>>>>>> baseline patch
>>>>>>>>>>>>>>>>> is out of our hair.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> The project is currently baselined on jdk-13+17.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here's the full webrev URL:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.full/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Here's the incremental webrev URL (JDK-8153224):
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/5-for-jdk13.inc/
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I still have to update the OpenJDK wiki to reflect the
>>>>>>>>>>>>>>>>> CR2 changes:
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> This version of the patch has been thru Mach5 tier[1-6]
>>>>>>>>>>>>>>>>> testing on
>>>>>>>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[7-8] is
>>>>>>>>>>>>>>>>> running now.
>>>>>>>>>>>>>>>>> My stress kit is running on Solaris-X64 now.
>>>>>>>>>>>>>>>>> Kitchensink8H is running
>>>>>>>>>>>>>>>>> now on product, fastdebug, and slowdebug bits on
>>>>>>>>>>>>>>>>> Linux-X64, MacOSX
>>>>>>>>>>>>>>>>> and Solaris-X64. 12 hour Inflate2 runs are running now
>>>>>>>>>>>>>>>>> on product,
>>>>>>>>>>>>>>>>> fastdebug and slowdebug bits on Linux-X64, MacOSX and
>>>>>>>>>>>>>>>>> Solaris-X64.
>>>>>>>>>>>>>>>>> I'll start my my stress kit on Linux-X64 sometime on
>>>>>>>>>>>>>>>>> Sunday (after
>>>>>>>>>>>>>>>>> my jdk-13+18 stress run is done).
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> I'll do SPECjbb2015 baseline and CR2 runs after all the
>>>>>>>>>>>>>>>>> stress
>>>>>>>>>>>>>>>>> testing is done.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>> On 4/19/19 11:58 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I finally have CR1 for the Async Monitor Deflation
>>>>>>>>>>>>>>>>>> project ready to
>>>>>>>>>>>>>>>>>> go. It's also known as v2.01 (for those for with the
>>>>>>>>>>>>>>>>>> patches) and as
>>>>>>>>>>>>>>>>>> webrev/4-for-jdk13 (for those with webrev URLs). Sorry
>>>>>>>>>>>>>>>>>> for all the
>>>>>>>>>>>>>>>>>> names...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Main bug URL:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Baseline bug fixes URL:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> JDK-8222295 more baseline cleanups from Async
>>>>>>>>>>>>>>>>>> Monitor Deflation project
>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8222295
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> The project is currently baselined on jdk-13+15.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's the webrev for the latest baseline changes
>>>>>>>>>>>>>>>>>> (JDK-8222295):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.8222295
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's the full webrev URL (JDK-8153224 only):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.full/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Here's the incremental webrev URL (JDK-8153224):
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/4-for-jdk13.inc/
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> So I'm looking for reviews for both JDK-8222295 and
>>>>>>>>>>>>>>>>>> the latest version
>>>>>>>>>>>>>>>>>> of JDK-8153224...
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> I still have to update the OpenJDK wiki to reflect the
>>>>>>>>>>>>>>>>>> CR changes:
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> This version of the patch has been thru Mach5
>>>>>>>>>>>>>>>>>> tier[1-3] testing on
>>>>>>>>>>>>>>>>>> Oracle's usual set of platforms. Mach5 tier[4-6] is
>>>>>>>>>>>>>>>>>> running now and
>>>>>>>>>>>>>>>>>> Mach5 tier[78] will be run later today. My stress kit
>>>>>>>>>>>>>>>>>> on Solaris-X64
>>>>>>>>>>>>>>>>>> is running now. Linux-X64 stress testing will start on
>>>>>>>>>>>>>>>>>> Sunday. I'm
>>>>>>>>>>>>>>>>>> planning to do Kitchensink runs, SPECjbb2015 runs and
>>>>>>>>>>>>>>>>>> my monitor
>>>>>>>>>>>>>>>>>> inflation stress tests on Linux-X64, MacOSX and
>>>>>>>>>>>>>>>>>> Solaris-X64.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>> On 3/24/19 9:57 AM, Daniel D. Daugherty wrote:
>>>>>>>>>>>>>>>>>>> Greetings,
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Welcome to the OpenJDK review thread for my port of
>>>>>>>>>>>>>>>>>>> Carsten's work on:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> JDK-8153224 Monitor deflation prolong safepoints
>>>>>>>>>>>>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here's a link to the OpenJDK wiki that describes my
>>>>>>>>>>>>>>>>>>> port:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here's the webrev URL:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~dcubed/8153224-webrev/3-for-jdk13/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Here's a link to Carsten's original webrev:
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~cvarming/monitor_deflate_conc/0/
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Earlier versions of this patch have been through
>>>>>>>>>>>>>>>>>>> several rounds of
>>>>>>>>>>>>>>>>>>> preliminary review. Many thanks to Carsten, Coleen,
>>>>>>>>>>>>>>>>>>> Robbin, and
>>>>>>>>>>>>>>>>>>> Roman for their preliminary code review comments. A
>>>>>>>>>>>>>>>>>>> very special
>>>>>>>>>>>>>>>>>>> thanks to Robbin and Roman for building and testing
>>>>>>>>>>>>>>>>>>> the patch in
>>>>>>>>>>>>>>>>>>> their own environments (including specJBB2015).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> This version of the patch has been thru Mach5
>>>>>>>>>>>>>>>>>>> tier[1-8] testing on
>>>>>>>>>>>>>>>>>>> Oracle's usual set of platforms. Earlier versions
>>>>>>>>>>>>>>>>>>> have been run
>>>>>>>>>>>>>>>>>>> through my stress kit on my Linux-X64 and Solaris-X64
>>>>>>>>>>>>>>>>>>> servers
>>>>>>>>>>>>>>>>>>> (product, fastdebug, slowdebug).Earlier versions have
>>>>>>>>>>>>>>>>>>> run Kitchensink
>>>>>>>>>>>>>>>>>>> for 12 hours on MacOSX, Linux-X64 and Solaris-X64
>>>>>>>>>>>>>>>>>>> (product, fastdebug
>>>>>>>>>>>>>>>>>>> and slowdebug). Earlier versions have run my monitor
>>>>>>>>>>>>>>>>>>> inflation stress
>>>>>>>>>>>>>>>>>>> tests for 12 hours on MacOSX, Linux-X64 and
>>>>>>>>>>>>>>>>>>> Solaris-X64 (product,
>>>>>>>>>>>>>>>>>>> fastdebug and slowdebug).
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> All of the testing done on earlier versions will be
>>>>>>>>>>>>>>>>>>> redone on the
>>>>>>>>>>>>>>>>>>> latest version of the patch.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Thanks, in advance, for any questions, comments or
>>>>>>>>>>>>>>>>>>> suggestions.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> Dan
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>> P.S.
>>>>>>>>>>>>>>>>>>> One subtest in
>>>>>>>>>>>>>>>>>>> gc/g1/humongousObjects/TestHumongousClassLoader.java
>>>>>>>>>>>>>>>>>>> is currently failing in -Xcomp mode on Win* only.
>>>>>>>>>>>>>>>>>>> I've been trying
>>>>>>>>>>>>>>>>>>> to characterize/analyze this failure for more than a
>>>>>>>>>>>>>>>>>>> week now. At
>>>>>>>>>>>>>>>>>>> this point I'm convinced that Async Monitor Deflation
>>>>>>>>>>>>>>>>>>> is aggravating
>>>>>>>>>>>>>>>>>>> an existing bug. However, I plan to have a better
>>>>>>>>>>>>>>>>>>> handle on that
>>>>>>>>>>>>>>>>>>> failure before these bits are pushed to the jdk/jdk
>>>>>>>>>>>>>>>>>>> repo.
>>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>
>>>
>
More information about the hotspot-runtime-dev
mailing list