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

[Michihiro Horie]

David, Kim, and Marin,

Thank you for your question and comments.

The important point I should specify earlier is that CAS contains a
compiler barrier that prevents moving code around it, e.g. by clobber
"memory" in inline asm code.

Thus, release with a two-way compiler barrier (CAS) is the prerequisite in
my change.

Regarding the Release-Consume ordering, I think making use of implicit
consume is enough and it is already realized with the existing code
(release and CAS).


Best regards,
--
Michihiro,
IBM Research - Tokyo



From:	"Doerr, Martin" <martin.doerr at sap.com>
To:	Kim Barrett <kim.barrett at oracle.com>, Michihiro Horie
            <HORIE at jp.ibm.com>
Cc:	"hotspot-dev at openjdk.java.net" <hotspot-dev at openjdk.java.net>,
            "hotspot-gc-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"
            <ppc-aix-port-dev at openjdk.java.net>, "david.holmes at oracle.com"
            <david.holmes at oracle.com>
Date:	2018/05/22 19:17
Subject:	RE: RFR(M): 8154736: enhancement of cmpxchg and
            copy_to_survivor for ppc64



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.

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




-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20180523/7387c446/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/ppc-aix-port-dev/attachments/20180523/7387c446/graycol.gif>