<html><body><p><font size="2">Hi Thomas,</font><br><br><font size="2">Thank you for telling that some people get a problem in handle_evacuation_failure.</font><br><br><font size="2">The handle_evacuation_failure is invoked from copy_to_survivor_space and also keeps the following two:</font><ul type="disc"><li><font size="2">There is no copy that must finish before the CAS.</font><li><font size="2">Threads that failed in the CAS must not dereference the forwardee.</font></ul><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__=8FBB0839DFD1ED958f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Thomas Schatzl ---2018/06/12 20:26:54---Hi, On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:"><font size="2" color="#424282">Thomas Schatzl ---2018/06/12 20:26:54---Hi, On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Thomas Schatzl <thomas.schatzl@oracle.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Michihiro Horie <HORIE@jp.ibm.com>, "Doerr, Martin" <martin.doerr@sap.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"david.holmes@oracle.com" <david.holmes@oracle.com>, "hotspot-gc-dev@openjdk.java.net" <hotspot-gc-dev@openjdk.java.net></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2018/06/12 20:26</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">Hi,<br><br>On Tue, 2018-06-12 at 20:18 +0900, Michihiro Horie wrote:<br>> Hi Martin,<br>> <br>> Thank you for your comments. Yes, this change is significant on PPC64<br>> as I showed a big improvement in SPECjbb2015 (27% better critical-<br>> jOPS).<br>> <br>> Changing the handle_evacuation_failure_par is not necessary. I could<br>> not observe the performance bottleneck in<br>> handle_evacuation_failure_par from the profiles,<br>> <br>> New webrev: </font></tt><tt><font size="2"><a href="http://cr.openjdk.java.net/~mhorie/8204524/webrev.01/">http://cr.openjdk.java.net/~mhorie/8204524/webrev.01/</a></font></tt><tt><font size="2"><br>> <br><br> of course handle_evacuation_failure_par() will not show up in the<br>profiles if there is no evacuation failure.<br><br>However during evacuation failure, this method will be stressed a lot.<br><br>While from the outside it might not look like it is worth optimizing,<br>lack of performance in evacuation failure has been a rather often<br>voiced complaint (for the users where this occurs).<br><br>This is only a side remark: I have not looked through the code for<br>issues due to relaxing memory order recently, but I remember having<br>done so when the similar change for parallel gc had been proposed last<br>year.<br>I remember that Michihiro's reasoning why this works for G1 the way it<br>does is sound, but as mentioned please wait for a proper review.<br><br>Thanks,<br> Thomas<br><br><br></font></tt><br><BR>
</body></html>