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

[Doerr, Martin]

Hi Kim,

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.
So it sounds like a request to fix the current implementation in addition to what his original intend was.

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.
What about keeping memory_order_release for the CAS and using acquire for both o->forwardee()?
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.

Thanks and best regards,
Martin


-----Original Message-----
From: Kim Barrett [mailto:kim.barrett at oracle.com] 
Sent: Dienstag, 29. Mai 2018 01:54
To: Michihiro Horie <HORIE at jp.ibm.com>
Cc: Erik Osterlund <erik.osterlund at oracle.com>; david.holmes at oracle.com; Gustavo Bueno Romero <gromero at br.ibm.com>; hotspot-dev at openjdk.java.net; hotspot-gc-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Doerr, Martin <martin.doerr at sap.com>
Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64

> On May 28, 2018, at 4:12 AM, Michihiro Horie <HORIE at jp.ibm.com> wrote:
> 
> Hi Erik,
> 
> Thank you very much for your review.
> 
> 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.
> 
> New webrev uses memory_order_acq_rel: http://cr.openjdk.java.net/~mhorie/8154736/webrev.10

This is missing the acquire barrier on the else branch for the initial test, so fails to meet
the previously described minimal requirements for even possibly being sufficient.  Any
analysis of weakening the CAS barriers must consider that test and successor code.

In the analysis, it’s not just the lexically nearby debugging / logging code that needs to be
considered; the forwardee is being returned to caller(s) that will presumably do something
with that object.

Since the whole point of this discussion is performance, any proposed change should come
with performance information.