<div dir="ltr">Dear Hiroshi,<div><br></div><div>In hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:266 the log line reads data from the forwardee even when the CAS fails. I believe those reads will be unsafe without barriers after the copy of the content of the object.</div><div><br></div><div>hotspot/src/share/vm/gc/parallel/psPromotionManager.inline.hpp:288 same problem as in line 266<br></div><div><br></div><div>I would argue that the logging should only happen if the thread successfully copied the object and CAS failures should be logged separately without reading data from the forwardee.</div><div><br></div><div>BTW, unrelated to your change: It seems like the logging in line 266 should be guarded by something like "if (log_develop_is_enabled(Trace, gc, scavenge)" like the logging in line 288.</div><div><br></div><div>Carsten</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Sep 29, 2016 at 8:00 AM, Hiroshi H Horii <span dir="ltr"><<a href="mailto:HORII@jp.ibm.com" target="_blank">HORII@jp.ibm.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">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 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>
<a href="http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~<wbr>mdoerr/8154736_copy_to_<wbr>survivor/webrev.01/</a><br>
JIRA: <a href="https://bugs.openjdk.java.net/browse/JDK-8154736" rel="noreferrer" target="_blank">https://bugs.openjdk.java.net/<wbr>browse/JDK-8154736</a><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 compiler-dev,<br>
but also from gc-dev.<br>
<span class=""><br>
Regards,<br>
Hiroshi<br>
-----------------------<br>
Hiroshi Horii, Ph.D.<br>
IBM Research - Tokyo<br>
<br>
<br>
<br>
<br>
</span>From: David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>><br>
To: "Doerr, Martin" <<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>>, Hiroshi H<br>
Horii/Japan/IBM@IBMJP<br>
<span class="">Cc: Tim Ellison <<a href="mailto:Tim_Ellison@uk.ibm.com">Tim_Ellison@uk.ibm.com</a>>,<br>
</span>"<a href="mailto:ppc-aix-port-dev@openjdk.java.net">ppc-aix-port-dev@openjdk.<wbr>java.net</a>" <<a href="mailto:ppc-aix-port-dev@openjdk.java.net">ppc-aix-port-dev@openjdk.<wbr>java.net</a>>,<br>
"<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.<wbr>net</a>" <<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.<wbr>net</a>>,<br>
"<a href="mailto:hotspot-runtime-dev@openjdk.java.net">hotspot-runtime-dev@openjdk.<wbr>java.net</a>"<br>
<<a href="mailto:hotspot-runtime-dev@openjdk.java.net">hotspot-runtime-dev@openjdk.<wbr>java.net</a>><br>
Date: 05/10/2016 19:31<br>
<div class="HOEnZb"><div class="h5">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>
> <a href="http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.01/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~<wbr>mdoerr/8155949_relaxed_cas/<wbr>webrev.01/</a><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>
mailto:<a href="mailto:hotspot-runtime-dev-bounces@openjdk.java.net">hotspot-runtime-dev-<wbr>bounces@openjdk.java.net</a>] On Behalf Of David<br>
Holmes<br>
> Sent: Dienstag, 10. Mai 2016 11:11<br>
> To: Hiroshi H Horii <<a href="mailto:HORII@jp.ibm.com">HORII@jp.ibm.com</a>><br>
> Cc: Tim Ellison <<a href="mailto:Tim_Ellison@uk.ibm.com">Tim_Ellison@uk.ibm.com</a>>;<br>
<a href="mailto:ppc-aix-port-dev@openjdk.java.net">ppc-aix-port-dev@openjdk.java.<wbr>net</a>; <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.<wbr>net</a>;<br>
<a href="mailto:hotspot-runtime-dev@openjdk.java.net">hotspot-runtime-dev@openjdk.<wbr>java.net</a><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.<wbr>daholme/s/hotspot/src/os_cpu/<wbr>solaris_x86/vm/atomic_solaris_<wbr>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.<wbr>daholme/s/hotspot/src/os_cpu/<wbr>solaris_x86/vm/atomic_solaris_<wbr>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>
>>> <a href="http://cr.openjdk.java.net/~mdoerr/8155949_relaxed_cas/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~<wbr>mdoerr/8155949_relaxed_cas/<wbr>webrev.00/</a><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 (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 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 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 <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote on 05/04/2016 14:55:29:<br>
>>><br>
>>>> From: David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>><br>
>>>> To: Hiroshi H Horii/Japan/IBM@IBMJP<br>
>>>> Cc: <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.<wbr>net</a>, hotspot-runtime-<br>
>>>> <a href="mailto:dev@openjdk.java.net">dev@openjdk.java.net</a>, <a href="mailto:ppc-aix-port-dev@openjdk.java.net">ppc-aix-port-dev@openjdk.java.<wbr>net</a>, Tim Ellison<br>
>>>> <<a href="mailto:Tim_Ellison@uk.ibm.com">Tim_Ellison@uk.ibm.com</a>>, Volker Simonis <<a href="mailto:volker.simonis@gmail.com">volker.simonis@gmail.com</a>>,<br>
>>>> "Doerr, Martin" <<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>>, "Lindenmaier, Goetz"<br>
>>>> <<a href="mailto:goetz.lindenmaier@sap.com">goetz.lindenmaier@sap.com</a>><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 implementations are<br>
>>>> clearly ignoring the memory_order attribute and there is no 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. oopDesc::cas_set_mark,<br>
>>>> oopDesc::cas_forward_to, unless those methods can sensibly be 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 which<br>
>>>> all<br>
>>>>> threads<br>
>>>>> observe all modifications (see below) in the same order."<br>
>>>>> (<a href="http://en.cppreference.com/w/cpp/atomic/memory_order" rel="noreferrer" target="_blank">http://en.cppreference.com/w/<wbr>cpp/atomic/memory_order</a>)<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 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>
>>>>> <a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/hotspot-runtime-dev/<wbr>2016-</a><br>
>>>> April/019079.html<br>
>>>>> However, I believe, we need comments of other GC experts to 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 <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>> wrote on 04/22/2016 21:57:07:<br>
>>>>><br>
>>>>>> From: David Holmes <<a href="mailto:david.holmes@oracle.com">david.holmes@oracle.com</a>><br>
>>>>>> To: Hiroshi H Horii/Japan/IBM@IBMJP, hotspot-runtime-<br>
>>>>>> <a href="mailto:dev@openjdk.java.net">dev@openjdk.java.net</a>, <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.<wbr>net</a><br>
>>>>>> Cc: Tim Ellison <<a href="mailto:Tim_Ellison@uk.ibm.com">Tim_Ellison@uk.ibm.com</a>>,<br>
>>>>> <a href="mailto:ppc-aix-port-dev@openjdk.java.net">ppc-aix-port-dev@openjdk.java.<wbr>net</a><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>
>>> <a href="http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/" rel="noreferrer" target="_blank">http://cr.openjdk.java.net/~<wbr>mdoerr/8154736_copy_to_<wbr>survivor/webrev.00/</a><br>
>>>>>>> (I initially created and Martin enhanced so much)<br>
>>>>>>><br>
>>>>>>> This change follows the discussion started from this mail.<br>
>>>>>>> <a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/hotspot-runtime-dev/<wbr>2016-</a><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 strict<br>
>>>>>>> semantics<br>
>>>>>>> may cause some overheads (according to the Andrew's mail).<br>
>>>>>>> <a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-" rel="noreferrer" target="_blank">http://mail.openjdk.java.net/<wbr>pipermail/hotspot-runtime-dev/<wbr>2016-</a><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 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 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.<wbr>hpp<br>
>>>>>>> - Defines enum memory_order and adds a parameter to cmpxchg.<br>
>>>>>>><br>
>>>>>>> * src/share/vm/runtime/atomic.<wbr>cpp<br>
>>>>>>> * src/os_cpu/bsd_x86/vm/atomic_<wbr>bsd_x86.inline.hpp<br>
>>>>>>> * src/os_cpu/bsd_zero/vm/atomic_<wbr>bsd_zero.inline.hpp<br>
>>>>>>> * src/os_cpu/linux_aarch64/vm/<wbr>atomic_linux_aarch64.inline.<wbr>hpp<br>
>>>>>>> * src/os_cpu/linux_sparc/vm/<wbr>atomic_linux_sparc.inline.hpp<br>
>>>>>>> * src/os_cpu/linux_x86/vm/<wbr>atomic_linux_x86.inline.hpp<br>
>>>>>>> * src/os_cpu/linux_zero/vm/<wbr>atomic_linux_zero.inline.hpp<br>
>>>>>>> * src/os_cpu/solaris_sparc/vm/<wbr>atomic_solaris_sparc.inline.<wbr>hpp<br>
>>>>>>> * src/os_cpu/solaris_x86/vm/<wbr>atomic_solaris_x86.inline.hpp<br>
>>>>>>> * src/os_cpu/windows_x86/vm/<wbr>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_<wbr>aix_ppc.inline.hpp<br>
>>>>>>> * src/os_cpu/linux_ppc/vm/<wbr>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 memory_order.<br>
>>>>>>><br>
>>>>>>> * src/share/vm/oops/oop.hpp<br>
>>>>>>> * src/share/vm/oops/oop.inline.<wbr>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/<wbr>psPromotionManager.cpp<br>
>>>>>>> * src/share/vm/gc/parallel/<wbr>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 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>
</div></div></blockquote></div><br></div>