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

[Michihiro Horie]

Hi Derek, Kim,

I agree Derek’s further report on an unexpected performance regression is
needed. I would like to know the root cause if any.

Just for reference, we once measured the copy_to_survivor_space change in
ParallelGC (JDK-8154736) with Cavium ThunderX ARMv8 (2.0GHz, 38 cores, 1
SMT for each core). There was no performance regression in SPECjbb2015.


Best regards,
--
Michihiro,
IBM Research - Tokyo



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



> 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/20180614/1c296c6a/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/20180614/1c296c6a/graycol.gif>