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

[Andrew Haley]

On Thu, 25 Dec 2025 09:55:13 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> @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.

> @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.

For there to be substantial disagreement, there would have to be some plausible scenario in which there was a race condition. For that, redefinition of the call would have to occur outside a safepoint. I do not believe that's possible, and if it did happen it would break the existing code, regardless of this patch, because a racing thread would observe a partially-initialized MOVZ/MOVK sequence.

> 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? 

I think I already answered that: it weakens the invariant on which the correctness of trampolines is based, making the whole thing harder to reason about.

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

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