<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:"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: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;}
p.msonormal0, li.msonormal0, div.msonormal0
        {mso-style-name:msonormal;
        mso-margin-top-alt:auto;
        margin-right:0cm;
        mso-margin-bottom-alt:auto;
        margin-left:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle20
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@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="mso-fareast-language:EN-US">Hi Michihiro,<o:p></o:p></span></p>
<p class="MsoNormal"><span style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">I think oopDesc::forward_to should not be changed with this change because it is used by many GCs.<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="mso-fareast-language:EN-US">If you want to add a StoreStore barrier, you could add “OrderAccess::storestore();” before “old->forward_to(new_obj);” for example.<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"><span lang="EN-US" style="mso-fareast-language:EN-US">It would be nice to have a comment for your new case in oopDesc::forward_to_atomic.<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"><span lang="EN-US" style="mso-fareast-language:EN-US">Best regards,<o:p></o:p></span></p>
<p class="MsoNormal"><span lang="EN-US" style="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"><span lang="EN-US" style="mso-fareast-language:EN-US"><o:p> </o:p></span></p>
<div>
<div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm">
<p class="MsoNormal"><b><span lang="EN-US">From:</span></b><span lang="EN-US"> Michihiro Horie [mailto:HORIE@jp.ibm.com]
<br>
<b>Sent:</b> Dienstag, 3. Juli 2018 10:26<br>
<b>To:</b> Doerr, Martin <martin.doerr@sap.com><br>
<b>Cc:</b> hotspot-gc-dev@openjdk.java.net; Kim Barrett <kim.barrett@oracle.com>; 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></span></p>
</div>
</div>
<p class="MsoNormal"><o:p> </o:p></p>
<p><span style="font-size:10.0pt">Hi Martin,</span><br>
<br>
<span style="font-size:10.0pt">Thanks a lot for your review. Sure, we need an OK from a CMS expert. Following is the new webrev:</span><br>
<a href="http://cr.openjdk.java.net/~mhorie/8205908/webrev.01/"><span style="font-size:10.0pt">http://cr.openjdk.java.net/~mhorie/8205908/webrev.01/</span></a><br>
<br>
>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.<br>
Thank you for pointing out this issue in the original implementation. I newly inserted a release at "<span style="font-size:10.0pt">2.4. Set new_obj as forwardee [L1142]</span>".<br>
<br>
<span style="font-size:10.0pt">Improvement of critical-jOPS in SPECjbb2015 was 10%, which is still a big number.</span><br>
<br>
<br>
<span style="font-size:10.0pt">Best regards,</span><br>
<span style="font-size:10.0pt">--</span><br>
<span style="font-size:10.0pt">Michihiro,</span><br>
<span style="font-size:10.0pt">IBM Research - Tokyo</span><br>
<br>
<img border="0" width="16" height="16" style="width:.1666in;height:.1666in" id="_x0000_i1025" src="cid:image001.gif@01D412E4.D7704690" alt="Inactive hide details for "Doerr, Martin" ---2018/07/02 16:56:03---Hi Michihiro, thanks for addressing this issue."><span style="font-size:10.0pt;color:#424282">"Doerr,
 Martin" ---2018/07/02 16:56:03---Hi Michihiro, thanks for addressing this issue.</span><br>
<br>
<span style="font-size:10.0pt;color:#5F5F5F">From: </span><span style="font-size:10.0pt">"Doerr, Martin" <<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.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>>, "<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>></span><br>
<span style="font-size:10.0pt;color:#5F5F5F">Cc: </span><span style="font-size:10.0pt">Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</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/02 16:56</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"><br>
<br>
<br>
Hi Michihiro,<br>
<br>
thanks for addressing this issue.<br>
<br>
The change looks good to me. I only have a comment on the coding style (oop.inline.hpp): “if ()” should be followed by braces “{ … }”.<br>
<br>
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.<br>
<br>
Please note that SAP still supports CMS in the commercial VM so this change is still relevant and we’d like to push it to jdk11 if possible.<br>
<br>
But we definitely need an OK from a CMS expert (which I’m not).<br>
<br>
Best regards,<br>
Martin<br>
<br>
<br>
<b>From:</b> Michihiro Horie [<a href="mailto:HORIE@jp.ibm.com">mailto:HORIE@jp.ibm.com</a>]
<b><br>
Sent:</b> Mittwoch, 27. Juni 2018 02:23<b><br>
To:</b> <a href="mailto:hotspot-gc-dev@openjdk.java.net">hotspot-gc-dev@openjdk.java.net</a><b><br>
Cc:</b> Doerr, Martin <<a href="mailto:martin.doerr@sap.com">martin.doerr@sap.com</a>>; Kim Barrett <<a href="mailto:kim.barrett@oracle.com">kim.barrett@oracle.com</a>>; Gustavo Romero <<a href="mailto:gromero@linux.vnet.ibm.com">gromero@linux.vnet.ibm.com</a>><b><br>
Subject:</b> RFR: 8205908: Unnecessarily strong memory barriers in ParNewGeneration::copy_to_survivor_space<o:p></o:p></p>
<p><span style="font-size:10.0pt">Dear all,</span><br>
<span style="font-size:10.0pt"><br>
Would you please review the following change?<br>
Bug: </span><a href="https://bugs.openjdk.java.net/browse/JDK-8205908"><span style="font-size:10.0pt">https://bugs.openjdk.java.net/browse/JDK-8205908</span></a><span style="font-size:10.0pt"><br>
Webrev: </span><a href="http://cr.openjdk.java.net/~mhorie/8205908/webrev.00/"><span style="font-size:10.0pt">http://cr.openjdk.java.net/~mhorie/8205908/webrev.00/</span></a><br>
<br>
<span style="font-size:10.0pt"><br>
[Current implementation]<br>
ParNewGeneration::copy_to_survivor_space tries to move live objects to a different location. There are two patterns on how to copy an object depending on whether there is space to allocate new_obj in to-space or not. If a thread cannot find space to allocate
 new_obj in to-space, the thread first executes the CAS with a dummy forwarding pointer "ClaimedForwardPtr", which is a sentinel to mark an object as claimed. After succeeding in the CAS, a thread can copy the new_obj in the old space. Here, suppose thread
 A succeeds in the CAS, while thread B fails in the CAS. When thread A finishes the copy, it replaces the dummy forwarding pointer with a real forwarding pointer. After thread B fails in the CAS, thread B returns the forwardee after waiting for the copy of
 the forwardee is completed. This is observable by checking the dummy forwarding pointer is replaced with a real forwarding pointer by thread A. In contrast, if a thread can find space to allocate new_obj in to-space, the thread first copies the new_obj and
 then executes the CAS with the new_obj. If a thread fails in the CAS, it deallocates the copied new_obj and returns the forwardee.</span><br>
<span style="font-size:10.0pt"><br>
Procedure of ParNewGeneration::copy_to_survivor_space : ([L****] represents the line number in src/hotspot/share/gc/cms/parNewGeneration.cpp)
<br>
1. Try to each allocate space for new_obj in to-space [L.1110]<br>
2. If fail in the allocation in to-space [L1117] <br>
2.1. Execute the CAS with the dummy forwarding pointer [L1122] ——— (A)<br>
2.2. If fail in the CAS, return the forwardee via real_forwardee() [L1123]<br>
2.3. If succeed in the CAS [L1128] <br>
2.3.1. If promotion is allowed, copy new_obj in the old area [L1129]<br>
2.3.2. If promotion is not allowed, forward to obj itself [L1133]<br>
2.4. Set new_obj as forwardee [L1142]<br>
3. If succeed in the allocation in to-space [L1144] <br>
3.1. Copy new_obj [L1146]<br>
3.2. Execute the CAS with new_obj [L1148] ——— (B)<br>
4. Dereference the new_obj for logging. Each new_obj copied by each thread at step 3.1 is used instead of forwardee() [L1159]<br>
5. If succeed in either CAS (A) or CAS (B), return new_obj [L1163]<br>
6. If fail in CAS (B), get the forwardee via real_forwardee(). Unallocate new_obj in to-space [L1193]<br>
7. Return forwardee [L1203]</span><br>
<span style="font-size:10.0pt"><br>
For reference, real_forwardee() is as shown below:<br>
oop ParNewGeneration::real_forwardee(oop obj) {<br>
oop forward_ptr = obj->forwardee();<br>
if (forward_ptr != ClaimedForwardPtr) {<br>
return forward_ptr;<br>
} else {<br>
// manually inlined for readability.<br>
oop forward_ptr = obj->forwardee();<br>
while (forward_ptr == ClaimedForwardPtr) {<br>
waste_some_time();<br>
forward_ptr = obj->forwardee();<br>
}<br>
return forward_ptr;<br>
}<br>
}</span><br>
<span style="font-size:10.0pt"><br>
Regarding the CAS (A),<br>
There is no copy before the CAS.<br>
Dereferencing the forwardee must be allowed after obtaining the forwardee.</span><br>
<span style="font-size:10.0pt"><br>
Regarding the CAS (B),<br>
There is a copy before the CAS.<br>
Dereferencing the forwardee must be allowed after obtaining the forwardee.</span><br>
<br>
<span style="font-size:10.0pt"><br>
[Observation on the current implementation]<br>
No fence is necessary before and after the CAS (A).<br>
Release barrier is necessary before the CAS (B).<br>
The forwardee_acquire() must be used instead of forwardee() in real_forwardee().</span><br>
<br>
<span style="font-size:10.0pt"><br>
[Performance measurement]<br>
The critical-jOPS of SPECjbb2015 improved by 12% with this change.</span><br>
<br>
<span style="font-size:10.0pt"><br>
Best regards,<br>
--<br>
Michihiro,<br>
IBM Research - Tokyo</span><o:p></o:p></p>
<p><o:p> </o:p></p>
</div>
</body>
</html>