RFR: 8291302: ARM32: nmethod entry barriers support [v2]
Aleksei Voitylov
avoitylov at openjdk.org
Mon Dec 5 14:23:28 UTC 2022
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
More information about the hotspot-dev
mailing list