Missing nmethod entry barriers on ARM32

[Reingruber, Richard]

Great, thanks! I’ve already commented on the pr (https://github.com/openjdk/jdk/pull/11442).

Thanks, Richard.

From: Boris Ulasevich <boris.ulasevich at bell-sw.com>
Date: Thursday, 1. December 2022 at 09:00
To: Reingruber, Richard <richard.reingruber at sap.com>, Sergey Nazarkin <snazarkin at azul.com>
Cc: porters-dev at openjdk.org <porters-dev at openjdk.org>
Subject: Re: Missing nmethod entry barriers on ARM32
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
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><mailto:snazarkin at azul.com>
Sent: Tuesday, November 29, 2022 15:29
To: Reingruber, Richard <richard.reingruber at sap.com><mailto:richard.reingruber at sap.com>
Cc: porters-dev at openjdk.org<mailto:porters-dev at openjdk.org> <porters-dev at openjdk.org><mailto:porters-dev at openjdk.org>; boris.ulasevich at bell-sw.com<mailto:boris.ulasevich at bell-sw.com> <boris.ulasevich at bell-sw.com><mailto: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><mailto: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/10d079bc/attachment.htm>