<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=utf-8">
<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";}
p.MsoListParagraph, li.MsoListParagraph, div.MsoListParagraph
{mso-style-priority:34;
margin-top:0cm;
margin-right:0cm;
margin-bottom:0cm;
margin-left:36.0pt;
margin-bottom:.0001pt;
font-size:12.0pt;
font-family:"Times New Roman",serif;}
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 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:10.0pt;font-family:"Arial",sans-serif">> I think, to use the enum and semantics of C++11, callers of cmpxchg need to call
</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">> memory-barrier after cmpxchg when all of updates in the other processes must be</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">> available for the following instructions of the cmpxchg. Correct?</span><span lang="EN-US"><br>
<br>
</span><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 the problem is that our current C++ code doesn’t use seq_cst semantics for volatile loads.<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">The sync at the end of the cmpxchg is only needed if a volatile load is following which is not preceded by a sync instruction.<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">As long as this is the case, I think we should keep the sync at the end of cmpxchg.<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:10.0pt;font-family:"Arial",sans-serif">> Do you mean that a new cmpxchg with relaxed semantics will be added and used in
</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">> the GC change? Or, after the discussion of the new cmpxchg interface, will be</span><span lang="EN-US"><br>
</span><span lang="EN-US" style="font-size:10.0pt;font-family:"Arial",sans-serif">> the discussion of the GC change started?</span><span lang="EN-US"><br>
<br>
</span><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">The second.<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> Mittwoch, 27. April 2016 05:34<br>
<b>To:</b> Doerr, Martin <martin.doerr@sap.com><br>
<b>Cc:</b> David Holmes <david.holmes@oracle.com>; Lindenmaier, Goetz <goetz.lindenmaier@sap.com>; 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><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"><span style="font-size:10.0pt;font-family:"Arial",sans-serif">Hi Martin,</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> I think we shouldn’t better use an own enum (e.g. like AccessKind in</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> library_call.cpp).</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> Otherwise we’ll get trouble when we switch to C++11. Would you agree?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I agree. </span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">I think, to use the enum and semantics of C++11, callers of cmpxchg need to call
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">memory-barrier after cmpxchg when all of updates in the other processes must be</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">available for the following instructions of the cmpxchg. Correct?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> Would it be better to split this bug into 2 and discuss the cmpxchg
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">> interface change on the runtime list and the GC change on the gc list?</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">Do you mean that a new cmpxchg with relaxed semantics will be added and used in
</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">the GC change? Or, after the discussion of the new cmpxchg interface, will be</span><br>
<span style="font-size:10.0pt;font-family:"Arial",sans-serif">the discussion of the GC change started?</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">"Doerr, Martin" <</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:martin.doerr@sap.com"><span lang="EN-US">martin.doerr@sap.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>
wrote on 04/25/2016 19:25:15:</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<br>
<tt>> From: "Doerr, Martin" <</tt></span><tt><span style="font-size:10.0pt"><a href="mailto:martin.doerr@sap.com"><span lang="EN-US">martin.doerr@sap.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, 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">></span></tt><span lang="EN-US"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> Cc: "</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><tt><span lang="EN-US" style="font-size:10.0pt">"
<hotspot-gc-</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-runtime-dev@openjdk.java.net"><span lang="EN-US">hotspot-runtime-dev@openjdk.java.net</span></a></span></tt><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>> <</tt></span><tt><span style="font-size:10.0pt"><a href="mailto:hotspot-runtime-dev@openjdk.java.net"><span lang="EN-US">hotspot-runtime-dev@openjdk.java.net</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>, "ppc-aix-port-</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:ppc-aix-port-dev@openjdk.java.net"><span lang="EN-US">ppc-aix-port-dev@openjdk.java.net</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>,
Tim </span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Ellison <</tt></span><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">>, Volker Simonis
</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:volker.simonis@gmail.com"><span lang="EN-US">volker.simonis@gmail.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>, "Lindenmaier, Goetz" <</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:goetz.lindenmaier@sap.com"><span lang="EN-US">goetz.lindenmaier@sap.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">> Date: 04/25/2016 19:26</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 David and Hiroshi,</tt></span><span lang="EN-US"><br>
</span><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">> thank you very much for this interesting question and analysis.</span></tt><span lang="EN-US"><br>
</span><tt><span style="font-size:10.0pt">> </span></tt><br>
<tt><span style="font-size:10.0pt">> I think we shouldn’t better use an own enum (e.g. like AccessKind in</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> library_call.cpp).</tt></span><br>
<tt><span style="font-size:10.0pt">> Otherwise we’ll get trouble when we switch to C++11. Would you agree?</span></tt><br>
<tt><span style="font-size:10.0pt">> </span></tt><br>
<tt><span style="font-size:10.0pt">> Would it be better to split this bug into 2 and discuss the cmpxchg
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> interface change on the runtime list and the GC change on the gc list?</tt></span><br>
<tt><span style="font-size:10.0pt">> </span></tt><br>
<tt><span style="font-size:10.0pt">> Best regards,</span></tt><br>
<tt><span style="font-size:10.0pt">> Martin</span></tt><br>
<tt><span style="font-size:10.0pt">> </span></tt><br>
<tt><span style="font-size:10.0pt">> From: Hiroshi H Horii [</span></tt><a href="mailto:HORII@jp.ibm.com"><tt><span style="font-size:10.0pt">mailto:HORII@jp.ibm.com</span></tt></a><tt><span style="font-size:10.0pt">]
</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Sent: Montag, 25. </tt></span><tt><span lang="EN-US" style="font-size:10.0pt">April 2016 09:10</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> To: 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" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> Cc: </tt></span><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><tt><span lang="EN-US" style="font-size:10.0pt">; 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:ppc-aix-port-dev@openjdk.java.net"><span lang="EN-US">ppc-aix-port-dev@openjdk.java.net</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">; Tim Ellison</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: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">>; Volker Simonis <</span></tt><tt><span style="font-size:10.0pt"><a href="mailto:volker.simonis@gmail.com"><span lang="EN-US">volker.simonis@gmail.com</span></a></span></tt><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>> Doerr, Martin <</tt></span><tt><span style="font-size:10.0pt"><a href="mailto:martin.doerr@sap.com"><span lang="EN-US">martin.doerr@sap.com</span></a></span></tt><tt><span lang="EN-US" style="font-size:10.0pt">>; Lindenmaier, Goetz
</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:goetz.lindenmaier@sap.com"><span lang="EN-US">goetz.lindenmaier@sap.com</span></a></span></tt><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>> Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and </tt><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"><br>
</span><tt><span lang="EN-US" style="font-size:10.0pt">> Hi David,</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> </tt><br>
<tt>> Thank you for your comments and questions.</tt><br>
</span><tt><span style="font-size:10.0pt">> </span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> > 1. Are the current cmpxchg semantics exactly the same as </tt><br>
<tt>> > memory_order_seq_cst?</tt><br>
<tt>> </tt><br>
<tt>> This is very good question..</tt><br>
<tt>> </tt><br>
<tt>> I guess, cmpxchg needs a more conservative constraint for memory ordering</tt><br>
<tt>> than C++11, to add sync after a compare-and-exchange operation. </tt><br>
<tt>> </tt><br>
<tt>> Could someone give comments or thoughts?</tt><br>
<tt>> </tt><br>
<tt>> memory_order_seq_cst is defined as </tt><br>
<tt>> "Any operation with this memory order is both an acquire operation and </tt>
<br>
<tt>> a release operation, plus a single total order exists in which </tt><br>
<tt>> all threads</tt><br>
<tt>> observe all modifications (see below) in the same order."</tt><br>
<tt>> (</tt></span><a href="http://en.cppreference.com/w/cpp/atomic/memory_order"><tt><span style="font-size:10.0pt">http://en.cppreference.com/w/cpp/atomic/memory_order</span></tt></a><tt><span style="font-size:10.0pt">)</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> </tt><br>
<tt>> In my environment, g++ and xlc generate following assemblies on ppc64le.</tt><br>
<tt>> (interestingly, they generates the same assemblies for any memory_order)</tt><br>
<tt>> </tt><br>
<tt>> g++ (4.9.2)</tt><br>
<tt>> 100008a4: ac 04 00 7c sync </tt><br>
<tt>> 100008a8: 28 50 20 7d lwarx r9,0,r10</tt><br>
<tt>> 100008ac: 00 18 09 7c cmpw r9,r3</tt><br>
<tt>> 100008b0: 0c 00 c2 40 bne- 100008bc</tt><br>
<tt>> 100008b4: 2d 51 80 7c stwcx. r4,0,r10</tt><br>
<tt>> 100008b8: f0 ff c2 40 bne- 100008a8</tt><br>
<tt>> 100008bc: 2c 01 00 4c isync</tt><br>
<tt>> </tt><br>
<tt>> xlc (13.1.3)</tt><br>
<tt>> 10000888: ac 04 00 7c sync </tt><br>
<tt>> 1000088c: 28 28 c0 7c lwarx r6,0,r5</tt><br>
<tt>> 10000890: 40 00 26 7c cmpld r6,r0</tt><br>
<tt>> 10000894: 0c 00 82 40 bne 100008a0</tt><br>
<tt>> 10000898: 2d 29 80 7c stwcx. r4,0,r5</tt><br>
<tt>> 1000089c: f0 ff e2 40 bne+ 1000088c</tt><br>
<tt>> 100008a0: 2c 01 00 4c isync</tt><br>
<tt>> </tt><br>
<tt>> On the other hand, the current OpenJDK generates following assemblies.</tt><br>
<tt>> </tt><br>
<tt>> 508: ac 04 00 7c sync </tt><br>
<tt>> 50c: 00 00 5c e9 ld r10,0(r28)</tt><br>
<tt>> 510: 00 50 3b 7c cmpd r27,r10</tt><br>
<tt>> 514: 1c 00 c2 40 bne- 530</tt><br>
<tt>> 518: a8 40 5c 7d ldarx r10,r28,r8</tt><br>
<tt>> 51c: 00 50 3b 7c cmpd r27,r10</tt><br>
<tt>> 520: 10 00 c2 40 bne- 530</tt><br>
<tt>> 524: ad 41 3c 7d stdcx. r9,r28,r8</tt><br>
<tt>> 528: f0 ff c2 40 bne- 518</tt><br>
<tt>> 52c: ac 04 00 7c sync </tt><br>
<tt>> 530: 00 50 bb 7f ...</tt><br>
<tt>> </tt><br>
<tt>> Though we can ignore 50c-514 (because they are a duplicated guard condition),
</tt><br>
<tt>> the last sync instruction (52c) makes cmpxchg more strict than </tt><br>
<tt>> memory_order_seq_cst.</tt><br>
<tt>> </tt><br>
<tt>> In some cases, the last sync is necessary when this thread must be </tt><br>
<tt>> able to read</tt><br>
<tt>> all of the changes in the other threads while executing from 508 to 530 </tt>
<br>
<tt>> (that processes compare-and-exchange).</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>> Volker and his colleagues have investigated the current GC codes </tt><br>
<tt>> according to this.</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/019079.html</tt><br>
<tt>> However, I believe, we need comments of other GC experts to change </tt><br>
<tt>> the shared codes.</tt><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>> 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>> 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">> wrote on 04/22/2016 21:57:07:</span></tt><span lang="EN-US" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> </tt><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" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> > To: Hiroshi H Horii/Japan/IBM@IBMJP, hotspot-runtime-</tt><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" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> > Cc: Tim Ellison <</tt></span><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" style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> > Date: 04/22/2016 21:58</tt><br>
<tt>> > Subject: Re: RFR(M): 8154736: enhancement of cmpxchg and </tt><br>
<tt>> > copy_to_survivor for ppc64</tt><br>
<tt>> > </tt><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>