RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space
White, Derek
Derek.White at cavium.com
Fri Jun 15 22:55:07 UTC 2018
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.
More information about the hotspot-gc-dev
mailing list