Missing nmethod entry barriers on ARM32

Sergey Nazarkin snazarkin at azul.com
Tue Nov 29 14:29:30 UTC 2022


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



More information about the porters-dev mailing list