<html><body><p><font size="2">Hi David,</font><br><br><tt><font size="2">>So the very last comment there was about not implicitly assuming <br>>memory_order_consume, yet that has not been addressed in the proposal.</font></tt><br><font size="2">></font><br><tt><font size="2">>Further the discussion on hotspot-runtime-dev through September and <br>>October was far more illuminating. I think my post here:<br>></font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=</a></font></tt><tt><font size="2"><br>>and the closely following one from Thomas Schatzl summed up the concerns <br>>about the proposed changes.</font></tt><br><font size="2">Thank you very much for pointing out the missing items I need to take into account.</font><br><br><tt><font size="2">>This is a proposal to change the memory ordering semantics of part of <br>>the shared GC code _not_ just the PPC64 implementation, but I have seen <br>>no analysis to demonstrate the correctness of such a proposal.</font></tt><br><font size="2">I do agree the necessity of demonstrating the correctness. I would try my best for this.</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__=8FBB08E8DFD3F7DC8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for David Holmes ---2018/04/25 21:45:28---Hi Michihiro, On 23/04/2018 8:33 PM, Michihiro Horie wrote:"><font size="2" color="#424282">David Holmes ---2018/04/25 21:45:28---Hi Michihiro, On 23/04/2018 8:33 PM, Michihiro Horie wrote:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">David Holmes <david.holmes@oracle.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">Michihiro Horie <HORIE@jp.ibm.com>, ppc-aix-port-dev@openjdk.java.net, hotspot-dev@openjdk.java.net, hotspot-gc-dev@openjdk.java.net</font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">Hiroshi H Horii <HORII@jp.ibm.com></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2018/04/25 21:45</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt><font size="2">Hi Michihiro,<br><br>On 23/04/2018 8:33 PM, Michihiro Horie wrote:<br>> <br>> <br>> Dear all,<br>> <br>> I would like to ask reviews on 8154736 “enhancement of cmpxchg and<br>> copy_to_survivor”. The change adds options to avoid expensive syncs with<br>> compare-and-exchange. An experiment by using SPECjbb2015 showed 6%<br>> improvement in critical-jOPS. This change focuses on ppc64 but would be<br>> potentially beneficial for aarch64.<br>> <br>> Although discussions stopped at<br>> </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002718.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=C2p8l68JKbOLCTpy4Zu5280A84QXht0U4_3Ha7QBaRc&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002718.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=C2p8l68JKbOLCTpy4Zu5280A84QXht0U4_3Ha7QBaRc&e=</a></font></tt><tt><font size="2"><br>> , I would like to restart the review by taking over Hiroshi's work if the<br>> discussion is still open.<br><br>So the very last comment there was about not implicitly assuming <br>memory_order_consume, yet that has not been addressed in the proposal.<br><br>Further the discussion on hotspot-runtime-dev through September and <br>October was far more illuminating. I think my post here:<br><br></font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_hotspot-2Druntime-2Ddev_2016-2DOctober_021617.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4DMMn8KoNrvfjd9HS_nXI5hLeagvDCcmeB6oFd-mcPk&e=</a></font></tt><tt><font size="2"><br><br>and the closely following one from Thomas Schatzl summed up the concerns <br>about the proposed changes.<br><br>AFAICS the restarted proposal addresses none of those concerns but <br>simply takes up where the previous implementation suggestion left off.<br><br>This is a proposal to change the memory ordering semantics of part of <br>the shared GC code _not_ just the PPC64 implementation, but I have seen <br>no analysis to demonstrate the correctness of such a proposal.<br><br>David<br>-----<br><br><br>> Bug: </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8154736&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4hpwVPathLPraOYinkDMNu4gAgivm62zURDtKyMKPe8&e=">https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.openjdk.java.net_browse_JDK-2D8154736&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=4hpwVPathLPraOYinkDMNu4gAgivm62zURDtKyMKPe8&e=</a></font></tt><tt><font size="2"><br>> Webrev: </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8154736_webrev.08_&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=DMMm7IWjNJSRB69AbPfo-zPkhDNK8EbhxWEdT6z46k8&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__cr.openjdk.java.net_-7Emhorie_8154736_webrev.08_&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=DMMm7IWjNJSRB69AbPfo-zPkhDNK8EbhxWEdT6z46k8&e=</a></font></tt><tt><font size="2"><br>> <br>> Previous review had discussions on improper log output (<br>> </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DSeptember_002672.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=s0YwAXbLaVr-SrmfU4DdH87Kd4baoN7bkGA1y-fBSrQ&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DSeptember_002672.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=s0YwAXbLaVr-SrmfU4DdH87Kd4baoN7bkGA1y-fBSrQ&e=</a></font></tt><tt><font size="2"><br>> ). Logs can be generated properly with this change, but I would like to ask<br>> if we should use “if(log) OrderAccess:acquire()” as is in webrev or more<br>> general approach with a call to OrderAccess:consume() with empty<br>> implementation on all supported platforms.<br>> <br>> Also, there were discussions on the problem of unawareness of copied obj (<br>> </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002696.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=HmMGF6U-OQ33yEAAUBjhhdBSVzw7m9ec0oiXn8y7eS8&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002696.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=HmMGF6U-OQ33yEAAUBjhhdBSVzw7m9ec0oiXn8y7eS8&e=</a></font></tt><tt><font size="2"><br>> ). This change adds “release” in cmpxchg_pre_membar. This was discussed in<br>> </font></tt><tt><font size="2"><a href="https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002698.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=mZWJvHc1jKeJlaDa1nu_vDz5FfB0WlCCnRmAOJYHLgA&e=">https://urldefense.proofpoint.com/v2/url?u=http-3A__mail.openjdk.java.net_pipermail_ppc-2Daix-2Dport-2Ddev_2016-2DOctober_002698.html&d=DwICJg&c=jf_iaSHvJObTbx-siA1ZOg&r=oecsIpYF-cifqq2i1JEH0Q&m=G-yYtdHSoT4SzbzpDm1wRbEXJKNJYc7V1jamUELVj_c&s=mZWJvHc1jKeJlaDa1nu_vDz5FfB0WlCCnRmAOJYHLgA&e=</a></font></tt><tt><font size="2"><br>> .<br>> <br>> I measured SPECjbb2015 with its multi JVMs mode on a POWER8 node (for JDK11<br>> , I modified MANIFEST in specjbb2015.jar to specify locations of JAXB<br>> related libraries). As a result, critical-jOPS improved by 6% due to this<br>> change.<br>> <br>> Best regards,<br>> --<br>> Michihiro,<br>> IBM Research - Tokyo<br>> <br><br></font></tt><br><BR>
</body></html>