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

[Andrew Haley]

On Wed, 17 Dec 2025 15:39:49 GMT, Fei Gao <fgao at openjdk.org> wrote:

> Assume the following race:
> 
>     * One thread has already entered the resolver and started patching, but has not yet completed.
> 
>     * Another thread has **not** observed the updated call site, but **has** observed the patched trampoline stub and therefore reaches the static call stub directly via the trampoline stub.

OK.

> In this case, the second thread will not execute the resolver. An ISB in `CompiledICLocker::~CompiledICLocker()` would not address this scenario, because the second thread never goes through the resolver path and therefore never executes that ISB. As a result, the second thread may execute stale MOV instructions in the static call stub. Would that be a problem? 

I don't think that's possible, because rewriting when a class gets redefined only happens at a safepoint. So I think we're OK, probably.

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

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