Missing nmethod entry barriers on ARM32

[Boris Ulasevich]

Hi,

As I know, the change for JDK-8291302 "ARM32: nmethod entry barriers 
support" is ready and going to be published in a few days.

thanks,
Boris

On 11/30/2022 12:07 AM, Reingruber, Richard wrote:
> Hi Sergey,
>
> > Is this blocking you? As workaround I can prepare simple barriers
> > implementation enough to run SerialGC.
>
> The entry barriers are required for G1. Without you can get a 
> corrupted java heap.
> Here's a reproducer: 
> https://bugs.openjdk.org/browse/JDK-8288970?focusedCommentId=14520842&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14520842 
> <https://bugs.openjdk.org/browse/JDK-8288970?focusedCommentId=14520842&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14520842>
> It should fail on ARM32.
>
> I'd like to do https://github.com/openjdk/jdk/pull/11314 which will 
> make that type of issue more likely.
>
> SerialGC and ParallelGC are not affected.
>
> > 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.
>
> A nmethod barrier is nothing too complicated. Without support for 
> ZGC/Shenandoah
> it is basically a conditional runtime call with
> BarrierSetNMethod::nmethod_stub_entry_barrier() as target. Without
> ZGC/Shenandoah you can implement BarrierSetNMethod::deoptimize() as
> ShouldNotReachHere() because 
> BarrierSetNMethod::nmethod_entry_barrier() always
> returns true (nmethod can be entered).
>
> The actual AARCH64 implementation is optimized and a little bit 
> complex. It is
> sufficient to implement the 
> NMethodPatchingType::stw_instruction_and_data_patch
> part without the extra C2 stub, i.e. slow_path==NULL in 
> BarrierSetAssembler::nmethod_entry_barrier(..., slow_path, ...)
>
> I hardly know ARM but I really don't think it would be a lot of effort to
> implement it.
>
> Best regards,
> Richard.
>
> ------------------------------------------------------------------------
> *From:* Sergey Nazarkin <snazarkin at azul.com>
> *Sent:* Tuesday, November 29, 2022 15:29
> *To:* Reingruber, Richard <richard.reingruber at sap.com>
> *Cc:* porters-dev at openjdk.org <porters-dev at openjdk.org>; 
> boris.ulasevich at bell-sw.com <boris.ulasevich at bell-sw.com>
> *Subject:* Re: Missing nmethod entry barriers on ARM32
> Hi Richard,
>
> 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.
>
> With best regards,
>
> Sergey
>
>
>
> > On 28 Nov 2022, at 13:03, Reingruber, Richard 
> <richard.reingruber at sap.com> wrote:
> >
> > Dear ARM32 Maintainers, Boris, Sergey, [1]
> >
> > ARM32 does not implement nmethod entry barriers (see 
> https://bugs.openjdk.org/browse/JDK-8291302).
> >
> > 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].
> >
> > 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.
> >
> > 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?
> >
> > Thanks,
> > Richard.
> >
> > [1] found you on https://wiki.openjdk.org/display/HotSpot/Ports
> > [2] https://bugs.openjdk.org/browse/JDK-8288970
> > [3] https://github.com/openjdk/jdk/pull/11314
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/porters-dev/attachments/20221201/d4a20d14/attachment-0001.htm>