On Sat, 18 Apr 2026 19:55:37 GMT, Vladimir Kozlov <[email protected]> wrote:
> 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.
Right, but IIUC registering alone does not put it in the aot code cache. For
each stub, we need to add calls to `load_archive_data()/store_archive_data()`.
> What command line you used?
I wanted to run the compiler tests with AOTCache, so I issued:
make test TEST=test/hotspot/jtreg/compiler JTREG="AOT_JDK=twostep"
The assertion happened when creating the AOT cache:
java
-Xlog:aot,aot+class=debug:file=build/8380476-fd/test-support/jtreg_test_hotspot_jtreg_compiler/aot/jdk.aotcache.log
-Xlog:cds*=error -Xlog:aot*=error
-XX:ExtraSharedClassListFile=build/8380476-fd/images/jdk/lib/classlist
-XX:AOTMode=create
-XX:AOTConfiguration=build/8380476-fd/test-support/jtreg_test_hotspot_jtreg_compiler/aot/jdk.aotconf
-XX:AOTCache=build/8380476-fd/test-support/jtreg_test_hotspot_jtreg_compiler/aot/jdk.aotcache
> I added string_indexof_array[] addresses in
> AOTCodeAddressTable::set_stubgen_stubs_complete().
@vnkozlov with this change and my patch for using
`AOTCompressedPointers::narrowPtr` I don't see any failure when running
compiler tests with AOT Cache.
> 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.
@vnkozlov @adinn we already capture certain VM flags that can affect the
usability of the aot code cache in `AOTCodeCache::Config`. But there may be
more flags that may impact the compiled code. For instance on x86 there is
`UseIncDec` which is true by default but set to false for atom and knights
family (done under https://bugs.openjdk.org/browse/JDK-8182138) due to
performance reasons.
With AOTCodeCache it is possible the AOT compiled code with `inc` and `dec`
instructions is executed on atom/knight processor in the production run and it
may not deliver the same performance had the AOT compiled code been generated
on atom/ knight processor. I think peak performance would not be affected as we
now have the aging mechanism in place, so the app won't be stuck in the
under-optimized aot code.
Should we track such flags as well?
And then there is a flag like `UseAddressNop` which is also enabled based on a
combination of cpu family and features. IIUC this flag enables multibyte nops
and if it is executed on a cpu which doesn't support, it may result in crash.
So this flag should be captured in the `AOTCodeCache::Config`. Moreover, it
seems [encoding by the
assembler](https://github.com/openjdk/jdk/blob/004d0ecf8693961455f4fe75cf0232aa6eead307/src/hotspot/cpu/x86/assembler_x86.cpp#L4280)
for multibyte nops is slightly different between vendors. I think this
necessitates the need to capture the vendors in `AOTCodeCache::Config`.
However, we can work around both the problems by switching to single-byte nops
at the cost of the performance loss with aot compiled code. I haven't come
across any other flag or instruction whose encoding depends on the vendor.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4275035798
PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4286050768
PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4347333050
