RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64
kim.barrett at oracle.com
Mon May 28 23:53:52 UTC 2018
> 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.
More information about the hotspot-gc-dev