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