RFR: 8363620: AArch64: reimplement emit_static_call_stub() [v6]

[Fei Gao]

On Wed, 10 Dec 2025 09:43:44 GMT, Dean Long <dlong at openjdk.org> wrote:

> I think `set_stub_to_clean` is the wrong place to restore the ISB. I don't think it is guaranteed to be called between `set_to_interpreted` calls. Instead, `reresolve_call_site` or `fixup_callers_callsite` will call `set_to_clean`. But even if the ISB is guaranteed to be restored, how to we guarantee that it is observed? Don't we have the same problem with the rewritten ISB as we did with the rewritten MOVs?

Thanks for your review @dean-long !

Based on my limited understanding, and as discussed earlier by Mikhail and Andrew [here](https://github.com/openjdk/jdk/pull/26638#issuecomment-3179283141), it is both unsafe and unnecessary to clear the static call stub by calling `CompiledDirectCall::set_stub_to_clean` in any situation where the stub is shared between calls to the same method.

In fact, `CompiledDirectCall::set_stub_to_clean` was effectively unused before
https://github.com/openjdk/jdk/pull/23573. That PR introduced a use of `set_stub_to_clean` when creating a relocated copy of an nmethod [here](https://github.com/openjdk/jdk/blob/8eaeb6990b85ac8717f4fc4ce883f674017b91f3/src/hotspot/share/code/nmethod.cpp#L1532), before the copy is marked as in use. Under these conditions, the ISB is guaranteed to be restored and observed. I think there is no race related to restoring the ISB.

WDYT? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/26638#issuecomment-3636597692