<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
Hi,<br>
<br>
As I know, the change for JDK-8291302 "ARM32: nmethod entry barriers
support" is ready and going to be published in a few days.<br>
<br>
thanks,<br>
Boris<br>
<br>
<div class="moz-cite-prefix">On 11/30/2022 12:07 AM, Reingruber,
Richard wrote:<br>
</div>
<blockquote type="cite"
cite="mid:AS4PR02MB85040D1722794DAE80CEEB5A9B129@AS4PR02MB8504.eurprd02.prod.outlook.com">
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
<style type="text/css" style="display:none;">P {margin-top:0;margin-bottom:0;}</style>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
255, 255);" class="elementToProof ContentPasted0">
Hi Sergey,</div>
<div style="font-family: Calibri, Arial, Helvetica, sans-serif;
font-size: 12pt; color: rgb(0, 0, 0); background-color: rgb(255,
255, 255);" class="elementToProof ContentPasted0">
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">> Is this blocking you? As
workaround I can prepare simple barriers</div>
<div class="ContentPasted0">> implementation enough to run
SerialGC.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">The entry barriers are required for
G1. Without you can get a corrupted java heap.</div>
<div class="ContentPasted0">Here's a reproducer: <a
href="https://bugs.openjdk.org/browse/JDK-8288970?focusedCommentId=14520842&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14520842"
id="LPlnk104171" moz-do-not-send="true">
https://bugs.openjdk.org/browse/JDK-8288970?focusedCommentId=14520842&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14520842</a></div>
<div class="ContentPasted0">It should fail on ARM32.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">I'd like to do
<a class="moz-txt-link-freetext" href="https://github.com/openjdk/jdk/pull/11314">https://github.com/openjdk/jdk/pull/11314</a> which will make that
type of issue more likely.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">SerialGC and ParallelGC are not
affected.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">> Unfortunately we have no plan
for this activity. I’m not familiar with the</div>
<div class="ContentPasted0">> problem so can’t estimate the
time required to implement the functionality.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">A nmethod barrier is nothing too
complicated. Without support for ZGC/Shenandoah</div>
<div class="ContentPasted0">it is basically a conditional
runtime call with</div>
<div class="ContentPasted0">BarrierSetNMethod::nmethod_stub_entry_barrier()
as target. Without</div>
<div class="ContentPasted0">ZGC/Shenandoah you can implement
BarrierSetNMethod::deoptimize() as</div>
<div class="ContentPasted0">ShouldNotReachHere() because
BarrierSetNMethod::nmethod_entry_barrier() always</div>
<div class="ContentPasted0">returns true (nmethod can be
entered).</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">The actual AARCH64 implementation is
optimized and a little bit complex. It is</div>
<div class="ContentPasted0">sufficient to implement the
NMethodPatchingType::stw_instruction_and_data_patch</div>
<div class="ContentPasted0">part without the extra C2 stub, i.e.
slow_path==NULL in
BarrierSetAssembler::nmethod_entry_barrier(..., slow_path,
...)</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">I hardly know ARM but I really don't
think it would be a lot of effort to</div>
<div class="ContentPasted0">implement it.</div>
<div><br class="ContentPasted0">
</div>
<div class="ContentPasted0">Best regards,</div>
<div class="ContentPasted0">Richard.</div>
<br>
</div>
<hr style="display:inline-block;width:98%" tabindex="-1">
<div id="divRplyFwdMsg" dir="ltr"><font style="font-size:11pt"
face="Calibri, sans-serif" color="#000000"><b>From:</b> Sergey
Nazarkin <a class="moz-txt-link-rfc2396E" href="mailto:snazarkin@azul.com"><snazarkin@azul.com></a><br>
<b>Sent:</b> Tuesday, November 29, 2022 15:29<br>
<b>To:</b> Reingruber, Richard
<a class="moz-txt-link-rfc2396E" href="mailto:richard.reingruber@sap.com"><richard.reingruber@sap.com></a><br>
<b>Cc:</b> <a class="moz-txt-link-abbreviated" href="mailto:porters-dev@openjdk.org">porters-dev@openjdk.org</a>
<a class="moz-txt-link-rfc2396E" href="mailto:porters-dev@openjdk.org"><porters-dev@openjdk.org></a>; <a class="moz-txt-link-abbreviated" href="mailto:boris.ulasevich@bell-sw.com">boris.ulasevich@bell-sw.com</a>
<a class="moz-txt-link-rfc2396E" href="mailto:boris.ulasevich@bell-sw.com"><boris.ulasevich@bell-sw.com></a><br>
<b>Subject:</b> Re: Missing nmethod entry barriers on ARM32</font>
<div> </div>
</div>
<div class="BodyFragment"><font size="2"><span
style="font-size:11pt;">
<div class="PlainText">Hi Richard,<br>
<br>
Unfortunately we have no plan for this activity. I’m not
familiar with the problem so can’t estimate the time
required to implement the functionality. Is this blocking
you? As workaround I can prepare simple barriers
implementation enough to run SerialGC.
<br>
<br>
With best regards,<br>
<br>
Sergey<br>
<br>
<br>
<br>
> On 28 Nov 2022, at 13:03, Reingruber, Richard
<a class="moz-txt-link-rfc2396E" href="mailto:richard.reingruber@sap.com"><richard.reingruber@sap.com></a> wrote:<br>
> <br>
> Dear ARM32 Maintainers, Boris, Sergey, [1]<br>
> <br>
> ARM32 does not implement nmethod entry barriers (see
<a href="https://bugs.openjdk.org/browse/JDK-8291302)"
moz-do-not-send="true" class="moz-txt-link-freetext">
https://bugs.openjdk.org/browse/JDK-8291302)</a>.<br>
> <br>
> This is actually a defect because nmethod entry
barriers are a G1 requirement where they are needed during
concurrent marking to keep alive nmethod oop constants as
they are all weak oops[2].<br>
> <br>
> I'd like to do a clean-up which removes redundant
stackwalks from the G1 remark pause[3]. With nmethod entry
barriers they are not necessary as they do the same keep
alive for oop constants of nmethods found on stack.
Without nmethod barriers (ARM32) these stackwalks are not
sufficient though as every nmethod that is called during
concurrent marking needs to do the keep alive for SATB.<br>
> <br>
> Could you share your plans regarding the
implementation of nmethod entry barriers? How would you
like me to handle ARM32 in the intended clean-up?<br>
> <br>
> Thanks,<br>
> Richard.<br>
> <br>
> [1] found you on <a
href="https://wiki.openjdk.org/display/HotSpot/Ports"
moz-do-not-send="true" class="moz-txt-link-freetext">https://wiki.openjdk.org/display/HotSpot/Ports</a><br>
> [2] <a
href="https://bugs.openjdk.org/browse/JDK-8288970"
moz-do-not-send="true" class="moz-txt-link-freetext">https://bugs.openjdk.org/browse/JDK-8288970</a><br>
> [3] <a
href="https://github.com/openjdk/jdk/pull/11314"
moz-do-not-send="true" class="moz-txt-link-freetext">https://github.com/openjdk/jdk/pull/11314</a><br>
<br>
</div>
</span></font></div>
</blockquote>
<br>
</body>
</html>