From kvn at openjdk.org Thu May 1 00:07:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 00:07:48 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:54:38 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> address Ioi's comments > > src/hotspot/share/code/aotCodeCache.cpp line 69: > >> 67: vm_abort(false); >> 68: } >> 69: log_info(aot, codecache, exit)("Unable to create AOT Code Cache."); > > Same here (`log_warning`?). I will remove `exit_vm_on_` from these 2 methods to avoid confusion. And will add comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069684684 From kvn at openjdk.org Thu May 1 00:26:47 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 00:26:47 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 22:59:03 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> address Ioi's comments > > src/hotspot/share/runtime/sharedRuntime.cpp line 2852: > >> 2850: entry_offset[2] = handler->get_c2i_unverified_entry() - i2c_entry; >> 2851: entry_offset[3] = handler->get_c2i_no_clinit_check_entry() - i2c_entry; >> 2852: AOTCodeCache::store_code_blob(*adapter_blob, AOTCodeEntry::Adapter, id, name, AdapterHandlerEntry::ENTRIES_COUNT, entry_offset); > > What the intended behavior here when `AOTCodeCache::store_code_blob` fails? If something happened when we tried to store blob (adapter in this case) into buffer (for example, if reserved for AOT code buffer is too small) the next will be called: set_failed(); exit_vm_on_store_failure(); So we either abort VM based on the flag or issue warning (as you suggested) and continue execution. `set_failed()` will prevent following attempts to cache blobs and prevent final dump any cached code into AOT cache: bool for_dump() const { return _for_dump && !_failed; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069703345 From kvn at openjdk.org Thu May 1 00:04:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 00:04:48 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: Message-ID: <1NHR78vH371vWOdTep3F2l0sql9M-qJ_TIMUyAAImS4=.2ece512b-51f9-47ca-aae7-d600806f53cc@github.com> On Wed, 30 Apr 2025 22:54:07 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> address Ioi's comments > > src/hotspot/share/code/aotCodeCache.cpp line 60: > >> 58: vm_exit_during_initialization("Unable to use AOT Code Cache.", nullptr); >> 59: } >> 60: log_info(aot, codecache, init)("Unable to use AOT Code Cache."); > > Should it be a warning instead? changed > src/hotspot/share/code/codeBlob.hpp line 208: > >> 206: CodeBlob* as_codeblob() const { return (CodeBlob*) this; } >> 207: AdapterBlob* as_adapter_blob() const { assert(is_adapter_blob(), "must be adapter blob"); return (AdapterBlob*) this; } >> 208: ExceptionBlob* as_exception_blob() const { assert(is_exception_stub(), "must be exception stub"); return (ExceptionBlob*) this; } > > `ExceptionBlob` is C2-specific, but `as_exception_blob()` is unused. removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069680668 PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069680012 From kvn at openjdk.org Thu May 1 00:32:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 00:32:51 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: Message-ID: 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.0000504 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.0000535 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 > How does _cache notice a store failure during dumping phase? `set_failed()` sets flags AOTCodeCache::_failed. Which is checked when we trying to get _cache pointer: ------------- PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2843795345 From kvn at openjdk.org Thu May 1 00:55:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 00:55:56 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v7] In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 01:53:55 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix message > > Finished the first pass over the code. > > > Overall, looks good. Some feedback follows. Thank you, @iwanowww, for review. I think I addressed your comments and answered your question. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2843828077 From kvn at openjdk.org Thu May 1 01:08:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 01:08:40 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v13] In-Reply-To: References: Message-ID: > [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.0000504 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.0000535 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 Vladimir's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24740/files - new: https://git.openjdk.org/jdk/pull/24740/files/78f2828d..70bd0294 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=11-12 Stats: 38 lines in 6 files changed: 0 ins; 19 del; 19 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 From vlivanov at openjdk.org Thu May 1 01:56:50 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 01:56:50 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: Message-ID: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> On Thu, 1 May 2025 00:24:07 GMT, Vladimir Kozlov wrote: >> src/hotspot/share/runtime/sharedRuntime.cpp line 2852: >> >>> 2850: entry_offset[2] = handler->get_c2i_unverified_entry() - i2c_entry; >>> 2851: entry_offset[3] = handler->get_c2i_no_clinit_check_entry() - i2c_entry; >>> 2852: AOTCodeCache::store_code_blob(*adapter_blob, AOTCodeEntry::Adapter, id, name, AdapterHandlerEntry::ENTRIES_COUNT, entry_offset); >> >> What the intended behavior here when `AOTCodeCache::store_code_blob` fails? > > If something happened when we tried to store blob (adapter in this case) into buffer (for example, if reserved for AOT code buffer is too small) the next will be called: > > set_failed(); > exit_vm_on_store_failure(); > > So we either abort VM based on the flag or issue warning (as you suggested) and continue execution. > > `set_failed()` will prevent following attempts to cache blobs and prevent final dump any cached code into AOT cache: > > bool for_dump() const { return _for_dump && !_failed; } Maybe add an assert here? bool success = AOTCodeCache::store_code_blob(...); assert(success || !AOTCodeCache::is_dumping_adapters(), ""); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069760236 From vlivanov at openjdk.org Thu May 1 01:56:48 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 01:56:48 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v13] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 01:08:40 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.0000504 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.0000535 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 Vladimir's comments Looks good! Minor suggestions follow. src/hotspot/share/code/aotCodeCache.cpp line 56: > 54: #include > 55: > 56: static void load_failure() { Maybe `on_(load|store)_failure()` or `report_(load|store)_failure()`? ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2809000158 PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069761472 From kvn at openjdk.org Thu May 1 02:24:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 02:24:48 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v13] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 01:53:20 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address Vladimir's comments > > src/hotspot/share/code/aotCodeCache.cpp line 56: > >> 54: #include >> 55: >> 56: static void load_failure() { > > Maybe `on_(load|store)_failure()` or `report_(load|store)_failure()`? I will use `report_` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2069775755 From kvn at openjdk.org Thu May 1 02:47:39 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 02:47:39 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v14] In-Reply-To: References: Message-ID: > [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.0000504 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.0000535 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: renaming and new assert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24740/files - new: https://git.openjdk.org/jdk/pull/24740/files/70bd0294..9c3e3688 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=12-13 Stats: 10 lines in 2 files changed: 1 ins; 0 del; 9 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 From vlivanov at openjdk.org Thu May 1 02:54:50 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 02:54:50 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v14] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 02:47:39 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.0000504 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.0000535 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: > > renaming and new assert Marked as reviewed by vlivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2809064479 From kvn at openjdk.org Thu May 1 02:58:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 02:58:53 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v14] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 02:51:53 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> renaming and new assert > > Marked as reviewed by vlivanov (Reviewer). Thank you, @iwanowww. I need 2 re-reviews so I asked @ashu-mehra to review again. Meanwhile I am re-running testing with latest mainline code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2843969503 From jwaters at openjdk.org Thu May 1 13:27:54 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 1 May 2025 13:27:54 GMT Subject: RFR: 8345265: Minor improvements for LTO across all compilers [v2] In-Reply-To: References: Message-ID: <2c2RGsRfSG3FXZWT21NSGQrXCfJxgCN04jMwxQjlDjg=.632416df-1f45-48a1-ba4e-d3495f013ce0@github.com> On Tue, 17 Dec 2024 14:54:03 GMT, Julian Waters wrote: >> This is a general cleanup and improvement of LTO, as well as a quick fix to remove a workaround in the Makefiles that disabled LTO for g1ParScanThreadState.cpp due to the old poisoning mechanism causing trouble. The -Wno-attribute-warning change here can be removed once Kim's new poisoning solution is integrated. >> >> - -fno-omit-frame-pointer is added to gcc to stop the linker from emitting code without the frame pointer >> - -flto is set to $(JOBS) instead of auto to better match what the user requested >> - -Gy is passed to the Microsoft compiler. This does not fully fix LTO under Microsoft, but prevents warnings about -LTCG:INCREMENTAL at least > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision: > > - Merge branch 'openjdk:master' into patch-16 > - -fno-omit-frame-pointer in JvmFeatures.gmk > - Revert compilerWarnings_gcc.hpp > - General LTO fixes JvmFeatures.gmk > - Revert DISABLE_POISONING_STOPGAP compilerWarnings_gcc.hpp > - Merge branch 'openjdk:master' into patch-16 > - Revert os.cpp > - Fix memory leak in jvmciEnv.cpp > - Stopgap fix in os.cpp > - Declaration fix in compilerWarnings_gcc.hpp > - ... and 2 more: https://git.openjdk.org/jdk/compare/0b5a830e...9d05cb8e Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/22464#issuecomment-2844843415 From duke at openjdk.org Thu May 1 13:18:19 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Thu, 1 May 2025 13:18:19 GMT Subject: RFR: 8356032: createAutoconfBundle.sh downloads to local directory Message-ID: Fixed a small issue in createAutoconfBundle.sh where we CD to `build/autoconf` folder before it's created. As result, we end up with `m4` and `autoconf` downloadable and unpacked folders in CWD. By a chance, I did few other improvements: * colored logs for easier log reading * resolved `/../../` in the path to ease log reading. * `http://yum.oracle.com` was permanently relocated to `https`. ------------- Commit messages: - fixed createAutoconfBundle.sh CD to build/ before the folder is created. Added logs. URL change as https is the only option Changes: https://git.openjdk.org/jdk/pull/24985/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24985&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356032 Stats: 34 lines in 1 file changed: 27 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24985.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24985/head:pull/24985 PR: https://git.openjdk.org/jdk/pull/24985 From liach at openjdk.org Thu May 1 15:06:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 1 May 2025 15:06:05 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 00:06:26 GMT, Vicente Romero wrote: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 make/langtools/src/classes/build/tools/symbolgenerator/CreateSymbols.java line 1: > 1: /* Need to add handling of `RequiresIdentity` in `createAnnotation` src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253: > 4251: > 4252: # lint: identity > 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\ How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049917728 PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2049921677 From vromero at openjdk.org Thu May 1 15:06:04 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 1 May 2025 15:06:04 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API Message-ID: This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. For more details please refer to the complete description in the corresponding JIRA entry [1] TIA [1] https://bugs.openjdk.org/browse/JDK-8354556 ------------- Commit messages: - final adjustments - additional refactorings - removing unneeded changes - more refactorings - more refactorings and tests - refactoring - refactoring - covering more cases plus refactoring in order to simplify the code - Merge branch 'JDK-8354556' of https://github.com/vicente-romero-oracle/jdk into JDK-8354556 - additional coverage for other uses of types - ... and 11 more: https://git.openjdk.org/jdk/compare/4dd64b49...5e3acc92 Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354556 Stats: 495 lines in 25 files changed: 469 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From asmehra at openjdk.org Thu May 1 15:12:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 1 May 2025 15:12:52 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> References: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> Message-ID: On Thu, 1 May 2025 01:51:07 GMT, Vladimir Ivanov wrote: > assert(success || !AOTCodeCache::is_dumping_adapters(), ""); This condtion `!AOTCodeCache::is_dumping_adapters()` in the assert is not very intuitive. I think what we need to assert is future stores in the aot code cache are disabled. So having a method like `AOTCodeCache::is_store_disabled()` would better communicate the intent here. But I don't mind keeping this condition for this initial PR. I will just suggest to add a better assert message like: ```assert(success || !AOTCodeCache::is_dumping_adapters(), "storing of adapter must be disabled");``` And I think we should also be setting `_adapter_caching` to false in `report_load_failure` and `report_store_failure` to be consistent, otherwise we may end up in a situation where `AOTAdapterCaching` is false but `_adapter_caching` is true. In fact, I feel we should only be setting `_adapter_caching` and not `AOTAdapterCaching` in `report_load/store_failure` because `_adapter_caching` is the flag used to gate store/load operations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2070387521 From kvn at openjdk.org Thu May 1 15:46:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 15:46:51 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> Message-ID: On Thu, 1 May 2025 15:10:09 GMT, Ashutosh Mehra wrote: >> Maybe add an assert here? >> >> >> bool success = AOTCodeCache::store_code_blob(...); >> assert(success || !AOTCodeCache::is_dumping_adapters(), ""); > >> assert(success || !AOTCodeCache::is_dumping_adapters(), ""); > > This condtion `!AOTCodeCache::is_dumping_adapters()` in the assert is not very intuitive. I think what we need to assert is future stores in the aot code cache are disabled. So having a method like `AOTCodeCache::is_store_disabled()` would better communicate the intent here. But I don't mind keeping this condition for this initial PR. I will just suggest to add a better assert message like: > > ```assert(success || !AOTCodeCache::is_dumping_adapters(), "storing of adapter must be disabled");``` > > And I think we should also be setting `_adapter_caching` to false in `report_load_failure` and `report_store_failure` to be consistent, otherwise we may end up in a situation where `AOTAdapterCaching` is false but `_adapter_caching` is true. In fact, I feel we should only be setting `_adapter_caching` and not `AOTAdapterCaching` in `report_load/store_failure` because `_adapter_caching` is the flag used to gate store/load operations. Thank you, @ashu-mehra. You have good points. I will work on them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2070428589 From vromero at openjdk.org Thu May 1 15:06:06 2025 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 1 May 2025 15:06:06 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API In-Reply-To: References: Message-ID: On Fri, 18 Apr 2025 02:32:06 GMT, Chen Liang wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler.properties line 4253: > >> 4251: >> 4252: # lint: identity >> 4253: compiler.warn.attempt.to.synchronize.on.instance.of.value.based.class2=\ > > How is this different from the message with no 2 suffix? Is there a reason why one localization entry is required for one type of lint? the requirement is for the identity lint warning to be an alias of the synchronization warning ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2053222093 From kvn at openjdk.org Thu May 1 15:53:36 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 15:53:36 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v15] In-Reply-To: References: Message-ID: > [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.0000504 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.0000535 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 16 commits: - Merge branch 'master' into JDK-8350209 - renaming and new assert - Address Vladimir's comments - address Ioi's comments - Remove unused method - 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 - ... and 6 more: https://git.openjdk.org/jdk/compare/e2ae50d8...286e0e67 ------------- Changes: https://git.openjdk.org/jdk/pull/24740/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=14 Stats: 3297 lines in 51 files changed: 2827 ins; 200 del; 270 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 From iveresov at openjdk.org Thu May 1 16:58:39 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 1 May 2025 16:58:39 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v9] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Port 8355915: [leyden] Crash in MDO clearing the unloaded array type ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/b937681e..ee6bd11d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=07-08 Stats: 17 lines in 4 files changed: 6 ins; 4 del; 7 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 From vlivanov at openjdk.org Thu May 1 17:12:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 17:12:49 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> Message-ID: On Thu, 1 May 2025 15:44:11 GMT, Vladimir Kozlov wrote: >>> assert(success || !AOTCodeCache::is_dumping_adapters(), ""); >> >> This condtion `!AOTCodeCache::is_dumping_adapters()` in the assert is not very intuitive. I think what we need to assert is future stores in the aot code cache are disabled. So having a method like `AOTCodeCache::is_store_disabled()` would better communicate the intent here. But I don't mind keeping this condition for this initial PR. I will just suggest to add a better assert message like: >> >> ```assert(success || !AOTCodeCache::is_dumping_adapters(), "storing of adapter must be disabled");``` >> >> And I think we should also be setting `_adapter_caching` to false in `report_load_failure` and `report_store_failure` to be consistent, otherwise we may end up in a situation where `AOTAdapterCaching` is false but `_adapter_caching` is true. In fact, I feel we should only be setting `_adapter_caching` and not `AOTAdapterCaching` in `report_load/store_failure` because `_adapter_caching` is the flag used to gate store/load operations. > > Thank you, @ashu-mehra. You have good points. I will work on them. FTR I suggested `!AOTCodeCache::is_dumping_adapters()` because that's the guarding check for `AOTCodeCache::store_code_blob()` call. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2070535559 From erikj at openjdk.org Thu May 1 16:54:47 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 1 May 2025 16:54:47 GMT Subject: RFR: 8356032: createAutoconfBundle.sh downloads to local directory In-Reply-To: References: Message-ID: <6dKkR1t-MVzHzBMbJPAMRVkWfAz7kbUubbfF6xrcq6o=.53217eb6-f588-4225-bed2-f5d6cc780af0@github.com> On Thu, 1 May 2025 13:12:46 GMT, Ivan Bereziuk wrote: > Fixed a small issue in createAutoconfBundle.sh where we CD to `build/autoconf` folder before it's created. > As result, we end up with `m4` and `autoconf` downloadable and unpacked folders in CWD. > > By a chance, I did few other improvements: > * added colored logs > * and resolved `../../` in the path to ease log reading > * changed URL `http://yum.oracle.com` as `https` is the only option today. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24985#pullrequestreview-2810199836 From kvn at openjdk.org Thu May 1 18:53:40 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 18:53:40 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v15] In-Reply-To: References: Message-ID: <2EBIRKcMsbi0pptQJnsclCch18L6caIEhHgC3VPlo8I=.e0372c4d-515a-451e-ac4b-dbf2c94e1e43@github.com> On Thu, 1 May 2025 15:53:36 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.0000504 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.0000535 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 16 commits: > > - Merge branch 'master' into JDK-8350209 > - renaming and new assert > - Address Vladimir's comments > - address Ioi's comments > - Remove unused method > - 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 > - ... and 6 more: https://git.openjdk.org/jdk/compare/e2ae50d8...286e0e67 I reverted back `log_warning()` to `log_info()` in `report_*_failure()` methods. I removed `AOTCodeCache::_adapter_caching` field and use `AOTAdapterCaching` flag check instead. Setting the flag to `false` in case of a failure make more sense now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2845485585 From kvn at openjdk.org Thu May 1 18:53:38 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 18:53:38 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v16] In-Reply-To: References: Message-ID: > [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.0000504 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.0000535 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: Revert log_warning change. Replace _adapter_caching check with flag check. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24740/files - new: https://git.openjdk.org/jdk/pull/24740/files/286e0e67..325efec0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24740&range=14-15 Stats: 20 lines in 3 files changed: 8 ins; 5 del; 7 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 From vlivanov at openjdk.org Thu May 1 19:27:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 1 May 2025 19:27:49 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v16] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 18:53:38 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.0000504 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.0000535 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: > > Revert log_warning change. Replace _adapter_caching check with flag check. Looks good. ------------- Marked as reviewed by vlivanov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2810533587 From iveresov at openjdk.org Thu May 1 19:34:34 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 1 May 2025 19:34:34 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v10] In-Reply-To: References: Message-ID: <4uRz9S2VvUHduPnG2Vnh3v-AbRtoB86mM1A9sJBLZ30=.840a3c9b-ada1-4ba4-b8d8-af4e94607556@github.com> > 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 incrementally with one additional commit since the last revision: Fix semantics change from the previous commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/ee6bd11d..014b0ec5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From mikael at openjdk.org Thu May 1 19:44:55 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 1 May 2025 19:44:55 GMT Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle [v2] In-Reply-To: References: Message-ID: > Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4. > > Testing: tier1-5 Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - Merge master - Update doc/building.md to reflect updated macOS/Xcode versions - 8355446: Change to Xcode 15.4 for building on macOS at Oracle ------------- Changes: https://git.openjdk.org/jdk/pull/24862/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24862&range=01 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24862.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24862/head:pull/24862 PR: https://git.openjdk.org/jdk/pull/24862 From asmehra at openjdk.org Thu May 1 19:53:50 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 1 May 2025 19:53:50 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v16] In-Reply-To: References: Message-ID: <47yR6by-cdpqHdDV9K_KcREg9d7Ii6tUvciBv_TWQKI=.42b886e4-befc-440a-bb16-c73df5db5d19@github.com> On Thu, 1 May 2025 18:53:38 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.0000504 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.0000535 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: > > Revert log_warning change. Replace _adapter_caching check with flag check. lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/24740#pullrequestreview-2810579866 From kvn at openjdk.org Thu May 1 18:39:50 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 18:39:50 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v12] In-Reply-To: References: <6QqEVIYBum6lJLSUHs_yZ-Zbk1vEDXqqQBYM6usjoJ8=.295c3db4-c458-42c9-a5ea-adc585a645d0@github.com> Message-ID: On Thu, 1 May 2025 17:10:17 GMT, Vladimir Ivanov wrote: >> Thank you, @ashu-mehra. You have good points. I will work on them. > > FTR I suggested `!AOTCodeCache::is_dumping_adapters()` because that's the guarding check for `AOTCodeCache::store_code_blob()` call. I will add assert message but keep check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24740#discussion_r2070638283 From kvn at openjdk.org Thu May 1 21:06:01 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 21:06:01 GMT Subject: Integrated: 8350209: Preserve adapters in AOT cache In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 19:11:47 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.0000504 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.0000535 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. This pull request has now been integrated. Changeset: aae2bb62 Author: Vladimir Kozlov URL: https://git.openjdk.org/jdk/commit/aae2bb62499855e3da33c06547d437e49c91a14b Stats: 3300 lines in 51 files changed: 2830 ins; 200 del; 270 mod 8350209: Preserve adapters in AOT cache Co-authored-by: Ashutosh Mehra Reviewed-by: vlivanov, asmehra, ihse, iklam ------------- PR: https://git.openjdk.org/jdk/pull/24740 From kvn at openjdk.org Thu May 1 21:05:59 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 1 May 2025 21:05:59 GMT Subject: RFR: 8350209: Preserve adapters in AOT cache [v16] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:24:46 GMT, Vladimir Ivanov wrote: >> Vladimir Kozlov has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert log_warning change. Replace _adapter_caching check with flag check. > > Looks good. Thank you again, @iwanowww and @ashu-mehra ------------- PR Comment: https://git.openjdk.org/jdk/pull/24740#issuecomment-2845771528 From jiangli at openjdk.org Thu May 1 22:49:56 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 1 May 2025 22:49:56 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk Message-ID: Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: .github/actions/get-bundles/action.yml. - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. - Add `static-jdk-path` output. - Unpack static bundles in bundles/static-jdk. .github/actions/upload-bundles/action.yml - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. .github/workflows/build-linux.yml - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. .github/workflows/main.yml - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. .github/workflows/test.yml - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. - Add `run-tests-static`. - Add step for notifying test failures on static JDK. @shipilev Could you please help review this change? Thanks! ------------- Commit messages: - Fix typo. - Export static-problemlist-path in 'path' step. - Remove inputs.static-suffix check when notify test failure. - Replace $(pwd) with `pwd` to form the path to static JDK problemlist. - Use different id fot test on static. Add step to notify failures on static JDK. - - Change run-tests-on-static id to run-tests id. - Don't set debug-suffix for static test job, since that causes incorrect bundle name used. - - Switch back to build 'release' binary for linux-x64-static job. - Switch to do 'debug' build for linux-x64-static job. - - Only setup static_jdk_dir if inputs.static-suffix is not empty. - ... and 14 more: https://git.openjdk.org/jdk/compare/62d165d0...5306dac3 Changes: https://git.openjdk.org/jdk/pull/24992/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355452 Stats: 108 lines in 5 files changed: 92 ins; 2 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From duke at openjdk.org Fri May 2 08:41:47 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 2 May 2025 08:41:47 GMT Subject: RFR: 8356032: createAutoconfBundle.sh downloads to local directory In-Reply-To: <6dKkR1t-MVzHzBMbJPAMRVkWfAz7kbUubbfF6xrcq6o=.53217eb6-f588-4225-bed2-f5d6cc780af0@github.com> References: <6dKkR1t-MVzHzBMbJPAMRVkWfAz7kbUubbfF6xrcq6o=.53217eb6-f588-4225-bed2-f5d6cc780af0@github.com> Message-ID: <_jcE3RCBDSKFxTMlN8io6KWGxbzIEKSNepZbbllUyyA=.55199692-45e9-4fa0-b768-64b18377220b@github.com> On Thu, 1 May 2025 16:51:45 GMT, Erik Joelsson wrote: >> Fixed a small issue in createAutoconfBundle.sh where we CD to `build/autoconf` folder before it's created. >> As result, we end up with `m4` and `autoconf` downloadable and unpacked folders in CWD. >> >> By a chance, I did few other improvements: >> * added colored logs >> * and resolved `../../` in the path to ease log reading >> * changed URL `http://yum.oracle.com` as `https` is the only option today. > > Marked as reviewed by erikj (Reviewer). @erikj79 , thank you for review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24985#issuecomment-2846672683 From duke at openjdk.org Fri May 2 08:41:48 2025 From: duke at openjdk.org (duke) Date: Fri, 2 May 2025 08:41:48 GMT Subject: RFR: 8356032: createAutoconfBundle.sh downloads to local directory In-Reply-To: References: Message-ID: On Thu, 1 May 2025 13:12:46 GMT, Ivan Bereziuk wrote: > Fixed a small issue in createAutoconfBundle.sh where we CD to `build/autoconf` folder before it's created. > As result, we end up with `m4` and `autoconf` downloadable and unpacked folders in CWD. > > By a chance, I did few other improvements: > * added colored logs > * and resolved `../../` in the path to ease log reading > * changed URL `http://yum.oracle.com` as `https` is the only option today. @Domest0s Your change (at version 42dafcd6cbf9842115b7ead4e85f5f7702f0c322) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24985#issuecomment-2846674750 From duke at openjdk.org Fri May 2 12:51:50 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Fri, 2 May 2025 12:51:50 GMT Subject: Integrated: 8356032: createAutoconfBundle.sh downloads to local directory In-Reply-To: References: Message-ID: On Thu, 1 May 2025 13:12:46 GMT, Ivan Bereziuk wrote: > Fixed a small issue in createAutoconfBundle.sh where we CD to `build/autoconf` folder before it's created. > As result, we end up with `m4` and `autoconf` downloadable and unpacked folders in CWD. > > By a chance, I did few other improvements: > * added colored logs > * and resolved `../../` in the path to ease log reading > * changed URL `http://yum.oracle.com` as `https` is the only option today. This pull request has now been integrated. Changeset: cf2f9ce8 Author: Ivan Bereziuk Committer: Erik Joelsson URL: https://git.openjdk.org/jdk/commit/cf2f9ce8207f12bd25fc866c179ff13b961bea44 Stats: 34 lines in 1 file changed: 27 ins; 1 del; 6 mod 8356032: createAutoconfBundle.sh downloads to local directory Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24985 From nbenalla at openjdk.org Fri May 2 14:57:52 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 2 May 2025 14:57:52 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 Message-ID: Get JDK 26 underway. ------------- Commit messages: - Update copyright years - Update --release 25 symbol information for JDK 24 build 20 - initial commit start-of-JDK-26 Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355746 Stats: 1193 lines in 54 files changed: 1100 ins; 16 del; 77 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Fri May 2 15:05:44 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Fri, 2 May 2025 15:05:44 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. This initial commit of the PR intentionally excludes the creation of the new symbol files so that the fundamental code aspects of the update are easier to see. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25008#issuecomment-2847422764 From liach at openjdk.org Fri May 2 15:56:47 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 15:56:47 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:48:01 GMT, Nizar Benalla wrote: > Get JDK 26 underway. Changes requested by liach (Reviewer). make/conf/version-numbers.conf line 36: > 34: DEFAULT_VERSION_EXTRA2=0 > 35: DEFAULT_VERSION_EXTRA3=0 > 36: DEFAULT_VERSION_DATE=2026-03-16 Is this accurate? src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: > 56: */ > 57: @SupportedAnnotationTypes("*") > 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: > 227: // Check the class' major_version. This field is after the magic and minor_version fields, which > 228: // use 4 and 2 bytes respectively. > 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: > 48: public class HelpOutputColumnWidthTest extends TestRunner { > 49: > 50: public static final int MAX_COLUMNS = 84; What is this for? ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2812349246 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071811476 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071815767 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071819374 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071817584 From darcy at openjdk.org Fri May 2 16:47:48 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 16:47:48 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 15:47:43 GMT, Chen Liang wrote: >> Get JDK 26 underway. > > make/conf/version-numbers.conf line 36: > >> 34: DEFAULT_VERSION_EXTRA2=0 >> 35: DEFAULT_VERSION_EXTRA3=0 >> 36: DEFAULT_VERSION_DATE=2026-03-16 > > Is this accurate? One day off; should be 2026-03-17. I should have double-checked that in the initial authoring of the change. > src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: > >> 56: */ >> 57: @SupportedAnnotationTypes("*") >> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) > > This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation. > test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: > >> 227: // Check the class' major_version. This field is after the magic and minor_version fields, which >> 228: // use 4 and 2 bytes respectively. >> 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { > > Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. > test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: > >> 48: public class HelpOutputColumnWidthTest extends TestRunner { >> 49: >> 50: public static final int MAX_COLUMNS = 84; > > What is this for? It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071878858 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071883440 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071881672 PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071880549 From alanb at openjdk.org Fri May 2 16:47:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 2 May 2025 16:47:49 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:43:02 GMT, Joe Darcy wrote: >> test/hotspot/jtreg/testlibrary/asm/org/objectweb/asm/ClassReader.java line 229: >> >>> 227: // Check the class' major_version. This field is after the magic and minor_version fields, which >>> 228: // use 4 and 2 bytes respectively. >>> 229: if (checkClassVersion && readShort(classFileOffset + 6) > Opcodes.V26) { >> >> Please do not change ASM - if a test uses ASM to generate or parse later class files, they must migrate to the ClassFile API. Open a JBS issue and identify the hotspot tests failing without this change. > > There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071884496 From erikj at openjdk.org Fri May 2 16:52:45 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 May 2025 16:52:45 GMT Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:44:55 GMT, Mikael Vidstedt wrote: >> Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4. >> >> Testing: tier1-5 > > Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge master > - Update doc/building.md to reflect updated macOS/Xcode versions > - 8355446: Change to Xcode 15.4 for building on macOS at Oracle Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24862#pullrequestreview-2812479819 From liach at openjdk.org Fri May 2 16:58:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 16:58:50 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:45:42 GMT, Alan Bateman wrote: >> There are various HotSpot tests that use ASM and they all fail under JDK 26 without this change. > > Hopefully new tests will use the ClassFile API and that over time that some of the existing tests that use ASM can be migrated. I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071895599 From mikael at openjdk.org Fri May 2 16:59:00 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 2 May 2025 16:59:00 GMT Subject: RFR: 8355446: Change to Xcode 15.4 for building on macOS at Oracle [v2] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 19:44:55 GMT, Mikael Vidstedt wrote: >> Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4. >> >> Testing: tier1-5 > > Mikael Vidstedt has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: > > - Merge master > - Update doc/building.md to reflect updated macOS/Xcode versions > - 8355446: Change to Xcode 15.4 for building on macOS at Oracle Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24862#issuecomment-2847681334 From mikael at openjdk.org Fri May 2 16:59:00 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 2 May 2025 16:59:00 GMT Subject: Integrated: 8355446: Change to Xcode 15.4 for building on macOS at Oracle In-Reply-To: References: Message-ID: On Thu, 24 Apr 2025 20:55:33 GMT, Mikael Vidstedt wrote: > Oracle is updating the version of Xcode for building the JDK on macOS to Xcode 15.4. > > Testing: tier1-5 This pull request has now been integrated. Changeset: 01fd49ff Author: Mikael Vidstedt URL: https://git.openjdk.org/jdk/commit/01fd49ffb3f02840a360f5d4e19c6b0e6d22cd70 Stats: 8 lines in 3 files changed: 0 ins; 0 del; 8 mod 8355446: Change to Xcode 15.4 for building on macOS at Oracle Reviewed-by: erikj, ihse ------------- PR: https://git.openjdk.org/jdk/pull/24862 From liach at openjdk.org Fri May 2 16:58:49 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 16:58:49 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> On Fri, 2 May 2025 16:44:40 GMT, Joe Darcy wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java line 58: >> >>> 56: */ >>> 57: @SupportedAnnotationTypes("*") >>> 58: @SupportedSourceVersion(SourceVersion.RELEASE_26) >> >> This processor should emulate `com.sun.tools.jdeprscan.TraverseProc` and override `getSupportedSourceVersion`. > > The implementation of getSupportedSourceVersion inherited from AbstractProcessor uses the value of this annotation. May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071896732 From darcy at openjdk.org Fri May 2 17:21:50 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 17:21:50 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:54:59 GMT, Chen Liang wrote: > I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071921145 From darcy at openjdk.org Fri May 2 17:46:58 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 2 May 2025 17:46:58 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 In-Reply-To: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> References: <9h_A8ZO25cAxj_Sex6ez9Lan6hjyoTc0_7PNqaCwfnI=.c8a68611-607c-4d6c-b0c9-23e8909a7376@github.com> Message-ID: On Fri, 2 May 2025 16:55:49 GMT, Chen Liang wrote: > May I prepare a quick patch to bring this in line with `TraverseProc` so we can skip this site for future start of release updates? I know it is possible to write getSupportedSourceVersion to return the latest version, but I don't think it is appropriate for this annotation processor to use that idiom since it might actually need to be meaningfully updated with code changes to support the new source level. Explicitly needing to change this annotation is a backstop reminder to do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2071949205 From liach at openjdk.org Fri May 2 19:19:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 19:19:55 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 Message-ID: Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. Testing: riscv64 cross build ------------- Commit messages: - 8355962: RISCV64 cross build fails after 8354996 Changes: https://git.openjdk.org/jdk/pull/25013/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25013&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355962 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25013.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25013/head:pull/25013 PR: https://git.openjdk.org/jdk/pull/25013 From vromero at openjdk.org Fri May 2 19:32:32 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:32:32 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v2] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: updating test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/5e3acc92..1134ffee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=00-01 Stats: 3 lines in 2 files changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Fri May 2 19:41:34 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:41:34 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v3] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Merge branch 'master' into JDK-8354556 - updating test - final adjustments - additional refactorings - removing unneeded changes - more refactorings - more refactorings and tests - refactoring - refactoring - covering more cases plus refactoring in order to simplify the code - ... and 13 more: https://git.openjdk.org/jdk/compare/60ba81d7...151908a2 ------------- Changes: https://git.openjdk.org/jdk/pull/24746/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02 Stats: 494 lines in 25 files changed: 468 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From vromero at openjdk.org Fri May 2 19:44:31 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 2 May 2025 19:44:31 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: > This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. > > For more details please refer to the complete description in the corresponding JIRA entry [1] > > TIA > > [1] https://bugs.openjdk.org/browse/JDK-8354556 Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: changes to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24746/files - new: https://git.openjdk.org/jdk/pull/24746/files/151908a2..60f1f53b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24746&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24746.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24746/head:pull/24746 PR: https://git.openjdk.org/jdk/pull/24746 From erikj at openjdk.org Fri May 2 19:54:44 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 2 May 2025 19:54:44 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2812795358 From liach at openjdk.org Fri May 2 21:34:46 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 21:34:46 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: <4Yq5q-QjlgK9ln9ICrwaQmH-_kwsbgz39_vi2eqP0pI=.85e4f24d-832f-4c90-af1f-28d90c805fa1@github.com> On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build If someone can verify this patch works - @caoman since you have tried to raise attention on this issue, can you test this patch for x86 to arm cross builds? Delegating integration as this seems in need. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848154785 From manc at openjdk.org Fri May 2 22:36:49 2025 From: manc at openjdk.org (Man Cao) Date: Fri, 2 May 2025 22:36:49 GMT Subject: RFR: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build Marked as reviewed by manc (Committer). Yes, I tested that this change fixes the failure for cross-compiling aarch64. ------------- PR Review: https://git.openjdk.org/jdk/pull/25013#pullrequestreview-2813005097 PR Comment: https://git.openjdk.org/jdk/pull/25013#issuecomment-2848222583 From liach at openjdk.org Fri May 2 22:36:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 2 May 2025 22:36:50 GMT Subject: Integrated: 8355962: RISCV64 cross build fails after 8354996 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:14:27 GMT, Chen Liang wrote: > Roll back the HelloClasslist downcall generation that caused cross build failures for riscv64 and aarch64 from x86-64. > > Testing: riscv64 cross build This pull request has now been integrated. Changeset: 4d2d1298 Author: Chen Liang Committer: Man Cao URL: https://git.openjdk.org/jdk/commit/4d2d12987f8c1be64719a7d01276a789af245ee2 Stats: 7 lines in 2 files changed: 0 ins; 6 del; 1 mod 8355962: RISCV64 cross build fails after 8354996 Reviewed-by: erikj, manc ------------- PR: https://git.openjdk.org/jdk/pull/25013 From iveresov at openjdk.org Sat May 3 01:13:41 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 3 May 2025 01:13:41 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v11] In-Reply-To: References: Message-ID: > 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 incrementally with two additional commits since the last revision: - Fix additional issues - Make sure command line flags that affect MDO layout are consistent ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/014b0ec5..9676039c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=09-10 Stats: 54 lines in 3 files changed: 52 ins; 0 del; 2 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 From iveresov at openjdk.org Sat May 3 05:25:35 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Sat, 3 May 2025 05:25:35 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v12] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Fix compile ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/9676039c..2441ad71 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=10-11 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 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 From yzheng at openjdk.org Mon May 5 09:42:47 2025 From: yzheng at openjdk.org (Yudi Zheng) Date: Mon, 5 May 2025 09:42:47 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 19:44:31 GMT, Vicente Romero wrote: >> This PR is defining a new internal annotation, `@jdk.internal.RequiresIdentity`, with target types PARAMETER and TYPE_PARAMETER. The @RequiresIdentity annotation expresses the expectation that an argument to a given method or constructor parameter will be an object with a unique identity, not an instance of a value-based class; or that the type argument to a given type parameter will not be a value-based class type. >> >> For more details please refer to the complete description in the corresponding JIRA entry [1] >> >> TIA >> >> [1] https://bugs.openjdk.org/browse/JDK-8354556 > > Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: > > changes to test src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669: > 667: > 668: public boolean isValueBased() { > 669: return (tsym.flags_field & VALUE_BASED) != 0; We have encountered a NPE in javac: java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669) at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739) at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918) at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915) ... It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073144717 From ihse at openjdk.org Mon May 5 14:35:47 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 14:35:47 GMT Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH benchmarks In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o wrote: > Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler. I apparently missed to approve this. I think this fix looks sane, regardless of any upstream changes. ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24571#pullrequestreview-2815042322 From vromero at openjdk.org Mon May 5 14:46:48 2025 From: vromero at openjdk.org (Vicente Romero) Date: Mon, 5 May 2025 14:46:48 GMT Subject: RFR: 8354556: Expand value-based class warnings to java.lang.ref API [v4] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 09:40:16 GMT, Yudi Zheng wrote: >> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision: >> >> changes to test > > src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java line 669: > >> 667: >> 668: public boolean isValueBased() { >> 669: return (tsym.flags_field & VALUE_BASED) != 0; > > We have encountered a NPE in javac: > > java.lang.NullPointerException: Cannot read field "flags_field" because "this.tsym" is null > at jdk.compiler/com.sun.tools.javac.code.Type.isValueBased(Type.java:669) > at jdk.compiler/com.sun.tools.javac.comp.Check.checkRequiresIdentity(Check.java:5739) > at jdk.compiler/com.sun.tools.javac.comp.Attr.visitNewClass(Attr.java:2918) > at jdk.compiler/com.sun.tools.javac.tree.JCTree$JCNewClass.accept(JCTree.java:1915) > ... > > It looks like `tsym` can be null https://github.com/openjdk/jdk/blob/60f1f53b18d065f110936e71b7430d7e365881d4/src/jdk.compiler/share/classes/com/sun/tools/javac/code/Type.java#L517-L519 thanks for the report I will update the PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24746#discussion_r2073595845 From ihse at openjdk.org Mon May 5 14:54:48 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 14:54:48 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Thu, 1 May 2025 22:46:00 GMT, Jiangli Zhou wrote: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! .github/workflows/main.yml line 234: > 232: with: > 233: platform: linux-x64 > 234: make-target: 'product-bundles test-bundles static-jdk-bundles' This will make us build the tests and the normal JDK twice, once here and once for the normal build-linux-x64 target. That seems like a useless waste of time and computing resources. There must be a better way of doing this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2073609867 From ihse at openjdk.org Mon May 5 15:01:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 15:01:55 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Thu, 1 May 2025 22:46:00 GMT, Jiangli Zhou wrote: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! .github/workflows/main.yml line 367: > 365: name: linux-x64-static > 366: needs: > 367: - build-linux-x64-static Just thinking out loud here, what if you also added ` build-linux-x64` to the `needs` list. I guess that would make sure the test bundle is built before trying to execute this. Then the trick will just be to get both the test bundle and the static-jdk bundle downloaded... .github/workflows/test.yml line 95: > 93: - test-name: 'hs/tier1 common' > 94: test-suite: 'test/hotspot/jtreg/:tier1_common' > 95: debug-suffix: ${{ inputs.debug-suffix }} I don't understand why these changes were needed? What are you doing with the debug suffix? .github/workflows/test.yml line 182: > 180: BOOT_JDK=${{ steps.bootjdk.outputs.path }} > 181: JDK_UNDER_TEST=${{ steps.bundles.outputs.static-jdk-path }} > 182: JDK_FOR_COMPILE=${{ steps.bundles.outputs.jdk-path }} Do we really need to duplicate all this code? From what I can see, this is just to be able to send in the JDK_FOR_COMPILE argument, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2073616222 PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2073618514 PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2073621919 From ihse at openjdk.org Mon May 5 15:05:45 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 15:05:45 GMT Subject: RFR: 8355570: [s390x] Update -march to z13 generation In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 06:24:31 GMT, Amit Kumar wrote: > updated march level from z10 to z13. > > Testing: tier1 (fastdebug-vm) GHA is using gcc 10.5.0 and it does not work. Maybe you can try building locally with 10.5.0 and see if you can reproduce the problem? Otherwise I have no suggestions to offer. But if you want to integrate this change, it cannot break GHA. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2851299291 From ihse at openjdk.org Mon May 5 15:08:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 5 May 2025 15:08:52 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: <7unkKqs4wV5Iy9XF-iKuz0PU9VNXMyWS740Gn93H8B0=.d0c238fc-8ca3-42ad-a7a8-b43af17f1cb2@github.com> On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Build changes look good. @ alexeysemenyukoracle Can you review the jpackage test change? ------------- Marked as reviewed by ihse (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2815147219 From jiangli at openjdk.org Mon May 5 21:02:47 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 5 May 2025 21:02:47 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:52:38 GMT, Magnus Ihse Bursie wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > .github/workflows/main.yml line 234: > >> 232: with: >> 233: platform: linux-x64 >> 234: make-target: 'product-bundles test-bundles static-jdk-bundles' > > This will make us build the tests and the normal JDK twice, once here and once for the normal build-linux-x64 target. That seems like a useless waste of time and computing resources. There must be a better way of doing this. I haven't tried, but I think it's possible to not requiring building `product-bundles`. The `product-bundles` (regular JDK) is used for compiling the test java sources. I think it's possible to use the boot JDK. I'll try that. > Just thinking out loud here, what if you also added ` build-linux-x64` to the `needs` list. I guess that would make sure the test bundle is built before trying to execute this. Then the trick will just be to get both the test bundle and the static-jdk bundle downloaded... That's an interesting idea. I'll give it a try. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2074194488 PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2074195554 From jiangli at openjdk.org Mon May 5 21:41:45 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 5 May 2025 21:41:45 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:57:08 GMT, Magnus Ihse Bursie wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > .github/workflows/test.yml line 95: > >> 93: - test-name: 'hs/tier1 common' >> 94: test-suite: 'test/hotspot/jtreg/:tier1_common' >> 95: debug-suffix: ${{ inputs.debug-suffix }} > > I don't understand why these changes were needed? What are you doing with the debug suffix? The hard-coded `debug-suffix: -debug` maps to run the hs/tier1 tests on `debug` build only. However, we can't build `debug` binary for static JDK yet due to the resource/space issue in GHA. I documented some related details in https://bugs.openjdk.org/browse/JDK-8355452?focusedId=14775969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14775969. Changing hard-coded `-debug` to `${{ inputs.debug-suffix }}` allows us to set '' for `debug-suffix`, which maps to run hs/tier1 tests on `static-jdk` `release` build for now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2074238275 From jiangli at openjdk.org Mon May 5 21:55:46 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 5 May 2025 21:55:46 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:59:04 GMT, Magnus Ihse Bursie wrote: > Do we really need to duplicate all this code? From what I can see, this is just to be able to send in the JDK_FOR_COMPILE argument, right? Yaml syntax is new to me. I went with that as it worked. :-) The static case sets the `JDK_FOR_COMPILE`|`JDK_UNDER_TEST` and `EXTRA_PROBLEM_LISTS` in `JTREG`. Any suggestion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2074252531 From shurailine at openjdk.org Tue May 6 03:29:00 2025 From: shurailine at openjdk.org (Alexandre Iline) Date: Tue, 6 May 2025 03:29:00 GMT Subject: RFR: 8356226: JCov Grabber server didn't respond Message-ID: Fix is to allow bigger XML files. ------------- Commit messages: - Also fix reports - JDK-8356226: JCov Grabber server didn't respond Changes: https://git.openjdk.org/jdk/pull/25056/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25056&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356226 Stats: 12 lines in 1 file changed: 6 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25056.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25056/head:pull/25056 PR: https://git.openjdk.org/jdk/pull/25056 From duke at openjdk.org Tue May 6 04:25:26 2025 From: duke at openjdk.org (duke) Date: Tue, 6 May 2025 04:25:26 GMT Subject: Withdrawn: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava In-Reply-To: References: Message-ID: On Wed, 24 Jul 2024 19:11:42 GMT, Brian Burkhalter wrote: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20317 From iveresov at openjdk.org Tue May 6 06:31:43 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 6 May 2025 06:31:43 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13] In-Reply-To: References: Message-ID: > 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 43 commits: - Merge branch 'master' into pp2 - Fix compile - Fix additional issues - Make sure command line flags that affect MDO layout are consistent - Fix semantics change from the previous commit - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type - Fix flag behavior - Fix log tags - Remove the proxy class counter - Address review comments part 2 - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=12 Stats: 3231 lines in 60 files changed: 3011 ins; 103 del; 117 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 From ihse at openjdk.org Tue May 6 14:38:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 14:38:00 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v2] In-Reply-To: References: Message-ID: > Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into with-jcov-modules - Also fix RepGen - Update with correct syntax + debug support - 8282493: Add --with-jcov-modules convenience option ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24481/files - new: https://git.openjdk.org/jdk/pull/24481/files/01b97343..bdd55156 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=00-01 Stats: 302887 lines in 2843 files changed: 94350 ins; 197756 del; 10781 mod Patch: https://git.openjdk.org/jdk/pull/24481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24481/head:pull/24481 PR: https://git.openjdk.org/jdk/pull/24481 From ihse at openjdk.org Tue May 6 15:06:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:06:36 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: > Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Update copyright year - Update testing documentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24481/files - new: https://git.openjdk.org/jdk/pull/24481/files/bdd55156..32e4b4a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=01-02 Stats: 16 lines in 3 files changed: 15 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24481/head:pull/24481 PR: https://git.openjdk.org/jdk/pull/24481 From ihse at openjdk.org Tue May 6 15:06:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:06:36 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: <73__FrDoixrwv27nKTz4zTX7PYmY6x17p235bVZ0Mj4=.8d940f7e-b285-4566-a5d3-5dabf3432d12@github.com> On Sun, 20 Apr 2025 03:52:38 GMT, SendaoYan wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Update testing documentation > > Should we update the copyright year from 2024 to 2025 for make/autoconf/spec.gmk.template file @sendaoYan > Should we update the copyright year from 2024 to 2025 for make/autoconf/spec.gmk.template file Done, thank you for noticing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2854897790 From ihse at openjdk.org Tue May 6 15:06:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:06:36 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option In-Reply-To: <6VO4wnIDI5lPu7wdEEnVRAE5QDi-3FsUQKUzYS0fneI=.6f97586f-2c15-4e2e-8adf-863ca6c38aea@github.com> References: <6VO4wnIDI5lPu7wdEEnVRAE5QDi-3FsUQKUzYS0fneI=.6f97586f-2c15-4e2e-8adf-863ca6c38aea@github.com> Message-ID: On Mon, 21 Apr 2025 06:58:52 GMT, Sergey Bylokhov wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Description of the new option can be added to [testing.md](https://github.com/openjdk/jdk/blob/128f2d1cadae3cf91e4c590e6dabe2086737b7dd/doc/testing.md?plain=1#L339). @mrserb I updated the testing documentation. I also included the other JCov flags that have been added but not documented. I hope you think it looks okay. With regard to the versions, I don't think I'd like to put that in the source code or test readme file. Such information tends to be quickly outdated and forgotten to be updated. Maybe the wiki can be used instead? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2854903380 From ihse at openjdk.org Tue May 6 15:12:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:12:19 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: <9Q_tHeUczynfbPen9yg52qG1NY6z_jVXFgIEnPcsh84=.7544bce2-ed3d-47fe-bb00-5c23bad638a8@github.com> On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato wrote: >>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment) >> >> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README. >> >> Is there some specific problem you are worried about on Windows that you were thinking about? > >> Is there some specific problem you are worried about on Windows that you were thinking about? > > I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas. @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale. I'll ping Yi Yang who was behind https://github.com/openjdk/jdk/pull/3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2854924350 From ihse at openjdk.org Tue May 6 15:25:43 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:25:43 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v4] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Add informative message about supported locales. - Allow C locale with warning instead of fatal error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24574/files - new: https://git.openjdk.org/jdk/pull/24574/files/452f42dc..9ce59e1f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=02-03 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From ihse at openjdk.org Tue May 6 15:29:27 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:29:27 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: <0yCHTP7eQgosQh4hZ5khOXUulKb6gRx_uCr7Rl785Zg=.16873d03-5d82-49f0-9ad4-26330b3282d0@github.com> On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: >> >> - Also document UTF-8 requirements (solves JDK-8338973) >> - Let configure only accept utf-8 locales >> - Address review comments from Kim > > make/autoconf/basic.m4 line 155: > >> 153: else >> 154: AC_MSG_RESULT([no UTF-8 locale found]) >> 155: AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.]) > > Seems we run into this 'else' part on AIX > > > checking for locale to use... no UTF-8 locale found > configure: error: No UTF-8 locale found. This is required for building successfully. > configure exiting with result code 1 > > maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity? (have to check if there are other names on AIX) @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2075728219 From ihse at openjdk.org Tue May 6 15:39:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:39:04 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Merge branch 'master' into go-full-utf8 - Add informative message about supported locales. - Allow C locale with warning instead of fatal error - Also document UTF-8 requirements (solves JDK-8338973) - Let configure only accept utf-8 locales - Address review comments from Kim - Also tell javadoc that we have utf-8 now - Fix flags for Windows - Mark java and native source code as utf-8 - Don't convert properties files to iso-8859-1. - ... and 3 more: https://git.openjdk.org/jdk/compare/e43ea2cd...bea19a70 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24574/files - new: https://git.openjdk.org/jdk/pull/24574/files/9ce59e1f..bea19a70 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=03-04 Stats: 273063 lines in 2455 files changed: 80969 ins; 183018 del; 9076 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From ihse at openjdk.org Tue May 6 15:52:16 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 6 May 2025 15:52:16 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: <4p-YXKf3dE0DR0rzew1i-KXyBlJmWaEvVSf6inZZSCo=.d2a17ec2-18c6-446d-b7e1-11ba55901eb1@github.com> On Mon, 5 May 2025 21:39:15 GMT, Jiangli Zhou wrote: >> .github/workflows/test.yml line 95: >> >>> 93: - test-name: 'hs/tier1 common' >>> 94: test-suite: 'test/hotspot/jtreg/:tier1_common' >>> 95: debug-suffix: ${{ inputs.debug-suffix }} >> >> I don't understand why these changes were needed? What are you doing with the debug suffix? > > The hard-coded `debug-suffix: -debug` maps to run the hs/tier1 tests on `debug` build only. However, we can't build `debug` binary for static JDK yet due to the resource/space issue in GHA. I documented some related details in https://bugs.openjdk.org/browse/JDK-8355452?focusedId=14775969&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14775969. > > Changing hard-coded `-debug` to `${{ inputs.debug-suffix }}` allows us to set '' for `debug-suffix`, which maps to run hs/tier1 tests on `static-jdk` `release` build for now. Ok, I see. Then it makes sense. >> .github/workflows/test.yml line 182: >> >>> 180: BOOT_JDK=${{ steps.bootjdk.outputs.path }} >>> 181: JDK_UNDER_TEST=${{ steps.bundles.outputs.static-jdk-path }} >>> 182: JDK_FOR_COMPILE=${{ steps.bundles.outputs.jdk-path }} >> >> Do we really need to duplicate all this code? From what I can see, this is just to be able to send in the JDK_FOR_COMPILE argument, right? > >> Do we really need to duplicate all this code? From what I can see, this is just to be able to send in the JDK_FOR_COMPILE argument, right? > > Yaml syntax is new to me. I went with that as it worked. :-) The static case sets the `JDK_FOR_COMPILE`|`JDK_UNDER_TEST` and `EXTRA_PROBLEM_LISTS` in `JTREG`. Any suggestion? I think you could add something like ${{ inputs.extra-test-options }} in the `make test-prebuilt` command line, and then set it up as arguments when calling the test workflow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2075767888 PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2075771620 From shurailine at openjdk.org Tue May 6 16:38:54 2025 From: shurailine at openjdk.org (Alexandre Iline) Date: Tue, 6 May 2025 16:38:54 GMT Subject: RFR: 8356226: JCov Grabber server didn't respond [v2] In-Reply-To: References: Message-ID: > Fix is to allow bigger XML files. Alexandre Iline has updated the pull request incrementally with two additional commits since the last revision: - Recover spaces - Declare JCOV_VM_OPTS, set the XML options to 0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25056/files - new: https://git.openjdk.org/jdk/pull/25056/files/5b00c28f..7fa3df9b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25056&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25056&range=00-01 Stats: 14 lines in 1 file changed: 2 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25056.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25056/head:pull/25056 PR: https://git.openjdk.org/jdk/pull/25056 From asemenyuk at openjdk.org Tue May 6 16:43:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 May 2025 16:43:15 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Marked as reviewed by asemenyuk (Reviewer). Looks good assuming jpackage tests ([test/jdk/tools/jpackage/windows/WinNoRestartTest.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24) and [test/jdk/tools/jpackage/windows/Win8301247Test.java](https://github.com/openjdk/jdk/blob/a6995a3d42955f1f207c14be1634daf225b5ab3f/test/jdk/tools/jpackage/windows/Win8301247Test.java#L24)) passed with this change. ------------- PR Review: https://git.openjdk.org/jdk/pull/24791#pullrequestreview-2818983754 PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2855254506 From erikj at openjdk.org Tue May 6 17:01:35 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 17:01:35 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: <-wxBgTp0xqQt8T554qaMqNtRVFkP8b4xqcGQ_6XseoY=.c1968057-1cb2-4081-8039-8731223400f2@github.com> On Tue, 6 May 2025 15:06:36 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Update testing documentation Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24481#pullrequestreview-2819026923 From erikj at openjdk.org Tue May 6 17:23:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 17:23:15 GMT Subject: RFR: 8356226: JCov Grabber server didn't respond [v2] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 16:38:54 GMT, Alexandre Iline wrote: >> Fix is to allow bigger XML files. > > Alexandre Iline has updated the pull request incrementally with two additional commits since the last revision: > > - Recover spaces > - Declare JCOV_VM_OPTS, set the XML options to 0 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25056#pullrequestreview-2819084012 From erikj at openjdk.org Tue May 6 17:26:23 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 17:26:23 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/e6fcaea5...bea19a70 Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2819093476 From cjplummer at openjdk.org Tue May 6 18:51:18 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 May 2025 18:51:18 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 06:31:43 GMT, Igor Veresov wrote: >> 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 43 commits: > > - Merge branch 'master' into pp2 > - Fix compile > - Fix additional issues > - Make sure command line flags that affect MDO layout are consistent > - Fix semantics change from the previous commit > - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type > - Fix flag behavior > - Fix log tags > - Remove the proxy class counter > - Address review comments part 2 > - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 129: > 127: metadataTypeArray[5] = db.lookupType("InstanceStackChunkKlass"); > 128: metadataTypeArray[6] = db.lookupType("Method"); > 129: metadataTypeArray[9] = db.lookupType("MethodData"); It looks like MethodData inheriting from Metadata is not a new change, but has always been the case. I'm surprised this didn't cause any test failures before your changes. Did you end up with test failures after your changes? src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 154: > 152: if (!VM.getVM().isCore()) { > 153: virtualConstructor.addMapping("CompilerThread", CompilerThread.class); > 154: virtualConstructor.addMapping("TrainingReplayThread", TrainingReplayThread.class); The new SA TrainingReplayThread class is not needed since it only overrides isHiddenFromExternalView() to return true. You can instead use HiddenJavaThread.class here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076064357 PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076058595 From shurailine at openjdk.org Tue May 6 19:22:21 2025 From: shurailine at openjdk.org (Alexandre Iline) Date: Tue, 6 May 2025 19:22:21 GMT Subject: Integrated: 8356226: JCov Grabber server didn't respond In-Reply-To: References: Message-ID: On Tue, 6 May 2025 03:23:19 GMT, Alexandre Iline wrote: > Fix is to allow bigger XML files. This pull request has now been integrated. Changeset: e2df9cde Author: Alexandre Iline URL: https://git.openjdk.org/jdk/commit/e2df9cdeb081735bddd24ac2622f59e20cda47ad Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8356226: JCov Grabber server didn't respond Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25056 From serb at openjdk.org Tue May 6 19:48:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 6 May 2025 19:48:15 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:06:36 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Update testing documentation Looks fine, note that is a merge conflict with https://github.com/openjdk/jdk/commit/e2df9cdeb081735bddd24ac2622f59e20cda47ad ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2855758182 From bpb at openjdk.org Tue May 6 20:14:05 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 May 2025 20:14:05 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v13] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - Merge - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c - Merge - ... and 3 more: https://git.openjdk.org/jdk/compare/9477c422...da21fa69 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=12 Stats: 1541 lines in 93 files changed: 774 ins; 668 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From serb at openjdk.org Tue May 6 21:04:14 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 6 May 2025 21:04:14 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:06:36 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Update testing documentation make/RunTests.gmk line 1376: > 1374: jcov-gen-report: jcov-stop-grabber > 1375: $(call LogWarn, Generating JCov report ...) > 1376: $(call ExecuteWithLog, $(JCOV_SUPPORT_DIR)/run-jcov-repgen, Shouldn't there be a backslash at the end of this line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2076269364 From serb at openjdk.org Tue May 6 21:04:14 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 6 May 2025 21:04:14 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:58:17 GMT, Sergey Bylokhov wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: >> >> - Update copyright year >> - Update testing documentation > > make/RunTests.gmk line 1376: > >> 1374: jcov-gen-report: jcov-stop-grabber >> 1375: $(call LogWarn, Generating JCov report ...) >> 1376: $(call ExecuteWithLog, $(JCOV_SUPPORT_DIR)/run-jcov-repgen, > > Shouldn't there be a backslash at the end of this line? On windows+cygwin: Generating JCov report ... RunTests.gmk:1378: *** unterminated call to function 'call': missing ')'. Stop. make[2]: *** [make/Main.gmk:820: jcov-test] Error 2 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2076270927 From iveresov at openjdk.org Tue May 6 21:50:34 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 6 May 2025 21:50:34 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/7d22a42a..11e3c398 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=12-13 Stats: 36 lines in 2 files changed: 0 ins; 35 del; 1 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 From iveresov at openjdk.org Tue May 6 21:50:36 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 6 May 2025 21:50:36 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v13] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 18:48:03 GMT, Chris Plummer wrote: >> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 43 commits: >> >> - Merge branch 'master' into pp2 >> - Fix compile >> - Fix additional issues >> - Make sure command line flags that affect MDO layout are consistent >> - Fix semantics change from the previous commit >> - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type >> - Fix flag behavior >> - Fix log tags >> - Remove the proxy class counter >> - Address review comments part 2 >> - ... and 33 more: https://git.openjdk.org/jdk/compare/e09d2e27...7d22a42a > > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/memory/FileMapInfo.java line 129: > >> 127: metadataTypeArray[5] = db.lookupType("InstanceStackChunkKlass"); >> 128: metadataTypeArray[6] = db.lookupType("Method"); >> 129: metadataTypeArray[9] = db.lookupType("MethodData"); > > It looks like MethodData inheriting from Metadata is not a new change, but has always been the case. I'm surprised this didn't cause any test failures before your changes. Did you end up with test failures after your changes? Honestly I don't remember, I think @iklam did these changes. > src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/runtime/Threads.java line 154: > >> 152: if (!VM.getVM().isCore()) { >> 153: virtualConstructor.addMapping("CompilerThread", CompilerThread.class); >> 154: virtualConstructor.addMapping("TrainingReplayThread", TrainingReplayThread.class); > > The new SA TrainingReplayThread class is not needed since it only overrides isHiddenFromExternalView() to return true. You can instead use HiddenJavaThread.class here. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076373507 PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2076369998 From erikj at openjdk.org Tue May 6 21:57:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 21:57:16 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:06:36 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Update copyright year > - Update testing documentation Changes requested by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24481#pullrequestreview-2819790106 From erikj at openjdk.org Tue May 6 21:57:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 6 May 2025 21:57:17 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v3] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 20:59:35 GMT, Sergey Bylokhov wrote: >> make/RunTests.gmk line 1376: >> >>> 1374: jcov-gen-report: jcov-stop-grabber >>> 1375: $(call LogWarn, Generating JCov report ...) >>> 1376: $(call ExecuteWithLog, $(JCOV_SUPPORT_DIR)/run-jcov-repgen, >> >> Shouldn't there be a backslash at the end of this line? > > On windows+cygwin: > > Generating JCov report ... > RunTests.gmk:1378: *** unterminated call to function 'call': missing ')'. Stop. > make[2]: *** [make/Main.gmk:820: jcov-test] Error 2 It should indeed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24481#discussion_r2076391734 From duke at openjdk.org Wed May 7 01:14:16 2025 From: duke at openjdk.org (Daishi Tabata) Date: Wed, 7 May 2025 01:14:16 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: <_DiRDJt8fWIUVE67JZBz77VD8I1ubbynjOkrjnX7jhU=.b6a7ef16-a1fb-447d-838c-b74b49157561@github.com> On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856733631 From duke at openjdk.org Wed May 7 01:14:17 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 01:14:17 GMT Subject: RFR: 8355249: Remove the use of WMIC from the entire source code [v2] In-Reply-To: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> References: <0qni46HUmpDRpH_gOtzNRJcLZ8YAX5J1FQ_0o0j2RU8=.a32c9c2f-c324-4fef-a11e-b4ed4ae373fb@github.com> Message-ID: On Tue, 22 Apr 2025 07:41:43 GMT, Daishi Tabata wrote: >> After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. >> >> The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. >> >> Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. >> Note: In my environment, it worked correctly even without these options. >> >> The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: >> >> - `environment.html`: `windows/system/os` section >> - `process.html`: `[Process ID]/windows/native/info` section >> >> **Testing:** >> I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. > > Daishi Tabata has updated the pull request incrementally with one additional commit since the last revision: > > run jcheck @tabata-d Your change (at version 76a3a7ee1f3f266795c88dd35e03205d7a8234aa) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24791#issuecomment-2856734732 From yyang at openjdk.org Wed May 7 01:43:18 2025 From: yyang at openjdk.org (Yi Yang) Date: Wed, 7 May 2025 01:43:18 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: On Thu, 17 Apr 2025 16:26:59 GMT, Naoto Sato wrote: >>> We will probably need to make sure things are ok on Windows as well (they are the other confusing environment) >> >> Windows is much more painful to work with, since there is no correspondence of `LC_ALL`; you must set the user's locale. There is a rather long paragraph detailing the requirements for building without problems in the build README. >> >> Is there some specific problem you are worried about on Windows that you were thinking about? > >> Is there some specific problem you are worried about on Windows that you were thinking about? > > I would have tested on non-English (preferrably Chinese/Japanese) Windows where users set it to English. I believe we had issues from contributors in those areas. > @naotoj Unfortunately, I do not have the possibility to test on a Windows machine with Chinese locale. > > I'll ping Yi Yang who was behind #3107, a suggested solution for [JDK-8263028](https://bugs.openjdk.org/browse/JDK-8263028). That is the best I was able to dig up for any contributor that clearly had run into this kind of problems before. > > @y1yang0 Can you please help us to test this patch so it works properly on Windows computers with Chinese locale? Sorry, I haven't worked on JDK for a while. Maybe @Glavo? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2856775920 From duke at openjdk.org Wed May 7 05:28:14 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 05:28:14 GMT Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH benchmarks In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o wrote: > Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler. @galderz Your change (at version a2b73be2533635ee169069d1a0552de466d1bf52) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2857097689 From galder at openjdk.org Wed May 7 06:20:21 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Wed, 7 May 2025 06:20:21 GMT Subject: Integrated: 8354257: xctracenorm profiler not working with JDK JMH benchmarks In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:02:45 GMT, Galder Zamarre?o wrote: > Avoid filtering out xml files at the root of the JMH folder, in order to get the `default.instruments.template.xml` file bundled in the JMH core jar to support xtrace profiler. This pull request has now been integrated. Changeset: 772c9703 Author: Galder Zamarre?o Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/772c97039e9841410f0ca2a25e984719221174e1 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8354257: xctracenorm profiler not working with JDK JMH benchmarks Reviewed-by: ihse ------------- PR: https://git.openjdk.org/jdk/pull/24571 From duke at openjdk.org Wed May 7 06:22:19 2025 From: duke at openjdk.org (Daishi Tabata) Date: Wed, 7 May 2025 06:22:19 GMT Subject: Integrated: 8355249: Remove the use of WMIC from the entire source code In-Reply-To: References: Message-ID: On Tue, 22 Apr 2025 07:29:08 GMT, Daishi Tabata wrote: > After searching the entire JDK source code, I found that WMIC is only used in four files. These WMIC calls can be replaced with PowerShell for WMI. > > The primary challenge in this replacement is to make it work the same as before, even if the output format of the PowerShell command is different from the original WMIC output. Where necessary, I've adjusted the output formatting to maintain consistency. > > Regarding the PowerShell options `-NoLogo`, `-NoProfile`, and `-NonInteractive`, I've included them only when they are already used in the surrounding code within the affected file. > Note: In my environment, it worked correctly even without these options. > > The `failure_handler` outputs powershell command execution results directly into HTML. While the number and order of output items may differ slightly after the modification, all previously output items are still included. Therefore, I believe this is not a problem. Specific output changes are located in: > > - `environment.html`: `windows/system/os` section > - `process.html`: `[Process ID]/windows/native/info` section > > **Testing:** > I have confirmed that all tests in `jdk/tools/jpackage` pass after these changes. This pull request has now been integrated. Changeset: 4458719a Author: Daishi Tabata Committer: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/4458719a108f45d3744d47a6ea081fe9ec3e675e Stats: 32 lines in 4 files changed: 6 ins; 2 del; 24 mod 8355249: Remove the use of WMIC from the entire source code Reviewed-by: erikj, ihse, asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/24791 From mbaesken at openjdk.org Wed May 7 07:23:16 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 07:23:16 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v3] In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 10:35:02 GMT, Matthias Baesken wrote: >> Magnus Ihse Bursie has updated the pull request incrementally with three additional commits since the last revision: >> >> - Also document UTF-8 requirements (solves JDK-8338973) >> - Let configure only accept utf-8 locales >> - Address review comments from Kim > > make/autoconf/basic.m4 line 155: > >> 153: else >> 154: AC_MSG_RESULT([no UTF-8 locale found]) >> 155: AC_MSG_ERROR([No UTF-8 locale found. This is required for building successfully.]) > > Seems we run into this 'else' part on AIX > > > checking for locale to use... no UTF-8 locale found > configure: error: No UTF-8 locale found. This is required for building successfully. > configure exiting with result code 1 > > maybe it would be nice to display the desired ones C.UTF-8 or en_US.UTF-8 in this message too for more clarity? (have to check if there are other names on AIX) > @MBaesken I added an informative text about supported locales. I also lowered the fatal error of missing an UTF-8 locale into just a warning (for all platforms, not just AIX). Apparently it works with building on AIX for now, even with a undefined character encoding, but I will not guarantee that it will continue to work for all eternity. But a warning is probably be enough, and if it does work the user is free to try. :) Sounds good to me , thanks for adjusting ! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24574#discussion_r2076970234 From ihse at openjdk.org Wed May 7 07:56:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 07:56:53 GMT Subject: RFR: 8356335: Remove linux-x86 from jib profiles Message-ID: After [JEP 503](https://openjdk.org/jeps/503), we cannot build linux-x86 so it should not be included in the jib profiles. I also took the opportunity to remove the superfluous `--with-target-bits=64` option, clean up some `configure_args` constructs, and to reorder the profiles to group all linux profiles together. ------------- Commit messages: - 8356335: Remove linux-x86 from jib profiles Changes: https://git.openjdk.org/jdk/pull/25083/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25083&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356335 Stats: 78 lines in 1 file changed: 23 ins; 33 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/25083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25083/head:pull/25083 PR: https://git.openjdk.org/jdk/pull/25083 From mbaesken at openjdk.org Wed May 7 08:17:21 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 08:17:21 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70 Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2820807425 From mdoerr at openjdk.org Wed May 7 08:17:22 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 May 2025 08:17:22 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v5] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 15:39:04 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - Don't convert properties files to iso-8859-1. > - ... and 3 more: https://git.openjdk.org/jdk/compare/747c59ad...bea19a70 @sxa I guess UTF-8 locales will need to be documented for Adoptium AIX build requirements, too, when this change goes in. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2857536070 From ihse at openjdk.org Wed May 7 08:45:49 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 08:45:49 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v4] In-Reply-To: References: Message-ID: > Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Merge branch 'master' into with-jcov-modules - Update copyright year - Update testing documentation - Merge branch 'master' into with-jcov-modules - Also fix RepGen - Update with correct syntax + debug support - 8282493: Add --with-jcov-modules convenience option ------------- Changes: https://git.openjdk.org/jdk/pull/24481/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=03 Stats: 46 lines in 6 files changed: 38 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/24481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24481/head:pull/24481 PR: https://git.openjdk.org/jdk/pull/24481 From ihse at openjdk.org Wed May 7 09:09:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 09:09:53 GMT Subject: RFR: 8356335: Remove linux-x86 from jib profiles [v2] In-Reply-To: References: Message-ID: <0l6p3W3SDTgKVbtlJDWnXrZFUZ44hoyqZRbxA_XpHRk=.ae7d2e62-f79d-4eb3-b9df-dfa7d403415c@github.com> > After [JEP 503](https://openjdk.org/jeps/503), we cannot build linux-x86 so it should not be included in the jib profiles. > > I also took the opportunity to remove the superfluous `--with-target-bits=64` option, clean up some `configure_args` constructs, and to reorder the profiles to group all linux profiles together. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into remove-linux-x86-in-jib - 8356335: Remove linux-x86 from jib profiles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25083/files - new: https://git.openjdk.org/jdk/pull/25083/files/bba90a19..34055672 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25083&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25083&range=00-01 Stats: 14 lines in 3 files changed: 8 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25083/head:pull/25083 PR: https://git.openjdk.org/jdk/pull/25083 From ihse at openjdk.org Wed May 7 09:18:29 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 09:18:29 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v5] In-Reply-To: References: Message-ID: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> > Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Add missing \ ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24481/files - new: https://git.openjdk.org/jdk/pull/24481/files/c44f7143..af3e04b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24481&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24481/head:pull/24481 PR: https://git.openjdk.org/jdk/pull/24481 From ihse at openjdk.org Wed May 7 11:02:28 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 11:02:28 GMT Subject: RFR: 8356379: Need a proper way to test existence of binary from configure Message-ID: When we setup a command to run, e.g. $FOO we typically set this to just a path to a binary, e.g. /usr/bin/foo. However, this is not necessarily true. On Windows, this can be prefixed by the $FIXPATH prefix, and on all platforms we are allowed to pass arguments to the executable. If we want to test if this binary actually exists, we need to extract the binary name from this command line. We have a NOFIXPATH argument to UTIL_LOOKUP_PROGS, which tried to resolve this, but it is not enough, and it makes it impossible to both lookup a program properly and also check for its existance afterwards. Instead, I propose to add a UTIL_GET_EXECUTABLE function that extracts just the path to the binary from such a command. ------------- Commit messages: - 8356379: Need a proper way to test existence of binary from configure Changes: https://git.openjdk.org/jdk/pull/25087/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25087&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356379 Stats: 37 lines in 2 files changed: 20 ins; 8 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25087.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25087/head:pull/25087 PR: https://git.openjdk.org/jdk/pull/25087 From ihse at openjdk.org Wed May 7 11:25:19 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 11:25:19 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v5] In-Reply-To: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> References: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> Message-ID: On Wed, 7 May 2025 09:18:29 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add missing \ Obviously I did not run the test to it's completion to get a jcov report before; my bad. :-( However, when I'm now trying to run some more comprehensive testing with jcov, I get multiple test failures. Most are along the lines of: STDERR: [Jstatd-Thread] Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g [Jstatd-Thread] Picked up _JAVA_OPTIONS: -Xms64m -Xmx4g [Jstatd-Thread] WARNING: jstatd is deprecated and will be removed in a future release. java.lang.RuntimeException: Output does not match the pattern Picked up JAVA_TOOL_OPTIONS: -Xms64m -Xmx4g: expected true, was false at jdk.test.lib.Asserts.fail(Asserts.java:715) JAVA_TOOL_OPTIONS and _JAVA_OPTIONS are setup in lines 127...130 in RunTests.gmk. @mrserb Is this expected behavior, or am I doing something wrong? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2858200929 From ihse at openjdk.org Wed May 7 11:51:18 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 11:51:18 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v5] In-Reply-To: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> References: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> Message-ID: On Wed, 7 May 2025 09:18:29 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add missing \ Apart from these test failures, the jcov run, including report generation, was successful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2858280443 From erikj at openjdk.org Wed May 7 13:14:16 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 13:14:16 GMT Subject: RFR: 8356335: Remove linux-x86 from jib profiles [v2] In-Reply-To: <0l6p3W3SDTgKVbtlJDWnXrZFUZ44hoyqZRbxA_XpHRk=.ae7d2e62-f79d-4eb3-b9df-dfa7d403415c@github.com> References: <0l6p3W3SDTgKVbtlJDWnXrZFUZ44hoyqZRbxA_XpHRk=.ae7d2e62-f79d-4eb3-b9df-dfa7d403415c@github.com> Message-ID: On Wed, 7 May 2025 09:09:53 GMT, Magnus Ihse Bursie wrote: >> After [JEP 503](https://openjdk.org/jeps/503), we cannot build linux-x86 so it should not be included in the jib profiles. >> >> I also took the opportunity to remove the superfluous `--with-target-bits=64` option, clean up some `configure_args` constructs, and to reorder the profiles to group all linux profiles together. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into remove-linux-x86-in-jib > - 8356335: Remove linux-x86 from jib profiles Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25083#pullrequestreview-2821699675 From erikj at openjdk.org Wed May 7 13:19:13 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 13:19:13 GMT Subject: RFR: 8356379: Need a proper way to test existence of binary from configure In-Reply-To: References: Message-ID: On Wed, 7 May 2025 10:57:27 GMT, Magnus Ihse Bursie wrote: > When we setup a command to run, e.g. $FOO we typically set this to just a path to a binary, e.g. /usr/bin/foo. However, this is not necessarily true. On Windows, this can be prefixed by the $FIXPATH prefix, and on all platforms we are allowed to pass arguments to the executable. > > If we want to test if this binary actually exists, we need to extract the binary name from this command line. We have a NOFIXPATH argument to UTIL_LOOKUP_PROGS, which tried to resolve this, but it is not enough, and it makes it impossible to both lookup a program properly and also check for its existance afterwards. > > Instead, I propose to add a UTIL_GET_EXECUTABLE function that extracts just the path to the binary from such a command. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25087#pullrequestreview-2821716649 From erikj at openjdk.org Wed May 7 13:22:17 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 13:22:17 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v5] In-Reply-To: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> References: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> Message-ID: On Wed, 7 May 2025 09:18:29 GMT, Magnus Ihse Bursie wrote: >> Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Add missing \ Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24481#pullrequestreview-2821723778 From ihse at openjdk.org Wed May 7 13:26:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 13:26:24 GMT Subject: Integrated: 8356335: Remove linux-x86 from jib profiles In-Reply-To: References: Message-ID: On Wed, 7 May 2025 07:51:16 GMT, Magnus Ihse Bursie wrote: > After [JEP 503](https://openjdk.org/jeps/503), we cannot build linux-x86 so it should not be included in the jib profiles. > > I also took the opportunity to remove the superfluous `--with-target-bits=64` option, clean up some `configure_args` constructs, and to reorder the profiles to group all linux profiles together. This pull request has now been integrated. Changeset: fa765e7d Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/fa765e7d346d26a1c5065830bd01d850720da8ae Stats: 78 lines in 1 file changed: 23 ins; 33 del; 22 mod 8356335: Remove linux-x86 from jib profiles Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25083 From ihse at openjdk.org Wed May 7 13:26:24 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 13:26:24 GMT Subject: Integrated: 8356379: Need a proper way to test existence of binary from configure In-Reply-To: References: Message-ID: On Wed, 7 May 2025 10:57:27 GMT, Magnus Ihse Bursie wrote: > When we setup a command to run, e.g. $FOO we typically set this to just a path to a binary, e.g. /usr/bin/foo. However, this is not necessarily true. On Windows, this can be prefixed by the $FIXPATH prefix, and on all platforms we are allowed to pass arguments to the executable. > > If we want to test if this binary actually exists, we need to extract the binary name from this command line. We have a NOFIXPATH argument to UTIL_LOOKUP_PROGS, which tried to resolve this, but it is not enough, and it makes it impossible to both lookup a program properly and also check for its existance afterwards. > > Instead, I propose to add a UTIL_GET_EXECUTABLE function that extracts just the path to the binary from such a command. This pull request has now been integrated. Changeset: a72f7506 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a72f7506bf07be722c90ed64f5177699d2cebdb2 Stats: 37 lines in 2 files changed: 20 ins; 8 del; 9 mod 8356379: Need a proper way to test existence of binary from configure Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25087 From ihse at openjdk.org Wed May 7 13:32:22 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 13:32:22 GMT Subject: Integrated: 8282493: Add --with-jcov-modules convenience option In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 08:45:13 GMT, Magnus Ihse Bursie wrote: > Allow the user to set "--with-jcov-modules=java.desktop", instead of "--with-jcov-filters=--include-modules java.desktop", since this is one of the common use cases for the filtering. This pull request has now been integrated. Changeset: ca5e0b18 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/ca5e0b1848054848fb5e39eebac06f2011cceb2e Stats: 46 lines in 6 files changed: 38 ins; 0 del; 8 mod 8282493: Add --with-jcov-modules convenience option Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24481 From ihse at openjdk.org Wed May 7 13:51:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 13:51:54 GMT Subject: RFR: 8244533: Configure should abort on missing short names in Windows Message-ID: Windows can create short names for directories that contain spaces in the name. However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. ------------- Commit messages: - 8244533: Configure should abort on missing short names in Windows Changes: https://git.openjdk.org/jdk/pull/24483/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24483&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8244533 Stats: 125 lines in 6 files changed: 76 ins; 5 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/24483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24483/head:pull/24483 PR: https://git.openjdk.org/jdk/pull/24483 From erikj at openjdk.org Wed May 7 15:26:15 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 15:26:15 GMT Subject: RFR: 8244533: Configure should abort on missing short names in Windows In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:18:08 GMT, Magnus Ihse Bursie wrote: > Windows can create short names for directories that contain spaces in the name. > > However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). > > We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. > > When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. This is a great change. Just a minor grammar nit in the docs. doc/building.md line 117: > 115: upper and lower case letters. > 116: > 117: Failure to follow this procedure might result in hard-to-debug build We are listing 2 bullets for Cygwin here so I think plural sounds better. Suggestion: Failure to follow these procedures might result in hard-to-debug build ------------- PR Review: https://git.openjdk.org/jdk/pull/24483#pullrequestreview-2822221921 PR Review Comment: https://git.openjdk.org/jdk/pull/24483#discussion_r2077896621 From cjplummer at openjdk.org Wed May 7 17:03:22 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 7 May 2025 17:03:22 GMT Subject: RFR: 8355003: Implement Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov wrote: >> 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 incrementally with one additional commit since the last revision: > > Address review comments SA changes look good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2822536705 From serb at openjdk.org Wed May 7 18:31:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 7 May 2025 18:31:15 GMT Subject: RFR: 8282493: Add --with-jcov-modules convenience option [v5] In-Reply-To: References: <6izsnSXGnAOwqtLkaMw21BbfoqcVPCKCe1W_m8nmAoc=.8fbdf814-3088-45d8-bac2-6ad5fd698363@github.com> Message-ID: On Wed, 7 May 2025 11:22:40 GMT, Magnus Ihse Bursie wrote: > JAVA_TOOL_OPTIONS and _JAVA_OPTIONS are setup in lines 127...130 in RunTests.gmk. > > @mrserb Is this expected behavior, or am I doing something wrong? That is a known issue: https://bugs.openjdk.org/browse/JDK-8219323 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24481#issuecomment-2859790217 From ihse at openjdk.org Wed May 7 20:18:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 20:18:09 GMT Subject: RFR: 8244533: Configure should abort on missing short names in Windows [v2] In-Reply-To: References: Message-ID: > Windows can create short names for directories that contain spaces in the name. > > However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). > > We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. > > When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Fix typo Co-authored-by: Erik Joelsson <37597443+erikj79 at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24483/files - new: https://git.openjdk.org/jdk/pull/24483/files/210aa040..45a94bfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24483&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24483&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24483/head:pull/24483 PR: https://git.openjdk.org/jdk/pull/24483 From ihse at openjdk.org Wed May 7 20:24:09 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 20:24:09 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source Message-ID: We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) ------------- Commit messages: - 8334391: JDK build should exclude *-files directories for Java source Changes: https://git.openjdk.org/jdk/pull/24449/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24449&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334391 Stats: 36 lines in 7 files changed: 18 ins; 17 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24449/head:pull/24449 PR: https://git.openjdk.org/jdk/pull/24449 From ihse at openjdk.org Wed May 7 20:26:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 20:26:13 GMT Subject: RFR: 8244533: Configure should abort on missing short names in Windows [v3] In-Reply-To: References: Message-ID: > Windows can create short names for directories that contain spaces in the name. > > However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). > > We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. > > When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Regenerate html file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24483/files - new: https://git.openjdk.org/jdk/pull/24483/files/45a94bfe..b3e6d2ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24483&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24483&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24483.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24483/head:pull/24483 PR: https://git.openjdk.org/jdk/pull/24483 From ihse at openjdk.org Wed May 7 20:36:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 20:36:51 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home Message-ID: If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. ------------- Commit messages: - 8351029: IncludeCustomExtension does not work on cygwin with source code below /home Changes: https://git.openjdk.org/jdk/pull/25100/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25100&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351029 Stats: 7 lines in 1 file changed: 4 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25100/head:pull/25100 PR: https://git.openjdk.org/jdk/pull/25100 From erikj at openjdk.org Wed May 7 20:47:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 20:47:53 GMT Subject: RFR: 8244533: Configure should abort on missing short names in Windows [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 20:26:13 GMT, Magnus Ihse Bursie wrote: >> Windows can create short names for directories that contain spaces in the name. >> >> However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). >> >> We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. >> >> When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Regenerate html file Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24483#pullrequestreview-2823166416 From erikj at openjdk.org Wed May 7 21:15:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 21:15:51 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 14:44:07 GMT, Magnus Ihse Bursie wrote: > We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. > > (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) make/common/JavaCompilation.gmk line 342: > 340: $1_SRCS_WITHOUT_ROOTS := $$($1_SRCS) > 341: $$(foreach i, $$($1_SRC), $$(eval $1_SRCS_WITHOUT_ROOTS := $$(patsubst \ > 342: $$i/%,%, $$($1_SRCS_WITHOUT_ROOTS)))) Using eval like this can sometimes have weird consequences. I would recommend rewriting this without eval. I think something like this should work. It may change the order of elements, but that shouldn't matter here. $1_SRCS_WITHOUT_ROOTS := $$(foreach i, $$($1_SRC), \ $$(patsubst $$i/%,%, $$(filter $$i/%, $$($1_SRCS)))) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24449#discussion_r2078501336 From erikj at openjdk.org Wed May 7 21:23:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 7 May 2025 21:23:55 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:08:53 GMT, Magnus Ihse Bursie wrote: > If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. > > The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. Is it the `cd $$(TOPDIR)` when calling make from `DefineMakeTargets` that is causing the mismatch that you are correcting by including SPEC here? make/PreInitSupport.gmk line 256: > 254: # We need to include the given SPEC file to setup TOPDIR properly > 255: SPEC_FILE := $(strip $2) > 256: -include $$(SPEC_FILE) Is it safe to include SPEC here? I thought the point of PreInit.gmk was that it didn't load it. ------------- PR Review: https://git.openjdk.org/jdk/pull/25100#pullrequestreview-2823235338 PR Review Comment: https://git.openjdk.org/jdk/pull/25100#discussion_r2078509849 From ihse at openjdk.org Wed May 7 21:30:11 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 21:30:11 GMT Subject: RFR: 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197 Message-ID: `echo -n` is not part of the required POSIX standard, and built in shell versions of echo might not support it. Restore the previous use of `printf` instead. ------------- Commit messages: - 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197 Changes: https://git.openjdk.org/jdk/pull/25106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354278 Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25106/head:pull/25106 PR: https://git.openjdk.org/jdk/pull/25106 From ihse at openjdk.org Wed May 7 21:36:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 21:36:56 GMT Subject: Integrated: 8244533: Configure should abort on missing short names in Windows In-Reply-To: References: Message-ID: On Mon, 7 Apr 2025 09:18:08 GMT, Magnus Ihse Bursie wrote: > Windows can create short names for directories that contain spaces in the name. > > However, where short name creation was previously enabled by default, it no longer seems to be in recent version of Windows (the default setting is instead 'per volume', and the default for each volume is 'off'). > > We should check that the output paths of these utility macros are actually space-free, and emit an error otherwise. We should also add additional documentation about short names, and the short name creation setting to doc/building.md. > > When testing this in several different cases with path including spaces that either had or had not a short name, it became apparent that the current handling of such cases were not ... optimal. Hence some bug fixes were needed to properly handle such cases. This pull request has now been integrated. Changeset: 493ac936 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/493ac93606e4637638ec1ae34e24526aaba7b7f3 Stats: 124 lines in 6 files changed: 76 ins; 5 del; 43 mod 8244533: Configure should abort on missing short names in Windows Co-authored-by: Jorn Vernee Co-authored-by: Magnus Ihse Bursie Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24483 From ihse at openjdk.org Wed May 7 21:40:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 21:40:51 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:21:14 GMT, Erik Joelsson wrote: > Is it the `cd $$(TOPDIR)` when calling make from `DefineMakeTargets` that is causing the mismatch that you are correcting by including SPEC here? No, it is the `-f $$(TOPDIR)/make/GenerateFindTests.gmk` argument to make. This is added verbatim by make to `MAKEFILE_LIST`, and then our string processing in make/common/MakeIncludeStart.gmk does not work properly, since it tries to strip off $(TOPDIR), which at that point is different. My first attempt was to re-create the TOPDIR in PreInit the same way as it is created in spec.gmk, but that would include mimicking the entire UTIL_FIXUP_PATH which seemed to be just too much work and too fragile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25100#issuecomment-2860452248 From ihse at openjdk.org Wed May 7 21:40:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 21:40:51 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home In-Reply-To: References: Message-ID: <-gWoWQNjhNSTsZaDyi_4BnFRySIMwFA48nz7s_iju_I=.db1cc8e8-7d33-4a32-8776-877654683cb5@github.com> On Wed, 7 May 2025 15:08:53 GMT, Magnus Ihse Bursie wrote: > If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. > > The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. I just realized that it might be possible to pass the TOPDIR actually used down to MakeIncludeStart, and it might be a better solution... I'll check that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25100#issuecomment-2860453924 From ihse at openjdk.org Wed May 7 21:44:53 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 21:44:53 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:17:47 GMT, Erik Joelsson wrote: >> If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. >> >> The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. > > make/PreInitSupport.gmk line 256: > >> 254: # We need to include the given SPEC file to setup TOPDIR properly >> 255: SPEC_FILE := $(strip $2) >> 256: -include $$(SPEC_FILE) > > Is it safe to include SPEC here? I thought the point of PreInit.gmk was that it didn't load it. Yeah, it is a bit scary. I don't really like it either. I tested this and it seemed okay, but we are not sure we are including the proper spec at this point, since we can pick an arbitrary spec file for e.g. tab expansion. I can't really say what could go wrong, but it is more of the lines "this is not obviously wrong" rather than "this is obviously right". I also toyed with the idea of extracting the TOPDIR line from the spec file, but that would mean accessing grep (and possibly some other tool like sed, awk or cut) before we have properly checked for that, and we have not done anything like that so early up until now, so that was not attractive either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25100#discussion_r2078535348 From ihse at openjdk.org Wed May 7 22:50:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 22:50:52 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home [v2] In-Reply-To: References: Message-ID: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> > If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. > > The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'master' into fix-preinit-topdir - Alternative solution - 8351029: IncludeCustomExtension does not work on cygwin with source code below /home ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25100/files - new: https://git.openjdk.org/jdk/pull/25100/files/65a1b222..f227d802 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25100&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25100&range=00-01 Stats: 1586 lines in 89 files changed: 925 ins; 309 del; 352 mod Patch: https://git.openjdk.org/jdk/pull/25100.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25100/head:pull/25100 PR: https://git.openjdk.org/jdk/pull/25100 From ihse at openjdk.org Wed May 7 22:53:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 22:53:54 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home [v2] In-Reply-To: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> References: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> Message-ID: <7d_LVIIT-_NVo5qmvI6MfJvvvT2_qrJgmseRNcOaSfg=.986be28c-0add-4390-a10c-6ecf6891c12c@github.com> On Wed, 7 May 2025 22:50:52 GMT, Magnus Ihse Bursie wrote: >> If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. >> >> The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fix-preinit-topdir > - Alternative solution > - 8351029: IncludeCustomExtension does not work on cygwin with source code below /home This seems like a much safer solution. It will allow us to have two different "spellings" for TOPDIR, one that configure puts in spec.gmk, and one that is calculated by the top-level `Makefile`. I think this will make for a robust solution. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25100#issuecomment-2860627277 From ihse at openjdk.org Wed May 7 22:54:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 22:54:51 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:12:54 GMT, Erik Joelsson wrote: >> We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. >> >> (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) > > make/common/JavaCompilation.gmk line 342: > >> 340: $1_SRCS_WITHOUT_ROOTS := $$($1_SRCS) >> 341: $$(foreach i, $$($1_SRC), $$(eval $1_SRCS_WITHOUT_ROOTS := $$(patsubst \ >> 342: $$i/%,%, $$($1_SRCS_WITHOUT_ROOTS)))) > > Using eval like this can sometimes have weird consequences. I would recommend rewriting this without eval. I think something like this should work. It may change the order of elements, but that shouldn't matter here. > > > $1_SRCS_WITHOUT_ROOTS := $$(foreach i, $$($1_SRC), \ > $$(patsubst $$i/%,%, $$(filter $$i/%, $$($1_SRCS)))) I agree that this looks a bit wonky. I just copied it from SetupNativeCompilation, since it has worked well there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24449#discussion_r2078598352 From ihse at openjdk.org Wed May 7 22:59:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 7 May 2025 22:59:04 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source [v2] In-Reply-To: References: Message-ID: > We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. > > (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Get rid of looped eval ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24449/files - new: https://git.openjdk.org/jdk/pull/24449/files/7dc87aca..04d4605f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24449&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24449&range=00-01 Stats: 7 lines in 2 files changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/24449.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24449/head:pull/24449 PR: https://git.openjdk.org/jdk/pull/24449 From iris at openjdk.org Wed May 7 23:33:51 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 7 May 2025 23:33:51 GMT Subject: RFR: 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197 In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:25:39 GMT, Magnus Ihse Bursie wrote: > `echo -n` is not part of the required POSIX standard, and built in shell versions of echo might not support it. Restore the previous use of `printf` instead. Verified 15 uses of `$(ECHO) -n` introduced by [8301197](https://bugs.openjdk.org/browse/JDK-8301197) ([PR 24415](https://github.com/openjdk/jdk/pull/24415)) reverted. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25106#pullrequestreview-2823459609 From ihse at openjdk.org Thu May 8 10:19:31 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 May 2025 10:19:31 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into go-full-utf8 - Merge branch 'master' into go-full-utf8 - Add informative message about supported locales. - Allow C locale with warning instead of fatal error - Also document UTF-8 requirements (solves JDK-8338973) - Let configure only accept utf-8 locales - Address review comments from Kim - Also tell javadoc that we have utf-8 now - Fix flags for Windows - Mark java and native source code as utf-8 - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db ------------- Changes: https://git.openjdk.org/jdk/pull/24574/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24574&range=05 Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/24574.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24574/head:pull/24574 PR: https://git.openjdk.org/jdk/pull/24574 From nbenalla at openjdk.org Thu May 8 13:18:07 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 8 May 2025 13:18:07 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - feedback: never bump ASM version - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274 + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274 + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274 + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274 + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274 - Update --release 25 symbol information for JDK 24 build 20 The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/ - initial commit start-of-JDK-26 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=01 Stats: 1390 lines in 53 files changed: 1299 ins; 16 del; 75 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From nbenalla at openjdk.org Thu May 8 13:18:08 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 8 May 2025 13:18:08 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 16:42:04 GMT, Joe Darcy wrote: >> test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java line 50: >> >>> 48: public class HelpOutputColumnWidthTest extends TestRunner { >>> 49: >>> 50: public static final int MAX_COLUMNS = 84; >> >> What is this for? > > It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". > > Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. I'll split the releases over two lines in the next update. The line is a little too long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2079697514 From ihse at openjdk.org Thu May 8 13:36:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Thu, 8 May 2025 13:36:56 GMT Subject: Integrated: 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197 In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:25:39 GMT, Magnus Ihse Bursie wrote: > `echo -n` is not part of the required POSIX standard, and built in shell versions of echo might not support it. Restore the previous use of `printf` instead. This pull request has now been integrated. Changeset: 57297e60 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/57297e60de92b9878fb3926109da3e0058a506ae Stats: 17 lines in 5 files changed: 0 ins; 0 del; 17 mod 8354278: Revert use of non-POSIX echo -n introduced in JDK-8301197 Reviewed-by: iris ------------- PR: https://git.openjdk.org/jdk/pull/25106 From mbaesken at openjdk.org Thu May 8 13:54:58 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 8 May 2025 13:54:58 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: <0MvaSKWRsIMKLk243wtixaCcKnNukwftJGg_yzHDTvo=.298e599e-de85-42c5-b2bd-cad7ad630fc7@github.com> On Wed, 9 Apr 2025 12:33:26 GMT, Magnus Ihse Bursie wrote: >> The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. >> On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there. >> >> On Linux x86_64 for example the lib shrinks from >> 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M . >> >> On Linux ppc64le for example the lib shrinks from >> 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M . > > I'd like to move to a world where we basically have just two optimization levels, "size" and "speed", and libraries do not in general have the level specified, so it falls back on a default, which could then be set by configure. For individual libraries we might need to override the default value, if we know that certain compilers make a mess of certain optimization levels, or if some libraries are especially performance sensitive. (Making hotspot `-Os` would certainly never make any sense, for example.) @magicus should we close this one and follow up with another JBS issue, making opt-size the default for JDK libs ? I think you proposed something like this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2863156276 From lkorinth at openjdk.org Thu May 8 15:02:42 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 15:02:42 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor Message-ID: This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. These fixes have been created when I have plown through testcases: JDK-8352719: Add an equals sign to the modules statement JDK-8352709: Remove bad timing annotations from WhileOpTest.java JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE CODETOOLS-7903961: Make default timeout configurable Sometime in the future I will also fix: 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 for which I am awaiting: CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 *After the review I will revert the two first commits, and update the copyrights* ------------- Commit messages: - 8356171: Increase timeout for testcases as preparation for change of default timeout factor - Fix some tests that need an upgrade of JTREG --- REVERT THIS LATER - 8260555 Changes: https://git.openjdk.org/jdk/pull/25122/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25122&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356171 Stats: 556 lines in 272 files changed: 59 ins; 96 del; 401 mod Patch: https://git.openjdk.org/jdk/pull/25122.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25122/head:pull/25122 PR: https://git.openjdk.org/jdk/pull/25122 From stefank at openjdk.org Thu May 8 16:09:00 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 May 2025 16:09:00 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Thanks for tackling this! I look forward to the day when you change TIMEOUT_FACTOR to be 1 by default. I think that will reduce confusion. I made a cursory look through some GC files and I think that looked good. doc/testing.md line 385: > 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a > 384: certain amount of time will apply this factor. If we run in > 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) Maybe Suggestion: interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) ------------- PR Review: https://git.openjdk.org/jdk/pull/25122#pullrequestreview-2825661242 PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080028720 From dfuchs at openjdk.org Thu May 8 16:28:53 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 May 2025 16:28:53 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* @lkorinth have you run all the tiers where the old default timeout factor of 4 applied? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863633579 From lkorinth at openjdk.org Thu May 8 16:45:56 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 16:45:56 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Before this version, I had run tiers 1-8, with 11 fails. ** DONE 01 serviceability/jvmti/vthread/SuspendResume2/SuspendResume2.java#debug 700 ** DONE 02 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER ** DONE 03 tools/javac/util/IteratorsTest.java 480 ** DONE 04 java/math/BigInteger/LargeValueExceptions.java 480 ** DONE 05 vmTestbase/gc/gctests/WeakReference/weak004/weak004.java OTHER ** DONE 06 compiler/loopstripmining/CheckLoopStripMining.java OTHER ** DONE 07 sun/security/tools/keytool/fakecacerts/TrustedCert.java 480 ** DONE 08 jdk/internal/platform/docker/TestUseContainerSupport.java OTHER ** DONE 09 containers/docker/TestJFRNetworkEvents.java OTHER ** DONE 10 java/foreign/TestMismatch.java 480 ** DONE 11 linux-riscv64-open-cmp-baseline-linux-x64-build-796 OTHER Six of those seems not related to my changes (marked `OTHER`), five I have updated for this run with new timeout. I have fixed the timeouts and rebased (I had one conflict), and I am now again running tier1-8. It will take time, and it looks like I will have more (unrelated) fails this time. After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863670496 PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863675379 From erikj at openjdk.org Thu May 8 16:49:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 May 2025 16:49:56 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home [v2] In-Reply-To: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> References: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> Message-ID: <5hvhcOHTdPV7hRz1ZhY7koPnF8ChnnnK_6kQ8vy08IA=.7abcf5be-7f4e-4f50-ba03-47c58a62e583@github.com> On Wed, 7 May 2025 22:50:52 GMT, Magnus Ihse Bursie wrote: >> If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. >> >> The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fix-preinit-topdir > - Alternative solution > - 8351029: IncludeCustomExtension does not work on cygwin with source code below /home I think this looks ok, and better than the other solution. Should we add a comment somewhere describing what TOPDIR_ALT is and why it's needed for future archeologists? ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25100#pullrequestreview-2825771908 From erikj at openjdk.org Thu May 8 16:52:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 May 2025 16:52:58 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source [v2] In-Reply-To: References: Message-ID: <_yw46cNd17v7QiE6Ivw6-5B3s2GnEKbUnRxZb3zcBxk=.e90abc9d-ad25-4089-845a-91e4923a6990@github.com> On Wed, 7 May 2025 22:59:04 GMT, Magnus Ihse Bursie wrote: >> We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. >> >> (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Get rid of looped eval Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24449#pullrequestreview-2825780015 From erikj at openjdk.org Thu May 8 16:52:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 May 2025 16:52:59 GMT Subject: RFR: 8334391: JDK build should exclude *-files directories for Java source [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 22:52:09 GMT, Magnus Ihse Bursie wrote: >> make/common/JavaCompilation.gmk line 342: >> >>> 340: $1_SRCS_WITHOUT_ROOTS := $$($1_SRCS) >>> 341: $$(foreach i, $$($1_SRC), $$(eval $1_SRCS_WITHOUT_ROOTS := $$(patsubst \ >>> 342: $$i/%,%, $$($1_SRCS_WITHOUT_ROOTS)))) >> >> Using eval like this can sometimes have weird consequences. I would recommend rewriting this without eval. I think something like this should work. It may change the order of elements, but that shouldn't matter here. >> >> >> $1_SRCS_WITHOUT_ROOTS := $$(foreach i, $$($1_SRC), \ >> $$(patsubst $$i/%,%, $$(filter $$i/%, $$($1_SRCS)))) > > I agree that this looks a bit wonky. I just copied it from SetupNativeCompilation, since it has worked well there. It certainly works most of the time, but can have weird effects when there are `$` characters in strings and this deep into the implementation of a big macro I would prefer to avoid it if possible. I hope you verified that my version worked. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24449#discussion_r2080098636 From erikj at openjdk.org Thu May 8 16:55:02 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 8 May 2025 16:55:02 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2825782371 From lkorinth at openjdk.org Thu May 8 17:06:02 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 8 May 2025 17:06:02 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> References: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> Message-ID: On Thu, 8 May 2025 16:04:53 GMT, Stefan Karlsson wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > doc/testing.md line 385: > >> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >> 384: certain amount of time will apply this factor. If we run in >> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) > > Maybe > Suggestion: > > interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080117016 From dfuchs at openjdk.org Thu May 8 17:43:54 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 8 May 2025 17:43:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2863805648 From naoto at openjdk.org Thu May 8 19:01:55 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 8 May 2025 19:01:55 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24574#pullrequestreview-2826102855 From prr at openjdk.org Thu May 8 20:02:52 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 8 May 2025 20:02:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* test/jdk/java/awt/font/NumericShaper/MTTest.java - * @run main/timeout=300/othervm MTTest + * @run main/timeout=1200/othervm MTTest I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java So 300 was fine, and 1200 isn't needed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864133534 From serb at openjdk.org Thu May 8 21:12:32 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 8 May 2025 21:12:32 GMT Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS Message-ID: The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217 The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458 It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110). Now that the issue has been resolved, we can re-enable this warning. The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced. ------------- Commit messages: - 8356571: Re-enable -Wtype-limits for GCC in LCMS Changes: https://git.openjdk.org/jdk/pull/25127/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25127&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356571 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25127.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25127/head:pull/25127 PR: https://git.openjdk.org/jdk/pull/25127 From jwaters at openjdk.org Thu May 8 22:08:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 8 May 2025 22:08:52 GMT Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov wrote: > The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217 > The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458 > It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110). > > Now that the issue has been resolved, we can re-enable this warning. > > The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced. Marked as reviewed by jwaters (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25127#pullrequestreview-2826465217 From prr at openjdk.org Thu May 8 22:33:51 2025 From: prr at openjdk.org (Phil Race) Date: Thu, 8 May 2025 22:33:51 GMT Subject: RFR: 8356571: Re-enable -Wtype-limits for GCC in LCMS In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov wrote: > The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217 > The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458 > It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110). > > Now that the issue has been resolved, we can re-enable this warning. > > The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced. CI Linux build passes ------------- Marked as reviewed by prr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25127#pullrequestreview-2826493341 From lmesnik at openjdk.org Thu May 8 23:12:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 8 May 2025 23:12:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: <2nBGcIjZC03ee74o34IXFgtoEVTAkQV-xXEC28_oFbI=.da57d5a4-4546-4566-aa79-cacce01562d7@github.com> Message-ID: On Thu, 8 May 2025 17:03:03 GMT, Leo Korinth wrote: >> doc/testing.md line 385: >> >>> 383: (`-timeoutFactor`). Also, some test cases that programmatically wait a >>> 384: certain amount of time will apply this factor. If we run in >>> 385: interpreted mode (`-Xcomp`), [RunTest.gmk](../make/RunTests.gmk) >> >> Maybe >> Suggestion: >> >> interpreted mode (`-Xint`), [RunTest.gmk](../make/RunTests.gmk) > > Thanks for catching this fault of mine. I will update the text and change `interpreted mode`, as it is really `-Xcomp` we are looking at in the RunTest.gmk. yep, let use Xcomp, the Xint is not really supported, a lot of tests might start failing ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25122#discussion_r2080606853 From lmesnik at openjdk.org Fri May 9 00:55:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Fri, 9 May 2025 00:55:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <2oUdV1ca6y_cEHL3kTptk3jAlwCwnvsLGhRIAhVEUo8=.010c2226-c5ec-4508-be7f-90d244b2b7dc@github.com> On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. @lkorinth Can you please proposed fix for https://bugs.openjdk.org/browse/JDK-8260555 to make it more clear the complete goal of the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2864795990 From dholmes at openjdk.org Fri May 9 02:08:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 02:08:58 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:18:07 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Update release date > - Update --release 25 symbol information for JDK 25 build 21 > The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > > # Conflicts: > # test/langtools/tools/javac/versions/Versions.java > - feedback: never bump ASM version > - Update copyright years > > Note: any commit hashes below might be outdated due to subsequent > history rewriting (e.g. git rebase). > > + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 > + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 > + update src/java.compiler/share/classes/... Hotspot source and test changes look trivially good. ------------- PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2826771967 From serb at openjdk.org Fri May 9 02:10:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 9 May 2025 02:10:56 GMT Subject: Integrated: 8356571: Re-enable -Wtype-limits for GCC in LCMS In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:30:11 GMT, Sergey Bylokhov wrote: > The -Wtype-limits warning was previously disabled in the OpenJDK build for LCMS 2.14+ due to upstream issues: https://github.com/openjdk/jdk/pull/11217 > The issue was reported to the LCMS project: https://github.com/mm2/Little-CMS/issues/458 > It has since been fixed in LCMS 2.17 and integrated into OpenJDK as part of [JDK-8348110](https://bugs.openjdk.org/browse/JDK-8348110). > > Now that the issue has been resolved, we can re-enable this warning. > > The build works fine on the system where the initial [issue](https://github.com/openjdk/jdk/pull/11217) could be reproduced. This pull request has now been integrated. Changeset: 9a0e6f33 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/9a0e6f338f34fb5da16d5f9eb710cdddd4302945 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8356571: Re-enable -Wtype-limits for GCC in LCMS Reviewed-by: jwaters, prr ------------- PR: https://git.openjdk.org/jdk/pull/25127 From dholmes at openjdk.org Fri May 9 04:57:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 04:57:50 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* My biggest concern with this change is that potentially any test that implicitly uses the default timeout, and which passes with no problem with a factor of 4, may now need to have an explicit timeout set due to the factor of 1. I see this change in a number of tests (default timeout of 120s expressed as a new timeout of 480s to maintain equivalence**), but how many times did you run the tiers? I fear that the gatekeepers will be playing timeout whack-a-mole once these changes are put in. ** though another option would be to update the jtreg default timeout instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865099247 From dfuchs at openjdk.org Fri May 9 07:18:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 07:18:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 17:41:02 GMT, Daniel Fuchs wrote: > Thank you. I have imported your PR locally and running some HTTP client tests in the CI. > Tests have not finished running - but I already see one intermittent failure: > `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. > It would be good to flush out any such intermittent failures before this PR is integrated. > This might require multiple runs before we can get confidence. Results came back - another intermittent timeout failure (much more frequent) observed in: `java/net/httpclient/CancelledResponse.java` on macOS x64 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865413003 From cstein at openjdk.org Fri May 9 07:36:51 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 9 May 2025 07:36:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 04:54:52 GMT, David Holmes wrote: > [...] > ** though another option would be to update the jtreg default timeout instead. And affect all other tests, too? I'd rather let the default stay on the former hard-coded 120s value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865469908 From alanb at openjdk.org Fri May 9 08:12:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 08:12:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 16:43:10 GMT, Leo Korinth wrote: >> This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). >> >> The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. >> >> In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). >> >> My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. >> >> These fixes have been created when I have plown through testcases: >> JDK-8352719: Add an equals sign to the modules statement >> JDK-8352709: Remove bad timing annotations from WhileOpTest.java >> JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test >> CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE >> CODETOOLS-7903961: Make default timeout configurable >> >> Sometime in the future I will also fix: >> 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 >> >> for which I am awaiting: >> CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 >> >> *After the review I will revert the two first commits, and update the copyrights* > > After I revert the two first commits and go back to a timeout factor of 4, I will run tier 1-8 again. @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865581927 From lkorinth at openjdk.org Fri May 9 08:32:55 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 08:32:55 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* I feel almost all of the comments raised here are for me changing the timeout factor to `1`. I will try to answer those questions here as well, but note that the timeout factor is not to be changed to `1` in this pull request and will remain 4, so excluding bugs I might have introduced, tiers would --- if anything --- be running more stable after the change as I have only increased timeouts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865644966 From lkorinth at openjdk.org Fri May 9 08:42:58 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 08:42:58 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 07:14:11 GMT, Daniel Fuchs wrote: > Thank you. I have imported your PR locally and running some HTTP client tests in the CI. Tests have not finished running - but I already see one intermittent failure: `java/net/httpclient/RedirectTimeoutTest.java` is timing out intermittently on windows. It would be good to flush out any such intermittent failures before this PR is integrated. This might require multiple runs before we can get confidence. My change of timeout factor to `0.7` is only temporal, as I said: it will be reverted to `4` before integration. Naturally, a few test cases will timeout when I do this /temporal/ change, hopefully `java/net/httpclient/RedirectTimeoutTest.java` will behave well with a timeout factor of `1` instead of `0.7`, but note that I will revert the timeout factor to `4` before integration. The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865685066 From stefank at openjdk.org Fri May 9 08:48:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 May 2025 08:48:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote: > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865697701 From lkorinth at openjdk.org Fri May 9 09:02:55 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:02:55 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> On Thu, 8 May 2025 20:00:21 GMT, Phil Race wrote: > test/jdk/java/awt/font/NumericShaper/MTTest.java > > * * @run main/timeout=300/othervm MTTest > > > * * @run main/timeout=1200/othervm MTTest > > > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. > > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java > > So 300 was fine, and 1200 isn't needed. I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865742871 From ihse at openjdk.org Fri May 9 09:09:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:09:02 GMT Subject: RFR: 8301971: Make JDK source code UTF-8 [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 10:19:31 GMT, Magnus Ihse Bursie wrote: >> Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. >> >> The fix is basically simple, and includes the following steps: >> * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already >> * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into go-full-utf8 > - Merge branch 'master' into go-full-utf8 > - Add informative message about supported locales. > - Allow C locale with warning instead of fatal error > - Also document UTF-8 requirements (solves JDK-8338973) > - Let configure only accept utf-8 locales > - Address review comments from Kim > - Also tell javadoc that we have utf-8 now > - Fix flags for Windows > - Mark java and native source code as utf-8 > - ... and 4 more: https://git.openjdk.org/jdk/compare/2c1eb339...e68305db It seems to be difficult to find someone to get this tested on a Chinese locale on Windows. I'll integrate this, and handle any problems that might arise as followups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24574#issuecomment-2865761193 From ihse at openjdk.org Fri May 9 09:09:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:09:03 GMT Subject: Integrated: 8301971: Make JDK source code UTF-8 In-Reply-To: References: Message-ID: <1fDziF7qdWQ1gvZZ2pPh0MYEqRKAS0w3lPQbuYVUOa0=.f9283dc7-b8a0-4bfc-8dd5-4d124b225aa1@github.com> On Thu, 10 Apr 2025 14:28:02 GMT, Magnus Ihse Bursie wrote: > Most of the JDK code base has been transitioned to UTF-8, but not all. This has recently become an acute problem, since our mixing of iso-8859-1 and utf-8 in properties files confused the version of `sed` that is shipped with the new macOS 15.4. > > The fix is basically simple, and includes the following steps: > * Look through the code base for text files containing non-ASCII characters, and convert them to UTF-8, if they are not already > * Update tooling used in building to recognize the fact that files are now in UTF-8 and treat them accordingly (basically, updating compiler flags, git attributes, etc). This pull request has now been integrated. Changeset: 3aa2ea7e Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/3aa2ea7e67c879dafa0f967073c2d8b98d62c996 Stats: 177 lines in 13 files changed: 49 ins; 105 del; 23 mod 8301971: Make JDK source code UTF-8 8338973: Document need to have UTF-8 locale available to build the JDK Reviewed-by: erikj, naoto, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/24574 From lkorinth at openjdk.org Fri May 9 09:12:19 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:12:19 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> Message-ID: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth wrote: >> test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> - * @run main/timeout=300/othervm MTTest >> + * @run main/timeout=1200/othervm MTTest >> >> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. >> >> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> So 300 was fine, and 1200 isn't needed. > >> test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> * * @run main/timeout=300/othervm MTTest >> >> >> * * @run main/timeout=1200/othervm MTTest >> >> >> I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. >> >> https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java >> >> So 300 was fine, and 1200 isn't needed. > > I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? > @lkorinth Moving to a TIMEOUT_FACTOR of 1 seems a good goal. Would it be possible to expand a bit on what repeat testing was done to identify the tests to add /timeout ? If I read it correctly, any tests using /timeout=N have been to bumped to 4*N so no change if the scaling is adjusted in the future. Most tests don't use /timeout so I assume many runs were done to identify the tests that would timeout with if there was no scaling. Test machines vary, as does the test execution times when running concurrently with other tests, so I think it would help if you could say a bit more, even to confirm that it was many test runs. The code was run as it currently looks (with a timeout factor of `0.7`), what timeout factor do you think I should use to test, and for how many times? At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to `1` will happen after the fork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865784064 From ihse at openjdk.org Fri May 9 09:12:28 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:12:28 GMT Subject: RFR: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home [v2] In-Reply-To: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> References: <-Hh5hlwe0eHzJfvPDgh0HXFe5u6yVdpvA85PPbAuM5k=.4cbf8fc5-83d6-4bec-b581-9aea653115dc@github.com> Message-ID: On Wed, 7 May 2025 22:50:52 GMT, Magnus Ihse Bursie wrote: >> If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. >> >> The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'master' into fix-preinit-topdir > - Alternative solution > - 8351029: IncludeCustomExtension does not work on cygwin with source code below /home There are no obvious place where to put that comment, and I don't want to sprinkle the code with comments about it everwhere it is used. I'd say that those future archaeologists will have to use `git blame` to find this PR, if it is not clear to them how the variable is used... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25100#issuecomment-2865783097 From ihse at openjdk.org Fri May 9 09:12:30 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 09:12:30 GMT Subject: Integrated: 8351029: IncludeCustomExtension does not work on cygwin with source code below /home In-Reply-To: References: Message-ID: On Wed, 7 May 2025 15:08:53 GMT, Magnus Ihse Bursie wrote: > If you check out your source code in Cygwin, somewhere under /home/... (as opposed to /cygpath/...), IncludeCustomExtension does not work. > > The problem is that TOPDIR gets a different lexical value from the spec.gmk file when setup in Makefile, even if this was the same directory. Since THIS_INCLUDE is calculated as a relative path by string substitution of $(TOPDIR), the path failed to relativize correctly. This pull request has now been integrated. Changeset: a091e2f2 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a091e2f2810da17ff61a63fd0f1f6538f1bdbb70 Stats: 12 lines in 4 files changed: 1 ins; 0 del; 11 mod 8351029: IncludeCustomExtension does not work on cygwin with source code below /home Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25100 From cstein at openjdk.org Fri May 9 09:15:51 2025 From: cstein at openjdk.org (Christian Stein) Date: Fri, 9 May 2025 09:15:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> <3-AQ92Sgr9tDJIWDO5OX43uBDLndiDN_3jyRj5t2z6Q=.af7cef0d-c447-4401-b4e0-e11a9bdba35b@github.com> Message-ID: On Fri, 9 May 2025 09:09:34 GMT, Leo Korinth wrote: > At the moment I am awaiting jtreg 7.6, I therefore guess the timeout factor change to 1 will happen after the fork. Note, that I moved the timeout configuration feature to `jtreg` 7.5.2 - which will be released soon. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865793769 From lkorinth at openjdk.org Fri May 9 09:15:52 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 09:15:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> References: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> Message-ID: On Fri, 9 May 2025 08:45:48 GMT, Stefan Karlsson wrote: > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. > > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865794195 From stefank at openjdk.org Fri May 9 09:19:51 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 May 2025 09:19:51 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: <1Sa3h-gkyVwOLDdj_wJdFohAGYbhYhbAYIaqHCmW7oY=.3b58c23d-cf55-421b-aeec-e149809826f2@github.com> Message-ID: On Fri, 9 May 2025 09:13:41 GMT, Leo Korinth wrote: > > > My change of timeout factor to 0.7 is only temporal, as I said: it will be reverted to 4 before integration. > > > > > > Is really worth reverting back to 4 instead of trying to get jtreg released with CODETOOLS-7903961 and then integrate this change with a timeout factor of 1? > > I think it is worth doing in two steps. First I do not want to postpone these limited changes, and second if I would have problems with JDK-8260555, it would be nice if those changes would be smaller and easier to revert. I understand the risk of being blocked on JDK-8260555, but frankly, if someone wants to block the change from 4 to 1 I'm not sure this PR is worth doing. We have enough groups represented in this PR so let's ask here: is anyone is opposing the idea of JDK-8260555? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865804474 From dfuchs at openjdk.org Fri May 9 09:33:52 2025 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Fri, 9 May 2025 09:33:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Fri, 9 May 2025 08:40:44 GMT, Leo Korinth wrote: > The whole idea of running with a timeout factor of `0.7` is to remove intermittent failures. (I had it close to 0.5 or maybe less to begin with until I found and reported CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE) Yes - I understand. My point is that there are probably more tests that will need an extended timeout than those that you have already modified. And we want to find out which before the actual change from 4 to 1.0. IMO if a test fails intermittently with 0.7, it's a good indication that it might continue failling intermittently with 1.0, and therefore it should be updated in this PR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2865849069 From ihse at openjdk.org Fri May 9 10:07:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 10:07:59 GMT Subject: Integrated: 8334391: JDK build should exclude *-files directories for Java source In-Reply-To: References: Message-ID: On Fri, 4 Apr 2025 14:44:07 GMT, Magnus Ihse Bursie wrote: > We should always exclude `doc-files` and `snippet-files` when compiling java code. To generalize this, exclude all `*-files` directories. > > (The usage of EXCLUDES and EXCLUDE_FILES is a bit weird. In essence, EXCLUDE_FILES prepends a `%` wildchar match to the filenames given, which we use here, while EXCLUDES matches only strict directory names in the path. These should probably be clarified/redesigned for more intuitive exclusion.) This pull request has now been integrated. Changeset: 568dcc15 Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/568dcc15cb1a2c02d6ac4421902d841d256ca1c2 Stats: 39 lines in 8 files changed: 17 ins; 18 del; 4 mod 8334391: JDK build should exclude *-files directories for Java source Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24449 From dholmes at openjdk.org Fri May 9 12:21:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 12:21:54 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: <3CKLh1TDhqMNxlWyINFVMAI6MGe_s2rJrgnfzXYpx2M=.ab9a5cb5-9671-4b90-ba81-83f65b82cd6d@github.com> On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* I saw this PR as preparation for the change of the timeout factor so they could be reviewed distinctly and then integrated close together. So it is natural that people are querying how the proposed changes will work with that change - in particular if it will require explicit timeouts to be added to a lot of tests that don't presently have them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866338479 From lkorinth at openjdk.org Fri May 9 12:51:52 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 12:51:52 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Every time I rerun the tests, some new testcase fails on timeouts. Even worse is that I get quite a few /totally unrelated/ test failures every time because I am running 8 tiers. I could probably change the timeout factor to 0.6 to weed out some more tests faster, but I can not use a timeout factor of 0.5 or less because of CODETOOLS-7903937. Every 0.1 percent corresponds to 12 seconds. So in absolute measurements I have a margin of 36 seconds now if I would go to a timeout factor of 1. I am also a bit afraid of having too big of a margin --- it will force me to convert possible huge amount of new test cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866421573 From lkorinth at openjdk.org Fri May 9 13:06:01 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Fri, 9 May 2025 13:06:01 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* Changing the timeout factor might be preferable to do after the fork. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2866463008 From ihse at openjdk.org Fri May 9 14:10:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 14:10:03 GMT Subject: RFR: 8347570: Configure fails on macOS if directory name do not have correct case Message-ID: If you have a directory `OpenJDK` and do `cd openjdk`, this will register the current directory as `openjdk`, not `OpenJDK`. This will later on make the check in configure to see if we are in the root directory (to determine where to put the configuration) will fail, since it does a case-sensitive comparison. ------------- Commit messages: - 8347570: Configure fails on macOS if directory name do not have correct case Changes: https://git.openjdk.org/jdk/pull/25146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8347570 Stats: 21 lines in 1 file changed: 16 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25146/head:pull/25146 PR: https://git.openjdk.org/jdk/pull/25146 From ccheung at openjdk.org Fri May 9 17:28:01 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 9 May 2025 17:28:01 GMT Subject: RFR: 8356229: cmp-baseline build fail due to lib/modules difference Message-ID: The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. Tested by running the cmp-baseline builds on various platforms. ------------- Commit messages: - 8356229: cmp-baseline build fail due to lib/modules difference Changes: https://git.openjdk.org/jdk/pull/25154/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25154&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356229 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25154.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25154/head:pull/25154 PR: https://git.openjdk.org/jdk/pull/25154 From iklam at openjdk.org Fri May 9 17:39:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 17:39:50 GMT Subject: RFR: 8356229: cmp-baseline build fail due to lib/modules difference In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:22:41 GMT, Calvin Cheung wrote: > The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. > A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. > > Tested by running the cmp-baseline builds on various platforms. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25154#pullrequestreview-2829187086 From ihse at openjdk.org Fri May 9 17:45:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 17:45:36 GMT Subject: RFR: 8347570: Configure fails on macOS if directory name do not have correct case [v2] In-Reply-To: References: Message-ID: > If you have a directory `OpenJDK` and do `cd openjdk`, this will register the current directory as `openjdk`, not `OpenJDK`. This will later on make the check in configure to see if we are in the root directory (to determine where to put the configuration) will fail, since it does a case-sensitive comparison. Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: Use tr instead of variable substitution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25146/files - new: https://git.openjdk.org/jdk/pull/25146/files/056e53e9..d44bb8b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25146&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25146&range=00-01 Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25146/head:pull/25146 PR: https://git.openjdk.org/jdk/pull/25146 From ihse at openjdk.org Fri May 9 17:45:36 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 9 May 2025 17:45:36 GMT Subject: RFR: 8347570: Configure fails on macOS if directory name do not have correct case In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:05:36 GMT, Magnus Ihse Bursie wrote: > If you have a directory `OpenJDK` and do `cd openjdk`, this will register the current directory as `openjdk`, not `OpenJDK`. This will later on make the check in configure to see if we are in the root directory (to determine where to put the configuration) will fail, since it does a case-sensitive comparison. The variable substitution did not work on the bash installed on the GHA macs... I did not know that it was not universally supported. *sigh* ------------- PR Comment: https://git.openjdk.org/jdk/pull/25146#issuecomment-2867014546 From erikj at openjdk.org Fri May 9 18:05:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 May 2025 18:05:56 GMT Subject: RFR: 8356229: cmp-baseline build fail due to lib/modules difference In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:22:41 GMT, Calvin Cheung wrote: > The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. > A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. > > Tested by running the cmp-baseline builds on various platforms. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25154#pullrequestreview-2829297721 From erikj at openjdk.org Fri May 9 18:08:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 9 May 2025 18:08:53 GMT Subject: RFR: 8347570: Configure fails on macOS if directory name do not have correct case [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:45:36 GMT, Magnus Ihse Bursie wrote: >> If you have a directory `OpenJDK` and do `cd openjdk`, this will register the current directory as `openjdk`, not `OpenJDK`. This will later on make the check in configure to see if we are in the root directory (to determine where to put the configuration) will fail, since it does a case-sensitive comparison. > > Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision: > > Use tr instead of variable substitution Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25146#pullrequestreview-2829303278 From liach at openjdk.org Fri May 9 18:12:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 18:12:50 GMT Subject: RFR: 8356229: cmp-baseline build fail due to lib/modules difference In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:22:41 GMT, Calvin Cheung wrote: > The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. > A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. > > Tested by running the cmp-baseline builds on various platforms. Let's integrate this before #25136. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25154#pullrequestreview-2829309775 From ccheung at openjdk.org Fri May 9 18:25:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 9 May 2025 18:25:55 GMT Subject: RFR: 8356229: cmp-baseline build fail due to lib/modules difference In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:37:04 GMT, Ioi Lam wrote: >> The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. >> A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. >> >> Tested by running the cmp-baseline builds on various platforms. > > LGTM Thanks @iklam @erikj79 @liach for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25154#issuecomment-2867544307 From ccheung at openjdk.org Fri May 9 18:25:56 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 9 May 2025 18:25:56 GMT Subject: Integrated: 8356229: cmp-baseline build fail due to lib/modules difference In-Reply-To: References: Message-ID: On Fri, 9 May 2025 17:22:41 GMT, Calvin Cheung wrote: > The fix for [JDK-8327495](https://bugs.openjdk.org/browse/JDK-8327495) logs more CDS error by default. The error gets printed into the `support/link_opt/default_jli_trace.txt` file which interferes with the cmp-baseline build. > A fix is to specify the `-Xlog:cds=off` to suppress the error message during the building of the $(CLASSLIST_FILE) target. > > Tested by running the cmp-baseline builds on various platforms. This pull request has now been integrated. Changeset: 3b20bed6 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/3b20bed6e2599fbddb16b75c06ee55637dd6836f Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod 8356229: cmp-baseline build fail due to lib/modules difference Reviewed-by: iklam, erikj, liach ------------- PR: https://git.openjdk.org/jdk/pull/25154 From prr at openjdk.org Fri May 9 19:24:53 2025 From: prr at openjdk.org (Phil Race) Date: Fri, 9 May 2025 19:24:53 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> References: <0AKC-4omm-W24u11ifhGm8Do8_5sqwPMJz6q3A71FNE=.f4209d38-51d6-4eda-b11e-d670e5ee5575@github.com> Message-ID: On Fri, 9 May 2025 08:58:15 GMT, Leo Korinth wrote: > > test/jdk/java/awt/font/NumericShaper/MTTest.java > > ``` > > * * @run main/timeout=300/othervm MTTest > > > > > > * * @run main/timeout=1200/othervm MTTest > > ``` > > > > > > > > > > > > > > > > > > > > > > > > I'm puzzling over why you saw this test fail with timeout = 300 .. or perhaps you saw it fail with 0.7 ? Which would amount to 210 seconds .. that might just be enough to cause it to fail because if you look at the whole test you'll see it wants the core loops of the test to run for 180 seconds. > > https://openjdk.github.io/cr/?repo=jdk&pr=25122&range=00#new-144-test/jdk/java/awt/font/NumericShaper/MTTest.java > > So 300 was fine, and 1200 isn't needed. > > I started with a timeout factor less than `0.7` but I got hindered by CODETOOLS-7903937. That is probably the reason. Maybe I should change the timeout to 400? I think it is reasonable to handle a timeout factor somewhat less than 1 to weed out tight test cases. But maybe 300 is good enough? I think 300 is correct for this test. Setting the timeout factor to < 1 is an interesting experiment but I don't think tests that timeout in such a case are automatic candidates to have an increased time out and this one shows why. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2867676176 From mikael at openjdk.org Fri May 9 22:44:03 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 9 May 2025 22:44:03 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js Message-ID: The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). Testing: tier1,builds-tier[2-5] ------------- Commit messages: - 8356656: Drop unused DEVKIT_HOME from jib-profiles.js Changes: https://git.openjdk.org/jdk/pull/25159/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25159&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356656 Stats: 18 lines in 3 files changed: 14 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25159/head:pull/25159 PR: https://git.openjdk.org/jdk/pull/25159 From mikael at openjdk.org Fri May 9 22:46:59 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Fri, 9 May 2025 22:46:59 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles Message-ID: The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. Testing: tier1,builds-tier[2-5] ------------- Commit messages: - 8356657: Use stable source-date for cmp-baseline jib profiles Changes: https://git.openjdk.org/jdk/pull/25160/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25160&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356657 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25160.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25160/head:pull/25160 PR: https://git.openjdk.org/jdk/pull/25160 From liach at openjdk.org Fri May 9 23:02:50 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 23:02:50 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] Let's fix our builds! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25160#pullrequestreview-2829846817 From iris at openjdk.org Fri May 9 23:06:50 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 9 May 2025 23:06:50 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25160#pullrequestreview-2829853545 From alanb at openjdk.org Sat May 10 06:39:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 10 May 2025 06:39:50 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: <4jcudFIpD5xXLhcxxkqthqnbm5WBmK5eHqOChqYwXS8=.fbd3ba4a-b807-42e8-b522-5c2713fef5c2@github.com> On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] This looks okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25160#pullrequestreview-2830433801 From liach at openjdk.org Sat May 10 14:34:57 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 10 May 2025 14:34:57 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 17:19:11 GMT, Joe Darcy wrote: >> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. > >> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. > > Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. See #25124. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083210454 From nbenalla at openjdk.org Sat May 10 15:44:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sat, 10 May 2025 15:44:51 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 14:32:10 GMT, Chen Liang wrote: >>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. >> >> Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. > > See #25124. Thanks Chen! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083223695 From kbarrett at openjdk.org Sat May 10 22:50:01 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Sat, 10 May 2025 22:50:01 GMT Subject: RFR: 8356686: doc/building.html is not up to date after JDK-8301971 Message-ID: Please review this change to doc/building.html. The change is the result of using `make update-build-docs` to regenerate it from the current building.md file. ------------- Commit messages: - use update-build-docs result Changes: https://git.openjdk.org/jdk/pull/25168/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25168&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356686 Stats: 13 lines in 1 file changed: 5 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25168.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25168/head:pull/25168 PR: https://git.openjdk.org/jdk/pull/25168 From jpai at openjdk.org Mon May 12 01:25:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 May 2025 01:25:54 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25160#pullrequestreview-2831601176 From jwaters at openjdk.org Mon May 12 06:48:52 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 12 May 2025 06:48:52 GMT Subject: RFR: 8356686: doc/building.html is not up to date after JDK-8301971 In-Reply-To: References: Message-ID: On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote: > Please review this change to doc/building.html. The change is the result of > using `make update-build-docs` to regenerate it from the current building.md > file. Looks good ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/25168#pullrequestreview-2831998939 From shade at openjdk.org Mon May 12 08:15:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 12 May 2025 08:15:54 GMT Subject: RFR: 8356686: doc/building.html is not up to date after JDK-8301971 In-Reply-To: References: Message-ID: <5CvyJtcwX5xlMbWELzfDCvbDa1gsHmL-npEEA2JsxQo=.6cdc72f7-20c3-4917-8947-82764a920999@github.com> On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote: > Please review this change to doc/building.html. The change is the result of > using `make update-build-docs` to regenerate it from the current building.md > file. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25168#pullrequestreview-2832249678 From erikj at openjdk.org Mon May 12 13:33:54 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 13:33:54 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:39:18 GMT, Mikael Vidstedt wrote: > The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). > > Testing: tier1,builds-tier[2-5] Looks like you accidentally added some extra files. ------------- Changes requested by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25159#pullrequestreview-2833240186 From erikj at openjdk.org Mon May 12 13:34:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 13:34:53 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25160#pullrequestreview-2833244656 From erikj at openjdk.org Mon May 12 13:35:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 13:35:56 GMT Subject: RFR: 8356686: doc/building.html is not up to date after JDK-8301971 In-Reply-To: References: Message-ID: On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote: > Please review this change to doc/building.html. The change is the result of > using `make update-build-docs` to regenerate it from the current building.md > file. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25168#pullrequestreview-2833247332 From mikael at openjdk.org Mon May 12 15:09:10 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 15:09:10 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js [v2] In-Reply-To: References: Message-ID: > The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). > > Testing: tier1,builds-tier[2-5] Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: Remove accidentally added server.log files ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25159/files - new: https://git.openjdk.org/jdk/pull/25159/files/63ffcfc5..df72d5be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25159&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25159&range=00-01 Stats: 14 lines in 2 files changed: 0 ins; 14 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25159.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25159/head:pull/25159 PR: https://git.openjdk.org/jdk/pull/25159 From mikael at openjdk.org Mon May 12 15:09:11 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 15:09:11 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:39:18 GMT, Mikael Vidstedt wrote: > The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). > > Testing: tier1,builds-tier[2-5] Oops, now removed! (I believe the make/server.log files have started showing up when running cmp-baseline, I should look into why) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25159#issuecomment-2872954817 From kvn at openjdk.org Mon May 12 16:14:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 16:14:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov wrote: >> 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 incrementally with one additional commit since the last revision: > > Address review comments Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833790759 From erikj at openjdk.org Mon May 12 16:24:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 16:24:52 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:09:10 GMT, Mikael Vidstedt wrote: >> The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). >> >> Testing: tier1,builds-tier[2-5] > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Remove accidentally added server.log files Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25159#pullrequestreview-2833814711 From mikael at openjdk.org Mon May 12 16:34:00 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 16:34:00 GMT Subject: RFR: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25160#issuecomment-2873229727 From mikael at openjdk.org Mon May 12 16:34:01 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 16:34:01 GMT Subject: RFR: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:09:10 GMT, Mikael Vidstedt wrote: >> The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). >> >> Testing: tier1,builds-tier[2-5] > > Mikael Vidstedt has updated the pull request incrementally with one additional commit since the last revision: > > Remove accidentally added server.log files Thank you for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25159#issuecomment-2873230233 From mikael at openjdk.org Mon May 12 16:34:00 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 16:34:00 GMT Subject: Integrated: 8356657: Use stable source-date for cmp-baseline jib profiles In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:41:09 GMT, Mikael Vidstedt wrote: > The cmp-baseline builds expect the source-date to be stable across the two builds (really: invocations of configure). For CI builds the source-date gets set based on information from the job, but for local builds it gets the default "current" value which will not be the same for the two builds. > > While it's possible to override this on the command line it would be more user friendly to have jib provide a stable source-date instead. > > Testing: tier1,builds-tier[2-5] This pull request has now been integrated. Changeset: e4638954 Author: Mikael Vidstedt URL: https://git.openjdk.org/jdk/commit/e4638954284a5e0592c27421ca53df0002bd0845 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8356657: Use stable source-date for cmp-baseline jib profiles Reviewed-by: liach, iris, alanb, jpai, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25160 From mikael at openjdk.org Mon May 12 16:34:01 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Mon, 12 May 2025 16:34:01 GMT Subject: Integrated: 8356656: Drop unused DEVKIT_HOME from jib-profiles.js In-Reply-To: References: Message-ID: On Fri, 9 May 2025 22:39:18 GMT, Mikael Vidstedt wrote: > The DEVKIT_HOME environment variable gets set up in jib-profiles.js but the last use of it was removed in [JDK-8264805](https://bugs.openjdk.org/browse/JDK-8264805). > > Testing: tier1,builds-tier[2-5] This pull request has now been integrated. Changeset: 50dced88 Author: Mikael Vidstedt URL: https://git.openjdk.org/jdk/commit/50dced88ff1aed23bb4c8fe9e4a08e6cc200b897 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod 8356656: Drop unused DEVKIT_HOME from jib-profiles.js Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25159 From iklam at openjdk.org Mon May 12 17:20:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 17:20:56 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov wrote: >> 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 incrementally with one additional commit since the last revision: > > Address review comments LGTM. Small nits about logging and testing. src/hotspot/share/cds/filemap.cpp line 1955: > 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, > 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); > 1955: return false; The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833939411 PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085115469 From jiangli at openjdk.org Mon May 12 18:00:29 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 18:00:29 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v2] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Experiment based on magicus comment: - Add build-linux-x64 to 'needs' in test-linux-x64-static. - Remove product-bundles test-bundles from build-linux-x64-static. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/5306dac3..498acd39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From jiangli at openjdk.org Mon May 12 18:48:17 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 18:48:17 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v3] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. - Merge branch 'master' into JDK-8355452 - Experiment based on magicus comment: - Add build-linux-x64 to 'needs' in test-linux-x64-static. - Remove product-bundles test-bundles from build-linux-x64-static. - Fix typo. - Export static-problemlist-path in 'path' step. - Remove inputs.static-suffix check when notify test failure. - Replace $(pwd) with `pwd` to form the path to static JDK problemlist. - Use different id fot test on static. Add step to notify failures on static JDK. - - Change run-tests-on-static id to run-tests id. - Remove extra '-' before '-static' in artifact_name. - Don't set debug-suffix for static test job, since that causes incorrect bundle name used. - ... and 17 more: https://git.openjdk.org/jdk/compare/c51ee97a...a472463a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/498acd39..a472463a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=01-02 Stats: 41955 lines in 1370 files changed: 28518 ins; 7475 del; 5962 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From iveresov at openjdk.org Mon May 12 19:29:18 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 12 May 2025 19:29:18 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v15] In-Reply-To: References: Message-ID: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> > 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 45 commits: - Merge branch 'master' into pp2 - Address review comments - Merge branch 'master' into pp2 - Fix compile - Fix additional issues - Make sure command line flags that affect MDO layout are consistent - Fix semantics change from the previous commit - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type - Fix flag behavior - Fix log tags - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14 Stats: 3226 lines in 59 files changed: 3011 ins; 100 del; 115 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 From heidinga at openjdk.org Mon May 12 20:05:55 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 12 May 2025 20:05:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v15] In-Reply-To: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> References: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> Message-ID: <931WapeeMqp8gbb720PmF0inR4k_kD9CL9UL9SGDyWY=.2406d164-dc7e-49ce-9e26-78f0a7f3f9e6@github.com> On Mon, 12 May 2025 19:29:18 GMT, Igor Veresov wrote: >> 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 45 commits: > > - Merge branch 'master' into pp2 > - Address review comments > - Merge branch 'master' into pp2 > - Fix compile > - Fix additional issues > - Make sure command line flags that affect MDO layout are consistent > - Fix semantics change from the previous commit > - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type > - Fix flag behavior > - Fix log tags > - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887 src/hotspot/share/cds/filemap.hpp line 120: > 118: bool _compressed_class_ptrs; // save the flag UseCompressedClassPointers > 119: int _narrow_klass_pointer_bits; // save number of bits in narrowKlass > 120: int _narrow_klass_shift; // save shift width used to pre-compute narrowKlass IDs in archived heap objectsa Suggestion: int _narrow_klass_shift; // save shift width used to pre-compute narrowKlass IDs in archived heap objects Minor typo, don't bother fixing if it will result in a re-review cycle ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085360465 From jiangli at openjdk.org Mon May 12 20:41:12 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 20:41:12 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v4] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add separate download-static-bundles. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/a472463a..dff580a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=02-03 Stats: 11 lines in 1 file changed: 9 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From iklam at openjdk.org Mon May 12 21:17:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:17:10 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: References: Message-ID: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - Use one-step training by default in AOT testing - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java - @vnkozlov comments - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS - Remove %t restriction - Added %p substitution; clean up - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04 Stats: 1893 lines in 22 files changed: 1387 ins; 456 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iveresov at openjdk.org Mon May 12 21:30:12 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 12 May 2025 21:30:12 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v16] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Make the test permute through default flag values too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/ae332887..d75cb5dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14-15 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 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 From iklam at openjdk.org Mon May 12 21:35:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:35:52 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e Per suggestion by @katyapav , I've updated RunTests.gmk to use the new "one step training" when creating the AOT cache for running jtreg test cases. `twostep` is the old behavior. E.g.: make test JTREG=AOT_JDK=onestep TEST=open/test/hotspot/jtreg/runtime/invokedynamic make test JTREG=AOT_JDK=twostep TEST=open/test/hotspot/jtreg/runtime/invokedynamic Also, for the existing CDS jtreg tests that use CDSAppTester, the default testing mode is to use "one step training" for creating the AOT cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2874205674 From erikj at openjdk.org Mon May 12 21:43:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 21:43:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: <8FryhUnn09RpstrSVIOwKLTPBwgh3HzS50dY2cMct5w=.b9e0840e-e585-4178-bd41-f19db4a6a016@github.com> On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e This change in functionality for the `JTREG=AOT_JDK` makefile argument should probably be mentioned somewhere in `doc/testing.md`. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834697107 From jiangli at openjdk.org Mon May 12 22:28:29 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 22:28:29 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/dff580a3..ed292625 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From epavlova at openjdk.org Mon May 12 23:24:04 2025 From: epavlova at openjdk.org (Ekaterina Pavlova) Date: Mon, 12 May 2025 23:24:04 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e make/RunTests.gmk changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834836628 From iklam at openjdk.org Tue May 13 00:01:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 00:01:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v6] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Allow one-step training even when -XX:AOTMode=auto is specified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/b044953e..f33d5994 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04-05 Stats: 81 lines in 3 files changed: 62 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From jiangli at openjdk.org Tue May 13 01:01:04 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 13 May 2025 01:01:04 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:55:54 GMT, Magnus Ihse Bursie wrote: >> Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: >> >> Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > > .github/workflows/main.yml line 367: > >> 365: name: linux-x64-static >> 366: needs: >> 367: - build-linux-x64-static > > Just thinking out loud here, what if you also added ` build-linux-x64` to the `needs` list. I guess that would make sure the test bundle is built before trying to execute this. Then the trick will just be to get both the test bundle and the static-jdk bundle downloaded... @magicus I looked into this today. Adding `build-linux-x64` to the `needs` list for `test-linux-x64-static` works with additonal changes in .github/actions/get-bundles/action.yml to download the static bundle separately. I added a `download-static-bundles` step for the static bundle. With this, I was able to only build the `static-jdk-bundles` without `product-bundles test-bundles` in `build-linux-x64-static` job, as your other suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2085744124 From jiangli at openjdk.org Tue May 13 01:18:58 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 13 May 2025 01:18:58 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 20:59:08 GMT, Jiangli Zhou wrote: >> .github/workflows/main.yml line 234: >> >>> 232: with: >>> 233: platform: linux-x64 >>> 234: make-target: 'product-bundles test-bundles static-jdk-bundles' >> >> This will make us build the tests and the normal JDK twice, once here and once for the normal build-linux-x64 target. That seems like a useless waste of time and computing resources. There must be a better way of doing this. > > I haven't tried, but I think it's possible to not requiring building `product-bundles`. The `product-bundles` (regular JDK) is used for compiling the test java sources. I think it's possible to use the boot JDK. I'll try that. I removed `product-bundles test-bundles` as suggested. Thanks. With your other suggestion to add `build-linux-x64` to the `needs` list for `test-linux-x64-static`, I didn't have to change to use the boot JDK for compiling the test java sources, since we download the bundles from the `build-linux-x64` as well and have a regular JDK. `JDK_FOR_COMPILE` is still set to `${{ steps.bundles.outputs.jdk-path }}`. That's actually better than using the boot JDK for `JDK_FOR_COMPILE`, since tests may use tools from the `-Dcompile.jdk` specified path. The boot JDK is not built from the current source, and using tools from the boot JDK may cause unexpected results. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2085755003 From cito at openjdk.org Tue May 13 01:22:47 2025 From: cito at openjdk.org (Chihiro Ito) Date: Tue, 13 May 2025 01:22:47 GMT Subject: RFR: 8356820: fixpath should allow + in paths on Windows Message-ID: When we run configure on Windows, fixpath is used, but this causes an error if the path contains +. For example, when we unzip Temurin 24, the directory name created is jdk-24+36. When we specify this as the boot JDK, the following error is output and configure fails configure: The path of BOOT_JDK_ARG, which is given as ?/mnt/d/opt/jdks/temurin-24+36?, cannot be properly resolved. configure: Please see the section ?Special Considerations? in building.md. configure: This is the error message given by fixpath: fixpath: failure: Path '/mnt/d/opt/jdks/temurin-24+36' could not be converted to short path configure: error: Cannot continue ------------- Commit messages: - 8356820: fixpath should allow + in paths on Windows Changes: https://git.openjdk.org/jdk/pull/25197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356820 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25197/head:pull/25197 PR: https://git.openjdk.org/jdk/pull/25197 From iklam at openjdk.org Tue May 13 03:06:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 03:06:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added param to makefile function SetupAOT for choosing onestep vs twostep ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/f33d5994..3cc2cb3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05-06 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iveresov at openjdk.org Tue May 13 03:31:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 03:31:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v17] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Update src/hotspot/share/cds/filemap.hpp Co-authored-by: Dan Heidinga ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/d75cb5dc..da4a3420 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 From iveresov at openjdk.org Tue May 13 03:34:54 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 03:34:54 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:13:55 GMT, Ioi Lam wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/hotspot/share/cds/filemap.cpp line 1955: > >> 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, >> 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); >> 1955: return false; > > The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) > > Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085858973 From iklam at openjdk.org Tue May 13 07:45:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 07:45:07 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:32:13 GMT, Igor Veresov wrote: >> src/hotspot/share/cds/filemap.cpp line 1955: >> >>> 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, >>> 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); >>> 1955: return false; >> >> The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) >> >> Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. > > Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? You can leave the existing code and just fix the new code you added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2086143903 From jpai at openjdk.org Tue May 13 12:05:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 May 2025 12:05:19 GMT Subject: RFR: 8327466: ct.sym zip not reproducible across build environment timezones Message-ID: Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466. Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output. The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries. Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp. The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument. The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix. I have run this change in tier1 and tier5 and this and other tests continue to pass. ------------- Commit messages: - 8327466: ct.sym zip not reproducible across build environment timezones Changes: https://git.openjdk.org/jdk/pull/25207/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25207&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327466 Stats: 186 lines in 2 files changed: 180 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25207.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25207/head:pull/25207 PR: https://git.openjdk.org/jdk/pull/25207 From erikj at openjdk.org Tue May 13 12:54:56 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 May 2025 12:54:56 GMT Subject: RFR: 8356820: fixpath should allow + in paths on Windows In-Reply-To: References: Message-ID: On Tue, 13 May 2025 01:17:25 GMT, Chihiro Ito wrote: > When we run configure on Windows, fixpath is used, but this causes an error if the path contains +. > > For example, when we unzip Temurin 24, the directory name created is jdk-24+36. When we specify this as the boot JDK, the following error is output and configure fails > > > configure: The path of BOOT_JDK_ARG, which is given as ?/mnt/d/opt/jdks/temurin-24+36?, cannot be properly resolved. > configure: Please see the section ?Special Considerations? in building.md. > configure: This is the error message given by fixpath: > fixpath: failure: Path '/mnt/d/opt/jdks/temurin-24+36' could not be converted to short path > configure: error: Cannot continue Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25197#pullrequestreview-2836644099 From erikj at openjdk.org Tue May 13 13:02:06 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 13 May 2025 13:02:06 GMT Subject: RFR: 8327466: ct.sym zip not reproducible across build environment timezones In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai wrote: > Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466. > > Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output. > > The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries. > > Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp. > > The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument. > > The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. > > The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix. > > I have run this change in tier1 and tier5 and this and other tests co... Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25207#pullrequestreview-2836670871 From jlahoda at openjdk.org Tue May 13 13:20:52 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 13 May 2025 13:20:52 GMT Subject: RFR: 8327466: ct.sym zip not reproducible across build environment timezones In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai wrote: > Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466. > > Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output. > > The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries. > > Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp. > > The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument. > > The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. > > The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix. > > I have run this change in tier1 and tier5 and this and other tests co... Looks good to me, thanks! ------------- Marked as reviewed by jlahoda (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25207#pullrequestreview-2836754836 From heidinga at openjdk.org Tue May 13 14:15:57 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 13 May 2025 14:15:57 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:06:44 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added param to makefile function SetupAOT for choosing onestep vs twostep src/java.base/share/man/java.md line 4073: > 4071: - `-XX:AOTMode=record` is specified, or > 4072: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode=auto` is specified, or > 4073: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specidied. Suggestion: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specified. src/java.base/share/man/java.md line 4084: > 4082: - `record`: Execute the application in the Training phase. > 4083: At least one of `-XX:AOTConfiguration=`*configfile* and/or > 4084: `-XX:AOTCache=`*cachefile* must be specified. Suggestion: `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* must be specified. AOTCacheOutput is also a valid configuration for mode record, right? src/java.base/share/man/java.md line 4087: > 4085: If `-XX:AOTConfiguration=`*configfile* is specified, the JVM gathers > 4086: statistical data and stores them into *configfile*. > 4087: If `-XX:AOTCache=`*cachefile* is specified, a second JVM process is launched Suggestion: If `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* is specified, a second JVM process is launched ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086925261 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086929891 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086934364 From honkar at openjdk.org Tue May 13 18:24:28 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 13 May 2025 18:24:28 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 Message-ID: The following line results in unused-result warning on linux/clang. /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); There are two ways to handle it 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. ------------- Commit messages: - unused-result changes Changes: https://git.openjdk.org/jdk/pull/25217/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354316 Stats: 7 lines in 2 files changed: 5 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25217/head:pull/25217 PR: https://git.openjdk.org/jdk/pull/25217 From honkar at openjdk.org Tue May 13 18:32:51 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Tue, 13 May 2025 18:32:51 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar wrote: > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function > declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > > > There are two ways to handle it > > 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. > > 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. > > NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. make/modules/java.desktop/lib/AwtLibraries.gmk line 281: > 279: DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \ > 280: DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \ > 281: DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \ Probably a question for build team - One thing to be noted here is that: With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not. So is there any chance that this disabled warning is being added from else where for gcc ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087413125 From aivanov at openjdk.org Tue May 13 18:38:52 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 13 May 2025 18:38:52 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:30:01 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > make/modules/java.desktop/lib/AwtLibraries.gmk line 281: > >> 279: DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \ >> 280: DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \ >> 281: DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \ > > Probably a question for build team - > One thing to be noted here is that: With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not. > So is there any chance that this disabled warning is being added from else where for gcc ? Maybe gcc doesn't detect this specific case. There could've been other cases which triggered the warning in gcc. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087418018 From aivanov at openjdk.org Tue May 13 18:38:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 13 May 2025 18:38:53 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar wrote: > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function > declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > > > There are two ways to handle it > > 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. > > 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. > > NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696: > 694: if (!isMainThread() && awt_pipe_inited) { > 695: if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) { > 696: // if block is left empty to avoid adding unused-result to Does it make sense to add a trace with `DTRACE_PRINTLN*`? It could be useful for debugging? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2087421715 From iveresov at openjdk.org Tue May 13 22:37:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:37:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v18] In-Reply-To: References: Message-ID: > 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 incrementally with 34 additional commits since the last revision: - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component Reviewed-by: alanb - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context Reviewed-by: mcimadamore - 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath Reviewed-by: darcy - ... and 24 more: https://git.openjdk.org/jdk/compare/da4a3420...72030a30 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/da4a3420..72030a30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16-17 Stats: 7451 lines in 145 files changed: 4269 ins; 1931 del; 1251 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 From iveresov at openjdk.org Tue May 13 22:40:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:40:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: > 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 82 commits: - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component Reviewed-by: alanb - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context Reviewed-by: mcimadamore - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18 Stats: 3330 lines in 59 files changed: 3116 ins; 100 del; 114 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 From iveresov at openjdk.org Tue May 13 22:44:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:44:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 07:42:33 GMT, Ioi Lam wrote: >> Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? > > You can leave the existing code and just fix the new code you added. Done. And changed the test. Please take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087730827 From iklam at openjdk.org Tue May 13 23:15:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 23:15:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 22:40:42 GMT, Igor Veresov wrote: >> 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 82 commits: > > - Merge branch 'master' into pp2 > - Address Ioi's comments > - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off > > Reviewed-by: vlivanov, kvn > - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing > > Reviewed-by: naoto > - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() > > Reviewed-by: wkemper > - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default > > Reviewed-by: asemenyuk > - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property > > Reviewed-by: naoto, bpb > - 8356447: Change default for EagerJVMCI to true > > Reviewed-by: yzheng, kvn, never > - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component > > Reviewed-by: alanb > - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context > > Reviewed-by: mcimadamore > - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: > 113: > 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); > 115: out.shouldContain("does not equal"); Since all the flags have `Profile` in them, I think we should use this to match the intended output: String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; out.shouldNotMatch(errorPattern); ... out.shouldMatch(errorPattern); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087753972 From iveresov at openjdk.org Tue May 13 23:15:57 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:15:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> On Tue, 13 May 2025 23:10:53 GMT, Ioi Lam wrote: >> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: >> >> - Merge branch 'master' into pp2 >> - Address Ioi's comments >> - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off >> >> Reviewed-by: vlivanov, kvn >> - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing >> >> Reviewed-by: naoto >> - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() >> >> Reviewed-by: wkemper >> - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default >> >> Reviewed-by: asemenyuk >> - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property >> >> Reviewed-by: naoto, bpb >> - 8356447: Change default for EagerJVMCI to true >> >> Reviewed-by: yzheng, kvn, never >> - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component >> >> Reviewed-by: alanb >> - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context >> >> Reviewed-by: mcimadamore >> - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 > > test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: > >> 113: >> 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); >> 115: out.shouldContain("does not equal"); > > Since all the flags have `Profile` in them, I think we should use this to match the intended output: > > > String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; > out.shouldNotMatch(errorPattern); > ... > out.shouldMatch(errorPattern); `SpecTrapLimitExtraEntries` does not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087755889 From iveresov at openjdk.org Tue May 13 23:46:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v20] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Address Ioi's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/1669f900..fd26cfe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18-19 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 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 From iklam at openjdk.org Tue May 13 23:46:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v20] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 23:43:01 GMT, Igor Veresov wrote: >> 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 incrementally with one additional commit since the last revision: > > Address Ioi's comments updates are good! ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2838347038 From iveresov at openjdk.org Tue May 13 23:46:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> References: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> Message-ID: On Tue, 13 May 2025 23:13:42 GMT, Igor Veresov wrote: >> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: >> >>> 113: >>> 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); >>> 115: out.shouldContain("does not equal"); >> >> Since all the flags have `Profile` in them, I think we should use this to match the intended output: >> >> >> String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; >> out.shouldNotMatch(errorPattern); >> ... >> out.shouldMatch(errorPattern); > > `SpecTrapLimitExtraEntries` does not. Fixed. Take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087775255 From cito at openjdk.org Wed May 14 00:28:58 2025 From: cito at openjdk.org (Chihiro Ito) Date: Wed, 14 May 2025 00:28:58 GMT Subject: Integrated: 8356820: fixpath should allow + in paths on Windows In-Reply-To: References: Message-ID: On Tue, 13 May 2025 01:17:25 GMT, Chihiro Ito wrote: > When we run configure on Windows, fixpath is used, but this causes an error if the path contains +. > > For example, when we unzip Temurin 24, the directory name created is jdk-24+36. When we specify this as the boot JDK, the following error is output and configure fails > > > configure: The path of BOOT_JDK_ARG, which is given as ?/mnt/d/opt/jdks/temurin-24+36?, cannot be properly resolved. > configure: Please see the section ?Special Considerations? in building.md. > configure: This is the error message given by fixpath: > fixpath: failure: Path '/mnt/d/opt/jdks/temurin-24+36' could not be converted to short path > configure: error: Cannot continue This pull request has now been integrated. Changeset: 0c4bc489 Author: Chihiro Ito URL: https://git.openjdk.org/jdk/commit/0c4bc48928cea7ddd48ba84ed09e9e42ffc68da6 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8356820: fixpath should allow + in paths on Windows Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25197 From kbarrett at openjdk.org Wed May 14 00:55:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 May 2025 00:55:03 GMT Subject: RFR: 8356686: doc/building.html is not up to date after JDK-8301971 In-Reply-To: References: Message-ID: On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote: > Please review this change to doc/building.html. The change is the result of > using `make update-build-docs` to regenerate it from the current building.md > file. Thanks for reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25168#issuecomment-2878287598 From kbarrett at openjdk.org Wed May 14 00:55:03 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 14 May 2025 00:55:03 GMT Subject: Integrated: 8356686: doc/building.html is not up to date after JDK-8301971 In-Reply-To: References: Message-ID: On Sat, 10 May 2025 22:45:54 GMT, Kim Barrett wrote: > Please review this change to doc/building.html. The change is the result of > using `make update-build-docs` to regenerate it from the current building.md > file. This pull request has now been integrated. Changeset: 530d14a1 Author: Kim Barrett URL: https://git.openjdk.org/jdk/commit/530d14a16e6b428ca9a21e8e373ee9c32e673c3e Stats: 13 lines in 1 file changed: 5 ins; 8 del; 0 mod 8356686: doc/building.html is not up to date after JDK-8301971 Reviewed-by: jwaters, shade, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25168 From serb at openjdk.org Wed May 14 04:25:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 May 2025 04:25:52 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:36:18 GMT, Alexey Ivanov wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696: > >> 694: if (!isMainThread() && awt_pipe_inited) { >> 695: if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) { >> 696: // if block is left empty to avoid adding unused-result to > > Does it make sense to add a trace with `DTRACE_PRINTLN*`? > > It could be useful for debugging? yes If write does not return 1 might indicate an error, it would be good to log it. so we can skip this long comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2088003281 From iklam at openjdk.org Wed May 14 06:16:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 06:16:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/3cc2cb3a..cd7a5a6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06-07 Stats: 748 lines in 9 files changed: 369 ins; 327 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From ihse at openjdk.org Wed May 14 06:39:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 06:39:56 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: <4p-YXKf3dE0DR0rzew1i-KXyBlJmWaEvVSf6inZZSCo=.d2a17ec2-18c6-446d-b7e1-11ba55901eb1@github.com> References: <4p-YXKf3dE0DR0rzew1i-KXyBlJmWaEvVSf6inZZSCo=.d2a17ec2-18c6-446d-b7e1-11ba55901eb1@github.com> Message-ID: On Tue, 6 May 2025 15:50:01 GMT, Magnus Ihse Bursie wrote: >>> Do we really need to duplicate all this code? From what I can see, this is just to be able to send in the JDK_FOR_COMPILE argument, right? >> >> Yaml syntax is new to me. I went with that as it worked. :-) The static case sets the `JDK_FOR_COMPILE`|`JDK_UNDER_TEST` and `EXTRA_PROBLEM_LISTS` in `JTREG`. Any suggestion? > > I think you could add something like > > ${{ inputs.extra-test-options }} > > in the `make test-prebuilt` command line, and then set it up as arguments when calling the test workflow. Did you try this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2088160481 From ihse at openjdk.org Wed May 14 06:42:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 14 May 2025 06:42:56 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 22:28:29 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. The code alternates between `if [[ '${{ inputs.static-suffix }}' != '' ]]` and `if: ${{ inputs.static-suffix == '-static' }}`. I don't really care about which you chose, but please pick one and stick to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2878864903 From jwaters at openjdk.org Wed May 14 11:31:59 2025 From: jwaters at openjdk.org (Julian Waters) Date: Wed, 14 May 2025 11:31:59 GMT Subject: RFR: 8342869: Errors related to unused code on Windows after 8339120 in awt In-Reply-To: References: Message-ID: On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters wrote: > After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did > > build.log on release configuration: > > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Component.cpp:3560:39: warning: '_VKS_ALT_MASK' defined but not used [-Wunused-const-variable=] > 3560 | static const UINT _VKS_ALT_MASK = 0x04; > | ^~~~~~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'void CSegTable::MakeTable()': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1361:14: warning: typedef 'PSUBTABLE' locally defined but not used [-Wunused-local-typedefs] > 1361 | } SUBTABLE, *PSUBTABLE; > | ^~~~~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp: In member function 'virtual void CEUDCSegTable::Create(LPCWSTR)': > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1588:10: warning: typedef 'PHEAD' locally defined but not used [-Wunused-local-typedefs] > 1588 | } HEAD, *PHEAD; > | ^~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/native/libawt/windows/awt_Font.cpp:1595:11: warning: typedef 'PENTRY' locally defined but not used [-Wunused-local-typedefs] > 1595 | } ENTRY, *PENTRY; > | ^~~~~~ > C:/users/vertig0/downloads/eclipse-committers-2023-12-r-win32-x86_64/workspace/jdk/src/java.desktop/windows/... Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2879835298 From hannesw at openjdk.org Wed May 14 12:06:32 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 14 May 2025 12:06:32 GMT Subject: RFR: 8355933: Change section title for permanent APIs affected by preview features Message-ID: Please review a change of how preview-related notes on permanent APIs are presented in the Preview API page. The section title changes to "Permanent APIs affected by Preview Features", and the section is rendered below the preview API summary tables rather than above. In order to show the permanent API notes below the other tables I had to change the way extra content is added to API summary pages. The extra content hook methods we had before always displayed extra content before ordinary API summaries (such as terminally deprecated APIs on the Deprecated API page). The new code replaces these hook methods with methods that generate parts of the page and can be overridden in subclasses to add content before or after the default content. I did not structure summary tables into separate preview and permanent API hierarchies as suggested, as that would have made the UI much more complex both visually and functionally. ------------- Commit messages: - 8355933: Change section title for permanent APIs affected by preview features Changes: https://git.openjdk.org/jdk/pull/25224/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25224&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355933 Stats: 83 lines in 8 files changed: 24 ins; 19 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/25224.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25224/head:pull/25224 PR: https://git.openjdk.org/jdk/pull/25224 From jpai at openjdk.org Wed May 14 12:41:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 12:41:59 GMT Subject: RFR: 8327466: ct.sym zip not reproducible across build environment timezones In-Reply-To: References: Message-ID: On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai wrote: > Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466. > > Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output. > > The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries. > > Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp. > > The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument. > > The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. > > The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix. > > I have run this change in tier1 and tier5 and this and other tests co... Thank you Erik and Jan for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25207#issuecomment-2880061230 From jpai at openjdk.org Wed May 14 12:42:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 May 2025 12:42:00 GMT Subject: Integrated: 8327466: ct.sym zip not reproducible across build environment timezones In-Reply-To: References: Message-ID: <0GmtuBkNc1HGnzMG12gcrrkKqmOnRywgBFNVY7CIDc8=.4c03bcd7-2716-4aad-8284-12f9b758ba4f@github.com> On Tue, 13 May 2025 12:00:15 GMT, Jaikiran Pai wrote: > Can I please get a review of this change in the JDK build tool class `CreateSymbols` which addresses an issue related to the reproducibility of the generated `ct.sym` file? This addresses https://bugs.openjdk.org/browse/JDK-8327466. > > Even before this change, in order to support reproducibility of the generated ct.sym file, this internal `CreateSymbols` program takes a `timestamp` argument. The value for the `timestamp` is considered to be the number of seconds since epoch and maps directly to the `SOURCE_DATE_EPOCH` construct that's used by several tools (even outside the JDK) to provide reproducible output. > > The ct.sym file generated by the `CreateSymbols` program is a ZIP file. `CreateSymbols` uses the passed `timestamp` value to set the last modified time on each of the ZIP entries of the generated ZIP file. That way, a constant value for the `timestamp` argument implies that without anything else having changed for a subsequent build, the subsequently generated ct.sym will also have the exact same value for the timestamp for each of the ZIP entries. > > Like many other things in the ZIP specification, a timestamp for a ZIP entry can be set in more than one place within the ZIP structure and the value thus set can be interpreted differently depending on where it is set. That also results in Java SE's `java.util.zip` APIs having more than one way of setting that timestamp. > > The `CreateSymbols` program uses the `java.util.zip.ZipEntry.setTime(...)` API to set this timestamp on the entry. However, that API is specified to be affected by the local system default timezone. This effectively means that if `CreateSymbols` is triggered more than once with the same `timestamp` value but with a different timezone, then the generated ct.sym files from each run will have a different value for the ZIP entry timestamps. This defeats the purpose of the `timestamp` agrument. > > The fix is to use an alternate API `java.util.zip.ZipEntry.setTimeLocal(...)` which isn't affected by the local system timezone. This API was introduced in Java 9 to solve issues like this. The decade old original RFR, when this API was introduced, does a very good job of explaining the necessity of this API and how it differs from the `setTime(...)` method https://mail.openjdk.org/pipermail/core-libs-dev/2015-June/034426.html. > > The commit in this PR also introduces a regression test which reproduces the issue and verifies the fix. > > I have run this change in tier1 and tier5 and this and other tests co... This pull request has now been integrated. Changeset: a989245a Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a989245a2424d136f5d2a828eda666c3867b0f48 Stats: 186 lines in 2 files changed: 180 ins; 4 del; 2 mod 8327466: ct.sym zip not reproducible across build environment timezones Reviewed-by: erikj, jlahoda ------------- PR: https://git.openjdk.org/jdk/pull/25207 From jlahoda at openjdk.org Wed May 14 14:53:34 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 May 2025 14:53:34 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity Message-ID: This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. Important parts of the patch: - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` - for type variables, the synthetic annotation is filtered out in the API method ------------- Depends on: https://git.openjdk.org/jdk/pull/24746 Commit messages: - Cleanup. - Fixing build - Adjustments, annotation filtering, adding more tests - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556 - Improving the behavior of the PrintingProcessor. - First support for runtime visible and invisible type annotations in CreateSymbols. - Merge branch 'master' into JDK-8354556 Changes: https://git.openjdk.org/jdk/pull/25232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356894 Stats: 543 lines in 12 files changed: 512 ins; 14 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232 PR: https://git.openjdk.org/jdk/pull/25232 From vromero at openjdk.org Wed May 14 15:29:55 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 14 May 2025 15:29:55 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda wrote: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2840646906 From kvn at openjdk.org Wed May 14 16:08:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 May 2025 16:08:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> On Wed, 14 May 2025 06:16:15 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 Few comments. src/hotspot/share/cds/cds_globals.hpp line 123: > 121: product(ccstr, AOTCacheOutput, nullptr, \ > 122: "Write AOT cache into this file (overrides AOTCache when " \ > 123: "writing)") \ This looks not complete description. And "override AOTCache .." is confusing. src/hotspot/share/cds/metaspaceShared.cpp line 1150: > 1148: print_java_launcher(&ss); > 1149: const char* cmd = ss.freeze(); > 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. Was this discussed? src/hotspot/share/runtime/arguments.cpp line 3060: > 3058: } > 3059: > 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { I don't like that we pollute `Arguments` code with AOT specific flags processing. Can we move this into `CDSConfig`? Both these 2 new methods. But I will agree if you want to keep it here. It is not critical. src/java.base/share/man/java.md line 4141: > 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line > 4140: options are compatible with the AOT cache. An alternative is to run your application with > 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. `-Xlog:aot` test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > 164: "-XX:-AOTClassLinking", > 165: "-XX:AOTConfiguration=" + aotConfigFile, > 166: "-Xlog:cds=debug", `-Xlog:aot` I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2840679467 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089234532 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089261456 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089267274 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089274796 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089279429 From liach at openjdk.org Wed May 14 19:35:51 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 14 May 2025 19:35:51 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda wrote: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method Looks good to me too; though I don't know why we need special treatment for requiresIdentityInternal for Symbol. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2841288882 From honkar at openjdk.org Wed May 14 21:28:37 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 14 May 2025 21:28:37 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: References: Message-ID: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function > declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > > > There are two ways to handle it > > 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. > > > There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html > > > 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. > > NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: DTRACE added ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25217/files - new: https://git.openjdk.org/jdk/pull/25217/files/f1172662..91f3d409 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25217/head:pull/25217 PR: https://git.openjdk.org/jdk/pull/25217 From honkar at openjdk.org Wed May 14 21:28:37 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Wed, 14 May 2025 21:28:37 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 04:23:18 GMT, Sergey Bylokhov wrote: >> src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 696: >> >>> 694: if (!isMainThread() && awt_pipe_inited) { >>> 695: if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) { >>> 696: // if block is left empty to avoid adding unused-result to >> >> Does it make sense to add a trace with `DTRACE_PRINTLN*`? >> >> It could be useful for debugging? > > yes If write does not return 1 might indicate an error, it would be good to log it. so we can skip this long comment Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2089778602 From serb at openjdk.org Wed May 14 22:18:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 14 May 2025 22:18:52 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: <0uH-6ZiwZcJSccs_3Fjwh7OiHRO-PJCisDiv8Dyju8c=.22ee3992-431d-4a1d-a9e0-74dac955b6a5@github.com> On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 695: > 693: static char wakeUp_char = 'p'; > 694: if (!isMainThread() && awt_pipe_inited) { > 695: if (write(AWT_WRITEPIPE, &wakeUp_char, 1) < 0) { No strong preference between write() < 0, < 1, or != 1, it depends on how strict we want to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2089843696 From iveresov at openjdk.org Wed May 14 23:39:43 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 May 2025 23:39:43 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v21] In-Reply-To: References: Message-ID: > 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 84 commits: - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - ... and 74 more: https://git.openjdk.org/jdk/compare/5e50a584...d3d51b00 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=20 Stats: 3332 lines in 59 files changed: 3118 ins; 100 del; 114 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 From serb at openjdk.org Thu May 15 00:09:52 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 15 May 2025 00:09:52 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Marked as reviewed by serb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2841767253 From jiangli at openjdk.org Thu May 15 00:27:57 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 00:27:57 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: <4p-YXKf3dE0DR0rzew1i-KXyBlJmWaEvVSf6inZZSCo=.d2a17ec2-18c6-446d-b7e1-11ba55901eb1@github.com> Message-ID: On Wed, 14 May 2025 06:37:09 GMT, Magnus Ihse Bursie wrote: >> I think you could add something like >> >> ${{ inputs.extra-test-options }} >> >> in the `make test-prebuilt` command line, and then set it up as arguments when calling the test workflow. > > Did you try this? I missed your above suggestion earlier. Experimenting with this. Thanks for the suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2089939753 From jiangli at openjdk.org Thu May 15 01:15:50 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 01:15:50 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v6] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/ed292625..a58e3818 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=04-05 Stats: 26 lines in 1 file changed: 2 ins; 15 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From jiangli at openjdk.org Thu May 15 02:13:25 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 02:13:25 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v7] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/a58e3818..252d42c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Wed, 14 May 2025 15:38:06 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - java.md updates from @rose00 >> - Resolved differences with CSR JDK-8356010 > > src/hotspot/share/cds/cds_globals.hpp line 123: > >> 121: product(ccstr, AOTCacheOutput, nullptr, \ >> 122: "Write AOT cache into this file (overrides AOTCache when " \ >> 123: "writing)") \ > > This looks not complete description. And "override AOTCache .." is confusing. I changed it to "Specifies the file name for writing the AOT cache". Since the behavior is complex, I don't know how much detail I should put here. > src/hotspot/share/cds/metaspaceShared.cpp line 1150: > >> 1148: print_java_launcher(&ss); >> 1149: const char* cmd = ss.freeze(); >> 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); > > I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. > Was this discussed? Currently we print things that are important to the user. The other examples are: $ java -XX:AOTMode=record .... AOTConfiguration recorded: hw.aotconfig $ java -XX:AOTMode=create .... Reading AOTConfiguration hw.aotconfig and writing AOTCache hw.aot AOTCache creation is complete: hw.aot 10498048 bytes I think AOT is still a new feature so a small number of TTY prints would be helpful. If people complain about the verbosity we can change them to UL logs. > src/hotspot/share/runtime/arguments.cpp line 3060: > >> 3058: } >> 3059: >> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { > > I don't like that we pollute `Arguments` code with AOT specific flags processing. > Can we move this into `CDSConfig`? Both these 2 new methods. > > But I will agree if you want to keep it here. It is not critical. These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. > src/java.base/share/man/java.md line 4141: > >> 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line >> 4140: options are compatible with the AOT cache. An alternative is to run your application with >> 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. > > `-Xlog:aot` `-Xlog:cds,aot` is correct for the current state of this PR. I'll change it after JDK-8356595 is integrated into the mainline. > test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > >> 164: "-XX:-AOTClassLinking", >> 165: "-XX:AOTConfiguration=" + aotConfigFile, >> 166: "-Xlog:cds=debug", > > `-Xlog:aot` > I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. `-Xlog:cds=debug` is correct for the current state of this PR (otherwise the test will fail). I'll change it after JDK-8356595 is integrated into the mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133925 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133649 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133612 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133585 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133557 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=08 Stats: 2082 lines in 24 files changed: 1558 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From kvn at openjdk.org Thu May 15 03:36:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:36:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Thu, 15 May 2025 03:15:23 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/arguments.cpp line 3060: >> >>> 3058: } >>> 3059: >>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { >> >> I don't like that we pollute `Arguments` code with AOT specific flags processing. >> Can we move this into `CDSConfig`? Both these 2 new methods. >> >> But I will agree if you want to keep it here. It is not critical. > > These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090168858 From kvn at openjdk.org Thu May 15 03:40:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:40:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2842120535 From aturbanov at openjdk.org Thu May 15 09:12:05 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 15 May 2025 09:12:05 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda wrote: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassReader.java line 1578: > 1576: Assert.check(sym.kind == MTH); > 1577: sym.flags_field |= RESTRICTED; > 1578: } else if (proxy.type.tsym == syms.requiresIdentityType.tsym) { Suggestion: } else if (proxy.type.tsym == syms.requiresIdentityType.tsym) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25232#discussion_r2090678802 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: RFR: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* After an offline discussion, we agreed to wait a bit with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25122#issuecomment-2883137218 From lkorinth at openjdk.org Thu May 15 09:20:03 2025 From: lkorinth at openjdk.org (Leo Korinth) Date: Thu, 15 May 2025 09:20:03 GMT Subject: Withdrawn: 8356171: Increase timeout for testcases as preparation for change of default timeout factor In-Reply-To: References: Message-ID: On Thu, 8 May 2025 14:51:24 GMT, Leo Korinth wrote: > This change tries to add timeout to individual testcases so that I am able to run them with a timeout factor of 1 in the future (JDK-8260555). > > The first commit changes the timeout factor to 0.7, so that I can run tests and test the change (it will finally be changed to 1.0 in JDK-8260555). The next commit excludes some junit/testng tests where I can currently not change the timeout factor (CODETOOLS-7903961). Both these commits will be reverted before integrating the change. I will also apply copyright updates after the review. > > In addition to changing the timeout factor, I am also using a library call to parse the timeout factor from the java properties (I can not use the library function everywhere as jtreg does not allow me to add @library notations to non testcase files). > > My approach has been to run all test, and afterwards updating those that fails due to a timeout factor. The amount of updated testcases is huge, and my strategy has been to quadruple the timeout if I could not directly see that less was needed (thus the timeout will be the same after JDK-8260555 is implemented). In a few places I have added a bit more timeout so that it will work with the 0.7 timeout factor. > > These fixes have been created when I have plown through testcases: > JDK-8352719: Add an equals sign to the modules statement > JDK-8352709: Remove bad timing annotations from WhileOpTest.java > JDK-8352074: Test MemoryLeak.java seems not to test what it is supposed to test > CODETOOLS-7903937: JTREG uses timeout factor on socket timeout but not on KEEPALIVE > CODETOOLS-7903961: Make default timeout configurable > > Sometime in the future I will also fix: > 8260555: Change the default TIMEOUT_FACTOR from 4 to 1 > > for which I am awaiting: > CODETOOLS-7903961 that is fixed in jtreg 7.6, but we are still running 7.5.1+1 > > *After the review I will revert the two first commits, and update the copyrights* This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25122 From erikj at openjdk.org Thu May 15 13:06:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 15 May 2025 13:06:59 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b doc/testing.md line 619: > 617: run existing jtreg test cases in a special "AOT_JDK" mode. Example: > 618: > 619: Is this extra newline intentional? doc/testing.md line 629: > 627: these classes (such as pre-linked lambda expressions, execution profiles, and pre-generated native code) > 628: are stored into an AOT cache file, which will be used by all the JVMs launched by the selected jtreg > 629: test cases. Some of these lines are >80 chars. Can you try to format line lengths in this file to stay under where reasonably feasible? It's ok if long markups such as links go over, just try to keep the normal text adhering to this. doc/testing.md line 640: > 638: Also, test cases that were written specifically to test AOT, such as the tests > 639: under [test/hotspot/jtreg/runtime/cds](../test/hotspot/jtreg/runtime/cds/), cannot > 640: be execute with the AOT_JDK mode. Suggestion: be executed with the AOT_JDK mode. doc/testing.md line 642: > 640: be execute with the AOT_JDK mode. > 641: > 642: Valid values for `AOT_JDK` are `one_step` and `two_step`. These control how Looks like the values are `onestep` and `twostep` in the makefile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091117516 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091125422 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091121317 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091122470 From amitkumar at openjdk.org Thu May 15 16:03:51 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Thu, 15 May 2025 16:03:51 GMT Subject: RFR: 8355570: [s390x] Update -march to z13 generation [v2] In-Reply-To: References: Message-ID: > updated march level from z10 to z13. > > Testing: tier1 (fastdebug-vm) Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: - Merge branch 'master' into z13 - z10 -> z15 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24869/files - new: https://git.openjdk.org/jdk/pull/24869/files/0f3486ad..f14a22b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24869&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24869&range=00-01 Stats: 66804 lines in 2080 files changed: 42720 ins; 13094 del; 10990 mod Patch: https://git.openjdk.org/jdk/pull/24869.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24869/head:pull/24869 PR: https://git.openjdk.org/jdk/pull/24869 From jiangli at openjdk.org Thu May 15 16:59:08 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 16:59:08 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v8] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Add missing '.outputs' after 'steps.extra-options'. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/252d42c8..2c94d913 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=06-07 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From jiangli at openjdk.org Thu May 15 19:26:07 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 19:26:07 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v9] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Address magicus comment: - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/2c94d913..b9c329ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=07-08 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From jiangli at openjdk.org Thu May 15 19:32:54 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 19:32:54 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v5] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 06:40:09 GMT, Magnus Ihse Bursie wrote: > The code alternates between `if [[ '${{ inputs.static-suffix }}' != '' ]]` and `if: ${{ inputs.static-suffix == '-static' }}`. I don't really care about which you chose, but please pick one and stick to it. Replaced `if [[ '${{ inputs.static-suffix }}' != '' ]]` with `if: ${{ inputs.static-suffix == '-static' }}` to be more consistent. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2884861630 From jiangli at openjdk.org Thu May 15 19:44:39 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 19:44:39 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v10] In-Reply-To: References: Message-ID: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 34 additional commits since the last revision: - Merge branch 'master' into JDK-8355452 - Address magicus comment: - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. - Add missing '.outputs' after 'steps.extra-options'. - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. - Add separate download-static-bundles. - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. - Merge branch 'master' into JDK-8355452 - Experiment based on magicus comment: - Add build-linux-x64 to 'needs' in test-linux-x64-static. - Remove product-bundles test-bundles from build-linux-x64-static. - ... and 24 more: https://git.openjdk.org/jdk/compare/3f710576...257b0349 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/b9c329ee..257b0349 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=08-09 Stats: 13785 lines in 488 files changed: 6317 ins; 4198 del; 3270 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From jiangli at openjdk.org Thu May 15 19:44:39 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 19:44:39 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v10] In-Reply-To: References: <4p-YXKf3dE0DR0rzew1i-KXyBlJmWaEvVSf6inZZSCo=.d2a17ec2-18c6-446d-b7e1-11ba55901eb1@github.com> Message-ID: <8gk8AcVgLr0prt-z_fx1OVArUF0zVTImGY5kN-O5o2Q=.ad4b8d8d-f4fd-41f5-ac9d-d40c130fddb7@github.com> On Thu, 15 May 2025 00:25:40 GMT, Jiangli Zhou wrote: >> Did you try this? > > I missed your above suggestion earlier. Experimenting with this. Thanks for the suggestion. I went with using an explicit `extra-options` step to set up the extra command-line options for `make test-prebuilt` to handle the static case. That got rid of the separate `run-tests-static` step and notify error step. The `run-tests` now is used for running tests for both the regular and static cases. GHA testing showed that it worked ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24992#discussion_r2091850312 From amitkumar at openjdk.org Fri May 16 03:52:51 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 16 May 2025 03:52:51 GMT Subject: RFR: 8355570: [s390x] Update -march to z13 generation In-Reply-To: References: Message-ID: <6oviH2XvWH42X9LHtURbZ5n8UD7dVDckkdwdb8HfCno=.bd4949ee-2d53-4bba-a285-1a131c345ef4@github.com> On Mon, 5 May 2025 15:02:49 GMT, Magnus Ihse Bursie wrote: > GHA is using gcc 10.5.0 and it does not work. Maybe you can try building locally with 10.5.0 and see if you can reproduce the problem? Otherwise I have no suggestions to offer. But if you want to integrate this change, it cannot break GHA. Just one thing I am not able to understand. How does changing the minimum-architecture will results into this build failure. GHA is using same gcc for other PRs as well and they are totally working fine. And in this PR I haven't interfered with GCC at all. If any error then I was expecting more of running into SIGILL but certainly not a compile failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2885560982 From galder at openjdk.org Fri May 16 07:24:07 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 16 May 2025 07:24:07 GMT Subject: RFR: 8354257: xctracenorm profiler not working with JDK JMH benchmarks In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 08:43:19 GMT, Galder Zamarre?o wrote: > > > I do think it's a bug that JMH is bundling its checkstyle and findbugs configurations in its distribution jar, so perhaps we can suggest to a JMH maintainer to stop doing that. :) > > > > > > I think that makes sense to me and I can try to do that. Both files could be moved to `src/test/resources`, modify the jmh-core pom.xml to files there instead. The combination of both would stop those xml from ending in the distribution jar. > > I've created [CODETOOLS-7903998](https://bugs.openjdk.org/browse/CODETOOLS-7903998) to track this. FYI ^ is now fixed in JMH ------------- PR Comment: https://git.openjdk.org/jdk/pull/24571#issuecomment-2885871006 From lucy at openjdk.org Fri May 16 09:54:55 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Fri, 16 May 2025 09:54:55 GMT Subject: RFR: 8355570: [s390x] Update -march to z13 generation [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:03:51 GMT, Amit Kumar wrote: >> updated march level from z10 to z13. >> >> Testing: tier1 (fastdebug-vm) > > Amit Kumar has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision: > > - Merge branch 'master' into z13 > - z10 -> z15 This is an overdue change, I agree. BUT: I would like to see successful PRODUCT tests. This change enables new gcc optimizations which fully kick in only in the release build. Out of curiosity: do you see any performance gain? ------------- Changes requested by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24869#pullrequestreview-2846141402 From amitkumar at openjdk.org Fri May 16 10:06:51 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Fri, 16 May 2025 10:06:51 GMT Subject: RFR: 8355570: [s390x] Update -march to z13 generation [v2] In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:52:28 GMT, Lutz Schmidt wrote: > This change enables new gcc optimizations which fully kick in only in the release build. locally both fastdebug + release builds are totally fine, I did build + tier1 test run and didn't see any issue. > do you see any performance gain? I haven't ran any benchmarks yet, just trying to figure out the reason of build failure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24869#issuecomment-2886269169 From duke at openjdk.org Fri May 16 20:02:02 2025 From: duke at openjdk.org (duke) Date: Fri, 16 May 2025 20:02:02 GMT Subject: Withdrawn: 8351842: Windows specific issues in combination of JEP 493 and --with-external-symbols-in-bundles=public In-Reply-To: References: Message-ID: On Fri, 14 Mar 2025 12:29:22 GMT, Christoph Langer wrote: > Alternative approach to #24012 > > This keeps the current handling of *.pdb vs *.stripped.pdb which allows debugging at the cost of a little hack in jlink. Maybe the code in jlink can be improved, e.g. make it more conditional. > > I'm running this through our testing still to see whether it'll resolve all of the test issues and does not introduce regressions. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24057 From ihse at openjdk.org Fri May 16 20:21:57 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 May 2025 20:21:57 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v10] In-Reply-To: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> References: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> Message-ID: On Thu, 15 May 2025 19:44:39 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 34 additional commits since the last revision: > > - Merge branch 'master' into JDK-8355452 > - Address magicus comment: > - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. > - Add missing '.outputs' after 'steps.extra-options'. > - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. > - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. > - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > - Add separate download-static-bundles. > - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. > - Merge branch 'master' into JDK-8355452 > - Experiment based on magicus comment: > - Add build-linux-x64 to 'needs' in test-linux-x64-static. > - Remove product-bundles test-bundles from build-linux-x64-static. > - ... and 24 more: https://git.openjdk.org/jdk/compare/c4bb3725...257b0349 Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24992#pullrequestreview-2847553551 From ihse at openjdk.org Fri May 16 20:25:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 May 2025 20:25:55 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v10] In-Reply-To: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> References: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> Message-ID: <7LVzSM4gagj4pJEjWgAoRpFXwzAXDbFH1fhBPJqUYYg=.d392717b-de21-4a92-8629-be0c982228c1@github.com> On Thu, 15 May 2025 19:44:39 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 34 additional commits since the last revision: > > - Merge branch 'master' into JDK-8355452 > - Address magicus comment: > - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. > - Add missing '.outputs' after 'steps.extra-options'. > - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. > - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. > - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > - Add separate download-static-bundles. > - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. > - Merge branch 'master' into JDK-8355452 > - Experiment based on magicus comment: > - Add build-linux-x64 to 'needs' in test-linux-x64-static. > - Remove product-bundles test-bundles from build-linux-x64-static. > - ... and 24 more: https://git.openjdk.org/jdk/compare/e8f069fb...257b0349 I approved this but then I noticed that there were failures in the last GHA run for the new static run. You need to fix or problemlist them before integrating. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2887611742 From ihse at openjdk.org Fri May 16 20:26:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 16 May 2025 20:26:56 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote: > The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. > On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there. > > On Linux x86_64 for example the lib shrinks from > 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M . > > On Linux ppc64le for example the lib shrinks from > 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M . I think so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2887613040 From jiangli at openjdk.org Fri May 16 20:36:50 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 16 May 2025 20:36:50 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v10] In-Reply-To: <7LVzSM4gagj4pJEjWgAoRpFXwzAXDbFH1fhBPJqUYYg=.d392717b-de21-4a92-8629-be0c982228c1@github.com> References: <9U2_7wMWsj2XXMQLkeMPrXMjTxpRthbEgDgMBgdCplc=.52c0911d-1707-41cf-a074-7172d5abd098@github.com> <7LVzSM4gagj4pJEjWgAoRpFXwzAXDbFH1fhBPJqUYYg=.d392717b-de21-4a92-8629-be0c982228c1@github.com> Message-ID: On Fri, 16 May 2025 20:23:00 GMT, Magnus Ihse Bursie wrote: > I approved this but then I noticed that there were failures in the last GHA run for the new static run. You need to fix or problemlist them before integrating. Right, I'll hold off integrating this PR, until the static testing goes green (planned to do so). Currently, there is one remaining issue being handled by https://github.com/openjdk/jdk/pull/25220. I'm waiting for that being approved & integrated first. Then, I'll sync this PR and rerun the static tests in GHA to make sure it's green before integrating the changes. @magicus Thanks for the review and helpful suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2887629603 From serb at openjdk.org Mon May 19 02:24:24 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 19 May 2025 02:24:24 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build Message-ID: This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. A proper fix (e.g., explicit type cast) may be introduced later if necessary. ------------- Commit messages: - 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build Changes: https://git.openjdk.org/jdk/pull/25293/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25293&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357193 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25293.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25293/head:pull/25293 PR: https://git.openjdk.org/jdk/pull/25293 From cjplummer at openjdk.org Mon May 19 03:00:55 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Mon, 19 May 2025 03:00:55 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. Other references to the jvmti version in the debug agent use the result of calling GetVersionNumber(), which provides a jint. These references are otherwise doing the same bit masking and not seeing this warning. Using the compile time JVMTI_VERSION is appropriate for the code in question (it wants the compile time version), and simply casting it to a jint should resolve the warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889473633 From serb at openjdk.org Mon May 19 05:28:50 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 19 May 2025 05:28:50 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. Unfortunately it cannot be suppressed by the cast due to bug in [VS2022](https://developercommunity.visualstudio.com/t/warning-C5287:-operands-are-different-e/10877942?space=21&sort=newest&viewtype=all&entry=myfeedback) I can suppress it by extracting JVMTI_VERSION into local variable similar to how other code looks like: > jint version = JVMTI_VERSION; > jvmtiCompileTimeMajorVersion = ( version & JVMTI_VERSION_MASK_MAJOR ) > >> JVMTI_VERSION_SHIFT_MAJOR; > jvmtiCompileTimeMinorVersion = ( version & JVMTI_VERSION_MASK_MINOR ) > >> JVMTI_VERSION_SHIFT_MINOR; > jvmtiCompileTimeMicroVersion = ( version & JVMTI_VERSION_MASK_MICRO ) > >> JVMTI_VERSION_SHIFT_MICRO; but it might be better just suppress it in the make file? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889662879 From kbarrett at openjdk.org Mon May 19 05:39:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Mon, 19 May 2025 05:39:51 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. The various constants involved here are currently defined as enumerators of (different) unscoped enums. Perhaps they shouldn't be enumerators at all. https://github.com/openjdk/jdk/blame/9927ec0b91775db342b2bbc1937253325c367a19/doc/hotspot-style.md#L670-L674 Ordinarily I would say these ought to be typed constexprs, probably `jint` since these seem to be actual Java values. But some of the code involved needs to be both valid C and valid C++, which makes that noticeably harder. I'm okay with the proposed warning suppression as a quick fix for a build failure, but there should be a followup bug to fix it properly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2889678580 From sspitsyn at openjdk.org Mon May 19 17:56:52 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Mon, 19 May 2025 17:56:52 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Mon, 19 May 2025 05:26:36 GMT, Sergey Bylokhov wrote: > I can suppress it by extracting JVMTI_VERSION into local variable similar to how other code looks like: > > jint version = JVMTI_VERSION; > jvmtiCompileTimeMajorVersion = ( version & JVMTI_VERSION_MASK_MAJOR ) > >> JVMTI_VERSION_SHIFT_MAJOR; > jvmtiCompileTimeMinorVersion = ( version & JVMTI_VERSION_MASK_MINOR ) > >> JVMTI_VERSION_SHIFT_MINOR; > jvmtiCompileTimeMicroVersion = ( version & JVMTI_VERSION_MASK_MICRO ) > >> JVMTI_VERSION_SHIFT_MICRO; > > but it might be better just suppress it in the make file? I like the suggestion to extract JVMTI_VERSION into a local variable. Fixing it in the make file is fine too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2891829112 From nbenalla at openjdk.org Mon May 19 18:11:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 18:11:34 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v3] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - feedback: never bump ASM version - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274 + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274 + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274 + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274 + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274 - Update --release 25 symbol information for JDK 24 build 20 The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/ - initial commit start-of-JDK-26 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=02 Stats: 1705 lines in 56 files changed: 1616 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From jlahoda at openjdk.org Mon May 19 22:54:09 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 22:54:09 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity [v2] In-Reply-To: References: Message-ID: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: - Cleanup. - Fixing build - Adjustments, annotation filtering, adding more tests - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556 - Merge branch 'master' into JDK-8354556 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java Co-authored-by: Chen Liang - additional changes from Archie - removing dead code - integrating code from Archie - fixing bugs, removing dead code - ... and 31 more: https://git.openjdk.org/jdk/compare/e7ce661a...daed20ff ------------- Changes: https://git.openjdk.org/jdk/pull/25232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=01 Stats: 1197 lines in 41 files changed: 1088 ins; 51 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/25232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232 PR: https://git.openjdk.org/jdk/pull/25232 From serb at openjdk.org Mon May 19 23:03:53 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Mon, 19 May 2025 23:03:53 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. I guess everyone agreed to disable the warning in the makefile ------------- PR Comment: https://git.openjdk.org/jdk/pull/25293#issuecomment-2892470978 From iveresov at openjdk.org Tue May 20 00:37:14 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 20 May 2025 00:37:14 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v22] In-Reply-To: References: Message-ID: <_HjblHzZnDzpYl3gZrcQL7FWeqJ_7jxEY_LwHQV6AiU=.ad599c04-7bd1-48db-9485-dd0dab940930@github.com> > 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 87 commits: - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - ... and 77 more: https://git.openjdk.org/jdk/compare/890456f0...2740c2f2 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=21 Stats: 3325 lines in 59 files changed: 3111 ins; 100 del; 114 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 From iklam at openjdk.org Tue May 20 02:02:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 02:02:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v10] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - ... and 14 more: https://git.openjdk.org/jdk/compare/890456f0...0956fcad ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09 Stats: 2088 lines in 24 files changed: 1564 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Tue May 20 03:43:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 03:43:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/0956fcad..502d1c07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From darcy at openjdk.org Tue May 20 04:58:30 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 May 2025 04:58:30 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes Message-ID: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread "Where to put supplementary docs?" https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html ------------- Commit messages: - Appease jcheck. - JDK-8357000: Write overview documentation for start of release changes Changes: https://git.openjdk.org/jdk/pull/25317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357000 Stats: 43 lines in 1 file changed: 43 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25317/head:pull/25317 PR: https://git.openjdk.org/jdk/pull/25317 From darcy at openjdk.org Tue May 20 04:58:30 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 May 2025 04:58:30 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 04:30:57 GMT, Joe Darcy wrote: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html This PR is intended to document current practices. As initially sent out, it discusses changes under `/src`, but not changes under `/test` (most changes are under `/src`). The PR is _not_ an invitation to re-architect or brainstorm how the start of releases changes could be restructured. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2892908175 From dholmes at openjdk.org Tue May 20 10:27:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 10:27:51 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 04:30:57 GMT, Joe Darcy wrote: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html Do you want to include manpage updates here? doc/ref/start-of-release.md line 5: > 3: ## Overview > 4: > 5: The start of release changes, the changes the turn JDK N into JDK Suggestion: The start of release changes, the changes that turn JDK N into JDK doc/ref/start-of-release.md line 6: > 4: > 5: The start of release changes, the changes the turn JDK N into JDK > 6: (N+1), are primarily small updates to various files along new files to Suggestion: (N+1), are primarily small updates to various files along with new files to ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2853617617 PR Review Comment: https://git.openjdk.org/jdk/pull/25317#discussion_r2097599140 PR Review Comment: https://git.openjdk.org/jdk/pull/25317#discussion_r2097599708 From dholmes at openjdk.org Tue May 20 10:30:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 10:30:50 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 10:25:11 GMT, David Holmes wrote: > Do you want to include manpage updates here? To answer myself "no". To clarify for others there are quite a lot of things that have to happen at the "start" of a release, but the ones documented here are the ones necessary to happen at the time the version number gets incremented. Other changes can be done more "lazily" after that is done - for example, mapage updates, hotspot obsoleted/expired flag updates, and related test changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2893836105 From sspitsyn at openjdk.org Tue May 20 10:58:53 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 20 May 2025 10:58:53 GMT Subject: RFR: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25293#pullrequestreview-2853707197 From ihse at openjdk.org Tue May 20 12:06:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 20 May 2025 12:06:59 GMT Subject: RFR: 8356820: fixpath should allow + in paths on Windows In-Reply-To: References: Message-ID: On Tue, 13 May 2025 01:17:25 GMT, Chihiro Ito wrote: > When we run configure on Windows, fixpath is used, but this causes an error if the path contains +. > > For example, when we unzip Temurin 24, the directory name created is jdk-24+36. When we specify this as the boot JDK, the following error is output and configure fails > > > configure: The path of BOOT_JDK_ARG, which is given as ?/mnt/d/opt/jdks/temurin-24+36?, cannot be properly resolved. > configure: Please see the section ?Special Considerations? in building.md. > configure: This is the error message given by fixpath: > fixpath: failure: Path '/mnt/d/opt/jdks/temurin-24+36' could not be converted to short path > configure: error: Cannot continue @chiroito Sorry for coming in late here. While this patch works, and solves your immediate problem, I think it opens more questions than it answers. Most pressing of all: why did the conversion to shortpath fail? That is supposed to be a general method to rewrite any "suspicious" path to a format that is guaranteed to work in make with no ill side effects. I believe adding + to the set of allowed characters is benign, but I did initially keep this set small and restricted, and rather convert to shortpath one time too many than to miss some odd characters that will cause trouble later on. I would like to know more why + failed, and why we don't see any more information about what was problematic. Especially when run after JDK-8244533 was integrated, more information should be given. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25197#issuecomment-2894156403 From armin.schrenk at skymatic.de Tue May 20 12:12:02 2025 From: armin.schrenk at skymatic.de (Armin Schrenk) Date: Tue, 20 May 2025 14:12:02 +0200 Subject: Applying JEP 493 results in "has been modified error" Message-ID: <97ca1dbd-2084-4b41-a633-ac72dc144995@skymatic.de> Hi all, I need to build the JDK due to a strict security environment. The build system is Ubuntu 22.04 x64 6.8.0 kernel inside a VM. I read about JEP 493 (https://openjdk.org/jeps/493) and used the option "--enable-linkable-runtime". My configure command is: configure \ ??? --with-conf-name=coffeelibs-openjdk-24 \ ??? --with-boot-jdk=/path/to/jdk23 \ ??? --with-version-pre= \ ??? --with-version-string="24.0.1+9" \ ??? --with-version-opt=coffeelibs \ ??? --with-native-debug-symbols=none \ ??? --enable-linkable-runtime The jlink tool of this JDK is used later on. But when i try to build a minial jre with "coffeelibs-openjdk-24/bin/jlink --output runtime --module-path "coffeelibs-openjdk-24/jmods" --add-modules java.base", it throws the "... has been modified" error mentioned in the JEP, not for cacerts or other config files, **but binaries (e.g. java or lib/libextnet.so ).** Does anyone know where the problem is? Best regards, -- Armin Schrenk Skymatic GmbH, Am Hauptbahnhof 6, 53111 Bonn Sitz der Gesellschaft: Bonn; Amtsgericht Bonn, HRB 22635 -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4964 bytes Desc: Kryptografische S/MIME-Signatur URL: From ihse at openjdk.org Tue May 20 13:41:25 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 20 May 2025 13:41:25 GMT Subject: RFR: 8357048: RunTest variables should always be assigned Message-ID: In `SetJtregValue` and `SetMicroValue`, if a default or user-supplied value was given, the corresponding "local" variable was assigned using :=, which will force future eager evaluation of the variable, most notably `+=`. However, if no default nor user-assigned value was given, the variable was not defined at all, which would lead the first `+=` to create a lazy evaluated definition (a macro). Since this was the common behavior for `JTREG_BASIC_OPTIONS`, we did not notice that `JTREG_TIMEOUT_FACTOR` did not have a value when it was used, but that it was assigned later. This made the evaluation broke when we set that variable on the command line and thus forcing eager definition. The fix is to make sure JTREG_TIMEOUT_FACTOR is defined before use. I also changed so SetJtregValue always assigns with :=, so a similar problem could not creep in again. The same problem also existed in SetMicroValue, so I fixed it there too. (There were no bugs caused by this, though.) ------------- Commit messages: - 8357048: RunTest variables should always be assigned Changes: https://git.openjdk.org/jdk/pull/25327/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25327&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357048 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25327.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25327/head:pull/25327 PR: https://git.openjdk.org/jdk/pull/25327 From mbaesken at openjdk.org Tue May 20 14:31:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Tue, 20 May 2025 14:31:56 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote: > The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. > On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there. > > On Linux x86_64 for example the lib shrinks from > 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M . > > On Linux ppc64le for example the lib shrinks from > 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M . >> I think you proposed something like this ? > I think so. Do you plan to propose such a PR ? But without benchmarks for the JDK native libs some people might have concerns . ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2894644441 From vromero at openjdk.org Tue May 20 15:56:56 2025 From: vromero at openjdk.org (Vicente Romero) Date: Tue, 20 May 2025 15:56:56 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 22:54:09 GMT, Jan Lahoda wrote: >> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. >> >> Important parts of the patch: >> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations >> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. >> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` >> - for type variables, the synthetic annotation is filtered out in the API method > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 41 commits: > > - Cleanup. > - Fixing build > - Adjustments, annotation filtering, adding more tests > - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556 > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - fixing bugs, removing dead code > - ... and 31 more: https://git.openjdk.org/jdk/compare/e7ce661a...daed20ff lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2854765603 From kizune at openjdk.org Tue May 20 15:59:57 2025 From: kizune at openjdk.org (Alexander Zuev) Date: Tue, 20 May 2025 15:59:57 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: <5AbtaN3spDPIwctnzjsCh9jUGtqjx4A5SJB-_6ZZEPY=.7441f23a-794b-43e3-913c-934bf6db6543@github.com> On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Marked as reviewed by kizune (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2854775307 From aivanov at openjdk.org Tue May 20 16:04:55 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Tue, 20 May 2025 16:04:55 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Marked as reviewed by aivanov (Reviewer). src/java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c line 1: > 1: /* Bump the copyright year to 2025. ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2854784582 PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2098346273 From darcy at openjdk.org Tue May 20 17:14:38 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 20 May 2025 17:14:38 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: > First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread > > "Where to put supplementary docs?" > https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25317/files - new: https://git.openjdk.org/jdk/pull/25317/files/75130c26..8e10f57b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25317&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25317/head:pull/25317 PR: https://git.openjdk.org/jdk/pull/25317 From erikj at openjdk.org Tue May 20 19:50:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 May 2025 19:50:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 03:43:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed merge make/RunTests.gmk line 753: > 751: $$(call MakeDir, $$($1_AOT_JDK_OUTPUT_DIR)) > 752: > 753: ifeq ($$($1_TRAINING), onestep) Sorry for not noticing this earlier. This is a conditional within a recipe. The preferred style for those are to align the `ifeq`, `else` and `endif` with the recipe itself, using spaces (as it's not a recipe line), and then indent the body with 2 extra spaces for logical indentation. See points 5 and 6 in https://openjdk.org/groups/build/doc/code-conventions.html. You can find an example of this in `make/Bundles.gmk`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2098741011 From erikj at openjdk.org Tue May 20 19:56:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 May 2025 19:56:50 GMT Subject: RFR: 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Tue, 20 May 2025 13:28:22 GMT, Magnus Ihse Bursie wrote: > In `SetJtregValue` and `SetMicroValue`, if a default or user-supplied value was given, the corresponding "local" variable was assigned using :=, which will force future eager evaluation of the variable, most notably `+=`. However, if no default nor user-assigned value was given, the variable was not defined at all, which would lead the first `+=` to create a lazy evaluated definition (a macro). > > Since this was the common behavior for `JTREG_BASIC_OPTIONS`, we did not notice that `JTREG_TIMEOUT_FACTOR` did not have a value when it was used, but that it was assigned later. This made the evaluation broke when we set that variable on the command line and thus forcing eager definition. > > The fix is to make sure JTREG_TIMEOUT_FACTOR is defined before use. I also changed so SetJtregValue always assigns with :=, so a similar problem could not creep in again. The same problem also existed in SetMicroValue, so I fixed it there too. (There were no bugs caused by this, though.) Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25327#pullrequestreview-2855413312 From erikj at openjdk.org Tue May 20 20:08:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 May 2025 20:08:52 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2855440465 From dholmes at openjdk.org Tue May 20 22:30:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 22:30:52 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2855728969 From duke at openjdk.org Wed May 21 03:12:50 2025 From: duke at openjdk.org (Luca Kellermann) Date: Wed, 21 May 2025 03:12:50 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. doc/ref/start-of-release.md line 15: > 13: * Feature value of `Runtime.version()` > 14: * Highest class file format major version recognized by the platform > 15: * Highest `-source`/`-target'/`--release` argument recognized by `javac` Suggestion: * Highest `-source`/`-target`/`--release` argument recognized by `javac` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25317#discussion_r2099213805 From jlahoda at openjdk.org Wed May 21 06:19:36 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 May 2025 06:19:36 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity [v3] In-Reply-To: References: Message-ID: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits: - Merge remote-tracking branch 'upstream/master' into JDK-8356894 - Cleanup. - Fixing build - Adjustments, annotation filtering, adding more tests - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556 - Merge branch 'master' into JDK-8354556 - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java Co-authored-by: Chen Liang - additional changes from Archie - removing dead code - integrating code from Archie - ... and 32 more: https://git.openjdk.org/jdk/compare/1a97eb42...696cd663 ------------- Changes: https://git.openjdk.org/jdk/pull/25232/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25232&range=02 Stats: 543 lines in 12 files changed: 513 ins; 14 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25232.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25232/head:pull/25232 PR: https://git.openjdk.org/jdk/pull/25232 From serb at openjdk.org Wed May 21 09:00:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 21 May 2025 09:00:56 GMT Subject: Integrated: 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build In-Reply-To: References: Message-ID: On Sun, 18 May 2025 23:44:13 GMT, Sergey Bylokhov wrote: > This patch suppresses compiler warning C5287 triggered in debugInit.c when building with Visual Studio 2022 version 17.14 (released a few days ago). > > I?m simply disabling the warning to unblock the broken build. This change is intended to be backported to update releases. > > A proper fix (e.g., explicit type cast) may be introduced later if necessary. This pull request has now been integrated. Changeset: 5f38d1bb Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/5f38d1bb94d008c33c1a7af12c81ee0e15371e13 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8357193: [VS 2022 17.14] Warning C5287 in debugInit.c: enum type mismatch during build Reviewed-by: sspitsyn ------------- PR: https://git.openjdk.org/jdk/pull/25293 From ihse at openjdk.org Wed May 21 09:22:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 21 May 2025 09:22:02 GMT Subject: RFR: 8349638: Build libjdwp with SIZE optimization In-Reply-To: References: Message-ID: On Tue, 11 Feb 2025 15:56:39 GMT, Matthias Baesken wrote: > The libjdwp is currently built with LOW optimization level, it could be built with SIZE optimization to lower the lib size by ~ 10 % on UNIX. > On Windows LOW and SIZE currently translate to the same O1 optimization flag so no difference there. > > On Linux x86_64 for example the lib shrinks from > 300K to 268K and the debuginfo file shrinks from 1.9M to 1.7M . > > On Linux ppc64le for example the lib shrinks from > 428K to 368K and the debuginfo file shrinks from 2.0M to 1.7M . No, I'm sorry, I don't have the cycles over to drive such a thing. I appreciate the work you are doing but I am unable to help with anything apart from reviewing. So if you think you want to do this library by library, then do so, and if so keep this PR. Or maybe you can publish a PR that updates all libraries, and try to gather feedback from it. I don't know what's best. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23563#issuecomment-2897228148 From ihse at openjdk.org Wed May 21 09:25:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 21 May 2025 09:25:58 GMT Subject: Integrated: 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Tue, 20 May 2025 13:28:22 GMT, Magnus Ihse Bursie wrote: > In `SetJtregValue` and `SetMicroValue`, if a default or user-supplied value was given, the corresponding "local" variable was assigned using :=, which will force future eager evaluation of the variable, most notably `+=`. However, if no default nor user-assigned value was given, the variable was not defined at all, which would lead the first `+=` to create a lazy evaluated definition (a macro). > > Since this was the common behavior for `JTREG_BASIC_OPTIONS`, we did not notice that `JTREG_TIMEOUT_FACTOR` did not have a value when it was used, but that it was assigned later. This made the evaluation broke when we set that variable on the command line and thus forcing eager definition. > > The fix is to make sure JTREG_TIMEOUT_FACTOR is defined before use. I also changed so SetJtregValue always assigns with :=, so a similar problem could not creep in again. The same problem also existed in SetMicroValue, so I fixed it there too. (There were no bugs caused by this, though.) This pull request has now been integrated. Changeset: 7c82e09b Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/7c82e09b509a67cafd67f6d2aa33756bf8755253 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod 8357048: RunTest variables should always be assigned Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25327 From hannesw at openjdk.org Wed May 21 10:42:29 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 21 May 2025 10:42:29 GMT Subject: RFR: 8357376: Disable syntax highlighting for JDK API docs Message-ID: Please review a trivial change to disable syntax highlighting in JDK API docs. ------------- Commit messages: - 8357376: Disable syntax highlighting for JDK API docs Changes: https://git.openjdk.org/jdk/pull/25348/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357376 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25348.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25348/head:pull/25348 PR: https://git.openjdk.org/jdk/pull/25348 From erikj at openjdk.org Wed May 21 13:06:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 13:06:53 GMT Subject: RFR: 8357376: Disable syntax highlighting for JDK API docs In-Reply-To: References: Message-ID: <0OxKTszaMiNIu5HYykS6P3aBHG07dcRt5UDZR2KHXsU=.85cd08c3-55d9-4530-a6ce-a584a8db6aab@github.com> On Wed, 21 May 2025 10:36:58 GMT, Hannes Walln?fer wrote: > Please review a trivial change to disable syntax highlighting in JDK API docs. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25348#pullrequestreview-2857648558 From hannesw at openjdk.org Wed May 21 13:28:00 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 21 May 2025 13:28:00 GMT Subject: Integrated: 8357376: Disable syntax highlighting for JDK API docs In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:36:58 GMT, Hannes Walln?fer wrote: > Please review a trivial change to disable syntax highlighting in JDK API docs. This pull request has now been integrated. Changeset: a07150af Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/a07150af1139b262513a25f4fdd32173af95ff4f Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8357376: Disable syntax highlighting for JDK API docs Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25348 From darcy at openjdk.org Wed May 21 16:15:01 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 May 2025 16:15:01 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 20:06:28 GMT, Erik Joelsson wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > Marked as reviewed by erikj (Reviewer). @erikj79 , do you know the build target that would generate the HTML from the new Mardown file? Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2898517147 From liach at openjdk.org Wed May 21 16:52:51 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 May 2025 16:52:51 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. I think the target is `update-build-docs`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2898613469 From erikj at openjdk.org Wed May 21 16:52:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 16:52:52 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 20:06:28 GMT, Erik Joelsson wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback. > > Marked as reviewed by erikj (Reviewer). > @erikj79 , do you know the build target that would generate the HTML from the new Mardown file? Thanks. make update-build-docs I'm not sure if it will search recursively through subdirectories or not. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2898616562 From darcy at openjdk.org Wed May 21 17:16:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 May 2025 17:16:51 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Wed, 21 May 2025 16:50:42 GMT, Erik Joelsson wrote: > > @erikj79 , do you know the build target that would generate the HTML from the new Mardown file? Thanks. > > ``` > make update-build-docs > ``` > > I'm not sure if it will search recursively through subdirectories or not. It did not; I'll take a stab at adding in support for the new subdirectory. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2898684117 From vromero at openjdk.org Wed May 21 18:01:00 2025 From: vromero at openjdk.org (Vicente Romero) Date: Wed, 21 May 2025 18:01:00 GMT Subject: RFR: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity [v3] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 06:19:36 GMT, Jan Lahoda wrote: >> This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. >> >> Important parts of the patch: >> - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations >> - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. >> - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` >> - for type variables, the synthetic annotation is filtered out in the API method > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits: > > - Merge remote-tracking branch 'upstream/master' into JDK-8356894 > - Cleanup. > - Fixing build > - Adjustments, annotation filtering, adding more tests > - Merge remote-tracking branch 'vicente/JDK-8354556' into JDK-8354556 > - Merge branch 'master' into JDK-8354556 > - Update src/jdk.compiler/share/classes/com/sun/tools/javac/code/Lint.java > > Co-authored-by: Chen Liang > - additional changes from Archie > - removing dead code > - integrating code from Archie > - ... and 32 more: https://git.openjdk.org/jdk/compare/1a97eb42...696cd663 lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25232#pullrequestreview-2858674319 From mr at openjdk.org Wed May 21 18:00:59 2025 From: mr at openjdk.org (Mark Reinhold) Date: Wed, 21 May 2025 18:00:59 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: <1MEOnvSEeDrU71vYhdI_6wSBc5wTgs__ml6zX40yofc=.a47ceedf-5cf2-4ccb-8ef4-2ab4971cdca4@github.com> On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Writing this up is good, but I think it belongs in `doc` rather than `doc/ref`. In discussion, the latter morphed into `doc/internals`, and this isn?t about JDK internals. Also, this fits well alongside the `building.md` and `testing.md` files already in `doc`. (Which suggests that a name that?s a gerund might fit even better ? `starting-next-release.md`? ? for extra credit.) Consider framing the whole document as ?how to prepare for the next release,? with explicit instructions on what to do. The present lists of concepts, and of files and changes, comes across more as your personal notes rather than a list of instructions for someone to follow. doc/ref/start-of-release.md line 3: > 1: % Explanation of start of release changes > 2: > 3: ## Overview Is there just one section, titled "Overview", or will there be more? If the former, consider omitting this heading. doc/ref/start-of-release.md line 17: > 15: * Highest `-source`/`-target'/`--release` argument recognized by `javac` > 16: > 17: In more detail, updated files include: The phrasing here, "... updated files include", suggests that this will just be a list of files, but in fact it's a list of files and instructions for updating them. ------------- Changes requested by mr (Lead). PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2858664833 PR Review Comment: https://git.openjdk.org/jdk/pull/25317#discussion_r2100868110 PR Review Comment: https://git.openjdk.org/jdk/pull/25317#discussion_r2100870143 From jiangli at openjdk.org Wed May 21 20:13:48 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 21 May 2025 20:13:48 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v11] In-Reply-To: References: Message-ID: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision: - Merge branch 'master' into JDK-8355452 - Merge branch 'master' into JDK-8355452 - Address magicus comment: - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. - Add missing '.outputs' after 'steps.extra-options'. - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. - Add separate download-static-bundles. - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. - Merge branch 'master' into JDK-8355452 - ... and 25 more: https://git.openjdk.org/jdk/compare/e88dc94f...c2487832 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/257b0349..c2487832 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=09-10 Stats: 52397 lines in 751 files changed: 28728 ins; 19702 del; 3967 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From vyazici at openjdk.org Wed May 21 21:02:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 21 May 2025 21:02:04 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner Message-ID: There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. ### Fixing strategy * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. ### Scanning strategy The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: # Perl is used for multi-line matching find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print git grep -H 'FileDescriptor.in' "*.java" All calls to `InputStreamReader::new` and `Scanner::new` are checked too. ### Problems encountered 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: ``` DOMImplementationRegistry InputRC ListingErrorHandler PandocFilter ``` 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property ------------- Commit messages: - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations Changes: https://git.openjdk.org/jdk/pull/25368/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25368&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356893 Stats: 244 lines in 58 files changed: 111 ins; 20 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/25368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25368/head:pull/25368 PR: https://git.openjdk.org/jdk/pull/25368 From iris at openjdk.org Wed May 21 21:16:52 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 21 May 2025 21:16:52 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Tue, 20 May 2025 17:14:38 GMT, Joe Darcy wrote: >> First attempt to populate "supplementary docs" with a discussion of the start of release changes. For reference on the idea of supplementary docs, see the thread >> >> "Where to put supplementary docs?" >> https://mail.openjdk.org/pipermail/jdk-dev/2025-April/009975.html > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback. Some of these changes require a CSR. Should that be mentioned somewhere? ------------- PR Review: https://git.openjdk.org/jdk/pull/25317#pullrequestreview-2859142069 From rriggs at openjdk.org Wed May 21 21:39:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 21 May 2025 21:39:53 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property There too many changes in too many different areas to be in a single PR. Please break it down by review areas. Client, core libs, tools, etc. ------------- PR Review: https://git.openjdk.org/jdk/pull/25368#pullrequestreview-2859185030 From jiangli at openjdk.org Wed May 21 22:09:15 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 21 May 2025 22:09:15 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: References: Message-ID: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: - Merge branch 'master' into JDK-8355452 - Merge branch 'master' into JDK-8355452 - Merge branch 'master' into JDK-8355452 - Address magicus comment: - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. - Add missing '.outputs' after 'steps.extra-options'. - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. - Add separate download-static-bundles. - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. - ... and 26 more: https://git.openjdk.org/jdk/compare/d7d250e5...fa162b7f ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24992/files - new: https://git.openjdk.org/jdk/pull/24992/files/c2487832..fa162b7f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24992&range=10-11 Stats: 6425 lines in 67 files changed: 6037 ins; 111 del; 277 mod Patch: https://git.openjdk.org/jdk/pull/24992.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24992/head:pull/24992 PR: https://git.openjdk.org/jdk/pull/24992 From mikael at openjdk.org Wed May 21 23:22:02 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Wed, 21 May 2025 23:22:02 GMT Subject: RFR: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned Message-ID: Backing out JDK-8357048 which broke testing. Testing: tier5 (in progress) ------------- Commit messages: - 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned Changes: https://git.openjdk.org/jdk/pull/25374/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25374&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357511 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25374.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25374/head:pull/25374 PR: https://git.openjdk.org/jdk/pull/25374 From dholmes at openjdk.org Wed May 21 23:26:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 May 2025 23:26:50 GMT Subject: RFR: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Wed, 21 May 2025 23:17:26 GMT, Mikael Vidstedt wrote: > Backing out JDK-8357048 which broke testing. > > Testing: tier5 (in progress) LGTM. Thanks for doing the backout. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25374#pullrequestreview-2859372528 From erikj at openjdk.org Wed May 21 23:26:50 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 21 May 2025 23:26:50 GMT Subject: RFR: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Wed, 21 May 2025 23:17:26 GMT, Mikael Vidstedt wrote: > Backing out JDK-8357048 which broke testing. > > Testing: tier5 (in progress) Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25374#pullrequestreview-2859375418 From mikael at openjdk.org Thu May 22 00:40:57 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 22 May 2025 00:40:57 GMT Subject: RFR: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: <6wQ-oCFcZCnGr3S8o-ukyaETE1R4BitWpz51htu0GmQ=.4a73b0bb-af18-4f56-b11f-1c8edf9b2c05@github.com> On Wed, 21 May 2025 23:17:26 GMT, Mikael Vidstedt wrote: > Backing out JDK-8357048 which broke testing. > > Testing: tier5 (in progress) Thank you for the quick reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25374#issuecomment-2899584725 From mikael at openjdk.org Thu May 22 00:40:58 2025 From: mikael at openjdk.org (Mikael Vidstedt) Date: Thu, 22 May 2025 00:40:58 GMT Subject: Integrated: 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned In-Reply-To: References: Message-ID: <8zbmRlylT4SxlnJfejwY0AtdjCc_B0C40ng1yvsDDkw=.f14314fb-b660-42cc-962f-8973204f1057@github.com> On Wed, 21 May 2025 23:17:26 GMT, Mikael Vidstedt wrote: > Backing out JDK-8357048 which broke testing. > > Testing: tier5 (in progress) This pull request has now been integrated. Changeset: b685ea54 Author: Mikael Vidstedt URL: https://git.openjdk.org/jdk/commit/b685ea54081fcf54a6567dddb49b63435a6e1ea4 Stats: 6 lines in 1 file changed: 0 ins; 5 del; 1 mod 8357511: [BACKOUT] 8357048: RunTest variables should always be assigned Reviewed-by: dholmes, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25374 From jiangli at openjdk.org Thu May 22 00:46:55 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 22 May 2025 00:46:55 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> References: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> Message-ID: On Wed, 21 May 2025 22:09:15 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: > > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Address magicus comment: > - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. > - Add missing '.outputs' after 'steps.extra-options'. > - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. > - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. > - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > - Add separate download-static-bundles. > - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. > - ... and 26 more: https://git.openjdk.org/jdk/compare/2472b1b0...fa162b7f All builds/tests in https://github.com/jianglizhou/jdk/actions/runs/15173492211 are green. I'll integrate tomorrow morning, just to be extra cautious (currently it's late afternoon PT time). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2899593380 From alanb at openjdk.org Thu May 22 05:54:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 May 2025 05:54:52 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property javax.swing.text.DefaultEditorKit.read(InputStream ...) is one example changed in the PR. If that is changed to special case System.in then it will require a spec change. It also means that `read(System.in)` will behave differently to say `new BufferedInputStream(System.in)`. From a quick scan, I suspect changes that impact the APIs will need to dropped from the PR, maybe replaced with spec clarification to document the charset that is actually used. In the DefaultEditorKit.read example it might direct folks to the read(Reader ..) method so that code can control which charset to use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2899998753 From syan at openjdk.org Thu May 22 06:30:58 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 May 2025 06:30:58 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Duplicated to https://bugs.openjdk.org/browse/JDK-8346103 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2900065310 From vyazici at openjdk.org Thu May 22 07:59:09 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:09 GMT Subject: RFR: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:37:07 GMT, Roger Riggs wrote: >> There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. >> >> ### Fixing strategy >> >> * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. >> * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. >> * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. >> >> @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. >> >> ### Scanning strategy >> >> The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: >> >> >> # Perl is used for multi-line matching >> find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print >> git grep -H 'FileDescriptor.in' "*.java" >> >> >> All calls to `InputStreamReader::new` and `Scanner::new` are checked too. >> >> ### Problems encountered >> >> 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: >> >> ``` >> DOMImplementationRegistry >> InputRC >> ListingErrorHandler >> PandocFilter >> ``` >> 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property > > There too many changes in too many different areas to be in a single PR. > Please break it down by review areas. Client, core libs, tools, etc. @RogerRiggs, @AlanBateman, thanks so much for the quick review. I see your points. I will 1. withdraw this PR, 2. convert certain changes to spec clarifications, 3. and break it down to multiple PRs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25368#issuecomment-2900262422 From vyazici at openjdk.org Thu May 22 07:59:10 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 22 May 2025 07:59:10 GMT Subject: Withdrawn: 8356893: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner In-Reply-To: References: Message-ID: On Wed, 21 May 2025 20:56:31 GMT, Volkan Yazici wrote: > There are several locations in the JDK source where `System.in` and `FileDescriptor.in` is read with `InputStreamReader` and `Scanner` using the default charset. As recommended by the recently merged [JDK-8356420](https://bugs.openjdk.org/browse/JDK-8356420), this PR replaces the default charset with the one provided by the `stdin.encoding` system property. > > ### Fixing strategy > > * Where it is obvious that `System.in` is passed to `InputStreamReader`/`Scanner` ctors, `stdin.encoding` is employed fixed. > * Where the `InputStream` passed to `InputStreamReader`/`Scanner` ctors is difficult to determine if it can ever be `System.in`, `assert` expressions are placed. > * Where the odds of receiving `System.in` are low, yet it is technically possible (e.g., `Process::getInputStream`, `URL::openConnection`, `Class::getResourceAsStream`), nothing is done. > > @naotoj was kind enough to guide me in this PR, and stated `assert` expressions can be skipped, since they are many ways one can circumvent those checks; wrapping `System.in`, usage of `System::setIn`, etc. Yet we decided to leave them as is to collect feedback from other reviewers too. > > ### Scanning strategy > > The following ~alien technology~ advanced static analysis tools are used to scan the code for potentially affected places: > > > # Perl is used for multi-line matching > find . -name "*.java" -exec perl -0777 -ne 'my $r = (/(InputStreamReader|Scanner)(\s*System.in)/) ? 0 : 1; exit $r' {} ; -print > git grep -H 'FileDescriptor.in' "*.java" > > > All calls to `InputStreamReader::new` and `Scanner::new` are checked too. > > ### Problems encountered > > 1. Due to either irregular, or non-existent license header, could not update the copyright year for following classes: > > ``` > DOMImplementationRegistry > InputRC > ListingErrorHandler > PandocFilter > ``` > 2. Could not employ `stdin.encoding` in `PandocFilter`, since the bootstrap VM running that class returns empty for that system property This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25368 From cstein at openjdk.org Thu May 22 10:44:40 2025 From: cstein at openjdk.org (Christian Stein) Date: Thu, 22 May 2025 10:44:40 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 Message-ID: Please review the change to update to using jtreg 7.5.2. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Tested with tier 1 ? tier 8. ------------- Commit messages: - 8357141: Update to use jtreg 7.5.2 - 8357141: Update to use jtreg 7.5.2 Changes: https://git.openjdk.org/jdk/pull/25263/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25263&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357141 Stats: 10 lines in 9 files changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/25263.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25263/head:pull/25263 PR: https://git.openjdk.org/jdk/pull/25263 From aivanov at openjdk.org Thu May 22 10:55:02 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Thu, 22 May 2025 10:55:02 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Thu, 22 May 2025 06:28:07 GMT, SendaoYan wrote: > Duplicated to https://bugs.openjdk.org/browse/JDK-8346103 So, [JDK-8346103](https://bugs.openjdk.org/browse/JDK-8346103) is closed as duplicate of [JDK-8346436](https://bugs.openjdk.org/browse/JDK-8346436). The latter has a closed code review #22794. I like this approach better because it doesn't simply ignore the return value but prints a trace if `write` returns the unexpected value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2900778127 From syan at openjdk.org Thu May 22 12:34:57 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 22 May 2025 12:34:57 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2861046664 From shade at openjdk.org Thu May 22 12:58:01 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 May 2025 12:58:01 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> References: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> Message-ID: On Wed, 21 May 2025 22:09:15 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: > > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Address magicus comment: > - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. > - Add missing '.outputs' after 'steps.extra-options'. > - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. > - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. > - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > - Add separate download-static-bundles. > - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. > - ... and 26 more: https://git.openjdk.org/jdk/compare/ccfdcb14...fa162b7f Taking a look at this today, sorry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2901132875 From erikj at openjdk.org Thu May 22 12:59:51 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 22 May 2025 12:59:51 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:51:56 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.5.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Tested with tier 1 ? tier 8. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25263#pullrequestreview-2861125561 From jiangli at openjdk.org Thu May 22 14:54:57 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 22 May 2025 14:54:57 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: References: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> Message-ID: On Thu, 22 May 2025 12:54:54 GMT, Aleksey Shipilev wrote: > Taking a look at this today, sorry. @shipilev I was going to integrate, then saw your above comment. I'll hold off then. There are benefits for integrating and enabling testing on static-jdk in GHA. If there is nothing major (or blocking) you after taking a look, could you please LGTM/approve first. I could also address your review feedback with follow up RFE, if ok with you. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2901529820 From shade at openjdk.org Thu May 22 15:13:57 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 22 May 2025 15:13:57 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> References: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> Message-ID: On Wed, 21 May 2025 22:09:15 GMT, Jiangli Zhou wrote: >> Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: >> >> .github/actions/get-bundles/action.yml. >> - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. >> - Add `static-jdk-path` output. >> - Unpack static bundles in bundles/static-jdk. >> >> .github/actions/upload-bundles/action.yml >> - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. >> >> .github/workflows/build-linux.yml >> - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. >> >> .github/workflows/main.yml >> - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. >> - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. >> - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. >> >> .github/workflows/test.yml >> - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. >> - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. >> - Add `run-tests-static`. >> - Add step for notifying test failures on static JDK. >> >> @shipilev Could you please help review this change? Thanks! > > Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: > > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Merge branch 'master' into JDK-8355452 > - Address magicus comment: > - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. > - Add missing '.outputs' after 'steps.extra-options'. > - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. > - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. > - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. > - Add separate download-static-bundles. > - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. > - ... and 26 more: https://git.openjdk.org/jdk/compare/0161ba0f...fa162b7f Looks fine to go in. I spot checked the GHA run on this PR, and it looks fine. As the follow-up, I would like to see if we can merge `bundle-suffix` (that we now only use for static-libs, AFAICS), and the `static-suffix`. Plus, `debug-suffix` needs to be rolled back eventually :) ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24992#pullrequestreview-2861630860 From jiangli at openjdk.org Thu May 22 15:37:05 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 22 May 2025 15:37:05 GMT Subject: RFR: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk [v12] In-Reply-To: References: <4h2ITJY8L8exU6122dNkNEI2tS0sXQd3ZCNLTZWZh7Q=.71b5f00b-7c0a-4689-b2d3-148bbbb12122@github.com> Message-ID: On Thu, 22 May 2025 12:54:54 GMT, Aleksey Shipilev wrote: >> Jiangli Zhou has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8355452 >> - Merge branch 'master' into JDK-8355452 >> - Merge branch 'master' into JDK-8355452 >> - Address magicus comment: >> - Replaced '${{ inputs.static-suffix }}' != '' to '${{ inputs.static-suffix }}' == '-static', to be more consistent. >> - Add missing '.outputs' after 'steps.extra-options'. >> - Remove 'if: ${{ inputs.static-suffix != '-static' }}' check from run-test step. >> - Add 'extra-options' step to setup additional options. Remove run-test-static and the related notify failure steps. >> - Add $static_jdk_bundle_zip$static_jdk_bundle_tar_gz for bundle-found check. >> - Add separate download-static-bundles. >> - Add jdk, langtools and lib-test ProblemList-StaticJdk.txt for test-linux-x64-static. >> - ... and 26 more: https://git.openjdk.org/jdk/compare/30db3fe0...fa162b7f > > Taking a look at this today, sorry. @shipilev Thanks! I created https://bugs.openjdk.org/browse/JDK-8357583 to follow up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24992#issuecomment-2901683985 From jiangli at openjdk.org Thu May 22 15:37:06 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 22 May 2025 15:37:06 GMT Subject: Integrated: 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk In-Reply-To: References: Message-ID: On Thu, 1 May 2025 22:46:00 GMT, Jiangli Zhou wrote: > Please review this PR that adds a `test-linux-x64-static` job, which runs tier1 tests on the static-jdk 'release' binary created from the `linux-x64-static` build job in GHA. Following are the details on the changes: > > .github/actions/get-bundles/action.yml. > - Add `static-suffix` parameter. `static-suffix` is added to the bundle name. > - Add `static-jdk-path` output. > - Unpack static bundles in bundles/static-jdk. > > .github/actions/upload-bundles/action.yml > - Add `static-suffix` parameter. The `static-suffix` is added to the bundle name. The `linux-x64-static` build job sets the parameter as "-static". In other jobs, `static-suffix` not set. > > .github/workflows/build-linux.yml > - Pass `${{ inputs.static-suffix }}` to upload-bundles action, with the `static-suffix` parameter. > > .github/workflows/main.yml > - Build `product-bundles test-bundles static-jdk-bundles` for `linux-x64-static` job. > - Add `test-linux-x64-static` job. It currently tests on `release` binary and not `debug` binary, since there are build issue with `debug` due to GHA resource/space limit. > - Set `debug-suffix` for the existing non-static test jobs, which test on `debug` binaries. > > .github/workflows/test.yml > - Add `debug-suffix` parameter and replace `debug-suffix: -debug` with `debug-suffix: ${{ inputs.debug-suffix }}` in hs/tier1 tests in the test matrix. The existing test jobs (on non-static JDK) set `debug-suffix` to `-debug` to test on `debug` binaries. > - Add `static-suffix` parameter. Add `${{ inputs.static-suffix }}` to the test result artifact name. > - Add `run-tests-static`. > - Add step for notifying test failures on static JDK. > > @shipilev Could you please help review this change? Thanks! This pull request has now been integrated. Changeset: 16d45511 Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/16d45511342c32ac8e8f72fb68dc21ce13339dbe Stats: 107 lines in 5 files changed: 91 ins; 2 del; 14 mod 8355452: GHA: Test jtreg tier1 on linux-x64 static-jdk Reviewed-by: ihse, shade ------------- PR: https://git.openjdk.org/jdk/pull/24992 From iveresov at openjdk.org Thu May 22 20:25:21 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 22 May 2025 20:25:21 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v23] In-Reply-To: References: Message-ID: > 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 88 commits: - Merge branch 'master' into pp2 - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - ... and 78 more: https://git.openjdk.org/jdk/compare/139a05d0...7a350671 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22 Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 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 From kbarrett at openjdk.org Thu May 22 23:53:52 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 22 May 2025 23:53:52 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Change builds without warning with clang 19. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25217#issuecomment-2902873876 From iveresov at openjdk.org Fri May 23 02:54:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 23 May 2025 02:54:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v24] In-Reply-To: References: Message-ID: > 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 incrementally with one additional commit since the last revision: Missing part of the merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/7a350671..a1958ece Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22-23 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 From iklam at openjdk.org Fri May 23 04:31:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 May 2025 04:31:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: References: Message-ID: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Fixed merge - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @erikj79 comments -- makefile indentation - Fixed merge - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=11 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From jlahoda at openjdk.org Fri May 23 04:38:04 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 May 2025 04:38:04 GMT Subject: Integrated: 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity In-Reply-To: References: Message-ID: <55TogwCOwcByQgs-FtTKTZOna2XMkJtr4tIkrLym2B4=.34352836-195c-4a44-8061-5d6c567b0743@github.com> On Wed, 14 May 2025 14:48:15 GMT, Jan Lahoda wrote: > This patch builds on top of https://github.com/openjdk/jdk/pull/24746, and adds support for `@RequiresIdentity` to `--release`. > > Important parts of the patch: > - `CreateSymbols` now keeps `RuntimeInvisibleTypeAnnotationsAttribute`/`RuntimeVisibleTypeAnnotationsAttribute` annotations > - for `ct.sym`, the `@RequiresIdentity` annotation is converted to a synthetic `@RequiresIdentity+Annotation`, as for other similar annotations. > - for parameters, there's a new flag that marks the parameter as "requires identity". The reason is that the other synthetic annotations on symbols used by `ct.sym`/`--release` are normally not added to the model, and hence invisible in the model. Flags are usually used instead of the synthetic annotations in javac. Using this new flag allows us to keep the behavior the same for the `@RequiresIdentity+Annotation` > - for type variables, the synthetic annotation is filtered out in the API method This pull request has now been integrated. Changeset: 9d9e41f5 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/9d9e41f5b4ea70a32871ea6f03a21e3d77212289 Stats: 543 lines in 12 files changed: 513 ins; 14 del; 16 mod 8356894: Adjust CreateSymbols to properly handle the newly added @jdk.internal.RequiresIdentity Reviewed-by: vromero, liach ------------- PR: https://git.openjdk.org/jdk/pull/25232 From erikj at openjdk.org Fri May 23 13:13:03 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:13:03 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> References: <7-rIMrKvXN94Gem4dGXcebX4ncbfWfkwtRcKNmusGfU=.b57df64c-d2ee-4172-aa30-c1d6b6f59202@github.com> Message-ID: <1o9tnuwmzueQpfYaQv_aBRS59u-YQJH2Mo6SUFEL--w=.22557300-24f2-4c52-aec0-3d5581cf331a@github.com> On Wed, 14 May 2025 21:28:37 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > DTRACE added Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2864360229 From erikj at openjdk.org Fri May 23 13:13:04 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:13:04 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v2] In-Reply-To: References: Message-ID: <0Etgi_kK2tLB7ENsbgdH8vlRnHmVyd-VgYcAqmEMw-8=.0721912a-0d89-4118-9456-f5dcb633d9a8@github.com> On Tue, 13 May 2025 18:33:40 GMT, Alexey Ivanov wrote: >> make/modules/java.desktop/lib/AwtLibraries.gmk line 281: >> >>> 279: DISABLED_WARNINGS_gcc_XlibWrapper.c := type-limits pointer-to-int-cast, \ >>> 280: DISABLED_WARNINGS_gcc_XRBackendNative.c := maybe-uninitialized, \ >>> 281: DISABLED_WARNINGS_gcc_XToolkit.c := unused-result, \ >> >> Probably a question for build team - >> One thing to be noted here is that: With unused-result line removed and WITHOUT the if block changes in XToolkit.c, I expected the build to fail due to unused-result on linux/gcc but it did not. >> So is there any chance that this disabled warning is being added from else where for gcc ? > > Maybe gcc doesn't detect this specific case. > > There could've been other cases which triggered the warning in gcc. It could be that not all versions of GCC trigger this warning in this particular case. We don't track disabling of warnings on a per version granularity, as that would be incredibly tedious, so it's hard to know. It could also be that this disabling of `unused-result` was added for a different case that has since disappeared. Regardless, since you are fixing such an issue in the code and no longer see this warning with a reasonably new GCC, it should be safe to remove this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25217#discussion_r2104557140 From erikj at openjdk.org Fri May 23 13:15:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:15:58 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> References: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> Message-ID: <7V06iTghjLDxbNUVkjjhLzZ8qNJ54W74R10Iy_HE6M8=.17c02df0-4cd6-4b9b-a7ad-d1404c17c817@github.com> On Fri, 23 May 2025 04:31:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Fixed merge > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @erikj79 comments -- makefile indentation > - Fixed merge > - @erikj79 comments > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2864370912 From honkar at openjdk.org Fri May 23 16:36:23 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 23 May 2025 16:36:23 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v3] In-Reply-To: References: Message-ID: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com> > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function > declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > > > There are two ways to handle it > > 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. > > > There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html > > > 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. > > NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25217/files - new: https://git.openjdk.org/jdk/pull/25217/files/91f3d409..ef89c987 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25217&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25217.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25217/head:pull/25217 PR: https://git.openjdk.org/jdk/pull/25217 From aivanov at openjdk.org Fri May 23 16:40:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Fri, 23 May 2025 16:40:53 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v3] In-Reply-To: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com> References: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com> Message-ID: On Fri, 23 May 2025 16:36:23 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2865037159 From ihse at openjdk.org Fri May 23 17:38:54 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 May 2025 17:38:54 GMT Subject: RFR: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 [v3] In-Reply-To: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com> References: <7UXyNl4k25yf_QXDsWbTwNydMieQS6Hrv2lq7C8O9QM=.12f497be-0849-476b-8ce7-0fa223b18065@github.com> Message-ID: On Fri, 23 May 2025 16:36:23 GMT, Harshitha Onkar wrote: >> The following line results in unused-result warning on linux/clang. >> >> >> /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function >> declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] >> 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); >> >> >> There are two ways to handle it >> >> 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. >> >> >> There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html >> >> >> 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. >> >> NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. > > Harshitha Onkar has updated the pull request incrementally with one additional commit since the last revision: > > copyright year Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25217#pullrequestreview-2865224400 From ihse at openjdk.org Fri May 23 17:51:51 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 May 2025 17:51:51 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: <1MEOnvSEeDrU71vYhdI_6wSBc5wTgs__ml6zX40yofc=.a47ceedf-5cf2-4ccb-8ef4-2ab4971cdca4@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> <1MEOnvSEeDrU71vYhdI_6wSBc5wTgs__ml6zX40yofc=.a47ceedf-5cf2-4ccb-8ef4-2ab4971cdca4@github.com> Message-ID: On Wed, 21 May 2025 17:58:30 GMT, Mark Reinhold wrote: > Writing this up is good, but I think it belongs in `doc` rather than `doc/ref`. I agree. It does not feel substantially different from the other "process" documents we already have in `doc`. (That would also take care of generation of .html files by the existing code.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2905334220 From ihse at openjdk.org Fri May 23 17:52:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 23 May 2025 17:52:55 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 In-Reply-To: References: Message-ID: <6VMNA8WnasL17rqZI_-t8lriA5SW1VvlldAc9wYR37A=.e53b6116-c873-46a9-af08-399deca2b1bf@github.com> On Fri, 16 May 2025 09:51:56 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.5.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Tested with tier 1 ? tier 8. Marked as reviewed by ihse (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25263#pullrequestreview-2865285931 From honkar at openjdk.org Fri May 23 18:05:57 2025 From: honkar at openjdk.org (Harshitha Onkar) Date: Fri, 23 May 2025 18:05:57 GMT Subject: Integrated: JDK-8354316 : clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:19:37 GMT, Harshitha Onkar wrote: > The following line results in unused-result warning on linux/clang. > > > /java.desktop/unix/native/libawt_xawt/xawt/XToolkit.c:695:9: error: ignoring return value of function > declared with 'warn_unused_result' attribute [-Werror,-Wunused-result] > 695 | write ( AWT_WRITEPIPE, &wakeUp_char, 1 ); > > > There are two ways to handle it > > 1) Make changes to XToolkit.c such that the warning is no longer thrown. But throwing an error based on the result of `write ( AWT_WRITEPIPE, &wakeUp_char, 1 );` will result in unexpected behavioral changes and the best way to handle it is to have an empty if block with an appropriate comment. > > > There was a discussion about the same line long ago and the reason the result of `write()` was not handled and it was left unchanged was not to introduce behavioral change - https://mail.openjdk.org/pipermail/awt-dev/2016-July/011626.html > > > 2) Add unused-result to disabled warning section for clang similar to gcc - https://github.com/openjdk/jdk/blob/d1543429ff29ca0d761b8473b3fb8621abcd226d/make/modules/java.desktop/lib/AwtLibraries.gmk#L281. The 1st approach was picked over the 2nd since the usual recommendation is not to add to disabled warning section unless there is no other option. > > NOTE: the fix has been tested on linux/gcc , it does need to be tested on linux/clang. This pull request has now been integrated. Changeset: 85ca0813 Author: Harshitha Onkar URL: https://git.openjdk.org/jdk/commit/85ca0813f1624141993b20b3d8e404f86da2cef3 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod 8354316: clang/linux build fails with -Wunused-result warning at XToolkit.c:695:9 Reviewed-by: aivanov, ihse, serb, kizune, syan, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25217 From iris at openjdk.org Fri May 23 21:58:51 2025 From: iris at openjdk.org (Iris Clark) Date: Fri, 23 May 2025 21:58:51 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 09:51:56 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 7.5.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Tested with tier 1 ? tier 8. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25263#pullrequestreview-2865801616 From darcy at openjdk.org Fri May 23 22:31:53 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 23 May 2025 22:31:53 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> Message-ID: On Wed, 21 May 2025 21:14:12 GMT, Iris Clark wrote: > Some of these changes require a CSR. Should that be mentioned somewhere? I think "and all the usual review processes need to be followed" is implicit. My main intention is to both summarize the concept of what is in the start-of-release changeset -- "all the bits and pieces that need to get incremented, get incremented" as well as listing out the current particulars, which does evolve slowly over time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2905941855 From darcy at openjdk.org Fri May 23 22:38:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 23 May 2025 22:38:51 GMT Subject: RFR: 8357000: Write overview documentation for start of release changes [v2] In-Reply-To: <1MEOnvSEeDrU71vYhdI_6wSBc5wTgs__ml6zX40yofc=.a47ceedf-5cf2-4ccb-8ef4-2ab4971cdca4@github.com> References: <7NSeUBOek-6Z1riZY4mNn4kZnvUXDNI5hwolz8b0IeI=.8d034b8b-31aa-4a0e-8191-4be3a7860ee9@github.com> <1MEOnvSEeDrU71vYhdI_6wSBc5wTgs__ml6zX40yofc=.a47ceedf-5cf2-4ccb-8ef4-2ab4971cdca4@github.com> Message-ID: On Wed, 21 May 2025 17:58:30 GMT, Mark Reinhold wrote: > Writing this up is good, but I think it belongs in `doc` rather than `doc/ref`. In discussion, the latter morphed into `doc/internals`, and this isn?t about JDK internals. Also, this fits well alongside the `building.md` and `testing.md` files already in `doc`. (Which suggests that a name that?s a gerund might fit even better ? `starting-next-release.md`? ? for extra credit.) > > Consider framing the whole document as ?how to prepare for the next release,? with explicit instructions on what to do. The present lists of concepts, and of files and changes, come across more as your personal notes rather than a list of instructions for someone to follow. Okay; I'll relocate the file. I think having both a conceptual overview as well as a list of current specific files / instructions is helpful in part of help make sure the file gets updated as needed in the future as any additional APIs that model something that get incremented in each release are added. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25317#issuecomment-2905950343 From cstein at openjdk.org Mon May 26 05:54:10 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 26 May 2025 05:54:10 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 [v2] In-Reply-To: References: Message-ID: > Please review the change to update to using jtreg 7.5.2. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. > > Tested with tier 1 ? tier 8. Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into 8357141-use-jtreg-7.5.2 - 8357141: Update to use jtreg 7.5.2 - 8357141: Update to use jtreg 7.5.2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25263/files - new: https://git.openjdk.org/jdk/pull/25263/files/d2bd463f..326da36b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25263&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25263&range=00-01 Stats: 59118 lines in 898 files changed: 34137 ins; 20417 del; 4564 mod Patch: https://git.openjdk.org/jdk/pull/25263.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25263/head:pull/25263 PR: https://git.openjdk.org/jdk/pull/25263 From ihse at openjdk.org Mon May 26 07:43:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Mon, 26 May 2025 07:43:59 GMT Subject: Integrated: 8347570: Configure fails on macOS if directory name do not have correct case In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:05:36 GMT, Magnus Ihse Bursie wrote: > If you have a directory `OpenJDK` and do `cd openjdk`, this will register the current directory as `openjdk`, not `OpenJDK`. This will later on make the check in configure to see if we are in the root directory (to determine where to put the configuration) will fail, since it does a case-sensitive comparison. This pull request has now been integrated. Changeset: 3dbd2d3d Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/3dbd2d3d2d554ce5a8561f1c0fa67fb176d1273d Stats: 20 lines in 1 file changed: 15 ins; 0 del; 5 mod 8347570: Configure fails on macOS if directory name do not have correct case Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25146 From shade at openjdk.org Mon May 26 11:50:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 11:50:54 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 05:54:10 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7.5.2. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> Tested with tier 1 ? tier 8. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8357141-use-jtreg-7.5.2 > - 8357141: Update to use jtreg 7.5.2 > - 8357141: Update to use jtreg 7.5.2 I see a few major JEPs lined up for JDK 25 integration. I'd prefer to wait for this until after JDK 25 fork. That is, we can still put it into JDK 25 stabilization tree, just after everyone complete their integrate-merge-retest rush for JDK 25. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25263#issuecomment-2909452732 From nbenalla at openjdk.org Mon May 26 13:07:06 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 13:07:06 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - ... and 4 more: https://git.openjdk.org/jdk/compare/bd095896...b79e5022 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=03 Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From cstein at openjdk.org Mon May 26 15:22:52 2025 From: cstein at openjdk.org (Christian Stein) Date: Mon, 26 May 2025 15:22:52 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 [v2] In-Reply-To: References: Message-ID: <62ZXWtHAJUtHK2OHfaqC6hbKbrMWtrcpbz1GCGFhH4Q=.e23dd9b7-3827-4406-aeee-1af93c1de5e3@github.com> On Mon, 26 May 2025 05:54:10 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7.5.2. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> Tested with tier 1 ? tier 8. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8357141-use-jtreg-7.5.2 > - 8357141: Update to use jtreg 7.5.2 > - 8357141: Update to use jtreg 7.5.2 Test runs through tier 1 to 8 show that only few unrelated tests do fail at the moment, thus the impact of updating to use jtreg 7.5.2 in the current phase is minimal. Except for provisioning the new tool version - which might put more stress to some teams compared to others. Integration after JDK 25-ea entering RDP1 is an option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25263#issuecomment-2910084965 From ihse at openjdk.org Tue May 27 11:25:08 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 11:25:08 GMT Subject: RFR: 8357842: PandocFilter misses copyright header Message-ID: `make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java` misses a copyright header. ------------- Commit messages: - 8357842: PandocFilter misses copyright header Changes: https://git.openjdk.org/jdk/pull/25463/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357842 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25463.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25463/head:pull/25463 PR: https://git.openjdk.org/jdk/pull/25463 From syan at openjdk.org Tue May 27 11:55:51 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 27 May 2025 11:55:51 GMT Subject: RFR: 8357842: PandocFilter misses copyright header In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:19:12 GMT, Magnus Ihse Bursie wrote: > `make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java` misses a copyright header. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25463#pullrequestreview-2870765088 From erikj at openjdk.org Tue May 27 12:38:02 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 May 2025 12:38:02 GMT Subject: RFR: 8357842: PandocFilter misses copyright header In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:19:12 GMT, Magnus Ihse Bursie wrote: > `make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java` misses a copyright header. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25463#pullrequestreview-2870888969 From ihse at openjdk.org Tue May 27 12:38:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 12:38:02 GMT Subject: Integrated: 8357842: PandocFilter misses copyright header In-Reply-To: References: Message-ID: On Tue, 27 May 2025 11:19:12 GMT, Magnus Ihse Bursie wrote: > `make/jdk/src/classes/build/tools/pandocfilter/PandocFilter.java` misses a copyright header. This pull request has now been integrated. Changeset: 72a3022d Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/72a3022dc6a1521d8e3f08fe5d592f760fc462d2 Stats: 23 lines in 1 file changed: 23 ins; 0 del; 0 mod 8357842: PandocFilter misses copyright header Reviewed-by: syan, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25463 From hannesw at openjdk.org Tue May 27 14:44:06 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 27 May 2025 14:44:06 GMT Subject: RFR: 8357869: Remove PreviewNote taglet in its current form Message-ID: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). The taglet is planned to be reintroduced at a later date in a redesigned form. ------------- Commit messages: - JDK-8357869: Remove PreviewNote taglet in its current form Changes: https://git.openjdk.org/jdk/pull/25467/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25467&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357869 Stats: 129 lines in 2 files changed: 0 ins; 129 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25467.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25467/head:pull/25467 PR: https://git.openjdk.org/jdk/pull/25467 From cstein at openjdk.org Tue May 27 16:29:54 2025 From: cstein at openjdk.org (Christian Stein) Date: Tue, 27 May 2025 16:29:54 GMT Subject: RFR: 8357141: Update to use jtreg 7.5.2 [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 05:54:10 GMT, Christian Stein wrote: >> Please review the change to update to using jtreg 7.5.2. >> >> The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. >> >> Tested with tier 1 ? tier 8. > > Christian Stein has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into 8357141-use-jtreg-7.5.2 > - 8357141: Update to use jtreg 7.5.2 > - 8357141: Update to use jtreg 7.5.2 Targeted to JDK 26 now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25263#issuecomment-2913219338 From erikj at openjdk.org Tue May 27 19:14:06 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 May 2025 19:14:06 GMT Subject: RFR: 8357869: Remove PreviewNote taglet in its current form In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> Message-ID: On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer wrote: > Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). > > The taglet is planned to be reintroduced at a later date in a redesigned form. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25467#pullrequestreview-2872285298 From ihse at openjdk.org Tue May 27 20:48:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 20:48:13 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk [v2] In-Reply-To: References: Message-ID: > After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Fix it for real - Merge branch 'master' into fix-clean-module-deps - 8349665: Make clean removes module-deps.gmk ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24406/files - new: https://git.openjdk.org/jdk/pull/24406/files/f8a50cd1..dad99084 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24406&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24406&range=00-01 Stats: 407553 lines in 4726 files changed: 155931 ins; 228355 del; 23267 mod Patch: https://git.openjdk.org/jdk/pull/24406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24406/head:pull/24406 PR: https://git.openjdk.org/jdk/pull/24406 From ihse at openjdk.org Tue May 27 20:48:13 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 20:48:13 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 09:18:07 GMT, Magnus Ihse Bursie wrote: > After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. Dang it! I tried a lot of approaches in a throwaway branch, and I thought I kept the correct one and tested it. Back to the drawing board, I guess. Thanks for double checking! Now I believe it should work for real this time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2784565328 PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2913993125 From ihse at openjdk.org Tue May 27 21:15:35 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 21:15:35 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk [v3] In-Reply-To: References: Message-ID: > After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: - Fix regression of JDK-8292944 - Update per review request ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24406/files - new: https://git.openjdk.org/jdk/pull/24406/files/dad99084..eea2b709 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24406&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24406&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24406.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24406/head:pull/24406 PR: https://git.openjdk.org/jdk/pull/24406 From ihse at openjdk.org Tue May 27 21:15:38 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 21:15:38 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk [v2] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 20:48:13 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fix it for real > - Merge branch 'master' into fix-clean-module-deps > - 8349665: Make clean removes module-deps.gmk Well it works, but causes a regression of JDK-8292944 ("make help" as the first target after configure). *sigh* It turns out there had already been a partial regression of JDK-8292944 by JDK-8349515... This is now fixed as well. Third time's a charm! Now this should really, really work. (And we should really, really have a regression testing framework for the build system ?). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2914017583 PR Comment: https://git.openjdk.org/jdk/pull/24406#issuecomment-2914060430 From erikj at openjdk.org Tue May 27 21:15:38 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 May 2025 21:15:38 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk [v2] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 20:48:13 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. > > Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Fix it for real > - Merge branch 'master' into fix-clean-module-deps > - 8349665: Make clean removes module-deps.gmk make/Main.gmk line 46: > 44: include FindTests.gmk > 45: > 46: ifneq ($(UPDATE_MODULE_DEPS), ) Why not check equals true? Suggestion: ifeq ($(UPDATE_MODULE_DEPS), true) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24406#discussion_r2110228876 From erikj at openjdk.org Tue May 27 21:21:57 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 27 May 2025 21:21:57 GMT Subject: RFR: 8349665: Make clean removes module-deps.gmk [v3] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:15:35 GMT, Magnus Ihse Bursie wrote: >> After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. > > Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision: > > - Fix regression of JDK-8292944 > - Update per review request Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24406#pullrequestreview-2872713239 From iveresov at openjdk.org Tue May 27 21:57:11 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 27 May 2025 21:57:11 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v25] In-Reply-To: References: Message-ID: > 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 90 commits: - Merge branch 'master' into pp2 - Missing part of the merge - Merge branch 'master' into pp2 - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=24 Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 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 From ihse at openjdk.org Tue May 27 22:04:03 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 22:04:03 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore Message-ID: The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. ------------- Commit messages: - 8357920: Add .rej and .orig to .gitignore Changes: https://git.openjdk.org/jdk/pull/25474/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25474&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357920 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25474.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25474/head:pull/25474 PR: https://git.openjdk.org/jdk/pull/25474 From ihse at openjdk.org Tue May 27 22:41:52 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 22:41:52 GMT Subject: RFR: 8357869: Remove PreviewNote taglet in its current form In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> Message-ID: <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com> On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer wrote: > Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). > > The taglet is planned to be reintroduced at a later date in a redesigned form. Can you really keep the changes to TestPreview.java from JDK-8346109? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25467#issuecomment-2914346710 From ihse at openjdk.org Tue May 27 22:44:55 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Tue, 27 May 2025 22:44:55 GMT Subject: Integrated: 8349665: Make clean removes module-deps.gmk In-Reply-To: References: Message-ID: On Thu, 3 Apr 2025 09:18:07 GMT, Magnus Ihse Bursie wrote: > After [JDK-8292944](https://bugs.openjdk.org/browse/JDK-8292944), we only generate module-deps.gmk once at the start of Init.gmk. This causes `make clean ` to first generate and then remove module-deps.gmk after which the rest of the build proceeds without a module-deps.gmk, causing problems with dependencies. This pull request has now been integrated. Changeset: f25f4a3e Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/f25f4a3eb2f3ebba4af30471de9d35778c120d50 Stats: 22 lines in 3 files changed: 15 ins; 4 del; 3 mod 8349665: Make clean removes module-deps.gmk Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/24406 From ihse at openjdk.org Wed May 28 00:02:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 00:02:04 GMT Subject: RFR: 8357510: [REDO] RunTest variables should always be assigned Message-ID: This is a redo of [JDK-8357048](https://bugs.openjdk.org/browse/JDK-8357048), which had to backed out since it caused testing errors in higher tiers. The problem was that `JTREG_PROBLEM_LIST_PREFIX` was not defined before it was used, and when `JTREG_BASIC_OPTIONS` were no longer implicitly declared as a macro, but instead got a definite assignment, the value of JTREG_PROBLEM_LIST_PREFIX was empty at the time of evaluation. I have now manually checked each and every `+=` assignment to `$1_JTREG_BASIC_OPTIONS`, and verified that all variables present is defined earlier. Here is the original description from JBS: When building `$1_JTREG_BASIC_OPTIONS`, it is assumed that the variable is recursively defined and that thus `+=` is lazy. $1_JTREG_BASIC_OPTIONS += -$$($1_JTREG_TEST_MODE) \ -verbose:$$(JTREG_VERBOSE) -retain:$$(JTREG_RETAIN) \ -concurrency:$$($1_JTREG_JOBS) -timeoutFactor:$$(JTREG_TIMEOUT_FACTOR) \ -vmoption:-XX:MaxRAMPercentage=$$($1_JTREG_MAX_RAM_PERCENTAGE) \ -vmoption:-Dtest.boot.jdk="$$(BOOT_JDK)" \ -vmoption:-Djava.io.tmpdir="$$($1_TEST_TMP_DIR)" ``` If `+=` is eagerly evaluated, the option -timeoutFactor: will get an empty argument and fail. The problem is the line: `$$(eval $$(call SetJtregValue,$1,JTREG_BASIC_OPTIONS))` might create the variable `$1_JTREG_BASIC_OPTIONS` "simply expanded" (the expansion will create an assignment using `:=`). Whereas if the variable is not created the first `+=` will be recursive and will work as expected. One solution to this problem is replacing the three assignments in `SetJtregValue` from `:=` to `=`. This might have other side effects. A more conservative solution might be to create another macro (thus not changing behaviour where strict evaluation might be needed): define SetJtregRecursiveValue ifneq ($$($2), ) $1_$2 = $$($2) else ifneq ($$($$($1_COMPONENT)_$2), ) $1_$2 = $$($$($1_COMPONENT)_$2) else ifneq ($3, ) $1_$2 = $3 endif endif endif endef ------------- Commit messages: - Fix bug with original implementation - Revert "8357511: [BACKOUT] 8357048: RunTest variables should always be assigned" Changes: https://git.openjdk.org/jdk/pull/25475/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25475&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357510 Stats: 18 lines in 1 file changed: 11 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25475.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25475/head:pull/25475 PR: https://git.openjdk.org/jdk/pull/25475 From ihse at openjdk.org Wed May 28 00:11:02 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 00:11:02 GMT Subject: RFR: 8355725: SPEC_FILTER stopped working Message-ID: >From the bug description: The SPEC_FILTER make variable is meant to be used to create small documentation bundles that just contain some selected files. Example usage: `make docs-specs-zip SPEC_FILTER="%-jls.md copyright.html %logo.gif resources"` The fix for [JDK-8349143](https://bugs.openjdk.org/browse/JDK-8349143) caused the feature to stop working: no matter what the filter variables says, all the specs get built. This is a regression, old behavior needs to be restored. ------------- Commit messages: - 8355725: SPEC_FILTER stopped working Changes: https://git.openjdk.org/jdk/pull/25476/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25476&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355725 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25476.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25476/head:pull/25476 PR: https://git.openjdk.org/jdk/pull/25476 From syan at openjdk.org Wed May 28 02:03:02 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 28 May 2025 02:03:02 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. .gitignore line 26: > 24: /.lldbinit > 25: **/core.[0-9]* > 26: *.rej How about use below config instead. It will ignore all the related diff files in root directory and in the any sub-directory. **/*.rej **/*.orig ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25474#discussion_r2110720316 From duke at openjdk.org Wed May 28 05:15:58 2025 From: duke at openjdk.org (duke) Date: Wed, 28 May 2025 05:15:58 GMT Subject: Withdrawn: 8345813: Replace $LDCXX with proper libraries to $LD instead In-Reply-To: References: Message-ID: On Mon, 9 Dec 2024 16:24:51 GMT, Magnus Ihse Bursie wrote: > As suggested by @djelinski in https://github.com/openjdk/jdk/pull/17986#issuecomment-1965991536, we can (and should) remove the special `$LDCXX` linker, and instead just pass the C++ standard libraries to gcc. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/22648 From ihse at openjdk.org Wed May 28 09:22:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 09:22:56 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Wed, 28 May 2025 02:00:41 GMT, SendaoYan wrote: >> The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. >> >> See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. > > .gitignore line 26: > >> 24: /.lldbinit >> 25: **/core.[0-9]* >> 26: *.rej > > How about use below config instead. It will ignore all the related diff files in root directory and in the any sub-directory. > > > **/*.rej > **/*.orig Patterns without a `/` in them will match in all subdirectories, so your suggestion is just redundant. I see we have some places where this was done previously; maybe we should remove that to avoid the confusion. `**` is only relevant if you want to do something like `src/**/*.java`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25474#discussion_r2111368739 From ihse at openjdk.org Wed May 28 09:22:56 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 09:22:56 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Wed, 28 May 2025 09:19:27 GMT, Magnus Ihse Bursie wrote: >> .gitignore line 26: >> >>> 24: /.lldbinit >>> 25: **/core.[0-9]* >>> 26: *.rej >> >> How about use below config instead. It will ignore all the related diff files in root directory and in the any sub-directory. >> >> >> **/*.rej >> **/*.orig > > Patterns without a `/` in them will match in all subdirectories, so your suggestion is just redundant. I see we have some places where this was done previously; maybe we should remove that to avoid the confusion. `**` is only relevant if you want to do something like `src/**/*.java`. And if you really wanted to just match files in the root directory, you'd have to write `/*.rej`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25474#discussion_r2111370705 From hannesw at openjdk.org Wed May 28 09:24:53 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 28 May 2025 09:24:53 GMT Subject: RFR: 8357869: Remove PreviewNote taglet in its current form In-Reply-To: <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com> References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> <04UjdATURCiMYfEnQyr5UmWi5WmL-Cs2CSv5GuxOnJM=.31efecf4-cb4a-4bd3-b997-3de2cab1c5cc@github.com> Message-ID: On Tue, 27 May 2025 22:38:58 GMT, Magnus Ihse Bursie wrote: > Can you really keep the changes to TestPreview.java from JDK-8346109? Yes, the test does not rely on the JDK build taglet, it uses the javadoc `-tag` option to register a generic tag. More importantly, the internal JavaDoc changes in JDK-8346109 (which were not subject to CSR) include refactorings and improvements which are also required for other issues I'm working on. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25467#issuecomment-2915600389 From hannesw at openjdk.org Wed May 28 09:49:59 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 28 May 2025 09:49:59 GMT Subject: Integrated: 8357869: Remove PreviewNote taglet in its current form In-Reply-To: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> References: <8O-UPcN2nsoo_Q9O07HKK-N6jaC0B4CLC9kJxKF84O4=.8218f638-09cf-47ec-b1d9-d3bb3b794773@github.com> Message-ID: On Tue, 27 May 2025 14:38:53 GMT, Hannes Walln?fer wrote: > Please review a change to remove the `PreviewNote` build taglet as it did not pass CSR. This is a partial (build changes) undo of [JDK-8346109](https://bugs.openjdk.org/browse/JDK-8346109). > > The taglet is planned to be reintroduced at a later date in a redesigned form. This pull request has now been integrated. Changeset: 39714b60 Author: Hannes Walln?fer URL: https://git.openjdk.org/jdk/commit/39714b603040f1619f5e0e2a13ea8a90bb993c27 Stats: 129 lines in 2 files changed: 0 ins; 129 del; 0 mod 8357869: Remove PreviewNote taglet in its current form Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25467 From nbenalla at openjdk.org Wed May 28 11:16:53 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 28 May 2025 11:16:53 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:15:35 GMT, Nizar Benalla wrote: >> It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". >> >> Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. > > I'll split the releases over two lines in the next update. The line is a little too long. Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111590538 From cstein at openjdk.org Wed May 28 11:38:53 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 28 May 2025 11:38:53 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: <3Ins14V5M3PnLXVBHH3sgqydHdmtaxrAERYbfG7egLc=.5ec6d31c-f442-482c-9f50-aa67f8e0f454@github.com> On Wed, 28 May 2025 11:14:22 GMT, Nizar Benalla wrote: >> I'll split the releases over two lines in the next update. The line is a little too long. > > Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`. Another variant: Supported releases: 8, 9, 10, ..., 24, 25, 26 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111627278 From syan at openjdk.org Wed May 28 13:47:54 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 28 May 2025 13:47:54 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25474#pullrequestreview-2875182457 From kvn at openjdk.org Wed May 28 14:11:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 May 2025 14:11:16 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v25] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:57:11 GMT, Igor Veresov wrote: >> 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 90 commits: > > - Merge branch 'master' into pp2 > - Missing part of the merge > - Merge branch 'master' into pp2 > - Merge branch 'master' into pp2 > - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform > - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache > - Merge branch 'master' into pp2 > - Address Ioi's comments > - Merge branch 'master' into pp2 > - Address Ioi's comments > - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368 Re-approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2875268813 From erikj at openjdk.org Wed May 28 14:19:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 May 2025 14:19:55 GMT Subject: RFR: 8357510: [REDO] RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Tue, 27 May 2025 23:57:03 GMT, Magnus Ihse Bursie wrote: > This is a redo of [JDK-8357048](https://bugs.openjdk.org/browse/JDK-8357048), which had to backed out since it caused testing errors in higher tiers. > > The problem was that `JTREG_PROBLEM_LIST_PREFIX` was not defined before it was used, and when `JTREG_BASIC_OPTIONS` were no longer implicitly declared as a macro, but instead got a definite assignment, the value of JTREG_PROBLEM_LIST_PREFIX was empty at the time of evaluation. > > I have now manually checked each and every `+=` assignment to `$1_JTREG_BASIC_OPTIONS`, and verified that all variables present is defined earlier. > > Here is the original description from JBS: > > When building `$1_JTREG_BASIC_OPTIONS`, it is assumed that the variable is recursively defined and that thus `+=` is lazy. > > > $1_JTREG_BASIC_OPTIONS += -$$($1_JTREG_TEST_MODE) \ > -verbose:$$(JTREG_VERBOSE) -retain:$$(JTREG_RETAIN) \ > -concurrency:$$($1_JTREG_JOBS) -timeoutFactor:$$(JTREG_TIMEOUT_FACTOR) \ > -vmoption:-XX:MaxRAMPercentage=$$($1_JTREG_MAX_RAM_PERCENTAGE) \ > -vmoption:-Dtest.boot.jdk="$$(BOOT_JDK)" \ > -vmoption:-Djava.io.tmpdir="$$($1_TEST_TMP_DIR)" > ``` > > If `+=` is eagerly evaluated, the option -timeoutFactor: will get an empty argument and fail. > > The problem is the line: `$$(eval $$(call SetJtregValue,$1,JTREG_BASIC_OPTIONS))` might create the variable `$1_JTREG_BASIC_OPTIONS` "simply expanded" (the expansion will create an assignment using `:=`). Whereas if the variable is not created the first `+=` will be recursive and will work as expected. > > One solution to this problem is replacing the three assignments in `SetJtregValue` from `:=` to `=`. This might have other side effects. > > A more conservative solution might be to create another macro (thus not changing behaviour where strict evaluation might be needed): > > define SetJtregRecursiveValue > ifneq ($$($2), ) > $1_$2 = $$($2) > else > ifneq ($$($$($1_COMPONENT)_$2), ) > $1_$2 = $$($$($1_COMPONENT)_$2) > else > ifneq ($3, ) > $1_$2 = $3 > endif > endif > endif > endef Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25475#pullrequestreview-2875299813 From erikj at openjdk.org Wed May 28 14:22:52 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 May 2025 14:22:52 GMT Subject: RFR: 8355725: SPEC_FILTER stopped working In-Reply-To: References: Message-ID: On Wed, 28 May 2025 00:06:36 GMT, Magnus Ihse Bursie wrote: > From the bug description: > > The SPEC_FILTER make variable is meant to be used to create small documentation bundles that just contain some selected files. Example usage: > > `make docs-specs-zip SPEC_FILTER="%-jls.md copyright.html %logo.gif resources"` > > The fix for [JDK-8349143](https://bugs.openjdk.org/browse/JDK-8349143) caused the feature to stop working: no matter what the filter variables says, all the specs get built. This is a regression, old behavior needs to be restored. Have you considered using `?=` for conditional assignments? It's not exactly the same here though as an empty value would be different from no value. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25476#pullrequestreview-2875310361 From erikj at openjdk.org Wed May 28 14:27:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 May 2025 14:27:59 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25474#pullrequestreview-2875321555 From ihse at openjdk.org Wed May 28 14:28:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 14:28:00 GMT Subject: Integrated: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. This pull request has now been integrated. Changeset: 7bd8375f Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/7bd8375fe49eedecae7b2a1c75e7efb5ab06b22d Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod 8357920: Add .rej and .orig to .gitignore Reviewed-by: syan, erikj ------------- PR: https://git.openjdk.org/jdk/pull/25474 From dnsimon at openjdk.org Wed May 28 14:38:25 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 28 May 2025 14:38:25 GMT Subject: RFR: 8357979: [JVMCI] jdk.internal.vm.ci should have earlier class file version Message-ID: There are plans to have libgraal be built for JDK master using a version of Native Image running on a JDK one version behind JDK master. This Native Image execution needs to be able to load the JVMCI classes. As such, the JVMCI classes must have a class file major version of N-1 where N is the major class file version of JDK master. ------------- Commit messages: - use class file version one behind JDK master for JVMCI Changes: https://git.openjdk.org/jdk/pull/25494/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25494&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357979 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25494.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25494/head:pull/25494 PR: https://git.openjdk.org/jdk/pull/25494 From ihse at openjdk.org Wed May 28 14:44:58 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 14:44:58 GMT Subject: Integrated: 8357510: [REDO] RunTest variables should always be assigned In-Reply-To: References: Message-ID: On Tue, 27 May 2025 23:57:03 GMT, Magnus Ihse Bursie wrote: > This is a redo of [JDK-8357048](https://bugs.openjdk.org/browse/JDK-8357048), which had to backed out since it caused testing errors in higher tiers. > > The problem was that `JTREG_PROBLEM_LIST_PREFIX` was not defined before it was used, and when `JTREG_BASIC_OPTIONS` were no longer implicitly declared as a macro, but instead got a definite assignment, the value of JTREG_PROBLEM_LIST_PREFIX was empty at the time of evaluation. > > I have now manually checked each and every `+=` assignment to `$1_JTREG_BASIC_OPTIONS`, and verified that all variables present is defined earlier. > > Here is the original description from JBS: > > When building `$1_JTREG_BASIC_OPTIONS`, it is assumed that the variable is recursively defined and that thus `+=` is lazy. > > > $1_JTREG_BASIC_OPTIONS += -$$($1_JTREG_TEST_MODE) \ > -verbose:$$(JTREG_VERBOSE) -retain:$$(JTREG_RETAIN) \ > -concurrency:$$($1_JTREG_JOBS) -timeoutFactor:$$(JTREG_TIMEOUT_FACTOR) \ > -vmoption:-XX:MaxRAMPercentage=$$($1_JTREG_MAX_RAM_PERCENTAGE) \ > -vmoption:-Dtest.boot.jdk="$$(BOOT_JDK)" \ > -vmoption:-Djava.io.tmpdir="$$($1_TEST_TMP_DIR)" > ``` > > If `+=` is eagerly evaluated, the option -timeoutFactor: will get an empty argument and fail. > > The problem is the line: `$$(eval $$(call SetJtregValue,$1,JTREG_BASIC_OPTIONS))` might create the variable `$1_JTREG_BASIC_OPTIONS` "simply expanded" (the expansion will create an assignment using `:=`). Whereas if the variable is not created the first `+=` will be recursive and will work as expected. > > One solution to this problem is replacing the three assignments in `SetJtregValue` from `:=` to `=`. This might have other side effects. > > A more conservative solution might be to create another macro (thus not changing behaviour where strict evaluation might be needed): > > define SetJtregRecursiveValue > ifneq ($$($2), ) > $1_$2 = $$($2) > else > ifneq ($$($$($1_COMPONENT)_$2), ) > $1_$2 = $$($$($1_COMPONENT)_$2) > else > ifneq ($3, ) > $1_$2 = $3 > endif > endif > endif > endef This pull request has now been integrated. Changeset: a4f870df Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/a4f870df553e4d7669edf6e454e147526ff2fae7 Stats: 18 lines in 1 file changed: 11 ins; 6 del; 1 mod 8357510: [REDO] RunTest variables should always be assigned Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25475 From ihse at openjdk.org Wed May 28 14:44:59 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 14:44:59 GMT Subject: RFR: 8355725: SPEC_FILTER stopped working In-Reply-To: References: Message-ID: On Wed, 28 May 2025 00:06:36 GMT, Magnus Ihse Bursie wrote: > From the bug description: > > The SPEC_FILTER make variable is meant to be used to create small documentation bundles that just contain some selected files. Example usage: > > `make docs-specs-zip SPEC_FILTER="%-jls.md copyright.html %logo.gif resources"` > > The fix for [JDK-8349143](https://bugs.openjdk.org/browse/JDK-8349143) caused the feature to stop working: no matter what the filter variables says, all the specs get built. This is a regression, old behavior needs to be restored. The problem with `?=` is that makes a macro (lazy evaluation), not an assignment (early evaluation). I try to avoid it for that reason and instead rely on assignment in conditionals. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25476#issuecomment-2916603046 From ihse at openjdk.org Wed May 28 14:45:00 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Wed, 28 May 2025 14:45:00 GMT Subject: Integrated: 8355725: SPEC_FILTER stopped working In-Reply-To: References: Message-ID: On Wed, 28 May 2025 00:06:36 GMT, Magnus Ihse Bursie wrote: > From the bug description: > > The SPEC_FILTER make variable is meant to be used to create small documentation bundles that just contain some selected files. Example usage: > > `make docs-specs-zip SPEC_FILTER="%-jls.md copyright.html %logo.gif resources"` > > The fix for [JDK-8349143](https://bugs.openjdk.org/browse/JDK-8349143) caused the feature to stop working: no matter what the filter variables says, all the specs get built. This is a regression, old behavior needs to be restored. This pull request has now been integrated. Changeset: 63d0e7ff Author: Magnus Ihse Bursie URL: https://git.openjdk.org/jdk/commit/63d0e7ff117537bf4768b88c43a0231a14ed1512 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8355725: SPEC_FILTER stopped working Reviewed-by: erikj ------------- PR: https://git.openjdk.org/jdk/pull/25476 From iveresov at openjdk.org Wed May 28 15:18:03 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 28 May 2025 15:18:03 GMT Subject: Integrated: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 20:18:41 GMT, Igor Veresov wrote: > 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 This pull request has now been integrated. Changeset: e3f85c96 Author: Igor Veresov URL: https://git.openjdk.org/jdk/commit/e3f85c961b4c1e5e01aedf3a0f4e1b0e6ff457fd Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod 8355003: Implement JEP 515: Ahead-of-Time Method Profiling Co-authored-by: John R Rose Co-authored-by: Vladimir Ivanov Co-authored-by: Ioi Lam Co-authored-by: Vladimir Kozlov Co-authored-by: Aleksey Shipilev Reviewed-by: kvn, ihse, cjplummer, iklam ------------- PR: https://git.openjdk.org/jdk/pull/24886 From iklam at openjdk.org Wed May 28 16:47:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 16:47:46 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v13] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Fixed merge - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @erikj79 comments -- makefile indentation - Fixed merge - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - ... and 19 more: https://git.openjdk.org/jdk/compare/b2a61a99...a8ce491e ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=12 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From jianglizhou at google.com Wed May 28 17:27:18 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Wed, 28 May 2025 10:27:18 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: On Mon, Apr 15, 2024 at 6:01?PM Jiangli Zhou wrote: > > Magnus, thanks for the response. Please see comments inlined below. > > On Fri, Apr 12, 2024 at 4:52?AM Magnus Ihse Bursie > wrote: > > > > On 2024-04-02 21:16, Jiangli Zhou wrote: > > > > Hi Magnus, > > > > In today's zoom meeting with Alan, Ron, Liam and Chuck, we (briefly) discussed how to move forward contributing the static Java related changes (additional runtime fixes/enhancements on top of the existing static support in JDK) from https://github.com/openjdk/leyden/tree/hermetic-java-runtime to JDK mainline. > > > > Just a bit more details/context below, which may be useful for others reading this thread. > > > > The https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch currently contains following for supporting hermetic Java (without the launcher work for runtime support): > > > > 1. Build change for linking the Java launcher (as bin/javastatic) with JDK/hotspot static libraries (.a), mainly in https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk. The part for creating the complete sets of static libraries (including libjvm.a) has already been included in the mainline since last year. https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk is in a very raw state and is intended to demonstrate the capability of building a static Java launcher. > > > > Indeed. It is nowhere near being able to be integrated. > > > > The main purpose of StaticLink.gmk is to support the static-java-image > make target, which can be used to perform the actual static linking > step using libjvm.a and JDK static libraries. That currently doesn't > exist in the JDK mainline. Creating a "fully" statically linked Java > launcher is the first step (out of many) towards supporting > static/hermetic Java. > > As part of cleaning/refactoring/integrating for the static linking > step, we want to agree and decide/accept on the following: > > - Support the "fully" statically linked java launcher for testing and > demoing the capability of static JDK support, e.g. > - Support running jtreg testing using the "fully" statically linked > Java launcher > - Set up tests in github workflow to help detect any breaking > changes for static support, e.g. new symbol issues introduced by any > changes. There were some earlier discussions on this with Ron and Alan > during the zoom meetings. > - Which JDK native libraries to be statically linked with the new > launcher target? E.g. StaticLink.gmk currently excludes libjsound.a, > libawt_xawt.a, etc from statically linked with the launcher. > - Do we want more than one statically linked launcher target, based on > the set of linked native libraries? > > Based on the decisions of the above, the launcher static linking part > would mostly be in a different shape when it's integrated into the > mainline. That's why I referred to StaticLink.gmk as in a "very raw" > state. > > Here is a high-level view of the state of things for static support: > > (I) What we already have in the JDK mainline: > - Able to build a complete set of JDK/VM static libraries using > `static-libs-image` make target (necessary for supporting static JDK) > - Compilation for .o files are done separately for the static > libraries and dynamic library (ok for now) > > (II) What missing: > - Static linking step as mentioned above > > (III) What needs to be improved (require cleanups and refactoring, and > you mentioned some of those in your response as well): > - Support building both the static libraries and dynamic libraries > using the same set of .o files, instead of separately compiled .o > files. That helps improve build speed and reduce memory overhead for > building JDK. Your current refactoring work aims to help that. > - Clean up the usages of STATIC_BUILD macro. Most of the usages are in > test code. > - Other runtime fixes/enhancements in the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > > I think most work mentioned in III has dependencies on II. We need a > workable base to be able to build the "fully" statically linked > launcher for building and testing the work mentioned in III, when > integrating any of those to the JDK mainline. The makefile refactoring > work can be done in parallel but does not need to be completed before > we add the static linking step in JDK mainline. > > > > > 2. Additional runtime fixes/enhancements on top of the existing static support in JDK, e.g. support further lookup dynamic native library if the built-in native library cannot be found. > > > > 3. Some initial (prototype) work on supporting hermetic JDK resource files in the jimage (JDK modules image). > > > > To move forward, one of the earliest items needed is to add the capability of building the fully statically linked Java launcher in JDK mainline. The other static Java runtime changes can be followed up after the launcher linking part, so they can be built and tested as individual PRs created for the JDK mainline. Magnus, you have expressed interest in helping get the launcher linking part (refactor from https://github.com/openjdk/leyden/blob/hermetic-java-runtime/make/StaticLink.gmk) into JDK mainline. What's your thought on prioritizing the launcher static linking part before other makefile clean ups for static libraries? > > > > Trust me, my absolute top priority now is working on getting the proper build support needed for Hermetic Java. I can't prioritize it any higher. > > Thanks! > > > > > I am not sure what you are asking for. We can't just merge StaticLink.gmk from your prototype. And even if we did, what good will it do you? > > Please see my comments above. > > > > > The problem you are running into is that the build system has not been designed to properly support static linking. There are already 3-4 hacks in place to get something sort-of useful out, but they are prone to breaking. I assume that we agree that for Hermetic Java to become a success, we need to have a stable foundation for static builds. > > > > The core problem of all static linking hacks is that they are not integrated in the right place. They need to be a core part of what NativeCompilation delivers, not something done in a separate file. To put it in other words, StaticLink.gmk from your branch do not need cleanup -- it needs to go away, and the functionality moved to the proper place. > > > > My approach is that NativeCompilation should support doing either only dynamic linking (as today), or static linking (as today with STATIC_LIBS or STATIC_BUILD), or both. The assumption is that the latter will be default, or at least should be tested by default in GHA. For this to work, we need to compile the source code to .o files only once, and then link these .o files either into a dynamic or a static library (or both). > > As of today, the leyden > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch > can build a "fully" statically linked Java launcher. The issue of > compiling the dynamic and static libraries .o files separately is not > a blocker. It's good to have it resolved at some point of time. > > > > > This, in turn, require several changes: > > > > 1) The linking code needs to be cleaned up, and all technical debt needs to be resolved. This is what I have been doing since I started working on static builds for Hermetic Java. JDK-8329704 (which was integrated yesterday) was the first major milestone of this cleanup. Now, the path were to find a library created by the JDK (static or dynamic) is encapsulated in ResolveLibPath. This is currently a monster, but at least all knowledge is collected in a single location, instead of spread over the code base. Getting this simplified is the next step. > > > > 2) We need to stop passing the STATIC_BUILD define when compiling. This is partially addressed in your PR, where you have replaced #ifdef STATIC_BUILD with a dynamic lookup. But there is also the problem of JNI/JVMTI entry points. I have been pondering how we can compile the code in a way so we support both dynamic and static name resolution, and I think I have a solution. > > > > This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > > Thumbs up! That seems to be a good direction. Currently in the leyden > branch, it first looks up the unique > JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > libraries, then search for the dynamic libraries using the > conventional naming when necessary. e.g.: > > https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > > When spec supports JNI_OnLoad_ and etc. for dynamic > libraries, we may still need to support the conventional naming > without the <_lib_name> part for existing libraries out there. Resuming the conversation on using JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L for dynamically linked JNI & agent libraries. It is related to JDK-8350450 [1]: Compile object files once for both static and dynamic builds. We have recently enabled building & tier1 testing for static-jdk with release binary in GHA on linux-x64. The debug build however cannot be enabled in GHA due to space/resource limit (please see more details in JDK-8350450). So it's a good time to pick up JDK-8350450 related work. Based on discussions with Magnus in JDK-8350450 bug comments and separate emails from last year, I'll extract the runtime changes from the leyden/hermetic-java-runtime branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically linked JNI/agent libraries. The work has been broadly tested in our internal prototype on JDK 11 and newer versions (linux-x64). Regarding the spec part, Ron, Alan, Magnus and myself had several discussions last year during hermetic Java meetings. The general understanding was that using JNI_OnLoad_L (and etc) for dynamically linked JDK native libraries requires no JNI/JVMTI spec change. I wonder if the following languages should be relaxed a bit to address potential questions. Any thoughts? >From JNI spec [3]: - JNI_OnLoad/JNI_OnUnload Optional function defined by dynamically linked libraries. LINKAGE: Exported from dynamically linked native libraries that contain native method implementations. - JNI_OnLoad_L Mandatory function that must be defined by statically linked libraries . LINKAGE: Exported from statically linked native libraries that contain native method implementations. - JNI_OnUnload_L Optional function defined by statically linked libraries. >From JVMTI spec [4]: An agent L whose image has been combined with the VM is defined as statically linked if and only if the agent exports a function called Agent_OnLoad_L. [1]: https://bugs.openjdk.org/browse/JDK-8350450 [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html Best, Jiangli > > > > > And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > > > > A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > > Thank you for taking this on! Potentially we could consider taking the > objcopy to localizing hotspot symbols on unix-like platforms, based on > https://github.com/openjdk/jdk/pull/17456 discussions. Additional > testing is still needed to verify the solution. > > > > > My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > > Most of the JDK resources are now supported as hermetic jimage > (lib/modules) bundled in the > https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > The remaining sound.properties, ct.sym and .jfc files can be handled > later. Overally, that part of the work has confirmed the hermetic > jimage bundled solution is robust and helps resolve some of the > difficult start-up sequence issues observed when the hermetic resource > was implemented using JAR file based solution. > > It might be a good idea to follow up on the static linking discussion > in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > > Thanks! > > Jiangli > > > > /Magnus > > > > > > > > Thanks! > > Jiangli > > > > On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >> > >> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >> > > >> > Hi Magnus, > >> > > >> > Thanks for looking into this from the build perspective. > >> > > >> > On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >> > wrote: > >> > > > >> > > First some background for build-dev: I have spent some time looking at > >> > > the build implications of the Hermetic Java effort, which is part of > >> > > Project Leyden. A high-level overview is available here: > >> > > https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source > >> > > code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > >> > > >> > Some additional hermetic Java related references that are also useful: > >> > > >> > - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >> > links to the issues for resolving static linking issues so far > >> > - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >> > building the complete set of static libraries in JDK/VM, particularly > >> > including libjvm.a > >> > > >> > > > >> > > Hermetic Java faces several challenges, but the part that is relevant > >> > > for the build system is the ability to create static libraries. We've > >> > > had this functionality (in three different ways...) for some time, but > >> > > it is rather badly implemented. > >> > > > >> > > As a result of my investigations, I have a bunch of questions. :-) I > >> > > have gotten some answers in private discussion, but for the sake of > >> > > transparency I will repeat them here, to foster an open dialogue. > >> > > > >> > > 1. Am I correct in understanding that the ultimate goal of this exercise > >> > > is to be able to have jmods which include static libraries (*.a) of the > >> > > native code which the module uses, and that the user can then run a > >> > > special jlink command to have this linked into a single executable > >> > > binary (which also bundles the *.class files and any additional > >> > > resources needed)? > >> > > > >> > > 2. If so, is the idea to create special kinds of static jmods, like > >> > > java.base-static.jmod, that contains *.a files instead of lib*.so files? > >> > > Or is the idea that the normal jmod should contain both? > >> > > > >> > > 3. Linking .o and .a files into an executable is a formidable task. Is > >> > > the intention to have jlink call a system-provided ld, or to bundle ld > >> > > with jlink, or to reimplement this functionality in Java? > >> > > >> > I have a similar view as Alan responded in your other email thread. > >> > Things are still in the early stage for the general solution. > >> > > >> > In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >> > branch, when configuring JDK with --with-static-java=yes, the JDK > >> > binary contains the following extra artifacts: > >> > > >> > - static-libs/*.a: The complete set of JDK/VM static libraries > >> > - jdk/bin/javastatic: A demo Java launcher fully statically linked > >> > with the selected JDK .a libraries (e.g. it currently statically link > >> > with the headless) and libjvm.a. It's the standard Java launcher > >> > without additional work for hermetic Java. > >> > > >> > In our prototype for hermetic Java, we build the hermetic executable > >> > image (a single image) from the following input (see description on > >> > singlejar packaging tool in > >> > https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >> > > >> > - A customized launcher (with additional work for hermetic) executable > >> > fully statically linked with JDK/VM static libraries (.a files), > >> > application natives and dependencies (e.g. in .a static libraries) > >> > - JDK lib/modules, JDK resource files > >> > - Application classes and resource files > >> > > >> > Including a JDK library .a into the corresponding .jmod would require > >> > extracting the .a for linking with the executable. In some systems > >> > that may cause memory overhead due to the extracted copy of the .a > >> > files. I think we should consider the memory overhead issue. > >> > > >> > One possibility (as Alan described in his response) is for jlink to > >> > invoke the ld on the build system. jlink could pass the needed JDK > >> > static libraries and libjvm.a (provided as part of the JDK binary) to > >> > ld based on the modules required for the application. > >> > > >> > >> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >> would need to know the complete linker options and inputs. Those > >> include options and inputs related to the application part as well. In > >> some usages, it might be easier to handle native linking separately > >> and pass the linker output, the executable to jlink directly. Maybe we > >> could consider supporting different modes for various usages > >> requirements, from static libraries and native linking point of view: > >> > >> Mode #1 > >> Support .jmod packaged natives static libraries, for both JDK/VM .a > >> and application natives and dependencies. If the inputs to jlink > >> include .jmods, jlink can extract the .a libraries and pass the > >> information to ld to link the executable. > >> > >> Mode #2 > >> Support separate .a as jlink input. Jlink could pass the path > >> information to the .a libraries and other linker options to ld to > >> create the executable. > >> > >> For both mode #1 and #2, jlink would then use the linker output > >> executable to create the final hermetic image. > >> > >> Mode #3 > >> Support a fully linked executable as a jlink input. When a linked > >> executable is given to jlink, it can process it directly with other > >> JDK data/files to create the final image, without native linking step. > >> > >> Any other thoughts and considerations? > >> > >> Best, > >> Jiangli > >> > >> > > > >> > > 4. Is the intention is to allow users to create their own jmods with > >> > > static libraries, and have these linked in as well? This seems to be the > >> > > case. > >> > > >> > An alternative with less memory overhead could be using application > >> > modular JAR and separate .a as the input for jlink. > >> > > >> > > If that is so, then there will always be the risk for name > >> > > collisions, and we can only minimize the risk by making sure any global > >> > > names are as unique as possible. > >> > > >> > Part of the current effort includes resolving the discovered symbol > >> > collision issues with static linking. Will respond to your other email > >> > on the symbol issue separately later. > >> > > >> > > > >> > > 5. The original implementation of static builds in the JDK, created for > >> > > the Mobile project, used a configure flag, --enable-static-builds, to > >> > > change the entire behavior of the build system to only produce *.a files > >> > > instead of lib*.so. In contrast, the current system is using a special > >> > > target instead. > >> > > >> > I think we would need both configure flag and special target for the > >> > static builds. > >> > > >> > > In my eyes, this is a much worse solution. Apart from > >> > > the conceptual principle (if the build should generate static or dynamic > >> > > libraries is definitely a property of what a "configuration" means), > >> > > this makes it much harder to implement efficiently, since we cannot make > >> > > changes in NativeCompilation.gmk, where they are needed. > >> > > >> > For the potential objcopy work to resolve symbol issues, we can add > >> > that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >> > have an internal prototype (not included in > >> > https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >> > by one of colleagues for localizing symbols in libfreetype using > >> > objcopy. > >> > > >> > > > >> > > That was not as much a question as a statement. ? But here is the > >> > > question: Do you think it would be reasonable to restore the old > >> > > behavior but with the new methods, so that we don't use special targets, > >> > > but instead tells configure to generate static libraries? I'm thinking > >> > > we should have a flag like "--with-library-type=" that can have values > >> > > "dynamic" (which is default), "static" or "both". > >> > > >> > If we want to also build a fully statically linked launcher, maybe > >> > --with-static-java? Being able to configure either dynamic, static or > >> > both as you suggested also seems to be a good idea. > >> > > >> > > I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files > >> > > into a single jmod file (see question 2 above), then it definitely is. > >> > > In general, the cost of producing two kinds of libraries are quite > >> > > small, compared to the cost of compiling the source code to object files. > >> > > >> > Completely agree. It would be good to avoid recompiling the .o file > >> > for static and dynamic builds. As proposed in > >> > https://bugs.openjdk.org/browse/JDK-8303796: > >> > > >> > It's beneficial to be able to build both .so and .a from the same set > >> > of .o files. That would involve some changes to handle the dynamic JDK > >> > and static JDK difference at runtime, instead of relying on the > >> > STATIC_BUILD macro. > >> > > >> > > > >> > > Finally, I have looked at how to manipulate symbol visibility. There > >> > > seems many ways forward, so I feel confident that we can find a good > >> > > solution. > >> > > > >> > > One way forward is to use objcopy to manipulate symbol status > >> > > (global/local). There is an option --localize-symbol in objcopy, that > >> > > has been available in objcopy since at least 2.15, which was released > >> > > 2004, so it should be safe to use. But ideally we should avoid using > >> > > objcopy and do this as part of the linking process. This should be > >> > > possible to do, given that we make changes in NativeCompilation.gmk -- > >> > > see question 5 above. > >> > > > >> > > As a fallback, it is also possible to rename symbols, either piecewise > >> > > or wholesale, using objcopy. There are many ways to do this, using > >> > > --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this > >> > > takes a file with a list of symbols). Thus we can always introduce a > >> > > "post factum namespace" by renaming symbols. > >> > > >> > Renaming or redefining the symbol at build time could cause confusions > >> > with debugging. That's a concern raised in > >> > https://github.com/openjdk/jdk/pull/17456 discussions. > >> > > >> > Additionally, redefining symbols using tools like objcopy may not > >> > handle member names referenced in string literals. For example, in > >> > https://github.com/openjdk/jdk/pull/17456 additional changes are > >> > needed in assembling and SA to reflect the symbol change. > >> > > >> > > > >> > > So in the end, I think it will be fully possible to produce .a files > >> > > that only has global symbols for the functions that are part of the API > >> > > exposed by that library, and have all other symbols local, and make this > >> > > is in a way that is consistent with the rest of the build system. > >> > > > >> > > Finally, a note on Hotspot. Due to debugging reasons, we export > >> > > basically all symbols in hotspot as global. This is not reasonable to do > >> > > for a static build. The effect of not exporting those symbols will be > >> > > that SA will not function to 100%. On the other hand, I have no idea if > >> > > SA works at all with a static build. Have you tested this? Is this part > >> > > of the plan to support, or will it be officially dropped for Hermetic Java? > >> > > >> > We have done some testing with jtreg SA related tests for the fully > >> > statically linked `javastatic`. > >> > > >> > If we use objcopy to localize symbols in hotspot, it's not yet clear > >> > what's the impact on SA. We could do some tests. The other question > >> > that I raised is the supported gcc versions (for partial linking) > >> > related to the solution. > >> > > >> > Best, > >> > Jiangli > >> > > >> > > > >> > > /Magnus > >> > > From erikj at openjdk.org Wed May 28 17:34:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Wed, 28 May 2025 17:34:55 GMT Subject: RFR: 8355725: SPEC_FILTER stopped working In-Reply-To: References: Message-ID: <8QnG7kKkfaYsyJHSJK3L1p4UgGDnBr2ie8hlowvhui0=.ab8a31fb-cfb3-4f9a-8893-aad12cbe52f2@github.com> On Wed, 28 May 2025 14:40:19 GMT, Magnus Ihse Bursie wrote: > The problem with `?=` is that makes a macro (lazy evaluation), not an assignment (early evaluation). I try to avoid it for that reason and instead rely on assignment in conditionals. That's a good point, I will try to remember that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25476#issuecomment-2917103916 From iklam at openjdk.org Wed May 28 22:15:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 22:15:02 GMT Subject: Integrated: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam wrote: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). This pull request has now been integrated. Changeset: dede3532 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/dede3532f7238d527fb89be41f1b8050bde02ee3 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics Reviewed-by: erikj, kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/24942 From david.holmes at oracle.com Thu May 29 05:36:03 2025 From: david.holmes at oracle.com (David Holmes) Date: Thu, 29 May 2025 15:36:03 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> Message-ID: <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> Hi Jiangli, On 29/05/2025 3:27 am, Jiangli Zhou wrote: >>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >> >> Thumbs up! That seems to be a good direction. Currently in the leyden >> branch, it first looks up the unique >> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in >> libraries, then search for the dynamic libraries using the >> conventional naming when necessary. e.g.: >> >> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a >> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 >> >> When spec supports JNI_OnLoad_ and etc. for dynamic >> libraries, we may still need to support the conventional naming >> without the <_lib_name> part for existing libraries out there. > > Resuming the conversation on using > JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > for dynamically linked JNI & agent libraries. It is related to > JDK-8350450 [1]: Compile object files once for both static and dynamic > builds. We have recently enabled building & tier1 testing for > static-jdk with release binary in GHA on linux-x64. The debug build > however cannot be enabled in GHA due to space/resource limit (please > see more details in JDK-8350450). So it's a good time to pick up > JDK-8350450 related work. Based on discussions with Magnus in > JDK-8350450 bug comments and separate emails from last year, I'll > extract the runtime changes from the leyden/hermetic-java-runtime > branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically > linked JNI/agent libraries. The work has been broadly tested in our > internal prototype on JDK 11 and newer versions (linux-x64). > > Regarding the spec part, Ron, Alan, Magnus and myself had several > discussions last year during hermetic Java meetings. The general > understanding was that using JNI_OnLoad_L (and etc) for dynamically > linked JDK native libraries requires no JNI/JVMTI spec change. I > wonder if the following languages should be relaxed a bit to address > potential questions. Any thoughts? I don't know exactly what was discussed, but I don't see how you can not update the JNI (and other) specifications to do what you want to do, if that involves invoking JNI_OnLoad_L in the dynamic case instead of JNI_OnLoad. ?? David ----- > From JNI spec [3]: > > - JNI_OnLoad/JNI_OnUnload > Optional function defined by dynamically linked libraries. > > LINKAGE: > Exported from dynamically linked native libraries that contain > native method implementations. > > - JNI_OnLoad_L > Mandatory function that must be defined by statically linked libraries . > > LINKAGE: > Exported from statically linked native libraries that contain native > method implementations. > > - JNI_OnUnload_L > Optional function defined by statically linked libraries. > > From JVMTI spec [4]: > > An agent L whose image has been combined with the VM is defined as > statically linked if and only if the agent exports a function called > Agent_OnLoad_L. > > [1]: https://bugs.openjdk.org/browse/JDK-8350450 > [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime > [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html > > Best, > Jiangli > >> >>> >>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>> >>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >> >> Thank you for taking this on! Potentially we could consider taking the >> objcopy to localizing hotspot symbols on unix-like platforms, based on >> https://github.com/openjdk/jdk/pull/17456 discussions. Additional >> testing is still needed to verify the solution. >> >>> >>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >> >> Most of the JDK resources are now supported as hermetic jimage >> (lib/modules) bundled in the >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. >> The remaining sound.properties, ct.sym and .jfc files can be handled >> later. Overally, that part of the work has confirmed the hermetic >> jimage bundled solution is robust and helps resolve some of the >> difficult start-up sequence issues observed when the hermetic resource >> was implemented using JAR file based solution. >> >> It might be a good idea to follow up on the static linking discussion >> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). >> >> Thanks! >> >> Jiangli >>> >>> /Magnus >>> >>> >>> >>> Thanks! >>> Jiangli >>> >>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>> >>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>> >>>>> Hi Magnus, >>>>> >>>>> Thanks for looking into this from the build perspective. >>>>> >>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>> wrote: >>>>>> >>>>>> First some background for build-dev: I have spent some time looking at >>>>>> the build implications of the Hermetic Java effort, which is part of >>>>>> Project Leyden. A high-level overview is available here: >>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source >>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. >>>>> >>>>> Some additional hermetic Java related references that are also useful: >>>>> >>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>> links to the issues for resolving static linking issues so far >>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>> building the complete set of static libraries in JDK/VM, particularly >>>>> including libjvm.a >>>>> >>>>>> >>>>>> Hermetic Java faces several challenges, but the part that is relevant >>>>>> for the build system is the ability to create static libraries. We've >>>>>> had this functionality (in three different ways...) for some time, but >>>>>> it is rather badly implemented. >>>>>> >>>>>> As a result of my investigations, I have a bunch of questions. :-) I >>>>>> have gotten some answers in private discussion, but for the sake of >>>>>> transparency I will repeat them here, to foster an open dialogue. >>>>>> >>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise >>>>>> is to be able to have jmods which include static libraries (*.a) of the >>>>>> native code which the module uses, and that the user can then run a >>>>>> special jlink command to have this linked into a single executable >>>>>> binary (which also bundles the *.class files and any additional >>>>>> resources needed)? >>>>>> >>>>>> 2. If so, is the idea to create special kinds of static jmods, like >>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? >>>>>> Or is the idea that the normal jmod should contain both? >>>>>> >>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is >>>>>> the intention to have jlink call a system-provided ld, or to bundle ld >>>>>> with jlink, or to reimplement this functionality in Java? >>>>> >>>>> I have a similar view as Alan responded in your other email thread. >>>>> Things are still in the early stage for the general solution. >>>>> >>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>> binary contains the following extra artifacts: >>>>> >>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>> without additional work for hermetic Java. >>>>> >>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>> image (a single image) from the following input (see description on >>>>> singlejar packaging tool in >>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>> >>>>> - A customized launcher (with additional work for hermetic) executable >>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>> application natives and dependencies (e.g. in .a static libraries) >>>>> - JDK lib/modules, JDK resource files >>>>> - Application classes and resource files >>>>> >>>>> Including a JDK library .a into the corresponding .jmod would require >>>>> extracting the .a for linking with the executable. In some systems >>>>> that may cause memory overhead due to the extracted copy of the .a >>>>> files. I think we should consider the memory overhead issue. >>>>> >>>>> One possibility (as Alan described in his response) is for jlink to >>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>> ld based on the modules required for the application. >>>>> >>>> >>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>> would need to know the complete linker options and inputs. Those >>>> include options and inputs related to the application part as well. In >>>> some usages, it might be easier to handle native linking separately >>>> and pass the linker output, the executable to jlink directly. Maybe we >>>> could consider supporting different modes for various usages >>>> requirements, from static libraries and native linking point of view: >>>> >>>> Mode #1 >>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>> and application natives and dependencies. If the inputs to jlink >>>> include .jmods, jlink can extract the .a libraries and pass the >>>> information to ld to link the executable. >>>> >>>> Mode #2 >>>> Support separate .a as jlink input. Jlink could pass the path >>>> information to the .a libraries and other linker options to ld to >>>> create the executable. >>>> >>>> For both mode #1 and #2, jlink would then use the linker output >>>> executable to create the final hermetic image. >>>> >>>> Mode #3 >>>> Support a fully linked executable as a jlink input. When a linked >>>> executable is given to jlink, it can process it directly with other >>>> JDK data/files to create the final image, without native linking step. >>>> >>>> Any other thoughts and considerations? >>>> >>>> Best, >>>> Jiangli >>>> >>>>>> >>>>>> 4. Is the intention is to allow users to create their own jmods with >>>>>> static libraries, and have these linked in as well? This seems to be the >>>>>> case. >>>>> >>>>> An alternative with less memory overhead could be using application >>>>> modular JAR and separate .a as the input for jlink. >>>>> >>>>>> If that is so, then there will always be the risk for name >>>>>> collisions, and we can only minimize the risk by making sure any global >>>>>> names are as unique as possible. >>>>> >>>>> Part of the current effort includes resolving the discovered symbol >>>>> collision issues with static linking. Will respond to your other email >>>>> on the symbol issue separately later. >>>>> >>>>>> >>>>>> 5. The original implementation of static builds in the JDK, created for >>>>>> the Mobile project, used a configure flag, --enable-static-builds, to >>>>>> change the entire behavior of the build system to only produce *.a files >>>>>> instead of lib*.so. In contrast, the current system is using a special >>>>>> target instead. >>>>> >>>>> I think we would need both configure flag and special target for the >>>>> static builds. >>>>> >>>>>> In my eyes, this is a much worse solution. Apart from >>>>>> the conceptual principle (if the build should generate static or dynamic >>>>>> libraries is definitely a property of what a "configuration" means), >>>>>> this makes it much harder to implement efficiently, since we cannot make >>>>>> changes in NativeCompilation.gmk, where they are needed. >>>>> >>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>> have an internal prototype (not included in >>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>> by one of colleagues for localizing symbols in libfreetype using >>>>> objcopy. >>>>> >>>>>> >>>>>> That was not as much a question as a statement. ? But here is the >>>>>> question: Do you think it would be reasonable to restore the old >>>>>> behavior but with the new methods, so that we don't use special targets, >>>>>> but instead tells configure to generate static libraries? I'm thinking >>>>>> we should have a flag like "--with-library-type=" that can have values >>>>>> "dynamic" (which is default), "static" or "both". >>>>> >>>>> If we want to also build a fully statically linked launcher, maybe >>>>> --with-static-java? Being able to configure either dynamic, static or >>>>> both as you suggested also seems to be a good idea. >>>>> >>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files >>>>>> into a single jmod file (see question 2 above), then it definitely is. >>>>>> In general, the cost of producing two kinds of libraries are quite >>>>>> small, compared to the cost of compiling the source code to object files. >>>>> >>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>> for static and dynamic builds. As proposed in >>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>> >>>>> It's beneficial to be able to build both .so and .a from the same set >>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>> and static JDK difference at runtime, instead of relying on the >>>>> STATIC_BUILD macro. >>>>> >>>>>> >>>>>> Finally, I have looked at how to manipulate symbol visibility. There >>>>>> seems many ways forward, so I feel confident that we can find a good >>>>>> solution. >>>>>> >>>>>> One way forward is to use objcopy to manipulate symbol status >>>>>> (global/local). There is an option --localize-symbol in objcopy, that >>>>>> has been available in objcopy since at least 2.15, which was released >>>>>> 2004, so it should be safe to use. But ideally we should avoid using >>>>>> objcopy and do this as part of the linking process. This should be >>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- >>>>>> see question 5 above. >>>>>> >>>>>> As a fallback, it is also possible to rename symbols, either piecewise >>>>>> or wholesale, using objcopy. There are many ways to do this, using >>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this >>>>>> takes a file with a list of symbols). Thus we can always introduce a >>>>>> "post factum namespace" by renaming symbols. >>>>> >>>>> Renaming or redefining the symbol at build time could cause confusions >>>>> with debugging. That's a concern raised in >>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>> >>>>> Additionally, redefining symbols using tools like objcopy may not >>>>> handle member names referenced in string literals. For example, in >>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>> needed in assembling and SA to reflect the symbol change. >>>>> >>>>>> >>>>>> So in the end, I think it will be fully possible to produce .a files >>>>>> that only has global symbols for the functions that are part of the API >>>>>> exposed by that library, and have all other symbols local, and make this >>>>>> is in a way that is consistent with the rest of the build system. >>>>>> >>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export >>>>>> basically all symbols in hotspot as global. This is not reasonable to do >>>>>> for a static build. The effect of not exporting those symbols will be >>>>>> that SA will not function to 100%. On the other hand, I have no idea if >>>>>> SA works at all with a static build. Have you tested this? Is this part >>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? >>>>> >>>>> We have done some testing with jtreg SA related tests for the fully >>>>> statically linked `javastatic`. >>>>> >>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>> what's the impact on SA. We could do some tests. The other question >>>>> that I raised is the supported gcc versions (for partial linking) >>>>> related to the solution. >>>>> >>>>> Best, >>>>> Jiangli >>>>> >>>>>> >>>>>> /Magnus >>>>>> From nbenalla at openjdk.org Thu May 29 13:42:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 29 May 2025 13:42:34 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v5] In-Reply-To: References: Message-ID: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=04 Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From coleenp at openjdk.org Thu May 29 15:50:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 May 2025 15:50:54 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v5] In-Reply-To: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> References: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> Message-ID: On Thu, 29 May 2025 13:42:34 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - Update release date > - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6 Hotspot changes look good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2878772498 From jianglizhou at google.com Thu May 29 16:57:34 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 29 May 2025 09:57:34 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> Message-ID: On Wed, May 28, 2025 at 10:36?PM David Holmes wrote: > > Hi Jiangli, > > > > On 29/05/2025 3:27 am, Jiangli Zhou wrote: > >>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >> > >> Thumbs up! That seems to be a good direction. Currently in the leyden > >> branch, it first looks up the unique > >> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > >> libraries, then search for the dynamic libraries using the > >> conventional naming when necessary. e.g.: > >> > >> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > >> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > >> > >> When spec supports JNI_OnLoad_ and etc. for dynamic > >> libraries, we may still need to support the conventional naming > >> without the <_lib_name> part for existing libraries out there. > > > > Resuming the conversation on using > > JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > > for dynamically linked JNI & agent libraries. It is related to > > JDK-8350450 [1]: Compile object files once for both static and dynamic > > builds. We have recently enabled building & tier1 testing for > > static-jdk with release binary in GHA on linux-x64. The debug build > > however cannot be enabled in GHA due to space/resource limit (please > > see more details in JDK-8350450). So it's a good time to pick up > > JDK-8350450 related work. Based on discussions with Magnus in > > JDK-8350450 bug comments and separate emails from last year, I'll > > extract the runtime changes from the leyden/hermetic-java-runtime > > branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically > > linked JNI/agent libraries. The work has been broadly tested in our > > internal prototype on JDK 11 and newer versions (linux-x64). > > > > Regarding the spec part, Ron, Alan, Magnus and myself had several > > discussions last year during hermetic Java meetings. The general > > understanding was that using JNI_OnLoad_L (and etc) for dynamically > > linked JDK native libraries requires no JNI/JVMTI spec change. I > > wonder if the following languages should be relaxed a bit to address > > potential questions. Any thoughts? > > I don't know exactly what was discussed, but I don't see how you can not > update the JNI (and other) specifications to do what you want to do, if > that involves invoking JNI_OnLoad_L in the dynamic case instead of > JNI_OnLoad. ?? Hi David, (refreshing my memory based on hermetic Java meeting notes) It's based on the following language in the JNI spec, https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries: Support for Statically Linked Libraries "If dynamically linked library defines JNI_OnLoad_L and/or JNI_OnUnload_L functions, these functions will be ignored." The spec allows JNI_OnLoad_L and etc in dynamically linked libraries. For JDK internal native libraries, the implementation could use these symbols without requiring changing the spec. Ron, Alan, or Magnus, please correct or add any additional info. Best, Jiangli > > David > ----- > > > > From JNI spec [3]: > > > > - JNI_OnLoad/JNI_OnUnload > > Optional function defined by dynamically linked libraries. > > > > LINKAGE: > > Exported from dynamically linked native libraries that contain > > native method implementations. > > > > - JNI_OnLoad_L > > Mandatory function that must be defined by statically linked libraries . > > > > LINKAGE: > > Exported from statically linked native libraries that contain native > > method implementations. > > > > - JNI_OnUnload_L > > Optional function defined by statically linked libraries. > > > > From JVMTI spec [4]: > > > > An agent L whose image has been combined with the VM is defined as > > statically linked if and only if the agent exports a function called > > Agent_OnLoad_L. > > > > [1]: https://bugs.openjdk.org/browse/JDK-8350450 > > [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime > > [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > > [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html > > > > Best, > > Jiangli > > > >> > >>> > >>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>> > >>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >> > >> Thank you for taking this on! Potentially we could consider taking the > >> objcopy to localizing hotspot symbols on unix-like platforms, based on > >> https://github.com/openjdk/jdk/pull/17456 discussions. Additional > >> testing is still needed to verify the solution. > >> > >>> > >>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >> > >> Most of the JDK resources are now supported as hermetic jimage > >> (lib/modules) bundled in the > >> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > >> The remaining sound.properties, ct.sym and .jfc files can be handled > >> later. Overally, that part of the work has confirmed the hermetic > >> jimage bundled solution is robust and helps resolve some of the > >> difficult start-up sequence issues observed when the hermetic resource > >> was implemented using JAR file based solution. > >> > >> It might be a good idea to follow up on the static linking discussion > >> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > >> > >> Thanks! > >> > >> Jiangli > >>> > >>> /Magnus > >>> > >>> > >>> > >>> Thanks! > >>> Jiangli > >>> > >>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>> > >>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>> > >>>>> Hi Magnus, > >>>>> > >>>>> Thanks for looking into this from the build perspective. > >>>>> > >>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>> wrote: > >>>>>> > >>>>>> First some background for build-dev: I have spent some time looking at > >>>>>> the build implications of the Hermetic Java effort, which is part of > >>>>>> Project Leyden. A high-level overview is available here: > >>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source > >>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > >>>>> > >>>>> Some additional hermetic Java related references that are also useful: > >>>>> > >>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>> links to the issues for resolving static linking issues so far > >>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>> including libjvm.a > >>>>> > >>>>>> > >>>>>> Hermetic Java faces several challenges, but the part that is relevant > >>>>>> for the build system is the ability to create static libraries. We've > >>>>>> had this functionality (in three different ways...) for some time, but > >>>>>> it is rather badly implemented. > >>>>>> > >>>>>> As a result of my investigations, I have a bunch of questions. :-) I > >>>>>> have gotten some answers in private discussion, but for the sake of > >>>>>> transparency I will repeat them here, to foster an open dialogue. > >>>>>> > >>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise > >>>>>> is to be able to have jmods which include static libraries (*.a) of the > >>>>>> native code which the module uses, and that the user can then run a > >>>>>> special jlink command to have this linked into a single executable > >>>>>> binary (which also bundles the *.class files and any additional > >>>>>> resources needed)? > >>>>>> > >>>>>> 2. If so, is the idea to create special kinds of static jmods, like > >>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? > >>>>>> Or is the idea that the normal jmod should contain both? > >>>>>> > >>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is > >>>>>> the intention to have jlink call a system-provided ld, or to bundle ld > >>>>>> with jlink, or to reimplement this functionality in Java? > >>>>> > >>>>> I have a similar view as Alan responded in your other email thread. > >>>>> Things are still in the early stage for the general solution. > >>>>> > >>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>> binary contains the following extra artifacts: > >>>>> > >>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>> without additional work for hermetic Java. > >>>>> > >>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>> image (a single image) from the following input (see description on > >>>>> singlejar packaging tool in > >>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>> > >>>>> - A customized launcher (with additional work for hermetic) executable > >>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>> - JDK lib/modules, JDK resource files > >>>>> - Application classes and resource files > >>>>> > >>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>> extracting the .a for linking with the executable. In some systems > >>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>> files. I think we should consider the memory overhead issue. > >>>>> > >>>>> One possibility (as Alan described in his response) is for jlink to > >>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>> ld based on the modules required for the application. > >>>>> > >>>> > >>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>> would need to know the complete linker options and inputs. Those > >>>> include options and inputs related to the application part as well. In > >>>> some usages, it might be easier to handle native linking separately > >>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>> could consider supporting different modes for various usages > >>>> requirements, from static libraries and native linking point of view: > >>>> > >>>> Mode #1 > >>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>> and application natives and dependencies. If the inputs to jlink > >>>> include .jmods, jlink can extract the .a libraries and pass the > >>>> information to ld to link the executable. > >>>> > >>>> Mode #2 > >>>> Support separate .a as jlink input. Jlink could pass the path > >>>> information to the .a libraries and other linker options to ld to > >>>> create the executable. > >>>> > >>>> For both mode #1 and #2, jlink would then use the linker output > >>>> executable to create the final hermetic image. > >>>> > >>>> Mode #3 > >>>> Support a fully linked executable as a jlink input. When a linked > >>>> executable is given to jlink, it can process it directly with other > >>>> JDK data/files to create the final image, without native linking step. > >>>> > >>>> Any other thoughts and considerations? > >>>> > >>>> Best, > >>>> Jiangli > >>>> > >>>>>> > >>>>>> 4. Is the intention is to allow users to create their own jmods with > >>>>>> static libraries, and have these linked in as well? This seems to be the > >>>>>> case. > >>>>> > >>>>> An alternative with less memory overhead could be using application > >>>>> modular JAR and separate .a as the input for jlink. > >>>>> > >>>>>> If that is so, then there will always be the risk for name > >>>>>> collisions, and we can only minimize the risk by making sure any global > >>>>>> names are as unique as possible. > >>>>> > >>>>> Part of the current effort includes resolving the discovered symbol > >>>>> collision issues with static linking. Will respond to your other email > >>>>> on the symbol issue separately later. > >>>>> > >>>>>> > >>>>>> 5. The original implementation of static builds in the JDK, created for > >>>>>> the Mobile project, used a configure flag, --enable-static-builds, to > >>>>>> change the entire behavior of the build system to only produce *.a files > >>>>>> instead of lib*.so. In contrast, the current system is using a special > >>>>>> target instead. > >>>>> > >>>>> I think we would need both configure flag and special target for the > >>>>> static builds. > >>>>> > >>>>>> In my eyes, this is a much worse solution. Apart from > >>>>>> the conceptual principle (if the build should generate static or dynamic > >>>>>> libraries is definitely a property of what a "configuration" means), > >>>>>> this makes it much harder to implement efficiently, since we cannot make > >>>>>> changes in NativeCompilation.gmk, where they are needed. > >>>>> > >>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>> have an internal prototype (not included in > >>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>> objcopy. > >>>>> > >>>>>> > >>>>>> That was not as much a question as a statement. ? But here is the > >>>>>> question: Do you think it would be reasonable to restore the old > >>>>>> behavior but with the new methods, so that we don't use special targets, > >>>>>> but instead tells configure to generate static libraries? I'm thinking > >>>>>> we should have a flag like "--with-library-type=" that can have values > >>>>>> "dynamic" (which is default), "static" or "both". > >>>>> > >>>>> If we want to also build a fully statically linked launcher, maybe > >>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>> both as you suggested also seems to be a good idea. > >>>>> > >>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files > >>>>>> into a single jmod file (see question 2 above), then it definitely is. > >>>>>> In general, the cost of producing two kinds of libraries are quite > >>>>>> small, compared to the cost of compiling the source code to object files. > >>>>> > >>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>> for static and dynamic builds. As proposed in > >>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>> > >>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>> and static JDK difference at runtime, instead of relying on the > >>>>> STATIC_BUILD macro. > >>>>> > >>>>>> > >>>>>> Finally, I have looked at how to manipulate symbol visibility. There > >>>>>> seems many ways forward, so I feel confident that we can find a good > >>>>>> solution. > >>>>>> > >>>>>> One way forward is to use objcopy to manipulate symbol status > >>>>>> (global/local). There is an option --localize-symbol in objcopy, that > >>>>>> has been available in objcopy since at least 2.15, which was released > >>>>>> 2004, so it should be safe to use. But ideally we should avoid using > >>>>>> objcopy and do this as part of the linking process. This should be > >>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- > >>>>>> see question 5 above. > >>>>>> > >>>>>> As a fallback, it is also possible to rename symbols, either piecewise > >>>>>> or wholesale, using objcopy. There are many ways to do this, using > >>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this > >>>>>> takes a file with a list of symbols). Thus we can always introduce a > >>>>>> "post factum namespace" by renaming symbols. > >>>>> > >>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>> with debugging. That's a concern raised in > >>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>> > >>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>> handle member names referenced in string literals. For example, in > >>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>> needed in assembling and SA to reflect the symbol change. > >>>>> > >>>>>> > >>>>>> So in the end, I think it will be fully possible to produce .a files > >>>>>> that only has global symbols for the functions that are part of the API > >>>>>> exposed by that library, and have all other symbols local, and make this > >>>>>> is in a way that is consistent with the rest of the build system. > >>>>>> > >>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export > >>>>>> basically all symbols in hotspot as global. This is not reasonable to do > >>>>>> for a static build. The effect of not exporting those symbols will be > >>>>>> that SA will not function to 100%. On the other hand, I have no idea if > >>>>>> SA works at all with a static build. Have you tested this? Is this part > >>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? > >>>>> > >>>>> We have done some testing with jtreg SA related tests for the fully > >>>>> statically linked `javastatic`. > >>>>> > >>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>> what's the impact on SA. We could do some tests. The other question > >>>>> that I raised is the supported gcc versions (for partial linking) > >>>>> related to the solution. > >>>>> > >>>>> Best, > >>>>> Jiangli > >>>>> > >>>>>> > >>>>>> /Magnus > >>>>>> > From bpb at openjdk.org Thu May 29 19:10:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 29 May 2025 19:10:46 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v14] In-Reply-To: References: Message-ID: <6JakAvYfDIFLQHI8MwxCjvEl-4MR4rQmJzJNGytPQIw=.689b5a9f-c0c6-4dea-8e6b-b668b999e8c0@github.com> > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge - Merge - Merge - Merge - Merge - Merge - 8337143: Minor makefile tweak - 8337143: Clean up to address reviewer comments - Merge - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c - ... and 4 more: https://git.openjdk.org/jdk/compare/79aff26c...95ce13fb ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=13 Stats: 1540 lines in 93 files changed: 774 ins; 668 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From david.holmes at oracle.com Thu May 29 22:16:53 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 May 2025 08:16:53 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> Message-ID: <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> On 30/05/2025 2:57 am, Jiangli Zhou wrote: > On Wed, May 28, 2025 at 10:36?PM David Holmes wrote: >> >> Hi Jiangli, >> >> >> >> On 29/05/2025 3:27 am, Jiangli Zhou wrote: >>>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >>>> >>>> Thumbs up! That seems to be a good direction. Currently in the leyden >>>> branch, it first looks up the unique >>>> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in >>>> libraries, then search for the dynamic libraries using the >>>> conventional naming when necessary. e.g.: >>>> >>>> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a >>>> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 >>>> >>>> When spec supports JNI_OnLoad_ and etc. for dynamic >>>> libraries, we may still need to support the conventional naming >>>> without the <_lib_name> part for existing libraries out there. >>> >>> Resuming the conversation on using >>> JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L >>> for dynamically linked JNI & agent libraries. It is related to >>> JDK-8350450 [1]: Compile object files once for both static and dynamic >>> builds. We have recently enabled building & tier1 testing for >>> static-jdk with release binary in GHA on linux-x64. The debug build >>> however cannot be enabled in GHA due to space/resource limit (please >>> see more details in JDK-8350450). So it's a good time to pick up >>> JDK-8350450 related work. Based on discussions with Magnus in >>> JDK-8350450 bug comments and separate emails from last year, I'll >>> extract the runtime changes from the leyden/hermetic-java-runtime >>> branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically >>> linked JNI/agent libraries. The work has been broadly tested in our >>> internal prototype on JDK 11 and newer versions (linux-x64). >>> >>> Regarding the spec part, Ron, Alan, Magnus and myself had several >>> discussions last year during hermetic Java meetings. The general >>> understanding was that using JNI_OnLoad_L (and etc) for dynamically >>> linked JDK native libraries requires no JNI/JVMTI spec change. I >>> wonder if the following languages should be relaxed a bit to address >>> potential questions. Any thoughts? >> >> I don't know exactly what was discussed, but I don't see how you can not >> update the JNI (and other) specifications to do what you want to do, if >> that involves invoking JNI_OnLoad_L in the dynamic case instead of >> JNI_OnLoad. ?? > > Hi David, > > (refreshing my memory based on hermetic Java meeting notes) > > It's based on the following language in the JNI spec, > https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries: > > Support for Statically Linked Libraries > > "If dynamically linked library defines JNI_OnLoad_L and/or > JNI_OnUnload_L functions, these functions will be ignored." > > The spec allows JNI_OnLoad_L and etc in dynamically linked libraries. > For JDK internal native libraries, the implementation could use these > symbols without requiring changing the spec. Ron, Alan, or Magnus, > please correct or add any additional info. If this is only a convention for internal-use then I agree, no spec change needed. For internal-use-only we can define whatever load/unload hooks we like. David > Best, > Jiangli > > >> >> David >> ----- >> >> >>> From JNI spec [3]: >>> >>> - JNI_OnLoad/JNI_OnUnload >>> Optional function defined by dynamically linked libraries. >>> >>> LINKAGE: >>> Exported from dynamically linked native libraries that contain >>> native method implementations. >>> >>> - JNI_OnLoad_L >>> Mandatory function that must be defined by statically linked libraries . >>> >>> LINKAGE: >>> Exported from statically linked native libraries that contain native >>> method implementations. >>> >>> - JNI_OnUnload_L >>> Optional function defined by statically linked libraries. >>> >>> From JVMTI spec [4]: >>> >>> An agent L whose image has been combined with the VM is defined as >>> statically linked if and only if the agent exports a function called >>> Agent_OnLoad_L. >>> >>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 >>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ >>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html >>> >>> Best, >>> Jiangli >>> >>>> >>>>> >>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>>>> >>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >>>> >>>> Thank you for taking this on! Potentially we could consider taking the >>>> objcopy to localizing hotspot symbols on unix-like platforms, based on >>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional >>>> testing is still needed to verify the solution. >>>> >>>>> >>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >>>> >>>> Most of the JDK resources are now supported as hermetic jimage >>>> (lib/modules) bundled in the >>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. >>>> The remaining sound.properties, ct.sym and .jfc files can be handled >>>> later. Overally, that part of the work has confirmed the hermetic >>>> jimage bundled solution is robust and helps resolve some of the >>>> difficult start-up sequence issues observed when the hermetic resource >>>> was implemented using JAR file based solution. >>>> >>>> It might be a good idea to follow up on the static linking discussion >>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). >>>> >>>> Thanks! >>>> >>>> Jiangli >>>>> >>>>> /Magnus >>>>> >>>>> >>>>> >>>>> Thanks! >>>>> Jiangli >>>>> >>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>>>> >>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>>>> >>>>>>> Hi Magnus, >>>>>>> >>>>>>> Thanks for looking into this from the build perspective. >>>>>>> >>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>>>> wrote: >>>>>>>> >>>>>>>> First some background for build-dev: I have spent some time looking at >>>>>>>> the build implications of the Hermetic Java effort, which is part of >>>>>>>> Project Leyden. A high-level overview is available here: >>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source >>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. >>>>>>> >>>>>>> Some additional hermetic Java related references that are also useful: >>>>>>> >>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>>>> links to the issues for resolving static linking issues so far >>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>>>> building the complete set of static libraries in JDK/VM, particularly >>>>>>> including libjvm.a >>>>>>> >>>>>>>> >>>>>>>> Hermetic Java faces several challenges, but the part that is relevant >>>>>>>> for the build system is the ability to create static libraries. We've >>>>>>>> had this functionality (in three different ways...) for some time, but >>>>>>>> it is rather badly implemented. >>>>>>>> >>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I >>>>>>>> have gotten some answers in private discussion, but for the sake of >>>>>>>> transparency I will repeat them here, to foster an open dialogue. >>>>>>>> >>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise >>>>>>>> is to be able to have jmods which include static libraries (*.a) of the >>>>>>>> native code which the module uses, and that the user can then run a >>>>>>>> special jlink command to have this linked into a single executable >>>>>>>> binary (which also bundles the *.class files and any additional >>>>>>>> resources needed)? >>>>>>>> >>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like >>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? >>>>>>>> Or is the idea that the normal jmod should contain both? >>>>>>>> >>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is >>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld >>>>>>>> with jlink, or to reimplement this functionality in Java? >>>>>>> >>>>>>> I have a similar view as Alan responded in your other email thread. >>>>>>> Things are still in the early stage for the general solution. >>>>>>> >>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>>>> binary contains the following extra artifacts: >>>>>>> >>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>>>> without additional work for hermetic Java. >>>>>>> >>>>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>>>> image (a single image) from the following input (see description on >>>>>>> singlejar packaging tool in >>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>>>> >>>>>>> - A customized launcher (with additional work for hermetic) executable >>>>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>>>> application natives and dependencies (e.g. in .a static libraries) >>>>>>> - JDK lib/modules, JDK resource files >>>>>>> - Application classes and resource files >>>>>>> >>>>>>> Including a JDK library .a into the corresponding .jmod would require >>>>>>> extracting the .a for linking with the executable. In some systems >>>>>>> that may cause memory overhead due to the extracted copy of the .a >>>>>>> files. I think we should consider the memory overhead issue. >>>>>>> >>>>>>> One possibility (as Alan described in his response) is for jlink to >>>>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>>>> ld based on the modules required for the application. >>>>>>> >>>>>> >>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>>>> would need to know the complete linker options and inputs. Those >>>>>> include options and inputs related to the application part as well. In >>>>>> some usages, it might be easier to handle native linking separately >>>>>> and pass the linker output, the executable to jlink directly. Maybe we >>>>>> could consider supporting different modes for various usages >>>>>> requirements, from static libraries and native linking point of view: >>>>>> >>>>>> Mode #1 >>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>>>> and application natives and dependencies. If the inputs to jlink >>>>>> include .jmods, jlink can extract the .a libraries and pass the >>>>>> information to ld to link the executable. >>>>>> >>>>>> Mode #2 >>>>>> Support separate .a as jlink input. Jlink could pass the path >>>>>> information to the .a libraries and other linker options to ld to >>>>>> create the executable. >>>>>> >>>>>> For both mode #1 and #2, jlink would then use the linker output >>>>>> executable to create the final hermetic image. >>>>>> >>>>>> Mode #3 >>>>>> Support a fully linked executable as a jlink input. When a linked >>>>>> executable is given to jlink, it can process it directly with other >>>>>> JDK data/files to create the final image, without native linking step. >>>>>> >>>>>> Any other thoughts and considerations? >>>>>> >>>>>> Best, >>>>>> Jiangli >>>>>> >>>>>>>> >>>>>>>> 4. Is the intention is to allow users to create their own jmods with >>>>>>>> static libraries, and have these linked in as well? This seems to be the >>>>>>>> case. >>>>>>> >>>>>>> An alternative with less memory overhead could be using application >>>>>>> modular JAR and separate .a as the input for jlink. >>>>>>> >>>>>>>> If that is so, then there will always be the risk for name >>>>>>>> collisions, and we can only minimize the risk by making sure any global >>>>>>>> names are as unique as possible. >>>>>>> >>>>>>> Part of the current effort includes resolving the discovered symbol >>>>>>> collision issues with static linking. Will respond to your other email >>>>>>> on the symbol issue separately later. >>>>>>> >>>>>>>> >>>>>>>> 5. The original implementation of static builds in the JDK, created for >>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to >>>>>>>> change the entire behavior of the build system to only produce *.a files >>>>>>>> instead of lib*.so. In contrast, the current system is using a special >>>>>>>> target instead. >>>>>>> >>>>>>> I think we would need both configure flag and special target for the >>>>>>> static builds. >>>>>>> >>>>>>>> In my eyes, this is a much worse solution. Apart from >>>>>>>> the conceptual principle (if the build should generate static or dynamic >>>>>>>> libraries is definitely a property of what a "configuration" means), >>>>>>>> this makes it much harder to implement efficiently, since we cannot make >>>>>>>> changes in NativeCompilation.gmk, where they are needed. >>>>>>> >>>>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>>>> have an internal prototype (not included in >>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>>>> by one of colleagues for localizing symbols in libfreetype using >>>>>>> objcopy. >>>>>>> >>>>>>>> >>>>>>>> That was not as much a question as a statement. ? But here is the >>>>>>>> question: Do you think it would be reasonable to restore the old >>>>>>>> behavior but with the new methods, so that we don't use special targets, >>>>>>>> but instead tells configure to generate static libraries? I'm thinking >>>>>>>> we should have a flag like "--with-library-type=" that can have values >>>>>>>> "dynamic" (which is default), "static" or "both". >>>>>>> >>>>>>> If we want to also build a fully statically linked launcher, maybe >>>>>>> --with-static-java? Being able to configure either dynamic, static or >>>>>>> both as you suggested also seems to be a good idea. >>>>>>> >>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files >>>>>>>> into a single jmod file (see question 2 above), then it definitely is. >>>>>>>> In general, the cost of producing two kinds of libraries are quite >>>>>>>> small, compared to the cost of compiling the source code to object files. >>>>>>> >>>>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>>>> for static and dynamic builds. As proposed in >>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>>>> >>>>>>> It's beneficial to be able to build both .so and .a from the same set >>>>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>>>> and static JDK difference at runtime, instead of relying on the >>>>>>> STATIC_BUILD macro. >>>>>>> >>>>>>>> >>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There >>>>>>>> seems many ways forward, so I feel confident that we can find a good >>>>>>>> solution. >>>>>>>> >>>>>>>> One way forward is to use objcopy to manipulate symbol status >>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that >>>>>>>> has been available in objcopy since at least 2.15, which was released >>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using >>>>>>>> objcopy and do this as part of the linking process. This should be >>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- >>>>>>>> see question 5 above. >>>>>>>> >>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise >>>>>>>> or wholesale, using objcopy. There are many ways to do this, using >>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this >>>>>>>> takes a file with a list of symbols). Thus we can always introduce a >>>>>>>> "post factum namespace" by renaming symbols. >>>>>>> >>>>>>> Renaming or redefining the symbol at build time could cause confusions >>>>>>> with debugging. That's a concern raised in >>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>>>> >>>>>>> Additionally, redefining symbols using tools like objcopy may not >>>>>>> handle member names referenced in string literals. For example, in >>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>>>> needed in assembling and SA to reflect the symbol change. >>>>>>> >>>>>>>> >>>>>>>> So in the end, I think it will be fully possible to produce .a files >>>>>>>> that only has global symbols for the functions that are part of the API >>>>>>>> exposed by that library, and have all other symbols local, and make this >>>>>>>> is in a way that is consistent with the rest of the build system. >>>>>>>> >>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export >>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do >>>>>>>> for a static build. The effect of not exporting those symbols will be >>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if >>>>>>>> SA works at all with a static build. Have you tested this? Is this part >>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? >>>>>>> >>>>>>> We have done some testing with jtreg SA related tests for the fully >>>>>>> statically linked `javastatic`. >>>>>>> >>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>>>> what's the impact on SA. We could do some tests. The other question >>>>>>> that I raised is the supported gcc versions (for partial linking) >>>>>>> related to the solution. >>>>>>> >>>>>>> Best, >>>>>>> Jiangli >>>>>>> >>>>>>>> >>>>>>>> /Magnus >>>>>>>> >> From jianglizhou at google.com Thu May 29 23:26:35 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Thu, 29 May 2025 16:26:35 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> Message-ID: On Thu, May 29, 2025 at 3:17?PM David Holmes wrote: > > On 30/05/2025 2:57 am, Jiangli Zhou wrote: > > On Wed, May 28, 2025 at 10:36?PM David Holmes wrote: > >> > >> Hi Jiangli, > >> > >> > >> > >> On 29/05/2025 3:27 am, Jiangli Zhou wrote: > >>>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >>>> > >>>> Thumbs up! That seems to be a good direction. Currently in the leyden > >>>> branch, it first looks up the unique > >>>> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > >>>> libraries, then search for the dynamic libraries using the > >>>> conventional naming when necessary. e.g.: > >>>> > >>>> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > >>>> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > >>>> > >>>> When spec supports JNI_OnLoad_ and etc. for dynamic > >>>> libraries, we may still need to support the conventional naming > >>>> without the <_lib_name> part for existing libraries out there. > >>> > >>> Resuming the conversation on using > >>> JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > >>> for dynamically linked JNI & agent libraries. It is related to > >>> JDK-8350450 [1]: Compile object files once for both static and dynamic > >>> builds. We have recently enabled building & tier1 testing for > >>> static-jdk with release binary in GHA on linux-x64. The debug build > >>> however cannot be enabled in GHA due to space/resource limit (please > >>> see more details in JDK-8350450). So it's a good time to pick up > >>> JDK-8350450 related work. Based on discussions with Magnus in > >>> JDK-8350450 bug comments and separate emails from last year, I'll > >>> extract the runtime changes from the leyden/hermetic-java-runtime > >>> branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically > >>> linked JNI/agent libraries. The work has been broadly tested in our > >>> internal prototype on JDK 11 and newer versions (linux-x64). > >>> > >>> Regarding the spec part, Ron, Alan, Magnus and myself had several > >>> discussions last year during hermetic Java meetings. The general > >>> understanding was that using JNI_OnLoad_L (and etc) for dynamically > >>> linked JDK native libraries requires no JNI/JVMTI spec change. I > >>> wonder if the following languages should be relaxed a bit to address > >>> potential questions. Any thoughts? > >> > >> I don't know exactly what was discussed, but I don't see how you can not > >> update the JNI (and other) specifications to do what you want to do, if > >> that involves invoking JNI_OnLoad_L in the dynamic case instead of > >> JNI_OnLoad. ?? > > > > Hi David, > > > > (refreshing my memory based on hermetic Java meeting notes) > > > > It's based on the following language in the JNI spec, > > https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries: > > > > Support for Statically Linked Libraries > > > > "If dynamically linked library defines JNI_OnLoad_L and/or > > JNI_OnUnload_L functions, these functions will be ignored." > > > > The spec allows JNI_OnLoad_L and etc in dynamically linked libraries. > > For JDK internal native libraries, the implementation could use these > > symbols without requiring changing the spec. Ron, Alan, or Magnus, > > please correct or add any additional info. > > If this is only a convention for internal-use then I agree, no spec > change needed. For internal-use-only we can define whatever load/unload > hooks we like. Thanks, David. Yeah, that seems to be the rationale with using JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L in JDK native libraries, before any spec update. I just thought of one more thing related to the discussion now. Any concern if the implementation does not ignore JNI_OnLoad_L and etc if they are defined application's dynamically linked native libraries? Or that's unspecified behavior and it's up to the implement to decide? Thanks! Jiangli > > David > > > Best, > > Jiangli > > > > > >> > >> David > >> ----- > >> > >> > >>> From JNI spec [3]: > >>> > >>> - JNI_OnLoad/JNI_OnUnload > >>> Optional function defined by dynamically linked libraries. > >>> > >>> LINKAGE: > >>> Exported from dynamically linked native libraries that contain > >>> native method implementations. > >>> > >>> - JNI_OnLoad_L > >>> Mandatory function that must be defined by statically linked libraries . > >>> > >>> LINKAGE: > >>> Exported from statically linked native libraries that contain native > >>> method implementations. > >>> > >>> - JNI_OnUnload_L > >>> Optional function defined by statically linked libraries. > >>> > >>> From JVMTI spec [4]: > >>> > >>> An agent L whose image has been combined with the VM is defined as > >>> statically linked if and only if the agent exports a function called > >>> Agent_OnLoad_L. > >>> > >>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 > >>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > >>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html > >>> > >>> Best, > >>> Jiangli > >>> > >>>> > >>>>> > >>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>>>> > >>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >>>> > >>>> Thank you for taking this on! Potentially we could consider taking the > >>>> objcopy to localizing hotspot symbols on unix-like platforms, based on > >>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional > >>>> testing is still needed to verify the solution. > >>>> > >>>>> > >>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >>>> > >>>> Most of the JDK resources are now supported as hermetic jimage > >>>> (lib/modules) bundled in the > >>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > >>>> The remaining sound.properties, ct.sym and .jfc files can be handled > >>>> later. Overally, that part of the work has confirmed the hermetic > >>>> jimage bundled solution is robust and helps resolve some of the > >>>> difficult start-up sequence issues observed when the hermetic resource > >>>> was implemented using JAR file based solution. > >>>> > >>>> It might be a good idea to follow up on the static linking discussion > >>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > >>>> > >>>> Thanks! > >>>> > >>>> Jiangli > >>>>> > >>>>> /Magnus > >>>>> > >>>>> > >>>>> > >>>>> Thanks! > >>>>> Jiangli > >>>>> > >>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>>>> > >>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>>>> > >>>>>>> Hi Magnus, > >>>>>>> > >>>>>>> Thanks for looking into this from the build perspective. > >>>>>>> > >>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>>>> wrote: > >>>>>>>> > >>>>>>>> First some background for build-dev: I have spent some time looking at > >>>>>>>> the build implications of the Hermetic Java effort, which is part of > >>>>>>>> Project Leyden. A high-level overview is available here: > >>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source > >>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > >>>>>>> > >>>>>>> Some additional hermetic Java related references that are also useful: > >>>>>>> > >>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>>>> links to the issues for resolving static linking issues so far > >>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>>>> including libjvm.a > >>>>>>> > >>>>>>>> > >>>>>>>> Hermetic Java faces several challenges, but the part that is relevant > >>>>>>>> for the build system is the ability to create static libraries. We've > >>>>>>>> had this functionality (in three different ways...) for some time, but > >>>>>>>> it is rather badly implemented. > >>>>>>>> > >>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I > >>>>>>>> have gotten some answers in private discussion, but for the sake of > >>>>>>>> transparency I will repeat them here, to foster an open dialogue. > >>>>>>>> > >>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise > >>>>>>>> is to be able to have jmods which include static libraries (*.a) of the > >>>>>>>> native code which the module uses, and that the user can then run a > >>>>>>>> special jlink command to have this linked into a single executable > >>>>>>>> binary (which also bundles the *.class files and any additional > >>>>>>>> resources needed)? > >>>>>>>> > >>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like > >>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? > >>>>>>>> Or is the idea that the normal jmod should contain both? > >>>>>>>> > >>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is > >>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld > >>>>>>>> with jlink, or to reimplement this functionality in Java? > >>>>>>> > >>>>>>> I have a similar view as Alan responded in your other email thread. > >>>>>>> Things are still in the early stage for the general solution. > >>>>>>> > >>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>>>> binary contains the following extra artifacts: > >>>>>>> > >>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>>>> without additional work for hermetic Java. > >>>>>>> > >>>>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>>>> image (a single image) from the following input (see description on > >>>>>>> singlejar packaging tool in > >>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>>>> > >>>>>>> - A customized launcher (with additional work for hermetic) executable > >>>>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>>>> - JDK lib/modules, JDK resource files > >>>>>>> - Application classes and resource files > >>>>>>> > >>>>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>>>> extracting the .a for linking with the executable. In some systems > >>>>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>>>> files. I think we should consider the memory overhead issue. > >>>>>>> > >>>>>>> One possibility (as Alan described in his response) is for jlink to > >>>>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>>>> ld based on the modules required for the application. > >>>>>>> > >>>>>> > >>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>>>> would need to know the complete linker options and inputs. Those > >>>>>> include options and inputs related to the application part as well. In > >>>>>> some usages, it might be easier to handle native linking separately > >>>>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>>>> could consider supporting different modes for various usages > >>>>>> requirements, from static libraries and native linking point of view: > >>>>>> > >>>>>> Mode #1 > >>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>>>> and application natives and dependencies. If the inputs to jlink > >>>>>> include .jmods, jlink can extract the .a libraries and pass the > >>>>>> information to ld to link the executable. > >>>>>> > >>>>>> Mode #2 > >>>>>> Support separate .a as jlink input. Jlink could pass the path > >>>>>> information to the .a libraries and other linker options to ld to > >>>>>> create the executable. > >>>>>> > >>>>>> For both mode #1 and #2, jlink would then use the linker output > >>>>>> executable to create the final hermetic image. > >>>>>> > >>>>>> Mode #3 > >>>>>> Support a fully linked executable as a jlink input. When a linked > >>>>>> executable is given to jlink, it can process it directly with other > >>>>>> JDK data/files to create the final image, without native linking step. > >>>>>> > >>>>>> Any other thoughts and considerations? > >>>>>> > >>>>>> Best, > >>>>>> Jiangli > >>>>>> > >>>>>>>> > >>>>>>>> 4. Is the intention is to allow users to create their own jmods with > >>>>>>>> static libraries, and have these linked in as well? This seems to be the > >>>>>>>> case. > >>>>>>> > >>>>>>> An alternative with less memory overhead could be using application > >>>>>>> modular JAR and separate .a as the input for jlink. > >>>>>>> > >>>>>>>> If that is so, then there will always be the risk for name > >>>>>>>> collisions, and we can only minimize the risk by making sure any global > >>>>>>>> names are as unique as possible. > >>>>>>> > >>>>>>> Part of the current effort includes resolving the discovered symbol > >>>>>>> collision issues with static linking. Will respond to your other email > >>>>>>> on the symbol issue separately later. > >>>>>>> > >>>>>>>> > >>>>>>>> 5. The original implementation of static builds in the JDK, created for > >>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to > >>>>>>>> change the entire behavior of the build system to only produce *.a files > >>>>>>>> instead of lib*.so. In contrast, the current system is using a special > >>>>>>>> target instead. > >>>>>>> > >>>>>>> I think we would need both configure flag and special target for the > >>>>>>> static builds. > >>>>>>> > >>>>>>>> In my eyes, this is a much worse solution. Apart from > >>>>>>>> the conceptual principle (if the build should generate static or dynamic > >>>>>>>> libraries is definitely a property of what a "configuration" means), > >>>>>>>> this makes it much harder to implement efficiently, since we cannot make > >>>>>>>> changes in NativeCompilation.gmk, where they are needed. > >>>>>>> > >>>>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>>>> have an internal prototype (not included in > >>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>>>> objcopy. > >>>>>>> > >>>>>>>> > >>>>>>>> That was not as much a question as a statement. ? But here is the > >>>>>>>> question: Do you think it would be reasonable to restore the old > >>>>>>>> behavior but with the new methods, so that we don't use special targets, > >>>>>>>> but instead tells configure to generate static libraries? I'm thinking > >>>>>>>> we should have a flag like "--with-library-type=" that can have values > >>>>>>>> "dynamic" (which is default), "static" or "both". > >>>>>>> > >>>>>>> If we want to also build a fully statically linked launcher, maybe > >>>>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>>>> both as you suggested also seems to be a good idea. > >>>>>>> > >>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files > >>>>>>>> into a single jmod file (see question 2 above), then it definitely is. > >>>>>>>> In general, the cost of producing two kinds of libraries are quite > >>>>>>>> small, compared to the cost of compiling the source code to object files. > >>>>>>> > >>>>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>>>> for static and dynamic builds. As proposed in > >>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>>>> > >>>>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>>>> and static JDK difference at runtime, instead of relying on the > >>>>>>> STATIC_BUILD macro. > >>>>>>> > >>>>>>>> > >>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There > >>>>>>>> seems many ways forward, so I feel confident that we can find a good > >>>>>>>> solution. > >>>>>>>> > >>>>>>>> One way forward is to use objcopy to manipulate symbol status > >>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that > >>>>>>>> has been available in objcopy since at least 2.15, which was released > >>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using > >>>>>>>> objcopy and do this as part of the linking process. This should be > >>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- > >>>>>>>> see question 5 above. > >>>>>>>> > >>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise > >>>>>>>> or wholesale, using objcopy. There are many ways to do this, using > >>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this > >>>>>>>> takes a file with a list of symbols). Thus we can always introduce a > >>>>>>>> "post factum namespace" by renaming symbols. > >>>>>>> > >>>>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>>>> with debugging. That's a concern raised in > >>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>>>> > >>>>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>>>> handle member names referenced in string literals. For example, in > >>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>>>> needed in assembling and SA to reflect the symbol change. > >>>>>>> > >>>>>>>> > >>>>>>>> So in the end, I think it will be fully possible to produce .a files > >>>>>>>> that only has global symbols for the functions that are part of the API > >>>>>>>> exposed by that library, and have all other symbols local, and make this > >>>>>>>> is in a way that is consistent with the rest of the build system. > >>>>>>>> > >>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export > >>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do > >>>>>>>> for a static build. The effect of not exporting those symbols will be > >>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if > >>>>>>>> SA works at all with a static build. Have you tested this? Is this part > >>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? > >>>>>>> > >>>>>>> We have done some testing with jtreg SA related tests for the fully > >>>>>>> statically linked `javastatic`. > >>>>>>> > >>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>>>> what's the impact on SA. We could do some tests. The other question > >>>>>>> that I raised is the supported gcc versions (for partial linking) > >>>>>>> related to the solution. > >>>>>>> > >>>>>>> Best, > >>>>>>> Jiangli > >>>>>>> > >>>>>>>> > >>>>>>>> /Magnus > >>>>>>>> > >> > From david.holmes at oracle.com Fri May 30 06:54:02 2025 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 May 2025 16:54:02 +1000 Subject: Questions about the Hermetic Java project In-Reply-To: References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> Message-ID: <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> On 30/05/2025 9:26 am, Jiangli Zhou wrote: > On Thu, May 29, 2025 at 3:17?PM David Holmes wrote: >> >> On 30/05/2025 2:57 am, Jiangli Zhou wrote: >>> On Wed, May 28, 2025 at 10:36?PM David Holmes wrote: >>>> >>>> Hi Jiangli, >>>> >>>> >>>> >>>> On 29/05/2025 3:27 am, Jiangli Zhou wrote: >>>>>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. >>>>>> >>>>>> Thumbs up! That seems to be a good direction. Currently in the leyden >>>>>> branch, it first looks up the unique >>>>>> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in >>>>>> libraries, then search for the dynamic libraries using the >>>>>> conventional naming when necessary. e.g.: >>>>>> >>>>>> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a >>>>>> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 >>>>>> >>>>>> When spec supports JNI_OnLoad_ and etc. for dynamic >>>>>> libraries, we may still need to support the conventional naming >>>>>> without the <_lib_name> part for existing libraries out there. >>>>> >>>>> Resuming the conversation on using >>>>> JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L >>>>> for dynamically linked JNI & agent libraries. It is related to >>>>> JDK-8350450 [1]: Compile object files once for both static and dynamic >>>>> builds. We have recently enabled building & tier1 testing for >>>>> static-jdk with release binary in GHA on linux-x64. The debug build >>>>> however cannot be enabled in GHA due to space/resource limit (please >>>>> see more details in JDK-8350450). So it's a good time to pick up >>>>> JDK-8350450 related work. Based on discussions with Magnus in >>>>> JDK-8350450 bug comments and separate emails from last year, I'll >>>>> extract the runtime changes from the leyden/hermetic-java-runtime >>>>> branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically >>>>> linked JNI/agent libraries. The work has been broadly tested in our >>>>> internal prototype on JDK 11 and newer versions (linux-x64). >>>>> >>>>> Regarding the spec part, Ron, Alan, Magnus and myself had several >>>>> discussions last year during hermetic Java meetings. The general >>>>> understanding was that using JNI_OnLoad_L (and etc) for dynamically >>>>> linked JDK native libraries requires no JNI/JVMTI spec change. I >>>>> wonder if the following languages should be relaxed a bit to address >>>>> potential questions. Any thoughts? >>>> >>>> I don't know exactly what was discussed, but I don't see how you can not >>>> update the JNI (and other) specifications to do what you want to do, if >>>> that involves invoking JNI_OnLoad_L in the dynamic case instead of >>>> JNI_OnLoad. ?? >>> >>> Hi David, >>> >>> (refreshing my memory based on hermetic Java meeting notes) >>> >>> It's based on the following language in the JNI spec, >>> https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries: >>> >>> Support for Statically Linked Libraries >>> >>> "If dynamically linked library defines JNI_OnLoad_L and/or >>> JNI_OnUnload_L functions, these functions will be ignored." >>> >>> The spec allows JNI_OnLoad_L and etc in dynamically linked libraries. >>> For JDK internal native libraries, the implementation could use these >>> symbols without requiring changing the spec. Ron, Alan, or Magnus, >>> please correct or add any additional info. >> >> If this is only a convention for internal-use then I agree, no spec >> change needed. For internal-use-only we can define whatever load/unload >> hooks we like. > > Thanks, David. Yeah, that seems to be the rationale with using > JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > in JDK native libraries, before any spec update. > > I just thought of one more thing related to the discussion now. Any > concern if the implementation does not ignore JNI_OnLoad_L and etc if > they are defined application's dynamically linked native libraries? Or > that's unspecified behavior and it's up to the implement to decide? For Internal libraries or external? For external you have to follow the spec - if both methods exist you only want to execute one of them. David ----- > Thanks! > Jiangli >> >> David >> >>> Best, >>> Jiangli >>> >>> >>>> >>>> David >>>> ----- >>>> >>>> >>>>> From JNI spec [3]: >>>>> >>>>> - JNI_OnLoad/JNI_OnUnload >>>>> Optional function defined by dynamically linked libraries. >>>>> >>>>> LINKAGE: >>>>> Exported from dynamically linked native libraries that contain >>>>> native method implementations. >>>>> >>>>> - JNI_OnLoad_L >>>>> Mandatory function that must be defined by statically linked libraries . >>>>> >>>>> LINKAGE: >>>>> Exported from statically linked native libraries that contain native >>>>> method implementations. >>>>> >>>>> - JNI_OnUnload_L >>>>> Optional function defined by statically linked libraries. >>>>> >>>>> From JVMTI spec [4]: >>>>> >>>>> An agent L whose image has been combined with the VM is defined as >>>>> statically linked if and only if the agent exports a function called >>>>> Agent_OnLoad_L. >>>>> >>>>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 >>>>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ >>>>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html >>>>> >>>>> Best, >>>>> Jiangli >>>>> >>>>>> >>>>>>> >>>>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. >>>>>>> >>>>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. >>>>>> >>>>>> Thank you for taking this on! Potentially we could consider taking the >>>>>> objcopy to localizing hotspot symbols on unix-like platforms, based on >>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional >>>>>> testing is still needed to verify the solution. >>>>>> >>>>>>> >>>>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. >>>>>> >>>>>> Most of the JDK resources are now supported as hermetic jimage >>>>>> (lib/modules) bundled in the >>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. >>>>>> The remaining sound.properties, ct.sym and .jfc files can be handled >>>>>> later. Overally, that part of the work has confirmed the hermetic >>>>>> jimage bundled solution is robust and helps resolve some of the >>>>>> difficult start-up sequence issues observed when the hermetic resource >>>>>> was implemented using JAR file based solution. >>>>>> >>>>>> It might be a good idea to follow up on the static linking discussion >>>>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). >>>>>> >>>>>> Thanks! >>>>>> >>>>>> Jiangli >>>>>>> >>>>>>> /Magnus >>>>>>> >>>>>>> >>>>>>> >>>>>>> Thanks! >>>>>>> Jiangli >>>>>>> >>>>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: >>>>>>>> >>>>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: >>>>>>>>> >>>>>>>>> Hi Magnus, >>>>>>>>> >>>>>>>>> Thanks for looking into this from the build perspective. >>>>>>>>> >>>>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie >>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>> First some background for build-dev: I have spent some time looking at >>>>>>>>>> the build implications of the Hermetic Java effort, which is part of >>>>>>>>>> Project Leyden. A high-level overview is available here: >>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source >>>>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. >>>>>>>>> >>>>>>>>> Some additional hermetic Java related references that are also useful: >>>>>>>>> >>>>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that >>>>>>>>> links to the issues for resolving static linking issues so far >>>>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for >>>>>>>>> building the complete set of static libraries in JDK/VM, particularly >>>>>>>>> including libjvm.a >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Hermetic Java faces several challenges, but the part that is relevant >>>>>>>>>> for the build system is the ability to create static libraries. We've >>>>>>>>>> had this functionality (in three different ways...) for some time, but >>>>>>>>>> it is rather badly implemented. >>>>>>>>>> >>>>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I >>>>>>>>>> have gotten some answers in private discussion, but for the sake of >>>>>>>>>> transparency I will repeat them here, to foster an open dialogue. >>>>>>>>>> >>>>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise >>>>>>>>>> is to be able to have jmods which include static libraries (*.a) of the >>>>>>>>>> native code which the module uses, and that the user can then run a >>>>>>>>>> special jlink command to have this linked into a single executable >>>>>>>>>> binary (which also bundles the *.class files and any additional >>>>>>>>>> resources needed)? >>>>>>>>>> >>>>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like >>>>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? >>>>>>>>>> Or is the idea that the normal jmod should contain both? >>>>>>>>>> >>>>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is >>>>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld >>>>>>>>>> with jlink, or to reimplement this functionality in Java? >>>>>>>>> >>>>>>>>> I have a similar view as Alan responded in your other email thread. >>>>>>>>> Things are still in the early stage for the general solution. >>>>>>>>> >>>>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime >>>>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK >>>>>>>>> binary contains the following extra artifacts: >>>>>>>>> >>>>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries >>>>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked >>>>>>>>> with the selected JDK .a libraries (e.g. it currently statically link >>>>>>>>> with the headless) and libjvm.a. It's the standard Java launcher >>>>>>>>> without additional work for hermetic Java. >>>>>>>>> >>>>>>>>> In our prototype for hermetic Java, we build the hermetic executable >>>>>>>>> image (a single image) from the following input (see description on >>>>>>>>> singlejar packaging tool in >>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): >>>>>>>>> >>>>>>>>> - A customized launcher (with additional work for hermetic) executable >>>>>>>>> fully statically linked with JDK/VM static libraries (.a files), >>>>>>>>> application natives and dependencies (e.g. in .a static libraries) >>>>>>>>> - JDK lib/modules, JDK resource files >>>>>>>>> - Application classes and resource files >>>>>>>>> >>>>>>>>> Including a JDK library .a into the corresponding .jmod would require >>>>>>>>> extracting the .a for linking with the executable. In some systems >>>>>>>>> that may cause memory overhead due to the extracted copy of the .a >>>>>>>>> files. I think we should consider the memory overhead issue. >>>>>>>>> >>>>>>>>> One possibility (as Alan described in his response) is for jlink to >>>>>>>>> invoke the ld on the build system. jlink could pass the needed JDK >>>>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to >>>>>>>>> ld based on the modules required for the application. >>>>>>>>> >>>>>>>> >>>>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it >>>>>>>> would need to know the complete linker options and inputs. Those >>>>>>>> include options and inputs related to the application part as well. In >>>>>>>> some usages, it might be easier to handle native linking separately >>>>>>>> and pass the linker output, the executable to jlink directly. Maybe we >>>>>>>> could consider supporting different modes for various usages >>>>>>>> requirements, from static libraries and native linking point of view: >>>>>>>> >>>>>>>> Mode #1 >>>>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a >>>>>>>> and application natives and dependencies. If the inputs to jlink >>>>>>>> include .jmods, jlink can extract the .a libraries and pass the >>>>>>>> information to ld to link the executable. >>>>>>>> >>>>>>>> Mode #2 >>>>>>>> Support separate .a as jlink input. Jlink could pass the path >>>>>>>> information to the .a libraries and other linker options to ld to >>>>>>>> create the executable. >>>>>>>> >>>>>>>> For both mode #1 and #2, jlink would then use the linker output >>>>>>>> executable to create the final hermetic image. >>>>>>>> >>>>>>>> Mode #3 >>>>>>>> Support a fully linked executable as a jlink input. When a linked >>>>>>>> executable is given to jlink, it can process it directly with other >>>>>>>> JDK data/files to create the final image, without native linking step. >>>>>>>> >>>>>>>> Any other thoughts and considerations? >>>>>>>> >>>>>>>> Best, >>>>>>>> Jiangli >>>>>>>> >>>>>>>>>> >>>>>>>>>> 4. Is the intention is to allow users to create their own jmods with >>>>>>>>>> static libraries, and have these linked in as well? This seems to be the >>>>>>>>>> case. >>>>>>>>> >>>>>>>>> An alternative with less memory overhead could be using application >>>>>>>>> modular JAR and separate .a as the input for jlink. >>>>>>>>> >>>>>>>>>> If that is so, then there will always be the risk for name >>>>>>>>>> collisions, and we can only minimize the risk by making sure any global >>>>>>>>>> names are as unique as possible. >>>>>>>>> >>>>>>>>> Part of the current effort includes resolving the discovered symbol >>>>>>>>> collision issues with static linking. Will respond to your other email >>>>>>>>> on the symbol issue separately later. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> 5. The original implementation of static builds in the JDK, created for >>>>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to >>>>>>>>>> change the entire behavior of the build system to only produce *.a files >>>>>>>>>> instead of lib*.so. In contrast, the current system is using a special >>>>>>>>>> target instead. >>>>>>>>> >>>>>>>>> I think we would need both configure flag and special target for the >>>>>>>>> static builds. >>>>>>>>> >>>>>>>>>> In my eyes, this is a much worse solution. Apart from >>>>>>>>>> the conceptual principle (if the build should generate static or dynamic >>>>>>>>>> libraries is definitely a property of what a "configuration" means), >>>>>>>>>> this makes it much harder to implement efficiently, since we cannot make >>>>>>>>>> changes in NativeCompilation.gmk, where they are needed. >>>>>>>>> >>>>>>>>> For the potential objcopy work to resolve symbol issues, we can add >>>>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We >>>>>>>>> have an internal prototype (not included in >>>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done >>>>>>>>> by one of colleagues for localizing symbols in libfreetype using >>>>>>>>> objcopy. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> That was not as much a question as a statement. ? But here is the >>>>>>>>>> question: Do you think it would be reasonable to restore the old >>>>>>>>>> behavior but with the new methods, so that we don't use special targets, >>>>>>>>>> but instead tells configure to generate static libraries? I'm thinking >>>>>>>>>> we should have a flag like "--with-library-type=" that can have values >>>>>>>>>> "dynamic" (which is default), "static" or "both". >>>>>>>>> >>>>>>>>> If we want to also build a fully statically linked launcher, maybe >>>>>>>>> --with-static-java? Being able to configure either dynamic, static or >>>>>>>>> both as you suggested also seems to be a good idea. >>>>>>>>> >>>>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files >>>>>>>>>> into a single jmod file (see question 2 above), then it definitely is. >>>>>>>>>> In general, the cost of producing two kinds of libraries are quite >>>>>>>>>> small, compared to the cost of compiling the source code to object files. >>>>>>>>> >>>>>>>>> Completely agree. It would be good to avoid recompiling the .o file >>>>>>>>> for static and dynamic builds. As proposed in >>>>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: >>>>>>>>> >>>>>>>>> It's beneficial to be able to build both .so and .a from the same set >>>>>>>>> of .o files. That would involve some changes to handle the dynamic JDK >>>>>>>>> and static JDK difference at runtime, instead of relying on the >>>>>>>>> STATIC_BUILD macro. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There >>>>>>>>>> seems many ways forward, so I feel confident that we can find a good >>>>>>>>>> solution. >>>>>>>>>> >>>>>>>>>> One way forward is to use objcopy to manipulate symbol status >>>>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that >>>>>>>>>> has been available in objcopy since at least 2.15, which was released >>>>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using >>>>>>>>>> objcopy and do this as part of the linking process. This should be >>>>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- >>>>>>>>>> see question 5 above. >>>>>>>>>> >>>>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise >>>>>>>>>> or wholesale, using objcopy. There are many ways to do this, using >>>>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this >>>>>>>>>> takes a file with a list of symbols). Thus we can always introduce a >>>>>>>>>> "post factum namespace" by renaming symbols. >>>>>>>>> >>>>>>>>> Renaming or redefining the symbol at build time could cause confusions >>>>>>>>> with debugging. That's a concern raised in >>>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. >>>>>>>>> >>>>>>>>> Additionally, redefining symbols using tools like objcopy may not >>>>>>>>> handle member names referenced in string literals. For example, in >>>>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are >>>>>>>>> needed in assembling and SA to reflect the symbol change. >>>>>>>>> >>>>>>>>>> >>>>>>>>>> So in the end, I think it will be fully possible to produce .a files >>>>>>>>>> that only has global symbols for the functions that are part of the API >>>>>>>>>> exposed by that library, and have all other symbols local, and make this >>>>>>>>>> is in a way that is consistent with the rest of the build system. >>>>>>>>>> >>>>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export >>>>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do >>>>>>>>>> for a static build. The effect of not exporting those symbols will be >>>>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if >>>>>>>>>> SA works at all with a static build. Have you tested this? Is this part >>>>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? >>>>>>>>> >>>>>>>>> We have done some testing with jtreg SA related tests for the fully >>>>>>>>> statically linked `javastatic`. >>>>>>>>> >>>>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear >>>>>>>>> what's the impact on SA. We could do some tests. The other question >>>>>>>>> that I raised is the supported gcc versions (for partial linking) >>>>>>>>> related to the solution. >>>>>>>>> >>>>>>>>> Best, >>>>>>>>> Jiangli >>>>>>>>> >>>>>>>>>> >>>>>>>>>> /Magnus >>>>>>>>>> >>>> >> From egahlin at openjdk.org Fri May 30 08:46:55 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 May 2025 08:46:55 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:59:05 GMT, Magnus Ihse Bursie wrote: > The file types .rej and .orig are often created by diff tools. Adding them to .gitignore will help people from mistakenly committing these files. > > See https://github.com/openjdk/jdk/pull/25306#discussion_r2102407122 for an example of where this happened. Not sure this is helping. When I do "git status" now, I can't see the *.rej files, so I have to remove the filter from .gitignore. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2921641404 From vyazici at openjdk.org Fri May 30 10:51:02 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 30 May 2025 10:51:02 GMT Subject: RFR: 8357996: Use "stdin.encoding" for reading System.in with InputStreamReader/Scanner [build/tools] Message-ID: Passes the `Charset` read from the `stdin.encoding` system property while creating `InputStreamReader` or `Scanner` instances for `System.in`. `stdin.encoding` is a recently added property for Java 25 in [JDK-8350703](https://bugs.openjdk.org/browse/JDK-8350703). Employing it throughout the entire code base is addressed by the parent ticket [JDK-8356893](https://bugs.openjdk.org/browse/JDK-8356893). JDK-8357996 this PR is addressing is a sub-task of JDK-8356893 and is concerned with only areas related to build and tools. ------------- Commit messages: - Discard changes unrelated with build and tools - Revert superfluous changes - Revert changes to 3rd parties in `com/sun/org/apache` - Revert `PandocFilter` changes - Use `stdin.encoding` in `InputStreamReader` and `Scanner` instantiations Changes: https://git.openjdk.org/jdk/pull/25541/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25541&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357996 Stats: 9 lines in 4 files changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25541.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25541/head:pull/25541 PR: https://git.openjdk.org/jdk/pull/25541 From erikj at openjdk.org Fri May 30 13:07:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 May 2025 13:07:59 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Fri, 30 May 2025 08:44:37 GMT, Erik Gahlin wrote: > Not sure this is helping. > > When I do "git status" now, I can't see the *.rej files, so I have to remove the filter from .gitignore. To see ignored files, there is a switch: git status --ignored It will show all ignored files and directories though so includes the build dir, but could still help you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2922346540 From ihse at openjdk.org Fri May 30 20:37:04 2025 From: ihse at openjdk.org (Magnus Ihse Bursie) Date: Fri, 30 May 2025 20:37:04 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Fri, 30 May 2025 13:05:15 GMT, Erik Joelsson wrote: > When I do "git status" now, I can't see the *.rej files Why would you want to do that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2923427385 From egahlin at openjdk.org Fri May 30 21:02:06 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Fri, 30 May 2025 21:02:06 GMT Subject: RFR: 8357920: Add .rej and .orig to .gitignore In-Reply-To: References: Message-ID: On Fri, 30 May 2025 20:34:37 GMT, Magnus Ihse Bursie wrote: > Why would you want to do that? To see what I couldn't merge or apply without a conflict. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25474#issuecomment-2923468742 From jianglizhou at google.com Fri May 30 21:20:40 2025 From: jianglizhou at google.com (Jiangli Zhou) Date: Fri, 30 May 2025 14:20:40 -0700 Subject: Questions about the Hermetic Java project In-Reply-To: <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> References: <6a9afe3f-e232-4636-8a2e-6112a6e68cce@oracle.com> <30fbc8de-74f9-483e-a1f4-7ab2f1f26fbd@oracle.com> <105e5e22-cc87-48a0-978c-f2e472277843@oracle.com> <8d5075b2-fcbf-4be2-8510-9619b33aee87@oracle.com> Message-ID: On Thu, May 29, 2025 at 11:54?PM David Holmes wrote: > > On 30/05/2025 9:26 am, Jiangli Zhou wrote: > > On Thu, May 29, 2025 at 3:17?PM David Holmes wrote: > >> > >> On 30/05/2025 2:57 am, Jiangli Zhou wrote: > >>> On Wed, May 28, 2025 at 10:36?PM David Holmes wrote: > >>>> > >>>> Hi Jiangli, > >>>> > >>>> > >>>> > >>>> On 29/05/2025 3:27 am, Jiangli Zhou wrote: > >>>>>>> This is unfortunately quite complex, and I have started a discussion with Alan if it is possible to update the JNI spec so that both static and dynamic entry points can have the form "JNI_OnLoad_". Ideally, I'd like to see us push for this with as much effort as possible. If we got this in place, static builds would be much easier, and the changes required for Hermetic Java even smaller. > >>>>>> > >>>>>> Thumbs up! That seems to be a good direction. Currently in the leyden > >>>>>> branch, it first looks up the unique > >>>>>> JNI_OnLoad<_lib_name>|Agent_OnLoad<_lib_name> etc for built-in > >>>>>> libraries, then search for the dynamic libraries using the > >>>>>> conventional naming when necessary. e.g.: > >>>>>> > >>>>>> https://github.com/openjdk/leyden/commit/a5c886d2e85a0ff0c3712a5488ae61d8c9d7ba1a > >>>>>> https://github.com/openjdk/leyden/commit/1da8e3240e0bd27366d19f2e7dde386e46015135 > >>>>>> > >>>>>> When spec supports JNI_OnLoad_ and etc. for dynamic > >>>>>> libraries, we may still need to support the conventional naming > >>>>>> without the <_lib_name> part for existing libraries out there. > >>>>> > >>>>> Resuming the conversation on using > >>>>> JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > >>>>> for dynamically linked JNI & agent libraries. It is related to > >>>>> JDK-8350450 [1]: Compile object files once for both static and dynamic > >>>>> builds. We have recently enabled building & tier1 testing for > >>>>> static-jdk with release binary in GHA on linux-x64. The debug build > >>>>> however cannot be enabled in GHA due to space/resource limit (please > >>>>> see more details in JDK-8350450). So it's a good time to pick up > >>>>> JDK-8350450 related work. Based on discussions with Magnus in > >>>>> JDK-8350450 bug comments and separate emails from last year, I'll > >>>>> extract the runtime changes from the leyden/hermetic-java-runtime > >>>>> branch [2] for supporting JNI_OnLoad_L (and etc) for dynamically > >>>>> linked JNI/agent libraries. The work has been broadly tested in our > >>>>> internal prototype on JDK 11 and newer versions (linux-x64). > >>>>> > >>>>> Regarding the spec part, Ron, Alan, Magnus and myself had several > >>>>> discussions last year during hermetic Java meetings. The general > >>>>> understanding was that using JNI_OnLoad_L (and etc) for dynamically > >>>>> linked JDK native libraries requires no JNI/JVMTI spec change. I > >>>>> wonder if the following languages should be relaxed a bit to address > >>>>> potential questions. Any thoughts? > >>>> > >>>> I don't know exactly what was discussed, but I don't see how you can not > >>>> update the JNI (and other) specifications to do what you want to do, if > >>>> that involves invoking JNI_OnLoad_L in the dynamic case instead of > >>>> JNI_OnLoad. ?? > >>> > >>> Hi David, > >>> > >>> (refreshing my memory based on hermetic Java meeting notes) > >>> > >>> It's based on the following language in the JNI spec, > >>> https://docs.oracle.com/en/java/javase/21/docs/specs/jni/invocation.html#support-for-statically-linked-libraries: > >>> > >>> Support for Statically Linked Libraries > >>> > >>> "If dynamically linked library defines JNI_OnLoad_L and/or > >>> JNI_OnUnload_L functions, these functions will be ignored." > >>> > >>> The spec allows JNI_OnLoad_L and etc in dynamically linked libraries. > >>> For JDK internal native libraries, the implementation could use these > >>> symbols without requiring changing the spec. Ron, Alan, or Magnus, > >>> please correct or add any additional info. > >> > >> If this is only a convention for internal-use then I agree, no spec > >> change needed. For internal-use-only we can define whatever load/unload > >> hooks we like. > > > > Thanks, David. Yeah, that seems to be the rationale with using > > JNI_OnLoad_L|JNI_OnUnload_L|Agent_OnLoad_L|Agent_OnUnLoad_L|Agent_OnAttach_L > > in JDK native libraries, before any spec update. > > > > I just thought of one more thing related to the discussion now. Any > > concern if the implementation does not ignore JNI_OnLoad_L and etc if > > they are defined application's dynamically linked native libraries? Or > > that's unspecified behavior and it's up to the implement to decide? > > For Internal libraries or external? For external you have to follow the > spec - if both methods exist you only want to execute one of them. It's for the external (non-JDK) library that I'm a bit more cautious. In the existing code in JDK mainline, https://github.com/openjdk/jdk/blob/3cc630985d47be6ba4cf991698e999f17dbde203/src/java.base/share/classes/jdk/internal/loader/NativeLibraries.java#L117, loadLibrary() first tries to find the built-in library using JNI_OnLoad_L symbol (L is the library name). When dlsym is called to find the symbol from the main process, any of the already loaded shared libraries are also searched, as described by the dlsym man page (included related part below). https://man7.org/linux/man-pages/man3/dlsym.3.html: RTLD_DEFAULT Find the first occurrence of the desired symbol using the default shared object search order. The search will include global symbols in the executable and its dependencies, as well as symbols in shared objects that were dynamically loaded with the RTLD_GLOBAL flag. I think it would be rare, it is possible to construct such case: There are user JNI libraries A and B, with B is built as a dependency of A. A defines JNI_OnLoad_A and JNI_OnLoad. B defines JNI_OnLoad_B and JNI_OnLoad. When A is being loaded using loadLibrary(), loadLibrary() tries first to lookup JNI_OnLoad_A, which is not found. A is then loaded dynamically, which causes B being loaded implicitly as a dependency of A. Later when loadLibrary() is called for B, JNI_OnLoad_B would be found and then called. This is an existing behavior. I think it's an unspecified behavior and we don't need to add any additional checks to prevent JNI_OnLoad_B from being called. Thanks, Jiangli > > David > ----- > > > Thanks! > > Jiangli > >> > >> David > >> > >>> Best, > >>> Jiangli > >>> > >>> > >>>> > >>>> David > >>>> ----- > >>>> > >>>> > >>>>> From JNI spec [3]: > >>>>> > >>>>> - JNI_OnLoad/JNI_OnUnload > >>>>> Optional function defined by dynamically linked libraries. > >>>>> > >>>>> LINKAGE: > >>>>> Exported from dynamically linked native libraries that contain > >>>>> native method implementations. > >>>>> > >>>>> - JNI_OnLoad_L > >>>>> Mandatory function that must be defined by statically linked libraries . > >>>>> > >>>>> LINKAGE: > >>>>> Exported from statically linked native libraries that contain native > >>>>> method implementations. > >>>>> > >>>>> - JNI_OnUnload_L > >>>>> Optional function defined by statically linked libraries. > >>>>> > >>>>> From JVMTI spec [4]: > >>>>> > >>>>> An agent L whose image has been combined with the VM is defined as > >>>>> statically linked if and only if the agent exports a function called > >>>>> Agent_OnLoad_L. > >>>>> > >>>>> [1]: https://bugs.openjdk.org/browse/JDK-8350450 > >>>>> [2]: https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>> [3]: https://docs.oracle.com/en/java/javase/21/docs/specs/jni/ > >>>>> [4]: https://docs.oracle.com/en/java/javase/24/docs/specs/jvmti.html > >>>>> > >>>>> Best, > >>>>> Jiangli > >>>>> > >>>>>> > >>>>>>> > >>>>>>> And finally, on top of all of this, is the question of widening the platform support. To support linux/gcc with objcopy is trivial, but the question about Windows still remain. I have two possible ways forward, one is to check if there is alternative tooling to use (the prime candidate is the clang-ldd), and the other is to try to "fake" a partial linking by concatenating all source code before compiling. This is not ideal, though, for many reasons, and I am not keen on implementing it, not even for testing. And at this point, I have not had time to investigate any of these options much further, since I have been focusing on 1) above. > >>>>>>> > >>>>>>> A third option is of course to just say that due to toolchain limitations, static linking is not available on Windows. > >>>>>> > >>>>>> Thank you for taking this on! Potentially we could consider taking the > >>>>>> objcopy to localizing hotspot symbols on unix-like platforms, based on > >>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. Additional > >>>>>> testing is still needed to verify the solution. > >>>>>> > >>>>>>> > >>>>>>> My recommendation is that you keep on working to resolve the (much more thorny) issues of resource access in Hermetic Java in your branch, where you have a prototype static build that works for you. In the meantime, I will make sure that there will be a functioning, stable and robust way of creating static builds in the mainline, that can be regularly tested and not bit-rot, like the static build hacks that has gone in before. > >>>>>> > >>>>>> Most of the JDK resources are now supported as hermetic jimage > >>>>>> (lib/modules) bundled in the > >>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime branch. > >>>>>> The remaining sound.properties, ct.sym and .jfc files can be handled > >>>>>> later. Overally, that part of the work has confirmed the hermetic > >>>>>> jimage bundled solution is robust and helps resolve some of the > >>>>>> difficult start-up sequence issues observed when the hermetic resource > >>>>>> was implemented using JAR file based solution. > >>>>>> > >>>>>> It might be a good idea to follow up on the static linking discussion > >>>>>> in tomorrow's zoom meeting (hope you'll be able to join tomorrow). > >>>>>> > >>>>>> Thanks! > >>>>>> > >>>>>> Jiangli > >>>>>>> > >>>>>>> /Magnus > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>> Thanks! > >>>>>>> Jiangli > >>>>>>> > >>>>>>> On Thu, Feb 15, 2024 at 12:01?PM Jiangli Zhou wrote: > >>>>>>>> > >>>>>>>> On Wed, Feb 14, 2024 at 5:07?PM Jiangli Zhou wrote: > >>>>>>>>> > >>>>>>>>> Hi Magnus, > >>>>>>>>> > >>>>>>>>> Thanks for looking into this from the build perspective. > >>>>>>>>> > >>>>>>>>> On Wed, Feb 14, 2024 at 1:00?AM Magnus Ihse Bursie > >>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>> First some background for build-dev: I have spent some time looking at > >>>>>>>>>> the build implications of the Hermetic Java effort, which is part of > >>>>>>>>>> Project Leyden. A high-level overview is available here: > >>>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf and the current source > >>>>>>>>>> code is here: https://github.com/openjdk/leyden/tree/hermetic-java-runtime. > >>>>>>>>> > >>>>>>>>> Some additional hermetic Java related references that are also useful: > >>>>>>>>> > >>>>>>>>> - https://bugs.openjdk.org/browse/JDK-8303796 is an umbrella bug that > >>>>>>>>> links to the issues for resolving static linking issues so far > >>>>>>>>> - https://github.com/openjdk/jdk21/pull/26 is the enhancement for > >>>>>>>>> building the complete set of static libraries in JDK/VM, particularly > >>>>>>>>> including libjvm.a > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Hermetic Java faces several challenges, but the part that is relevant > >>>>>>>>>> for the build system is the ability to create static libraries. We've > >>>>>>>>>> had this functionality (in three different ways...) for some time, but > >>>>>>>>>> it is rather badly implemented. > >>>>>>>>>> > >>>>>>>>>> As a result of my investigations, I have a bunch of questions. :-) I > >>>>>>>>>> have gotten some answers in private discussion, but for the sake of > >>>>>>>>>> transparency I will repeat them here, to foster an open dialogue. > >>>>>>>>>> > >>>>>>>>>> 1. Am I correct in understanding that the ultimate goal of this exercise > >>>>>>>>>> is to be able to have jmods which include static libraries (*.a) of the > >>>>>>>>>> native code which the module uses, and that the user can then run a > >>>>>>>>>> special jlink command to have this linked into a single executable > >>>>>>>>>> binary (which also bundles the *.class files and any additional > >>>>>>>>>> resources needed)? > >>>>>>>>>> > >>>>>>>>>> 2. If so, is the idea to create special kinds of static jmods, like > >>>>>>>>>> java.base-static.jmod, that contains *.a files instead of lib*.so files? > >>>>>>>>>> Or is the idea that the normal jmod should contain both? > >>>>>>>>>> > >>>>>>>>>> 3. Linking .o and .a files into an executable is a formidable task. Is > >>>>>>>>>> the intention to have jlink call a system-provided ld, or to bundle ld > >>>>>>>>>> with jlink, or to reimplement this functionality in Java? > >>>>>>>>> > >>>>>>>>> I have a similar view as Alan responded in your other email thread. > >>>>>>>>> Things are still in the early stage for the general solution. > >>>>>>>>> > >>>>>>>>> In the https://github.com/openjdk/leyden/tree/hermetic-java-runtime > >>>>>>>>> branch, when configuring JDK with --with-static-java=yes, the JDK > >>>>>>>>> binary contains the following extra artifacts: > >>>>>>>>> > >>>>>>>>> - static-libs/*.a: The complete set of JDK/VM static libraries > >>>>>>>>> - jdk/bin/javastatic: A demo Java launcher fully statically linked > >>>>>>>>> with the selected JDK .a libraries (e.g. it currently statically link > >>>>>>>>> with the headless) and libjvm.a. It's the standard Java launcher > >>>>>>>>> without additional work for hermetic Java. > >>>>>>>>> > >>>>>>>>> In our prototype for hermetic Java, we build the hermetic executable > >>>>>>>>> image (a single image) from the following input (see description on > >>>>>>>>> singlejar packaging tool in > >>>>>>>>> https://cr.openjdk.org/~jiangli/hermetic_java.pdf): > >>>>>>>>> > >>>>>>>>> - A customized launcher (with additional work for hermetic) executable > >>>>>>>>> fully statically linked with JDK/VM static libraries (.a files), > >>>>>>>>> application natives and dependencies (e.g. in .a static libraries) > >>>>>>>>> - JDK lib/modules, JDK resource files > >>>>>>>>> - Application classes and resource files > >>>>>>>>> > >>>>>>>>> Including a JDK library .a into the corresponding .jmod would require > >>>>>>>>> extracting the .a for linking with the executable. In some systems > >>>>>>>>> that may cause memory overhead due to the extracted copy of the .a > >>>>>>>>> files. I think we should consider the memory overhead issue. > >>>>>>>>> > >>>>>>>>> One possibility (as Alan described in his response) is for jlink to > >>>>>>>>> invoke the ld on the build system. jlink could pass the needed JDK > >>>>>>>>> static libraries and libjvm.a (provided as part of the JDK binary) to > >>>>>>>>> ld based on the modules required for the application. > >>>>>>>>> > >>>>>>>> > >>>>>>>> I gave a bit more thoughts on this one. For jlink to trigger ld, it > >>>>>>>> would need to know the complete linker options and inputs. Those > >>>>>>>> include options and inputs related to the application part as well. In > >>>>>>>> some usages, it might be easier to handle native linking separately > >>>>>>>> and pass the linker output, the executable to jlink directly. Maybe we > >>>>>>>> could consider supporting different modes for various usages > >>>>>>>> requirements, from static libraries and native linking point of view: > >>>>>>>> > >>>>>>>> Mode #1 > >>>>>>>> Support .jmod packaged natives static libraries, for both JDK/VM .a > >>>>>>>> and application natives and dependencies. If the inputs to jlink > >>>>>>>> include .jmods, jlink can extract the .a libraries and pass the > >>>>>>>> information to ld to link the executable. > >>>>>>>> > >>>>>>>> Mode #2 > >>>>>>>> Support separate .a as jlink input. Jlink could pass the path > >>>>>>>> information to the .a libraries and other linker options to ld to > >>>>>>>> create the executable. > >>>>>>>> > >>>>>>>> For both mode #1 and #2, jlink would then use the linker output > >>>>>>>> executable to create the final hermetic image. > >>>>>>>> > >>>>>>>> Mode #3 > >>>>>>>> Support a fully linked executable as a jlink input. When a linked > >>>>>>>> executable is given to jlink, it can process it directly with other > >>>>>>>> JDK data/files to create the final image, without native linking step. > >>>>>>>> > >>>>>>>> Any other thoughts and considerations? > >>>>>>>> > >>>>>>>> Best, > >>>>>>>> Jiangli > >>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 4. Is the intention is to allow users to create their own jmods with > >>>>>>>>>> static libraries, and have these linked in as well? This seems to be the > >>>>>>>>>> case. > >>>>>>>>> > >>>>>>>>> An alternative with less memory overhead could be using application > >>>>>>>>> modular JAR and separate .a as the input for jlink. > >>>>>>>>> > >>>>>>>>>> If that is so, then there will always be the risk for name > >>>>>>>>>> collisions, and we can only minimize the risk by making sure any global > >>>>>>>>>> names are as unique as possible. > >>>>>>>>> > >>>>>>>>> Part of the current effort includes resolving the discovered symbol > >>>>>>>>> collision issues with static linking. Will respond to your other email > >>>>>>>>> on the symbol issue separately later. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> 5. The original implementation of static builds in the JDK, created for > >>>>>>>>>> the Mobile project, used a configure flag, --enable-static-builds, to > >>>>>>>>>> change the entire behavior of the build system to only produce *.a files > >>>>>>>>>> instead of lib*.so. In contrast, the current system is using a special > >>>>>>>>>> target instead. > >>>>>>>>> > >>>>>>>>> I think we would need both configure flag and special target for the > >>>>>>>>> static builds. > >>>>>>>>> > >>>>>>>>>> In my eyes, this is a much worse solution. Apart from > >>>>>>>>>> the conceptual principle (if the build should generate static or dynamic > >>>>>>>>>> libraries is definitely a property of what a "configuration" means), > >>>>>>>>>> this makes it much harder to implement efficiently, since we cannot make > >>>>>>>>>> changes in NativeCompilation.gmk, where they are needed. > >>>>>>>>> > >>>>>>>>> For the potential objcopy work to resolve symbol issues, we can add > >>>>>>>>> that conditionally in NativeCompilation.gmk if STATIC_LIBS is true. We > >>>>>>>>> have an internal prototype (not included in > >>>>>>>>> https://github.com/openjdk/leyden/tree/hermetic-java-runtime yet) done > >>>>>>>>> by one of colleagues for localizing symbols in libfreetype using > >>>>>>>>> objcopy. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> That was not as much a question as a statement. ? But here is the > >>>>>>>>>> question: Do you think it would be reasonable to restore the old > >>>>>>>>>> behavior but with the new methods, so that we don't use special targets, > >>>>>>>>>> but instead tells configure to generate static libraries? I'm thinking > >>>>>>>>>> we should have a flag like "--with-library-type=" that can have values > >>>>>>>>>> "dynamic" (which is default), "static" or "both". > >>>>>>>>> > >>>>>>>>> If we want to also build a fully statically linked launcher, maybe > >>>>>>>>> --with-static-java? Being able to configure either dynamic, static or > >>>>>>>>> both as you suggested also seems to be a good idea. > >>>>>>>>> > >>>>>>>>>> I am not sure if "both" are needed, but if we want to bundle both lib*.so and *.a files > >>>>>>>>>> into a single jmod file (see question 2 above), then it definitely is. > >>>>>>>>>> In general, the cost of producing two kinds of libraries are quite > >>>>>>>>>> small, compared to the cost of compiling the source code to object files. > >>>>>>>>> > >>>>>>>>> Completely agree. It would be good to avoid recompiling the .o file > >>>>>>>>> for static and dynamic builds. As proposed in > >>>>>>>>> https://bugs.openjdk.org/browse/JDK-8303796: > >>>>>>>>> > >>>>>>>>> It's beneficial to be able to build both .so and .a from the same set > >>>>>>>>> of .o files. That would involve some changes to handle the dynamic JDK > >>>>>>>>> and static JDK difference at runtime, instead of relying on the > >>>>>>>>> STATIC_BUILD macro. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> Finally, I have looked at how to manipulate symbol visibility. There > >>>>>>>>>> seems many ways forward, so I feel confident that we can find a good > >>>>>>>>>> solution. > >>>>>>>>>> > >>>>>>>>>> One way forward is to use objcopy to manipulate symbol status > >>>>>>>>>> (global/local). There is an option --localize-symbol in objcopy, that > >>>>>>>>>> has been available in objcopy since at least 2.15, which was released > >>>>>>>>>> 2004, so it should be safe to use. But ideally we should avoid using > >>>>>>>>>> objcopy and do this as part of the linking process. This should be > >>>>>>>>>> possible to do, given that we make changes in NativeCompilation.gmk -- > >>>>>>>>>> see question 5 above. > >>>>>>>>>> > >>>>>>>>>> As a fallback, it is also possible to rename symbols, either piecewise > >>>>>>>>>> or wholesale, using objcopy. There are many ways to do this, using > >>>>>>>>>> --prefix-symbols, --redefine-sym or --redefine-syms (note the -s, this > >>>>>>>>>> takes a file with a list of symbols). Thus we can always introduce a > >>>>>>>>>> "post factum namespace" by renaming symbols. > >>>>>>>>> > >>>>>>>>> Renaming or redefining the symbol at build time could cause confusions > >>>>>>>>> with debugging. That's a concern raised in > >>>>>>>>> https://github.com/openjdk/jdk/pull/17456 discussions. > >>>>>>>>> > >>>>>>>>> Additionally, redefining symbols using tools like objcopy may not > >>>>>>>>> handle member names referenced in string literals. For example, in > >>>>>>>>> https://github.com/openjdk/jdk/pull/17456 additional changes are > >>>>>>>>> needed in assembling and SA to reflect the symbol change. > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> So in the end, I think it will be fully possible to produce .a files > >>>>>>>>>> that only has global symbols for the functions that are part of the API > >>>>>>>>>> exposed by that library, and have all other symbols local, and make this > >>>>>>>>>> is in a way that is consistent with the rest of the build system. > >>>>>>>>>> > >>>>>>>>>> Finally, a note on Hotspot. Due to debugging reasons, we export > >>>>>>>>>> basically all symbols in hotspot as global. This is not reasonable to do > >>>>>>>>>> for a static build. The effect of not exporting those symbols will be > >>>>>>>>>> that SA will not function to 100%. On the other hand, I have no idea if > >>>>>>>>>> SA works at all with a static build. Have you tested this? Is this part > >>>>>>>>>> of the plan to support, or will it be officially dropped for Hermetic Java? > >>>>>>>>> > >>>>>>>>> We have done some testing with jtreg SA related tests for the fully > >>>>>>>>> statically linked `javastatic`. > >>>>>>>>> > >>>>>>>>> If we use objcopy to localize symbols in hotspot, it's not yet clear > >>>>>>>>> what's the impact on SA. We could do some tests. The other question > >>>>>>>>> that I raised is the supported gcc versions (for partial linking) > >>>>>>>>> related to the solution. > >>>>>>>>> > >>>>>>>>> Best, > >>>>>>>>> Jiangli > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> /Magnus > >>>>>>>>>> > >>>> > >> >