RFR(L) 8153224 Monitor deflation prolong safepoints (CR14/v2.14/17-for-jdk15)
Daniel D. Daugherty
daniel.daugherty at oracle.com
Tue Sep 15 16:42:57 UTC 2020
Thanks for filing the bug.
Dan
On 9/15/20 12:32 PM, Doerr, Martin wrote:
> Thank you, Dan!
>
> I've created https://bugs.openjdk.java.net/browse/JDK-8253183
> Feel free to modify/assign.
>
> Best regards,
> Martin
>
>
>> -----Original Message-----
>> From: Daniel D. Daugherty <daniel.daugherty at oracle.com>
>> Sent: Dienstag, 15. September 2020 16:59
>> To: Doerr, Martin <martin.doerr at sap.com>; Carsten Varming
>> <varming at gmail.com>; Erik Österlund <erik.osterlund at oracle.com>
>> Cc: Roman Kennke <rkennke at redhat.com>; hotspot-runtime-
>> dev at openjdk.java.net
>> Subject: Re: RFR(L) 8153224 Monitor deflation prolong safepoints
>> (CR14/v2.14/17-for-jdk15)
>>
>> Hi Martin,
>>
>> I believe that the support_IRIW_for_not_multiple_copy_atomic_cpu stuff
>> came from Erik O. so I'm adding him to this email thread.
>>
>> Yes, please create an issue that describes the problem and we'll
>> figure out who should take the issue...
>>
>> Dan
>>
>>
>> On 9/15/20 10:52 AM, Doerr, Martin wrote:
>>> Hi Dan and Carsten,
>>>
>>> I just noticed that this change introduced 2 usages of
>> "support_IRIW_for_not_multiple_copy_atomic_cpu".
>>> I think this is incorrect for arm32 which is not multi-copy-atomic, but uses
>> support_IRIW_for_not_multiple_copy_atomic_cpu = false.
>>> You probably meant "#ifdef CPU_MULTI_COPY_ATOMIC"?
>>>
>>> I haven't studied the access patterns you were trying to fix, but this looks
>> wrong.
>>> Should I create an issue? Would be great if I could assign it to somebody
>> familiar with this new code.
>>> Best regards,
>>> Martin
>>>
>>>
>>>> -----Original Message-----
>>>> From: hotspot-runtime-dev <hotspot-runtime-dev-
>>>> bounces at openjdk.java.net> On Behalf Of Daniel D. Daugherty
>>>> Sent: Dienstag, 2. Juni 2020 21:25
>>>> To: Carsten Varming <varming at gmail.com>
>>>> Cc: Roman Kennke <rkennke at redhat.com>; hotspot-runtime-
>>>> dev at openjdk.java.net
>>>> Subject: Re: RFR(L) 8153224 Monitor deflation prolong safepoints
>>>> (CR14/v2.14/17-for-jdk15)
>>>>
>>>> Hi Carsten,
>>>>
>>>> Thanks for the fast review of the updated comments.
>>>>
>>>> I filed the following new bug to track the change:
>>>>
>>>> JDK-8246359 clarify confusing comment in ObjectMonitor::EnterI()'s
>>>> race with async deflation
>>>> https://bugs.openjdk.java.net/browse/JDK-8153224
>>>>
>>>> And I started a review thread for the fix under that new bug ID.
>>>>
>>>> Dan
>>>>
>>>>
>>>> On 6/2/20 2:13 PM, Carsten Varming wrote:
>>>>> Hi Dan,
>>>>>
>>>>> I like the new comment. Thank you for doing the update.
>>>>>
>>>>> Carsten
>>>>>
>>>>> On Tue, Jun 2, 2020 at 1:54 PM Daniel D. Daugherty
>>>>> <daniel.daugherty at oracle.com
>> <mailto:daniel.daugherty at oracle.com>>
>>>> wrote:
>>>>> Hi Carsten,
>>>>>
>>>>> See replies below...
>>>>>
>>>>> David, Erik and Robbin, if you folks could also check out the revised
>>>>> comment below that would be appreciated.
>>>>>
>>>>>
>>>>> On 6/2/20 9:39 AM, Carsten Varming wrote:
>>>>>> Hi Dan,
>>>>>>
>>>>>> See inline.
>>>>>>
>>>>>> On Mon, Jun 1, 2020 at 11:32 PM Daniel D. Daugherty
>>>>>> <daniel.daugherty at oracle.com
>>>>>> <mailto:daniel.daugherty at oracle.com>> wrote:
>>>>>>
>>>>>> Hi Carsten,
>>>>>>
>>>>>> Thanks for chiming in on this review thread!!
>>>>>>
>>>>>>
>>>>>> It is my pleasure. You know the code is solid when the discussion
>>>>>> is focused on the comments.
>>>>> So true, so very true!
>>>>>
>>>>>
>>>>>> On 6/1/20 10:41 PM, Carsten Varming wrote:
>>>>>>> Hi Dan,
>>>>>>>
>>>>>>> I like the new protocol, but I had to think about how the
>>>>>>> extra increment to _contentions replaced the check on _owner
>>>>>>> that I originally added.
>>>>>> Right. The check on _owner was described in detail in the
>>>>>> OpenJDK wiki
>>>>>> subsection that was called "T-enter Wins By A-B-A". It can
>>>>>> still be
>>>>>> found by going thru the wiki's history links.
>>>>>>
>>>>>> That subsection was renamed and rewritten and can be found
>> here:
>>>>>>
>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation#A
>>>> syncMonitorDeflation-T-
>>>> enterWinsByCancellationViaDEFLATER_MARKERSwap
>>>>>>> I am thinking that the increased _contention value is a
>>>>>>> little mark left on the ObjectMonitor to signal to the
>>>>>>> deflater thread (which must be in the middle of trying to
>>>>>>> acquire the object monitor as _owner was set to
>>>>>>> DEFLATER_MARKER) that the deflater thread lost the race.
>>>>>> That is exactly what the extra increment is being used for.
>>>>>>
>>>>>> In my reply to David H. that you quoted below, I describe the
>>>>>> progression
>>>>>> of contention values thru the two possible race scenarios.
>>>>>> The progression
>>>>>> shows the T-enter thread winning the race and marking the
>>>>>> contention field
>>>>>> with the extra increment while the T-deflater thread
>>>>>> recognizes that it has
>>>>>> lost the race and unmarks the contention field with an extra
>>>>>> decrement.
>>>>>>
>>>>>>
>>>>>> I noticed that. Looks like David and I were racing and David won. :)
>>>>>>
>>>>>>> That little mark stays with the object monitor long after
>>>>>>> the thread is done with the monitor.
>>>>>> The "little mark" stays with the ObjectMonitor after T-enter
>>>>>> is done
>>>>>> entering until the T-deflater thread recognizes that the
>>>>>> async deflation
>>>>>> was canceled and does an extra decrement. I don't think I
>>>>>> would describe
>>>>>> it as "long after".
>>>>>>
>>>>>>
>>>>>> Sorry about the use of "long after". When I think about the
>>>>>> correctness of protocols, like the deflation protocol, I end up
>>>>>> thinking about sequences of instructions and the relevant
>>>>>> interleavings. In that context I often end up using phrases like
>>>>>> "long after" and "after" to mean anything after a particular
>>>>>> instruction. I did not mean to imply anything about the relative
>>>>>> speed of the execution of the code.
>>>>> It's okay. I do something similar in the transaction diagrams that
>>>>> I use to work out timing issues: <thread stalls> ... <thread resumes>
>>>>>
>>>>> The only point that I was trying to make is that the T-deflate thread
>>>>> is responsible for cleaning up the extra mark and it's committed to
>>>>> the code path that will result in the cleanup. Yes, there may be a
>>>>> <thread stalls> between the time that T-deflate recognizes that async
>>>>> deflation was canceled and when T-deflate does the extra
>> decrement,
>>>>> but I don't see any harm in it.
>>>>>
>>>>>
>>>>>>> It might be worth adding a comment to the code explaining
>>>>>>> that after the increment, the _contention field can only be
>>>>>>> set to 0 by a corresponding decrement in the async deflater
>>>>>>> thread, ensuring that the
>>>>>>> Atomic::cmpxchg(&mid->_contentions, (jint)0, -max_jint) on
>>>>>>> line 2166 fails. In particular, the comment:
>>>>>>> +. // .... We bump contentions an
>>>>>>> + // extra time to prevent the async deflater thread from
>>>>>>> temporarily
>>>>>>> + // changing it to -max_jint and back to zero (no flicker
>>>>>>> to confuse
>>>>>>> + // is_being_async_deflated()
>>>>>>> confused me as after the deflater thread sets _contentions
>>>>>>> to -max_jint, the deflater thread has won the race and the
>>>>>>> object monitor is about to be deflated.
>>>>>> For context, here's the code and comment being discussed:
>>>>>>
>>>>>>> 527 if (AsyncDeflateIdleMonitors &&
>>>>>>> 528 try_set_owner_from(DEFLATER_MARKER, Self) ==
>>>> DEFLATER_MARKER) {
>>>>>>> 529 // Cancelled the in-progress async deflation. We bump
>>>>>>> contentions an
>>>>>>> 530 // extra time to prevent the async deflater thread from
>>>>>>> temporarily
>>>>>>> 531 // changing it to -max_jint and back to zero (no flicker
>>>>>>> to confuse
>>>>>>> 532 // is_being_async_deflated()). The async deflater thread
>>>>>>> will
>>>>>>> 533 // decrement contentions after it recognizes that the async
>>>>>>> 534 // deflation was cancelled.
>>>>>>> 535 add_to_contentions(1);
>>>>>> This part of the new comment:
>>>>>>
>>>>>> 532 // ... The async deflater thread will
>>>>>> 533 // decrement contentions after it recognizes that
>>>>>> the async
>>>>>> 534 // deflation was cancelled.
>>>>>>
>>>>>> makes it clear that the async deflater thread does the
>>>>>> corresponding decrement
>>>>>> to the increment done by the T-enter thread so that covers
>>>>>> this part of your
>>>>>> comment above:
>>>>>>
>>>>>> the _contention field can only be set to 0 by a
>>>>>> corresponding decrement
>>>>>> in the async deflater thread
>>>>>>
>>>>>> This part of the new comment:
>>>>>>
>>>>>> 529 // ... We bump contentions an
>>>>>> 530 // extra time to prevent the async deflater thread
>>>>>> from temporarily
>>>>>> 531 // changing it to -max_jint and back to zero (no
>>>>>> flicker to confuse
>>>>>> 532 // is_being_async_deflated()).
>>>>>>
>>>>>> makes it clear that we're keeping make-contentions-negative
>>>>>> part of the
>>>>>> async deflation protocol from happening so that covers this
>>>>>> part of your
>>>>>> comment above:
>>>>>>
>>>>>> ensuring that the Atomic::cmpxchg(&mid->_contentions,
>>>>>> (jint)0, -max_jint)
>>>>>> on line 2166 fails.
>>>>>>
>>>>>> This part of your comment above makes it clear where the
>>>>>> confusion arises:
>>>>>>
>>>>>> confused me as after the deflater thread sets
>>>>>> _contentions to -max_jint,
>>>>>> the deflater thread has won the race and the object
>>>>>> monitor is about to
>>>>>> be deflated.
>>>>>>
>>>>>> Your original algorithm is a three-part async deflation protocol:
>>>>>>
>>>>>> Part 1 - set owner field to DEFLATER marker
>>>>>> Part 2 - make a zero contentions field -max_jint
>>>>>> Part 3 - check to see if the owner field is still DEFLATER_MARKER
>>>>>>
>>>>>> If part 3 fails, then the contentions field that is currently
>>>>>> negative
>>>>>> has max_jint added to it to complete the bail out process.
>>>>>> It's that
>>>>>> third part that makes the contentions field flicker from:
>>>>>>
>>>>>> 0 -> -max_jint -> 0
>>>>>>
>>>>>> And the extra contentions increment in the new two part
>>>>>> protocol solves
>>>>>> that flicker and allows us to treat (contentions < 0) as a
>>>>>> linearization
>>>>>> point.
>>>>>>
>>>>>> Please let me know if this clarifies your concern.
>>>>>>
>>>>>>
>>>>>> I am no longer confused, but the cause of my confusion is still
>>>>>> present in the comment.
>>>>>>
>>>>>> This group knows about the three part algorithm, but when the
>>>>>> code is pushed there is no representation of the three part
>>>>>> algorithm in the code or repository.
>>>>> That's a really good point and a side effect of my living with this
>>>>> code for a very long time...
>>>>>
>>>>>
>>>>>> I forgot the details of the algorithm and read the latest version
>>>>>> of the code to figure out what the flickering was about. As you
>>>>>> would expect, I found that there is no way the code can cause the
>>>>>> flicker mentioned. That made me worried. I started to question
>>>>>> myself: What can cause the behavior that is described in the
>>>>>> comments? What am I missing? As a result, I think it is best if
>>>>>> we keep the flickering to ourselves and update the comment to
>>>>>> describe that because _owner was DEFLATER_MARKER the deflation
>>>>>> thread must be in the middle of the protocol for deflating the
>>>>>> object monitor, and in particular, incrementing _contentions
>>>>>> ensures the failure of the final CAS in the deflation protocol
>>>>>> (final in the protocol implemented in the code).
>>>>> The above is a more clear expression of your concerns and I agree.
>>>>>
>>>>>
>>>>>> To be clear:
>>>>>>
>>>>>> > 529 // Cancelled the in-progress async deflation.
>>>>>>
>>>>>> I would expend this comment by mentioning that the deflator
>>>>>> thread cannot win the last part of the 2-part deflation protocol
>>>>>> as 0 < _contentions (pre-condition to this method).
>>>>>>
>>>>>> > We bump contentions an
>>>>>> > 530 // extra time to prevent the async deflater thread from
>>>>>> temporarily
>>>>>> > 531 // changing it to -max_jint and back to zero (no flicker to
>>>>>> confuse
>>>>>> > 532 // is_being_async_deflated()).
>>>>>>
>>>>>> I would replace this part with something along the lines of: We
>>>>>> bump contentions an extra time to prevent the deflator thread
>>>>>> from winning the last part of the (2-part) deflation protocol
>>>>>> after this thread decrements _contentions as part of the release
>>>>>> of the object monitor.
>>>>>>
>>>>>> > The async deflater thread will
>>>>>> > 533 // decrement contentions after it recognizes that the async
>>>>>> > 534 // deflation was cancelled.
>>>>>>
>>>>>> I would keep this part.
>>>>> So here's my rewrite of the code and comment block:
>>>>>
>>>>> if (AsyncDeflateIdleMonitors &&
>>>>> try_set_owner_from(DEFLATER_MARKER, Self) ==
>>>> DEFLATER_MARKER) {
>>>>> // Cancelled the in-progress async deflation by changing owner
>>>>> from
>>>>> // DEFLATER_MARKER to Self. As part of the contended enter
>>>>> protocol,
>>>>> // contentions was incremented to a positive value before EnterI()
>>>>> // was called and that prevents the deflater thread from
>>>>> winning the
>>>>> // last part of the 2-part async deflation protocol. After
>>>>> EnterI()
>>>>> // returns to enter(), contentions is decremented because the
>>>>> caller
>>>>> // now owns the monitor. We bump contentions an extra time here
>> to
>>>>> // prevent the deflater thread from winning the last part of the
>>>>> // 2-part async deflation protocol after the regular decrement
>>>>> // occurs in enter(). The deflater thread will decrement
>>>>> contentions
>>>>> // after it recognizes that the async deflation was cancelled.
>>>>> add_to_contentions(1);
>>>>>
>>>>> I've made this change to both places in EnterI() that had the original
>>>>> confusing comment.
>>>>>
>>>>> Please let me know if this rewrite works for everyone.
>>>>>
>>>>> Since I've already pushed 8153224, I'll file a new bug to push this
>>>>> clarification once we're all in agreement here.
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>>> I hope this helps,
>>>>>> Carsten
>>>>>>
>>>>>>> Otherwise, the code looks great. I am looking forward to
>>>>>>> seeing in the repo.
>>>>>> Thanks! The code should be there soon.
>>>>>>
>>>>>> Dan
>>>>>>
>>>>>>
>>>>>>> Carsten
>>>>>>>
>>>>>>> On Mon, Jun 1, 2020 at 8:32 PM Daniel D. Daugherty
>>>>>>> <daniel.daugherty at oracle.com
>>>>>>> <mailto:daniel.daugherty at oracle.com>> wrote:
>>>>>>>
>>>>>>> Hi David,
>>>>>>>
>>>>>>> On 6/1/20 7:58 PM, David Holmes wrote:
>>>>>>> > Hi Dan,
>>>>>>> >
>>>>>>> > Sorry for the delay.
>>>>>>>
>>>>>>> No worries. It's always worth waiting for your code
>>>>>>> review in general
>>>>>>> and, with the complexity of this project, it's on my
>>>>>>> must-do list!
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> > On 28/05/2020 3:20 am, Daniel D. Daugherty 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/
>>>>>>> >
>>>>>>> >
>>>>>>> > src/hotspot/share/runtime/synchronizer.cpp
>>>>>>> >
>>>>>>> > I'm having a little trouble keeping the _contentions
>>>>>>> relationships in
>>>>>>> > my head. In particular with this change I can't quite
>>>>>>> grok the:
>>>>>>> >
>>>>>>> > // Deferred decrement for the JT EnterI() that
>>>>>>> cancelled the async
>>>>>>> > deflation.
>>>>>>> > mid->add_to_contentions(-1);
>>>>>>> >
>>>>>>> > change. I kind of get EnterI() does an extra increment
>>>>>>> and the
>>>>>>> > deflator thread does the above matching decrement. But
>>>>>>> given the two
>>>>>>> > changes can happen in any order I'm not sure what the
>>>>>>> possible visible
>>>>>>> > values for _contentions will be and how that might
>>>>>>> affect other code
>>>>>>> > inspecting it?
>>>>>>>
>>>>>>> I have a sub-section in the OpenJDK wiki dedicated to
>>>>>>> this particular race:
>>>>>>>
>>>>>>>
>> https://wiki.openjdk.java.net/display/HotSpot/Async+Monitor+Deflation#A
>>>> syncMonitorDeflation-T-
>>>> enterWinsByCancellationViaDEFLATER_MARKERSwap
>>>>>>> In order for this race condition to manifest, the
>>>>>>> T-enter thread has to
>>>>>>> successfully swap the owner field's DEFLATER_MARKER
>>>>>>> value for Self. That
>>>>>>> swap will eventually cause the T-deflate thread to
>>>>>>> realize that the async
>>>>>>> deflation that it started has been canceled.
>>>>>>>
>>>>>>> The diagram shows the progression of contentions values:
>>>>>>>
>>>>>>> - ObjectMonitor box 1 shows contentions == 1 because
>>>>>>> T-enter incremented
>>>>>>> the contentions field
>>>>>>>
>>>>>>> - ObjectMonitor box 2 shows contentions == 2 because
>>>>>>> EnterI() did the
>>>>>>> extra increment.
>>>>>>>
>>>>>>> - ObjectMonitor box 3 shows contentions == 1 because
>>>>>>> T-enter did the
>>>>>>> regular contentions decrement.
>>>>>>>
>>>>>>> - ObjectMonitor box 4 shows contentions == 0 because
>>>>>>> T-deflate did the
>>>>>>> extra contentions decrement.
>>>>>>>
>>>>>>> Now it is possible for T-deflate to do the extra
>>>>>>> decrement before T-enter
>>>>>>> does the extra increment. If I were to add another
>>>>>>> diagram to show that
>>>>>>> variant of the race, that progression of contentions
>>>>>>> values would be:
>>>>>>>
>>>>>>> - ObjectMonitor box 1 shows contentions == 1 because
>>>>>>> T-enter incremented
>>>>>>> the contentions field
>>>>>>>
>>>>>>> - ObjectMonitor box 2 shows contentions == 0 because
>>>>>>> T-deflate did the
>>>>>>> extra contentions decrement.
>>>>>>>
>>>>>>> - ObjectMonitor box 3 shows contentions == 1 because
>>>>>>> EnterI() did the
>>>>>>> extra increment.
>>>>>>>
>>>>>>> - ObjectMonitor box 4 shows contentions == 0 because
>>>>>>> T-enter did the
>>>>>>> regular contentions decrement.
>>>>>>>
>>>>>>> Notice that in this second scenario the contentions
>>>>>>> field never goes
>>>>>>> negative so there's nothing to confuse a potential caller of
>>>>>>> is_being_async_deflated():
>>>>>>>
>>>>>>> inline bool ObjectMonitor::is_being_async_deflated() {
>>>>>>> return AsyncDeflateIdleMonitors && contentions() < 0;
>>>>>>> }
>>>>>>>
>>>>>>> It is not possible for T-deflate's extra decrement of
>>>>>>> the contentions
>>>>>>> field to make the contentions field negative. That
>>>>>>> decrement only happens
>>>>>>> when T-deflate detects that the async deflation has been
>>>>>>> canceled and
>>>>>>> async deflation can only be canceled after T-enter has
>>>>>>> already made the
>>>>>>> contentions field > 0.
>>>>>>>
>>>>>>> Please let me know if this resolves your concern about:
>>>>>>>
>>>>>>> > // Deferred decrement for the JT EnterI() that
>>>>>>> cancelled the async
>>>>>>> > deflation.
>>>>>>> > mid->add_to_contentions(-1);
>>>>>>>
>>>>>>> I'm not planning to update the OpenJDK wiki to add a
>>>>>>> second variant of
>>>>>>> the cancellation race. Please let me know if that is okay.
>>>>>>>
>>>>>>> >
>>>>>>> > But otherwise the changes in this version seem good
>>>>>>> and overall the
>>>>>>> > protocol seems simpler.
>>>>>>>
>>>>>>> This sounds like a thumbs up, but I'm looking for
>>>>>>> something more definitive.
>>>>>>>
>>>>>>>
>>>>>>> > I'm still going to spend some more time going over the
>>>>>>> complete webrev
>>>>>>> > to get a fuller sense of things.
>>>>>>>
>>>>>>> As always, if you find something after I've pushed,
>>>>>>> we'll deal with it.
>>>>>>>
>>>>>>> Thanks for your many re-reviews for this project!!
>>>>>>>
>>>>>>> Dan
>>>>>>>
>>>>>>>
>>>>>>> >
>>>>>>> > Thanks,
>>>>>>> > David
>>>>>>> >
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> 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.
>>>>>>> >>>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>>
>>>>>>> >>>>>>>>>>>
>>>>>>> >>>>>>>>>>
>>>>>>> >>>>>>>>>
>>>>>>> >>>>>>>>
>>>>>>> >>>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>
>>>>>>> >>>>
>>>>>>> >>>
>>>>>>> >>
>>>>>>>
More information about the hotspot-runtime-dev
mailing list