<html><body><p><font size="2" color="#2F2F2F">Hi Derek</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> Kim</font><font size="2" color="#2F2F2F">,</font><br><br><font size="2" color="#2F2F2F">I agree Derek</font><font size="2" color="#2F2F2F">’</font><font size="2" color="#2F2F2F">s further report on an unexpected performance regression is needed. I would like to know the root cause if any.</font><br><br><font size="2" color="#2F2F2F">Just for reference</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> we once measured the copy_to_survivor_space change in ParallelGC </font><font size="2" color="#2F2F2F">(</font><font size="2" color="#2F2F2F">JDK-8154736</font><font size="2" color="#2F2F2F">)</font><font size="2" color="#2F2F2F"> with Cavium ThunderX ARMv8 </font><font size="2" color="#2F2F2F">(</font><font size="2" color="#2F2F2F">2.0GHz</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> 38 cores</font><font size="2" color="#2F2F2F">,</font><font size="2" color="#2F2F2F"> 1 SMT for each core</font><font size="2" color="#2F2F2F">)</font><font size="2" color="#2F2F2F">. There was no performance regression in SPECjbb2015.</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__=8FBB0838DF121D908f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Kim Barrett ---2018/06/14 06:15:49---> On Jun 7, 2018, at 2:01 AM, Michihiro Horie <HORIE@jp.ibm.com>"><font size="2" color="#424282">Kim Barrett ---2018/06/14 06:15:49---> On Jun 7, 2018, at 2:01 AM, Michihiro Horie <HORIE@jp.ibm.com> wrote: ></font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Kim Barrett <kim.barrett@oracle.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Michihiro Horie <HORIE@jp.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"hotspot-gc-dev@openjdk.java.net" <hotspot-gc-dev@openjdk.java.net>, Gustavo Bueno Romero <gromero@br.ibm.com>, "david.holmes@oracle.com" <david.holmes@oracle.com>, Erik Osterlund <erik.osterlund@oracle.com>, "Doerr, Martin" <martin.doerr@sap.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2018/06/14 06:15</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><tt><font size="2">> On Jun 7, 2018, at 2:01 AM, Michihiro Horie <HORIE@jp.ibm.com> wrote:<br>> <br>> Dear all,<br>> <br>> Would you please review the following change?<br>> <br>> Bug: </font></tt><tt><font size="2"><a href="https://bugs.openjdk.java.net/browse/JDK-8204524">https://bugs.openjdk.java.net/browse/JDK-8204524</a></font></tt><tt><font size="2"><br>> Webrev: </font></tt><tt><font size="2"><a href="http://cr.openjdk.java.net/~mhorie/8204524/webrev.00">http://cr.openjdk.java.net/~mhorie/8204524/webrev.00</a></font></tt><tt><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 regression.<br>I’d like to wait until he reports back.<br><br><br></font></tt><br><br><BR>
</body></html>