On Tue, 30 Jun 2026 13:16:56 GMT, Andrew Dinn <[email protected]> wrote:
>> src/hotspot/cpu/aarch64/stubGenerator_aarch64.cpp line 13771:
>>
>>> 13769:
>>> 13770: if (InlineTypeReturnedAsFields) {
>>> 13771: StubRoutines::_load_inline_type_fields_in_regs =
>>
>> This looks suspicious.
>>
>> I noticed that the generator code for this stub is not attempting to look up
>> the stub in the AOT cache as with other `StubGen initial` stubs. On
>> investigation I also noticed that the generator is allocating its own code
>> buffer to write the code into and then wrapping it up in its own
>> `RuntimeStub` before handing back the entry address.
>>
>> I'm not really sure why this stub has been bundled in with the other
>> `StubGen initial` stubs. `StubGen` stubs are generated in related groups
>> with all stubs in the group sharing a common code blob. So all the `initial`
>> stubs are expected to be in the `StubGen initial` blob.
>>
>> If this stub needs to be in it's own standalone blob then perhaps it needs
>> to be declared as a `Shared` stub in its own blob rather than being lumped
>> in with the `StubGen initial` stubs? Was there a good reason to try
>> generating it here amongst the `initial` blobs? e.g. timing of generation?
>
> Looking further into this I cannot see anywhere where these stubs are being
> used? So, it's hard to say what is really needed here.
>
> However, it looks to me as if these two return value stubs ought to be
> generated as `SharedRuntime` stubs. That is where we generate stubs that need
> their own blob and also require an associated oop map. The right time to
> generate looks like under the call to
> `SharedRuntime::generate_initial_stubs()`. That will occur just after
> generation of the `StubGen initial` stubs i.e. before generating any of the
> gc/jfr/continuation stubs or interpreter and before calling
> `AOTCodeCache::init3()`.
The callee should be passed a stub id which it can use to look up the stub name
provided in the stub declaration. That also means there is no need to provide a
true/false argument as the callee can pick its generation strategy based on
stub id.
The target address can also be determined in the callee according to whatever
the stub id is. If you want to pass it here then you will need to add asserts
in the callee that the method is the correct target for the stub id.
Also, in order for save and restore of the generated stubs to work the two
target addresses need to be added to the AOT address table as external
addresses in AOTCodeCache::init_extrs().
Since generation of these subs is dependent on the setting of
`InlineTypeReturnedAsFields` the resulting dependence of any generated AOT code
cache's contents on this flag setting needs to be recorded by adding an entry
for `InlineTypeReturnedAsFields` to macro `AOTCODECACHE_CONFIGS_GENERIC_DO` in
file `aotCodecache.hpp.`
If any help is required to implement these changes I am happy to provide
guidance.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/31122#discussion_r3499102014
