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

Vladimir Kozlov kvn at openjdk.org
Wed May 7 19:37:54 UTC 2025


On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters.
>> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs.
>> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`.
>
> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - 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>
>  - Fix win64 compile failures
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Fix AOTCodeFlags.java test
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Fix compile failure in minimal config
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Revert back changes that added AOTRuntimeConstants.
>    Ensure CompressedOops::base and CompressedKlssPointers::base does not
>    change in production run
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Fix merge conflicts
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Store/load AsmRemarks and DbgStrings in aot code cache
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - Add missing external address in aarch64
>    
>    Signed-off-by: Ashutosh Mehra <asmehra at redhat.com>
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab

I think it is fine not use AOT code when the heap base does not match. Based on my test it will happen only with big heap's size difference between assembly and production runs.

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

PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860006997


More information about the hotspot-runtime-dev mailing list