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

[Dean Long]

On Mon, 8 Dec 2025 14:01:48 GMT, Fei Gao <fgao at openjdk.org> wrote:

>> In the existing implementation, the static call stub typically emits a sequence like:
>> `isb; movk; movz; movz; movk; movz; movz; br`.
>> 
>> This patch reimplements it using a more compact and patch-friendly sequence:
>> 
>> ldr x12, Label_data
>> ldr x8, Label_entry
>> br x8
>> Label_data:
>>   0x00000000
>>   0x00000000
>> Label_entry:
>>   0x00000000
>>   0x00000000
>> 
>> The new approach places the target addresses adjacent to the code and loads them dynamically. This allows us to update the call target by modifying only the data in memory, without changing any instructions. This avoids the need for I-cache flushes or issuing an `isb`[1], which are both relatively expensive operations.
>> 
>> While emitting direct branches in static stubs for small code caches can save 2 instructions compared to the new implementation, modifying those branches still requires I-cache flushes or an `isb`. This patch unifies the code generation by emitting the same static stubs for both small and large code caches.
>> 
>> A microbenchmark (StaticCallStub.java) demonstrates a performance uplift of approximately 43%.
>> 
>> 
>> Benchmark                       (length)   Mode   Cnt Master     Patch      Units
>> StaticCallStubFar.callCompiled    1000     avgt   5   39.346     22.474     us/op
>> StaticCallStubFar.callCompiled    10000    avgt   5   390.05     218.478    us/op
>> StaticCallStubFar.callCompiled    100000   avgt   5   3869.264   2174.001   us/op
>> StaticCallStubNear.callCompiled   1000     avgt   5   39.093     22.582     us/op
>> StaticCallStubNear.callCompiled   10000    avgt   5   387.319    217.398    us/op
>> StaticCallStubNear.callCompiled   100000   avgt   5   3855.825   2206.923   us/op
>> 
>> 
>> All tests in Tier1 to Tier3, under both release and debug builds, have passed.
>> 
>> [1] https://community.arm.com/arm-community-blogs/b/architectures-and-processors-blog/posts/caches-self-modifying-code-working-with-threads
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Add a newline at the end of test file
>  - Merge branch 'master' into reimplement-static-call-stub
>  - Update comments based on Aph's suggestion
>  - The patch is contributed by @theRealAph
>  - Merge branch 'master' into reimplement-static-call-stub
>  - Update comments and fix benchmarks
>  - The patch is contributed by @theRealAph
>  - Merge branch 'master' into reimplement-static-call-stub
>  - Patch 'isb' to 'nop'
>  - Merge branch 'master' into reimplement-static-call-stub
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/fa24325c...415495da

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.  The ISB doesn't save us either.

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

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