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

[Andrew Haley]

On Sat, 17 Jan 2026 04:57:53 GMT, Dean Long <dlong at openjdk.org> wrote:

> I'm probably missing something, but even if we assume class redefinition happens at a safepoint, I don't see how that saves us. I think we have an existing problem even without the changes in this PR. Consider:
> 
> ```
> void test() {
>     foo.bar(); // static or opt_virtual call site
>     MyRedefinerHelper.redefineClass("foo", "bar", ....);
>     foo.bar();
> }
> ```
> 
> Thread 1 calls foo.bar() for the first time, which redirects to the resolve stub and eventually calls set_to_interpreted with the original Method*. Next, we redefine foo.bar(), and then call foo.bar() again. This is the first time we have hit this call site, so we resolve it, but this time we call set_to_interpreted() on the shares stub with the new redefined Method*. Note that the two call sites use the same stub, because x86 and aarch64 share static stubs. Now, add a second thread calling the same test() method. The second thread can be executing in the static stub at the same time that the first thread is in the middle of writing a different Method* to the stub.

Which means it's being rewritten outside of a safepoint. 

> The ISB doesn't save us either.

Hmm, maybe. I think we need a test case that does exactly this.

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

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