RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space

Wed Jun 20 11:41:44 UTC 2018

Hi Martin, Kim, all,

> I assume webrev.00 was used for reviews and tests as Thomas has
emphasized that evacuation failures may be performance critical, too. It
looks correct to me, too.
>
> I can sponsor the change if needed. Please let me know when I can
consider it reviewed.

Thanks a lot for sponsoring the change, Martin. Yes, webrev.00 is the one
used for the review:
http://cr.openjdk.java.net/~mhorie/8204524/webrev.00/

I think Kim would review the change because Derek concluded there is a
moderate performance gain in SPECjbb on AArch64. Kim, would you agree with
this change?

> I was going to say that this looks good to me.
>
> But then I saw Derek White’s reply about an unexpected performance
regression.
> I’d like to wait until he reports back.

Best regards,
--
Michihiro,
IBM Research - Tokyo

From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Michihiro Horie <HORIE at jp.ibm.com>, "White, Derek"
            <Derek.White at cavium.com>
Cc:	"david.holmes at oracle.com" <david.holmes at oracle.com>, Gustavo
            Bueno Romero <gromero at br.ibm.com>,
            "hotspot-gc-dev at openjdk.java.net"
            <hotspot-gc-dev at openjdk.java.net>, Kim Barrett
            <kim.barrett at oracle.com>
Date:	2018/06/19 05:28
Subject:	RE: RFR(M): 8204524: Unnecessary memory barriers in
            G1ParScanThreadState::copy_to_survivor_space

Hi,

I assume webrev.00 was used for reviews and tests as Thomas has emphasized
that evacuation failures may be performance critical, too. It looks correct
to me, too.

I can sponsor the change if needed. Please let me know when I can consider
it reviewed.

Best regards,
Martin

From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Dienstag, 19. Juni 2018 00:19
To: White, Derek <Derek.White at cavium.com>
Cc: david.holmes at oracle.com; Gustavo Bueno Romero <gromero at br.ibm.com>;
hotspot-gc-dev at openjdk.java.net; Kim Barrett <kim.barrett at oracle.com>;
Doerr, Martin <martin.doerr at sap.com>
Subject: RE: RFR(M): 8204524: Unnecessary memory barriers in
G1ParScanThreadState::copy_to_survivor_space

Hi Derek,

Thank you for the investigation on AArch64. It would be very helpful and I
am glad to know that you had a moderate performance gain with this G1
change.

Best regards,
--
Michihiro,
IBM Research - Tokyo

Inactive hide details for "White, Derek" ---2018/06/18 17:57:58---Hi
Michihiro, Further testing is showing a moderate performan"White, Derek"
---2018/06/18 17:57:58---Hi Michihiro, Further testing is showing a
moderate performance gain with your G1 patch in SPECjbb o

From: "White, Derek" <Derek.White at cavium.com>
To: Michihiro Horie <HORIE at jp.ibm.com>
Cc: "david.holmes at oracle.com" <david.holmes at oracle.com>, Gustavo Bueno
Romero <gromero at br.ibm.com>, "hotspot-gc-dev at openjdk.java.net" <
hotspot-gc-dev at openjdk.java.net>, Kim Barrett <kim.barrett at oracle.com>,
"Doerr, Martin" <martin.doerr at sap.com>
Date: 2018/06/18 17:57
Subject: RE: RFR(M): 8204524: Unnecessary memory barriers in
G1ParScanThreadState::copy_to_survivor_space

Hi Michihiro,

Further testing is showing a moderate performance gain with your G1 patch
in SPECjbb on AArch64. We haven’t completely pinned the earlier regression
on user error on our part, but it’s looking likely. The new code on AArch64
is looking as relaxed as can be ?

Thank you for working on this, and letting us investigate!
      Derek

From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Friday, June 15, 2018 11:44 PM
To: White, Derek <Derek.White at cavium.com>
Cc: david.holmes at oracle.com; Gustavo Bueno Romero <gromero at br.ibm.com>;
hotspot-gc-dev at openjdk.java.net; Kim Barrett <kim.barrett at oracle.com>;
Doerr, Martin <martin.doerr at sap.com>
Subject: RE: RFR(M): 8204524: Unnecessary memory barriers in
G1ParScanThreadState::copy_to_survivor_space

Hi Derek,

Thank you for sharing your status of still having inconsistent results with
the patch. I would wait for your updates.

Thanks again,

Best regards,
--
Michihiro,
IBM Research - Tokyo

Inactive hide details for "White, Derek" ---2018/06/15 17:55:19---Hi
Michihiro, Status update:"White, Derek" ---2018/06/15 17:55:19---Hi
Michihiro, Status update:

From: "White, Derek" <Derek.White at cavium.com>
To: Kim Barrett <kim.barrett at oracle.com>, Michihiro Horie <HORIE at jp.ibm.com
>
Cc: Gustavo Bueno Romero <gromero at br.ibm.com>, "david.holmes at oracle.com" <
david.holmes at oracle.com>, "hotspot-gc-dev at openjdk.java.net" <
hotspot-gc-dev at openjdk.java.net>
Date: 2018/06/15 17:55
Subject: RE: RFR(M): 8204524: Unnecessary memory barriers in
G1ParScanThreadState::copy_to_survivor_space

Hi Michihiro,

Status update:
My colleague and I are getting inconsistent results with this patch: -23%
to +7% on SPECjbb, so we're trying to verify what's going on.

On an unrelated note, the aarch64 port relies on GCC's
__atomic_compare_exchange to implemented the relaxed case of
Atomic::PlatformCmpxchg, and gcc 6 and earlier sometimes do a poor job on
it. Not enough to account for the numbers we saw though.

I hope to have an answer by Monday.

- Derek

> -----Original Message-----
> From: hotspot-gc-dev [mailto:hotspot-gc-dev-bounces at openjdk.java.net]
> On Behalf Of Kim Barrett
> Sent: Wednesday, June 13, 2018 5:16 PM
> To: Michihiro Horie <HORIE at jp.ibm.com>
> Cc: Gustavo Bueno Romero <gromero at br.ibm.com>;
> david.holmes at oracle.com; hotspot-gc-dev at openjdk.java.net
> Subject: Re: RFR(M): 8204524: Unnecessary memory barriers in
> G1ParScanThreadState::copy_to_survivor_space
>
> External Email
>
> > On Jun 7, 2018, at 2:01 AM, Michihiro Horie <HORIE at jp.ibm.com> wrote:
> >
> > Dear all,
> >
> > Would you please review the following change?
> >
> > Bug: https://bugs.openjdk.java.net/browse/JDK-8204524
> > Webrev: http://cr.openjdk.java.net/~mhorie/8204524/webrev.00
>
> I was going to say that this looks good to me.
>
> But then I saw Derek White’s reply about an unexpected performance
> regression.
> I’d like to wait until he reports back.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180620/e04c233e/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180620/e04c233e/graycol.gif>