RFR: 8354887: Preserve runtime blobs in AOT code cache [v6]

[Ashutosh Mehra]

On Thu, 15 May 2025 15:31:34 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2188:
>> 
>>> 2186: #endif
>>> 2187:   const char* name = SharedRuntime::stub_name(SharedStubId::deopt_id);
>>> 2188:   CodeBlob* blob = AOTCodeCache::load_code_blob(AOTCodeEntry::SharedBlob, (uint)SharedStubId::deopt_id, name);
>> 
>> For most shared blobs we have a single entry at offset 0. However, for the deopt blob we have 3 (or 5) extra entry points which are embedded in the deopt blob as field values. Saving and restoring the blob internal state removes the need to pass a count and array of entry offsets into load_code_blob and store_code_blob at this point.
>> That makes we wonder if we need to do the same with AdapterBlob. If we embedded the offsets that are currently stored in AdapterHandlerEntry into AdapterBlob then we could also avoid having to explicitly pass the count and array of offsets at AOT load/store for adapters. The getters in AdapterHandlerEntry could fetch them indirectly or else the entry could cache them locally when it is initialized depending on whether we care about a memory indirection. Maybe this would make things more uniform?
>
> yup, I agree and I have the similar idea of storing entry points in AdapterBlob just like DeoptimizationBlob. Currently the pointer to AdapterBlob is not maintained anywhere. So the AdapterHandlerEntry would also have to maintain pointer to AdapterBlob.
> I was actually wondering if we can eliminate AdapterHandlerEntry by also storing AdapterFingerprint in the AdapterBlob. The Method can then have a pointer to AdapterBlob.

I will open an RFE to move entry points to AdapterBlob.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091498971