RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

[Kim Barrett]

> On May 22, 2018, at 12:16 PM, Doerr, Martin <martin.doerr at sap.com> wrote:
> 
> Hi Kim,
> 
> I can't see how a new implicit consume is introduced by Michihiro's change. He just explained how the existing code works.
> 
> If implicit consume has been rejected the current code is wrong:
> "new_obj = o->forwardee();" would need some kind of barrier before using the new_obj.
> 
> But this issue is not related to what Michihiro wants to change AFAICS.

The current full-fence CAS guarantees the stores into the new
forwardee installed by the CAS happen before loads from that object
after the CAS.  Algorithmically, o->forwardee() is guaranteed to be
the same object as was returned by the CAS.  Hence, loads from the
forwardee are being ordered by the fenced CAS.

I've discussed this with others on the GC team; we think the minimal
required barriers are CAS with memory_order_acq_rel, plus an acquire
barrier on the else branch of

 122   if (!test_mark->is_marked()) {
...
 261   } else {
 262     assert(o->is_forwarded(), "Sanity");
 263     new_obj = o->forwardee();
 264   }

We've not done enough analysis to show this is sufficient, but we
think anything weaker is not sufficient for shared code.


> 
> Best regards,
> Martin
> 
> 
> -----Original Message-----
> From: ppc-aix-port-dev [mailto:ppc-aix-port-dev-bounces at openjdk.java.net] On Behalf Of Kim Barrett
> Sent: Montag, 21. Mai 2018 06:00
> To: Michihiro Horie <HORIE at jp.ibm.com>
> Cc: hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; Gustavo Bueno Romero <gromero at br.ibm.com>; ppc-aix-port-dev at openjdk.java.net; david.holmes at oracle.com
> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
> 
>> On May 18, 2018, at 5:12 PM, Michihiro Horie <HORIE at jp.ibm.com> wrote:
>> 
>> Dear all,
>> 
>> I update the webrev: http://cr.openjdk.java.net/~mhorie/8154736/webrev.09/
>> 
>> 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.)
>> 
>> 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).
> 
> Relying on implicit consume has been been discussed and rejected, in
> the earlier thread on this topic and I think elsewhere too.
> 
> http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-October/021538.html