RFR: 8291302: ARM32: nmethod entry barriers support

[Richard Reingruber]

On Wed, 30 Nov 2022 20:26:23 GMT, Aleksei Voitylov <avoitylov at openjdk.org> wrote:

> This PR implements nmethod entry barriers for ARM32. It has already been implemented for other ports and is related with JDK-8290025 "Remove the Sweeper".

Hi Aleksei,
thanks for picking up the work on ARM32 support of nmethod entry barriers.
Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC? If so you could simplify the implementation.
Thanks, Richard.

src/hotspot/cpu/arm/gc/shared/barrierSetAssembler_arm.cpp line 221:

> 219:   // Subsequent loads of oops must occur after load of guard value.
> 220:   // BarrierSetNMethod::disarm sets guard with release semantics.
> 221:   __ membar(MacroAssembler::LoadLoad, tmp1);

Is my assumption correct that ARM32 supports neither ZGC nor ShenandoahGC?
If so then no memory barrier is needed as no oops are modified concurrently with G1 (and other GCs are not concurrent).
I'd recomment to implement `BarrierSetAssembler::nmethod_patching_type()` as on AARCH64 and replace the membar with an assertion that `NMethodPatchingType::stw_instruction_and_data_patch` is in effect.
@fisk wouldn't it be good if there was a shared method to query if oops (other values?) are modified concurrently?

src/hotspot/cpu/arm/gc/shared/barrierSetNMethod_arm.cpp line 87:

> 85:    to the interpreter if the nmethod has been unloaded. */
> 86: void BarrierSetNMethod::deoptimize(nmethod* nm, address* return_address_ptr) {
> 87: 

Again if neither ZGC nor ShenandoahGC are supported then you can leave this unimplemented. [`BarrierSetNMethod::nmethod_entry_barrier()`](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L72-L103) never returns false so the single [call site](https://github.com/openjdk/jdk/blob/fa0c599a003962cf3457bb49b9f771659532b5c3/src/hotspot/share/gc/shared/barrierSetNMethod.cpp#L181) cannot be reached unless you want to support `DeoptimizeNMethodBarriersALot` which IMO is not needed without support for ZGC/ShenandoahGC.

src/hotspot/cpu/arm/stubGenerator_arm.cpp line 2944:

> 2942:     __ BIND(deoptimize_label);
> 2943: 
> 2944:     __ ldr(Rtemp, Address(SP, 0));

If neither ZGC nor ShenandoahGC are supported then `deoptimization_label` will not be reached.

-------------

PR: https://git.openjdk.org/jdk/pull/11442