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