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

[Doerr, Martin]

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/12b56e3c/attachment.htm>