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

[Andrew Dinn]

On Mon, 23 Feb 2026 10:36:21 GMT, Andrew Dinn <adinn 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
>
> Andrew Dinn has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add AOT logging for C strings

I have implemented a fix for for https://bugs.openjdk.org/browse/JDK-8377554 in this branch

  https://github.com/adinn/jdk/tree/aot_runtime_constants 

which I have been using to test this current PR. That branch includes a fix to the card table loads in CardTableBarierSetAssembler which removes the two bugs you are seeing

  https://github.com/openjdk/jdk/commit/00418049d378e7669cb2ad37a113e865b62522f9

After rebasing this PR on top of the above branch the failing test works with Parallel GC. It also bypasses the crash that made the ZGC test fail. However, I did not raise a PR for my AOTRC patch because I am still seeing a secondary error with the ZGC test. I think it is unrelated but am not sure because I can only reproduce it by downloading the static lib bundle. Since that has no debug info I have to debug the problem using logging and PrintStub tracing.

The bug happens shortly after an array copy and always seems to involve an attempt to consume an oop in the format 0x00020000000nnnnn. The error is normally a failed load_klass operation (it SEGVs). I have been trying to see if this is an error in the stub code but I printed all the code and relocs and it looked like everything was relocating correctly.

The 0x00020000 in the top 32 bits makes me wonder if this is an issue storing and loading a heap value from the archive. ZGC is using 0x00004000 to mark oops which makes me supsicious because that equals (0x00020000 >> 3).

I have just rebased my aot_runtime_constants branch over master which means I will now include Ashu's patch to ensure the configured options do not change. I'll try testing this branch against the rebased patch to make sure that the problem was not related to an option change.

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

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