<html><body><p><font size="2" color="#2F2F2F">Hi Martin</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> Kim</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> all</font><font size="2" color="#2F2F2F">,</font><br><br><font size="2" color="#2F2F2F">> I assume webrev.00 was used for reviews and tests as Thomas has emphasized that evacuation failures may be performance critical</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> too. It looks correct to me</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> too.</font><br><font size="2" color="#2F2F2F">> </font><br><font size="2" color="#2F2F2F">> I can sponsor the change if needed. Please let me know when I can consider it reviewed.</font><br><br><font size="2" color="#2F2F2F">Thanks a lot</font><font size="2" color="#2F2F2F"> for sponsoring the change,</font><font size="2" color="#2F2F2F"> Martin. Yes</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> webrev.00 is the one used for the review:</font><br><a href="http://cr.openjdk.java.net/~mhorie/8204524/webrev.00/"><font size="2" color="#BFBF00">http://cr.openjdk.java.net/~mhorie/8204524/webrev.00/</font></a><br><br><font size="2" color="#2F2F2F">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?</font><br><br><font size="2" color="#2F2F2F">> I was going to say that this looks good to me.</font><br><font size="2" color="#2F2F2F">> </font><br><font size="2" color="#2F2F2F">> But then I saw Derek White</font><font size="2" color="#2F2F2F">’</font><font size="2" color="#2F2F2F">s reply about an unexpected performance regression.</font><br><font size="2" color="#2F2F2F">> I</font><font size="2" color="#2F2F2F">’</font><font size="2" color="#2F2F2F">d like to wait until he reports back.</font><br><br><br><font size="2">Best regards,</font><br><font size="2">--</font><br><font size="2">Michihiro,</font><br><font size="2">IBM Research - Tokyo</font><br><br><img width="16" height="16" src="cid:1__=8FBB0821DFADE2328f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Doerr, Martin" ---2018/06/19 05:28:01---Hi, I assume webrev.00 was used for reviews and tests as Tho"><font size="2" color="#424282">"Doerr, Martin" ---2018/06/19 05:28:01---Hi, I assume webrev.00 was used for reviews and tests as Thomas has emphasized that evacuation failu</font><br><br><font size="2" color="#5F5F5F">From:        </font><font size="2">"Doerr, Martin" <martin.doerr@sap.com></font><br><font size="2" color="#5F5F5F">To:        </font><font size="2">Michihiro Horie <HORIE@jp.ibm.com>, "White, Derek" <Derek.White@cavium.com></font><br><font size="2" color="#5F5F5F">Cc:        </font><font size="2">"david.holmes@oracle.com" <david.holmes@oracle.com>, Gustavo Bueno Romero <gromero@br.ibm.com>, "hotspot-gc-dev@openjdk.java.net" <hotspot-gc-dev@openjdk.java.net>, Kim Barrett <kim.barrett@oracle.com></font><br><font size="2" color="#5F5F5F">Date:        </font><font size="2">2018/06/19 05:28</font><br><font size="2" color="#5F5F5F">Subject:        </font><font size="2">RE: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br>Hi,<br> <br>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.<br> <br>I can sponsor the change if needed. Please let me know when I can consider it reviewed.<br> <br>Best regards,<br>Martin<br> <br> <br><b>From:</b> Michihiro Horie [<a href="mailto:HORIE@jp.ibm.com">mailto:HORIE@jp.ibm.com</a>] <b><br>Sent:</b> Dienstag, 19. Juni 2018 00:19<b><br>To:</b> White, Derek <Derek.White@cavium.com><b><br>Cc:</b> david.holmes@oracle.com; Gustavo Bueno Romero <gromero@br.ibm.com>; hotspot-gc-dev@openjdk.java.net; Kim Barrett <kim.barrett@oracle.com>; Doerr, Martin <martin.doerr@sap.com><b><br>Subject:</b> RE: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space<br> 

<font size="2">Hi Derek, <font size="2"> 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. <font size="2"> Best regards, -- Michihiro, IBM Research - Tokyo <img src="cid:1__=8FBB0821DFADE2328f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive hide details for "White, Derek" ---2018/06/18 17:57:58---Hi Michihiro, Further testing is showing a moderate performan"><font size="2" color="#424282">"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 <font size="2" color="#5F5F5F"> From: <font size="2">"White, Derek" <<a href="mailto:Derek.White@cavium.com"><font size="2" color="#0000FF">Derek.White@cavium.com</a><font size="2">><font size="2" color="#5F5F5F"> To: <font size="2">Michihiro Horie <<a href="mailto:HORIE@jp.ibm.com"><font size="2" color="#0000FF">HORIE@jp.ibm.com</a><font size="2">><font size="2" color="#5F5F5F"> Cc: <font size="2">"<a href="mailto:david.holmes@oracle.com"><font size="2" color="#0000FF">david.holmes@oracle.com</a><font size="2">" <<a href="mailto:david.holmes@oracle.com"><font size="2" color="#0000FF">david.holmes@oracle.com</a><font size="2">>, Gustavo Bueno Romero <<a href="mailto:gromero@br.ibm.com"><font size="2" color="#0000FF">gromero@br.ibm.com</a><font size="2">>, "<a href="mailto:hotspot-gc-dev@openjdk.java.net"><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</a><font size="2">" <<a href="mailto:hotspot-gc-dev@openjdk.java.net"><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</a><font size="2">>, Kim Barrett <<a href="mailto:kim.barrett@oracle.com"><font size="2" color="#0000FF">kim.barrett@oracle.com</a><font size="2">>, "Doerr, Martin" <<a href="mailto:martin.doerr@sap.com"><font size="2" color="#0000FF">martin.doerr@sap.com</a><font size="2">><font size="2" color="#5F5F5F"> Date: <font size="2">2018/06/18 17:57<font size="2" color="#5F5F5F"> Subject: <font size="2">RE: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space <hr width="100%" size="2" align="left" noshade style="color:#000000; "> 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!

<ul><ul type="disc"><li>Derek</ul></ul><b><br>From:</b> Michihiro Horie [<a href="mailto:HORIE@jp.ibm.com"><u><font color="#0000FF">mailto:HORIE@jp.ibm.com</font></u></a>] <b><br>Sent:</b> Friday, June 15, 2018 11:44 PM<b><br>To:</b> White, Derek <<a href="mailto:Derek.White@cavium.com"><u><font color="#0000FF">Derek.White@cavium.com</font></u></a>><b><br>Cc:</b> <a href="mailto:david.holmes@oracle.com"><u><font color="#0000FF">david.holmes@oracle.com</font></u></a>; Gustavo Bueno Romero <<a href="mailto:gromero@br.ibm.com"><u><font color="#0000FF">gromero@br.ibm.com</font></u></a>>; <a href="mailto:hotspot-gc-dev@openjdk.java.net"><u><font color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></a>; Kim Barrett <<a href="mailto:kim.barrett@oracle.com"><u><font color="#0000FF">kim.barrett@oracle.com</font></u></a>>; Doerr, Martin <<a href="mailto:martin.doerr@sap.com"><u><font color="#0000FF">martin.doerr@sap.com</font></u></a>><b><br>Subject:</b> RE: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space 

<p><font size="2" color="#2F2F2F">Hi Derek,<br><br>Thank you for sharing your status of still having inconsistent results with the patch. I would wait for your updates.<br><br>Thanks again,</font><br><font size="2"><br><br>Best regards,<br>--<br>Michihiro,<br>IBM Research - Tokyo</font><br><br><img src="cid:1__=8FBB0821DFADE2328f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive hide details for "White, Derek" ---2018/06/15 17:55:19---Hi Michihiro, Status update:"><font size="2" color="#424282">"White, Derek" ---2018/06/15 17:55:19---Hi Michihiro, Status update:</font><font size="2" color="#5F5F5F"><br><br>From: </font><font size="2">"White, Derek" <</font><a href="mailto:Derek.White@cavium.com"><u><font size="2" color="#0000FF">Derek.White@cavium.com</font></u></a><font size="2">></font><font size="2" color="#5F5F5F"><br>To: </font><font size="2">Kim Barrett <</font><a href="mailto:kim.barrett@oracle.com"><u><font size="2" color="#0000FF">kim.barrett@oracle.com</font></u></a><font size="2">>, Michihiro Horie <</font><a href="mailto:HORIE@jp.ibm.com"><u><font size="2" color="#0000FF">HORIE@jp.ibm.com</font></u></a><font size="2">></font><font size="2" color="#5F5F5F"><br>Cc: </font><font size="2">Gustavo Bueno Romero <</font><a href="mailto:gromero@br.ibm.com"><u><font size="2" color="#0000FF">gromero@br.ibm.com</font></u></a><font size="2">>, "</font><a href="mailto:david.holmes@oracle.com"><u><font size="2" color="#0000FF">david.holmes@oracle.com</font></u></a><font size="2">" <</font><a href="mailto:david.holmes@oracle.com"><u><font size="2" color="#0000FF">david.holmes@oracle.com</font></u></a><font size="2">>, "</font><a href="mailto:hotspot-gc-dev@openjdk.java.net"><u><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></a><font size="2">" <</font><a href="mailto:hotspot-gc-dev@openjdk.java.net"><u><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></a><font size="2">></font><font size="2" color="#5F5F5F"><br>Date: </font><font size="2">2018/06/15 17:55</font><font size="2" color="#5F5F5F"><br>Subject: </font><font size="2">RE: RFR(M): 8204524: Unnecessary memory barriers in G1ParScanThreadState::copy_to_survivor_space</font><br><hr width="100%" size="2" align="left" noshade style="color:#000000; "><br><br><br><font size="2"><br><br>Hi Michihiro,<br><br>Status update:<br>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.<br><br>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.<br><br>I hope to have an answer by Monday.<br><br>- Derek<br><br>> -----Original Message-----<br>> From: hotspot-gc-dev [</font><a href="mailto:hotspot-gc-dev-bounces@openjdk.java.net"><u><font size="2" color="#0000FF">mailto:hotspot-gc-dev-bounces@openjdk.java.net</font></u></a><font size="2">]<br>> On Behalf Of Kim Barrett<br>> Sent: Wednesday, June 13, 2018 5:16 PM<br>> To: Michihiro Horie <</font><a href="mailto:HORIE@jp.ibm.com"><u><font size="2" color="#0000FF">HORIE@jp.ibm.com</font></u></a><font size="2">><br>> Cc: Gustavo Bueno Romero <</font><a href="mailto:gromero@br.ibm.com"><u><font size="2" color="#0000FF">gromero@br.ibm.com</font></u></a><font size="2">>;<br>> </font><a href="mailto:david.holmes@oracle.com"><u><font size="2" color="#0000FF">david.holmes@oracle.com</font></u></a><font size="2">; </font><a href="mailto:hotspot-gc-dev@openjdk.java.net"><u><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></a><font size="2"><br>> Subject: Re: RFR(M): 8204524: Unnecessary memory barriers in<br>> G1ParScanThreadState::copy_to_survivor_space<br>> <br>> External Email<br>> <br>> > On Jun 7, 2018, at 2:01 AM, Michihiro Horie <</font><a href="mailto:HORIE@jp.ibm.com"><u><font size="2" color="#0000FF">HORIE@jp.ibm.com</font></u></a><font size="2">> wrote:<br>> ><br>> > Dear all,<br>> ><br>> > Would you please review the following change?<br>> ><br>> > Bug: </font><a href="https://bugs.openjdk.java.net/browse/JDK-8204524"><u><font size="2" color="#0000FF">https://bugs.openjdk.java.net/browse/JDK-8204524</font></u></a><font size="2"><br>> > Webrev: </font><a href="http://cr.openjdk.java.net/~mhorie/8204524/webrev.00"><u><font size="2" color="#0000FF">http://cr.openjdk.java.net/~mhorie/8204524/webrev.00</font></u></a><font size="2"><br>> <br>> I was going to say that this looks good to me.<br>> <br>> But then I saw Derek White’s reply about an unexpected performance<br>> regression.<br>> I’d like to wait until he reports back.<br></font><br><br><br><br><br><br><BR>

</body></html>