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

[Fei Gao]

On Wed, 17 Dec 2025 18:17:57 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.
>
>> 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!

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

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