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

[Fei Gao]

On Wed, 17 Dec 2025 12:12:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> 
> That visibility is not guaranteed. A `B .+4` already exists because the static stub has already been patched. We then rewrite the static stub because the destination method moved.

I see. Thanks for your explanation!

> What about a 3rd thread that sees the call site already resolved so never calls the resolve helper? It won't execute an ISB either. I thought the ISB was only needed to see changes to the stub, not the call site.

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.

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’m not sure whether this is what @dean-long had in mind.

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

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