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

[Dean Long]

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?
Winter break is coming up, so I probably won't be able look at this again until 2026.

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

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