RFR: 8372617: Save and restore stubgen stubs when using an AOT code cache

[Andrew Dinn]

On Fri, 21 Nov 2025 00:34:14 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> This PR adds save and restore of all generated stubs to the AOT code cache on x86 and aarch64. Other arches are modified to deal with the related generic PAI changes.
>> 
>> Small changes were required to the aarch64 and x86_64 generator code in order to meet two key constraints:
>> 1. the first declared entry of every stub starts at the first instruction in the stub code range
>> 2. all data/code cross-references from one stub to another target a declared stub entry
>
> I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics).
> May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table.

@vnkozlov

> I noticed that we have to add a lot of local data tables addresses for stubs (math intrinsics).
> May be we should consider to have platform specific AOT address tables for such address (and platform specific stubs). To avoid search in one big table.

I think we only need to search the the _extrs address list when we are saving stub or nmethod blobs and need to translate a target address to a table index. When loading code we simply use an index to lookup the corresponding address. So, performance is only an issue for the assembly phase.

I don't think splitting the externals tables is going to be much help. If we flag stubs as arch-specific or generic then, sure, we can bypass the local externals table if we are saving a generic stub. But that does not avoid what is essentially an o(n^2) lookup, it merely reduces it by a constant factor (ratio of generic external references to all external references) that is not that much less than 1.

I suggest instead that during stub save we populate a hash table of <address, int> whenever we insert a new external address into the table. That way we can do the lookup in constant time. How does that sound?

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

PR Comment: https://git.openjdk.org/jdk/pull/28433#issuecomment-3774066187