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

[Andrew Haley]

On Tue, 23 Dec 2025 16:56:39 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.
>
> @theRealAph It seems that patching ISB to B .+4 has caused some confusion, and there is still disagreement about the safety implications around class redefinition. How about avoiding trampoline patching when resolving the static stub, and ensuring that the trampoline never points to the static call stub? That might simplify the reasoning. What do you think? Thanks!

> @fg1417 , thanks for the explanation. It helps. However, looking at the existing code even before this change, and what verify_mt_safe allows, I am worried that there are already races in this code, and using instruction patching and ISB makes it harder to analyze. 

> It has probably been discussed before, but why doesn't the stub read the Method* from data instead of using MOVK/MOVZ?

It has been discussed before; see my comment of Aug 6. You could use STLR/LDAR but that'd be more of a runtime overhead, and you need to read _two_ words. Also, it wouldn't be possible to use the guarantee that patching the jump at the call site makes the target instructions visible.

My problem here is not so much how to make this code correct, which is not difficult. It is that I do not know what a thread mutating a static call stub might be allowed to do. I already know that the initial writes to a static call stub are correctly synchronized, but later changes are not unless they are always done at a safepoint.

May that later mutation only happen at a safepoint? If that is so, then we're good to go, because a safepoint can do the ISB.

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

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