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

[Michihiro Horie]

Hi Martin,

Thank you for your comments. Yes, this change is significant on PPC64 as I
showed a big improvement in SPECjbb2015 (27% better critical-jOPS).

Changing the handle_evacuation_failure_par is not necessary. I could not
observe the performance bottleneck in handle_evacuation_failure_par from
the profiles,

New webrev: http://cr.openjdk.java.net/~mhorie/8204524/webrev.01/


Best regards,
--
Michihiro,
IBM Research - Tokyo



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



Hi Michihiro,

I have removed the mailing lists except hotspot-gc-dev which is the one for
this review.

Thank you for taking care of this PPC64 performance problem. I think we
shouldn’t ship jdk11 on PPC64 without addressing it.

I guess handle_evacuation_failure_par is not performance critical, so I
wonder if it needs to be part of this change. I haven’t checked if it’s
correct.

Your description and change of copy_to_survivor_space fit to the comments
and how the algorithm works. So it looks good to me.
I couldn’t find any requirement for memory barriers regarding the CAS. But
we should have a G1 expert double-check that we haven’t missed anything.

Best regards,
Martin


From: Michihiro Horie [mailto:HORIE at jp.ibm.com]
Sent: Donnerstag, 7. Juni 2018 08:01
To: hotspot-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net;
hotspot-gc-dev at openjdk.java.net
Cc: Kim Barrett <kim.barrett at oracle.com>; Gustavo Bueno Romero
<gromero at br.ibm.com>; david.holmes at oracle.com; Erik Osterlund
<erik.osterlund at oracle.com>; Doerr, Martin <martin.doerr at sap.com>
Subject: RFR(M): 8204524: Unnecessary memory barriers in
G1ParScanThreadState::copy_to_survivor_space



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

G1ParScanThreadState::copy_to_survivor_space tries to move live objects to
a different location. It uses a forwarding technique and allows multiple
threads to compete for performing the copy step.

A copy is performed after a thread succeeds in the CAS. CAS-failed threads
are not allowed to dereference the forwardee concurrently. Current code is
already written so that CAS-failed threads do not dereference the
forwardee. Also, this constraint is documented in a caller function
mark_forwarded_object as “the object might be in the process of being
copied by another worker so we cannot trust that its to-space image is
well-formed”.
      There is no copy that must finish before the CAS.
      Threads that failed in the CAS must not dereference the forwardee.

Therefore, no fence is necessary before and after the CAS.

I measured SPECjbb2015 with this change. As a result, critical-jOPS
performance improved by 27% on POWER8.


Best regards,
--
Michihiro,
IBM Research - Tokyo
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-gc-dev/attachments/20180612/1af74a4f/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/20180612/1af74a4f/graycol.gif>