On Sun, 19 Apr 2026 02:48:21 GMT, Ashutosh Mehra <[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. >> >> What command line you used? > >> 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 @ashu-mehra I reproduced your issue by using your command plus `TEST_OPTS_JAVA_OPTIONS="-XX:UseAVX=2 -XX:+EnableX86ECoreOpts"` > @ashu-mehra I reproduced your issue by using your command plus > `TEST_OPTS_JAVA_OPTIONS="-XX:UseAVX=2 -XX:+EnableX86ECoreOpts"` I filed https://bugs.openjdk.org/browse/JDK-8382546 >> 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. @ashu-mehra > Should we track such flags as well? Not now. As you said, it should not affect much. I agree with using general NOPs as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4283016370 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4283077269 PR Comment: https://git.openjdk.org/jdk/pull/30778#issuecomment-4354375304
