<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)">
<!--[if !mso]><style>v\:* {behavior:url(#default#VML);}
o\:* {behavior:url(#default#VML);}
w\:* {behavior:url(#default#VML);}
.shape {behavior:url(#default#VML);}
</style><![endif]--><style><!--
/* Font Definitions */
@font-face
{font-family:Wingdings;
panose-1:5 0 0 0 0 0 0 0 0 0;}
@font-face
{font-family:"MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@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;}
@font-face
{font-family:"\@MS Mincho";
panose-1:2 2 6 9 4 2 5 8 3 4;}
@font-face
{font-family:"Default San Serif";
panose-1:0 0 0 0 0 0 0 0 0 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-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:0in;
margin-right:0in;
margin-bottom:0in;
margin-left:.5in;
margin-bottom:.0001pt;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
p.msonormal0, li.msonormal0, div.msonormal0
{mso-style-name:msonormal;
mso-margin-top-alt:auto;
margin-right:0in;
mso-margin-bottom-alt:auto;
margin-left:0in;
font-size:11.0pt;
font-family:"Calibri",sans-serif;}
span.EmailStyle21
{mso-style-type:personal;
font-family:"Calibri",sans-serif;
color:windowtext;}
span.EmailStyle22
{mso-style-type:personal-compose;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:8.5in 11.0in;
margin:1.0in 1.0in 1.0in 1.0in;}
div.WordSection1
{page:WordSection1;}
/* List Definitions */
@list l0
{mso-list-id:125855883;
mso-list-type:hybrid;
mso-list-template-ids:1199208372 -982366664 67698691 67698693 67698689 67698691 67698693 67698689 67698691 67698693;}
@list l0:level1
{mso-level-start-at:0;
mso-level-number-format:bullet;
mso-level-text:-;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:20.4pt;
text-indent:-.25in;
font-family:"Calibri",sans-serif;
mso-fareast-font-family:"Times New Roman";
mso-bidi-font-family:Calibri;}
@list l0:level2
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:56.4pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level3
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:92.4pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level4
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:128.4pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level5
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:164.4pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level6
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:200.4pt;
text-indent:-.25in;
font-family:Wingdings;}
@list l0:level7
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:236.4pt;
text-indent:-.25in;
font-family:Symbol;}
@list l0:level8
{mso-level-number-format:bullet;
mso-level-text:o;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:272.4pt;
text-indent:-.25in;
font-family:"Courier New";}
@list l0:level9
{mso-level-number-format:bullet;
mso-level-text:;
mso-level-tab-stop:none;
mso-level-number-position:left;
margin-left:308.4pt;
text-indent:-.25in;
font-family:Wingdings;}
ol
{margin-bottom:0in;}
ul
{margin-bottom:0in;}
--></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="EN-US" link="blue" vlink="purple">
<div class="WordSection1">
<p class="MsoNormal">Hi Michihiro,<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">FYI, this patch does seem to help AArch64 also on SPECjbb to a lesser degree. This was benchmarked with very large young gen, so GC overhead is kept lower than you’d see in typical applications.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<ul style="margin-top:0in" type="disc">
<li class="MsoListParagraph" style="margin-left:-15.6pt;mso-list:l0 level1 lfo1">
Derek<o:p></o:p></li></ul>
<p class="MsoNormal"><o:p> </o:p></p>
<div style="border:none;border-left:solid blue 1.5pt;padding:0in 0in 0in 4.0pt">
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0in 0in 0in">
<p class="MsoNormal"><b>From:</b> hotspot-gc-dev [mailto:hotspot-gc-dev-bounces@openjdk.java.net]
<b>On Behalf Of </b>Michihiro Horie<br>
<b>Sent:</b> Wednesday, July 04, 2018 4:26 AM<br>
<b>To:</b> Kim Barrett <kim.barrett@oracle.com><br>
<b>Cc:</b> hotspot-gc-dev@openjdk.java.net; Gustavo Romero <gromero@linux.vnet.ibm.com><br>
<b>Subject:</b> Re: 8205908: Unnecessarily strong memory barriers in ParNewGeneration::copy_to_survivor_space<o:p></o:p></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="color:red">External Email</span><o:p></o:p></p>
<div>
<p><span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">Hi Martin, Kim,</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">Thank you for both of your comments.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">I missed the point that oopDesc::forward_to is invoked from several callers. Using OrderAccess:storestore() before the invocation of forward_to() would be a great idea, thanks.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">>I haven't looked carefully at the change, though I did find one part</span><span style="font-size:10.0pt;font-family:"MS Mincho";color:#2F2F2F">
</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">>that I don't like. The new test of "order" in forward_to_atomic not</span><span style="font-size:10.0pt;font-family:"MS Mincho";color:#2F2F2F">
</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">>only affects CMS, but also (uselessly) affects G1.</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">Please let me confirm your point. You mean I should give memory_order_acq_rel to forward_to_atomic, which uses tests as follows to hold the consistent meaning of acquire/release
in forward_to_atomic? I agree it is not clear the test with release returns the forwardee with acquire.</span><br>
<br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">oop oopDesc::forward_to_atomic(oop p, atomic_memory_order order) {</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">:</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">while (!oldMark->is_marked()) {</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">if (order == memory_order_acq_rel) {</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">curMark = cas_set_mark_raw(forwardPtrMark, oldMark, memory_order_release);</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">} else {</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">curMark = cas_set_mark_raw(forwardPtrMark, oldMark, order);</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">}</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">}</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">:</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">}</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">if (order == memory_order_acq_rel) {</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">return forwardee_acquire();</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">}</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">return forwardee();</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif;color:#2F2F2F">}</span><br>
<br>
<br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif">Best regards,</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif">--</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif">Michihiro,</span><br>
<span style="font-size:10.0pt;font-family:"Default San Serif",serif">IBM Research - Tokyo</span><br>
<br>
<img width="16" height="16" style="width:.1666in;height:.1666in" id="_x0000_i1025" src="cid:image001.gif@01D417A1.F84BFCD0" alt="Inactive hide details for Kim Barrett ---2018/07/04 05:41:02---> On Jul 3, 2018, at 4:25 AM, Michihiro Horie <HORIE@jp.ibm.com>"><span style="font-size:10.0pt;color:#424282">Kim
Barrett ---2018/07/04 05:41:02---> On Jul 3, 2018, at 4:25 AM, Michihiro Horie <<a href="mailto:HORIE@jp.ibm.com">HORIE@jp.ibm.com</a>> wrote: ></span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">To: </span><span style="font-size:10.0pt">Michihiro Horie <<a href="mailto:HORIE@jp.ibm.com">HORIE@jp.ibm.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Cc: </span><span style="font-size:10.0pt">"Doerr, Martin" <<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>>, "<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a>" <<a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a>>,
Gustavo Romero <<a href="mailto:gromero@linux.vnet.ibm.com">gromero@linux.vnet.ibm.com</a>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Date: </span><span style="font-size:10.0pt">2018/07/04 05:41</span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Subject: </span><span style="font-size:10.0pt">Re: 8205908: Unnecessarily strong memory barriers in ParNewGeneration::copy_to_survivor_space</span><o:p></o:p></p>
<div class="MsoNormal">
<hr size="2" width="100%" noshade="" style="color:#8091A5" align="left">
</div>
<p class="MsoNormal" style="margin-bottom:12.0pt"><br>
<br>
<br>
<tt><span style="font-size:10.0pt">> On Jul 3, 2018, at 4:25 AM, Michihiro Horie <<a href="mailto:HORIE@jp.ibm.com">HORIE@jp.ibm.com</a>> wrote:</span></tt><span style="font-size:10.0pt;font-family:"Courier New""><br>
<tt>> </tt><br>
<tt>> Hi Martin,</tt><br>
<tt>> </tt><br>
<tt>> Thanks a lot for your review. Sure, we need an OK from a CMS expert. Following is the new webrev:</tt><br>
<tt>> <a href="http://cr.openjdk.java.net/~mhorie/8205908/webrev.01/">http://cr.openjdk.java.net/~mhorie/8205908/webrev.01/</a></tt><br>
<tt>> </tt><br>
<tt>> >Seems like a user of the forwardee needs to rely on memory_order_consume in the current implementation. I guess it will be appreciated that you’re fixing this.</tt><br>
<tt>> Thank you for pointing out this issue in the original implementation. I newly inserted a release at "2.4. Set new_obj as forwardee [L1142]".</tt><br>
<tt>> </tt><br>
<tt>> Improvement of critical-jOPS in SPECjbb2015 was 10%, which is still a big number.</tt><br>
<tt>> </tt><br>
<tt>> </tt><br>
<tt>> Best regards,</tt><br>
<tt>> --</tt><br>
<tt>> Michihiro,</tt><br>
<tt>> IBM Research - Tokyo</tt><br>
<br>
<tt>CMS was deprecated in JDK 9, and has been on maintenance life-support</tt><br>
<tt>for some time. This complex-to-review performance enhancement was</tt><br>
<tt>proposed less than 48 hours before JDK 11 FC, and didn't receive any</tt><br>
<tt>reviews until after FC. Because of these factors, I don't think it</tt><br>
<tt>should be included in JDK 11. And if CMS gets removed in JDK 12 (I</tt><br>
<tt>don't know if that will happen), then this change would be rendered</tt><br>
<tt>entirely moot.</tt><br>
<br>
<tt>I haven't looked carefully at the change, though I did find one part</tt><br>
<tt>that I don't like. The new test of "order" in forward_to_atomic not</tt><br>
<tt>only affects CMS, but also (uselessly) affects G1.</tt><br>
<br>
<tt>I'm not going to be able to look at this carefully soon, as JDK 11 bug</tt><br>
<tt>fixing has a higher priority for me. Since I think CMS might soon not</tt><br>
<tt>be an issue, I'd really rather not look at it at all. I think this</tt><br>
<tt>change needs not just a CMS-expert reviewer, but someone who is</tt><br>
<tt>willing to maintain CMS (including any potential bug tail from this</tt><br>
<tt>change).</tt><br>
<br>
<br>
<br>
</span><br>
<br>
<o:p></o:p></p>
</div>
</div>
</div>
</body>
</html>