RFR: Experiment with storing target method for static and opt-virtual callsites in reloc info
Ashutosh Mehra
asmehra at openjdk.org
Wed Dec 10 02:08:45 UTC 2025
On Tue, 9 Dec 2025 21:15:23 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:
> This work aims to reduce the time taken to perform call resolution by caching the result of direct calls (static and opt-virtual) in the reloc info during compilation of a method.
> Relocations for static and opt-virtual calls already have a field `method_index` which is used to store the "real" method to be invoked by the method handle. It is currently only used during c2 compilations.
> This patch re-uses the `method_index` field for static and opt-virtual calls to store the target method. The runtime call (`SharedRuntime::resolve_helper`) used by the compiled code to perform the call site resolution can then optimize the resolution process by getting the target method from the reloc info and patches the callsite through CompiledDirectCall.
> No special handling is needed for AOT code.
>
> On a 4-cpu system there is around 3% improvement in `spring-boot-getting-started`. Numbers for JavacBench range between 0-3% improvement.
>
> `spring-boot-getting-started`:
>
> Run,Old CDS + AOT,New CDS + AOT
> 1,199,192
> 2,199,196
> 3,202,197
> 4,203,198
> 5,198,196
> 6,201,194
> 7,203,197
> 8,200,193
> 9,204,193
> 10,199,201
> Geomean,200.79,195.68 (1.03x improvement)
> Stdev,1.99,2.61
>
>
> `-Xlog:init` shows the numbers for time spent in call resolution from the compiled code.
> For `spring-boot-getting-started` before this patch:
>
> [0.357s][info][init] SharedRuntime:
> [0.357s][info][init] resolve_opt_virtual_call: 8260us / 2249 events
> [0.357s][info][init] resolve_virtual_call: 6899us / 1297 events
> [0.357s][info][init] resolve_static_call: 4646us / 1723 events
> [0.357s][info][init] handle_wrong_method: 680us / 145 events
> [0.357s][info][init] ic_miss: 2109us / 488 events
> [0.357s][info][init] Total: 22596us
> [0.357s][info][init] perf_resolve_static_cache_hit_ctr: 0
> [0.357s][info][init] perf_resolve_opt_virtual_cache_hit_ctr: 0
>
>
> For `spring-boot-getting-started` after this patch:
>
> [0.348s][info][init] SharedRuntime:
> [0.348s][info][init] resolve_opt_virtual_call: 2774us / 2251 events
> [0.348s][info][init] resolve_virtual_call: 5577us / 1294 events
> [0.348s][info][init] resolve_static_call: 1901us / 1728 events
> [0.348s][info][init] handle_wrong_method: 719us / 146 events
> [0.348s][info][init] ic_miss: 2109us / 474 events
> [0.348s][info][init] Total: 13082us
> [0.348s][info][init] perf_resolve_static_cache_hit_ctr: 1704
> ...
To make it convenient to measure perf impact the change in `SharedRuntime::resolve_helper` is protected by `UseNewCode2` flag. If these changes make sense I will remove this flag before integrating.
-------------
PR Comment: https://git.openjdk.org/leyden/pull/106#issuecomment-3635039448
More information about the leyden-dev
mailing list