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

[Andrew Dinn]

On Tue, 2 Dec 2025 20:56:18 GMT, Ashutosh Mehra <asmehra at openjdk.org> wrote:

>> Andrew Dinn has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:
>> 
>>  - fix AOT externals after merge with main branch
>>  - Merge branch 'master' into save-stubgen-stubs
>>  - fix header declarations
>>  - move AOT address init impl into arch tree below StubRoutines
>>  - put AOT address table init code under INCLUDE_CDS
>>  - fix extras count to match number of unsafe handler regions
>>  - merge
>>  - more whitespace
>>  - rmeove whitespace
>>  - remove redundant comment
>>  - ... and 23 more: https://git.openjdk.org/jdk/compare/e0edc656...6e221ac6
>
> src/hotspot/share/code/aotCodeCache.cpp line 191:
> 
>> 189: 
>> 190:   // Disable stubs caching until JDK-8357398 is fixed.
>> 191:   // FLAG_SET_ERGO(AOTStubCaching, false);
> 
> I can't seem to access JDK-8357398. I am not sure if that bug is fixed or not. But if it is not fixed yet, I think we should keep this un-commented. I guess this was commented out for testing purpose.

That's a private bug (I believe it related to some internal testing which cannot be made public). Yu are right that this change is there to ensure the test checks stub save and restore. I also tweaked the AOTCodeFlags test for the same purpose. This change cannot go in as is without checking that it avoids the issue in JDK-8357398. If it does not then we would need to reset the above edit and the test. However, that means tier1 testing could fail to catch stub changes that correctly update runtime generation but fail to cache (the most likely error is failing to register an external address with the AOT cache). So, I'd prefer it if we could recheck the problem in JDK-8357398 and leave these changes as is. Perhaps @vnkozlov could help here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/28433#discussion_r2707614833