<html><body bgcolor="#FFFFFF"><p><font size="2">>Hi Michihiro,<br>><br>>Looks good to me.</font><br><font size="2"><br>Thanks a lot, Erik!</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__=8FBB080CDFC612A28f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for "Erik Österlund" ---2018/06/02 00:15:15---Hi Michihiro, Looks good to me."><font size="2" color="#424282">"Erik Österlund" ---2018/06/02 00:15:15---Hi Michihiro, Looks good to me.</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">"Erik Österlund" <erik.osterlund@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">"Andrew Haley (aph@redhat.com)" <aph@redhat.com>, "david.holmes@oracle.com" <david.holmes@oracle.com>, "hotspot-gc-dev@openjdk.java.net" <hotspot-gc-dev@openjdk.java.net>, Kim Barrett <kim.barrett@oracle.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/06/02 00:15</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>Hi Michihiro,<br><br>Looks good to me.<br><br>Thanks,<br>/Erik<br><br>On 2018-06-01 17:08, Michihiro Horie wrote:
<ul><ul><font size="2">Hi Kim, Erik, and Martin,</font><br><font size="2"><br>Thank you very much for reminding me that an acquire barrier in the else-statement for “!test_mark->is_marked()” is necessary under the criteria of not relying on the consume. </font><br><font size="2"><br>I uploaded a new webrev : </font><a href="http://cr.openjdk.java.net/%7Emhorie/8154736/webrev.13/"></a><a href="http://cr.openjdk.java.net/~mhorie/8154736/webrev.13/"><u><font size="2" color="#0000FF">http://cr.openjdk.java.net/~mhorie/8154736/webrev.13/</font></u></a><font size="2"><br>This change uses forwardee_acquire(), which would generate better code on ARM. </font><br><font size="2"><br>Necessary barriers are located in all the paths in copy_to_survivor_space, and the returned new_obj can be safely handled in the caller sites.</font><br><font size="2"><br>I measured SPECjbb2015 with the latest webrev. Critical-jOPS improved by 5%. Since my previous measurement with implicit consume showed 6% improvement, adding acquire barriers degraded the performance a little, but 5% is still good enough.</font><br><br><font size="2"><br>Best regards,<br>--<br>Michihiro,<br>IBM Research - Tokyo</font><br><br><img src="cid:1__=8FBB080CDFC612A28f9e8a93df938690918c8FB@" width="16" height="16" alt="Inactive
hide details for "Doerr, Martin" ---2018/05/30
16:18:09---Hi Erik, the current implementation works on PPC
because of "><font size="2" color="#424282">"Doerr, Martin" ---2018/05/30 16:18:09---Hi Erik, the current implementation works on PPC because of "MP+sync+addr".</font><br><font size="2" color="#5F5F5F"><br>From: </font><font size="2">"Doerr, Martin" </font><a href="mailto:martin.doerr@sap.com"><u><font size="2" color="#0000FF"><martin.doerr@sap.com></font></u></a><font size="2" color="#5F5F5F"><br>To: </font><font size="2">"Erik Österlund" </font><a href="mailto:erik.osterlund@oracle.com"><u><font size="2" color="#0000FF"><erik.osterlund@oracle.com></font></u></a><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">, "Andrew Haley (</font><a href="mailto:aph@redhat.com"><u><font size="2" color="#0000FF">aph@redhat.com</font></u></a><font size="2">)" </font><a href="mailto:aph@redhat.com"><u><font size="2" color="#0000FF"><aph@redhat.com></font></u></a><font size="2" color="#5F5F5F"><br>Cc: </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><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><u><font size="2" color="#0000FF">"ppc-aix-port-dev@openjdk.java.net"</font></u></a><font size="2"> </font><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><u><font size="2" color="#0000FF"><ppc-aix-port-dev@openjdk.java.net></font></u></a><font size="2" color="#5F5F5F"><br>Date: </font><font size="2">2018/05/30 16:18</font><font size="2" color="#5F5F5F"><br>Subject: </font><font size="2">RE: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64</font><p><hr width="100%" size="2" align="left" noshade><br><br><tt><font size="2"><br>Hi Erik,<br><br>the current implementation works on PPC because of "MP+sync+addr".<br>So we already rely on ordering of "load volatile field" + "implicit consume" on the reader's side. We have never seen any issues related to this with the compilers we have been using during the ~10 years the PPC implementation exists.<br><br>PPC supports "MP+lwsync+addr" the same way, so Michihiro's proposal doesn't make it unreliable for PPC.<br><br>But I'm ok with evaluating acquire barriers although they are not required by the PPC/ARM memory models.<br>ARM/aarch64 will also be affected when the o->forwardee uses load_acquire. So somebody should check the impact. If it is not acceptable we may need to introduce explicit consume.<br><br>Implicit consume is also bad in shared code because somebody may want to run it on DEC Alpha.<br><br>Thanks and best regards,<br>Martin<br><br><br>-----Original Message-----<br>From: Erik Österlund [</font></tt><a href="mailto:erik.osterlund@oracle.com"></a><a href="mailto:erik.osterlund@oracle.com"><tt><u><font size="2" color="#0000FF">mailto:erik.osterlund@oracle.com</font></u></tt></a><tt><font size="2">] <br>Sent: Dienstag, 29. Mai 2018 14:01<br>To: Doerr, Martin </font></tt><a href="mailto:martin.doerr@sap.com"><tt><u><font size="2" color="#0000FF"><martin.doerr@sap.com></font></u></tt></a><tt><font size="2">; Kim Barrett </font></tt><a href="mailto:kim.barrett@oracle.com"><tt><u><font size="2" color="#0000FF"><kim.barrett@oracle.com></font></u></tt></a><tt><font size="2">; Michihiro Horie </font></tt><a href="mailto:HORIE@jp.ibm.com"><tt><u><font size="2" color="#0000FF"><HORIE@jp.ibm.com></font></u></tt></a><tt><font size="2"><br>Cc: </font></tt><a href="mailto:david.holmes@oracle.com"><tt><u><font size="2" color="#0000FF">david.holmes@oracle.com</font></u></tt></a><tt><font size="2">; Gustavo Bueno Romero </font></tt><a href="mailto:gromero@br.ibm.com"><tt><u><font size="2" color="#0000FF"><gromero@br.ibm.com></font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:hotspot-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">hotspot-dev@openjdk.java.net</font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">ppc-aix-port-dev@openjdk.java.net</font></u></tt></a><tt><font size="2"><br>Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64<br><br>Hi Martin and Michihiro,<br><br>On 2018-05-29 12:30, Doerr, Martin wrote:<br>> Hi Kim,<br>><br>> I'm trying to understand how this is related to Michihiro's change. The else path of the initial test is not affected by it AFAICS.<br>> So it sounds like a request to fix the current implementation in addition to what his original intend was.<br><br>I think we are just trying to nail down the correct fencing and just go <br>for that. And yes, this is arguably a pre-existing problem, but in a <br>race involving the very same accesses that we are changing the fencing <br>for. So it is not completely unrelated I suppose.<br><br>In particular, hotspot has code that assumes that if you on the writer <br>side issue a full fence before publishing a pointer to newly initialized <br>data, then the initializing stores and their side effects should be <br>globally "visible" across the system before the pointer to it is <br>published, and hence elide the need for acquire on the loading side, <br>without relying on retained data dependencies on the loader side. I <br>believe this code falls under that category. It is assumed that the <br>leading fence of the CAS publishing the forwarding pointer makes the <br>initializing stores globally observable before publishing a pointer to <br>the initialized data, hence assuming that any loads able to observe the <br>new pointer would not rely on acquire or data dependent loads to <br>correctly read the initialized data.<br><br>Unfortunately, this is not reliable in the IRIW case, as per the litmus <br>test "MP+sync+ctrl" as described in "Understanding POWER <br>multiprocessors" (</font></tt><a href="https://dl.acm.org/citation.cfm?id=1993520"></a><a href="https://dl.acm.org/citation.cfm?id=1993520"><tt><u><font size="2" color="#0000FF">https://dl.acm.org/citation.cfm?id=1993520</font></u></tt></a><tt><font size="2">), as <br>opposed to "MP+sync+addr" that gets away with it because of the data <br>dependency (not IRIW). Similarly, an isync does the job too on the <br>reader side as shown in MP+sync+ctrlisync. So while what I believe was <br>the previous reasoning that the leading sync of the CAS would elide the <br>necessity for acquire on the reader side without relying on data <br>dependent loads (implicit consume), I think that assumption was wrong in <br>the first place and that we do indeed need explicit acquire (even with <br>the precious conservative CAS fencing) in this context to not rely on <br>implicit consume semantics generating the required data dependent loads <br>on the reader side. In practice though, the leading sync of the CAS has <br>been enough to generate the correct machine code. Now, with the leading <br>sync removed, we are increasing the possible holes in the generated <br>machine code due to this flawed reasoning. So it would be nice to do <br>something more sound instead that does not make such assumptions.<br><br>> Anyway, I agree with that implicit consume is not good. And I think it would be good to treat both o->forwardee() the same way.<br>> What about keeping memory_order_release for the CAS and using acquire for both o->forwardee()?<br>> The case in which the CAS succeeds is safe because the current thread has created new_obj so it doesn't need memory barriers to access it.<br><br>Sure, that sounds good to me.<br><br>Thanks,<br>/Erik<br><br>> Thanks and best regards,<br>> Martin<br>><br>><br>> -----Original Message-----<br>> From: Kim Barrett [</font></tt><a href="mailto:kim.barrett@oracle.com"></a><a href="mailto:kim.barrett@oracle.com"><tt><u><font size="2" color="#0000FF">mailto:kim.barrett@oracle.com</font></u></tt></a><tt><font size="2">]<br>> Sent: Dienstag, 29. Mai 2018 01:54<br>> To: Michihiro Horie </font></tt><a href="mailto:HORIE@jp.ibm.com"><tt><u><font size="2" color="#0000FF"><HORIE@jp.ibm.com></font></u></tt></a><tt><font size="2"><br>> Cc: Erik Osterlund </font></tt><a href="mailto:erik.osterlund@oracle.com"><tt><u><font size="2" color="#0000FF"><erik.osterlund@oracle.com></font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:david.holmes@oracle.com"><tt><u><font size="2" color="#0000FF">david.holmes@oracle.com</font></u></tt></a><tt><font size="2">; Gustavo Bueno Romero </font></tt><a href="mailto:gromero@br.ibm.com"><tt><u><font size="2" color="#0000FF"><gromero@br.ibm.com></font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:hotspot-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">hotspot-dev@openjdk.java.net</font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">hotspot-gc-dev@openjdk.java.net</font></u></tt></a><tt><font size="2">; </font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><u><font size="2" color="#0000FF">ppc-aix-port-dev@openjdk.java.net</font></u></tt></a><tt><font size="2">; Doerr, Martin </font></tt><a href="mailto:martin.doerr@sap.com"><tt><u><font size="2" color="#0000FF"><martin.doerr@sap.com></font></u></tt></a><tt><font size="2"><br>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64<br>><br>>> On May 28, 2018, at 4:12 AM, Michihiro Horie </font></tt><a href="mailto:HORIE@jp.ibm.com"><tt><u><font size="2" color="#0000FF"><HORIE@jp.ibm.com></font></u></tt></a><tt><font size="2"> wrote:<br>>><br>>> Hi Erik,<br>>><br>>> Thank you very much for your review.<br>>><br>>> I understood that implicit consume should not be used in the shared code. Also, I believe performance degradation would be negligible even if we use acquire.<br>>><br>>> New webrev uses memory_order_acq_rel: </font></tt><a href="http://cr.openjdk.java.net/%7Emhorie/8154736/webrev.10"><tt><u><font size="2" color="#0000FF">http://cr.openjdk.java.net/~mhorie/8154736/webrev.10</font></u></tt></a><tt><font size="2"><br>> This is missing the acquire barrier on the else branch for the initial test, so fails to meet<br>> the previously described minimal requirements for even possibly being sufficient. Any<br>> analysis of weakening the CAS barriers must consider that test and successor code.<br>><br>> In the analysis, it’s not just the lexically nearby debugging / logging code that needs to be<br>> considered; the forwardee is being returned to caller(s) that will presumably do something<br>> with that object.<br>><br>> Since the whole point of this discussion is performance, any proposed change should come<br>> with performance information.<br>><br><br></font></tt><br><br></ul></ul><br><BR>
</body></html>