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

[Ashutosh Mehra]

On Thu, 15 May 2025 15:19:30 GMT, Andrew Dinn <adinn at openjdk.org> wrote:

>> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
>> 
>>  - Merge branch 'master' into preserve-runtime-blobs-master
>>  - Address Vladimir's comments
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Update test to make it more resilient
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Remove more unused code
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Fix whitespace issue. Remove unused code.
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Add test for using AOTCodeCache with different CompressedOops
>>    configuration
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Add check for compressed oops base address; minor refacotring
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Merge branch 'master' into preserve-runtime-blobs-master
>>  - Address Vladimir's comments
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - Remove irrelevant comment
>>    
>>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>>  - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0
>
> 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.

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

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