<html><body><p><font size="2">Hi David,</font><br><br><font size="2">I shouldn’t have written Release-Consume even though this wording is known from C++11.</font><p><font size="2">Consume is currently used for accessing the forwardee: One thread releases, another thread consumes new_obj.</font><p><font size="2">The place where I would like to change the barriers is the CAS. We don't need to rely on consume there. The release is the important part.</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__=8FBB0805DFA8A86C8f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Doerr, Martin" ---2018/05/23 18:13:44---Hi David, Michihiro's change does not rely on Consume AFAICS"><font size="2" color="#424282">"Doerr, Martin" ---2018/05/23 18:13:44---Hi David, Michihiro's change does not rely on Consume AFAICS. Only existing code does.</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">David Holmes <david.holmes@oracle.com>, Kim Barrett <kim.barrett@oracle.com>, Michihiro Horie <HORIE@jp.ibm.com></font><br><font size="2" color="#5F5F5F">Cc: </font><font size="2">"hotspot-dev@openjdk.java.net" <hotspot-dev@openjdk.java.net>, "hotspot-gc-dev@openjdk.java.net" <hotspot-gc-dev@openjdk.java.net>, "Gustavo Bueno Romero" <gromero@br.ibm.com>, "ppc-aix-port-dev@openjdk.java.net" <ppc-aix-port-dev@openjdk.java.net></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">2018/05/23 18:13</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 David,<br><br>Michihiro's change does not rely on Consume AFAICS. Only existing code does.<br><br>The CAS is not in the path between "new_obj = o->forwardee();" and the usage of new_obj.<br>So the CAS' barrier won't help. There's just ordering by "Consume".<br><br>The other thread's CAS (which has set the _mark field) currently has a post-barrier which won't help the reading thread, either.<br><br>Michihiro's change relies on the ordering of the CAS with respect to "new_obj = o->forwardee();" by accessing the same memory location "_mark" which is ensured by memory coherency.<br>And it relies on that compilers don't speculatively load o->forwardee() before the CAS which is ensured by the integrated compiler barriers (clobber "memory" in the volatile inline asm code). And it is also prevented because _mark is declared volatile.<br> <br>Best regards,<br>Martin<br><br><br>-----Original Message-----<br>From: David Holmes [</font></tt><tt><font size="2"><a href="mailto:david.holmes@oracle.com">mailto:david.holmes@oracle.com</a></font></tt><tt><font size="2">] <br>Sent: Mittwoch, 23. Mai 2018 10:36<br>To: Doerr, Martin <martin.doerr@sap.com>; Kim Barrett <kim.barrett@oracle.com>; Michihiro Horie <HORIE@jp.ibm.com><br>Cc: hotspot-dev@openjdk.java.net; hotspot-gc-dev@openjdk.java.net; Gustavo Bueno Romero <gromero@br.ibm.com>; ppc-aix-port-dev@openjdk.java.net<br>Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64<br><br>On 22/05/2018 8:16 PM, Doerr, Martin wrote:<br>> Hi Kim,<br>> <br>> I can't see how a new implicit consume is introduced by Michihiro's change. He just explained how the existing code works.<br>> <br>> If implicit consume has been rejected the current code is wrong:<br>> "new_obj = o->forwardee();" would need some kind of barrier before using the new_obj.<br><br>But if forwardee is set by a CAS with (default) full bi-directional <br>fence we have that barrier. The argument is that such a strong barrier <br>can be relaxed yet maintain correctness - isn't it?<br><br>David<br><br><br>> But this issue is not related to what Michihiro wants to change AFAICS.<br>> <br>> Best regards,<br>> Martin<br>> <br>> <br>> -----Original Message-----<br>> From: ppc-aix-port-dev [</font></tt><tt><font size="2"><a href="mailto:ppc-aix-port-dev-bounces@openjdk.java.net">mailto:ppc-aix-port-dev-bounces@openjdk.java.net</a></font></tt><tt><font size="2">] On Behalf Of Kim Barrett<br>> Sent: Montag, 21. Mai 2018 06:00<br>> To: Michihiro Horie <HORIE@jp.ibm.com><br>> Cc: hotspot-dev@openjdk.java.net; hotspot-gc-dev@openjdk.java.net; Gustavo Bueno Romero <gromero@br.ibm.com>; ppc-aix-port-dev@openjdk.java.net; david.holmes@oracle.com<br>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64<br>> <br>>> On May 18, 2018, at 5:12 PM, Michihiro Horie <HORIE@jp.ibm.com> wrote:<br>>><br>>> Dear all,<br>>><br>>> I update the webrev: </font></tt><tt><font size="2"><a href="http://cr.openjdk.java.net/~mhorie/8154736/webrev.09/">http://cr.openjdk.java.net/~mhorie/8154736/webrev.09/</a></font></tt><tt><font size="2"><br>>><br>>> With the release barrier before the CAS, new_obj can be observed from other threads. If the CAS succeeds, the current thread can use new_obj without barriers. If the CAS fails, "o->forwardee()" is ordered with respect to CAS by accessing the same memory location "_mark", so no barriers needed. The order of (1) access to the forwardee and (2) access to forwardee's fields is preserved due to Release-Consume ordering on supported platforms. (The ordering between "new_obj = o->forwardee();" and logging or other usages is not changed.)<br>>><br>>> Regarding the maintainability, the requirement is CAS(memory_order_release) as Release-Consume to be consistent with C++11. This requirement is necessary when a weaker platform like DEC Alpha is to be supported. On currently supported platforms, code change can be safe if the code meats this requirement (and the order of (1) access to the forwardee and (2) access to forwardee's fields is the natural way of coding).<br>> <br>> Relying on implicit consume has been been discussed and rejected, in<br>> the earlier thread on this topic and I think elsewhere too.<br>> <br>> </font></tt><tt><font size="2"><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021538.html">http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021538.html</a></font></tt><tt><font size="2"><br>> <br><br></font></tt><br><BR>
</body></html>