RFR(L) 8153224 Monitor deflation prolong safepoints (CR14/v2.14/17-for-jdk15)
Doerr, Martin
martin.doerr at sap.com
Tue Sep 15 16:32:20 UTC 2020
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