<font size=2 face="sans-serif">Dear David, and Dan,</font><br><br><font size=2 face="sans-serif">Thank you for your comments.</font><br><br><font size=2 face="sans-serif">> In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:</font><br><font size=2 face="sans-serif">> 266 the log line reads data from
the forwardee even when the CAS </font><br><font size=2 face="sans-serif">> fails. I believe those reads will
be unsafe without barriers after </font><br><font size=2 face="sans-serif">> the copy of the content of the
object.</font><br><font size=2 face="sans-serif">> hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288
</font><br><font size=2 face="sans-serif">> same problem as in line 266</font><br><br><font size=2 face="sans-serif">Can we use o->size() or new_obj_size
instead of new_obj->size()?</font><br><br><font size=2 face="sans-serif">> If you feel that the use of new_obj->size()
is potentially unsafe then </font><br><font size=2 face="sans-serif">> the fact we return new_obj means
that any use of new_obj by the caller </font><br><font size=2 face="sans-serif">> may also potentially be unsafe.</font><br><br><font size=2 face="sans-serif">In my understanding, while copying objects
to a survivor space, if a thread creates a new_obj and sets a pointer with
CAS, the other threads can touch the new_obj after the thread calls push_contents(new_obj)
(Line: 239). In push_contents, OrderAccess::release_store is called before
pushing the object as a task into a deque of workstealing (taskqueue.inline.hpp).
If the other thread reads the task, all of copy for new_obj is safe.</font><br><br><font size=2 face="sans-serif">Thank you for your helps again. I may
be misunderstanding or missing something critical. Any comments and claims
are always appreciated. </font><br><br><font size=2 face="sans-serif">Regards,<br>Hiroshi<br>-----------------------<br>Hiroshi Horii, Ph.D.<br>IBM Research - Tokyo<br></font><br><br><tt><font size=2>David Holmes <david.holmes@oracle.com> wrote
on 09/30/2016 07:16:16:<br><br>> From: David Holmes <david.holmes@oracle.com></font></tt><br><tt><font size=2>> To: Carsten Varming <varming@gmail.com>,
Hiroshi H Horii/Japan/IBM@IBMJP</font></tt><br><tt><font size=2>> Cc: Tim Ellison <Tim_Ellison@uk.ibm.com>,
"ppc-aix-port-<br>> dev@openjdk.java.net" <ppc-aix-port-dev@openjdk.java.net>,
"hotspot-<br>> runtime-dev@openjdk.java.net" <hotspot-runtime-<br>> dev@openjdk.java.net>, "hotspot-gc-dev@openjdk.java.net"
<hotspot-<br>> gc-dev@openjdk.java.net>, hotspot-compiler-dev <hotspot-compiler-<br>> dev-bounces@openjdk.java.net></font></tt><br><tt><font size=2>> Date: 09/30/2016 07:17</font></tt><br><tt><font size=2>> Subject: Re: RFR(M): 8154736: enhancement of
cmpxchg and <br>> copy_to_survivor for ppc64</font></tt><br><tt><font size=2>> <br>> On 30/09/2016 12:47 AM, Carsten Varming wrote:<br>> > Dear Hiroshi,<br>> ><br>> > In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266<br>> > the log line reads data from the forwardee even when the CAS
fails. I<br>> > believe those reads will be unsafe without barriers after the
copy of<br>> > the content of the object.<br>> <br>> I find it extremely hard to reason about a barrier-less cmpxchg in
general.<br>> <br>> If you feel that the use of new_obj->size() is potentially unsafe
then <br>> the fact we return new_obj means that any use of new_obj by the caller
<br>> may also potentially be unsafe.<br>> <br>> David<br>> -----<br>> <br>> > hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288
same<br>> > problem as in line 266<br>> ><br>> > I would argue that the logging should only happen if the thread<br>> > successfully copied the object and CAS failures should be logged<br>> > separately without reading data from the forwardee.<br>> ><br>> > BTW, unrelated to your change: It seems like the logging in line
266<br>> > should be guarded by something like "if (log_develop_is_enabled(Trace,<br>> > gc, scavenge)" like the logging in line 288.<br>> ><br>> > Carsten<br>> ><br>> > On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii <HORII@jp.ibm.com<br>> > <</font></tt><a href=mailto:HORII@jp.ibm.com><tt><font size=2>mailto:HORII@jp.ibm.com</font></tt></a><tt><font size=2>>>
wrote:<br>> ><br>> > Hi all,<br>> ><br>> > Can I please request reviews for a change for 8154736
that improve<br>> > copy_to_survivor performance of ppc64 and aarch64?<br>> > If possible, I would like to include this change
into jdk9.<br>> ><br>> > 8154736 includes two changes, cmpxchg and copy_to_suvivor,
and the<br>> > former<br>> > was resolved as 8155949.<br>> > Now, I would like to ask a review for the remaining,
copy_to_suvivor<br>> > change.<br>> ><br>> > webrev:<br>> > </font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/</font></tt></a><tt><font size=2><br>> > <</font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/</font></tt></a><tt><font size=2>><br>> > JIRA: </font></tt><a href="https://bugs.openjdk.java.net/browse/JDK-8154736"><tt><font size=2>https://bugs.openjdk.java.net/browse/JDK-8154736</font></tt></a><tt><font size=2><br>> > <</font></tt><a href="https://bugs.openjdk.java.net/browse/JDK-8154736"><tt><font size=2>https://bugs.openjdk.java.net/browse/JDK-8154736</font></tt></a><tt><font size=2>><br>> ><br>> > I tested this change with SPECjbb2013. Also, I
re-check that relaxed<br>> > cmpxchg is available for changing forwarding pointers.
However, because<br>> > this change is sensitive, we need more reviews
not only from<br>> > compiler-dev,<br>> > but also from gc-dev.<br>> ><br>> > Regards,<br>> > Hiroshi<br>> > -----------------------<br>> > Hiroshi Horii, Ph.D.<br>> > IBM Research - Tokyo<br>> ><br>> ><br>> ><br>> ><br>> > From: David Holmes <david.holmes@oracle.com<br>> > <</font></tt><a href=mailto:david.holmes@oracle.com><tt><font size=2>mailto:david.holmes@oracle.com</font></tt></a><tt><font size=2>>><br>> > To: "Doerr, Martin" <martin.doerr@sap.com<br>> > <</font></tt><a href=mailto:martin.doerr@sap.com><tt><font size=2>mailto:martin.doerr@sap.com</font></tt></a><tt><font size=2>>>,
Hiroshi H<br>> > Horii/Japan/IBM@IBMJP<br>> > Cc: Tim Ellison <Tim_Ellison@uk.ibm.com<br>> > <</font></tt><a href=mailto:Tim_Ellison@uk.ibm.com><tt><font size=2>mailto:Tim_Ellison@uk.ibm.com</font></tt></a><tt><font size=2>>>,<br>> > "ppc-aix-port-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><font size=2>mailto:ppc-aix-port-dev@openjdk.java.net</font></tt></a><tt><font size=2>>"<br>> > <ppc-aix-port-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><font size=2>mailto:ppc-aix-port-dev@openjdk.java.net</font></tt></a><tt><font size=2>>>,<br>> > "hotspot-gc-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-gc-dev@openjdk.java.net</font></tt></a><tt><font size=2>>"<br>> > <hotspot-gc-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-gc-dev@openjdk.java.net</font></tt></a><tt><font size=2>>>,<br>> > "hotspot-runtime-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-runtime-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-runtime-dev@openjdk.java.net</font></tt></a><tt><font size=2>>"<br>> > <hotspot-runtime-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-runtime-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-runtime-dev@openjdk.java.net</font></tt></a><tt><font size=2>>><br>> > Date: 05/10/2016 19:31<br>> > Subject: Re: RFR(M):
8154736: enhancement of cmpxchg and<br>> > copy_to_survivor for ppc64<br>> ><br>> ><br>> ><br>> > On 10/05/2016 7:41 PM, Doerr, Martin wrote:<br>> > > Hi David,<br>> > ><br>> > > thank you very much for testing the other
platforms.<br>> > ><br>> > > Here's an updated webrev:<br>> > > </font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/</font></tt></a><tt><font size=2><br>> > <</font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/</font></tt></a><tt><font size=2>><br>> ><br>> > Thanks. Second test run on its way.<br>> ><br>> > David<br>> > -----<br>> ><br>> > > Best regards,<br>> > > Martin<br>> > ><br>> > > -----Original Message-----<br>> > > From: hotspot-runtime-dev [<br>> > </font></tt><a href="mailto:hotspot-runtime-dev-bounces@openjdk.java.net"><tt><font size=2>mailto:hotspot-runtime-dev-bounces@openjdk.java.net</font></tt></a><tt><font size=2><br>> > <</font></tt><a href="mailto:hotspot-runtime-dev-bounces@openjdk.java.net"><tt><font size=2>mailto:hotspot-runtime-dev-bounces@openjdk.java.net</font></tt></a><tt><font size=2>>]
On Behalf Of<br>> > David<br>> > Holmes<br>> > > Sent: Dienstag, 10. Mai 2016 11:11<br>> > > To: Hiroshi H Horii <HORII@jp.ibm.com <</font></tt><a href=mailto:HORII@jp.ibm.com><tt><font size=2>mailto:HORII@jp.ibm.com</font></tt></a><tt><font size=2>>><br>> > > Cc: Tim Ellison <Tim_Ellison@uk.ibm.com<br>> > <</font></tt><a href=mailto:Tim_Ellison@uk.ibm.com><tt><font size=2>mailto:Tim_Ellison@uk.ibm.com</font></tt></a><tt><font size=2>>>;<br>> > ppc-aix-port-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><font size=2>mailto:ppc-aix-port-dev@openjdk.java.net</font></tt></a><tt><font size=2>>;<br>> > hotspot-gc-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-gc-dev@openjdk.java.net</font></tt></a><tt><font size=2>>;<br>> > hotspot-runtime-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-runtime-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-runtime-dev@openjdk.java.net</font></tt></a><tt><font size=2>><br>> > > Subject: Re: RFR(M): 8154736: enhancement
of cmpxchg and<br>> > copy_to_survivor for ppc64<br>> > ><br>> > > The fix seems incomplete for solaris:<br>> > ><br>> > > make/Main.gmk:232: recipe for target 'hotspot'
failed<br>> > ><br>> > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/<br>> solaris_x86/vm/atomic_solaris_x86.inline.hpp",<br>> > > line 124: Error: Too many arguments in call
to<br>> > > "_Atomic_cmpxchg_long(long, volatile
long*, long)".<br>> > ><br>> > "/opt/jprt/T/P1/073516.daholme/s/hotspot/src/os_cpu/<br>> solaris_x86/vm/atomic_solaris_x86.inline.hpp",<br>> > > line 128: Error: Too many arguments in call
to<br>> > > "_Atomic_cmpxchg_long(long, volatile
long*, long)".<br>> > ><br>> > > David<br>> > ><br>> > > On 10/05/2016 5:34 PM, David Holmes wrote:<br>> > >> Hi Hiroshi,<br>> > >><br>> > >> On 6/05/2016 8:11 PM, Hiroshi H Horii
wrote:<br>> > >>> Hi David,<br>> > >>><br>> > >>> Thank you for your comments.<br>> > >>><br>> > >>> As Martin suggested me, I would like
to separate this proposal to<br>> > >>> - relaxing memory order of
cmpxchg<br>> > >>> - improvement of copy_to_survivior
with relaxed cmpxchg<br>> > >>> and discuss the former first.<br>> > >>><br>> > >>> Martin thankfully created a new webrev
that include a change of<br>> > cmpxchg.<br>> > >>><br>> > </font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/</font></tt></a><tt><font size=2><br>> > <</font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/</font></tt></a><tt><font size=2>><br>> > >>> He has already tested it with AIX,
linuxx86_64, linuxppc64le and<br>> > >>> darwinintel64.<br>> > >>> (Please tell me if I need to send
a new mail for this PFR)<br>> > >><br>> > >> Please do as it will be simpler to track
that way.<br>> > >><br>> > >>>> What I would prefer to see is
an additional memory_order value<br>> > (such<br>> > as<br>> > >>>> memory_order_ignored) which is
the default for all methods declared<br>> > to<br>> > >>>> take a memory_order parameter.<br>> > >>><br>> > >>> We added simple enum to specify memory
order in atomic.hpp as<br>> > follows.<br>> > >>><br>> > >>> typedef enum cmpxchg_cmpxchg_memory_order
{<br>> > >>> memory_order_relaxed,<br>> > >>> memory_order_conservative<br>> > >>> } cmpxchg_memory_order;<br>> > >>><br>> > >>> All of cmpxchg functions have an argument
of cmpxchg_memory_order<br>> > >>> with a default value memory_order_conservative
that uses the same<br>> > >>> semantics with the existing cmpxchg
and requires no change for the<br>> > >>> existing<br>> > >>> callers. If you think "memory_order_ignored"
is better than<br>> > >>> "memory_order_conservative",
I will be happy to modify this change.<br>> > >>> (I just thought, "ignored"
may resemble "relaxed" and may make<br>> > >>> people who are familiar with C++11's
memory semantics confused.<br>> > >>> I would like to know thoughts of native
speakers.)<br>> > >><br>> > >> That is fine by me. I don't think "ignored"
would be confused with<br>> > >> "relaxed", but "conservative"
is fine.<br>> > >><br>> > >> I will run the patch through our internal
build system while you<br>> > prepare<br>> > >> the updated RFR. My only concern is "unused
argument" warnings<br>> > from the<br>> > >> compiler. :)<br>> > >><br>> > >> We are quickly running into a hard deadline
with Feature Complete<br>> > >> however - possibly less than 24 hours
- for hotspot changes. If this<br>> > >> doesn't get in in time I will see if I
can shepherd it through the<br>> > >> approval process.<br>> > >><br>> > >> Thanks,<br>> > >> David<br>> > >><br>> > >><br>> > >>> Regards,<br>> > >>> Hiroshi<br>> > >>> -----------------------<br>> > >>> Hiroshi Horii, Ph.D.<br>> > >>> IBM Research - Tokyo<br>> > >>><br>> > >>><br>> > >>> David Holmes <david.holmes@oracle.com<br>> > <</font></tt><a href=mailto:david.holmes@oracle.com><tt><font size=2>mailto:david.holmes@oracle.com</font></tt></a><tt><font size=2>>>
wrote on 05/04/2016 14:55:29:<br>> > >>><br>> > >>>> From: David Holmes <david.holmes@oracle.com<br>> > <</font></tt><a href=mailto:david.holmes@oracle.com><tt><font size=2>mailto:david.holmes@oracle.com</font></tt></a><tt><font size=2>>><br>> > >>>> To: Hiroshi H Horii/Japan/IBM@IBMJP<br>> > >>>> Cc: hotspot-gc-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-gc-dev@openjdk.java.net</font></tt></a><tt><font size=2>>,
hotspot-runtime-<br>> > >>>> dev@openjdk.java.net <</font></tt><a href=mailto:dev@openjdk.java.net><tt><font size=2>mailto:dev@openjdk.java.net</font></tt></a><tt><font size=2>>,<br>> > ppc-aix-port-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><font size=2>mailto:ppc-aix-port-dev@openjdk.java.net</font></tt></a><tt><font size=2>>,
Tim Ellison<br>> > >>>> <Tim_Ellison@uk.ibm.com <</font></tt><a href=mailto:Tim_Ellison@uk.ibm.com><tt><font size=2>mailto:Tim_Ellison@uk.ibm.com</font></tt></a><tt><font size=2>>>,<br>> > Volker Simonis <volker.simonis@gmail.com<br>> > <</font></tt><a href=mailto:volker.simonis@gmail.com><tt><font size=2>mailto:volker.simonis@gmail.com</font></tt></a><tt><font size=2>>>,<br>> > >>>> "Doerr, Martin" <martin.doerr@sap.com<br>> > <</font></tt><a href=mailto:martin.doerr@sap.com><tt><font size=2>mailto:martin.doerr@sap.com</font></tt></a><tt><font size=2>>>,
"Lindenmaier, Goetz"<br>> > >>>> <goetz.lindenmaier@sap.com
<</font></tt><a href=mailto:goetz.lindenmaier@sap.com><tt><font size=2>mailto:goetz.lindenmaier@sap.com</font></tt></a><tt><font size=2>>><br>> > >>>> Date: 05/04/2016 14:57<br>> > >>>> Subject: Re: RFR(M): 8154736:
enhancement of cmpxchg and<br>> > >>>> copy_to_survivor for ppc64<br>> > >>>><br>> > >>>> Hi Hiroshi,<br>> > >>>><br>> > >>>> Sorry for the delay on getting
back to this.<br>> > >>>><br>> > >>>> On 25/04/2016 5:09 PM, Hiroshi
H Horii wrote:<br>> > >>>>> Hi David,<br>> > >>>>><br>> > >>>>> Thank you for your comments
and questions.<br>> > >>>>><br>> > >>>>>> 1. Are the current cmpxchg
semantics exactly the same as<br>> > >>>>>> memory_order_seq_cst?<br>> > >>>>><br>> > >>>>> This is very good question..<br>> > >>>>><br>> > >>>>> I guess, cmpxchg needs a more
conservative constraint for memory<br>> > >>> ordering<br>> > >>>>> than C++11, to add sync after
a compare-and-exchange operation.<br>> > >>>>><br>> > >>>>> Could someone give comments
or thoughts?<br>> > >>>><br>> > >>>> I don't want to comment on the
comparison with C++11. What I would<br>> > >>>> prefer to see is an additional
memory_order value (such as<br>> > >>>> memory_order_ignored) which is
the default for all methods declared<br>> > to<br>> > >>>> take a memory_order parameter.
That way existing<br>> > implementations are<br>> > >>>> clearly ignoring the memory_order
attribute and there is no<br>> > potential<br>> > >>>> for confusion as to whether the
existing implementations equate to<br>> > >>>> memory_order_seq_cst or not.<br>> > >>>><br>> > >>>> That said, I'm not sure it makes
sense to add the memory_order<br>> > parameter<br>> > >>>> to all methods with "cas"
in their name, e.g.<br>> > oopDesc::cas_set_mark,<br>> > >>>> oopDesc::cas_forward_to, unless
those methods can sensibly be<br>> > called<br>> > >>>> with any value for memory_order
- which seems highly unlikely.<br>> > Perhaps<br>> > >>>> those methods should identify
the weakest form of memory_order they<br>> > >>>> support and that should be hard-wired
into them?<br>> > >>>><br>> > >>>> Thanks,<br>> > >>>> David<br>> > >>>><br>> > >>>>> memory_order_seq_cst is defined
as<br>> > >>>>> "Any operation
with this memory order is both an acquire<br>> > >>> operation and<br>> > >>>>> a release
operation, plus a single total order exists in<br>> > which<br>> > >>>> all<br>> > >>>>> threads<br>> > >>>>> observe
all modifications (see below) in the same order."<br>> > >>>>> (</font></tt><a href=http://en.cppreference.com/w/cpp/atomic/memory_order><tt><font size=2>http://en.cppreference.com/w/cpp/atomic/memory_order</font></tt></a><tt><font size=2><br>> > <</font></tt><a href=http://en.cppreference.com/w/cpp/atomic/memory_order><tt><font size=2>http://en.cppreference.com/w/cpp/atomic/memory_order</font></tt></a><tt><font size=2>>)<br>> > >>>>><br>> > >>>>> In my environment, g++ and
xlc generate following assemblies on<br>> > >>>> ppc64le.<br>> > >>>>> (interestingly, they generates
the same assemblies for any<br>> > >>>> memory_order)<br>> > >>>>><br>> > >>>>> g++ (4.9.2)<br>> > >>>>> 100008a4:
ac 04 00 7c sync<br>> > >>>>> 100008a8:
28 50 20 7d lwarx r9,0,r10<br>> > >>>>> 100008ac:
00 18 09 7c cmpw r9,r3<br>> > >>>>> 100008b0:
0c 00 c2 40 bne- 100008bc<br>> > >>>>> 100008b4:
2d 51 80 7c stwcx. r4,0,r10<br>> > >>>>> 100008b8:
f0 ff c2 40 bne- 100008a8<br>> > >>>>> 100008bc:
2c 01 00 4c isync<br>> > >>>>><br>> > >>>>> xlc (13.1.3)<br>> > >>>>> 10000888:
ac 04 00 7c sync<br>> > >>>>> 1000088c:
28 28 c0 7c lwarx r6,0,r5<br>> > >>>>> 10000890:
40 00 26 7c cmpld r6,r0<br>> > >>>>> 10000894:
0c 00 82 40 bne 100008a0<br>> > >>>>> 10000898:
2d 29 80 7c stwcx. r4,0,r5<br>> > >>>>> 1000089c:
f0 ff e2 40 bne+ 1000088c<br>> > >>>>> 100008a0:
2c 01 00 4c isync<br>> > >>>>><br>> > >>>>> On the other hand, the current
OpenJDK generates following<br>> > assemblies.<br>> > >>>>><br>> > >>>>> 508:
ac 04 00 7c sync<br>> > >>>>> 50c:
00 00 5c e9 ld r10,0(r28)<br>> > >>>>> 510:
00 50 3b 7c cmpd r27,r10<br>> > >>>>> 514:
1c 00 c2 40 bne- 530<br>> > >>>>> 518:
a8 40 5c 7d ldarx r10,r28,r8<br>> > >>>>> 51c:
00 50 3b 7c cmpd r27,r10<br>> > >>>>> 520:
10 00 c2 40 bne- 530<br>> > >>>>> 524:
ad 41 3c 7d stdcx. r9,r28,r8<br>> > >>>>> 528:
f0 ff c2 40 bne- 518<br>> > >>>>> 52c:
ac 04 00 7c sync<br>> > >>>>> 530:
00 50 bb 7f ...<br>> > >>>>><br>> > >>>>> Though we can ignore 50c-514
(because they are a duplicated guard<br>> > >>>>> condition),<br>> > >>>>> the last sync instruction
(52c) makes cmpxchg more strict than<br>> > >>>>> memory_order_seq_cst.<br>> > >>>>><br>> > >>>>> In some cases, the last sync
is necessary when this thread must be<br>> > >>>> able<br>> > >>>>> to read<br>> > >>>>> all of the changes in the
other threads while executing from<br>> > 508 to<br>> > >>>> 530<br>> > >>>>> (that processes compare-and-exchange).<br>> > >>>>><br>> > >>>>>> 2. Has there been a discussion
already, establishing that the<br>> > >>>> modified<br>> > >>>>>> GC code can indeed use
memory_order_relaxed? Otherwise who is<br>> > >>>>>> postulating that and based
on what evidence?<br>> > >>>>><br>> > >>>>> Volker and his colleagues
have investigated the current GC codes<br>> > >>>>> according to this.<br>> > >>>>><br>> > </font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2><br>> > <</font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2>><br>> > >>>> April/019079.html<br>> > >>>>> However, I believe, we need
comments of other GC expertsto change<br>> > >>>>> the shared codes.<br>> > >>>>><br>> > >>>>> Regards,<br>> > >>>>> Hiroshi<br>> > >>>>> -----------------------<br>> > >>>>> Hiroshi Horii, Ph.D.<br>> > >>>>> IBM Research - Tokyo<br>> > >>>>><br>> > >>>>><br>> > >>>>> David Holmes <david.holmes@oracle.com<br>> > <</font></tt><a href=mailto:david.holmes@oracle.com><tt><font size=2>mailto:david.holmes@oracle.com</font></tt></a><tt><font size=2>>>
wrote on 04/22/2016 21:57:07:<br>> > >>>>><br>> > >>>>>> From: David Holmes <david.holmes@oracle.com<br>> > <</font></tt><a href=mailto:david.holmes@oracle.com><tt><font size=2>mailto:david.holmes@oracle.com</font></tt></a><tt><font size=2>>><br>> > >>>>>> To: Hiroshi H Horii/Japan/IBM@IBMJP,
hotspot-runtime-<br>> > >>>>>> dev@openjdk.java.net <</font></tt><a href=mailto:dev@openjdk.java.net><tt><font size=2>mailto:dev@openjdk.java.net</font></tt></a><tt><font size=2>>,<br>> > hotspot-gc-dev@openjdk.java.net <</font></tt><a href="mailto:hotspot-gc-dev@openjdk.java.net"><tt><font size=2>mailto:hotspot-gc-dev@openjdk.java.net</font></tt></a><tt><font size=2>><br>> > >>>>>> Cc: Tim Ellison <Tim_Ellison@uk.ibm.com<br>> > <</font></tt><a href=mailto:Tim_Ellison@uk.ibm.com><tt><font size=2>mailto:Tim_Ellison@uk.ibm.com</font></tt></a><tt><font size=2>>>,<br>> > >>>>> ppc-aix-port-dev@openjdk.java.net<br>> > <</font></tt><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><tt><font size=2>mailto:ppc-aix-port-dev@openjdk.java.net</font></tt></a><tt><font size=2>><br>> > >>>>>> Date: 04/22/2016 21:58<br>> > >>>>>> Subject: Re: RFR(M): 8154736:
enhancement of cmpxchg and<br>> > >>>>>> copy_to_survivor for ppc64<br>> > >>>>>><br>> > >>>>>> Hi Hiroshi,<br>> > >>>>>><br>> > >>>>>> Two initial questions:<br>> > >>>>>><br>> > >>>>>> 1. Are the current cmpxchg
semantics exactly the same as<br>> > >>>>>> memory_order_seq_cst?<br>> > >>>>>><br>> > >>>>>> 2. Has there been a discussion
already, establishing that the<br>> > >>>> modified<br>> > >>>>>> GC code can indeed use
memory_order_relaxed? Otherwise who is<br>> > >>>>>> postulating that and based
on what evidence?<br>> > >>>>>><br>> > >>>>>> Missing memory barriers
have caused very difficult to track down<br>> > >>> bugs in<br>> > >>>>>> the past - very rare race
conditions. So any relaxation here has<br>> > >>>> to be<br>> > >>>>>> done with extreme confidence.<br>> > >>>>>><br>> > >>>>>> Thanks,<br>> > >>>>>> David<br>> > >>>>>><br>> > >>>>>> On 22/04/2016 10:28 PM,
Hiroshi H Horii wrote:<br>> > >>>>>>> Dear all:<br>> > >>>>>>><br>> > >>>>>>> Can I please request
reviews for the following change?<br>> > >>>>>>><br>> > >>>>>>> Code change:<br>> > >>>>>>><br>> > >>><br>> > </font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/</font></tt></a><tt><font size=2><br>> > <</font></tt><a href=http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/><tt><font size=2>http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/</font></tt></a><tt><font size=2>><br>> > >>>>>>> (I initially created
and Martin enhanced so much)<br>> > >>>>>>><br>> > >>>>>>> This change follows
the discussion started from this mail.<br>> > >>>>>>><br>> > </font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2><br>> > <</font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2>><br>> > >>>>>> April/018960.html<br>> > >>>>>>><br>> > >>>>>>> Description:<br>> > >>>>>>> This change provides
relaxed compare-and-exchange by introducing<br>> > >>>>>>> similar semantics
of C++ atomic memory operators, enum<br>> > >>>> memory_order.<br>> > >>>>>>> As described in atomic_linux_ppc.inline.hpp,
the current<br>> > >>>>> implementation of<br>> > >>>>>>> cmpxchg is fence_cmpxchg_acquire.
This implementation is useful<br>> > for<br>> > >>>>>>> general purposes because
twice calls of sync before and after<br>> > >>>>> cmpxchg will<br>> > >>>>>>> provide strict consistency.
However, they sometimes cause<br>> > overheads<br>> > >>>>>>> because<br>> > >>>>>>> sync instructions
are very expensive in the current POWER chip<br>> > >>> design.<br>> > >>>>>>> In addition, for the
other platforms, such as aarch64, this<br>> > strict<br>> > >>>>>>> semantics<br>> > >>>>>>> may cause some overheads
(according to the Andrew's mail).<br>> > >>>>>>><br>> > </font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2><br>> > <</font></tt><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><font size=2>http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</font></tt></a><tt><font size=2>><br>> > >>>>>> April/019073.html<br>> > >>>>>>><br>> > >>>>>>> With this change,
callers can explicitly specify constraints of<br>> > >>> memory<br>> > >>>>>>> ordering<br>> > >>>>>>> for cmpxchg with an
additional parameter, memory_order order.<br>> > >>>>>>><br>> > >>>>>>> typedef enum memory_order
{<br>> > >>>>>>> memory_order_relaxed,<br>> > >>>>>>> memory_order_consume,<br>> > >>>>>>> memory_order_acquire,<br>> > >>>>>>> memory_order_release,<br>> > >>>>>>> memory_order_acq_rel,<br>> > >>>>>>> memory_order_seq_cst<br>> > >>>>>>> } memory_order;<br>> > >>>>>>><br>> > >>>>>>> Because the default
value of the parameter is<br>> > memory_order_seq_cst,<br>> > >>>>>>> existing codes can
use the same semantics of cmpxchg without any<br>> > >>>>>>> modification. The
relaxed cmpxchg is implemented only on ppc<br>> > >>>>>>> in this changeset.
Therefore, the behavior on the other<br>> > platforms<br>> > >>> will<br>> > >>>>>>> not be changed with
this changeset.<br>> > >>>>>>><br>> > >>>>>>> In addition, with
the new parameter of cmpxchg, this change<br>> > >>>> improves<br>> > >>>>>>> performance of copy_to_survivor
in the parallel GC.<br>> > >>>>>>> copy_to_survivor changes
forward pointers by using cmpxchg. This<br>> > >>>>>>> operation doesn't
require any sync instructions. A pointer is<br>> > >>> changed<br>> > >>>>>>> at most once in a
GC and when cmpxchg fails, the latest<br>> > pointer is<br>> > >>>>>>> available for the
caller. cas_set_mark and cas_forward_to are<br>> > >>> extended<br>> > >>>>>>> with an additional
memory_order parameter as cmpxchg and<br>> > >>>>> copy_to_survivor<br>> > >>>>>>> uses memory_order_relaxed
to modify the forward pointers.<br>> > >>>>>>><br>> > >>>>>>> Summary of source
code changes:<br>> > >>>>>>><br>> > >>>>>>> * src/share/vm/runtime/atomic.hpp<br>> > >>>>>>>
- Defines enum memory_order and adds a parameter to<br>> > cmpxchg.<br>> > >>>>>>><br>> > >>>>>>> * src/share/vm/runtime/atomic.cpp<br>> > >>>>>>> * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp<br>> > >>>>>>> * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp<br>> > >>>>>>> * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp<br>> > >>>>>>> * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp<br>> > >>>>>>> * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp<br>> > >>>>>>> * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp<br>> > >>>>>>> * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp<br>> > >>>>>>> * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp<br>> > >>>>>>> * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp<br>> > >>>>>>>
- Added a parameter for each cmpxchg function to follow<br>> > >>>>>>>
the change of atomic.hpp. Their implementations are not<br>> > >>>>> changed.<br>> > >>>>>>><br>> > >>>>>>> * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp<br>> > >>>>>>> * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp<br>> > >>>>>>>
- Added a parameter for each cmpxchg function to follow<br>> > >>>>>>>
the change of atomic.hpp. In addition, implementations<br>> > >>>>>>>
are changed corresponding to the specified<br>> > memory_order.<br>> > >>>>>>><br>> > >>>>>>> * src/share/vm/oops/oop.hpp<br>> > >>>>>>> * src/share/vm/oops/oop.inline.hpp<br>> > >>>>>>>
- Add a memory_order parameter to use relaxed cmpxchg in<br>> > >>>>>>>
cas_set_mark and cas_forward_to.<br>> > >>>>>>><br>> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.cpp<br>> > >>>>>>> * src/share/vm/gc/parallel/psPromotionManager.inline.hpp<br>> > >>>>>>><br>> > >>>>>>> Martin tested this
changeset on linuxx86_64, linuxppc64le and<br>> > >>>>>>> darwinintel64.<br>> > >>>>>>> Though more time is
needed to test on the other platform, we<br>> > would<br>> > >>>>> like to<br>> > >>>>>>> ask<br>> > >>>>>>> reviews and start
discussion on this changeset.<br>> > >>>>>>> I also tested this
changeset with SPECjbb2013 and confirmed that<br>> > gc<br>> > >>>>> pause<br>> > >>>>>>> time<br>> > >>>>>>> is reduced.<br>> > >>>>>>><br>> > >>>>>>> Regards,<br>> > >>>>>>> Hiroshi<br>> > >>>>>>> -----------------------<br>> > >>>>>>> Hiroshi Horii, Ph.D.<br>> > >>>>>>> IBM Research - Tokyo<br>> > >>>>>>><br>> > >>>>>>><br>> > >>>>>><br>> > >>>>><br>> > >>>><br>> > >>><br>> ><br>> ><br>> ><br>> ><br>> ><br>> ><br>> <br></font></tt><BR>