On Thu, 16 Apr 2026 23:09:52 GMT, Vladimir Kozlov <[email protected]> wrote:
> Improve startup and warmup time by making optimized native code for an > application instantly available when the HotSpot Java Virtual Machine starts. > Achieve this by compiling application code to native code in a training run, > storing the native code in the [AOT > cache](https://openjdk.org/jeps/483#Description) for use in subsequent > production runs. > > More details in the [JEP](https://openjdk.org/jeps/544). > > --------- > - [x] I confirm that I make this contribution in accordance with the [OpenJDK > Interim AI Policy](https://openjdk.org/legal/ai). Why I did not hit this in our internal testing? assert(_extrs_length <= 380) failed: increase size There is also crash on MacOS-x86 with -XX:+UseShenandoahGC during product run. >From my local X86 testing with Z GC and additional output update: [0.260s][info ][aot,codecache,init] External addresses 368 recorded and closed ... [0.304s][debug][aot,codecache,init ] External C1 addresses 4 recorded Which is very near 380 limit. It is possible we generate more intrinsics/stubs on GHA machines. 400 could be still small. I will change it to 500 `string_indexof_linear_ll` address is registered by `do_stub(compiler, string_indexof_linear_ll)`. The stub it self is part of **is_multi_stub_blob** `compiler_stub` blob. What command line you used? So these addresses are stored in `StubRoutines::_string_indexof_array[]` and in Leyden (which does not have Andrew's stubs caching) we records all elements of these array: #ifdef COMPILER2 for (int i = 0; i < 4; i++) { SET_ADDRESS(_stubs, StubRoutines::_string_indexof_array[i]); } #endif I don't see any reference to `StubRoutines::_string_indexof_array` in stubs declaration. I assumed it should be covered by `do_stub(compiler, string_indexof_linear_ll)` But based on my recent changes for #30735 we indeed missing similar `ADD()` code here. I looked and this stubs are only used for ECore which we don't have in our testing and that is why it is passed: #ifdef COMPILER2 if ((UseAVX == 2) && EnableX86ECoreOpts) { generate_string_indexof(StubRoutines::_string_indexof_array); } #endif I added `string_indexof_array[]` addresses in `AOTCodeAddressTable::set_stubgen_stubs_complete()`. I leave the bug fixing to @adinn because I don't know how to use `do_entry_array()` macro for this case. We discussed this on meeting. Windows VS can "optimize" address of a function which just calls an other one. The current Windows GHA failure is because of that - VS compiles `clone_addr()` to return address of common `HeapAccess<>::clone(src, dst, size)` method instead of GC specific one: JRT_LEAF(void, G1BarrierSetRuntime::clone(oopDesc* src, oopDesc* dst, size_t size)) HeapAccess<>::clone(src, dst, size); JRT_END address G1BarrierSetRuntime::clone_addr() { return reinterpret_cast<address>(clone); } As result AOT address table caught "duplicated" address when we added `ZBarrierSetRuntime::clone_addr()`. I will fix it by placing `if (Use*GC)` checks when we add GC related addresses to AOT table. For portability we will have to disable address nops >= 12. @adinn I did not added missing JFR's external addresses yet. s390 compilation failure in GHA is known issue [JDK-8389552](https://bugs.openjdk.org/browse/JDK-8389552) ------------- PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4268064413 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4268065546 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4268359157 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4268372484 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4274457783 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4282849219 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4283761769 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4317056643 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4360378792 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4412748294 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-5160616447
