Re: RFR: 8350209: Preserve adapters in AOT cache [v12]
On Wed, 30 Apr 2025 02:05:41 GMT, Vladimir Kozlov wrote: >> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class >> information in AOT cache which helps Java startup performance. >> >> We should also preserve adapters (i2c, c2i) to further improve performance >> of class linking where adapters are generated. >> >> Short running Java application can see several percents improvement. I got >> 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): >> >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > >> /dev/null) 2>&1 | grep elapsed >> 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache >> -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar >> HelloWorld > /dev/null) 2>&1 | grep elapsed >> 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) >> >> >> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to >> unlock them): >> >> >> -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i >> adapters >> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching >> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code >> caching failure >> >> By default `AOTAdapterCaching` is `false` and enabled ergonomically when >> `-XX:AOTCache` is specified. >> This flag is ignored when `AOTCache` is not specified. >> >> To use AOT adapters follow process described in JEP 483: >> >> >> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App >> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf >> -XX:AOTCache=app.aot -cp app.jar >> java -XX:AOTCache=app.aot -cp app.jar App >> >> >> There are several new UL flag combinations to trace the AOT code caching >> process: >> >> >> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs >> >> >> @ashu-mehra is main author of changes. He implemented adapters caching. >> I did main framework (`AOTCodeCache` class) for saving and loading AOT code. >> >> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also >> Xcomp,stress and JCK. > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > address Ioi's comments Marked as reviewed by iklam (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2805579280
Re: RFR: 8355570: [s390x] Update -march to z13 generation
On Mon, 28 Apr 2025 19:35:46 GMT, Magnus Ihse Bursie wrote: > This is a failure when building the gtest framework. > > Could this different arch flag be sensitive to different gcc versions? When > you say you tested locally, what gcc version did you use? This is the config: gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) - PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2840757074
Re: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v5]
> Improve warm-up time by making profile data from a previous run of an > application instantly available, when the HotSpot Java Virtual Machine > starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) > to store method execution profiles from training runs, reducing profiling > delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: - Address review comments part 2 - Merge branch 'master' into pp2 - Merge branch 'master' into pp2 - Fix class filtering - Remove the workaround of setting AOTRecordTraining during assembly - Address some of the review comments - Merge branch 'master' into pp - Add AOTCompileEagerly flag to control compilation after clinit - Port 8355334: [leyden] Missing type profile info in archived training data - Port 8355296: [leyden] Some methods are stuck at level=0 with -XX:-TieredCompilation - ... and 24 more: https://git.openjdk.org/jdk/compare/6850757f...4514d032 - Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=04 Stats: 3197 lines in 57 files changed: 2972 ins; 103 del; 122 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886
Re: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v5]
On Sun, 27 Apr 2025 01:15:54 GMT, Vladimir Kozlov wrote: >> You mean you want these checks to be done only if `TrainingData::have_data() >> == true` ? > > Yes, if it is related. Otherwise you may change default behavior when Leyden > code is not used. I simplified it and factored out the new semantics. - PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2067883564
Re: RFR: 8350209: Preserve adapters in AOT cache [v11]
On Tue, 29 Apr 2025 15:29:08 GMT, Vladimir Kozlov wrote:
>> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class
>> information in AOT cache which helps Java startup performance.
>>
>> We should also preserve adapters (i2c, c2i) to further improve performance
>> of class linking where adapters are generated.
>>
>> Short running Java application can see several percents improvement. I got
>> 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz):
>>
>>
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld >
>> /dev/null) 2>&1 | grep elapsed
>> 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% )
>>
>> (perf stat -r 100 java -XX:AOTCache=app.aotcache
>> -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar
>> HelloWorld > /dev/null) 2>&1 | grep elapsed
>> 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% )
>>
>>
>> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to
>> unlock them):
>>
>>
>> -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i
>> adapters
>> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching
>> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code
>> caching failure
>>
>> By default `AOTAdapterCaching` is `false` and enabled ergonomically when
>> `-XX:AOTCache` is specified.
>> This flag is ignored when `AOTCache` is not specified.
>>
>> To use AOT adapters follow process described in JEP 483:
>>
>>
>> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App
>> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf
>> -XX:AOTCache=app.aot -cp app.jar
>> java -XX:AOTCache=app.aot -cp app.jar App
>>
>>
>> There are several new UL flag combinations to trace the AOT code caching
>> process:
>>
>>
>> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs
>>
>>
>> @ashu-mehra is main author of changes. He implemented adapters caching.
>> I did main framework (`AOTCodeCache` class) for saving and loading AOT code.
>>
>> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also
>> Xcomp,stress and JCK.
>
> Vladimir Kozlov has updated the pull request incrementally with one
> additional commit since the last revision:
>
> Remove unused method
LGTM. Some small nits.
src/hotspot/share/cds/filemap.cpp line 1296:
> 1294: mapped_base = requested_base;
> 1295: } else {
> 1296: bool read_only = false, allow_exec = false;
Add comment for clarity:
// We do not execute in-place in the AOT code region. AOT code is copied to
// the CodeCache for execution.
bool read_only = false, allow_exec = false;
src/hotspot/share/include/cds.h line 38:
> 36: // Also, this is a C header file. Do not use C++ here.
> 37:
> 38: #define NUM_CDS_REGIONS 5 // this must be the same as
> MetaspaceShared::n_regions
Change `CURRENT_CDS_ARCHIVE_VERSION` below to `19`
-
Marked as reviewed by iklam (Reviewer).
PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2805483199
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2067701064
PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2067702057
Re: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK [v3]
On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie wrote: >> Jiangli Zhou has updated the pull request incrementally with two additional >> commits since the last revision: >> >> - Merge branch 'JDK-8355080' of ssh://github.com/jianglizhou/jdk into >> JDK-8355080 >> - Address henryjen@ comment: >>- Remove '#include '. > > This was news to me. I'm thinking about what this means in terms of the > static build, where all native JDK libraries are "loaded" as soon as the > application starts executing. Do we have native libraries in the JDK that are > not loaded by the boot loader? If so, have we introduced some corner case > effects by marking them with the static JNI symbol? 🤔 @magicus For existing JDK JNI native libraries, I think adding `DEF_STATIC_JNI_OnLoad` (if missing) does not affect the classloader usage associated with the library. The static support for built-in JNI native library affects the native "load" operation (e.g. on Linux `dlopen`) only ([Java_jdk_internal_loader_NativeLibraries_load](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L119). Double checking [Java_jdk_internal_loader_NativeLibraries_unload](https://github.com/openjdk/jdk/blob/c2485d5f7dd00eaed34a5d309276114eb4c78cb0/src/java.base/share/native/libjava/NativeLibraries.c#L180), the existing code also makes sure `JVM_UnloadLibrary` is not called to "unload" (e.g. on Linux `dlclose`) built-in JNI native library. The reason why boot loader question/consideration brought up in this thread was because `libsyslookup` was not associated with the boot loader but now does with the change in src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java. - PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2840305879
Re: RFR: 8350209: Preserve adapters in AOT cache [v12]
> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class > information in AOT cache which helps Java startup performance. > > We should also preserve adapters (i2c, c2i) to further improve performance of > class linking where adapters are generated. > > Short running Java application can see several percents improvement. I got 6% > improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): > > > (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > > /dev/null) 2>&1 | grep elapsed > 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) > > (perf stat -r 100 java -XX:AOTCache=app.aotcache > -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar > HelloWorld > /dev/null) 2>&1 | grep elapsed > 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) > > > New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to > unlock them): > > > -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i > adapters > -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching > -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code > caching failure > > By default `AOTAdapterCaching` is `false` and enabled ergonomically when > `-XX:AOTCache` is specified. > This flag is ignored when `AOTCache` is not specified. > > To use AOT adapters follow process described in JEP 483: > > > java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App > java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot > -cp app.jar > java -XX:AOTCache=app.aot -cp app.jar App > > > There are several new UL flag combinations to trace the AOT code caching > process: > > > -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs > > > @ashu-mehra is main author of changes. He implemented adapters caching. > I did main framework (`AOTCodeCache` class) for saving and loading AOT code. > > Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also > Xcomp,stress and JCK. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: address Ioi's comments - Changes: - all: https://git.openjdk.org/jdk/pull/24740/files - new: https://git.openjdk.org/jdk/pull/24740/files/b2466e6e..78f2828d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=10-11 Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740 PR: https://git.openjdk.org/jdk/pull/24740
Re: RFR: 8350209: Preserve adapters in AOT cache [v11]
On Wed, 30 Apr 2025 01:15:21 GMT, Ioi Lam wrote: >> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Remove unused method > > LGTM. Some small nits. Thank you, @iklam, for review. I pushed your suggestions. - PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2840619267
RE: clang Memory sanitizer (msan) and OpenJDK
* I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-) Yeah I looked into msan some time ago and wanted to look into it again now . * I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler? I think so ! When I build a simple (working) example with msan (clang++ -fsanitize=memoryin complie and link step, no libs added), I get a LOT of msan symbols in the resulting binary : nm msan_umr | grep _msan | more 000221a0 t _GLOBAL__sub_I_msan_chained_origin_depot.cpp 00057520 T __msan_allocated_memory 0004c5c0 T __msan_chain_origin 0004c2b0 T __msan_check_mem_is_initialized 00093200 T __msan_clear_and_unpoison 0004c020 T __msan_clear_on_return 00057600 T __msan_copy_shadow 0004cb50 W __msan_default_options 0004c150 T __msan_dump_shadow 0004ca60 T __msan_finish_switch_fiber 0004c3c0 T __msan_get_origin 0004ade0 T __msan_get_track_origins 0004c710 T __msan_get_umr_origin * Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference. Sounds like a good idea to start with, I will try this! Seems the visibility stuff plays a role here. Best regards, Matthias From: Magnus Ihse Bursie Sent: Monday, 28 April 2025 22:06 To: Baesken, Matthias ; build-dev@openjdk.org Subject: Re: clang Memory sanitizer (msan) and OpenJDK I thought I recognized this issue, and started searching the mail archive. Seems the same question was asked last year by ... you. :-) https://mail.openjdk.org/pipermail/build-dev/2024-August/046011.html I guess nobody still has a simple answer to give you. I don't understand how the msan internal functions are supposed to work, if there is no library to link to. Are they added by the compiler? Maybe you can try patching out -fvisibility=hidden from the compile command line to see if that makes any difference. /Magnus On 2025-04-25 16:28, Baesken, Matthias wrote: Hi, Memory sanitizer https://clang.llvm.org/docs/MemorySanitizer.html is supported with the clang toolchain (e.g. on Linux) ; “MemorySanitizer is a detector of uninitialized memory use” . For small examples it is rather easy to use, you just compile and link with -fsanitize=memory (and for better results maybe additionally -fno-omit-frame-pointer ) . So I gave it a try with OpenJDK too and added -fsanitize=memory to the C/CXX and LD flags (--with-extra-cflags=-fsanitize=memory --with-extra-cxxflags=-fsanitize=memory --with-extra-ldflags=-fsanitize=memory ). As far as compiling single compilation units this seems to be okay . But when it comes to executing the new generated binaries in the build process we unfortunately get lookup errors / undefined symbols : /builddir/jdk/bin/javac: symbol lookup error: /builddir/jdk/bin/../lib/libjli.so: undefined symbol: __msan_param_tls Is there something special in our OpenJDK build that causes trouble here ? Here I found an somewhat similar looking issue : https://groups.google.com/g/memory-sanitizer/c/xV3OZZCiL9A where re-exporting symbols is mentioned - is this maybe something that hits us in OpenJDK too ? For address sanitizer, we set -shared-libasan in the OpenJDK : https://github.com/openjdk/jdk/blob/5c067232bf21aaca2b7addd2a862e15a8696ffb8/make/autoconf/jdk-options.m4#L449 ASAN_LDFLAGS="$ASAN_LDFLAGS -shared-libasan" But I could not find something similar for msan . (btw. I use clang 15.0.7 on SUSE Linux x86_64 in case this matters) Best regards, Matthias
Re: RFR: 8355594: Warnings occur when building with clang and enabling ubsan [v2]
On Tue, 29 Apr 2025 09:05:07 GMT, Matthias Baesken wrote: >> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX >> or Linux), we get the following warnings : >> >> >> warning: unknown warning option '-Wno-stringop-truncation'; did you mean >> '-Wno-string-concatenation'? [-Wunknown-warning-option] >> warning: unknown warning option '-Wno-format-overflow'; did you mean >> '-Wno-shift-overflow'? [-Wunknown-warning-option] >> warning: unknown warning option '-Wno-stringop-overflow'; did you mean >> '-Wno-shift-overflow'? [-Wunknown-warning-option] > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Sort flags Marked as reviewed by erikj (Reviewer). - PR Review: https://git.openjdk.org/jdk/pull/24924#pullrequestreview-2803359916
Re: RFR: 8355594: Warnings occur when building with clang and enabling ubsan [v2]
On Tue, 29 Apr 2025 09:05:07 GMT, Matthias Baesken wrote: >> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX >> or Linux), we get the following warnings : >> >> >> warning: unknown warning option '-Wno-stringop-truncation'; did you mean >> '-Wno-string-concatenation'? [-Wunknown-warning-option] >> warning: unknown warning option '-Wno-format-overflow'; did you mean >> '-Wno-shift-overflow'? [-Wunknown-warning-option] >> warning: unknown warning option '-Wno-stringop-overflow'; did you mean >> '-Wno-shift-overflow'? [-Wunknown-warning-option] > > Matthias Baesken has updated the pull request incrementally with one > additional commit since the last revision: > > Sort flags Thanks for the reviews ! - PR Comment: https://git.openjdk.org/jdk/pull/24924#issuecomment-2838910357
Integrated: 8355594: Warnings occur when building with clang and enabling ubsan
On Mon, 28 Apr 2025 15:22:50 GMT, Matthias Baesken wrote: > When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or > Linux), we get the following warnings : > > > warning: unknown warning option '-Wno-stringop-truncation'; did you mean > '-Wno-string-concatenation'? [-Wunknown-warning-option] > warning: unknown warning option '-Wno-format-overflow'; did you mean > '-Wno-shift-overflow'? [-Wunknown-warning-option] > warning: unknown warning option '-Wno-stringop-overflow'; did you mean > '-Wno-shift-overflow'? [-Wunknown-warning-option] This pull request has now been integrated. Changeset: 9f42ff89 Author:Matthias Baesken URL: https://git.openjdk.org/jdk/commit/9f42ff8960c740fa6ae5be21677b874463c7f500 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8355594: Warnings occur when building with clang and enabling ubsan Reviewed-by: erikj, jkern, ihse - PR: https://git.openjdk.org/jdk/pull/24924
RE: clang Memory sanitizer (msan) and OpenJDK
>>Maybe you can try patching out -fvisibility=hidden from the compile command >>line to see if that makes any difference. >Sounds like a good idea to start with, I will try this! Seems the visibility >stuff plays a role here. I removed the -fvisibility=hidden from make/autoconf/flags-cflags.m4 (3 places) but the issue is still there. When looking at our launchers in the msan – enabled build (java, javac) I see the msan_param_tls as “b” (local symbol) . But I think it is expected as “B” (global/exported) . In my simple working standalone example, the msan_param_tls is “B” . So there must be something in out build that prevents the “export” of those msan symbols (even when removing -fvisibility=hidden ) . Probably I should look in more details at our launcher builds and all the settings ... Best regards, Matthias
Re: RFR: 8355080: java.base/jdk.internal.foreign.SystemLookup.find() doesn't work on static JDK [v3]
On Tue, 29 Apr 2025 06:43:59 GMT, Magnus Ihse Bursie wrote: > Do we have native libraries in the JDK that are not loaded by the boot > loader? There are few, e.g. java.security.jgss, jdk.security.auth and jdk.crypto.cryptoki are mapped to the platform class loader, and jdk.attach mapped to the application class loader. - PR Comment: https://git.openjdk.org/jdk/pull/24801#issuecomment-2837849469
Re: RFR: 8355697: Create windows devkit on wsl and msys2 [v3]
On Tue, 29 Apr 2025 03:38:33 GMT, kuaiwei wrote: >> The patch fix error when creating devkit on wsl/msys2 . >> * Msys2 can be supported like cygwin >> * In wsl, it can not test path name in windows format, like `if [ -d >> "d:/VisualStuio"]` . The path must be converted as linux style before >> testing. >> * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it >> can be work around with `cmd.exe //c`. see >> https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell >> >> I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6) > > kuaiwei has updated the pull request incrementally with one additional commit > since the last revision: > > Support more msys2 environments and use MSYS2_ARG_CONV_EXCL for cmd.exe @kuaiwei Your change (at version a81a294e7d6a6630604c03e72f7adfe7565ff9b9) is now ready to be sponsored by a Committer. - PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2837862847
Re: RFR: 8355697: Create windows devkit on wsl and msys2 [v2]
On Mon, 28 Apr 2025 13:47:47 GMT, Erik Joelsson wrote: >> kuaiwei has updated the pull request incrementally with one additional >> commit since the last revision: >> >> Get SDK_INSTALL_DIR from enviroment variable > > Verified that it still works in Cygwin on my machine. Looks good. @erikj79 @magicus Thanks for your review. - PR Comment: https://git.openjdk.org/jdk/pull/24916#issuecomment-2837899304
Integrated: 8355697: Create windows devkit on wsl and msys2
On Mon, 28 Apr 2025 11:03:16 GMT, kuaiwei wrote: > The patch fix error when creating devkit on wsl/msys2 . > * Msys2 can be supported like cygwin > * In wsl, it can not test path name in windows format, like `if [ -d > "d:/VisualStuio"]` . The path must be converted as linux style before testing. > * In msys2, `cmd.exe /c` doesn't work because "/c" is converted as "c:", it > can be work around with `cmd.exe //c`. see > https://superuser.com/questions/526736/how-to-run-internal-cmd-command-from-the-msys-shell > > I tested it with win10 + wsl/msys2 + VisualStudio 2022(17.13.6) This pull request has now been integrated. Changeset: 31e70e41 Author:Kuai Wei Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/31e70e41d56777ba6f4bba4cc3266130646b3202 Stats: 17 lines in 1 file changed: 12 ins; 0 del; 5 mod 8355697: Create windows devkit on wsl and msys2 Reviewed-by: ihse, erikj - PR: https://git.openjdk.org/jdk/pull/24916
Re: RFR: 8355594: Warnings occur when building with clang and enabling ubsan [v2]
On Mon, 28 Apr 2025 19:25:55 GMT, Magnus Ihse Bursie wrote: >> Matthias Baesken has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Sort flags > > make/autoconf/jdk-options.m4 line 525: > >> 523: UBSAN_CFLAGS="$UBSAN_CHECKS -Wno-array-bounds -fno-omit-frame-pointer >> -DUNDEFINED_BEHAVIOR_SANITIZER" >> 524: if test "x$TOOLCHAIN_TYPE" = "xgcc"; then >> 525: UBSAN_CFLAGS="$UBSAN_CFLAGS -Wno-stringop-truncation >> -Wno-format-overflow -Wno-stringop-overflow" > > Just for the sake of my sanity, can you reorder the `-Wno-*` options in > alphabetical order? Done ! Need a re-review now . - PR Review Comment: https://git.openjdk.org/jdk/pull/24924#discussion_r2065839527
Re: RFR: 8355594: Warnings occur when building with clang and enabling ubsan [v2]
> When building ubsan-enabled binaries with the clang toolchain (e.g. on AIX or > Linux), we get the following warnings : > > > warning: unknown warning option '-Wno-stringop-truncation'; did you mean > '-Wno-string-concatenation'? [-Wunknown-warning-option] > warning: unknown warning option '-Wno-format-overflow'; did you mean > '-Wno-shift-overflow'? [-Wunknown-warning-option] > warning: unknown warning option '-Wno-stringop-overflow'; did you mean > '-Wno-shift-overflow'? [-Wunknown-warning-option] Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Sort flags - Changes: - all: https://git.openjdk.org/jdk/pull/24924/files - new: https://git.openjdk.org/jdk/pull/24924/files/dbfcece2..72bec244 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24924&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24924&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24924.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24924/head:pull/24924 PR: https://git.openjdk.org/jdk/pull/24924
Re: RFR: 8350209: Preserve adapters in AOT cache [v11]
> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class > information in AOT cache which helps Java startup performance. > > We should also preserve adapters (i2c, c2i) to further improve performance of > class linking where adapters are generated. > > Short running Java application can see several percents improvement. I got 6% > improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): > > > (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > > /dev/null) 2>&1 | grep elapsed > 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) > > (perf stat -r 100 java -XX:AOTCache=app.aotcache > -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar > HelloWorld > /dev/null) 2>&1 | grep elapsed > 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) > > > New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to > unlock them): > > > -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i > adapters > -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching > -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code > caching failure > > By default `AOTAdapterCaching` is `false` and enabled ergonomically when > `-XX:AOTCache` is specified. > This flag is ignored when `AOTCache` is not specified. > > To use AOT adapters follow process described in JEP 483: > > > java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App > java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf -XX:AOTCache=app.aot > -cp app.jar > java -XX:AOTCache=app.aot -cp app.jar App > > > There are several new UL flag combinations to trace the AOT code caching > process: > > > -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs > > > @ashu-mehra is main author of changes. He implemented adapters caching. > I did main framework (`AOTCodeCache` class) for saving and loading AOT code. > > Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also > Xcomp,stress and JCK. Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: Remove unused method - Changes: - all: https://git.openjdk.org/jdk/pull/24740/files - new: https://git.openjdk.org/jdk/pull/24740/files/1b0c89f6..b2466e6e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24740.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24740/head:pull/24740 PR: https://git.openjdk.org/jdk/pull/24740
Re: RFR: 8350209: Preserve adapters in AOT cache [v8]
On Tue, 29 Apr 2025 14:42:42 GMT, Ashutosh Mehra wrote: >> Vladimir Kozlov has updated the pull request incrementally with one >> additional commit since the last revision: >> >> Downgraded UL as asked. Added synchronization to C strings caching. > > src/hotspot/share/code/aotCodeCache.hpp line 340: > >> 338: static const char* add_C_string(const char* str) NOT_CDS_RETURN_(str); >> 339: >> 340: static const char* add_C_string2(const char* str) NOT_CDS_RETURN_(str); > > This method is not used. removed - PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2066822894
Re: RFR: 8350209: Preserve adapters in AOT cache [v11]
On Tue, 29 Apr 2025 15:29:08 GMT, Vladimir Kozlov wrote: >> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class >> information in AOT cache which helps Java startup performance. >> >> We should also preserve adapters (i2c, c2i) to further improve performance >> of class linking where adapters are generated. >> >> Short running Java application can see several percents improvement. I got >> 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): >> >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > >> /dev/null) 2>&1 | grep elapsed >> 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache >> -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar >> HelloWorld > /dev/null) 2>&1 | grep elapsed >> 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) >> >> >> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to >> unlock them): >> >> >> -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i >> adapters >> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching >> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code >> caching failure >> >> By default `AOTAdapterCaching` is `false` and enabled ergonomically when >> `-XX:AOTCache` is specified. >> This flag is ignored when `AOTCache` is not specified. >> >> To use AOT adapters follow process described in JEP 483: >> >> >> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App >> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf >> -XX:AOTCache=app.aot -cp app.jar >> java -XX:AOTCache=app.aot -cp app.jar App >> >> >> There are several new UL flag combinations to trace the AOT code caching >> process: >> >> >> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs >> >> >> @ashu-mehra is main author of changes. He implemented adapters caching. >> I did main framework (`AOTCodeCache` class) for saving and loading AOT code. >> >> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also >> Xcomp,stress and JCK. > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > Remove unused method Marked as reviewed by asmehra (Committer). - PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2804162746
Re: RFR: 8354919: Move HotSpot .editorconfig into the global .editorconfig
On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters wrote: > The src/hotspot directory should ideally only be used for HotSpot source > files, and we should avoid polluting it with an .editorconfig. A cleaner > solution exists since we can just specify the desired code formatting for > HotSpot as an override in the root .editorconfig To address Sergey's concerns, testing on my end _seems_ to indicate that it does inherit the whitespace option. Since this is not a serious breaking change, I'm going to integrate it. If it turns out to break editor formatting for someone somewhere, we can easily back this out later Oops, before I integrate, this should have the ide-support flag too - PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2839366874 PR Comment: https://git.openjdk.org/jdk/pull/24714#issuecomment-2839369944
Integrated: 8354919: Move HotSpot .editorconfig into the global .editorconfig
On Thu, 17 Apr 2025 07:28:03 GMT, Julian Waters wrote: > The src/hotspot directory should ideally only be used for HotSpot source > files, and we should avoid polluting it with an .editorconfig. A cleaner > solution exists since we can just specify the desired code formatting for > HotSpot as an override in the root .editorconfig This pull request has now been integrated. Changeset: fa2a9d1e Author:Julian Waters URL: https://git.openjdk.org/jdk/commit/fa2a9d1e10679aad270f4641f43595b36fe8e04c Stats: 7 lines in 2 files changed: 4 ins; 3 del; 0 mod 8354919: Move HotSpot .editorconfig into the global .editorconfig Reviewed-by: erikj, ihse - PR: https://git.openjdk.org/jdk/pull/24714
RE: clang Memory sanitizer (msan) and OpenJDK
I checked the link call for javac . /usr/bin/clang -fuse-ld=lld -fuse-ld=lld -Wl,--exclude-libs,ALL -Wl,-z,noexecstack -m64 -fsanitize=memory Could it be that the -Wl,--exclude-libs,ALL“hides” the msan symbols like __msan_param_tlsfrom exporting ? But I guess we set this for a reason so removing it might cause other trouble ? Best regards, Matthias >>Maybe you can try patching out -fvisibility=hidden from the compile command >>line to see if that makes any difference. >Sounds like a good idea to start with, I will try this! Seems the visibility >stuff plays a role here. I removed the -fvisibility=hidden from make/autoconf/flags-cflags.m4 (3 places) but the issue is still there. When looking at our launchers in the msan – enabled build (java, javac) I see the msan_param_tls as “b” (local symbol) . But I think it is expected as “B” (global/exported) . In my simple working standalone example, the msan_param_tls is “B” . So there must be something in out build that prevents the “export” of those msan symbols (even when removing -fvisibility=hidden ) . Probably I should look in more details at our launcher builds and all the settings ... Best regards, Matthias
Re: RFR: 8350209: Preserve adapters in AOT cache [v10]
On Tue, 29 Apr 2025 06:27:41 GMT, Vladimir Kozlov wrote: >> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class >> information in AOT cache which helps Java startup performance. >> >> We should also preserve adapters (i2c, c2i) to further improve performance >> of class linking where adapters are generated. >> >> Short running Java application can see several percents improvement. I got >> 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): >> >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > >> /dev/null) 2>&1 | grep elapsed >> 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache >> -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar >> HelloWorld > /dev/null) 2>&1 | grep elapsed >> 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) >> >> >> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to >> unlock them): >> >> >> -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i >> adapters >> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching >> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code >> caching failure >> >> By default `AOTAdapterCaching` is `false` and enabled ergonomically when >> `-XX:AOTCache` is specified. >> This flag is ignored when `AOTCache` is not specified. >> >> To use AOT adapters follow process described in JEP 483: >> >> >> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App >> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf >> -XX:AOTCache=app.aot -cp app.jar >> java -XX:AOTCache=app.aot -cp app.jar App >> >> >> There are several new UL flag combinations to trace the AOT code caching >> process: >> >> >> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs >> >> >> @ashu-mehra is main author of changes. He implemented adapters caching. >> I did main framework (`AOTCodeCache` class) for saving and loading AOT code. >> >> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also >> Xcomp,stress and JCK. > > Vladimir Kozlov has updated the pull request with a new target base due to a > merge or a rebase. The pull request now contains 11 commits: > > - Fix C strings caching > - Merge branch 'master' into JDK-8350209 > - Merge branch 'master' into JDK-8350209 > - Downgraded UL as asked. Added synchronization to C strings caching. > - Fix message > - Generate far jumps for AOT code on AArch64 > - remove _enabled suffix > - Add sanity test for AOTAdapterCaching flag > - AOT code flags are ignored when AOTCache is not specified. Set range for > AOTCodeMaxSize values. > - Removed unused AOTCodeSection class > - ... and 1 more: https://git.openjdk.org/jdk/compare/7cf190fb...1b0c89f6 Just to note there is still some code related to blobs but we are not storing them yet in the aot code cache. But I think we would need them pretty soon. So I think it should be okay to keep that code as is. rest lgtm - PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839210239 PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839211140
Re: RFR: 8350209: Preserve adapters in AOT cache [v10]
On Tue, 29 Apr 2025 14:47:42 GMT, Ashutosh Mehra wrote: >> Vladimir Kozlov has updated the pull request with a new target base due to a >> merge or a rebase. The pull request now contains 11 commits: >> >> - Fix C strings caching >> - Merge branch 'master' into JDK-8350209 >> - Merge branch 'master' into JDK-8350209 >> - Downgraded UL as asked. Added synchronization to C strings caching. >> - Fix message >> - Generate far jumps for AOT code on AArch64 >> - remove _enabled suffix >> - Add sanity test for AOTAdapterCaching flag >> - AOT code flags are ignored when AOTCache is not specified. Set range for >> AOTCodeMaxSize values. >> - Removed unused AOTCodeSection class >> - ... and 1 more: https://git.openjdk.org/jdk/compare/7cf190fb...1b0c89f6 > > rest lgtm Thank you, @ashu-mehra, for review! - PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2839457011
RE: clang Memory sanitizer (msan) and OpenJDK
>Could it be that the -Wl,--exclude-libs,ALL“hides” the msan symbols >like __msan_param_tlsfrom exporting ? >But I guess we set this for a reason so removing it might cause other trouble ? Seems the -Wl,--exclude-libs,ALL is the setting that caused the msan build issue, when I remove it the build works until the first “new” binary is executed and runs into : ==64305==WARNING: MemorySanitizer: use-of-uninitialized-value #0 0x7fbe17639b01 (/builddir/jdk/lib/server/libjvm.so+0x246bb01) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5) #1 0x7fbe18ba4751 (/builddir/jdk/lib/server/libjvm.so+0x39d6751) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5) #2 0x7fbe17489e64 (/builddir/jdk/lib/server/libjvm.so+0x22bbe64) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5) #3 0x7fbe18bc90ab (/builddir/jdk/lib/server/libjvm.so+0x39fb0ab) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5) #4 0x7fbe176e695b (/builddir/jdk/lib/server/libjvm.so+0x251895b) (BuildId: b0fcd4709b54740840412c9e6ff0c9ce284848e5) #5 0x7fbe1ae182d8 (/builddir/jdk/bin/../lib/libjli.so+0x112d8) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5) #6 0x7fbe1ae23358 (/builddir/jdk/bin/../lib/libjli.so+0x1c358) (BuildId: 6ae5315fdc089fba90719ba08ab0373371f52bf5) #7 0x7fbe1add06e9 (/lib64/libpthread.so.0+0xa6e9) (BuildId: 938e42b7e407d175ee3ef9a89c038168101d330c) #8 0x7fbe1ab4558e (/lib64/libc.so.6+0x11858e) (BuildId: 74f77bf013a66413c77197c121955e029c32d259) Unfortunately the functions and line numbers from the backtrace are not (yet) nicely displayed , guess this needs some improvement . When calling addr2line on libjvm.so with the last address from the stack , I get jfrThreadLocal.cpp:81 . Best regards, Matthias
Re: RFR: 8350209: Preserve adapters in AOT cache [v8]
On Sun, 27 Apr 2025 21:52:43 GMT, Vladimir Kozlov wrote: >> [JEP 483](https://bugs.openjdk.org/browse/JDK-8315737) preserves class >> information in AOT cache which helps Java startup performance. >> >> We should also preserve adapters (i2c, c2i) to further improve performance >> of class linking where adapters are generated. >> >> Short running Java application can see several percents improvement. I got >> 6% improvement when ran `HelloWorld.java` on Linux-x64 Ice Lake CPU (2.5Ghz): >> >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache -cp hello.jar HelloWorld > >> /dev/null) 2>&1 | grep elapsed >> 0.0299401 +- 0.504 seconds time elapsed ( +- 0.17% ) >> >> (perf stat -r 100 java -XX:AOTCache=app.aotcache >> -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -cp hello.jar >> HelloWorld > /dev/null) 2>&1 | grep elapsed >> 0.0318654 +- 0.535 seconds time elapsed ( +- 0.17% ) >> >> >> New diagnostic flags are introduced (use `-XX:+UnlockDiagnosticVMOptions` to >> unlock them): >> >> >> -XX:+AOTAdapterCaching - Enable or disable saving and restoring i2c2i >> adapters >> -XX:AOTCodeMaxSize=10*M - buffer size in bytes for AOT code caching >> -XX:+AbortVMOnAOTCodeFailure - Abort VM on the first occurrence of AOT code >> caching failure >> >> By default `AOTAdapterCaching` is `false` and enabled ergonomically when >> `-XX:AOTCache` is specified. >> This flag is ignored when `AOTCache` is not specified. >> >> To use AOT adapters follow process described in JEP 483: >> >> >> java -XX:AOTMode=record -XX:AOTConfiguration=app.aotconf -cp app.jar App >> java -XX:AOTMode=create -XX:AOTConfiguration=app.aotconf >> -XX:AOTCache=app.aot -cp app.jar >> java -XX:AOTCache=app.aot -cp app.jar App >> >> >> There are several new UL flag combinations to trace the AOT code caching >> process: >> >> >> -Xlog:aot+codecache+init -Xlog:aot+codecache+exit -Xlog:aot+codecache+stubs >> >> >> @ashu-mehra is main author of changes. He implemented adapters caching. >> I did main framework (`AOTCodeCache` class) for saving and loading AOT code. >> >> Tested tier1-6,10, which includes tests with `AOTClassLinking` enabled. Also >> Xcomp,stress and JCK. > > Vladimir Kozlov has updated the pull request incrementally with one > additional commit since the last revision: > > Downgraded UL as asked. Added synchronization to C strings caching. src/hotspot/share/code/aotCodeCache.hpp line 340: > 338: static const char* add_C_string(const char* str) NOT_CDS_RETURN_(str); > 339: > 340: static const char* add_C_string2(const char* str) NOT_CDS_RETURN_(str); This method is not used. - PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2066731291
