RFR: 8363620: AArch64: reimplement emit_static_call_stub()

[Andrew Haley]

On Tue, 5 Aug 2025 21:47:34 GMT, Dean Long <dlong at openjdk.org> wrote:

> > Unaligned memory access may be non-atomic, although in this case, other threads aren’t modifying the data.
> 
> I thought other threads are modifying the data, which is the reason why we needed the ISB.

Yes, exactly. Other threads are executing this nmethod while we are modifying its static call stub.

We hold the lock while we're doing this, so any thread racing with us to _modify_ the call stub would be blocked. However, another thread could execute the call we just patched but not fully observe the changes we made to the stub, which is why we need the ISB.

We have a similar situation with this PR, but with data rather than instruction memory. We need to make sure that any racing thread observes changes to the stub before it observes the patched call to the stub. There is no ordering between instruction and data memory, which is why the current stub uses only instruction memory, keeping everything right. The ISB ensures that the executing thread observes the changed stub: there is a happens-before from the `ICache::invalidate_range` after patching the stub (but before patching the call) to the `isb` at the start of the stub.

For this PR to be correctly synchronized, we'd need a similar happens-before from patching the constants used in the stub to executing the stub. I can think of a way to do that, but it's fiddly and may not be worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26638#discussion_r2256564579