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

[Andrew Haley]

On Wed, 17 Dec 2025 12:06:13 GMT, Fei Gao <fgao at openjdk.org> wrote:

> > I can't really understand why that might matter. I do, though see a possible problem when two threads resolve the same call site. They both lock on`CompiledICLocker`, one wins the race, resolves the site. The other loses, exits, but it sees the patched call site with no intervening ISB. An ISB in `CompiledICLocker::~CompiledICLocker() ` would fix that.
> 
> @theRealAph Sorry, I don’t quite understand this point. If the second thread observes the patched stub without the ISB, does that mean it must have observed the patched B .+4 and also the updated MOV instructions, since the visibility of the MOVs is guaranteed to happen before the visibility of the B .+4? 

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.

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

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