RFR: 8358690: Some initialization code asks for AOT cache status way too early

[Andrew Dinn]

On Thu, 12 Jun 2025 04:44:24 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Thanks to @shipilev for catching the issue.
>> 
>> [JDK-8350209](https://bugs.openjdk.org/browse/JDK-8350209) came with the bootstrapping problem by checking the AOT cache status way too early. Before full AOT cache init sequence runs, these checks would always reply that AOT cache is off. This causes initial stubs to never practically restored/dumped.
>> 
>> This does not affect JDK 25 because [JDK-8357514](https://github.com/openjdk/jdk/commit/8184ce39a8a732352ee841fed09cae905d27643c) switched off AOT stubs generation.
>> 
>> We can't resolve bootstrap issue as it is because `initial_stubs_init()` is  called before `universe_init()` where AOT code cache is created.  I looked why it is required (based on comments) that `initial_stubs_init()` be called before `universe_init()`. And I found that we had a special stub during HotSpot development (1997) which was used for Vtable entries population when we run with -Xcomp (or whatever was equivalent back then). We still have reference to it in the comment: [stubRoutines.cpp#L185](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/runtime/stubRoutines.cpp#L185).
>> 
>> We don't have that code anymore. I moved `initial_stubs_init()` after `universe_init()` and `AOTCodeCache::init2()`. I added asserts into some initial stubs to check that they are not NULL when used. I ran from hs-tier1 to hs-tier6 + hs-tier10-rt.
>> 
>> The only issue I found is that `AOTCodeCache::init_early_stubs()` needs to be call separately after `initial_stubs_init()` instead of from `AOTCodeCache::init2()`. This solved bootstrap issue.
>> 
>> I also did some cleanup to match `leyden/premain` branch for easy merges.
>> 
>> Tested hs-tier1-6, hs-tier1-rt, stress, xcomp
>
> I found that `StubRoutines::_fence_entry` from initial stubs is used by [OrderAccess::fence()](https://github.com/openjdk/jdk/blob/master/src/hotspot/os_cpu/windows_x86/orderAccess_windows_x86.hpp#L50) on Windows-x64 and only. And `OrderAccess::fence()` is used by GC worked threads which are started by `universe_init()`.
> 
> I am work on fixing it. I hope I don't need to move all initial stubs. May be 'pre-initial` stubs for this?

@vnkozlov Are you suggesting moving the fence stubs to a separate StubGen preinitial blob created before the initial blob? That should be relatively easy to do.

If you want me to push that change first in a separate PR I will be happy to do so.

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

PR Comment: https://git.openjdk.org/jdk/pull/25763#issuecomment-2965753322