<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
{font-family:"Cambria Math";
panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
{font-family:Calibri;
panose-1:2 15 5 2 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
a:link, span.MsoHyperlink
{mso-style-priority:99;
color:blue;
text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
{mso-style-priority:99;
color:purple;
text-decoration:underline;}
tt
{mso-style-priority:99;
font-family:"Courier New";}
span.EmailStyle18
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:#1F497D;}
.MsoChpDefault
{mso-style-type:export-only;
font-family:"Calibri",sans-serif;
mso-fareast-language:EN-US;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
div.WordSection1
{page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="DE" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Hi David and Hiroshi,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">thank you very much for this interesting question and analysis.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">I think we shouldn’t better use an own enum (e.g. like AccessKind in library_call.cpp).<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Otherwise we’ll get trouble when we switch to C++11. Would you agree?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Would it be better to split this bug into 2 and discuss the cmpxchg interface change on the runtime list and the GC change
on the gc list?<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif;color:#1F497D;mso-fareast-language:EN-US">Martin<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif">From:</span></b><span lang="EN-US" style="font-size:11.0pt;font-family:"Calibri",sans-serif"> Hiroshi H Horii [mailto:HORII@jp.ibm.com]
<br>
<b>Sent:</b> Montag, 25. April 2016 09:10<br>
<b>To:</b> David Holmes <david.holmes@oracle.com><br>
<b>Cc:</b> hotspot-gc-dev@openjdk.java.net; hotspot-runtime-dev@openjdk.java.net; ppc-aix-port-dev@openjdk.java.net; Tim Ellison <Tim_Ellison@uk.ibm.com>; Volker Simonis <volker.simonis@gmail.com>; Doerr, Martin <martin.doerr@sap.com>; Lindenmaier, Goetz <goetz.lindenmaier@sap.com><br>
<b>Subject:</b> Re: RFR(M): 8154736: enhancement of cmpxchg and copy_to_survivor for ppc64<o:p></o:p></span></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal" style="margin-bottom:12.0pt"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi David,</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Thank you for your comments and questions.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> 1. Are the current cmpxchg semantics exactly the same as
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> memory_order_seq_cst?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">This is very good question..</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I guess, cmpxchg needs a more conservative constraint for memory ordering</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">than C++11, to add sync after a compare-and-exchange operation.
</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Could someone give comments or thoughts?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">memory_order_seq_cst is defined as
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> "Any operation with this memory order is both an acquire operation and
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> a release operation, plus a single total order exists in which all threads</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> observe all modifications (see below) in the same order."</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">(</span><a href="http://en.cppreference.com/w/cpp/atomic/memory_order"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://en.cppreference.com/w/cpp/atomic/memory_order</span></a><span style="font-size:10.0pt;font-family:"Arial",sans-serif">)</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">In my environment, g++ and xlc generate following assemblies on ppc64le.</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">(interestingly, they generates the same assemblies for any memory_order)</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">g++ (4.9.2)</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008a4: ac 04 00 7c sync </span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008a8: 28 50 20 7d lwarx r9,0,r10</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008ac: 00 18 09 7c cmpw r9,r3</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008b0: 0c 00 c2 40 bne- 100008bc</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008b4: 2d 51 80 7c stwcx. r4,0,r10</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008b8: f0 ff c2 40 bne- 100008a8</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008bc: 2c 01 00 4c isync</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">xlc (13.1.3)</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 10000888: ac 04 00 7c sync </span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 1000088c: 28 28 c0 7c lwarx r6,0,r5</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 10000890: 40 00 26 7c cmpld r6,r0</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 10000894: 0c 00 82 40 bne 100008a0</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 10000898: 2d 29 80 7c stwcx. r4,0,r5</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 1000089c: f0 ff e2 40 bne+ 1000088c</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 100008a0: 2c 01 00 4c isync</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">On the other hand, the current OpenJDK generates following assemblies.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 508: ac 04 00 7c sync </span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 50c: 00 00 5c e9 ld r10,0(r28)</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 510: 00 50 3b 7c cmpd r27,r10</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 514: 1c 00 c2 40 bne- 530</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 518: a8 40 5c 7d ldarx r10,r28,r8</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 51c: 00 50 3b 7c cmpd r27,r10</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 520: 10 00 c2 40 bne- 530</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 524: ad 41 3c 7d stdcx. r9,r28,r8</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 528: f0 ff c2 40 bne- 518</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 52c: ac 04 00 7c sync </span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif"> 530: 00 50 bb 7f ...</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Though we can ignore 50c-514 (because they are a duplicated guard condition),
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">the last sync instruction (52c) makes cmpxchg more strict than
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">memory_order_seq_cst.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">In some cases, the last sync is necessary when this thread must be able to read</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">all of the changes in the other threads while executing from 508 to 530
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">(that processes compare-and-exchange).</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> 2. Has there been a discussion already, establishing that the modified
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> GC code can indeed use memory_order_relaxed? Otherwise who is
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> postulating that and based on what evidence?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Volker and his colleagues have investigated the current GC codes according to this.</span><br>
<a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-April/019079.html</span></a><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">However, I believe, we need comments of other GC experts to change
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">the shared codes.</span><br>
<br>
<span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">Regards,<br>
Hiroshi<br>
-----------------------<br>
Hiroshi Horii, Ph.D.<br>
IBM Research - Tokyo<br>
</span><span lang="EN-US"><br>
<br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">David Holmes <</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:david.holmes@oracle.com"><span lang="EN-US">david.holmes@oracle.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>
wrote on 04/22/2016 21:57:07:</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>> From: David Holmes <</tt></span><tt><span style="font-size:10.0pt"><a href="mailto:david.holmes@oracle.com"><span lang="EN-US">david.holmes@oracle.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">></span></tt><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> To: Hiroshi H Horii/Japan/IBM@IBMJP, hotspot-runtime-</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> </tt></span><tt><span style="font-size:10.0pt"><a href="mailto:dev@openjdk.java.net"><span lang="EN-US">dev@openjdk.java.net</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">,
</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:hotspot-gc-dev@openjdk.java.net"><span lang="EN-US">hotspot-gc-dev@openjdk.java.net</span></a></span></tt><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> Cc: Tim Ellison <</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:Tim_Ellison@uk.ibm.com"><span lang="EN-US">Tim_Ellison@uk.ibm.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>,
</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:ppc-aix-port-dev@openjdk.java.net"><span lang="EN-US">ppc-aix-port-dev@openjdk.java.net</span></a></span></tt><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> Date: 04/22/2016 21:58</span></tt><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and
</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> copy_to_survivor for ppc64</tt></span><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> </span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Hi Hiroshi,</tt><br>
<tt>> </tt><br>
<tt>> Two initial questions:</tt><br>
<tt>> </tt><br>
<tt>> 1. </tt></span><tt><span style="font-size:10.0pt">Are the current cmpxchg semantics exactly the same as
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> memory_order_seq_cst?</tt><br>
<tt>> </tt><br>
<tt>> 2. Has there been a discussion already, establishing that the modified </tt>
<br>
<tt>> GC code can indeed use memory_order_relaxed? Otherwise who is </tt><br>
<tt>> postulating that and based on what evidence?</tt><br>
<tt>> </tt><br>
<tt>> Missing memory barriers have caused very difficult to track down bugs in </tt>
<br>
<tt>> the past - very rare race conditions. So any relaxation here has to be </tt>
<br>
<tt>> done with extreme confidence.</tt><br>
<tt>> </tt><br>
<tt>> Thanks,</tt><br>
<tt>> David</tt><br>
<tt>> </tt><br>
<tt>> On 22/04/2016 10:28 PM, Hiroshi H Horii wrote:</tt><br>
<tt>> > Dear all:</tt><br>
<tt>> ></tt><br>
<tt>> > Can I please request reviews for the following change?</tt><br>
<tt>> ></tt><br>
<tt>> > Code change:</tt><br>
<tt>> > </tt></span><a href="http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/"><tt><span style="font-size:10.0pt">http://cr.openjdk.java.net/~mdoerr/8154736_copy_to_survivor/webrev.00/</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> > (I initially created and Martin enhanced so much)</tt><br>
<tt>> ></tt><br>
<tt>> > This change follows the discussion started from this mail.</tt><br>
<tt>> > </tt></span><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><span style="font-size:10.0pt">http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> April/018960.html</tt><br>
<tt>> ></tt><br>
<tt>> > Description:</tt><br>
<tt>> > This change provides relaxed compare-and-exchange by introducing</tt><br>
<tt>> > similar semantics of C++ atomic memory operators, enum memory_order.</tt><br>
<tt>> > As described in atomic_linux_ppc.inline.hpp, the current implementation of</tt><br>
<tt>> > cmpxchg is fence_cmpxchg_acquire. This implementation is useful for</tt><br>
<tt>> > general purposes because twice calls of sync before and after cmpxchg will</tt><br>
<tt>> > provide strict consistency. However, they sometimes cause overheads</tt><br>
<tt>> > because</tt><br>
<tt>> > sync instructions are very expensive in the current POWER chip design.</tt><br>
<tt>> > In addition, for the other platforms, such as aarch64, this strict</tt><br>
<tt>> > semantics</tt><br>
<tt>> > may cause some overheads (according to the Andrew's mail).</tt><br>
<tt>> > </tt></span><a href="http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-"><tt><span style="font-size:10.0pt">http://mail.openjdk.java.net/pipermail/hotspot-runtime-dev/2016-</span></tt></a><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> April/019073.html</tt><br>
<tt>> ></tt><br>
<tt>> > With this change, callers can explicitly specify constraints of memory</tt><br>
<tt>> > ordering</tt><br>
<tt>> > for cmpxchg with an additional parameter, memory_order order.</tt><br>
<tt>> ></tt><br>
<tt>> > typedef enum memory_order {</tt><br>
<tt>> > memory_order_relaxed,</tt><br>
<tt>> > memory_order_consume,</tt><br>
<tt>> > memory_order_acquire,</tt><br>
<tt>> > memory_order_release,</tt><br>
<tt>> > memory_order_acq_rel,</tt><br>
<tt>> > memory_order_seq_cst</tt><br>
<tt>> > } memory_order;</tt><br>
<tt>> ></tt><br>
<tt>> > Because the default value of the parameter is memory_order_seq_cst,</tt><br>
<tt>> > existing codes can use the same semantics of cmpxchg without any</tt><br>
<tt>> > modification. The relaxed cmpxchg is implemented only on ppc</tt><br>
<tt>> > in this changeset. Therefore, the behavior on the other platforms will</tt><br>
<tt>> > not be changed with this changeset.</tt><br>
<tt>> ></tt><br>
<tt>> > In addition, with the new parameter of cmpxchg, this change improves</tt><br>
<tt>> > performance of copy_to_survivor in the parallel GC.</tt><br>
<tt>> > copy_to_survivor changes forward pointers by using cmpxchg. This</tt><br>
<tt>> > operation doesn't require any sync instructions. A pointer is changed</tt><br>
<tt>> > at most once in a GC and when cmpxchg fails, the latest pointer is</tt><br>
<tt>> > available for the caller. cas_set_mark and cas_forward_to are extended</tt><br>
<tt>> > with an additional memory_order parameter as cmpxchg and copy_to_survivor</tt><br>
<tt>> > uses memory_order_relaxed to modify the forward pointers.</tt><br>
<tt>> ></tt><br>
<tt>> > Summary of source code changes:</tt><br>
<tt>> ></tt><br>
<tt>> > * src/share/vm/runtime/atomic.hpp</tt><br>
<tt>> > - Defines enum memory_order and adds a parameter to cmpxchg.</tt><br>
<tt>> ></tt><br>
<tt>> > * src/share/vm/runtime/atomic.cpp</tt><br>
<tt>> > * src/os_cpu/bsd_x86/vm/atomic_bsd_x86.inline.hpp</tt><br>
<tt>> > * src/os_cpu/bsd_zero/vm/atomic_bsd_zero.inline.hpp</tt><br>
<tt>> > * src/os_cpu/linux_aarch64/vm/atomic_linux_aarch64.inline.hpp</tt><br>
<tt>> > * src/os_cpu/linux_sparc/vm/atomic_linux_sparc.inline.hpp</tt><br>
<tt>> > * src/os_cpu/linux_x86/vm/atomic_linux_x86.inline.hpp</tt><br>
<tt>> > * src/os_cpu/linux_zero/vm/atomic_linux_zero.inline.hpp</tt><br>
<tt>> > * src/os_cpu/solaris_sparc/vm/atomic_solaris_sparc.inline.hpp</tt><br>
<tt>> > * src/os_cpu/solaris_x86/vm/atomic_solaris_x86.inline.hpp</tt><br>
<tt>> > * src/os_cpu/windows_x86/vm/atomic_windows_x86.inline.hpp</tt><br>
<tt>> > - Added a parameter for each cmpxchg function to follow</tt><br>
<tt>> > the change of atomic.hpp. Their implementations are not changed.</tt><br>
<tt>> ></tt><br>
<tt>> > * src/os_cpu/aix_ppc/vm/atomic_aix_ppc.inline.hpp</tt><br>
<tt>> > * src/os_cpu/linux_ppc/vm/atomic_linux_ppc.inline.hpp</tt><br>
<tt>> > - Added a parameter for each cmpxchg function to follow</tt><br>
<tt>> > the change of atomic.hpp. In addition, implementations</tt><br>
<tt>> > are changed corresponding to the specified memory_order.</tt><br>
<tt>> ></tt><br>
<tt>> > * src/share/vm/oops/oop.hpp</tt><br>
<tt>> > * src/share/vm/oops/oop.inline.hpp</tt><br>
<tt>> > - Add a memory_order parameter to use relaxed cmpxchg in</tt><br>
<tt>> > cas_set_mark and cas_forward_to.</tt><br>
<tt>> ></tt><br>
<tt>> > * src/share/vm/gc/parallel/psPromotionManager.cpp</tt><br>
<tt>> > * src/share/vm/gc/parallel/psPromotionManager.inline.hpp</tt><br>
<tt>> ></tt><br>
<tt>> > Martin tested this changeset on linuxx86_64, linuxppc64le and</tt><br>
<tt>> > darwinintel64.</tt><br>
<tt>> > Though more time is needed to test on the other platform, we would like to</tt><br>
<tt>> > ask</tt><br>
<tt>> > reviews and start discussion on this changeset.</tt><br>
<tt>> > I also tested this changeset with SPECjbb2013 and confirmed that gc pause</tt><br>
<tt>> > time</tt><br>
<tt>> > is reduced.</tt><br>
<tt>> ></tt><br>
<tt>> > Regards,</tt><br>
<tt>> > Hiroshi</tt><br>
<tt>> > -----------------------</tt><br>
<tt>> > Hiroshi Horii, Ph.D.</tt><br>
<tt>> > IBM Research - Tokyo</tt><br>
<tt>> ></tt><br>
<tt>> ></tt><br>
<tt>> </tt></span><o:p></o:p></p>
</div>
</body>
</html>