RFR: 8291302: ARM32: nmethod entry barriers support [v2]

[Aleksei Voitylov]

On Mon, 5 Dec 2022 12:37:09 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> 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.
>
> Isn't there a jtreg test which triggers the deoptimization somehow?

I could not find jtreg tests that specially target deoptimization codepath but one can trigger and test it using a benchmark, e.g. dacapo lusearch with +DeoptimizeNMethodBarriersALot key.

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

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