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: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: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: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 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 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 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 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 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 Samuel.Chee at arm.com Thu May 1 09:43:22 2025 From: Samuel.Chee at arm.com (Samuel Chee) Date: Thu, 1 May 2025 09:43:22 +0000 Subject: Removing ldar acquire from safepoint_poll method Message-ID: Hello, I was looking at whether it would be valid to remove the acquire from safepoint_poll completely from here which emits an ldar instead of a ldr for memory ordering. [1] As currently, there is only a single instance of this argument being used, in the panama downstream ffi. [2] And similar changes have been made to remove the acquire argument from other native methods [3] with the reasoning being that threads now disarm their own poll value and hence an ldar is no longer needed. Hence the same reasoning should apply when removing the acquire from the safepoint_poll used in the panama ffi and all other uses of safepoint_poll (especially since panama ffi is the only one which uses acquire). If it applies, this means the acquire argument functionality should be able to be removed completely from the safepoint_poll method. This change seemed to have been allowed when concurrent thread-stack processing and watermarking was introduced and the SafepointMechanism::update_poll_values method was updated such that the poll value could not be armed when leaving this method. [4] [5] As previously this may have not been the case as it could exit this function with an armed poll value. [6] Given the complexity of the code - particularly around safepoints and thread-handshake mechanisms, which have evolved significantly over time - I?d like to clarify a few aspects to ensure this change is correct. My questions are: 1. What specifically allowed this change to be made to the other JNIs? Why is the ldar acquire no longer needed? 2. Is there a reason why this was not done to the panama FFI safepoint_poll when the acquire arguments were removed from the other JNIs in [3]? 3. Why is a load_acquire required here [7] for before the handshake operation or global state but not from some of the existing jit-emitted code? 4. Why did the introduction of watermarking introduce both a poll word and poll page? Why is both needed? 5. And any more additional context on how safepointing and poll values work. Any clarification on the matter would be much appreciated! Samuel Chee [1] https://github.com/openjdk/jdk/blob/4c695fa8a459adcdb8cdfe9e90783007c65fb90e/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L556 [2] https://github.com/openjdk/jdk/blob/482538b100856afe2252395d47e576e6c6d885ce/src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp#L292 [3] https://bugs.openjdk.org/browse/JDK-8337657 [4] https://github.com/openjdk/jdk/pull/296/files#diff-2a18ec5d55c3c0c18669d55ff48fb455b633d152132915caf65766e41a5a58ab [5] https://openjdk.org/jeps/376 [6] https://github.com/openjdk/jdk/blob/a2f651904d1a1fdb14428be5485709b8ff252331/src/hotspot/share/runtime/safepointMechanism.cpp#L86, [7] https://github.com/openjdk/jdk/blob/765cef45465806e53f11fa7d92b9c184899b0932/src/hotspot/share/runtime/safepointMechanism.inline.hpp#L48 IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 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 patricio.chilano.mateo at oracle.com Thu May 1 18:31:04 2025 From: patricio.chilano.mateo at oracle.com (Patricio Chilano Mateo) Date: Thu, 1 May 2025 14:31:04 -0400 Subject: Removing ldar acquire from safepoint_poll method In-Reply-To: References: Message-ID: <56aabc5d-8ac6-04ad-c2cd-8b80c1783231@oracle.com> Hi Samuel, I?ll try to answer your questions below. On 5/1/25 5:43?AM, Samuel Chee wrote: > Hello, > > I was looking at whether it would be valid to remove the acquire from > safepoint_poll completely from here which emits an ldar instead of a > ldr for memory ordering. [1] As currently, there is only a single > instance of this argument being used, in the panama downstream ffi. [2] > And similar changes have been made to remove the acquire argument from > other native methods [3] with the reasoning being that threads now > disarm their own poll value and hence an ldar is no longer needed. > Hence the same reasoning should apply when removing the acquire from > the safepoint_poll used in the panama ffi and all other uses of > safepoint_poll (especially since panama ffi is the only one which uses > acquire). If it applies, this means the acquire argument functionality > should be able to be removed completely from the safepoint_poll method. > > This change seemed to have been allowed when concurrent thread-stack > processing and watermarking was introduced and the > SafepointMechanism::update_poll_values method was updated such that > the poll value could not be armed when leaving this method. [4] [5] As > previously this may have not been the case as it could exit this > function with an armed poll value. [6] > Given the complexity of the code - particularly around safepoints and > thread-handshake mechanisms, which have evolved significantly over > time - I?d like to clarify a few aspects to ensure this change is correct. > My questions are: > > 1. What specifically allowed this change to be made to the other JNIs? > Why is the ldar acquire no longer needed? As you found out from [1], the race is no longer present after JavaThreads disarm themselves. The race is well described by Erik in the links posted on that initial email. > 2. Is there a reason why this was not done to the panama FFI > safepoint_poll when the acquire arguments were removed from the other > JNIs in [3]? Seems the patch just meant to address the overhead on the JNI path, but this applies to the Panama one as well so we should be able to also use ldr. Let me know if you need help creating the JBS issue. > 3. Why is a load_acquire required here [7] for before the handshake > operation or global state but not from some of the existing > jit-emitted code? Good question. Once we see an armed poll we want to avoid memory operations to float up, otherwise we might for instance read stale values instead of the ones written by the arming thread before arming the poll. In particular, for handshakes we want to synchronize with the store release when arming the poll after the operation is added to the queue. For safepoints, the arming operation itself is done without extra fences but we previously executed storestore fences to order with some previous stores. I see SafepointMechanism::process() has a loadload fence and at least one early load acquire for the thread state so perhaps the acquire you mention when reading the poll word is not strictly needed. Erik and Robbin might have better insights. > 4. Why did the introduction of watermarking introduce both a poll word > and poll page? Why is both needed? Before 8253180 there were already two ways in which JavaThreads poll for safepoints/handshakes: testing the poll_bit of its polling_page or just trying to load from it (good page or bad page). Compiled methods use the latter method. I vaguely recall Erik trying to unify this and always test the poll_bit but I think there were some performance concerns. In any case, one field was enough. With 8253180, we now have to also check if we need to process frames when returning from a method. This requires a comparison of sp/fp with some previously saved reference, so we need an extra field. Thanks, Patricio [1] https://mail.openjdk.org/pipermail/hotspot-compiler-dev/2024-July/078698.html > 5. And any more additional context on how safepointing and poll values > work. > > Any clarification on the matter would be much appreciated! > Samuel Chee > > > [1] > _https://github.com/openjdk/jdk/blob/4c695fa8a459adcdb8cdfe9e90783007c65fb90e/src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp#L556 > _ > [2] > _https://github.com/openjdk/jdk/blob/482538b100856afe2252395d47e576e6c6d885ce/src/hotspot/cpu/aarch64/downcallLinker_aarch64.cpp#L292 > _ > [3] _https://bugs.openjdk.org/browse/JDK-8337657 > _ > [4] > _https://github.com/openjdk/jdk/pull/296/files#diff-2a18ec5d55c3c0c18669d55ff48fb455b633d152132915caf65766e41a5a58ab > _ > [5] _https://openjdk.org/jeps/376 _ > [6] > _https://github.com/openjdk/jdk/blob/a2f651904d1a1fdb14428be5485709b8ff252331/src/hotspot/share/runtime/safepointMechanism.cpp#L86 > _, > [7] > _https://github.com/openjdk/jdk/blob/765cef45465806e53f11fa7d92b9c184899b0932/src/hotspot/share/runtime/safepointMechanism.inline.hpp#L48 > _ > > IMPORTANT NOTICE: The contents of this email and any attachments are > confidential and may also be privileged. If you are not the intended > recipient, please notify the sender immediately and do not disclose > the contents to any other person, use it for any purpose, or store or > copy the information in any medium. Thank you. -------------- next part -------------- An HTML attachment was scrubbed... URL: 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 duke at openjdk.org Thu May 1 17:40:01 2025 From: duke at openjdk.org (duke) Date: Thu, 1 May 2025 17:40:01 GMT Subject: Withdrawn: 8333151: Investigate if the Hotspot Arena chunk pools still make sense In-Reply-To: References: Message-ID: <7cVdVatABn8oJ2djMZdTCriAX_NYqGlK45vDpuIRQo4=.6c871e02-69e9-42ea-b218-691655fa43b6@github.com> On Wed, 31 Jul 2024 23:14:41 GMT, Afshin Zafari wrote: > Using `ChunkPool` or not is investigated in this PR based on time and memory consumption. > Based on the tests using ChunkPool shows no better speed nor memory footprint. > Memory usage is taken from RSS reports of Linux API. (GHA tests for non-linux platforms fail) > These improvements should be confirmed also in more related micro-benchmarks. > This PR is created only to receive feedbacks on the measurements and comparisons. > Anyway, since the purpose of the PR is investigation only, it won't be merged to the mainline. > Sample output: > > Total time, no pool, alloc: 190, free: 1 > Total time, no pool, alloc: 68, free: 1 > Total time, no pool, alloc: 56, free: 1 > Total time, no pool, alloc: 36, free: 1 > Total time, no pool, alloc: 37, free: 1 > Total time, with pool, alloc: 201, free: 12 > Total time, with pool, alloc: 190, free: 13 > Total time, with pool, alloc: 189, free: 13 > Total time, with pool, alloc: 190, free: 13 > Total time, with pool, alloc: 189, free: 13 > > RSS(KB): no-pool= 14524, pool= 735464, diff=-720940 > RSS(KB): no-pool= 480, pool= 34840, diff=-34360 > RSS(KB): no-pool= 2560, pool= 22036, diff=-19476 > RSS(KB): no-pool= 128, pool= 21580, diff=-21452 > RSS(KB): no-pool= -28, pool= 7732, diff=-7760 This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20411 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 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 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 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 dlong at openjdk.org Thu May 1 21:12:46 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 1 May 2025 21:12:46 GMT Subject: RFR: 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 09:43:25 GMT, Johan Sj?len wrote: >> Hi, >> >> This fixes a typical wrong overflow check. `_bci` and `_next_bci` are both `int`, so any overflow is undefined, therefore an optimizing C++ compiler is allowed to remove this check. When looking at the x64 assembly for this, I could not find the check, so I guess that it was actually removed as well. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove Look good, and my testing passed. However, I think this deserves a 2nd review. ------------- Marked as reviewed by dlong (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24920#pullrequestreview-2810736044 From amenkov at openjdk.org Thu May 1 21:18:45 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 1 May 2025 21:18:45 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output Ping. Can I get review for this test update ------------- PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2845798768 From jsjolen at openjdk.org Fri May 2 07:37:50 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 2 May 2025 07:37:50 GMT Subject: RFR: 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next [v3] In-Reply-To: References: Message-ID: On Thu, 1 May 2025 21:09:47 GMT, Dean Long wrote: > Look good, and my testing passed. However, I think this deserves a 2nd review. Thanks Dean, I appreciate it. @matias9927 , would you mind reviewing? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24920#issuecomment-2846564225 From azafari at openjdk.org Fri May 2 08:23:27 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 2 May 2025 08:23:27 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v17] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: new version. All tests except one passed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/cc0db115..7cf5338d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=15-16 Stats: 633 lines in 3 files changed: 220 ins; 200 del; 213 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From duke at openjdk.org Fri May 2 10:00:07 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:07 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Refactor container runtime version code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/223a5d1b..3b18431d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=01-02 Stats: 246 lines in 3 files changed: 111 ins; 133 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Fri May 2 10:00:07 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:07 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <_D4nqTI9xJUe43WrWHRaozFfHG5HQSv-jzFSNnrggmo=.fc3318d8-a776-48a3-b564-2d8e376bc299@github.com> On Tue, 29 Apr 2025 20:18:17 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 74: > >> 72: return; >> 73: } >> 74: if (IS_DOCKER && TestDockerMemoryMetricsSubgroup.DockerVersion.VERSION_20_10_0.compareTo(getDockerVersion()) > 0) { > > Should this change also cover Podman, in which the minimum version that supports `--cgroupns` is 3.0 ? updated for podman In podman cgroupns support was added in 1.5.0 https://github.com/containers/podman/releases?page=18 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071383984 From duke at openjdk.org Fri May 2 10:00:08 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 2 May 2025 10:00:08 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v2] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 20:28:36 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> update reference of DockerVersion > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 149: > >> 147: } >> 148: >> 149: private static class DockerVersion implements Comparable { > > The same code is added to multiple tests. Created a util file for common code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2071384406 From rkennke at openjdk.org Fri May 2 10:37:04 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Fri, 2 May 2025 10:37:04 GMT Subject: RFR: 8350457: Implement Compact Object Headers (Production) [v3] In-Reply-To: References: Message-ID: > As title says. Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: Build COH CDS archives ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24522/files - new: https://git.openjdk.org/jdk/pull/24522/files/56a50df8..ad389db3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24522/head:pull/24522 PR: https://git.openjdk.org/jdk/pull/24522 From matsaave at openjdk.org Fri May 2 14:38:48 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 2 May 2025 14:38:48 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests [v4] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 08:47:30 GMT, Anton Artemov wrote: >> Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that they are not using jar files, but instead class files are created on the fly using the ASM library. >> >> Test in tiers 1-3 on multiple platforms pass. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8354329: Got rid of unused variables. This is a good change! I have a few comments on style but overall the implementation looks good. test/hotspot/jtreg/runtime/ClassFile/JsrRewriting.java line 47: > 45: import jdk.test.lib.process.OutputAnalyzer; > 46: > 47: import java.io.File; Imports should be clustered together in alphabetical order test/hotspot/jtreg/runtime/ClassFile/OOMCrashClass1960_2.java line 33: > 31: > 32: /* > 33: This is class is a dumper for the original OOMCrashClass1960_2.class, i.e. its dump() method Was there a copyright date on the original version of this class? If so maybe it should be included in the header test/hotspot/jtreg/runtime/ClassFile/OOMCrashClass1960_2.java line 63: > 61: methodVisitor.visitMethodInsn(INVOKESTATIC, "java/lang/Integer", "parseInt", "(Ljava/lang/String;)I", false); > 62: methodVisitor.visitVarInsn(ISTORE, 1); > 63: Label label1 = new Label(); Just a suggestion so you can ignore this if you prefer the current style: Declaring labels in the middle of the code is a bit confusing since it isn't actually applied until you call `visitLabel()`. Maybe it would be better to declare the labels at the top of the method. test/hotspot/jtreg/runtime/ClassFile/OomWhileParsingRepeatedJsr.java line 45: > 43: */ > 44: > 45: import jdk.test.lib.process.ProcessTools; Same as above, imports should be in alphabetical order test/hotspot/jtreg/runtime/ClassFile/OomWhileParsingRepeatedJsr.java line 69: > 67: // in order to trigger and observe a fake os::malloc oom. This needs NMT. > 68: ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder( > 69: "-cp", ".", Align the arguments here ------------- Changes requested by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24662#pullrequestreview-2812140573 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071687874 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071705626 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071702225 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071707308 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071708172 From duke at openjdk.org Fri May 2 14:57:25 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 2 May 2025 14:57:25 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests [v5] In-Reply-To: References: Message-ID: <2da_-P2P_euEGfSmoISvXnfHjTpzze6JAwZQh28pAzM=.3119eb23-9f2b-46e5-b8f5-69b5c703a4cc@github.com> > Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that they are not using jar files, but instead class files are created on the fly using the ASM library. > > Test in tiers 1-3 on multiple platforms pass. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8354329: Addressed latest reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24662/files - new: https://git.openjdk.org/jdk/pull/24662/files/14f69c7f..4644c4bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24662&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24662&range=03-04 Stats: 18 lines in 4 files changed: 3 ins; 12 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24662.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24662/head:pull/24662 PR: https://git.openjdk.org/jdk/pull/24662 From duke at openjdk.org Fri May 2 14:57:26 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 2 May 2025 14:57:26 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests [v4] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 14:20:54 GMT, Matias Saavedra Silva wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8354329: Got rid of unused variables. > > test/hotspot/jtreg/runtime/ClassFile/JsrRewriting.java line 47: > >> 45: import jdk.test.lib.process.OutputAnalyzer; >> 46: >> 47: import java.io.File; > > Imports should be clustered together in alphabetical order Addressed in the latest commit. > test/hotspot/jtreg/runtime/ClassFile/OOMCrashClass1960_2.java line 33: > >> 31: >> 32: /* >> 33: This is class is a dumper for the original OOMCrashClass1960_2.class, i.e. its dump() method > > Was there a copyright date on the original version of this class? If so maybe it should be included in the header No, there was no copyright, as this file was generated by me using ASMifier, and then refactored. I added a standard copyright comment there. > test/hotspot/jtreg/runtime/ClassFile/OOMCrashClass1960_2.java line 63: > >> 61: methodVisitor.visitMethodInsn(INVOKESTATIC, "java/lang/Integer", "parseInt", "(Ljava/lang/String;)I", false); >> 62: methodVisitor.visitVarInsn(ISTORE, 1); >> 63: Label label1 = new Label(); > > Just a suggestion so you can ignore this if you prefer the current style: Declaring labels in the middle of the code is a bit confusing since it isn't actually applied until you call `visitLabel()`. Maybe it would be better to declare the labels at the top of the method. This code was auto-generated by ASMifier, essentially I identified a repeating pattern and put to a method in order to make the code feasible in size. Declaration of a label is a part of that pattern. > test/hotspot/jtreg/runtime/ClassFile/OomWhileParsingRepeatedJsr.java line 45: > >> 43: */ >> 44: >> 45: import jdk.test.lib.process.ProcessTools; > > Same as above, imports should be in alphabetical order Addressed in the latest commit. > test/hotspot/jtreg/runtime/ClassFile/OomWhileParsingRepeatedJsr.java line 69: > >> 67: // in order to trigger and observe a fake os::malloc oom. This needs NMT. >> 68: ProcessBuilder pb = ProcessTools.createLimitedTestJavaProcessBuilder( >> 69: "-cp", ".", > > Align the arguments here Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071732255 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071728152 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071724161 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071732107 PR Review Comment: https://git.openjdk.org/jdk/pull/24662#discussion_r2071732387 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 matsaave at openjdk.org Fri May 2 15:08:47 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 2 May 2025 15:08:47 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests [v5] In-Reply-To: <2da_-P2P_euEGfSmoISvXnfHjTpzze6JAwZQh28pAzM=.3119eb23-9f2b-46e5-b8f5-69b5c703a4cc@github.com> References: <2da_-P2P_euEGfSmoISvXnfHjTpzze6JAwZQh28pAzM=.3119eb23-9f2b-46e5-b8f5-69b5c703a4cc@github.com> Message-ID: On Fri, 2 May 2025 14:57:25 GMT, Anton Artemov wrote: >> Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that they are not using jar files, but instead class files are created on the fly using the ASM library. >> >> Test in tiers 1-3 on multiple platforms pass. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8354329: Addressed latest reviewer's comments. New changes look good! Thanks for removing the unused imports as well. ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24662#pullrequestreview-2812249444 From matsaave at openjdk.org Fri May 2 15:17:48 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 2 May 2025 15:17:48 GMT Subject: RFR: 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 09:43:25 GMT, Johan Sj?len wrote: >> Hi, >> >> This fixes a typical wrong overflow check. `_bci` and `_next_bci` are both `int`, so any overflow is undefined, therefore an optimizing C++ compiler is allowed to remove this check. When looking at the x64 assembly for this, I could not find the check, so I guess that it was actually removed as well. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove LGTM! I don't see any potential overflow since `_end_bci` and `_next_bci` are bound by u2 ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24920#pullrequestreview-2812269289 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 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 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 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 matsaave at openjdk.org Fri May 2 17:49:47 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Fri, 2 May 2025 17:49:47 GMT Subject: RFR: 8327495: Print more warning with -Xshare:auto when CDS fails to use archive [v5] In-Reply-To: References: <7KqtLcfk4G02yq2796-brsa3mCwUkeoLvPlfzj1k3JU=.705104e7-1bc7-46c3-b3bd-401c2eefc8e3@github.com> Message-ID: On Wed, 30 Apr 2025 04:12:31 GMT, Calvin Cheung wrote: >> Before this change, if the `-Xshare:auto` is specified with a CDS archive, the user won't see the following error message when the archive has failed to load: >> `An error has occurred while processing the the shared archive file.` >> This change will print the above error message if the `-Xshare:auto` is specified and the archive is not the default one. >> Several existing `log_ino(cds)()` calls have been changed to calling the new function `MetaspaceShared::report_loading_error()`. Also modified couple of tests to check the above error message is printed. >> >> Passed tiers 1 - 3 testing. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > fix build errors on macosx platforms LGTM! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24889#pullrequestreview-2812583819 From coleenp at openjdk.org Fri May 2 18:52:07 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 May 2025 18:52:07 GMT Subject: RFR: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 Message-ID: Simple change to close an opened file. Tested with tier1-4. ------------- Commit messages: - 8355353: File Leak in os::read_image_release_file of os.cpp:1552 Changes: https://git.openjdk.org/jdk/pull/25012/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25012&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355353 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25012.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25012/head:pull/25012 PR: https://git.openjdk.org/jdk/pull/25012 From zgu at openjdk.org Fri May 2 19:18:44 2025 From: zgu at openjdk.org (Zhengyu Gu) Date: Fri, 2 May 2025 19:18:44 GMT Subject: RFR: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:46:39 GMT, Coleen Phillimore wrote: > Simple change to close an opened file. > Tested with tier1-4. LGTM ------------- Marked as reviewed by zgu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25012#pullrequestreview-2812736606 From duke at openjdk.org Fri May 2 19:59:11 2025 From: duke at openjdk.org (duke) Date: Fri, 2 May 2025 19:59:11 GMT Subject: Withdrawn: 8337217: Port VirtualMemoryTracker to use VMATree In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com> Message-ID: On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari wrote: > - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTracker`. > - A wrapper/helper `RegionTree` is made around VMATree to make some calls easier. > - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs. > - All tier1 tests pass except this https://bugs.openjdk.org/browse/JDK-8335167. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20425 From coleenp at openjdk.org Fri May 2 20:30:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Fri, 2 May 2025 20:30:49 GMT Subject: RFR: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:46:39 GMT, Coleen Phillimore wrote: > Simple change to close an opened file. > Tested with tier1-4. Thanks Zhengyu. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25012#issuecomment-2848061162 From jiangli at openjdk.org Fri May 2 23:20:54 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 2 May 2025 23:20:54 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk Message-ID: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. Tested all three tests on static-jdk. All three tests pass with the fix. ------------- Commit messages: - Set -Dcompile.jdk=<> in launched test process. Changes: https://git.openjdk.org/jdk/pull/25018/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25018&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356102 Stats: 11 lines in 3 files changed: 6 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25018/head:pull/25018 PR: https://git.openjdk.org/jdk/pull/25018 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 asmehra at openjdk.org Sat May 3 04:21:31 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Sat, 3 May 2025 04:21:31 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache Message-ID: [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. ------------- Commit messages: - Remove irrelevant comment - Fix win64 compile failures - Fix AOTCodeFlags.java test - Fix compile failure in minimal config - Revert back changes that added AOTRuntimeConstants. - Fix merge conflicts - Store/load AsmRemarks and DbgStrings in aot code cache - Add missing external address in aarch64 - 8354887: Preserve runtime blobs in AOT code cache Changes: https://git.openjdk.org/jdk/pull/25019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354887 Stats: 1048 lines in 22 files changed: 815 ins; 132 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 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 jsjolen at openjdk.org Sat May 3 07:44:44 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Sat, 3 May 2025 07:44:44 GMT Subject: RFR: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:46:39 GMT, Coleen Phillimore wrote: > Simple change to close an opened file. > Tested with tier1-4. Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25012#pullrequestreview-2813179784 From kvn at openjdk.org Sat May 3 17:46:49 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 May 2025 17:46:49 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 04:10:01 GMT, Ashutosh Mehra wrote: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Few comments. src/hotspot/cpu/x86/x86_64.ad line 1868: > 1866: } else { > 1867: __ mov64(r10, (int64_t) $meth$$method); > 1868: } I think we should do it always, not conditionally. On AArch64 it is unconditional - relocation processing know how to do that. src/hotspot/share/asm/codeBuffer.hpp line 303: > 301: os::free((void*)_string); > 302: _string = nullptr; > 303: } Move it into `.cpp` so you don't need to include `os.hpp` here. src/hotspot/share/code/aotCodeCache.cpp line 27: > 25: #ifdef COMPILER1 > 26: #include "c1/c1_Runtime1.hpp" > 27: #endif Conditional includes are placed at the end of includes. src/hotspot/share/code/aotCodeCache.cpp line 414: > 412: log_debug(aot, codecache, init)("AOT Code Cache disabled: it was created with CompressedOops::base() = %p vs current %p", _compressedOopBase, CompressedOops::base()); > 413: return false; > 414: } I think we have relocation for CompressedOops::base() so we can patch. No need to bailout. Do you have stub/blob which missed relocation? src/hotspot/share/code/aotCodeCache.cpp line 422: > 420: log_debug(aot, codecache, init)("AOT Code Cache disabled: it was created with CompressedKlassPointers::base() = %p vs current %p", _compressedKlassBase, CompressedKlassPointers::base()); > 421: return false; > 422: } I would suggest to use relocation for klass's base too but not in these changes. I think bailout is fine here. src/hotspot/share/code/aotCodeCache.cpp line 774: > 772: return false; > 773: } > 774: log_info(aot, codecache, stubs)("Writing blob '%s' (id=%u, kind=%s) to AOT Code Cache", name, id, AOTCodeEntry::kind_string(entry_kind)); Please, use `log_debug()` in final changes. src/hotspot/share/code/aotCodeCache.cpp line 880: > 878: CodeBlob* blob = reader.compile_code_blob(name, entry_offset_count, entry_offsets); > 879: > 880: log_info(aot, codecache, stubs)("Read blob '%s' (id=%u, kind=%s) from AOT Code Cache", name, id, AOTCodeEntry::kind_string(entry_kind)); Use `log_debug()` src/hotspot/share/code/aotCodeCache.cpp line 1119: > 1117: uint n = write_bytes(&offset, sizeof(uint)); > 1118: if (n != sizeof(uint)) { > 1119: return false; Consider using `id_for_C_string()` and record ID instead of coping string. These strings should be recorded in C strings table already. If `id_for_C_string()` does not find - assert. We should add `add_C_string()` in missing place. src/hotspot/share/code/aotCodeCache.cpp line 1158: > 1156: log_trace(aot, codecache, stubs)("dbg string=%s", str); > 1157: uint len = (uint)strlen(str) + 1; // including '\0' char > 1158: uint n = write_bytes(str, len); Same here src/hotspot/share/opto/runtime.cpp line 161: > 159: C2_STUB_C_FUNC(name), \ > 160: C2_STUB_NAME(name), \ > 161: (int)C2_STUB_ID(name), \ Please, align `` src/hotspot/share/opto/runtime.cpp line 175: > 173: C2_JVMTI_STUB_C_FUNC(name), \ > 174: C2_STUB_NAME(name), \ > 175: (int)C2_STUB_ID(name), \ Here too. ------------- PR Review: https://git.openjdk.org/jdk/pull/25019#pullrequestreview-2813266337 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072427336 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072427806 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072431635 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072433399 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072433955 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072434259 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072434351 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072435358 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072435774 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072428528 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072428575 From kvn at openjdk.org Sat May 3 17:46:50 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 May 2025 17:46:50 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 16:44:52 GMT, Vladimir Kozlov wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > src/hotspot/cpu/x86/x86_64.ad line 1868: > >> 1866: } else { >> 1867: __ mov64(r10, (int64_t) $meth$$method); >> 1868: } > > I think we should do it always, not conditionally. On AArch64 it is unconditional - relocation processing know how to do that. I will update `premain` code too later. > src/hotspot/share/asm/codeBuffer.hpp line 303: > >> 301: os::free((void*)_string); >> 302: _string = nullptr; >> 303: } > > Move it into `.cpp` so you don't need to include `os.hpp` here. Constructor too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072427496 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2072427920 From kvn at openjdk.org Sat May 3 23:35:45 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 3 May 2025 23:35:45 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 04:10:01 GMT, Ashutosh Mehra wrote: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. We need to do something about Compressed Klass base: java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -XX:+AOTStubCaching -Xlog:aot+codecache+init=debug -cp hello.jar HelloWorld [0.009s][debug][aot,codecache,init] Mapped 548864 bytes at address 0x00007f17b1611000 at AOT Code Cache [0.009s][info ][aot,codecache,init] Loaded 384 AOT code entries from AOT Code Cache [0.009s][debug][aot,codecache,init] Adapters: total=316 [0.009s][debug][aot,codecache,init] Shared Blobs: total=14 [0.009s][debug][aot,codecache,init] C1 Blobs: total=34 [0.009s][debug][aot,codecache,init] C2 Blobs: total=20 [0.009s][debug][aot,codecache,init] AOT code cache size: 543392 bytes [0.009s][debug][aot,codecache,init] Loaded 1 C strings of total length 28 at offset 521860 from AOT Code Cache [0.010s][debug][aot,codecache,init] AOT Code Cache disabled: it was created with CompressedKlassPointers::base() = 0x7f56c6000000 vs current 0x7f1762000000 [0.010s][info ][aot,codecache,init] Unable to use AOT Code Cache. Hellow World! Which blob/stubs decompress/compress klass using the base? May be we should use Relocation for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2848857110 PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2848857305 PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2848857738 From iklam at openjdk.org Mon May 5 00:29:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 00:29:19 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics Message-ID: This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" - Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. Examples: # Create an AOT cache with a single command: $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld Hello World Temporary AOTConfiguration recorded: foo.aot.config Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot AOTCache creation is complete: foo.aot 10240000 bytes # Create logging file for the AOT cache assembly phase $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). ------------- Commit messages: - Remove %t restriction - Added %p substitution; clean up - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - fixed typo - added comment that was removed in previous commit - Refactored code to enfore the order of argument parsing - 8355798: Implement JEP-JDK-8350022: Ahead-of-time Command Line Ergonomics Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355798 Stats: 1776 lines in 17 files changed: 1298 ins; 439 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From kvn at openjdk.org Mon May 5 00:29:20 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 00:29:20 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam wrote: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `AOT_TOOL_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Few comments. JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix. src/hotspot/share/cds/metaspaceShared.cpp line 1068: > 1066: } > 1067: > 1068: // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS. `_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`? src/hotspot/share/cds/metaspaceShared.cpp line 1071: > 1069: for (int i = 0; i < Arguments::num_jvm_args(); i++) { > 1070: const char* arg = Arguments::jvm_args_array()[i]; > 1071: if (strncmp("-XX:AOTMode", arg, 11) == 0) { In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent. src/java.base/share/classes/jdk/internal/misc/CDS.java line 510: > 508: > 509: Map env = pb.environment(); > 510: env.put("JAVA_TOOL_OPTIONS", sb.toString()); What about `JAVA_AOT_OPTIONS`? ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2804218715 PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2839405664 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066881980 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066888741 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2066892210 From iklam at openjdk.org Mon May 5 00:38:13 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 00:38:13 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v2] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/acba394e..5e51e8fe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=00-01 Stats: 305 lines in 5 files changed: 142 ins; 140 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @vnkozlov comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/5e51e8fe..0eb8b545 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=01-02 Stats: 9 lines in 1 file changed: 6 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 15:48:12 GMT, Vladimir Kozlov wrote: > JEP and CSR call env var :`JAVA_AOT_OPTIONS`. This description and changes call it `AOT_TOOL_OPTIONS`. Please, fix. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2849668130 From iklam at openjdk.org Mon May 5 01:00:31 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 5 May 2025 01:00:31 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 15:56:59 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/metaspaceShared.cpp line 1068: > >> 1066: } >> 1067: >> 1068: // Pass all arguments. These include those from JAVA_TOOL_OPTIONS and _JAVA_OPTIONS. > > `_JAVA_OPTIONS`. Do you mean `JAVA_AOT_OPTIONS`? `JAVA_AOT_OPTIONS` is not parsed here. I added comments. > src/hotspot/share/cds/metaspaceShared.cpp line 1071: > >> 1069: for (int i = 0; i < Arguments::num_jvm_args(); i++) { >> 1070: const char* arg = Arguments::jvm_args_array()[i]; >> 1071: if (strncmp("-XX:AOTMode", arg, 11) == 0) { > > In arguments.cpp you do `strncmp("-XX:AOTMode=", arg, 12) == 0`. I think you need to be consistent. Fixed. > src/java.base/share/classes/jdk/internal/misc/CDS.java line 510: > >> 508: >> 509: Map env = pb.environment(); >> 510: env.put("JAVA_TOOL_OPTIONS", sb.toString()); > > What about `JAVA_AOT_OPTIONS`? This method doesn't not touch `JAVA_AOT_OPTIONS`, which will be inherited by the child process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761734 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761745 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2072761767 From jsjolen at openjdk.org Mon May 5 07:16:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 5 May 2025 07:16:53 GMT Subject: RFR: 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next [v3] In-Reply-To: References: Message-ID: On Wed, 30 Apr 2025 09:43:25 GMT, Johan Sj?len wrote: >> Hi, >> >> This fixes a typical wrong overflow check. `_bci` and `_next_bci` are both `int`, so any overflow is undefined, therefore an optimizing C++ compiler is allowed to remove this check. When looking at the x64 assembly for this, I could not find the check, so I guess that it was actually removed as well. > > Johan Sj?len has updated the pull request incrementally with one additional commit since the last revision: > > Remove Cheers! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24920#issuecomment-2850109196 From jsjolen at openjdk.org Mon May 5 07:16:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 5 May 2025 07:16:53 GMT Subject: Integrated: 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 13:18:53 GMT, Johan Sj?len wrote: > Hi, > > This fixes a typical wrong overflow check. `_bci` and `_next_bci` are both `int`, so any overflow is undefined, therefore an optimizing C++ compiler is allowed to remove this check. When looking at the x64 assembly for this, I could not find the check, so I guess that it was actually removed as well. This pull request has now been integrated. Changeset: f04e556d Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/f04e556d471d65a9b1a86d33acf72f6ddec944e1 Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod 8355711: Remove incorrect overflow check in RawBytecodeStream::raw_next Reviewed-by: dlong, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/24920 From duke at openjdk.org Mon May 5 08:03:48 2025 From: duke at openjdk.org (duke) Date: Mon, 5 May 2025 08:03:48 GMT Subject: RFR: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests [v5] In-Reply-To: <2da_-P2P_euEGfSmoISvXnfHjTpzze6JAwZQh28pAzM=.3119eb23-9f2b-46e5-b8f5-69b5c703a4cc@github.com> References: <2da_-P2P_euEGfSmoISvXnfHjTpzze6JAwZQh28pAzM=.3119eb23-9f2b-46e5-b8f5-69b5c703a4cc@github.com> Message-ID: On Fri, 2 May 2025 14:57:25 GMT, Anton Artemov wrote: >> Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that they are not using jar files, but instead class files are created on the fly using the ASM library. >> >> Test in tiers 1-3 on multiple platforms pass. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8354329: Addressed latest reviewer's comments. @toxaart Your change (at version 4644c4bc28c452187b8de034dac2569e15c954b1) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24662#issuecomment-2850208189 From duke at openjdk.org Mon May 5 08:55:56 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 5 May 2025 08:55:56 GMT Subject: Integrated: 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 13:37:17 GMT, Anton Artemov wrote: > Rewrote JsrRewriting and OomWhileParsingRepeatedJsr tests so that they are not using jar files, but instead class files are created on the fly using the ASM library. > > Test in tiers 1-3 on multiple platforms pass. This pull request has now been integrated. Changeset: 6dd55538 Author: Anton Artemov Committer: Afshin Zafari URL: https://git.openjdk.org/jdk/commit/6dd555382326d02a1fc419bc443285509886e46f Stats: 303 lines in 6 files changed: 267 ins; 17 del; 19 mod 8354329: Rewrite runtime/ClassFile/JsrRewriting.java and OomWhileParsingRepeatedJsr.java tests Reviewed-by: matsaave, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/24662 From jwaters at openjdk.org Mon May 5 09:19:48 2025 From: jwaters at openjdk.org (Julian Waters) Date: Mon, 5 May 2025 09:19:48 GMT Subject: RFR: 8343249: [Windows] Implement SpinPause [v4] In-Reply-To: References: Message-ID: On Mon, 18 Nov 2024 06:08:08 GMT, Julian Waters wrote: >> SpinPause is currently not implemented on any Windows platforms, due to a lack of access to assembly in the Microsoft compiler. The YieldProcessor macro can act as a stand in for this purpose, as it compiles down to a single pause instruction on x64 (Which seems to be all that one needs to implement SpinPause in HotSpot). I am less certain about the Windows/ARM64 implementation. There, YieldProcessor compiles down to dmb ishst; yield and I am unsure whether that is a correct SpinPause implementation. If need be, I can retract the ARM64 implementation and only have this for x86 > > Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'openjdk:master' into patch-13 > - Merge branch 'master' into patch-13 > - Swap to handwritten assembly to implement SpinPause in os_windows_aarch64.cpp > - YieldProcessor in os_windows_aarch64.cpp > - 8343249 Keep open ------------- PR Comment: https://git.openjdk.org/jdk/pull/21781#issuecomment-2850390035 From coleenp at openjdk.org Mon May 5 11:59:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 May 2025 11:59:49 GMT Subject: RFR: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:46:39 GMT, Coleen Phillimore wrote: > Simple change to close an opened file. > Tested with tier1-4. Thanks for the reviews Johan and Zhengyu. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25012#issuecomment-2850758221 From coleenp at openjdk.org Mon May 5 11:59:49 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 May 2025 11:59:49 GMT Subject: Integrated: 8355353: File Leak in os::read_image_release_file of os.cpp:1552 In-Reply-To: References: Message-ID: On Fri, 2 May 2025 18:46:39 GMT, Coleen Phillimore wrote: > Simple change to close an opened file. > Tested with tier1-4. This pull request has now been integrated. Changeset: a8cd01f6 Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/a8cd01f6e2075bef89fcd82893cf417c9e1fa877 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8355353: File Leak in os::read_image_release_file of os.cpp:1552 Reviewed-by: zgu, jsjolen ------------- PR: https://git.openjdk.org/jdk/pull/25012 From duke at openjdk.org Mon May 5 14:43:55 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Mon, 5 May 2025 14:43:55 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version Message-ID: fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". Tested locally - run test with mocked podman version string. ------------- Commit messages: - TestJcmd.java may incorrectly parse podman version Changes: https://git.openjdk.org/jdk/pull/25041/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25041&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356187 Stats: 12 lines in 1 file changed: 4 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25041/head:pull/25041 PR: https://git.openjdk.org/jdk/pull/25041 From asmehra at openjdk.org Mon May 5 15:14:47 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 5 May 2025 15:14:47 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 23:30:44 GMT, Vladimir Kozlov wrote: > We need to do something about Compressed Klass base: I too feel bailing out is too restrictive. In my tests I have seen this happening too frequently to ignore. > Which blob/stubs decompress/compress klass using the base? `CompressedKlassPointers::base()` is called by C1 blob for `is_instance_of` [0]. [0] https://github.com/openjdk/jdk/blob/1501a5e41e59162a374cf5b8cfc37faced48a6ed/src/hotspot/cpu/x86/c1_Runtime1_x86.cpp#L1131 https://github.com/openjdk/jdk/blob/1501a5e41e59162a374cf5b8cfc37faced48a6ed/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L5439 > May be we should use Relocation for it. @vnkozlov How about updating `decode_klass_not_null` like this? if (CompressedKlassPointers::base() != nullptr) { if (AOTCodeCache::is_on_for_dump()) { movptr(tmp, ExternalAddress(CompressedKlassPointers::base_addr())); } else { mov64(tmp, (int64_t)CompressedKlassPointers::base()); } addq(r, tmp); } and adding `CompressedKlassPointers::base_addr()` to the AOTAddressTable. > I think we have relocation for CompressedOops::base() so we can patch. We have relocation for `CompressedOops::base()` only when heap is not yet initialized: void MacroAssembler::reinit_heapbase() { if (UseCompressedOops) { if (Universe::heap() != nullptr) { if (CompressedOops::base() == nullptr) { MacroAssembler::xorptr(r12_heapbase, r12_heapbase); } else { mov64(r12_heapbase, (int64_t)CompressedOops::base()); } } else { movptr(r12_heapbase, ExternalAddress(CompressedOops::base_addr())); } } } In premain we do add `CompressedOops::base_addr()` to the AOT Address table. But I don't think we are accessing `CompressedOops::base` in adapters or blobs that we are targeting in mainline. At least I haven't come across the need to have `CompressedOops::base` in the address table. Is that correct @vnkozlov @adinn ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2851321094 PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2851326869 PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2073639605 From kvn at openjdk.org Mon May 5 15:35:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 15:35:46 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 04:10:01 GMT, Ashutosh Mehra wrote: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Yes, please do that in `decode_klass_not_null()`. We update other methods for nmethod caching in JDK 26. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2851382631 From mdoerr at openjdk.org Mon May 5 15:54:48 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 May 2025 15:54:48 GMT Subject: RFR: 8350457: Implement Compact Object Headers (Production) [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:37:04 GMT, Roman Kennke wrote: >> As title says. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Build COH CDS archives LGTM. A bit unfortunate that we need so many CDS archives. Maybe some people are interested in e.g. using CDS only with COH. Just an idea for future enhancements (configure options). ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24522#pullrequestreview-2815271196 From kvn at openjdk.org Mon May 5 15:55:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 15:55:48 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: <77aRy2Ss1fvM3EOR9VCGoKiwg4-8PsHOCDRgCd-ekn0=.203e4b18-7b98-4fa2-8391-94e7a412000d@github.com> On Sat, 3 May 2025 04:10:01 GMT, Ashutosh Mehra wrote: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. I think `reinit_heapbase()` is used after JNI calls to put it back into register for compiled code. I don't think For debugging your changes you can add print Into `reinit_heapbase()` using UseNewCode flag and set the flag in `compiler_stubs_init()` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2851441182 From rkennke at openjdk.org Mon May 5 16:17:44 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Mon, 5 May 2025 16:17:44 GMT Subject: RFR: 8350457: Implement Compact Object Headers (Production) [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 15:51:50 GMT, Martin Doerr wrote: > LGTM. A bit unfortunate that we need so many CDS archives. Maybe some people are interested in e.g. using CDS only with COH. Just an idea for future enhancements (configure options). The plan is to get rid of options and combinations. The only option that will most likely remain is +/-UseCompressedOops. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24522#issuecomment-2851519046 From kvn at openjdk.org Mon May 5 16:21:46 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 16:21:46 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: <7xQPMF73IAIbB7vGPS8ipjIiaimA6O4Jmm8XqqMgN4I=.f6084b06-65d6-453e-a8c6-f455ccc7a15a@github.com> On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/metaspaceShared.cpp line 1018: > 1016: CDSConfig::disable_dumping_aot_code(); > 1017: } > 1018: Is this from merge form mainline? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073756831 From kvn at openjdk.org Mon May 5 16:24:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 16:24:48 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/cdsConfig.cpp line 412: > 410: log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored"); > 411: } > 412: Also from merge? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2073760775 From coleenp at openjdk.org Mon May 5 17:27:46 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 5 May 2025 17:27:46 GMT Subject: RFR: 8350457: Implement Compact Object Headers (Production) [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:37:04 GMT, Roman Kennke wrote: >> As title says. > > Roman Kennke has updated the pull request incrementally with one additional commit since the last revision: > > Build COH CDS archives This looks good pending JEP targeting. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24522#pullrequestreview-2815531623 From azafari at openjdk.org Mon May 5 19:32:30 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 5 May 2025 19:32:30 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v18] In-Reply-To: References: Message-ID: <3-R-WdGGPF2CC278xbqVk3l41cVMbn0vLq2Q8QL-dBY=.fd205d21-bddc-4c75-8e80-f05c08123873@github.com> > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: complete code coverage for new impl. All tests pass. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/7cf5338d..87f60cad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=16-17 Stats: 1026 lines in 3 files changed: 866 ins; 124 del; 36 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From ccheung at openjdk.org Mon May 5 19:38:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 5 May 2025 19:38:52 GMT Subject: RFR: 8327495: Print more warning with -Xshare:auto when CDS fails to use archive [v5] In-Reply-To: References: <7KqtLcfk4G02yq2796-brsa3mCwUkeoLvPlfzj1k3JU=.705104e7-1bc7-46c3-b3bd-401c2eefc8e3@github.com> Message-ID: On Wed, 30 Apr 2025 06:51:32 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> fix build errors on macosx platforms > > LGTM. Thanks @iklam and @matias9927 for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24889#issuecomment-2852129930 From ccheung at openjdk.org Mon May 5 19:38:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Mon, 5 May 2025 19:38:52 GMT Subject: Integrated: 8327495: Print more warning with -Xshare:auto when CDS fails to use archive In-Reply-To: <7KqtLcfk4G02yq2796-brsa3mCwUkeoLvPlfzj1k3JU=.705104e7-1bc7-46c3-b3bd-401c2eefc8e3@github.com> References: <7KqtLcfk4G02yq2796-brsa3mCwUkeoLvPlfzj1k3JU=.705104e7-1bc7-46c3-b3bd-401c2eefc8e3@github.com> Message-ID: On Fri, 25 Apr 2025 21:43:19 GMT, Calvin Cheung wrote: > Before this change, if the `-Xshare:auto` is specified with a CDS archive, the user won't see the following error message when the archive has failed to load: > `An error has occurred while processing the the shared archive file.` > This change will print the above error message if the `-Xshare:auto` is specified and the archive is not the default one. > Several existing `log_ino(cds)()` calls have been changed to calling the new function `MetaspaceShared::report_loading_error()`. Also modified couple of tests to check the above error message is printed. > > Passed tiers 1 - 3 testing. This pull request has now been integrated. Changeset: 620f8167 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/620f81671ae721c5e40291f396bbc7707d9d6bcc Stats: 103 lines in 12 files changed: 53 ins; 4 del; 46 mod 8327495: Print more warning with -Xshare:auto when CDS fails to use archive Reviewed-by: iklam, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/24889 From asmehra at openjdk.org Mon May 5 21:13:25 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 5 May 2025 21:13:25 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Sat, 3 May 2025 17:34:38 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - Fix win64 compile failures >> >> Signed-off-by: Ashutosh Mehra >> - Fix AOTCodeFlags.java test >> >> Signed-off-by: Ashutosh Mehra >> - Fix compile failure in minimal config >> >> Signed-off-by: Ashutosh Mehra >> - Revert back changes that added AOTRuntimeConstants. >> Ensure CompressedOops::base and CompressedKlssPointers::base does not >> change in production run >> >> Signed-off-by: Ashutosh Mehra >> - Fix merge conflicts >> >> Signed-off-by: Ashutosh Mehra >> - Store/load AsmRemarks and DbgStrings in aot code cache >> >> Signed-off-by: Ashutosh Mehra >> - Add missing external address in aarch64 >> >> Signed-off-by: Ashutosh Mehra >> - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab > > src/hotspot/share/code/aotCodeCache.cpp line 1119: > >> 1117: uint n = write_bytes(&offset, sizeof(uint)); >> 1118: if (n != sizeof(uint)) { >> 1119: return false; > > Consider using `id_for_C_string()` and record ID instead of coping string. These strings should be recorded in C strings table already. > If `id_for_C_string()` does not find - assert. We should add `add_C_string()` in missing place. The asm remarks and dbg strings are not currently recorded in C string table. I tried to add these strings by calling `AOTCodeCache::add_C_string()` in `AsmRemarkCollection::insert()` but this results in adding LOTS of strings. So I add the strings to the string table only when writing the asm remarks. This keeps the string count in check. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2074200389 From asmehra at openjdk.org Mon May 5 21:13:24 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 5 May 2025 21:13:24 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: - Merge branch 'master' into preserve-runtime-blobs-master - Address Vladimir's comments Signed-off-by: Ashutosh Mehra - Remove irrelevant comment Signed-off-by: Ashutosh Mehra - Fix win64 compile failures Signed-off-by: Ashutosh Mehra - Fix AOTCodeFlags.java test Signed-off-by: Ashutosh Mehra - Fix compile failure in minimal config Signed-off-by: Ashutosh Mehra - Revert back changes that added AOTRuntimeConstants. Ensure CompressedOops::base and CompressedKlssPointers::base does not change in production run Signed-off-by: Ashutosh Mehra - Fix merge conflicts Signed-off-by: Ashutosh Mehra - Store/load AsmRemarks and DbgStrings in aot code cache Signed-off-by: Ashutosh Mehra - Add missing external address in aarch64 Signed-off-by: Ashutosh Mehra - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab ------------- Changes: https://git.openjdk.org/jdk/pull/25019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=01 Stats: 1116 lines in 25 files changed: 874 ins; 125 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 From asmehra at openjdk.org Mon May 5 21:13:24 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 5 May 2025 21:13:24 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Mon, 5 May 2025 15:32:54 GMT, Vladimir Kozlov wrote: > Yes, please do that in decode_klass_not_null(). > We update other methods for nmethod caching in JDK 26. I updated both encode and decode versions. Thanks to @adinn for providing aarch64 changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852346882 From kvn at openjdk.org Mon May 5 21:59:48 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 21:59:48 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab This looks good. Let me test it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852429548 From kvn at openjdk.org Mon May 5 22:10:12 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 22:10:12 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab 1% improvement ;^) ghost29:jdk_git2$ (perf stat -r 100 ./build/product/images/jdk/bin/java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:-AOTAdapterCaching -XX:-AOTStubCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed 0.0252305 +- 0.0000543 seconds time elapsed ( +- 0.22% ) ghost29:jdk_git2$ (perf stat -r 100 ./build/product/images/jdk/bin/java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -XX:-AOTStubCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed 0.0234828 +- 0.0000415 seconds time elapsed ( +- 0.18% ) ghost29:jdk_git2$ (perf stat -r 100 ./build/product/images/jdk/bin/java -XX:AOTCache=app.aotcache -XX:+UnlockDiagnosticVMOptions -XX:+AOTAdapterCaching -XX:+AOTStubCaching -cp hello.jar HelloWorld > /dev/null) 2>&1 | grep elapsed 0.0232267 +- 0.0000355 seconds time elapsed ( +- 0.15% ) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852446885 From kvn at openjdk.org Mon May 5 23:30:23 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 23:30:23 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Test crashes on linux-x64 with debug VM: % make test JTREG=AOT_JDK=true CONF=fastdebug TEST=compiler/c2/cr6865031/Test.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852646752 From kvn at openjdk.org Mon May 5 23:53:18 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 23:53:18 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Test `runtime/cds/appcds/aotClassLinking/MethodHandleTest.java` crashed on linux-aarch64: # # A fatal error has been detected by the Java Runtime Environment: # # SIGSEGV (0xb) at pc=0x0000ffffb4df1f84, pid=3645763, tid=3645766 # # JRE version: Java(TM) SE Runtime Environment (25.0) (fastdebug build 25-internal-LTS-2025-05-05-2218263.vladimir.kozlov.jdkgit2) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-05-05-2218263.vladimir.kozlov.jdkgit2, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-aarch64) # Problematic frame: # v ~RuntimeStub::Shared Runtime throw_NullPointerException_at_call_blob 0x0000ffff73dd2db0 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852738551 From kvn at openjdk.org Mon May 5 23:57:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 5 May 2025 23:57:17 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab I attached hs_err file to RFE in JBS. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2852759147 From iklam at openjdk.org Tue May 6 00:00:22 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 May 2025 00:00:22 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 16:21:56 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/cdsConfig.cpp line 412: > >> 410: log_debug(aot,codecache,init)("AOTCache is not specified - AOTAdapterCaching is ignored"); >> 411: } >> 412: > > Also from merge? That's from the merge. This block doesn't show up when you select "show all commits". > src/hotspot/share/cds/metaspaceShared.cpp line 1018: > >> 1016: CDSConfig::disable_dumping_aot_code(); >> 1017: } >> 1018: > > Is this from merge form mainline? That's from the merge. This block doesn't show up when you select "show all commits". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074421751 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2074419749 From kvn at openjdk.org Tue May 6 00:06:14 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 6 May 2025 00:06:14 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2816460660 From ccheung at openjdk.org Tue May 6 00:29:58 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 6 May 2025 00:29:58 GMT Subject: RFR: 8356020: Failed assert in virtualMemoryTracker.cpp Message-ID: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> This is a temporary fix. The real fix needs more investigation in the NMT area. The change is just to pass `mtNone` as the `mem_tag` when calling `MemoryReserver::reserve()`. Testing: - Ran the test group `open/test/hotspot/jtreg:hotspot_aot_classlinking` 40 times on linux-aarch64 with the options: `-XX:+AOTClassLinking -XX:MaxRAMPercentage=6.25` - tier1 - tiers 2 - 3 (in progress) ------------- Commit messages: - 8356020: Failed assert in virtualMemoryTracker.cpp Changes: https://git.openjdk.org/jdk/pull/25054/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25054&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356020 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25054.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25054/head:pull/25054 PR: https://git.openjdk.org/jdk/pull/25054 From iklam at openjdk.org Tue May 6 00:35:17 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 May 2025 00:35:17 GMT Subject: RFR: 8356020: Failed assert in virtualMemoryTracker.cpp In-Reply-To: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> References: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> Message-ID: On Tue, 6 May 2025 00:24:20 GMT, Calvin Cheung wrote: > This is a temporary fix. The real fix needs more investigation in the NMT area. The change is just to pass `mtNone` as the `mem_tag` when calling `MemoryReserver::reserve()`. > > Testing: > > - Ran the test group `open/test/hotspot/jtreg:hotspot_aot_classlinking` 40 times on linux-aarch64 with the options: `-XX:+AOTClassLinking -XX:MaxRAMPercentage=6.25` > - tier1 > - tiers 2 - 3 (in progress) Marked as reviewed by iklam (Reviewer). LGTM and trivial. This reverts a single line in [JDK-8354547](https://bugs.openjdk.org/browse/JDK-8354547) which revealed a long standing bug (NMT thinks that the region reserved by AcrhiveBuilder is larger than it actually is, on Linux/aarch64). This temporary fix will suppress the noise in testing while we work on a fix for the underlying issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/25054#pullrequestreview-2816484655 PR Comment: https://git.openjdk.org/jdk/pull/25054#issuecomment-2852840836 From sspitsyn at openjdk.org Tue May 6 00:37:17 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Tue, 6 May 2025 00:37:17 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output The fix looks good to me. Nice unification with simplifications. test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54: > 52: > 53: pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail")); > 54: System.out.println("Address is " + Long.toHexString(addr)); Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24672#pullrequestreview-2816484606 PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2074470851 From gziemski at openjdk.org Tue May 6 01:30:15 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 6 May 2025 01:30:15 GMT Subject: RFR: 8356020: Failed assert in virtualMemoryTracker.cpp In-Reply-To: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> References: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> Message-ID: On Tue, 6 May 2025 00:24:20 GMT, Calvin Cheung wrote: > This is a temporary fix. The real fix needs more investigation in the NMT area. The change is just to pass `mtNone` as the `mem_tag` when calling `MemoryReserver::reserve()`. > > Testing: > > - Ran the test group `open/test/hotspot/jtreg:hotspot_aot_classlinking` 40 times on linux-aarch64 with the options: `-XX:+AOTClassLinking -XX:MaxRAMPercentage=6.25` > - tier1 > - tiers 2 - 3 (in progress) LGTM, thank you for fixing, ------------- Marked as reviewed by gziemski (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25054#pullrequestreview-2816542016 From ccheung at openjdk.org Tue May 6 01:37:30 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 6 May 2025 01:37:30 GMT Subject: RFR: 8356020: Failed assert in virtualMemoryTracker.cpp In-Reply-To: References: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> Message-ID: On Tue, 6 May 2025 00:32:17 GMT, Ioi Lam wrote: >> This is a temporary fix. The real fix needs more investigation in the NMT area. The change is just to pass `mtNone` as the `mem_tag` when calling `MemoryReserver::reserve()`. >> >> Testing: >> >> - Ran the test group `open/test/hotspot/jtreg:hotspot_aot_classlinking` 40 times on linux-aarch64 with the options: `-XX:+AOTClassLinking -XX:MaxRAMPercentage=6.25` >> - tier1 >> - tiers 2 - 3 (in progress) > > LGTM and trivial. This reverts a single line in [JDK-8354547](https://bugs.openjdk.org/browse/JDK-8354547) which revealed a long standing bug (NMT thinks that the region reserved by AcrhiveBuilder is larger than it actually is, on Linux/aarch64). > > This temporary fix will suppress the noise in testing while we work on a fix for the underlying issue. Thanks @iklam for the quick review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25054#issuecomment-2852962604 From ccheung at openjdk.org Tue May 6 01:37:31 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Tue, 6 May 2025 01:37:31 GMT Subject: Integrated: 8356020: Failed assert in virtualMemoryTracker.cpp In-Reply-To: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> References: <9Tjwwdo5PZYck6gjDHBZuTi1musOwm64GLVbhLQvs38=.6d315199-fc10-4f85-9ec8-f9a76249c164@github.com> Message-ID: On Tue, 6 May 2025 00:24:20 GMT, Calvin Cheung wrote: > This is a temporary fix. The real fix needs more investigation in the NMT area. The change is just to pass `mtNone` as the `mem_tag` when calling `MemoryReserver::reserve()`. > > Testing: > > - Ran the test group `open/test/hotspot/jtreg:hotspot_aot_classlinking` 40 times on linux-aarch64 with the options: `-XX:+AOTClassLinking -XX:MaxRAMPercentage=6.25` > - tier1 > - tiers 2 - 3 (in progress) This pull request has now been integrated. Changeset: 7f6ea27d Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/7f6ea27d3ef7a8f18f031467d302ed6b03d7d37a Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8356020: Failed assert in virtualMemoryTracker.cpp Reviewed-by: iklam, gziemski ------------- PR: https://git.openjdk.org/jdk/pull/25054 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 azafari at openjdk.org Tue May 6 07:32:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 6 May 2025 07:32:09 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v19] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: removed print_on for release build success. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/87f60cad..aafa57ad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=17-18 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From tschatzl at openjdk.org Tue May 6 08:21:17 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Tue, 6 May 2025 08:21:17 GMT Subject: RFR: 8330022: Failure test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java: Could not initialize class java.util.concurrent.ThreadLocalRandom In-Reply-To: References: Message-ID: On Mon, 5 May 2025 12:21:36 GMT, Coleen Phillimore wrote: > Apply patch suggested by David Leopoldseder for checking the ultimate cause for OOM, which is what the test is looking for. > Tested with tier5-7 with vmTestbase tests that use this package. Marked as reviewed by tschatzl (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25034#pullrequestreview-2817322299 From azafari at openjdk.org Tue May 6 08:45:35 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Tue, 6 May 2025 08:45:35 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v20] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixes for cross-compilations ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/aafa57ad..f276ba93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=18-19 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From myankelevich at openjdk.org Tue May 6 11:04:18 2025 From: myankelevich at openjdk.org (Mikhail Yankelevich) Date: Tue, 6 May 2025 11:04:18 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version In-Reply-To: References: Message-ID: On Mon, 5 May 2025 14:37:46 GMT, Ivan Bereziuk wrote: > fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". > > Tested locally - run test with mocked podman version string. Nitpick: Copyright :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25041#issuecomment-2854152141 From coleenp at openjdk.org Tue May 6 11:44:16 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 May 2025 11:44:16 GMT Subject: RFR: 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:51:13 GMT, Leonid Mesnik wrote: > Test fails with OOME if CDS is disabled. It is not a regression, it just rarely executed in this mode. > The fix is just to slightly increase Metaspace. > Verified that test now pass with CDS disabled + Xcomp. (It fails with Xcomp only) So this still passes with CDS on though? I shrunk this one with ad104932e6c26806c353ad048ce5cff7d2b4c29a to 10. There's another test that I increased MaxMetaspaceSize for valhalla but I can't find it right now. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25046#pullrequestreview-2817944178 From duke at openjdk.org Tue May 6 13:52:34 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 6 May 2025 13:52:34 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version [v2] In-Reply-To: References: Message-ID: > fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". > > Tested locally - run test with mocked podman version string. Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25041/files - new: https://git.openjdk.org/jdk/pull/25041/files/6a1e3d44..345fb84b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25041&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25041&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25041.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25041/head:pull/25041 PR: https://git.openjdk.org/jdk/pull/25041 From duke at openjdk.org Tue May 6 13:52:34 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 6 May 2025 13:52:34 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version In-Reply-To: References: Message-ID: On Tue, 6 May 2025 11:01:41 GMT, Mikhail Yankelevich wrote: > Nitpick: Copyright :) Ah, true. Will fix the year shortly. Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/25041#issuecomment-2854651737 From coleenp at openjdk.org Tue May 6 14:02:17 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 May 2025 14:02:17 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:29:12 GMT, Fredrik Bredberg wrote: > Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. > > If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. > > If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. > > This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. > > When running performance tests we see that the number of test that has improved outnumber the tests that has not. > > Passes tier1-7 with no added problems. Besides the typo, this makes sense. Instead of releasing the lock and reacquiring it to find the heir-apparent, you do that before releasing the lock if there's no successor. So the difference is that if a successor shows up after you check that there's none and assign an heir, the heir will get the lock next and not the successor. Avoiding a CAS seems worth it for the short window where this might happen. src/hotspot/share/runtime/objectMonitor.cpp line 1513: > 1511: > 1512: // If there is a successor we should release the lock as soon as > 1513: // posible, so that the successor can aquire the look. If there is typo: possible ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24927#pullrequestreview-2818374608 PR Review Comment: https://git.openjdk.org/jdk/pull/24927#discussion_r2075529295 From asmehra at openjdk.org Tue May 6 14:14:22 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 6 May 2025 14:14:22 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> On Mon, 5 May 2025 23:54:55 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - Fix win64 compile failures >> >> Signed-off-by: Ashutosh Mehra >> - Fix AOTCodeFlags.java test >> >> Signed-off-by: Ashutosh Mehra >> - Fix compile failure in minimal config >> >> Signed-off-by: Ashutosh Mehra >> - Revert back changes that added AOTRuntimeConstants. >> Ensure CompressedOops::base and CompressedKlssPointers::base does not >> change in production run >> >> Signed-off-by: Ashutosh Mehra >> - Fix merge conflicts >> >> Signed-off-by: Ashutosh Mehra >> - Store/load AsmRemarks and DbgStrings in aot code cache >> >> Signed-off-by: Ashutosh Mehra >> - Add missing external address in aarch64 >> >> Signed-off-by: Ashutosh Mehra >> - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab > > I attached hs_err file to RFE in JBS. @vnkozlov thanks for testing the patch. > % make test JTREG=AOT_JDK=true CONF=fastdebug TEST=compiler/c2/cr6865031/Test.java I can recreate this test locally. Looking into it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2854731804 From jkratochvil at openjdk.org Tue May 6 14:14:26 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Tue, 6 May 2025 14:14:26 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited Message-ID: When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM. test/hotspot/jtreg/containers/docker/TestPids.java TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128 DefaultTasksMax=28776 for RAM 24576MB DefaultTasksMax=19128 for RAM 16384MB DefaultTasksMax=1088 for RAM 1024MB The testcase expects DefaultTasksMax>=20000. ------------- Commit messages: - 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited Changes: https://git.openjdk.org/jdk/pull/25067/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25067&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356277 Stats: 59 lines in 1 file changed: 56 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25067.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25067/head:pull/25067 PR: https://git.openjdk.org/jdk/pull/25067 From lmesnik at openjdk.org Tue May 6 15:20:14 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 6 May 2025 15:20:14 GMT Subject: RFR: 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled In-Reply-To: References: Message-ID: On Mon, 5 May 2025 17:51:13 GMT, Leonid Mesnik wrote: > Test fails with OOME if CDS is disabled. It is not a regression, it just rarely executed in this mode. > The fix is just to slightly increase Metaspace. > Verified that test now pass with CDS disabled + Xcomp. (It fails with Xcomp only) yes, still pass, it takes 3 seconds instead of 2 on my laptop. But nont-CDS configuration worth to test. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25046#issuecomment-2854971703 From sgehwolf at openjdk.org Tue May 6 15:54:16 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 6 May 2025 15:54:16 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version [v2] In-Reply-To: References: Message-ID: <0DghlFkRMghKX4mfWQAghypVEhJJ90P2hbQC2ndaJeg=.656dab4d-6c72-494b-8a37-c9cdaa06a01e@github.com> On Tue, 6 May 2025 13:52:34 GMT, Ivan Bereziuk wrote: >> fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". >> >> Tested locally - run test with mocked podman version string. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year LGTM. Thanks for fixing it. ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25041#pullrequestreview-2818795927 From matsaave at openjdk.org Tue May 6 18:05:17 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Tue, 6 May 2025 18:05:17 GMT Subject: RFR: 8330022: Failure test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java: Could not initialize class java.util.concurrent.ThreadLocalRandom In-Reply-To: References: Message-ID: On Mon, 5 May 2025 12:21:36 GMT, Coleen Phillimore wrote: > Apply patch suggested by David Leopoldseder for checking the ultimate cause for OOM, which is what the test is looking for. > Tested with tier5-7 with vmTestbase tests that use this package. LGTM! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25034#pullrequestreview-2819191469 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 cjplummer at openjdk.org Tue May 6 19:02:19 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 May 2025 19:02:19 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output So this issue is only with tests that attach back to the test process? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2855609698 From coleenp at openjdk.org Tue May 6 19:04:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 May 2025 19:04:19 GMT Subject: RFR: 8330022: Failure test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java: Could not initialize class java.util.concurrent.ThreadLocalRandom In-Reply-To: References: Message-ID: On Mon, 5 May 2025 12:21:36 GMT, Coleen Phillimore wrote: > Apply patch suggested by David Leopoldseder for checking the ultimate cause for OOM, which is what the test is looking for. > Tested with tier5-7 with vmTestbase tests that use this package. Thanks for reviewing, Thomas and Matias. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25034#issuecomment-2855609574 From coleenp at openjdk.org Tue May 6 19:04:19 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Tue, 6 May 2025 19:04:19 GMT Subject: Integrated: 8330022: Failure test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java: Could not initialize class java.util.concurrent.ThreadLocalRandom In-Reply-To: References: Message-ID: On Mon, 5 May 2025 12:21:36 GMT, Coleen Phillimore wrote: > Apply patch suggested by David Leopoldseder for checking the ultimate cause for OOM, which is what the test is looking for. > Tested with tier5-7 with vmTestbase tests that use this package. This pull request has now been integrated. Changeset: 4977588d Author: Coleen Phillimore URL: https://git.openjdk.org/jdk/commit/4977588d5e3424282f40209590737a487747095d Stats: 10 lines in 1 file changed: 9 ins; 0 del; 1 mod 8330022: Failure test/hotspot/jtreg/vmTestbase/nsk/sysdict/share/BTreeTest.java: Could not initialize class java.util.concurrent.ThreadLocalRandom Co-authored-by: David Leopoldseder Reviewed-by: tschatzl, matsaave ------------- PR: https://git.openjdk.org/jdk/pull/25034 From amenkov at openjdk.org Tue May 6 19:29:17 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 6 May 2025 19:29:17 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 6 May 2025 18:59:11 GMT, Chris Plummer wrote: > So this issue is only with tests that attach back to the test process? Yes. There is no issues when tests create dedicated process as target VM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24672#issuecomment-2855690778 From amenkov at openjdk.org Tue May 6 19:36:13 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 6 May 2025 19:36:13 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com> On Tue, 6 May 2025 00:32:21 GMT, Serguei Spitsyn wrote: >> The change is a preparation step to enable attach streaming output by default. >> The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. >> Details in the first comment. >> Testing: tier1..7 with enabled attach streaming output > > test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54: > >> 52: >> 53: pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail")); >> 54: System.out.println("Address is " + Long.toHexString(addr)); > > Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here? The test uses created ProcessBuilder many times, so the test would require much more changes ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2076129633 From pchilanomate at openjdk.org Tue May 6 19:41:15 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 6 May 2025 19:41:15 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:29:12 GMT, Fredrik Bredberg wrote: > Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. > > If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. > > If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. > > This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. > > When running performance tests we see that the number of test that has improved outnumber the tests that has not. > > Passes tier1-7 with no added problems. Looks reasonable to me too. src/hotspot/share/runtime/objectMonitor.cpp line 1510: > 1508: > 1509: for (;;) { > 1510: assert(has_owner(current), "invariant"); Preexisting, but since we're touching this code, this assert seems redundant. We have already checked for this at the beginning of `exit()` and we check again at the end of the loop in case of reacquiring the lock. ------------- PR Review: https://git.openjdk.org/jdk/pull/24927#pullrequestreview-2819406053 PR Review Comment: https://git.openjdk.org/jdk/pull/24927#discussion_r2076129622 From pchilanomate at openjdk.org Tue May 6 19:41:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 6 May 2025 19:41:17 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit In-Reply-To: References: Message-ID: On Tue, 6 May 2025 13:51:23 GMT, Coleen Phillimore wrote: >> Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. >> >> If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. >> >> If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. >> >> This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. >> >> When running performance tests we see that the number of test that has improved outnumber the tests that has not. >> >> Passes tier1-7 with no added problems. > > src/hotspot/share/runtime/objectMonitor.cpp line 1513: > >> 1511: >> 1512: // If there is a successor we should release the lock as soon as >> 1513: // posible, so that the successor can aquire the look. If there is > > typo: possible typos: acquire, lock ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24927#discussion_r2076133472 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 iklam at openjdk.org Tue May 6 22:33:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 May 2025 22:33:39 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache Message-ID: *Specification:* When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. *Examples:* Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible $ java -Xshare:auto -Xlog:cds --version | grep trying [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. [0.009s][error][aot] Loading AOT cache failed: nofile.aot java 25-internal 2025-09-16 Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) ------------- Commit messages: - clean up of existing UL logs for cds - Fixed test cases - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - Much more simplification - Much simplified - More tightening .... but this may be the wrong approach - Added LogTagSet::verify_for_aot_aliases() - Simplified design/implementation: aliasing will always happen with new workflow; added PrintCDSLogsAsAOTLogs diagnostic flag - update - 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds Changes: https://git.openjdk.org/jdk/pull/24895/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8355638 Stats: 185 lines in 13 files changed: 160 ins; 0 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From jsjolen at openjdk.org Tue May 6 22:33:39 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 6 May 2025 22:33:39 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache In-Reply-To: References: Message-ID: On Sat, 26 Apr 2025 05:55:34 GMT, Ioi Lam wrote: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) src/hotspot/share/logging/logSelection.cpp line 25: > 23: */ > 24: > 25: #include "cds/cds_globals.hpp" Maybe wrap this include in `INCLUDE_CDS` as well? src/hotspot/share/logging/logSelectionList.cpp line 103: > 101: injected_copy[1] = 'c'; > 102: injected_copy[2] = 'd'; > 103: injected_copy[3] = 's'; Just use `stringStream` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2075978495 PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2075993963 From iklam at openjdk.org Tue May 6 22:33:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 6 May 2025 22:33:40 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache In-Reply-To: References: Message-ID: On Tue, 6 May 2025 17:47:19 GMT, Johan Sj?len wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > src/hotspot/share/logging/logSelection.cpp line 25: > >> 23: */ >> 24: >> 25: #include "cds/cds_globals.hpp" > > Maybe wrap this include in `INCLUDE_CDS` as well? We usually don't put includes around cds header files (there are lots of them). These header are compatible whether `INCLUDE_CDS` is enabled or not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2076435554 From cjplummer at openjdk.org Tue May 6 22:47:13 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Tue, 6 May 2025 22:47:13 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: <5OdwszO_QsJhBfsJSCkxMjnpcHRd0HNCFbWjeiqc37w=.b6c15111-d499-41d5-b92b-01248e9cafda@github.com> On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output Marked as reviewed by cjplummer (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24672#pullrequestreview-2819881603 From duke at openjdk.org Tue May 6 22:52:59 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Tue, 6 May 2025 22:52:59 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: References: Message-ID: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. Yannik Stradmann 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 remote-tracking branch 'upstream/master' into robust_pthread - Fix build on Windows: Sleep() only accepts milliseconds - Exponentially delay native thread creation retries ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24682/files - new: https://git.openjdk.org/jdk/pull/24682/files/d4841a00..14b2b82f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=01-02 Stats: 87438 lines in 2152 files changed: 66142 ins; 13032 del; 8264 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From iklam at openjdk.org Wed May 7 00:43:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 00:43:41 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v2] In-Reply-To: References: Message-ID: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24895/files - new: https://git.openjdk.org/jdk/pull/24895/files/43bdeac3..15a87cef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Wed May 7 00:50:36 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 00:50:36 GMT Subject: RFR: 8356318: Unexpected VerifyError in AOT training run Message-ID: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> This PR fixes a bug introduced by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426) : when running with -XX:AOTMode=record, we incorrectly reject some valid classes that need to be verified with the old verifier. This bug does not affect JDK 24. ------------- Commit messages: - fixed comment - 8356318: Unexpected VerifyError in AOT training run Changes: https://git.openjdk.org/jdk/pull/25074/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25074&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356318 Stats: 188 lines in 4 files changed: 178 ins; 3 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25074.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25074/head:pull/25074 PR: https://git.openjdk.org/jdk/pull/25074 From kvn at openjdk.org Wed May 7 02:07:19 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 02:07:19 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 00:43:41 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comment Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24895#pullrequestreview-2820133028 From asmehra at openjdk.org Wed May 7 02:40:15 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 02:40:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 01:00:31 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @vnkozlov comments src/hotspot/share/cds/cdsConfig.cpp line 428: > 426: > 427: // At least one AOT flag has been used > 428: _new_aot_flags_used = true; indentation seems off? src/hotspot/share/cds/cdsConfig.cpp line 490: > 488: bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput); > 489: > 490: if (has_output) { Can this if-else block be refactored as: if (!has_output && !has_config) { vm_exit_during_initialization("..."); } if (has_output) { } This pattern in much easier to read IMO. src/hotspot/share/cds/cdsConfig.cpp line 504: > 502: } else { > 503: if (!has_config) { > 504: vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration"); I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent. src/hotspot/share/cds/cdsConfig.cpp line 526: > 524: void CDSConfig::check_aotmode_create() { > 525: if (FLAG_IS_DEFAULT(AOTConfiguration)) { > 526: vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration"); Same suggestion regarding error msg: Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` with `AOTConfiguration must be specified when using -XX:AOTMode=create` src/hotspot/share/cds/metaspaceShared.cpp line 1082: > 1080: for (int i = 0; i < Arguments::num_jvm_args(); i++) { > 1081: const char* arg = Arguments::jvm_args_array()[i]; > 1082: if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 || I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this: strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1) Counting chars is really error prone. sizeof("...")-1 gives the same result. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076664964 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076665081 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667404 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667613 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076667744 From asmehra at openjdk.org Wed May 7 03:54:13 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 03:54:13 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: On Tue, 6 May 2025 14:11:54 GMT, Ashutosh Mehra wrote: > I can recreate this test locally. Looking into it. Looks like the code for C2 blobs generated in assembly phase is not correct. For example, code for new_instance blob is: [0.141s][550409][aot,codecache,stubs] Decoding CodeBlob, name: C2 Runtime new_instance, at [0x00007fed0f904260, 0x00007fed0f9042b8] 88 bytes [0.141s][550409][aot,codecache,stubs] ;; N1: # out( B1 ) <- in( B3 B2 ) Freq: 1 [0.141s][550409][aot,codecache,stubs] ;; B1: # out( B3 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904260: sub $0x8,%rsp [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904267: mov %rbp,(%rsp) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90426b: mov %rsp,0x3e8(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904272: mov %rsi,%rdi [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904275: mov %r15,%rsi [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904278: movabs $0x7fed28908982,%r10 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904282: call *%r10 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904285: nopl 0x0(%rax,%rax,1) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90428d: mov %r12,0x3e8(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904294: mov %r12,0x3f0(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90429b: mov 0x440(%r15),%rax [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a2: mov %r12,0x440(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a9: cmp 0x8(%r15),%r12 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042ad: jne 0x00007fed0f9042b1 [0.141s][550409][aot,codecache,stubs] ;; B2: # out( N1 ) <- in( B1 ) Freq: 0.999999 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042af: pop %rbp [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b0: ret [0.141s][550409][aot,codecache,stubs] ;; B3: # out( N1 ) <- in( B1 ) Freq: 1e-06 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b1: pop %rbp [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b2: jmp Stub::forward_exception [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b7: hlt Look at the instructions generated after the call to runtime method: [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90428d: mov %r12,0x3e8(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904294: mov %r12,0x3f0(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90429b: mov 0x440(%r15),%rax [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a2: mov %r12,0x440(%r15) [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a9: cmp 0x8(%r15),%r12 [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042ad: jne 0x00007fed0f9042b1 Comparing it with the case when AOT code cache is not used: 0x7fffdef07c8d: movq $0x0,0x3e8(%r15) 0x7fffdef07c98: movq $0x0,0x3f0(%r15) 0x7fffdef07ca3: mov 0x440(%r15),%rax 0x7fffdef07caa: movq $0x0,0x440(%r15) 0x7fffdef07cb5: mov 0x8(%r15),%r10 0x7fffdef07cb9: test %r10,%r10 0x7fffdef07cbc: jne 0x7fffdef07cc0 For some reason r12 is used instead of null (0x0). r12 is the CompressedOop::base address. C2 code that generates this is https://github.com/openjdk/jdk/blob/762423d64d10dcdb37800767d2b2f1b7757c804a/src/hotspot/share/opto/generateOptoStub.cpp#L222 I suspect I missed porting a change from premain. @adinn @vnkozlov any idea what that could be? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2856943220 From iklam at openjdk.org Wed May 7 04:10:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 04:10:23 GMT Subject: RFR: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty Message-ID: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. ------------- Commit messages: - 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty Changes: https://git.openjdk.org/jdk/pull/25078/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25078&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351313 Stats: 40 lines in 4 files changed: 39 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25078.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25078/head:pull/25078 PR: https://git.openjdk.org/jdk/pull/25078 From iklam at openjdk.org Wed May 7 05:11:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 05:11:01 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/0eb8b545..5004a0b7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=02-03 Stats: 19 lines in 5 files changed: 4 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Wed May 7 05:11:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 05:11:01 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v3] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 02:33:50 GMT, Ashutosh Mehra wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @vnkozlov comments > > src/hotspot/share/cds/cdsConfig.cpp line 428: > >> 426: >> 427: // At least one AOT flag has been used >> 428: _new_aot_flags_used = true; > > indentation seems off? Fixed. > src/hotspot/share/cds/cdsConfig.cpp line 490: > >> 488: bool has_output = !FLAG_IS_DEFAULT(AOTCacheOutput); >> 489: >> 490: if (has_output) { > > Can this if-else block be refactored as: > > > if (!has_output && !has_config) { > vm_exit_during_initialization("..."); > } > if (has_output) { > > } > > This pattern in much easier to read IMO. Fixed. > src/hotspot/share/cds/cdsConfig.cpp line 504: > >> 502: } else { >> 503: if (!has_config) { >> 504: vm_exit_during_initialization("-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration"); > > I suggest to be consistent in phrasing the error messages related to incomplete options. I liked the way it is worded in `check_aotmode_create()`. So my preference is to replace `-XX:AOTMode=record cannot be used without setting AOTCacheOutput or AOTConfiguration` with `AOTCacheOutput or AOTConfiguration must be specified when using -XX:AOTMode=record`. But you may chose otherwise as long as the structure of the error messages is consistent. I changed to "At least one of AOTCacheOutput and AOTConfiguration must be specified when using -XX:AOTMode=record", so it's clear that both option can be specified together. > src/hotspot/share/cds/cdsConfig.cpp line 526: > >> 524: void CDSConfig::check_aotmode_create() { >> 525: if (FLAG_IS_DEFAULT(AOTConfiguration)) { >> 526: vm_exit_during_initialization("-XX:AOTMode=create cannot be used without setting AOTConfiguration"); > > Same suggestion regarding error msg: > Replace `-XX:AOTMode=create cannot be used without setting AOTConfiguration` > with > `AOTConfiguration must be specified when using -XX:AOTMode=create` Fixed. > src/hotspot/share/cds/metaspaceShared.cpp line 1082: > >> 1080: for (int i = 0; i < Arguments::num_jvm_args(); i++) { >> 1081: const char* arg = Arguments::jvm_args_array()[i]; >> 1082: if (strncmp("-XX:AOTCacheOutput=", arg, 19) == 0 || > > I have seen this hard coding of string length in the `strncmp` call many times in the code base. I wonder why we don't use something like this: > > strncmp("-XX:AOTCacheOutput=", arg, sizeof("-XX:AOTCacheOutput=")-1) > > Counting chars is really error prone. sizeof("...")-1 gives the same result. I end up using `strstr()`, as I don't want to repeat the string literal twice (risking a typo) or use a macro. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796934 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796911 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796869 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796827 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2076796802 From kvn at openjdk.org Wed May 7 06:02:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 06:02:15 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Easy to fix. Look for checks `UseCompressedOops && (CompressedOops::base() == nullptr)` in predicates in `x86_64.ad` and add additional check `!AOTCodeCache::is_on_for dump()`. May be create new function `r12_is_null()` or something. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2857157137 From ccheung at openjdk.org Wed May 7 06:27:12 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 7 May 2025 06:27:12 GMT Subject: RFR: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty In-Reply-To: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> References: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Message-ID: On Wed, 7 May 2025 04:06:12 GMT, Ioi Lam wrote: > Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. Looks good. IMO, it's a trivial fix. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25078#pullrequestreview-2820494991 From shade at openjdk.org Wed May 7 07:10:18 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 7 May 2025 07:10:18 GMT Subject: RFR: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty In-Reply-To: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> References: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Message-ID: On Wed, 7 May 2025 04:06:12 GMT, Ioi Lam wrote: > Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25078#pullrequestreview-2820608460 From duke at openjdk.org Wed May 7 07:41:18 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 7 May 2025 07:41:18 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version In-Reply-To: References: Message-ID: <0uTjCGlGRaARiYEtikIlRjWjGOidXcuhdOM8KWLjMXc=.7e9ea5ef-fc6c-4761-99dd-4557e5dbd8a5@github.com> On Tue, 6 May 2025 11:01:41 GMT, Mikhail Yankelevich wrote: >> fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". >> >> Tested locally - run test with mocked podman version string. > > Nitpick: Copyright :) @myankelev @jerboaa thank you for reviewing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25041#issuecomment-2857443092 From duke at openjdk.org Wed May 7 07:41:20 2025 From: duke at openjdk.org (duke) Date: Wed, 7 May 2025 07:41:20 GMT Subject: RFR: 8356187: TestJcmd.java may incorrectly parse podman version [v2] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 13:52:34 GMT, Ivan Bereziuk wrote: >> fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". >> >> Tested locally - run test with mocked podman version string. > > Ivan Bereziuk has updated the pull request incrementally with one additional commit since the last revision: > > update copyright year @Domest0s Your change (at version 345fb84bd883c4b518eacf0c29740f1d654ac262) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25041#issuecomment-2857445117 From duke at openjdk.org Wed May 7 08:09:19 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Wed, 7 May 2025 08:09:19 GMT Subject: Integrated: 8356187: TestJcmd.java may incorrectly parse podman version In-Reply-To: References: Message-ID: <2HBJLmXK-JVwsMKBgvEiBpCGWk8J7ZQxhrIrTMqN7b4=.e500f7d3-de34-4e89-bd4c-3f9182fe3fbb@github.com> On Mon, 5 May 2025 14:37:46 GMT, Ivan Bereziuk wrote: > fixing an issue with TestJcmd.java test not able to parse podman version string of kind "podman version 4.9.4-rhel". > > Tested locally - run test with mocked podman version string. This pull request has now been integrated. Changeset: 328715d8 Author: Ivan Bereziuk Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/328715d84c0eafb4fe58d28b301138374ddac168 Stats: 13 lines in 1 file changed: 4 ins; 0 del; 9 mod 8356187: TestJcmd.java may incorrectly parse podman version Reviewed-by: sgehwolf ------------- PR: https://git.openjdk.org/jdk/pull/25041 From mbaesken at openjdk.org Wed May 7 08:25:14 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 08:25:14 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch In-Reply-To: References: Message-ID: On Thu, 1 May 2025 04:54:37 GMT, Thomas Stuefe wrote: > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) Looks like a useful 'thing' , thanks ! test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32: > 30: * @modules java.base/jdk.internal.misc > 31: * @requires vm.flagless > 32: * @requires vm.bits == "64" Not sure why the bits == 64 requirement is there but maybe it is because of the other settings used by the test ? ------------- Marked as reviewed by mbaesken (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24980#pullrequestreview-2820822912 PR Review Comment: https://git.openjdk.org/jdk/pull/24980#discussion_r2077075682 From shade at openjdk.org Wed May 7 08:47:15 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 7 May 2025 08:47:15 GMT Subject: RFR: 8356318: Unexpected VerifyError in AOT training run In-Reply-To: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> References: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> Message-ID: On Wed, 7 May 2025 00:45:13 GMT, Ioi Lam wrote: > This PR fixes a bug introduced by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426) : when running with -XX:AOTMode=record, we incorrectly reject some valid classes that need to be verified with the old verifier. > > This bug does not affect JDK 24. Looks fine, thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25074#pullrequestreview-2820925641 From jsikstro at openjdk.org Wed May 7 08:55:16 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 May 2025 08:55:16 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch In-Reply-To: References: Message-ID: On Thu, 1 May 2025 04:54:37 GMT, Thomas Stuefe wrote: > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) I really like this. Will be useful when testing and developing printing code. src/hotspot/share/runtime/globals.hpp line 706: > 704: \ > 705: product(bool, PrintVMInfoAtExit, false, DIAGNOSTIC, \ > 706: "Executes the the VM.info diagnostic command at exit") \ Suggestion: "Executes the VM.info diagnostic command at exit") \ ------------- Marked as reviewed by jsikstro (Committer). PR Review: https://git.openjdk.org/jdk/pull/24980#pullrequestreview-2820910157 PR Review Comment: https://git.openjdk.org/jdk/pull/24980#discussion_r2077124746 From jsjolen at openjdk.org Wed May 7 09:00:15 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 7 May 2025 09:00:15 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 00:43:41 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed comment OK! src/hotspot/share/logging/logSelection.cpp line 189: > 187: // Consider it a match > 188: i ++; > 189: } Wrap this in INCLUDE_CDS. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24895#pullrequestreview-2820879909 PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2077110041 From stuefe at openjdk.org Wed May 7 09:03:34 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 09:03:34 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 08:19:40 GMT, Matthias Baesken wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Update src/hotspot/share/runtime/globals.hpp >> >> Co-authored-by: Joel Sikstr?m > > test/hotspot/jtreg/runtime/ErrorHandling/PrintVMInfoAtExitTest.java line 32: > >> 30: * @modules java.base/jdk.internal.misc >> 31: * @requires vm.flagless >> 32: * @requires vm.bits == "64" > > Not sure why the bits == 64 requirement is there but maybe it is because of the other settings used by the test ? Exactly ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24980#discussion_r2077160550 From stuefe at openjdk.org Wed May 7 09:03:33 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 09:03:33 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch In-Reply-To: References: Message-ID: On Thu, 1 May 2025 04:54:37 GMT, Thomas Stuefe wrote: > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) Thanks, folks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24980#issuecomment-2857743439 From stuefe at openjdk.org Wed May 7 09:03:33 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 09:03:33 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v2] In-Reply-To: References: Message-ID: > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/globals.hpp Co-authored-by: Joel Sikstr?m ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24980/files - new: https://git.openjdk.org/jdk/pull/24980/files/88aacea1..4445265a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24980&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24980&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24980/head:pull/24980 PR: https://git.openjdk.org/jdk/pull/24980 From jsikstro at openjdk.org Wed May 7 09:08:13 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 May 2025 09:08:13 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 09:03:33 GMT, Thomas Stuefe wrote: >> Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. >> >> The `VM.info` output contains a large range of valuable information about the JVM and the process. >> >> The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. >> >> It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/globals.hpp > > Co-authored-by: Joel Sikstr?m Ah, missed the space in my suggestion. src/hotspot/share/runtime/globals.hpp line 706: > 704: \ > 705: product(bool, PrintVMInfoAtExit, false, DIAGNOSTIC, \ > 706: "Executes the VM.info diagnostic command at exit") \ Suggestion: product(bool, PrintVMInfoAtExit, false, DIAGNOSTIC, \ "Executes the VM.info diagnostic command at exit") \ ------------- PR Review: https://git.openjdk.org/jdk/pull/24980#pullrequestreview-2821000897 PR Review Comment: https://git.openjdk.org/jdk/pull/24980#discussion_r2077176795 From sgehwolf at openjdk.org Wed May 7 09:35:29 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 7 May 2025 09:35:29 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads Message-ID: Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. Testing: - [x] GHA - tier 1 (windows failures seem infra related) - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. Thoughts? Opinions? ------------- Commit messages: - 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads Changes: https://git.openjdk.org/jdk/pull/25086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350596 Stats: 170 lines in 5 files changed: 170 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25086/head:pull/25086 PR: https://git.openjdk.org/jdk/pull/25086 From stuefe at openjdk.org Wed May 7 09:41:57 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 09:41:57 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v3] In-Reply-To: References: Message-ID: <4C7ezcFLu_dbz8EfIgmAmYjZO5ymu0O37z6J4y9oFm4=.8b53559b-5f1e-4d68-b3b7-ab9f84edd3a3@github.com> > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/runtime/globals.hpp Co-authored-by: Joel Sikstr?m ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24980/files - new: https://git.openjdk.org/jdk/pull/24980/files/4445265a..53f5419b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24980&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24980&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24980/head:pull/24980 PR: https://git.openjdk.org/jdk/pull/24980 From stuefe at openjdk.org Wed May 7 09:41:57 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 09:41:57 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 09:05:07 GMT, Joel Sikstr?m wrote: > Ah, missed the space in my suggestion. :-) Please re-approve (I will wait for tests to run through before integrating) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24980#issuecomment-2857885185 From adinn at openjdk.org Wed May 7 09:55:16 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 7 May 2025 09:55:16 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: On Wed, 7 May 2025 03:51:32 GMT, Ashutosh Mehra wrote: > I suspect I missed porting a change from premain. @adinn @vnkozlov any idea what that could be? @ashu-mehra Just to explain what is going on here: This is a performance trick. When compressed oops base is null r12 (aka rheapbase) will have been initialized to zero so it can be used as a zero register. This allows, for example, a move instruction to employ a register operand immediate rather than include a 64 bit zero value in the instruction stream, which results in reduced code size. In this case the two moves are zeroing the current Java thread's frame anchor fields, last Java frame pc and sp, which are only set while the thread is in native. This trick is fine when generated code is run in the same JVM but no use if the code is generated in a VM with zero compressed oops base then reloaded into a JVM where it is no longer null. So, Vladimir's advice is to disable this trick when generating AOT code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2857925946 From jsikstro at openjdk.org Wed May 7 11:16:22 2025 From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=) Date: Wed, 7 May 2025 11:16:22 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v3] In-Reply-To: <4C7ezcFLu_dbz8EfIgmAmYjZO5ymu0O37z6J4y9oFm4=.8b53559b-5f1e-4d68-b3b7-ab9f84edd3a3@github.com> References: <4C7ezcFLu_dbz8EfIgmAmYjZO5ymu0O37z6J4y9oFm4=.8b53559b-5f1e-4d68-b3b7-ab9f84edd3a3@github.com> Message-ID: On Wed, 7 May 2025 09:41:57 GMT, Thomas Stuefe wrote: >> Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. >> >> The `VM.info` output contains a large range of valuable information about the JVM and the process. >> >> The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. >> >> It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/globals.hpp > > Co-authored-by: Joel Sikstr?m Marked as reviewed by jsikstro (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24980#pullrequestreview-2821357090 From fbredberg at openjdk.org Wed May 7 12:13:54 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 7 May 2025 12:13:54 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit [v2] In-Reply-To: References: Message-ID: > Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. > > If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. > > If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. > > This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. > > When running performance tests we see that the number of test that has improved outnumber the tests that has not. > > Passes tier1-7 with no added problems. Fredrik Bredberg 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: - Updated after review - Merge branch 'master' into 8355646_optimize_objectmonitor_exit - 8355646: Optimize ObjectMonitor::exit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24927/files - new: https://git.openjdk.org/jdk/pull/24927/files/fc2d1466..91a37196 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24927&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24927&range=00-01 Stats: 25768 lines in 702 files changed: 20387 ins; 2840 del; 2541 mod Patch: https://git.openjdk.org/jdk/pull/24927.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24927/head:pull/24927 PR: https://git.openjdk.org/jdk/pull/24927 From fbredberg at openjdk.org Wed May 7 12:13:55 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 7 May 2025 12:13:55 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit [v2] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 19:33:21 GMT, Patricio Chilano Mateo wrote: >> Fredrik Bredberg 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: >> >> - Updated after review >> - Merge branch 'master' into 8355646_optimize_objectmonitor_exit >> - 8355646: Optimize ObjectMonitor::exit > > src/hotspot/share/runtime/objectMonitor.cpp line 1510: > >> 1508: >> 1509: for (;;) { >> 1510: assert(has_owner(current), "invariant"); > > Preexisting, but since we're touching this code, this assert seems redundant. We have already checked for this at the beginning of `exit()` and we check again at the end of the loop in case of reacquiring the lock. I agree. Removed the `assert()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24927#discussion_r2077483245 From fbredberg at openjdk.org Wed May 7 12:13:55 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 7 May 2025 12:13:55 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit [v2] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 19:36:24 GMT, Patricio Chilano Mateo wrote: >> src/hotspot/share/runtime/objectMonitor.cpp line 1513: >> >>> 1511: >>> 1512: // If there is a successor we should release the lock as soon as >>> 1513: // posible, so that the successor can aquire the look. If there is >> >> typo: possible > > typos: acquire, lock Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24927#discussion_r2077483852 From cnorrbin at openjdk.org Wed May 7 13:08:53 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 7 May 2025 13:08:53 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 Message-ID: Hi, There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. ------------- Commit messages: - still close file descriptor if we fail to read Changes: https://git.openjdk.org/jdk/pull/25093/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25093&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354878 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25093/head:pull/25093 PR: https://git.openjdk.org/jdk/pull/25093 From azafari at openjdk.org Wed May 7 13:16:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 7 May 2025 13:16:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v21] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: more tests for full coverage of update_region. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/f276ba93..e5375140 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=19-20 Stats: 140 lines in 3 files changed: 124 ins; 14 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From mbaesken at openjdk.org Wed May 7 13:56:17 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 13:56:17 GMT Subject: RFR: 8356025: Provide a PrintVMInfoAtExit diagnostic switch [v3] In-Reply-To: <4C7ezcFLu_dbz8EfIgmAmYjZO5ymu0O37z6J4y9oFm4=.8b53559b-5f1e-4d68-b3b7-ab9f84edd3a3@github.com> References: <4C7ezcFLu_dbz8EfIgmAmYjZO5ymu0O37z6J4y9oFm4=.8b53559b-5f1e-4d68-b3b7-ab9f84edd3a3@github.com> Message-ID: On Wed, 7 May 2025 09:41:57 GMT, Thomas Stuefe wrote: >> Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. >> >> The `VM.info` output contains a large range of valuable information about the JVM and the process. >> >> The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. >> >> It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/share/runtime/globals.hpp > > Co-authored-by: Joel Sikstr?m Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24980#pullrequestreview-2821858746 From kvn at openjdk.org Wed May 7 14:01:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 14:01:17 GMT Subject: RFR: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty In-Reply-To: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> References: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Message-ID: On Wed, 7 May 2025 04:06:12 GMT, Ioi Lam wrote: > Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25078#pullrequestreview-2821876420 From kvn at openjdk.org Wed May 7 14:20:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 14:20:17 GMT Subject: RFR: 8356318: Unexpected VerifyError in AOT training run In-Reply-To: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> References: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> Message-ID: On Wed, 7 May 2025 00:45:13 GMT, Ioi Lam wrote: > This PR fixes a bug introduced by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426) : when running with -XX:AOTMode=record, we incorrectly reject some valid classes that need to be verified with the old verifier. > > This bug does not affect JDK 24. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25074#pullrequestreview-2821943762 From kvn at openjdk.org Wed May 7 14:30:27 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 14:30:27 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab In `premain` branch we don't have null in R12 because we set shift together with base when we generate AOT code: [compressedOops.cpp#L51](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/oops/compressedOops.cpp#L51) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2858806920 From kvn at openjdk.org Wed May 7 14:43:15 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 14:43:15 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: On Wed, 7 May 2025 09:52:23 GMT, Andrew Dinn wrote: >>> I can recreate this test locally. Looking into it. >> >> Looks like the code for C2 blobs generated in assembly phase is not correct. >> For example, code for new_instance blob is: >> >> >> [0.141s][550409][aot,codecache,stubs] Decoding CodeBlob, name: C2 Runtime new_instance, at [0x00007fed0f904260, 0x00007fed0f9042b8] 88 bytes >> [0.141s][550409][aot,codecache,stubs] ;; N1: # out( B1 ) <- in( B3 B2 ) Freq: 1 >> [0.141s][550409][aot,codecache,stubs] ;; B1: # out( B3 B2 ) <- BLOCK HEAD IS JUNK Freq: 1 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904260: sub $0x8,%rsp >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904267: mov %rbp,(%rsp) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90426b: mov %rsp,0x3e8(%r15) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904272: mov %rsi,%rdi >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904275: mov %r15,%rsi >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904278: movabs $0x7fed28908982,%r10 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904282: call *%r10 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904285: nopl 0x0(%rax,%rax,1) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90428d: mov %r12,0x3e8(%r15) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f904294: mov %r12,0x3f0(%r15) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90429b: mov 0x440(%r15),%rax >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a2: mov %r12,0x440(%r15) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042a9: cmp 0x8(%r15),%r12 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042ad: jne 0x00007fed0f9042b1 >> [0.141s][550409][aot,codecache,stubs] ;; B2: # out( N1 ) <- in( B1 ) Freq: 0.999999 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042af: pop %rbp >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b0: ret >> [0.141s][550409][aot,codecache,stubs] ;; B3: # out( N1 ) <- in( B1 ) Freq: 1e-06 >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b1: pop %rbp >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b2: jmp Stub::forward_exception >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042b7: hlt >> >> Look at the instructions generated after the call to runtime method: >> >> >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f90428d: mov %r12,0x3e8(%r15) >> [0.141s][550409][aot,codecache,stubs] 0x00007fed0f9042... > >> I suspect I missed porting a change from premain. @adinn @vnkozlov any idea what that could be? > > @ashu-mehra Just to explain what is going on here: > > This is a performance trick. When compressed oops base is null r12 (aka rheapbase) will have been initialized to zero so it can be used as a zero register. This allows, for example, a move instruction to employ a register operand immediate rather than include a 64 bit zero value in the instruction stream, which results in reduced code size. In this case the two moves are zeroing the current Java thread's frame anchor fields, last Java frame pc and sp, which are only set while the thread is in native. > > This trick is fine when generated code is run in the same JVM but no use if the code is generated in a VM with zero compressed oops base then reloaded into a JVM where it is no longer null. > > So, Vladimir's advice is to disable this trick when generating AOT code. @adinn Do you remember why we commented `UseCompatibleCompressedOops` setting?: https://github.com/openjdk/leyden/commit/478f86f9cd6df6b92c037c83d0540b9c5fe97e5c It is still not enabled - how we are not crashing in premain? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2858861733 From pchilanomate at openjdk.org Wed May 7 14:48:17 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 7 May 2025 14:48:17 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 12:13:54 GMT, Fredrik Bredberg wrote: >> Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. >> >> If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. >> >> If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. >> >> This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. >> >> When running performance tests we see that the number of test that has improved outnumber the tests that has not. >> >> Passes tier1-7 with no added problems. > > Fredrik Bredberg 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: > > - Updated after review > - Merge branch 'master' into 8355646_optimize_objectmonitor_exit > - 8355646: Optimize ObjectMonitor::exit Thanks! ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24927#pullrequestreview-2822062820 From mbaesken at openjdk.org Wed May 7 14:56:01 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 7 May 2025 14:56:01 GMT Subject: RFR: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro Message-ID: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. See the discussion here https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html ------------- Commit messages: - JDK-8356394 Changes: https://git.openjdk.org/jdk/pull/25099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356394 Stats: 21 lines in 3 files changed: 0 ins; 20 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25099/head:pull/25099 PR: https://git.openjdk.org/jdk/pull/25099 From asmehra at openjdk.org Wed May 7 15:06:19 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 15:06:19 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: On Wed, 7 May 2025 14:40:29 GMT, Vladimir Kozlov wrote: > It is still not enabled - how we are not crashing in premain? That's a news to me. I thought we were setting `UseCompatibleCompressedOops` to true which is why we are avoiding this issue in premain. But .. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2858954202 From adinn at openjdk.org Wed May 7 15:34:15 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 7 May 2025 15:34:15 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: On Wed, 7 May 2025 14:40:29 GMT, Vladimir Kozlov wrote: >>> I suspect I missed porting a change from premain. @adinn @vnkozlov any idea what that could be? >> >> @ashu-mehra Just to explain what is going on here: >> >> This is a performance trick. When compressed oops base is null r12 (aka rheapbase) will have been initialized to zero so it can be used as a zero register. This allows, for example, a move instruction to employ a register operand immediate rather than include a 64 bit zero value in the instruction stream, which results in reduced code size. In this case the two moves are zeroing the current Java thread's frame anchor fields, last Java frame pc and sp, which are only set while the thread is in native. >> >> This trick is fine when generated code is run in the same JVM but no use if the code is generated in a VM with zero compressed oops base then reloaded into a JVM where it is no longer null. >> >> So, Vladimir's advice is to disable this trick when generating AOT code. > > @adinn Do you remember why we commented `UseCompatibleCompressedOops` setting?: > https://github.com/openjdk/leyden/commit/478f86f9cd6df6b92c037c83d0540b9c5fe97e5c > > It is still not enabled - how we are not crashing in premain? @vnkozlov Ergonomics comes into play. It is set to true in cdsConfig.cpp if CacheDataStore != nullptr. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859064405 From asmehra at openjdk.org Wed May 7 15:40:16 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 15:40:16 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> Message-ID: <8z5J8AajcQA7YjCT8k4MFzgtN7el8CablPhGPvau9yY=.dac69bdc-6466-4415-8105-fea569573668@github.com> On Wed, 7 May 2025 15:31:35 GMT, Andrew Dinn wrote: >> @adinn Do you remember why we commented `UseCompatibleCompressedOops` setting?: >> https://github.com/openjdk/leyden/commit/478f86f9cd6df6b92c037c83d0540b9c5fe97e5c >> >> It is still not enabled - how we are not crashing in premain? > > @vnkozlov Ergonomics comes into play. It is set to true in cdsConfig.cpp if CacheDataStore != nullptr. @adinn in premain it is commented out - https://github.com/openjdk/leyden/blob/f09d2f7724c628c90df51eacb16b33fee710ed1a/src/hotspot/share/cds/cdsConfig.cpp#L790 #ifdef _LP64 // FLAG_SET_ERGO_IF_DEFAULT(UseCompatibleCompressedOops, true); // FIXME @iklam - merge with mainline - UseCompatibleCompressedOops #endif I don't see any other place it is set. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859083913 From lmesnik at openjdk.org Wed May 7 15:45:25 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 7 May 2025 15:45:25 GMT Subject: Integrated: 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled In-Reply-To: References: Message-ID: <4zQ8ZudBToUnJymsj1nlCYji4tdh5BfOPIWNZHLew2o=.0f999186-d3d9-4e17-9b09-47d3e95dc9f7@github.com> On Mon, 5 May 2025 17:51:13 GMT, Leonid Mesnik wrote: > Test fails with OOME if CDS is disabled. It is not a regression, it just rarely executed in this mode. > The fix is just to slightly increase Metaspace. > Verified that test now pass with CDS disabled + Xcomp. (It fails with Xcomp only) This pull request has now been integrated. Changeset: c8a30c2a Author: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/c8a30c2aaba04c11b70a4f74ee74452250be6e59 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8347004: vmTestbase/metaspace/shrink_grow/ShrinkGrowTest/ShrinkGrowTest.java fails with CDS disabled Reviewed-by: coleenp ------------- PR: https://git.openjdk.org/jdk/pull/25046 From adinn at openjdk.org Wed May 7 15:46:19 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 7 May 2025 15:46:19 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: <8z5J8AajcQA7YjCT8k4MFzgtN7el8CablPhGPvau9yY=.dac69bdc-6466-4415-8105-fea569573668@github.com> References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> <8z5J8AajcQA7YjCT8k4MFzgtN7el8CablPhGPvau9yY=.dac69bdc-6466-4415-8105-fea569573668@github.com> Message-ID: <82gBa1jyJx2ufjpp1VfS5j9KeivBL9N5M8Rf-3pL8RY=.c7e5f335-a391-4d87-a1a1-808b92753f37@github.com> On Wed, 7 May 2025 15:37:54 GMT, Ashutosh Mehra wrote: > I don't see any other place it is set. I do ;-) Look at cdsConfig.cpp:468 in method CDSConfig::check_vm_args_consistency() if (CacheDataStore != nullptr) { // Leyden temp work-around: // // By default, when using CacheDataStore, use the HeapBasedNarrowOop mode so that // AOT code can be always work regardless of runtime heap range. // // If you are *absolutely sure* that the CompressedOops::mode() will be the same // between training and production runs (e.g., if you specify -Xmx128m // for both training and production runs, and you know the OS will always reserve // the heap under 4GB), you can explicitly disable this with: // java -XX:-UseCompatibleCompressedOops -XX:CacheDataStore=... // However, this is risky and there's a chance that the production run will be slower // because it is unable to load the AOT code cache. #ifdef _LP64 FLAG_SET_ERGO_IF_DEFAULT(UseCompatibleCompressedOops, true); // <== here #endif ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859103569 From kvn at openjdk.org Wed May 7 16:06:17 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 16:06:17 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: <82gBa1jyJx2ufjpp1VfS5j9KeivBL9N5M8Rf-3pL8RY=.c7e5f335-a391-4d87-a1a1-808b92753f37@github.com> References: <7e6TPADKIO-d9cqpuhk-O-4bEX1esJsQdFtztwF5gcU=.8df43b49-7e62-4aa4-8f14-184b9376467b@github.com> <8z5J8AajcQA7YjCT8k4MFzgtN7el8CablPhGPvau9yY=.dac69bdc-6466-4415-8105-fea569573668@github.com> <82gBa1jyJx2ufjpp1VfS5j9KeivBL9N5M8Rf-3pL8RY=.c7e5f335-a391-4d87-a1a1-808b92753f37@github.com> Message-ID: On Wed, 7 May 2025 15:43:55 GMT, Andrew Dinn wrote: >> @adinn in premain it is commented out - >> https://github.com/openjdk/leyden/blob/f09d2f7724c628c90df51eacb16b33fee710ed1a/src/hotspot/share/cds/cdsConfig.cpp#L790 >> >> >> #ifdef _LP64 >> // FLAG_SET_ERGO_IF_DEFAULT(UseCompatibleCompressedOops, true); // FIXME @iklam - merge with mainline - UseCompatibleCompressedOops >> #endif >> >> >> I don't see any other place it is set. > >> I don't see any other place it is set. > > I do ;-) > > Look at cdsConfig.cpp:468 in method CDSConfig::check_vm_args_consistency() > > > > if (CacheDataStore != nullptr) { > // Leyden temp work-around: > // > // By default, when using CacheDataStore, use the HeapBasedNarrowOop mode so that > // AOT code can be always work regardless of runtime heap range. > // > // If you are *absolutely sure* that the CompressedOops::mode() will be the same > // between training and production runs (e.g., if you specify -Xmx128m > // for both training and production runs, and you know the OS will always reserve > // the heap under 4GB), you can explicitly disable this with: > // java -XX:-UseCompatibleCompressedOops -XX:CacheDataStore=... > // However, this is risky and there's a chance that the production run will be slower > // because it is unable to load the AOT code cache. > #ifdef _LP64 > FLAG_SET_ERGO_IF_DEFAULT(UseCompatibleCompressedOops, true); // <== here > #endif @adinn I think you are looking on old version of `premain` branch. The latest changeset is Igor's "Address review comments". ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859162780 From adinn at openjdk.org Wed May 7 16:13:18 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 7 May 2025 16:13:18 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <7MtJxoIoftDUXjZEGtVUX-_Yct3XfjbT65fSztm_FBA=.65168a5b-53fd-4fdc-a128-18d2fc1ade97@github.com> On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Ah yes, I was looking at an old version. Apologies for that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859183350 From adinn at openjdk.org Wed May 7 16:38:15 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Wed, 7 May 2025 16:38:15 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab I looked back at the history and found that this line got commented out as part of a merge from mainline (date: 2025-01-15 shaid 4cd4c7cdfae7b4b5eb3308abc8fa8d0ed7581ad8). I'm not at all sure why Ioi did this and have no idea why he added my name to the original FIXME. The very next change he made in the premain branch was to update the FIXME comment, resetting it to his name. I also don't understand why this is not biting us in premain. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859254016 From kvn at openjdk.org Wed May 7 16:44:23 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 16:44:23 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab There could be testing failures which expect some state of compressed oops. I will test enabling this flag. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859268199 From stuefe at openjdk.org Wed May 7 16:55:28 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 7 May 2025 16:55:28 GMT Subject: Integrated: 8356025: Provide a PrintVMInfoAtExit diagnostic switch In-Reply-To: References: Message-ID: On Thu, 1 May 2025 04:54:37 GMT, Thomas Stuefe wrote: > Provides a `PrintVMInfoAtExit` diagnostic switch that, if active, causes the JVM to print out the equivalent of `jcmd VM.info` before exiting. > > The `VM.info` output contains a large range of valuable information about the JVM and the process. > > The switch can be surprisingly useful, e.g. when analysing short-lived processes that are too quick to be analysed with jcmd, or analysing JVM child processes in a process tree, and so on. Going forward, it can also remove the need for some of the more specific PrintxxxAtExit flags. > > It can also make writing tests easier (want to make sure switch XX enables condition YY, and YY is printed as part of VM.info? Just start the VM with PrintVMInfoAtExit and parse the output ) This pull request has now been integrated. Changeset: da5dc528 Author: Thomas Stuefe URL: https://git.openjdk.org/jdk/commit/da5dc5287b3a81909a5c316f164f7f42d07d3664 Stats: 70 lines in 3 files changed: 70 ins; 0 del; 0 mod 8356025: Provide a PrintVMInfoAtExit diagnostic switch Reviewed-by: mbaesken, jsikstro ------------- PR: https://git.openjdk.org/jdk/pull/24980 From asmehra at openjdk.org Wed May 7 16:58:15 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 16:58:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4] In-Reply-To: References: Message-ID: <5EjPGeqBe78hoAgNgx8-1_BeO8cAyoP0H2t_e-41LnU=.2cfa426f-8240-43ab-9c9a-7352f2614243@github.com> On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java thanks for addressing the comments. lgtm ------------- Marked as reviewed by asmehra (Committer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2822524147 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 iklam at openjdk.org Wed May 7 17:36:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 17:36:30 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run Message-ID: Please see [JDK-8356407](https://bugs.openjdk.org/browse/JDK-8356407) for a detailed description of the problem. This fix strictly tightens the handling of class verification during CDS dump -- now the `VerificationType::is_reference_assignable_from()` checks are skipped only when dumping the "classic static archive". In the AOT training run, CDS is configured to dump a "preimage static archive". I.e., - `CDSConfig::is_dumping_classic_static_archive()` == false - `CDSConfig::is_dumping_preimage_static_archive()` == true Therefore, the skipping no longer happens. I added a test case and improve the comments in the C++ code. (This bug is caused by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), which is new in JDK 25. So it does not affect JDK 24 or earlier releases). ------------- Commit messages: - 8356407: Part of class verification is skipped in AOT training run Changes: https://git.openjdk.org/jdk/pull/25104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356407 Stats: 120 lines in 5 files changed: 93 ins; 7 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/25104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25104/head:pull/25104 PR: https://git.openjdk.org/jdk/pull/25104 From iklam at openjdk.org Wed May 7 17:39:24 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 17:39:24 GMT Subject: RFR: 8356318: Unexpected VerifyError in AOT training run In-Reply-To: References: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> Message-ID: On Wed, 7 May 2025 08:45:00 GMT, Aleksey Shipilev wrote: >> This PR fixes a bug introduced by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426) : when running with -XX:AOTMode=record, we incorrectly reject some valid classes that need to be verified with the old verifier. >> >> This bug does not affect JDK 24. > > Looks fine, thanks! Thanks @shipilev @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25074#issuecomment-2859512883 From iklam at openjdk.org Wed May 7 17:39:26 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 17:39:26 GMT Subject: Integrated: 8356318: Unexpected VerifyError in AOT training run In-Reply-To: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> References: <-FWuupLizGatcae7yHTHc4UHX8-sWR7WMo7b303SRMI=.7794e317-baa2-477b-9e06-dd3e0de599e0@github.com> Message-ID: On Wed, 7 May 2025 00:45:13 GMT, Ioi Lam wrote: > This PR fixes a bug introduced by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426) : when running with -XX:AOTMode=record, we incorrectly reject some valid classes that need to be verified with the old verifier. > > This bug does not affect JDK 24. This pull request has now been integrated. Changeset: 40f696db Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/40f696dbe49f348327bf0f3dc6493a7110918813 Stats: 188 lines in 4 files changed: 178 ins; 3 del; 7 mod 8356318: Unexpected VerifyError in AOT training run Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25074 From iklam at openjdk.org Wed May 7 17:43:18 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 17:43:18 GMT Subject: RFR: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty In-Reply-To: References: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Message-ID: On Wed, 7 May 2025 07:07:19 GMT, Aleksey Shipilev wrote: >> Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @vnkozlov @calvinccheung for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25078#issuecomment-2859543540 From iklam at openjdk.org Wed May 7 17:43:19 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 17:43:19 GMT Subject: Integrated: 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty In-Reply-To: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> References: <3GE-LqDYAAbqRjmr3K3PQH6HosiMhugj3HiDp4DlIaA=.bc550a19-2cdc-449f-8c07-3b1bb65654a8@github.com> Message-ID: On Wed, 7 May 2025 04:06:12 GMT, Ioi Lam wrote: > Please review this trivial patch. When `-XX:AOTMode=`, etc, is given on the command line, the global takes on the problematic value `nullptr`. I added constraint functions to forbid such cases. This pull request has now been integrated. Changeset: 28e6b7cb Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/28e6b7cb7462b0e231698c86ff57828e9e288087 Stats: 40 lines in 4 files changed: 39 ins; 1 del; 0 mod 8351313: VM crashes when AOTMode/AOTCache/AOTConfiguration are empty Reviewed-by: ccheung, shade, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25078 From sspitsyn at openjdk.org Wed May 7 17:47:18 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 7 May 2025 17:47:18 GMT Subject: RFR: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com> References: <1yfPR9tE5koDZLUZcr5f5pYsjX70zMfklsE1qy-oPT4=.46a29830-6e06-4a10-b7f3-7a8f9d9d0f3f@github.com> Message-ID: On Tue, 6 May 2025 19:33:22 GMT, Alex Menkov wrote: >> test/hotspot/jtreg/runtime/NMT/CommitOverlappingRegions.java line 54: >> >>> 52: >>> 53: pb.command(new PidJcmdExecutor().getCommandLine("VM.native_memory", "detail")); >>> 54: System.out.println("Address is " + Long.toHexString(addr)); >> >> Q: Can we use the `NMTTestUtils.startJcmdVMNativeMemory()` here? > > The test uses created ProcessBuilder many times, so the test would require much more changes Okay, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24672#discussion_r2078164486 From iklam at openjdk.org Wed May 7 18:13:41 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 18:13:41 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v3] In-Reply-To: References: Message-ID: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) Ioi Lam 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 14 additional commits since the last revision: - cds+aot+load -> aot+load - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - @jdksjolen comment - Fixed comment - clean up of existing UL logs for cds - Fixed test cases - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - Much more simplification - Much simplified - More tightening .... but this may be the wrong approach - ... and 4 more: https://git.openjdk.org/jdk/compare/f34bc86a...b772b3d4 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24895/files - new: https://git.openjdk.org/jdk/pull/24895/files/15a87cef..b772b3d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=01-02 Stats: 1843 lines in 88 files changed: 902 ins; 534 del; 407 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Wed May 7 18:14:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 18:14:11 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v2] In-Reply-To: References: Message-ID: <7Wctu1vfyT8B1U_mU4AXm0AOUkdXptJT-kUYHiTIqIA=.e89f8e56-0b31-417f-b8b7-64236b926698@github.com> On Wed, 7 May 2025 08:34:31 GMT, Johan Sj?len wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed comment > > src/hotspot/share/logging/logSelection.cpp line 189: > >> 187: // Consider it a match >> 188: i ++; >> 189: } > > Wrap this in INCLUDE_CDS. Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2078205694 From amenkov at openjdk.org Wed May 7 18:21:37 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 7 May 2025 18:21:37 GMT Subject: Integrated: 8354461: Update tests to disable streaming output for attach tools In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 23:30:35 GMT, Alex Menkov wrote: > The change is a preparation step to enable attach streaming output by default. > The fix updates a number of tests which fail with timeout in tier1..tier7 when attach streaming output is enabled. > Details in the first comment. > Testing: tier1..7 with enabled attach streaming output This pull request has now been integrated. Changeset: cb021580 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/cb02158090fa97bf4d11d09c23ce3058a5f83fc8 Stats: 159 lines in 19 files changed: 44 ins; 56 del; 59 mod 8354461: Update tests to disable streaming output for attach tools Reviewed-by: sspitsyn, cjplummer ------------- PR: https://git.openjdk.org/jdk/pull/24672 From kvn at openjdk.org Wed May 7 19:11:02 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 19:11:02 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <1shOfSgE57gegdChqv-NY00cKuBQrI2Fq-UEZ5w0gR4=.123963df-22fe-4b43-a45f-659bc504c064@github.com> On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab We were lucky. I reproduced issue in `premain` with HelloWord by running `AOTMode=create -Xmx4G` and product run with `Xmx31g`. It has the same `shift = 3` but different base (0 for 4Gb). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859928242 From kvn at openjdk.org Wed May 7 19:34:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 19:34:53 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Unfortunately we can't enable the flag (that is why Ioi commented it, I think): # Internal Error (/leyden/open/src/hotspot/share/oops/compressedOops.cpp:87), pid=1169225, tid=1169229 # assert((intptr_t)base() <= ((intptr_t)_heap_address_range.start() - (intptr_t)os::vm_page_size()) || base() == nullptr) failed: invalid value # # JRE version: (25.0) (fastdebug build ) # Java VM: Java HotSpot(TM) 64-Bit Server VM (fastdebug 25-internal-LTS-2025-05-07-1649004.vkozlov..., mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xba81e9] CompressedOops::initialize(ReservedHeapSpace const&)+0x3c9 @ashu-mehra please restore verification check for COOP base you had. instead of patching `x86_64.ad` file ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2859997830 From kvn at openjdk.org Wed May 7 19:37:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 19:37:54 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab I think it is fine not use AOT code when the heap base does not match. Based on my test it will happen only with big heap's size difference between assembly and production runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860006997 From dnsimon at openjdk.org Wed May 7 20:08:02 2025 From: dnsimon at openjdk.org (Doug Simon) Date: Wed, 7 May 2025 20:08:02 GMT Subject: RFR: 8348203: [JVMCI] Make eager JVMCI initialization observable in the debugger In-Reply-To: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com> References: <0n4M57_4SZLCoazU26tJrOiKq2YUzCtU8OvlniixyA0=.c2df9707-c0ef-4c43-b106-772c3c626b4a@github.com> Message-ID: On Tue, 21 Jan 2025 16:59:05 GMT, Volker Simonis wrote: > I realized that I can't debug (i.e. with a Java debugger) the Graal compiler initialization if it happens eagerly (e.g. with `EagerJVMCI`, `JVMCIPrintProperties`, `JVMCILibDumpJNIConfig`). Not that this is something I need every day, but I think it can easily be fixed by moving the early initializing a little further down, right after `JvmtiExport::post_vm_initialized()`: > > > diff --git a/src/hotspot/share/runtime/threads.cpp b/src/hotspot/share/runtime/threads.cpp > index 1cab9bc5d53..191409c22e3 100644 > --- a/src/hotspot/share/runtime/threads.cpp > +++ b/src/hotspot/share/runtime/threads.cpp > @@ -806,12 +806,6 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { > } > #endif > > -#if INCLUDE_JVMCI > - if (force_JVMCI_initialization) { > - JVMCI::initialize_compiler(CHECK_JNI_ERR); > - } > -#endif > - > if (NativeHeapTrimmer::enabled()) { > NativeHeapTrimmer::initialize(); > } > @@ -826,6 +820,12 @@ jint Threads::create_vm(JavaVMInitArgs* args, bool* canTryAgain) { > // Notify JVMTI agents that VM initialization is complete - nop if no agents. > JvmtiExport::post_vm_initialized(); > > +#if INCLUDE_JVMCI > + if (force_JVMCI_initialization) { > + JVMCI::initialize_compiler(CHECK_JNI_ERR); > + } > +#endif > + > JFR_ONLY(Jfr::on_create_vm_3();) > > #if INCLUDE_MANAGEMENT FYI: https://bugs.openjdk.org/browse/JDK-8356447 ------------- PR Comment: https://git.openjdk.org/jdk/pull/23219#issuecomment-2860185609 From dholmes at openjdk.org Wed May 7 20:26:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 7 May 2025 20:26:56 GMT Subject: RFR: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro In-Reply-To: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> References: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> Message-ID: On Wed, 7 May 2025 14:48:50 GMT, Matthias Baesken wrote: > The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. > See the discussion here > https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html This seems fine to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25099#pullrequestreview-2823120057 From coleenp at openjdk.org Wed May 7 20:41:53 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Wed, 7 May 2025 20:41:53 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run In-Reply-To: References: Message-ID: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> On Wed, 7 May 2025 17:29:25 GMT, Ioi Lam wrote: > Please see [JDK-8356407](https://bugs.openjdk.org/browse/JDK-8356407) for a detailed description of the problem. > > This fix strictly tightens the handling of class verification during CDS dump -- now the `VerificationType::is_reference_assignable_from()` checks are skipped only when dumping the "classic static archive". > > In the AOT training run, CDS is configured to dump a "preimage static archive". I.e., > > - `CDSConfig::is_dumping_classic_static_archive()` == false > - `CDSConfig::is_dumping_preimage_static_archive()` == true > > Therefore, the skipping no longer happens. > > I added a test case and improve the comments in the C++ code. > > (This bug is caused by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), which is new in JDK 25. So it does not affect JDK 24 or earlier releases). The new comments make sense. src/hotspot/share/classfile/systemDictionaryShared.cpp line 765: > 763: // true: is_reference_assignable_from() should SKIP the assignability check > 764: // false: is_reference_assignable_from() should COMPLETE the assignability check > 765: void SystemDictionaryShared::add_verification_constraint(InstanceKlass* k, Symbol* name, Why did you change the type of the return variable? src/hotspot/share/classfile/verificationType.cpp line 111: > 109: #if INCLUDE_CDS > 110: if (CDSConfig::is_dumping_archive()) { > 111: bool skip_assignability_check; I think you have to assign this to false in case add_verification_constraint() doesn't set the value, something you don't know at the call site. I guess the return value is worse than a return parameter because false seems to indicate that the call didn't add a verification constraint. But I think this should be initialized just in case. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25104#pullrequestreview-2823145545 PR Review Comment: https://git.openjdk.org/jdk/pull/25104#discussion_r2078453540 PR Review Comment: https://git.openjdk.org/jdk/pull/25104#discussion_r2078457873 From asmehra at openjdk.org Wed May 7 21:52:59 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 7 May 2025 21:52:59 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <9EQGY48c-yRgmnLAPd3wXy1JsQ7xbiyzFXlHZHSuEqY=.94aba91d-a006-4832-967d-fb90da38ce6f@github.com> On Wed, 7 May 2025 19:35:34 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - Fix win64 compile failures >> >> Signed-off-by: Ashutosh Mehra >> - Fix AOTCodeFlags.java test >> >> Signed-off-by: Ashutosh Mehra >> - Fix compile failure in minimal config >> >> Signed-off-by: Ashutosh Mehra >> - Revert back changes that added AOTRuntimeConstants. >> Ensure CompressedOops::base and CompressedKlssPointers::base does not >> change in production run >> >> Signed-off-by: Ashutosh Mehra >> - Fix merge conflicts >> >> Signed-off-by: Ashutosh Mehra >> - Store/load AsmRemarks and DbgStrings in aot code cache >> >> Signed-off-by: Ashutosh Mehra >> - Add missing external address in aarch64 >> >> Signed-off-by: Ashutosh Mehra >> - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab > > I think it is fine not use AOT code when the heap base does not match. Based on my test it will happen only with big heap's size difference between assembly and production runs. @vnkozlov I wonder if that assert needs modification as well. This assert assumes that if `CompressedOops::_base` is not null, then it will be set to a page size before the heap range start. This is fine because _base is not null only when heap range goes beyond `OopEncodingHeapMax`, and in such cases `ReservedHeapSpace::noaccess_prefix` is equal to `os::vm_page_size()`. But with `UseCompatibleCompressedOops` the _base is set to non-null value even when heap range is within `OopEncodingHeapMax` and in such cases `ReservedHeapSpace::noaccess_prefix` is 0. I think the assert should be using `noaccess_prefix` instead of hard-coding `os::vm_page_size`: - assert((intptr_t)base() <= ((intptr_t)_heap_address_range.start() - (intptr_t)os::vm_page_size()) || + assert((intptr_t)base() <= ((intptr_t)_heap_address_range.start() - (intptr_t)heap_space.noaccess_prefix()) || With this change I can run the helloworld program with `UseCompatibleCompressedOops` enabled. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860472892 From iklam at openjdk.org Wed May 7 21:55:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 21:55:09 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: References: Message-ID: > Please see [JDK-8356407](https://bugs.openjdk.org/browse/JDK-8356407) for a detailed description of the problem. > > This fix strictly tightens the handling of class verification during CDS dump -- now the `VerificationType::is_reference_assignable_from()` checks are skipped only when dumping the "classic static archive". > > In the AOT training run, CDS is configured to dump a "preimage static archive". I.e., > > - `CDSConfig::is_dumping_classic_static_archive()` == false > - `CDSConfig::is_dumping_preimage_static_archive()` == true > > Therefore, the skipping no longer happens. > > I added a test case and improve the comments in the C++ code. > > (This bug is caused by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), which is new in JDK 25. So it does not affect JDK 24 or earlier releases). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @coleenp comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25104/files - new: https://git.openjdk.org/jdk/pull/25104/files/bdfed0d5..5c795980 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25104&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25104&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25104/head:pull/25104 PR: https://git.openjdk.org/jdk/pull/25104 From matsaave at openjdk.org Wed May 7 21:55:09 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 7 May 2025 21:55:09 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 21:52:35 GMT, Ioi Lam wrote: >> Please see [JDK-8356407](https://bugs.openjdk.org/browse/JDK-8356407) for a detailed description of the problem. >> >> This fix strictly tightens the handling of class verification during CDS dump -- now the `VerificationType::is_reference_assignable_from()` checks are skipped only when dumping the "classic static archive". >> >> In the AOT training run, CDS is configured to dump a "preimage static archive". I.e., >> >> - `CDSConfig::is_dumping_classic_static_archive()` == false >> - `CDSConfig::is_dumping_preimage_static_archive()` == true >> >> Therefore, the skipping no longer happens. >> >> I added a test case and improve the comments in the C++ code. >> >> (This bug is caused by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), which is new in JDK 25. So it does not affect JDK 24 or earlier releases). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @coleenp comments After reading the other comments I understand your reasoning. Looks good! ------------- Marked as reviewed by matsaave (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25104#pullrequestreview-2823292674 From matsaave at openjdk.org Wed May 7 21:55:09 2025 From: matsaave at openjdk.org (Matias Saavedra Silva) Date: Wed, 7 May 2025 21:55:09 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> References: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> Message-ID: <6R1uimYKEwqCunKynqpTZ2zFbypKEkMgqFz-Z9TidnU=.dd676bc1-0c9e-48d1-bd6e-03aba8dc0140@github.com> On Wed, 7 May 2025 20:35:56 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > src/hotspot/share/classfile/systemDictionaryShared.cpp line 765: > >> 763: // true: is_reference_assignable_from() should SKIP the assignability check >> 764: // false: is_reference_assignable_from() should COMPLETE the assignability check >> 765: void SystemDictionaryShared::add_verification_constraint(InstanceKlass* k, Symbol* name, > > Why did you change the type of the return variable? I second this, why can't you return skip_assignability_check here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25104#discussion_r2078538209 From iklam at openjdk.org Wed May 7 21:55:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 21:55:09 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: <6R1uimYKEwqCunKynqpTZ2zFbypKEkMgqFz-Z9TidnU=.dd676bc1-0c9e-48d1-bd6e-03aba8dc0140@github.com> References: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> <6R1uimYKEwqCunKynqpTZ2zFbypKEkMgqFz-Z9TidnU=.dd676bc1-0c9e-48d1-bd6e-03aba8dc0140@github.com> Message-ID: <8qxOyeWL9VCqUk4glWhkcjPVqxzCGi36qr6Ywxo3xrk=.8f2df50a-8077-4f8e-b691-679c95151ded@github.com> On Wed, 7 May 2025 21:44:42 GMT, Matias Saavedra Silva wrote: >> src/hotspot/share/classfile/systemDictionaryShared.cpp line 765: >> >>> 763: // true: is_reference_assignable_from() should SKIP the assignability check >>> 764: // false: is_reference_assignable_from() should COMPLETE the assignability check >>> 765: void SystemDictionaryShared::add_verification_constraint(InstanceKlass* k, Symbol* name, >> >> Why did you change the type of the return variable? > > I second this, why can't you return skip_assignability_check here? I changed the code because a `bool` return, without spelling out what it actually means, is hard to understand, especially on the side of the caller. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25104#discussion_r2078543074 From iklam at openjdk.org Wed May 7 21:55:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 7 May 2025 21:55:09 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> References: <8-XnGKEJmM37imzpMOy0R5_lQgdNhxxF6dsrK-PUUyc=.e9267e9b-bbcb-472f-9dc5-111766844f4b@github.com> Message-ID: On Wed, 7 May 2025 20:38:50 GMT, Coleen Phillimore wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > src/hotspot/share/classfile/verificationType.cpp line 111: > >> 109: #if INCLUDE_CDS >> 110: if (CDSConfig::is_dumping_archive()) { >> 111: bool skip_assignability_check; > > I think you have to assign this to false in case add_verification_constraint() doesn't set the value, something you don't know at the call site. I guess the return value is worse than a return parameter because false seems to indicate that the call didn't add a verification constraint. But I think this should be initialized just in case. I added the assignment as you suggested. The reason I used a separate variable is to make the code and the comment easier to understand. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25104#discussion_r2078539580 From kvn at openjdk.org Wed May 7 22:32:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 22:32:54 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab I also hit failure in `premain` testing in runtime/cds/appcds/leyden/LeydenHello.java#aot test on Windows-x64 due to wrong Compress Class encoding due to different base: [0.031s][info][cds] The current max heap size = 1024M, G1HeapRegion::GrainBytes = 1048576 [0.031s][info][cds] narrow_klass_base = 0x0000015298000000, arrow_klass_pointer_bits = 32, narrow_klass_shift = 0 AOT code uses 0x800000000 instead : 88: 8b 78 08 mov edi,DWORD PTR [rax+0x8] 8b: 49 ba 00 00 00 00 08 movabs r10,0x800000000 92: 00 00 00 95: 49 03 fa add rdi,r10 98: 48 3b 5f 38 cmp rbx,QWORD PTR [rdi+0x38] So we need the relocation fix from current changes in `premain` branch too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860595058 From kvn at openjdk.org Wed May 7 22:43:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 22:43:53 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: <9EQGY48c-yRgmnLAPd3wXy1JsQ7xbiyzFXlHZHSuEqY=.94aba91d-a006-4832-967d-fb90da38ce6f@github.com> References: <9EQGY48c-yRgmnLAPd3wXy1JsQ7xbiyzFXlHZHSuEqY=.94aba91d-a006-4832-967d-fb90da38ce6f@github.com> Message-ID: On Wed, 7 May 2025 21:50:04 GMT, Ashutosh Mehra wrote: > With this change I can run the helloworld program with UseCompatibleCompressedOops enabled. I will try your assert fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860612123 From kvn at openjdk.org Wed May 7 23:15:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 7 May 2025 23:15:54 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Several AOT tests failed on linux-x64 with flag enabled: $ make test CONF=fast TEST=test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking TEST_OPTS_JAVA_OPTIONS="-Xmixed -XX:+UseCompatibleCompressedOops" ... TEST TOTAL PASS FAIL ERROR SKIP jtreg:open/test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking >> 15 5 8 0 2 I moved `UseCompatibleCompressedOops` flag setting to `check_vm_args_consistency()` to affect current workflow. And I used `if (AOTCodeCache::is_caching_enabled()) {` for its setting. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860658834 PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860664022 From kvn at openjdk.org Thu May 8 00:18:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 8 May 2025 00:18:55 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab I think for these changes we should not use AOT code when the heap base does not match. Something changed in compressed oops code which prevents enforcing encoding. We can investigate and fix it later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2860897941 From ccheung at openjdk.org Thu May 8 00:28:07 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 May 2025 00:28:07 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking Message-ID: This fix adds the `--add-reads` support for CDS and AOTClassLinking. Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` During runtime, the archived full module graph will be disabled: `[0.021s][info][cds ] full module graph: disabled` With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. Testing: tiers 1 - 4. ------------- Commit messages: - fix trailing whitespace - 8354083: Support --add-reads with -XX:+AOTClassLinking Changes: https://git.openjdk.org/jdk/pull/25109/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8354083 Stats: 111 lines in 4 files changed: 81 ins; 14 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109 PR: https://git.openjdk.org/jdk/pull/25109 From john.r.rose at oracle.com Thu May 8 00:31:28 2025 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 May 2025 17:31:28 -0700 Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <3C8B5BF7-0024-44A9-8198-F2AF30F1C5BB@oracle.com> On 7 May 2025, at 12:37, Vladimir Kozlov wrote: > I think it is fine not use AOT code when the heap base does not match. Based on my test it will happen only with big heap's size difference between assembly and production runs. Won?t ASLR spoil matches on some platforms? The match must depend on how the VM negotiates memory segments with the OS. If the OS is committed to random segment assignment, then routine mismatch is something we should be prepared to address, as the issue comes up. (I?m not saying we need to address it now, if tests seem to behave properly. But I suspect even now there are some platforms that will throw a monkey wrench at us.) ASLR: https://en.wikipedia.org/wiki/Address_space_layout_randomization From iklam at openjdk.org Thu May 8 01:11:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 01:11:07 GMT Subject: RFR: 8356407: Part of class verification is skipped in AOT training run [v2] In-Reply-To: References: Message-ID: <9WhC5UHEyMwGzrclczftKzanu-emw326h2B5TpfSUHA=.e6f04c82-9736-4609-bee1-8f51153c360b@github.com> On Wed, 7 May 2025 21:51:48 GMT, Matias Saavedra Silva wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> @coleenp comments > > After reading the other comments I understand your reasoning. Looks good! Thanks @matias9927 @coleenp for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25104#issuecomment-2861091276 From iklam at openjdk.org Thu May 8 01:11:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 01:11:07 GMT Subject: Integrated: 8356407: Part of class verification is skipped in AOT training run In-Reply-To: References: Message-ID: On Wed, 7 May 2025 17:29:25 GMT, Ioi Lam wrote: > Please see [JDK-8356407](https://bugs.openjdk.org/browse/JDK-8356407) for a detailed description of the problem. > > This fix strictly tightens the handling of class verification during CDS dump -- now the `VerificationType::is_reference_assignable_from()` checks are skipped only when dumping the "classic static archive". > > In the AOT training run, CDS is configured to dump a "preimage static archive". I.e., > > - `CDSConfig::is_dumping_classic_static_archive()` == false > - `CDSConfig::is_dumping_preimage_static_archive()` == true > > Therefore, the skipping no longer happens. > > I added a test case and improve the comments in the C++ code. > > (This bug is caused by [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), which is new in JDK 25. So it does not affect JDK 24 or earlier releases). This pull request has now been integrated. Changeset: 3e258cbd Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/3e258cbddf335a6b4f4307e5a1304fe2664c80a0 Stats: 120 lines in 5 files changed: 93 ins; 7 del; 20 mod 8356407: Part of class verification is skipped in AOT training run Co-authored-by: Vladimir Ivanov Reviewed-by: matsaave, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/25104 From kvn at openjdk.org Thu May 8 01:19:06 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 8 May 2025 01:19:06 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab @rose00 We have solution for that: we enforce encoding instructions (UseCompatibleCompressedOops flag) and use relocation info to patch correct COOP base address when loading AOT code. The current issue is something changed in COOP code in runtime which cause next assert hit when we enforce encoding and use AOT code: [instanceKlass.cpp#L794](https://github.com/openjdk/leyden/blob/premain/src/hotspot/share/oops/instanceKlass.cpp#L794) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2861107654 From kvn at openjdk.org Thu May 8 01:24:59 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 8 May 2025 01:24:59 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v3] In-Reply-To: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> References: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> Message-ID: On Wed, 7 May 2025 18:13:41 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam 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 14 additional commits since the last revision: > > - cds+aot+load -> aot+load > - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds > - @jdksjolen comment > - Fixed comment > - clean up of existing UL logs for cds > - Fixed test cases > - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds > - Much more simplification > - Much simplified > - More tightening .... but this may be the wrong approach > - ... and 4 more: https://git.openjdk.org/jdk/compare/1bfc597d...b772b3d4 I found typo UL ouput in filemap.cpp: [arrow_klass_pointer_bits](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/cds/filemap.cpp#L1513) ------------- Changes requested by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24895#pullrequestreview-2823587951 From asmehra at openjdk.org Thu May 8 01:36:52 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 8 May 2025 01:36:52 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: <8W_FRkLbamdZ6l0Lkbn8WqXv_JXPjG-i5hBus2foor4=.4f80cd55-4141-46ff-8436-0cbbc9228461@github.com> On Thu, 8 May 2025 00:15:46 GMT, Vladimir Kozlov wrote: > I think for these changes we should not use AOT code when the heap base does not match. Something changed in compressed oops code which prevents enforcing encoding. We can investigate and fix it later. @vnkozlov for this PR we are relying on having relocation for COOP base, not on enforcing encoding. And that should be able to handle cases where heap base is different in assembly vs prod. Why do you suggest to not use AOT code when the heap base does not match? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2861154733 From dholmes at openjdk.org Thu May 8 01:37:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 01:37:54 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v3] In-Reply-To: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> References: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> Message-ID: On Wed, 7 May 2025 18:13:41 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam 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 14 additional commits since the last revision: > > - cds+aot+load -> aot+load > - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds > - @jdksjolen comment > - Fixed comment > - clean up of existing UL logs for cds > - Fixed test cases > - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds > - Much more simplification > - Much simplified > - More tightening .... but this may be the wrong approach > - ... and 4 more: https://git.openjdk.org/jdk/compare/15d8a3ec...b772b3d4 This PR seems to be combining a few things: - establishing the "aliasing" mechanism - changing some logging statements from CDS to AOT (which already has its own JBS issue IIRC) - adding new configuration error checking It may be cleaner to keep these distinct. I'm also wondering whether we can have a more direct, and general-purpose, aliasing mechanism, that simply connects two tags as aliases such that enabling one enables the other and changes it's printed name? That would be less intrusive than putting this AOT specific logic (which is still an experiment/preview feature isn't it?) into the UL code. src/hotspot/share/logging/logSelection.cpp line 190: > 188: if (PrintCDSLogsAsAOTLogs && _ntags > 0 && _tags[0] == LogTag::_aot && ts.tag(0) == LogTag::_cds) { > 189: // Consider it a match > 190: i ++; Suggestion: i++; ------------- PR Review: https://git.openjdk.org/jdk/pull/24895#pullrequestreview-2823584480 PR Review Comment: https://git.openjdk.org/jdk/pull/24895#discussion_r2078740159 From kvn at openjdk.org Thu May 8 02:17:00 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 8 May 2025 02:17:00 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab To support that you would need to modify x86_64.ad to exclude r12 from usage as 0 as we discussed. I think that using your original changes to not use AOT code with mismatched coop base is simpler for these changes and more robust for mainline. I concern that we may missing some places which will cause issues later. And we near JDK 25 fork. We can do more changes/improvements later in JDK 26. One suggestion I have is to skip using only new runtime blobs you are adding when bases do not match because adapters don't have this issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2861272270 From iklam at openjdk.org Thu May 8 02:47:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 02:47:07 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v4] In-Reply-To: References: Message-ID: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - @vnkozlov and @dholmes-ora comments - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - cds+aot+load -> aot+load - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - @jdksjolen comment - Fixed comment - clean up of existing UL logs for cds - Fixed test cases - Merge branch 'master' into 8355638-xlog-aot-as-alias-for-xlog-cds - Much more simplification - ... and 6 more: https://git.openjdk.org/jdk/compare/3e258cbd...38dbe7eb ------------- Changes: https://git.openjdk.org/jdk/pull/24895/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=03 Stats: 191 lines in 13 files changed: 163 ins; 0 del; 28 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Thu May 8 02:54:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 02:54:38 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v5] In-Reply-To: References: Message-ID: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Reverted unrelated changes in filemap.cpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24895/files - new: https://git.openjdk.org/jdk/pull/24895/files/38dbe7eb..031cbef1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=03-04 Stats: 9 lines in 1 file changed: 0 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Thu May 8 02:59:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 02:59:35 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v6] In-Reply-To: References: Message-ID: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Removed checks for error message that got removed from the PR ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24895/files - new: https://git.openjdk.org/jdk/pull/24895/files/031cbef1..82e55187 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24895&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24895.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24895/head:pull/24895 PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Thu May 8 03:01:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 03:01:51 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v3] In-Reply-To: References: <6nVhY-lg25piZC9WoZn4t330tcjLdU3W9xolacYE860=.96c8ed40-779e-4164-a57b-7b95f481968b@github.com> Message-ID: <8J1x7YQXgtuI1zKNAZbdZADwXbPsvnW_MpO4t3Doj2U=.7efa6cd1-9d84-4e5c-bac7-b09a3b3f80d5@github.com> On Thu, 8 May 2025 01:34:51 GMT, David Holmes wrote: > This PR seems to be combining a few things: > > * establishing the "aliasing" mechanism > * changing some logging statements from CDS to AOT (which already has its own JBS issue IIRC) The logs that are changed are of the pattern `cds+aot+link`. UL cannot accept `aot+aot+link`: $ java -Xlog:aot+aot --version [0.000s][error][logging] Log selection contains duplicates of tag aot. Invalid -Xlog option '-Xlog:aot+aot', see error log for details. Therefore, these logs must be changed, or else they cannot be accessed using the `-Xlog:aot` alias. I didn't change any other cds logs. > * adding new configuration error checking Do you mean the changes in filemap.cpp? I've reverted them. > It may be cleaner to keep these distinct. > > I'm also wondering whether we can have a more direct, and general-purpose, aliasing mechanism, that simply connects two tags as aliases such that enabling one enables the other and changes it's printed name? That would be less intrusive than putting this AOT specific logic (which is still an experiment/preview feature isn't it?) into the UL code. I am not sure if we want a general-purpose, aliasing mechanism. I think it will just be confusing for both HotSpot developers and users. I see this exercise as a one off -- a long time feature that gets a new name. Once the -Xlog:cds logs are all removed, this aliasing mechanism (a dozen or so lines of code) will be completely removed. AOT is not an experiment/preview feature. It's a product feature in JEP 483 which was introduced in JDK 24. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24895#issuecomment-2861468570 From iklam at openjdk.org Thu May 8 03:24:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 03:24:50 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung wrote: > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java) I think we need a similar test for `--add-opens` as well. Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to - runtime/cds/appcds/aotClassLinking/modules/AddExports.java And then add AddReads.java and AddOpens.java there as well. The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2861575003 From ccheung at openjdk.org Thu May 8 05:10:29 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 May 2025 05:10:29 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking Message-ID: The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. Increasing the timeout value from 500 to 800 seems to have addressed the issue. With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. ------------- Commit messages: - 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking Changes: https://git.openjdk.org/jdk/pull/25111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356212 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25111/head:pull/25111 PR: https://git.openjdk.org/jdk/pull/25111 From dholmes at openjdk.org Thu May 8 06:45:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 06:45:55 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v7] In-Reply-To: <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com> References: <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com> Message-ID: On Wed, 23 Apr 2025 08:46:00 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform Re-running through our testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/23536#issuecomment-2861952490 From dholmes at openjdk.org Thu May 8 07:23:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 07:23:56 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> References: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> Message-ID: <4cQadUYQeg36rEjqKfduZaH4KUpdubDImEV6CTERNhU=.80094823-0a68-44f9-af9f-60a56a0fbdc3@github.com> On Tue, 6 May 2025 22:52:59 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries Sorry for the delay but I have been on vacation (and noone else picked this up). Seems okay in principle but a couple of small issues below. Thanks src/hotspot/os/bsd/os_bsd.cpp line 647: > 645: pthread_t tid; > 646: int ret = 0; > 647: { Why the extra block scope? src/hotspot/os/bsd/os_bsd.cpp line 661: > 659: } > 660: > 661: log_warning(os, thread)("Failed to start native thread (%s), retrying after %dus.", os::errno_name(ret), next_delay); I don't think we want to issue a warning unless we completely fail to start the native thread. For debugging purposes this may be better as a log_debug, ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24682#pullrequestreview-2824072686 PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2079056634 PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2079059986 From dholmes at openjdk.org Thu May 8 07:35:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 07:35:53 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 In-Reply-To: References: Message-ID: On Wed, 7 May 2025 13:03:42 GMT, Casper Norrbin wrote: > Hi, > > There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. Looks good to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25093#pullrequestreview-2824112726 From adinn at openjdk.org Thu May 8 08:11:54 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 8 May 2025 08:11:54 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 02:14:41 GMT, Vladimir Kozlov wrote: > One suggestion I have is to skip using only new runtime blobs you are adding when bases do not match because adapters don't have this issue. c2i adapters do suffer this issue. They call out to the barrier set to plant a c2i entry barrier. The barrier performs a weak reference load through field `ClassLoaderData::holder` (type `WeakHandle`). Method `resolve_weak_handle` calls `decode_heap_oop`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2862157506 From sgehwolf at openjdk.org Thu May 8 08:31:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 8 May 2025 08:31:51 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 In-Reply-To: References: Message-ID: On Wed, 7 May 2025 13:03:42 GMT, Casper Norrbin wrote: > Hi, > > There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25093#pullrequestreview-2824259755 From syan at openjdk.org Thu May 8 09:54:51 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 8 May 2025 09:54:51 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 05:06:01 GMT, Calvin Cheung wrote: > The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. > Increasing the timeout value from 500 to 800 seems to have addressed the issue. > With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. Marked as reviewed by syan (Committer). test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 37: > 35: /* > 36: * @test > 37: * @summary Try to archive lots and lots of classes. The copyright header "Copyright Amazon.com Inc" miss the year message. ------------- PR Review: https://git.openjdk.org/jdk/pull/25111#pullrequestreview-2824435947 PR Review Comment: https://git.openjdk.org/jdk/pull/25111#discussion_r2079285510 From syan at openjdk.org Thu May 8 10:08:52 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 8 May 2025 10:08:52 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 In-Reply-To: References: Message-ID: <08Hc0qV-N6MofjxEuSWshC9_MFGEHUzqpe0naUpHQuw=.3edd7792-0109-4d05-a88d-03d9ee61f812@github.com> On Wed, 7 May 2025 13:03:42 GMT, Casper Norrbin wrote: > Hi, > > There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. Maybe we should update the copyright year. ------------- Changes requested by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25093#pullrequestreview-2824597704 From dholmes at openjdk.org Thu May 8 10:37:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 10:37:58 GMT Subject: RFR: 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform [v7] In-Reply-To: <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com> References: <20TRpLYXGNXfc4ppAfGQysrYBJWBwV4iK4tPTk8MiTM=.08e71de3-4b53-4735-9742-9e87ef05bfa4@github.com> Message-ID: On Wed, 23 Apr 2025 08:46:00 GMT, Kazuhisa Takakuri wrote: >> To resolve runtime/os/windows/TestAvailableProcessors.java failure, I made "systeminfo.exe" executed with "chcp 437". This ensures that the English message "OS Version: " is output on localized windows platforms. >> I added the path C:\Windows\System32 to make chcp command recognized on the GHA Windows test machine. Without this addition, GHA will fail. >> After this fix, I verified that the test passed. >> >> https://github.com/openjdk/jdk/pull/22142 >> I refer to this fix. >> tools/jpackage/windows/Win8301247Test.java does not run in GHA, so the problems with recognition of chcp command did not occur before. >> >> Thanks. > > Kazuhisa Takakuri has updated the pull request incrementally with one additional commit since the last revision: > > 8349288: runtime/os/windows/TestAvailableProcessors.java fails on localized Windows platform test/hotspot/jtreg/runtime/os/windows/TestAvailableProcessors.java line 72: > 70: System.getenv("WINDIR") != null ? new File(System.getenv ("WINDIR")) : > 71: null; > 72: String systemDirW = new File(systemRoot, "System32").getPath(); If `SystemRoot` is null this will just throw `NullPointerException`. You should check for null and throw a more meaningful exception ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23536#discussion_r2079458307 From cnorrbin at openjdk.org Thu May 8 11:47:33 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 11:47:33 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 [v2] In-Reply-To: References: Message-ID: > Hi, > > There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: fixed copyright header ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25093/files - new: https://git.openjdk.org/jdk/pull/25093/files/a5180f6d..c38ac300 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25093&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25093&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25093.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25093/head:pull/25093 PR: https://git.openjdk.org/jdk/pull/25093 From jsjolen at openjdk.org Thu May 8 11:50:51 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 May 2025 11:50:51 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:47:33 GMT, Casper Norrbin wrote: >> Hi, >> >> There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright header Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25093#pullrequestreview-2824868497 From kbarrett at openjdk.org Thu May 8 12:14:51 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Thu, 8 May 2025 12:14:51 GMT Subject: RFR: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro In-Reply-To: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> References: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> Message-ID: On Wed, 7 May 2025 14:48:50 GMT, Matthias Baesken wrote: > The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. > See the discussion here > https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25099#pullrequestreview-2824927963 From azafari at openjdk.org Thu May 8 12:15:40 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 8 May 2025 12:15:40 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v22] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: semantic text added. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/e5375140..f5b14988 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=20-21 Stats: 53 lines in 1 file changed: 53 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From cnorrbin at openjdk.org Thu May 8 12:21:08 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 12:21:08 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong [v3] In-Reply-To: References: Message-ID: > There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: > - The range contains no nodes, **but** > - Nodes exist **outside** that range. > > The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. > > To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. > > Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: changed key_leq to assert_key_leq ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24658/files - new: https://git.openjdk.org/jdk/pull/24658/files/3748e564..f29fa727 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24658&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24658&range=01-02 Stats: 7 lines in 2 files changed: 1 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24658.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24658/head:pull/24658 PR: https://git.openjdk.org/jdk/pull/24658 From jsjolen at openjdk.org Thu May 8 12:39:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 8 May 2025 12:39:03 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:21:08 GMT, Casper Norrbin wrote: >> There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: >> - The range contains no nodes, **but** >> - Nodes exist **outside** that range. >> >> The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. >> >> To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. >> >> Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed key_leq to assert_key_leq Marked as reviewed by jsjolen (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24658#pullrequestreview-2824978970 From aboldtch at openjdk.org Thu May 8 12:39:04 2025 From: aboldtch at openjdk.org (Axel Boldt-Christmas) Date: Thu, 8 May 2025 12:39:04 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:21:08 GMT, Casper Norrbin wrote: >> There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: >> - The range contains no nodes, **but** >> - Nodes exist **outside** that range. >> >> The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. >> >> To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. >> >> Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed key_leq to assert_key_leq lgtm ------------- Marked as reviewed by aboldtch (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24658#pullrequestreview-2824986190 From cnorrbin at openjdk.org Thu May 8 13:06:04 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 13:06:04 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong [v3] In-Reply-To: References: Message-ID: <0YgfmpMLI81w9L6KzAJ_czQkXqBUvFJeLejINncDlP0=.769817ba-10cf-491c-89e2-c7c19cca5fd0@github.com> On Thu, 8 May 2025 12:21:08 GMT, Casper Norrbin wrote: >> There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: >> - The range contains no nodes, **but** >> - Nodes exist **outside** that range. >> >> The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. >> >> To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. >> >> Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed key_leq to assert_key_leq Thank you for reviewing! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24658#issuecomment-2862971920 From duke at openjdk.org Thu May 8 13:06:04 2025 From: duke at openjdk.org (duke) Date: Thu, 8 May 2025 13:06:04 GMT Subject: RFR: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong [v3] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:21:08 GMT, Casper Norrbin wrote: >> There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: >> - The range contains no nodes, **but** >> - Nodes exist **outside** that range. >> >> The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. >> >> To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. >> >> Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > changed key_leq to assert_key_leq @caspernorrbin Your change (at version f29fa7277932aa44106a4514c28295481049c3b4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24658#issuecomment-2862976528 From sgehwolf at openjdk.org Thu May 8 13:17:54 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 8 May 2025 13:17:54 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:47:33 GMT, Casper Norrbin wrote: >> Hi, >> >> There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright header Marked as reviewed by sgehwolf (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25093#pullrequestreview-2825103623 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 cnorrbin at openjdk.org Thu May 8 13:46:56 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 13:46:56 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 [v2] In-Reply-To: References: Message-ID: <7BsdJ8csyiMLwAuyhwmrxZIyYiIQTrXh2jiHK3iEPL8=.8a1d73ae-759d-4d98-b827-75a49ff5290c@github.com> On Thu, 8 May 2025 11:47:33 GMT, Casper Norrbin wrote: >> Hi, >> >> There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright header Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25093#issuecomment-2863122667 From duke at openjdk.org Thu May 8 13:46:57 2025 From: duke at openjdk.org (duke) Date: Thu, 8 May 2025 13:46:57 GMT Subject: RFR: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 11:47:33 GMT, Casper Norrbin wrote: >> Hi, >> >> There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > fixed copyright header @caspernorrbin Your change (at version c38ac30027dd5ce9ada789efd45d55e087fe5a49) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25093#issuecomment-2863126845 From shade at openjdk.org Thu May 8 14:28:56 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 May 2025 14:28:56 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 09:27:06 GMT, SendaoYan wrote: >> The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. >> Increasing the timeout value from 500 to 800 seems to have addressed the issue. >> With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. > > test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java line 37: > >> 35: /* >> 36: * @test >> 37: * @summary Try to archive lots and lots of classes. > > The copyright header "Copyright Amazon.com Inc" miss the year message. This is as designed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25111#discussion_r2079832709 From shade at openjdk.org Thu May 8 14:34:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 May 2025 14:34:50 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: <4ska2SfORLmbIP-LkZbbVKdu47cbC43JBhTXSYvmlrI=.29339da7-c283-4d59-a7c5-b7816b5c7c21@github.com> On Thu, 8 May 2025 05:06:01 GMT, Calvin Cheung wrote: > The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. > Increasing the timeout value from 500 to 800 seems to have addressed the issue. > With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. When I wrote this test, `Step 3` was really an optional step that takes most of the time. That step effectively does class load for 100K classes. We can increase timeout for the test, but we can also optimize that part a bit, or disable the loading step altogether. I have not tested with `-XX:+AOTClassLinking`, maybe there are simple bottlenecks somewhere, let me quickly take a look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25111#issuecomment-2863280947 From shade at openjdk.org Thu May 8 15:41:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 8 May 2025 15:41:51 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 05:06:01 GMT, Calvin Cheung wrote: > The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. > Increasing the timeout value from 500 to 800 seems to have addressed the issue. > With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. Quick profiling shows we spend _a lot_ of time in class inits and SystemDictionary verification. Some of this can be alleviated by skipping the verification. Also, a different route: the test is a regression test for JDK-8342283. That bug is about backing storage in `Map`, `List` exceeding CDS archival limit (256KB). So nominally, we want 256KB / 4 bytes = 64K classes in this test. So I propose in addition to bumping the timeout, we also optimize the test like this: diff --git a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java index 96d2dc0d6ee..6267c6bdf33 100644 --- a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java +++ b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java @@ -42,9 +42,12 @@ public class LotsOfSyntheticClasses { - // Generate 100 top-level classes, each containing 1000 nested classes. - // 100K total classes are more than enough to push the CDS limits. - private static final int NUM_CLASSES = 100; + // Generate 70 top-level classes, each containing 1000 nested classes. + // 70K total classes is enough to push the CDS limits. Any archived + // collection that holds Classes should not have backing storage larger + // than CDS archival limit (256KB). This means we want at least 64K classes + // to probe that limit. + private static final int NUM_CLASSES = 70; private static final int NUM_NESTED_CLASSES = 1000; private static final Path USER_DIR = Paths.get(CDSTestUtils.getOutputDir()); @@ -117,7 +120,11 @@ public static void main(String[] args) throws Exception { OutputAnalyzer output = TestCommon.createArchive( APP_JAR.toString(), listAppClasses(), - MAIN_CLASS_NAME + MAIN_CLASS_NAME, + // Verification for lots of classes slows down the test. + "-XX:+IgnoreUnrecognizedVMOptions", + "-XX:-VerifyDependencies", + "-XX:-VerifyBeforeExit" ); TestCommon.checkDump(output); } @@ -125,9 +132,10 @@ public static void main(String[] args) throws Exception { // Step 3. Try to run, touching every class. { TestCommon.run( - // Verifying dependencies for lots of classes slows down the test. - "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-VerifyDependencies", - "-Xlog:cds", + // Verification for lots of classes slows down the test. + "-XX:+IgnoreUnrecognizedVMOptions", + "-XX:-VerifyDependencies", + "-XX:-VerifyBeforeExit", "-cp", APP_JAR.toString(), MAIN_CLASS_NAME). assertNormalExit("Success"); This cuts the test time about 4x on my macos-aarch64-debug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25111#issuecomment-2863504243 From stefank at openjdk.org Thu May 8 16:17:54 2025 From: stefank at openjdk.org (Stefan Karlsson) Date: Thu, 8 May 2025 16:17:54 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 02:59:35 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed checks for error message that got removed from the PR This seems like a hack in the UL system. Did you consider confining this in the CDS / AOT code instead? Something like this pseudo code: bool aot_log_is_enabled(Level, ...) { return log_is_enabled(Level, aot, link) || log_is_enabled(Level, cds, link); } void aot_log_info(...) {} ... if (aot_log_is_enabled(Info, link) { ResourceMark rm; aot_log_info(link)("%s %s %p", class_category_name(ik), ik->external_name(), ik); } ------------- PR Comment: https://git.openjdk.org/jdk/pull/24895#issuecomment-2863605568 From cnorrbin at openjdk.org Thu May 8 16:23:58 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 16:23:58 GMT Subject: Integrated: 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 In-Reply-To: References: Message-ID: On Wed, 7 May 2025 13:03:42 GMT, Casper Norrbin wrote: > Hi, > > There's a file descriptor in `cgroupSubsystem_linux.cpp` that isn't closed if we successfully open it but can't read from it. In that case, the open descriptor should still be closed before returning. This pull request has now been integrated. Changeset: 7f3191a6 Author: Casper Norrbin Committer: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/7f3191a630edba32ddb7bb64a835ec663d91ed92 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8354878: File Leak in CgroupSubsystemFactory::determine_type of cgroupSubsystem_linux.cpp:300 Reviewed-by: sgehwolf, jsjolen, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25093 From cnorrbin at openjdk.org Thu May 8 16:23:59 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 8 May 2025 16:23:59 GMT Subject: Integrated: 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong In-Reply-To: References: Message-ID: On Tue, 15 Apr 2025 12:03:39 GMT, Casper Norrbin wrote: > There was an assert in `AbstractRBTree::visit_range_in_order` that could incorrectly trigger when: > - The range contains no nodes, **but** > - Nodes exist **outside** that range. > > The assert checked `from <= to` indirectly via `from <= start <= to`, but `start` could be valid outside that range. > > To fix this, I added the ability to supply a direct key comparison for intrusive trees to the `COMPARATOR` template. This already existed in the non-intrusive RBTree, and works the same as the other extra `cmp` function. > > Additionally, I found another wrong assert in `replace_at_cursor` that is also fixed here. This pull request has now been integrated. Changeset: 1e8927dd Author: Casper Norrbin Committer: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/1e8927dded2d6d7049dc277564c77dff81ff1047 Stats: 77 lines in 3 files changed: 36 ins; 19 del; 22 mod 8354433: Assert in AbstractRBTree::visit_range_in_order(const K& from, const K& to, F f) is wrong Reviewed-by: jsjolen, aboldtch ------------- PR: https://git.openjdk.org/jdk/pull/24658 From iklam at openjdk.org Thu May 8 18:30:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 8 May 2025 18:30:52 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 16:15:07 GMT, Stefan Karlsson wrote: > This seems like a hack in the UL system. Did you consider confining this in the CDS / AOT code instead? > > Something like this pseudo code: > > ``` > bool aot_log_is_enabled(Level, ...) { > return log_is_enabled(Level, aot, link) || > log_is_enabled(Level, cds, link); > } > void aot_log_info(...) {} > ... > if (aot_log_is_enabled(Info, link) { > ResourceMark rm; > aot_log_info(link)("%s %s %p", class_category_name(ik), ik->external_name(), ik); > } > ``` OK I'll try that. I think most `cds` logs are obscure and can be changed to `aot`. I'll implement a few macros for the style you suggested above, and use them on the "user facing" logs -- e.g, those that report errors for trouble shooting purposes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24895#issuecomment-2863912652 From azafari at openjdk.org Thu May 8 19:09:55 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 8 May 2025 19:09:55 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v23] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: test with random requests passes now. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/f5b14988..abf61321 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=21-22 Stats: 5 lines in 2 files changed: 0 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From lucy at openjdk.org Thu May 8 19:27:50 2025 From: lucy at openjdk.org (Lutz Schmidt) Date: Thu, 8 May 2025 19:27:50 GMT Subject: RFR: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro In-Reply-To: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> References: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> Message-ID: On Wed, 7 May 2025 14:48:50 GMT, Matthias Baesken wrote: > The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. > See the discussion here > https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html LGTM. Nice cleanup. ------------- Marked as reviewed by lucy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25099#pullrequestreview-2826163841 From ccheung at openjdk.org Thu May 8 19:54:33 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 May 2025 19:54:33 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: <3UsVIl152hUKeYobfTSQjB44pgz4pAbsdS9ONlevIPI=.7a166710-2c4a-4b3f-90b4-1a4117fe06f6@github.com> On Thu, 8 May 2025 15:39:03 GMT, Aleksey Shipilev wrote: > > This cuts the test time about 4x on my macos-aarch64-debug. Thanks! Your suggested change is good enough to avoid the timeout. I ran the test group 80 (2x40) times and didn't see a timeout. I've pushed a change with your suggestion and with the timeout value reverted. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25111#issuecomment-2864114460 From ccheung at openjdk.org Thu May 8 19:54:33 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 8 May 2025 19:54:33 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: > The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. > Increasing the timeout value from 500 to 800 seems to have addressed the issue. > With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: @shipilev comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25111/files - new: https://git.openjdk.org/jdk/pull/25111/files/65d369dc..2d372a5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25111&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25111&range=00-01 Stats: 16 lines in 1 file changed: 8 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/25111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25111/head:pull/25111 PR: https://git.openjdk.org/jdk/pull/25111 From liach at openjdk.org Thu May 8 20:11:08 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 8 May 2025 20:11:08 GMT Subject: RFR: 8356577: Migrate ClassFileVersionTest to be feature-agnostic Message-ID: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> In #24923 we noted that ClassFileVersionTest depends on arbitrary preview features to have javac mark itself as preview. This creates an extra, hard-to-detect dependency on those features, and make its maintenance costly. The best way to have a class that has preview bit is to use ClassFile API to generate such a simple class instead, now that ClassFile API is available. Testing: This test itself ------------- Commit messages: - 8356577: Migrate ClassFileVersionTest to be feature-agnostic Changes: https://git.openjdk.org/jdk/pull/25128/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25128&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356577 Stats: 19 lines in 1 file changed: 7 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25128.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25128/head:pull/25128 PR: https://git.openjdk.org/jdk/pull/25128 From duke at openjdk.org Thu May 8 21:42:08 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Thu, 8 May 2025 21:42:08 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v4] In-Reply-To: References: Message-ID: > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: Reduce interim thread start log level to debug ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24682/files - new: https://git.openjdk.org/jdk/pull/24682/files/14b2b82f..25b9718a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=02-03 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From duke at openjdk.org Thu May 8 21:42:11 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Thu, 8 May 2025 21:42:11 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> References: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> Message-ID: On Tue, 6 May 2025 22:52:59 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries > Sorry for the delay but I have been on vacation (and noone else picked this up). No worries, thanks a lot for getting back to me! ------------- PR Review: https://git.openjdk.org/jdk/pull/24682#pullrequestreview-2826419146 From duke at openjdk.org Thu May 8 21:42:11 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Thu, 8 May 2025 21:42:11 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: <4cQadUYQeg36rEjqKfduZaH4KUpdubDImEV6CTERNhU=.80094823-0a68-44f9-af9f-60a56a0fbdc3@github.com> References: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> <4cQadUYQeg36rEjqKfduZaH4KUpdubDImEV6CTERNhU=.80094823-0a68-44f9-af9f-60a56a0fbdc3@github.com> Message-ID: On Thu, 8 May 2025 07:17:42 GMT, David Holmes wrote: >> Yannik Stradmann 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 remote-tracking branch 'upstream/master' into robust_pthread >> - Fix build on Windows: Sleep() only accepts milliseconds >> - Exponentially delay native thread creation retries > > src/hotspot/os/bsd/os_bsd.cpp line 647: > >> 645: pthread_t tid; >> 646: int ret = 0; >> 647: { > > Why the extra block scope? I'm limiting the visibility of the "loop" variables `trials_remaining` and `next_delay` to the loop itself, preventing accidental use further down in the function. > src/hotspot/os/bsd/os_bsd.cpp line 661: > >> 659: } >> 660: >> 661: log_warning(os, thread)("Failed to start native thread (%s), retrying after %dus.", os::errno_name(ret), next_delay); > > I don't think we want to issue a warning unless we completely fail to start the native thread. For debugging purposes this may be better as a log_debug, ACK, fixed in all files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2080499542 PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2080500040 From dholmes at openjdk.org Thu May 8 22:21:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 22:21:52 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: References: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> <4cQadUYQeg36rEjqKfduZaH4KUpdubDImEV6CTERNhU=.80094823-0a68-44f9-af9f-60a56a0fbdc3@github.com> Message-ID: On Thu, 8 May 2025 21:33:58 GMT, Yannik Stradmann wrote: >> src/hotspot/os/bsd/os_bsd.cpp line 647: >> >>> 645: pthread_t tid; >>> 646: int ret = 0; >>> 647: { >> >> Why the extra block scope? > > I'm limiting the visibility of the "loop" variables `trials_remaining` and `next_delay` to the loop itself, preventing accidental use further down in the function. That really is not necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2080538558 From duke at openjdk.org Thu May 8 22:59:51 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Thu, 8 May 2025 22:59:51 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v5] In-Reply-To: References: Message-ID: > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: Remove restrictive scopes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24682/files - new: https://git.openjdk.org/jdk/pull/24682/files/25b9718a..fede12c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=03-04 Stats: 67 lines in 3 files changed: 12 ins; 18 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From duke at openjdk.org Thu May 8 22:59:52 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Thu, 8 May 2025 22:59:52 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v3] In-Reply-To: References: <7aBC6riuoHQmXKdSyGWQkJoA5DKICMr5PEA2CEqzquQ=.2551126c-a5f2-409a-a88b-76ed33b48e2c@github.com> <4cQadUYQeg36rEjqKfduZaH4KUpdubDImEV6CTERNhU=.80094823-0a68-44f9-af9f-60a56a0fbdc3@github.com> Message-ID: On Thu, 8 May 2025 22:19:12 GMT, David Holmes wrote: >> I'm limiting the visibility of the "loop" variables `trials_remaining` and `next_delay` to the loop itself, preventing accidental use further down in the function. > > That really is not necessary. Alright, I have removed the over-defensive scoping across all platforms. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2080594411 From dholmes at openjdk.org Thu May 8 23:04:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 8 May 2025 23:04:50 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v5] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 22:59:51 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: > > Remove restrictive scopes Thanks for updates. That seems fine to me. You still need a second reviewer for hotspot changes. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24682#pullrequestreview-2826563771 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 iklam at openjdk.org Fri May 9 02:47:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 02:47:55 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:54:33 GMT, Calvin Cheung wrote: >> The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. >> Increasing the timeout value from 500 to 800 seems to have addressed the issue. >> With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @shipilev comment Looks good to me. FYI, I tried the following patch to avoid initializing the inner classes, but it doesn't seem to be any faster. So the current patch is good enough. public static List generateClass(int idx) { List out = new ArrayList<>(); out.add("public class " + TOP_CLASS_NAME + idx + " {"); + out.add("Object f;"); out.add("public " + TOP_CLASS_NAME + idx + "() {"); for (int c = 0; c < NUM_NESTED_CLASSES; c++) { - out.add("new " + NESTED_CLASS_NAME + c + "();"); + out.add("f = " + NESTED_CLASS_NAME + c + ".class;"); } ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25111#pullrequestreview-2826841535 From iklam at openjdk.org Fri May 9 04:00:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 04:00:52 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 18:27:51 GMT, Ioi Lam wrote: > > This seems like a hack in the UL system. Did you consider confining this in the CDS / AOT code instead? > > Something like this pseudo code: > > ``` > > bool aot_log_is_enabled(Level, ...) { > > return log_is_enabled(Level, aot, link) || > > log_is_enabled(Level, cds, link); > > } > > void aot_log_info(...) {} > > ... > > if (aot_log_is_enabled(Info, link) { > > ResourceMark rm; > > aot_log_info(link)("%s %s %p", class_category_name(ik), ik->external_name(), ik); > > } > > ``` > > OK I'll try that. I think most `cds` logs are obscure and can be changed to `aot`. I'll implement a few macros for the style you suggested above, and use them on the "user facing" logs -- e.g, those that report errors for trouble shooting purposes. @stefank @jdksjolen could you check out https://github.com/openjdk/jdk/pull/25136 for the new approach? That PR has much more changes than this PR, but we need to change those eventually anyway to complete the `[cds]` to `[aot]` transition. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24895#issuecomment-2865016262 From dholmes at openjdk.org Fri May 9 04:39:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 04:39:50 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 2 May 2025 23:16:50 GMT, Jiangli Zhou wrote: > Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. > > These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. > > Tested all three tests on static-jdk. All three tests pass with the fix. This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2865073087 From stuefe at openjdk.org Fri May 9 05:16:50 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 9 May 2025 05:16:50 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 9 May 2025 04:37:34 GMT, David Holmes wrote: > This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2865142017 From dholmes at openjdk.org Fri May 9 05:27:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 05:27:53 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil wrote: > When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM. > > > test/hotspot/jtreg/containers/docker/TestPids.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128 > > > DefaultTasksMax=28776 for RAM 24576MB > DefaultTasksMax=19128 for RAM 16384MB > DefaultTasksMax=1088 for RAM 1024MB > > The testcase expects DefaultTasksMax>=20000. I need to run this through our testing ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2865160809 From sjohanss at openjdk.org Fri May 9 06:07:53 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 May 2025 06:07:53 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: References: Message-ID: On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf wrote: > Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). > > I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. > > Testing: > - [x] GHA - tier 1 (windows failures seem infra related) > - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. > > Thoughts? Opinions? Thanks for looking into this Severin. Thinking back to the discussions we had around this at OCW, I remember there were some concerns regarding different types of deployments. I think this really makes sense in the cases where we divide a machines memory using containers, but what if containers are just used to divide other resources. One use-case that was raised was containerized applications on Linux. I'm not sure if such an application would report true for `is_containerized()`, but it would be nice to have some data around this. Have you done any testing with containerized apps? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-2865246427 From dholmes at openjdk.org Fri May 9 06:08:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 9 May 2025 06:08:52 GMT Subject: RFR: 8356577: Migrate ClassFileVersionTest to be feature-agnostic In-Reply-To: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> References: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> Message-ID: On Thu, 8 May 2025 20:05:56 GMT, Chen Liang wrote: > In #24923 we noted that ClassFileVersionTest depends on arbitrary preview features to have javac mark itself as preview. This creates an extra, hard-to-detect dependency on those features, and make its maintenance costly. The best way to have a class that has preview bit is to use ClassFile API to generate such a simple class instead, now that ClassFile API is available. > > Testing: This test itself I'm not fluent in ClassFile API but this looks good to me. Thanks for fixing. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25128#pullrequestreview-2827120321 From iklam at openjdk.org Fri May 9 06:25:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 06:25:29 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode Message-ID: For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. ------------- Commit messages: - 8356597: AOT cache and CDS archive should not be created in read-only mode Changes: https://git.openjdk.org/jdk/pull/25137/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25137&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356597 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25137/head:pull/25137 PR: https://git.openjdk.org/jdk/pull/25137 From alanb at openjdk.org Fri May 9 06:28:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 May 2025 06:28:52 GMT Subject: RFR: 8356577: Migrate ClassFileVersionTest to be feature-agnostic In-Reply-To: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> References: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> Message-ID: On Thu, 8 May 2025 20:05:56 GMT, Chen Liang wrote: > In #24923 we noted that ClassFileVersionTest depends on arbitrary preview features to have javac mark itself as preview. This creates an extra, hard-to-detect dependency on those features, and make its maintenance costly. The best way to have a class that has preview bit is to use ClassFile API to generate such a simple class instead, now that ClassFile API is available. > > Testing: This test itself Good okay, thanks for getting this updated to avoid the SV JEP changes needing to deal with this. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25128#pullrequestreview-2827152214 From mbaesken at openjdk.org Fri May 9 07:15:56 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 May 2025 07:15:56 GMT Subject: RFR: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro In-Reply-To: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> References: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> Message-ID: On Wed, 7 May 2025 14:48:50 GMT, Matthias Baesken wrote: > The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. > See the discussion here > https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25099#issuecomment-2865406180 From mbaesken at openjdk.org Fri May 9 07:15:57 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 9 May 2025 07:15:57 GMT Subject: Integrated: 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro In-Reply-To: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> References: <5OJVQzskDzGe1QOJ6ejveXpk3fn1zCr2ofpYsyzGOGQ=.3bfa8be7-7864-4dc6-982e-ab53204a2da3@github.com> Message-ID: On Wed, 7 May 2025 14:48:50 GMT, Matthias Baesken wrote: > The macro USE_LIBRARY_BASED_TLS_ONLY played a role on AIX and some mobile platforms a while ago but currently it seems to be not needed any more, so it can be removed. > See the discussion here > https://mail.openjdk.org/pipermail/mobile-dev/2025-May/000946.html This pull request has now been integrated. Changeset: c88f94c9 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/c88f94c9d7a12225a3571e0ba5399d4c42eeb707 Stats: 21 lines in 3 files changed: 0 ins; 20 del; 1 mod 8356394: Remove USE_LIBRARY_BASED_TLS_ONLY macro Reviewed-by: dholmes, kbarrett, lucy ------------- PR: https://git.openjdk.org/jdk/pull/25099 From shade at openjdk.org Fri May 9 07:29:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 May 2025 07:29:51 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 19:54:33 GMT, Calvin Cheung wrote: >> The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. >> Increasing the timeout value from 500 to 800 seems to have addressed the issue. >> With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > @shipilev comment Looks fine, thanks! ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25111#pullrequestreview-2827295608 From jsjolen at openjdk.org Fri May 9 08:49:52 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 9 May 2025 08:49:52 GMT Subject: RFR: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache [v6] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 02:59:35 GMT, Ioi Lam wrote: >> *Specification:* >> >> When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: >> >> - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` >> - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. >> >> *Examples:* >> >> Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible >> >> $ java -Xshare:auto -Xlog:cds --version | grep trying >> [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration >> >> $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying >> [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration >> >> $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi >> [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa >> >> >> When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified >> >> $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version >> [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. >> [0.009s][error][aot] Loading AOT cache failed: nofile.aot >> java 25-internal 2025-09-16 >> Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) >> Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Removed checks for error message that got removed from the PR > > > This seems like a hack in the UL system. Did you consider confining this in the CDS / AOT code instead? > > > Something like this pseudo code: > > > ``` > > > bool aot_log_is_enabled(Level, ...) { > > > return log_is_enabled(Level, aot, link) || > > > log_is_enabled(Level, cds, link); > > > } > > > void aot_log_info(...) {} > > > ... > > > if (aot_log_is_enabled(Info, link) { > > > ResourceMark rm; > > > aot_log_info(link)("%s %s %p", class_category_name(ik), ik->external_name(), ik); > > > } > > > ``` > > > > > > OK I'll try that. I think most `cds` logs are obscure and can be changed to `aot`. I'll implement a few macros for the style you suggested above, and use them on the "user facing" logs -- e.g, those that report errors for trouble shooting purposes. > > @stefank @jdksjolen could you check out #25136 for the new approach? > > That PR has much more changes than this PR, but we need to change those eventually anyway to complete the `[cds]` to `[aot]` transition. Personally, I was fine with a **temporary** hack. Now, we do have a 'proper' solution, so let's go with that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24895#issuecomment-2865705250 From sgehwolf at openjdk.org Fri May 9 10:06:50 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 9 May 2025 10:06:50 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: References: Message-ID: <3zkVeUEqr_avGG1v8Q0Dp_0_FiZrXLxHJeU4KQ556sg=.77fbebb1-8bcf-40bb-95c0-664120321cbf@github.com> On Wed, 7 May 2025 09:29:16 GMT, Severin Gehwolf wrote: > Please take a look at this proposal to fix the "Java needs so much memory" perception in containers. The idea would be to bump the default `MaxRAMPercentage` to a higher value. The patch proposes 75%, but we could just as well use 50% if people feel more comfortable about it. Right now the default deployment in containers with resource limits in place (common for Kubernetes deployments) where a single process runs in the container isn't well catered for today for an application that just uses the default configuration. Only 25% of the container memory will be used for the Java heap, arguably wasting much of the remaining memory that has been granted to the container by a memory limit (that the JVM would detect and use as physical memory). > > I've filed a CSR for this as well for which I'm looking for reviewers too and intend to write a release note as well about this change as it has some risk associated with it, although the escape hatch is pretty simple: set `-XX:MaxRAMPercentage=25.0` to go back to the old behavour. > > Testing: > - [x] GHA - tier 1 (windows failures seem infra related) > - [x] hotspot and jdk container tests on cg v2 and cg v1 including the two new tests. > > Thoughts? Opinions? Thanks for looking at this, Stefan. > Thinking back to the discussions we had around this at OCW, I remember there were some concerns regarding different types of deployments. I think this really makes sense in the cases where we divide a machines memory using containers, but what if containers are just used to divide other resources. One use-case that was raised was containerized applications on Linux. Currently there is only the generic `is_containerized()` API which has been documented in the bug that fixed that: [JDK-8261242](https://bugs.openjdk.org/browse/JDK-8261242?focusedId=14685743&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14685743) So yes, this would update the RAM percentage for a) unprivileged container (no limits), b) some other container tech which sets the cgroup CPU limit for example. The JVM currently only looks at memory/cpu limits for privileged containers and takes that into consideration for `is_containerized()`. If there is consensus, we could add an API that returns true if only a memory limit is present. That doesn't exist yet, though. Happy to propose something going into that direction. The infra is already there. > I'm not sure if such an application would report true for `is_containerized()`, but it would be nice to have some data around this. It would return true for any non-privileged container. I can see that this might be a concern. > Have you done any testing with containerized apps? I have done some basic testing so far, but would be happy to do more. What specific testing would you be interested in? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-2865954385 From shade at openjdk.org Fri May 9 11:31:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 May 2025 11:31:52 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: On Fri, 9 May 2025 06:20:47 GMT, Ioi Lam wrote: > For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. > > Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. src/hotspot/share/cds/filemap.cpp line 750: > 748: // allow processes that have it open continued access to the file. > 749: remove(_full_path); > 750: int fd = os::open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0666); Why `0666`, though, i.e. world-writable? None of the tools, AFAICS from your examples, do world-writability. Should be `0644`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25137#discussion_r2081477375 From shade at openjdk.org Fri May 9 11:36:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 May 2025 11:36:54 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: On Fri, 9 May 2025 11:25:11 GMT, Aleksey Shipilev wrote: >> For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. >> >> Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. > > src/hotspot/share/cds/filemap.cpp line 750: > >> 748: // allow processes that have it open continued access to the file. >> 749: remove(_full_path); >> 750: int fd = os::open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0666); > > Why `0666`, though, i.e. world-writable? None of the tools, AFAICS from your examples, do world-writability. Should be at most `0664`? Also matches what Linux does: $ rm 1; touch 1; stat 1 | grep Access Access: (0664/-rw-rw-r--) Uid: ( 1000/ shade) Gid: ( 1000/ shade) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25137#discussion_r2081487700 From azafari at openjdk.org Fri May 9 12:09:45 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Fri, 9 May 2025 12:09:45 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v24] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed one case. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/abf61321..a0d30ac8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=22-23 Stats: 23 lines in 2 files changed: 0 ins; 7 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From sgehwolf at openjdk.org Fri May 9 13:27:53 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 9 May 2025 13:27:53 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil wrote: > When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM. > > > test/hotspot/jtreg/containers/docker/TestPids.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128 > > > DefaultTasksMax=28776 for RAM 24576MB > DefaultTasksMax=19128 for RAM 16384MB > DefaultTasksMax=1088 for RAM 1024MB > > The testcase expects DefaultTasksMax>=20000. Not sure if it's worth this complication for the test. I have this setting in `/etc/systemd/system.conf` for that reason: $ grep DefaultTasksMax /etc/systemd/system.conf DefaultTasksMax = 31000 Maybe we could amend the failure message instead to add this config? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2866537562 From jkratochvil at openjdk.org Fri May 9 13:49:50 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 9 May 2025 13:49:50 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Fri, 9 May 2025 13:24:45 GMT, Severin Gehwolf wrote: > $ grep DefaultTasksMax /etc/systemd/system.conf > DefaultTasksMax = 31000 That does not work for me. /usr/lib/systemd/system.conf:DefaultTasksMax=31000 systemd-255.18-1.fc40.x86_64 java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.096s][trace][os,container] Maximum number of tasks is: 19128 Plus it is questionable why to require system reconfiguration when it can be fixed in the testsuite. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2866622289 From sgehwolf at openjdk.org Fri May 9 14:02:53 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 9 May 2025 14:02:53 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Tue, 6 May 2025 14:06:54 GMT, Jan Kratochvil wrote: > When running the testcase in a VM with 16GB RAM it fails as systemd limits DefaultTasksMax based on available RAM. > > > test/hotspot/jtreg/containers/docker/TestPids.java > TEST RESULT: Failed. Execution failed: `main' threw exception: java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.083s][trace][os,container] Maximum number of tasks is: 19128 > > > DefaultTasksMax=28776 for RAM 24576MB > DefaultTasksMax=19128 for RAM 16384MB > DefaultTasksMax=1088 for RAM 1024MB > > The testcase expects DefaultTasksMax>=20000. > > $ grep DefaultTasksMax /etc/systemd/system.conf > > DefaultTasksMax = 31000 > > That does not work for me. > > ``` > /usr/lib/systemd/system.conf:DefaultTasksMax=31000 > systemd-255.18-1.fc40.x86_64 > java.lang.RuntimeException: Limit value 19128 is not accepted as unlimited, log line was [0.096s][trace][os,container] Maximum number of tasks is: 19128 > ``` I think you need to do `sudo systemctl daemon-reload` for it to take effect (or reboot). > Plus it is questionable why to require system reconfiguration when it can be fixed in the testsuite. While that's true, AFAIK, it's only fixing the problem for `docker` and relies on `systemctl show` being present on the system, so it's not necessarily more universal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2866665165 From jkratochvil at openjdk.org Fri May 9 14:28:50 2025 From: jkratochvil at openjdk.org (Jan Kratochvil) Date: Fri, 9 May 2025 14:28:50 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Fri, 9 May 2025 14:00:30 GMT, Severin Gehwolf wrote: > I think you need to do `sudo systemctl daemon-reload` for it to take effect (or reboot). I did reboot. But for some reason it must be in `/etc/systemd/system.conf` and not in `/usr/lib/systemd/system.conf`. > While that's true, AFAIK, it's only fixing the problem for `docker` I do not use `docker` in any way for this bug/fix. > and relies on `systemctl show` being present on the system, so it's not necessarily more universal. Is there an OS with `systemd`-limited process count while not having `systemctl`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2866762382 From iklam at openjdk.org Fri May 9 15:44:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 9 May 2025 15:44:52 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: On Fri, 9 May 2025 11:33:55 GMT, Aleksey Shipilev wrote: >> src/hotspot/share/cds/filemap.cpp line 750: >> >>> 748: // allow processes that have it open continued access to the file. >>> 749: remove(_full_path); >>> 750: int fd = os::open(_full_path, O_RDWR | O_CREAT | O_TRUNC | O_BINARY, 0666); >> >> Why `0666`, though, i.e. world-writable? None of the tools, AFAICS from your examples, do world-writability. Should be at most `0664`? > > Also matches what Linux does: > > > $ rm 1; touch 1; stat 1 | grep Access > Access: (0664/-rw-rw-r--) Uid: ( 1000/ shade) Gid: ( 1000/ shade) We have existing code that uses `0666` ./share/ci/ciEnv.cpp: int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); ./share/ci/ciEnv.cpp: int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); ./share/runtime/os.cpp: int fd = ::open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0666); ./share/utilities/vmError.cpp: fd = open(buf, mode, 0666); `0666` is the default mode on Linux (posix?). The actual file mode will be combined with umask. (And your umask happens to be `002` so you get `rw-rw-r--` instead of `rw-r--r--` :-) ) $ umask 0002 $ rm -f foo $ strace -f touch foo 2>&1 | grep 'foo.*O_CREAT' openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 $ ls -l foo -rw-rw-r-- 1 iklam iklam 0 May 9 08:36 foo Also Javac does the same: $ rm -f HelloWorld.class $ strace -f jdk24/bin/javac HelloWorld.java 2>&1 | grep O_CREAT.*HelloWorld.class [pid 3673548] openat(AT_FDCWD, "/tmp/HelloWorld.class", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 $ ls -l HelloWorld.class -rw-rw-r-- 1 iklam iklam 425 May 9 08:37 HelloWorld.class and $ umask 022 $ rm -f HelloWorld.class $ strace -f /jdk3/official/jdk24/bin/javac HelloWorld.java 2>&1 | grep HelloWorld.class | grep O_CREAT [pid 3674853] openat(AT_FDCWD, "/jdk3/tmp/HelloWorld.class", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 $ ls -l HelloWorld.class -rw-r--r-- 1 iklam iklam 425 May 9 08:37 HelloWorld.class ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25137#discussion_r2081959509 From ccheung at openjdk.org Fri May 9 16:22:00 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 9 May 2025 16:22:00 GMT Subject: RFR: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 15:39:03 GMT, Aleksey Shipilev wrote: >> The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. >> Increasing the timeout value from 500 to 800 seems to have addressed the issue. >> With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. > > Quick profiling shows we spend _a lot_ of time in class inits and SystemDictionary verification. Some of this can be alleviated by skipping the verification. > > Also, a different route: the test is a regression test for JDK-8342283. That bug is about backing storage in `Map`, `List` exceeding CDS archival limit (256KB). So nominally, we want 256KB / 4 bytes = 64K classes in this test. > > So I propose in addition to bumping the timeout, we also optimize the test like this: > > > diff --git a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java > index 96d2dc0d6ee..6267c6bdf33 100644 > --- a/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java > +++ b/test/hotspot/jtreg/runtime/cds/appcds/LotsOfSyntheticClasses.java > @@ -42,9 +42,12 @@ > > public class LotsOfSyntheticClasses { > > - // Generate 100 top-level classes, each containing 1000 nested classes. > - // 100K total classes are more than enough to push the CDS limits. > - private static final int NUM_CLASSES = 100; > + // Generate 70 top-level classes, each containing 1000 nested classes. > + // 70K total classes is enough to push the CDS limits. Any archived > + // collection that holds Classes should not have backing storage larger > + // than CDS archival limit (256KB). This means we want at least 64K classes > + // to probe that limit. > + private static final int NUM_CLASSES = 70; > private static final int NUM_NESTED_CLASSES = 1000; > > private static final Path USER_DIR = Paths.get(CDSTestUtils.getOutputDir()); > @@ -117,7 +120,11 @@ public static void main(String[] args) throws Exception { > OutputAnalyzer output = TestCommon.createArchive( > APP_JAR.toString(), > listAppClasses(), > - MAIN_CLASS_NAME > + MAIN_CLASS_NAME, > + // Verification for lots of classes slows down the test. > + "-XX:+IgnoreUnrecognizedVMOptions", > + "-XX:-VerifyDependencies", > + "-XX:-VerifyBeforeExit" > ); > TestCommon.checkDump(output); > } > @@ -125,9 +132,10 @@ public static void main(String[] args) throws Exception { > // Step 3. Try to run, touching every class. > { > TestCommon.run( > - // Verifying dependencies for lots of classes slows down the test. > - "-XX:+IgnoreUnrecognizedVMOptions", "-XX:-VerifyDe... Thanks @shipilev @sendaoYan @iklam for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25111#issuecomment-2867127249 From ccheung at openjdk.org Fri May 9 16:22:01 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 9 May 2025 16:22:01 GMT Subject: Integrated: 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 05:06:01 GMT, Calvin Cheung wrote: > The LotsOfSyntheticClasses.java test times out intermittently when the `open/test/hotspot/jtreg:hotspot_aot_classlinking` test group is run with the` -XX:+AOTClassLinking` option on macosx-aarch64 platform. > Increasing the timeout value from 500 to 800 seems to have addressed the issue. > With the change, there's no timeout when the test group is run 40 times on macosx-aarch64 with the same option. This pull request has now been integrated. Changeset: dd25799c Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/dd25799c21529bf8dac49a63ddbcab530af0215b Stats: 15 lines in 1 file changed: 8 ins; 0 del; 7 mod 8356212: runtime/cds/appcds/LotsOfSyntheticClasses.java timed out with -XX:+AOTClassLinking Reviewed-by: iklam, shade, syan ------------- PR: https://git.openjdk.org/jdk/pull/25111 From shade at openjdk.org Fri May 9 16:25:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 May 2025 16:25:52 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: On Fri, 9 May 2025 06:20:47 GMT, Ioi Lam wrote: > For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. > > Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25137#pullrequestreview-2828941354 From shade at openjdk.org Fri May 9 16:25:53 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 May 2025 16:25:53 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: On Fri, 9 May 2025 15:42:26 GMT, Ioi Lam wrote: >> Also matches what Linux does: >> >> >> $ rm 1; touch 1; stat 1 | grep Access >> Access: (0664/-rw-rw-r--) Uid: ( 1000/ shade) Gid: ( 1000/ shade) > > We have existing code that uses `0666` > > > ./share/ci/ciEnv.cpp: int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); > ./share/ci/ciEnv.cpp: int fd = os::open(buffer, O_RDWR | O_CREAT | O_TRUNC, 0666); > ./share/runtime/os.cpp: int fd = ::open(filename, O_WRONLY | O_CREAT | O_TRUNC, 0666); > ./share/utilities/vmError.cpp: fd = open(buf, mode, 0666); > > > `0666` is the default mode on Linux (posix?). The actual file mode will be combined with umask. > > (And your umask happens to be `002` so you get `rw-rw-r--` instead of `rw-r--r--` :-) ) > > > $ umask > 0002 > $ rm -f foo > $ strace -f touch foo 2>&1 | grep 'foo.*O_CREAT' > openat(AT_FDCWD, "foo", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 > $ ls -l foo > -rw-rw-r-- 1 iklam iklam 0 May 9 08:36 foo > > > Also Javac does the same: > > > $ rm -f HelloWorld.class > $ strace -f jdk24/bin/javac HelloWorld.java 2>&1 | grep O_CREAT.*HelloWorld.class > [pid 3673548] openat(AT_FDCWD, "/tmp/HelloWorld.class", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 > $ ls -l HelloWorld.class > -rw-rw-r-- 1 iklam iklam 425 May 9 08:37 HelloWorld.class > > and > > $ umask 022 > $ rm -f HelloWorld.class > $ strace -f /jdk3/official/jdk24/bin/javac HelloWorld.java 2>&1 | grep HelloWorld.class | grep O_CREAT > [pid 3674853] openat(AT_FDCWD, "/jdk3/tmp/HelloWorld.class", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 > $ ls -l HelloWorld.class > -rw-r--r-- 1 iklam iklam 425 May 9 08:37 HelloWorld.class Oh, TIL. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25137#discussion_r2082026482 From kvn at openjdk.org Fri May 9 16:43:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 9 May 2025 16:43:53 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: <1Jk4BVVABSiIk8zmmjHw6H8UKQ9meUndx0tNbJtAup0=.6b547a45-9719-41b0-8139-14d7cd49d1d1@github.com> On Fri, 9 May 2025 06:20:47 GMT, Ioi Lam wrote: > For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. > > Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25137#pullrequestreview-2829030065 From liach at openjdk.org Fri May 9 22:00:54 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 22:00:54 GMT Subject: RFR: 8356577: Migrate ClassFileVersionTest to be feature-agnostic In-Reply-To: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> References: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> Message-ID: On Thu, 8 May 2025 20:05:56 GMT, Chen Liang wrote: > In #24923 we noted that ClassFileVersionTest depends on arbitrary preview features to have javac mark itself as preview. This creates an extra, hard-to-detect dependency on those features, and make its maintenance costly. The best way to have a class that has preview bit is to use ClassFile API to generate such a simple class instead, now that ClassFile API is available. > > Testing: This test itself Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25128#issuecomment-2867953140 From liach at openjdk.org Fri May 9 22:00:54 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 May 2025 22:00:54 GMT Subject: Integrated: 8356577: Migrate ClassFileVersionTest to be feature-agnostic In-Reply-To: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> References: <1xJ-NuAkNMVnviU5JZ2LTOiw4NNshfVcCUOVdzPypO4=.3311fdb9-f17c-4581-8d0f-d3b531d05e34@github.com> Message-ID: On Thu, 8 May 2025 20:05:56 GMT, Chen Liang wrote: > In #24923 we noted that ClassFileVersionTest depends on arbitrary preview features to have javac mark itself as preview. This creates an extra, hard-to-detect dependency on those features, and make its maintenance costly. The best way to have a class that has preview bit is to use ClassFile API to generate such a simple class instead, now that ClassFile API is available. > > Testing: This test itself This pull request has now been integrated. Changeset: 0f2a6c26 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/0f2a6c266b2e3aab59a5cd183e10dfc4820ca92d Stats: 19 lines in 1 file changed: 7 ins; 8 del; 4 mod 8356577: Migrate ClassFileVersionTest to be feature-agnostic Reviewed-by: dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25128 From jiangli at openjdk.org Fri May 9 22:53:51 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Fri, 9 May 2025 22:53:51 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 9 May 2025 05:14:06 GMT, Thomas Stuefe wrote: > > This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? > > I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. @dholmes-ora @tstuefe Thanks for looking at this. Setting up the `-Dtest.jdk` and `-Dcompile.jdk` in `ProcessTools` seems reasonable on the first thought. I went ahead and changed to move setting `-Dtest.jdk` and `-Dcompile.jdk` into `ProcessTools.createJavaProcessBuilder()`, in my local branch. All three tests pass on static-jdk in my local testing, without explicitly setting `-Dtest.jdk` and `-Dcompile.jdk` in test code when launching child process. However, thinking more on this I realize that some tests may want to set to a different `test.jdk` or `compile.jdk` intentionally, and we need to be careful to not cause any unexpected side-effects. Of course, if we put `-Dtest.jdk=` and `-Dcompile.jdk=` command-line options immediately after the launcher (that's the case with my new local change), the settings from test can override the default settings in `ProcessTools.createJavaProcessBuilder()`. There would be no unexpected behavior. Any other thoughts, in case I missed something? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2868009830 From dholmes at openjdk.org Sat May 10 02:03:01 2025 From: dholmes at openjdk.org (David Holmes) Date: Sat, 10 May 2025 02:03:01 GMT Subject: RFR: 8356277: containers/docker/TestPids.java: Limit value 19128 is not accepted as unlimited In-Reply-To: References: Message-ID: On Fri, 9 May 2025 05:25:00 GMT, David Holmes wrote: > I need to run this through our testing ... Turns out I can't so I have no further input here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25067#issuecomment-2868218350 From iklam at openjdk.org Sat May 10 05:40:03 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 10 May 2025 05:40:03 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode [v2] In-Reply-To: References: Message-ID: <_vIAjqw3MFRkLBmqygTCbUovOzwt-6or1mpwGIdk8nY=.4de3e61c-28f2-42eb-8754-cc7acd3d9411@github.com> > For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. > > Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. Ioi Lam 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 8356597-aot-cache-and-cds-archive-should-not-be-read-only - 8356597: AOT cache and CDS archive should not be created in read-only mode ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25137/files - new: https://git.openjdk.org/jdk/pull/25137/files/7c639936..020e0ca7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25137&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25137&range=00-01 Stats: 3059 lines in 105 files changed: 1864 ins; 466 del; 729 mod Patch: https://git.openjdk.org/jdk/pull/25137.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25137/head:pull/25137 PR: https://git.openjdk.org/jdk/pull/25137 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 iklam at openjdk.org Sat May 10 15:18:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 10 May 2025 15:18:56 GMT Subject: RFR: 8356597: AOT cache and CDS archive should not be created in read-only mode [v2] In-Reply-To: References: Message-ID: On Fri, 9 May 2025 16:23:34 GMT, Aleksey Shipilev wrote: >> Ioi Lam 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 8356597-aot-cache-and-cds-archive-should-not-be-read-only >> - 8356597: AOT cache and CDS archive should not be created in read-only mode > > Marked as reviewed by shade (Reviewer). Thanks @shipilev @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25137#issuecomment-2868959302 From iklam at openjdk.org Sat May 10 15:18:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Sat, 10 May 2025 15:18:57 GMT Subject: Integrated: 8356597: AOT cache and CDS archive should not be created in read-only mode In-Reply-To: References: Message-ID: <8kFJvuvy4htLUUm_uzsbc5CQUD4AyTedMaeE7GUMVMY=.137e214a-014c-4481-91dc-f3e9a05ba40f@github.com> On Fri, 9 May 2025 06:20:47 GMT, Ioi Lam wrote: > For some unknown historical reasons, AOT caches and CDS archives have been created in read-only mode. This makes them hard to delete, causing problems when running tests that creates a lot of these files. > > Since all other JDK tools create binary files in read-write mode, AOT caches and CDS archives should do the same. This pull request has now been integrated. Changeset: 43696030 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/436960308cebe020549fcdbb4bcb12c90ce7aeb8 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod 8356597: AOT cache and CDS archive should not be created in read-only mode Reviewed-by: shade, kvn ------------- PR: https://git.openjdk.org/jdk/pull/25137 From nbenalla at openjdk.org Sat May 10 15:44:51 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sat, 10 May 2025 15:44:51 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v2] In-Reply-To: References: Message-ID: On Sat, 10 May 2025 14:32:10 GMT, Chen Liang wrote: >>> I have asked @nizarbenalla in offline communications for a list of failing hotspot tests. I aim to update them on a case-by-case basis, to determine if the compile arguments should provide a `--release ` argument or migrate class file parsing to ClassFile API. >> >> Sounds good. I think prepping such a change is outside the scope of what @nizarbenalla or myself should do as part of the start of JDK 26 patch. > > See #25124. Thanks Chen! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2083223695 From dholmes at openjdk.org Mon May 12 01:52:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 May 2025 01:52:58 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 9 May 2025 22:50:48 GMT, Jiangli Zhou wrote: >>> This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? >> >> I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. > >> > This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? >> >> I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. > > @dholmes-ora @tstuefe Thanks for looking at this. Setting up the `-Dtest.jdk` and `-Dcompile.jdk` in `ProcessTools` seems reasonable on the first thought. I went ahead and changed to move setting `-Dtest.jdk` and `-Dcompile.jdk` into `ProcessTools.createJavaProcessBuilder()`, in my local branch. All three tests pass on static-jdk in my local testing, without explicitly setting `-Dtest.jdk` and `-Dcompile.jdk` in test code when launching child process. However, thinking more on this I realize that some tests may want to set to a different `test.jdk` or `compile.jdk` intentionally, and we need to be careful to not cause any unexpected side-effects. Of course, if we put `-Dtest.jdk=` and `-Dcompile.jdk=` command-line options immediately after the launcher (that's the case with my new local change), the settings from test can override the default settings in `ProcessTools.createJavaProcessBuilder()`. There would be no unexpected behavior. Any other thoughts, in case I missed something? @jianglizhou FWIW I couldn't find any test that explicitly sets `-Dcompile.jdk= ...` it seems these are things expected to only be set via jtreg for a test component to use. The problem we face here is that tests that exec a VM programmatically do not pass through these jtreg settings (reasonably so as the individual tests need not have any knowledge of their existence). We have defined `createJavaProcessBuilder` to pass through flags passed via jtreg (as opposed to `createLimitedJavaProcessBuilder`) so I think it is quite reasonable to include these properties as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2870487570 From dholmes at openjdk.org Mon May 12 01:59:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 May 2025 01:59:51 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 2 May 2025 23:16:50 GMT, Jiangli Zhou wrote: > Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. > > These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. > > Tested all three tests on static-jdk. All three tests pass with the fix. For anyone just following the emails please note my previous comment [1] was sent prematurely and has been updated in a significant way. [1] https://github.com/openjdk/jdk/pull/25018#issuecomment-2870487570 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2870494279 From jiangli at openjdk.org Mon May 12 04:32:50 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 04:32:50 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 9 May 2025 22:50:48 GMT, Jiangli Zhou wrote: >>> This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? >> >> I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. > >> > This looks rather hackish to me - individual tests should not need to know about how to make jdkToolFinder work. Can this be hidden away in `ProcessTools.createLimitedTestJavaProcessBuilder` and other `ProcessTools` code as needed? >> >> I agree, this feels like the wrong place for this kind of logic. The tests should not have to care whether they run on a static JDK. > > @dholmes-ora @tstuefe Thanks for looking at this. Setting up the `-Dtest.jdk` and `-Dcompile.jdk` in `ProcessTools` seems reasonable on the first thought. I went ahead and changed to move setting `-Dtest.jdk` and `-Dcompile.jdk` into `ProcessTools.createJavaProcessBuilder()`, in my local branch. All three tests pass on static-jdk in my local testing, without explicitly setting `-Dtest.jdk` and `-Dcompile.jdk` in test code when launching child process. However, thinking more on this I realize that some tests may want to set to a different `test.jdk` or `compile.jdk` intentionally, and we need to be careful to not cause any unexpected side-effects. Of course, if we put `-Dtest.jdk=` and `-Dcompile.jdk=` command-line options immediately after the launcher (that's the case with my new local change), the settings from test can override the default settings in `ProcessTools.createJavaProcessBuilder()`. There would be no unexpected behavior. Any other thoughts, in case I missed something? > @jianglizhou FWIW I couldn't find any test that explicitly sets `-Dcompile.jdk= ...` it seems these are things expected to only be set via jtreg for a test component to use. > > The problem we face here is that tests that exec a VM programmatically do not pass through these jtreg settings (reasonably so as the individual tests need not have any knowledge of their existence). We have defined `createJavaProcessBuilder` to pass through flags passed via jtreg (as opposed to `createLimitedJavaProcessBuilder`) so I think it is quite reasonable to include these properties as well. > > However, the tests at hand use `createLimitedJavaProcessbuilder` which intentionally does not pass on any flags, so we are muddying the waters if we decide that it should pass on some flags after all. Thanks for the thoughts, @dholmes-ora. I didn't notice the difference between `createTestJavaProcessBuilder` and `createLimitedTestJavaProcessBuilder` before reading your comments above. Thanks for pointing out to those. Both methods calls the underlying `createJavaProcessBuilder`, and `createTestJavaProcessBuilder` includes additional arguments from `test.vm.opts` and `test.java.opts` from jtreg environment (comparing to `createLimitedTestJavaProcessBuilder`). The underlying `createJavaProcessBuilder` already adds `-Dtest.thread.factory=...` to the child process' command-line argument if the system property is defined. It seems also ok to add `-Dcompile.jdk=...` then. `-Dcompile.jdk=...` doesn't affect the VM and Java options, so it seems fine for `createLimitedTestJavaProcessBuilder` to also include it. In my local change, I included `-Dtest.jdk= ...` as well. It's probably better to leave `-Dtest.jdk= ...` out. I'll update my PR based on the discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2870784488 From jiangli at openjdk.org Mon May 12 04:44:32 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 04:44:32 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> > Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. > > These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. > > Tested all three tests on static-jdk. All three tests pass with the fix. Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: Address David and Thomas comment: - Set `-Dcompile.jdk= ...` for child process from `ProcessTools.createJavaProcessBuilder()`. - Revert tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25018/files - new: https://git.openjdk.org/jdk/pull/25018/files/6fd8d7ef..dd23d795 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25018&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25018&range=00-01 Stats: 13 lines in 4 files changed: 4 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25018/head:pull/25018 PR: https://git.openjdk.org/jdk/pull/25018 From fbredberg at openjdk.org Mon May 12 08:19:01 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 12 May 2025 08:19:01 GMT Subject: RFR: 8355646: Optimize ObjectMonitor::exit [v2] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 12:13:54 GMT, Fredrik Bredberg wrote: >> Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. >> >> If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. >> >> If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. >> >> This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. >> >> When running performance tests we see that the number of test that has improved outnumber the tests that has not. >> >> Passes tier1-7 with no added problems. > > Fredrik Bredberg 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: > > - Updated after review > - Merge branch 'master' into 8355646_optimize_objectmonitor_exit > - 8355646: Optimize ObjectMonitor::exit Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24927#issuecomment-2871357425 From fbredberg at openjdk.org Mon May 12 08:19:01 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 12 May 2025 08:19:01 GMT Subject: Integrated: 8355646: Optimize ObjectMonitor::exit In-Reply-To: References: Message-ID: On Mon, 28 Apr 2025 15:29:12 GMT, Fredrik Bredberg wrote: > Today ObjectMonitor::exit always releases the lock before checking if it needs to wake up a waiting thread that is queued on the entry_list. In order to unpark a thread from the entry_list it needs to re-acquire the lock again. > > If we (before releasing the lock) check if there is no assigned successor but there is a waiting thread in the entry_list we can immediately unpark the thread, thus saving us the trouble of releasing and re-acquiring the lock. > > If there already is an assigned successor (spinning and wanting to acquire the lock) we still want to release the lock as soon as possible so that we don't lengthen the critical section thereby delaying any spinning threads from getting the lock in a high contention scenario. > > This PR is first and foremost an optimization if the lock is lightly contended. It also removes some source reading confusion, as to why we release and then immediately re-acquire the lock. > > When running performance tests we see that the number of test that has improved outnumber the tests that has not. > > Passes tier1-7 with no added problems. This pull request has now been integrated. Changeset: 39a28ffe Author: Fredrik Bredberg URL: https://git.openjdk.org/jdk/commit/39a28ffe4e23274dba34317d8960bfb7e6d203ed Stats: 54 lines in 1 file changed: 27 ins; 23 del; 4 mod 8355646: Optimize ObjectMonitor::exit Reviewed-by: pchilanomate, coleenp ------------- PR: https://git.openjdk.org/jdk/pull/24927 From jsjolen at openjdk.org Mon May 12 08:39:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 12 May 2025 08:39:07 GMT Subject: RFR: 8356756: Cleanup: Make ClassLoaderData::_deallocate_list an object Message-ID: A small cleanup in order to get rid of some branches checking for null. Testing: GHA ------------- Commit messages: - Make ClassLoaderData::_deallocate_list an ordinary object Changes: https://git.openjdk.org/jdk/pull/25117/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25117&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356756 Stats: 30 lines in 2 files changed: 0 ins; 15 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25117.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25117/head:pull/25117 PR: https://git.openjdk.org/jdk/pull/25117 From azafari at openjdk.org Mon May 12 11:21:41 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 12 May 2025 11:21:41 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit - fixed one case. - test with random requests passes now. - semantic text added. - more tests for full coverage of update_region. - fixes for cross-compilations - removed print_on for release build success. - complete code coverage for new impl. All tests pass. - new version. All tests except one passed. - second try - ... and 17 more: https://git.openjdk.org/jdk/compare/365570f8...043c11d6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/a0d30ac8..043c11d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=23-24 Stats: 65015 lines in 1946 files changed: 44836 ins; 12014 del; 8165 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Mon May 12 11:25:58 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 12 May 2025 11:25:58 GMT Subject: RFR: 8354115: NMT: VMATree should not accept `uncommit` a `released` region [v5] In-Reply-To: References: Message-ID: On Wed, 23 Apr 2025 14:25:07 GMT, Afshin Zafari wrote: >> At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. >> This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. >> >> Two test-cases added and run. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > debug prints to trace the test-case executions This change will be covered more efficiently in [here](https://bugs.openjdk.org/browse/JDK-8351661). ------------- PR Comment: https://git.openjdk.org/jdk/pull/24572#issuecomment-2872149288 From azafari at openjdk.org Mon May 12 11:25:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Mon, 12 May 2025 11:25:59 GMT Subject: Withdrawn: 8354115: NMT: VMATree should not accept `uncommit` a `released` region In-Reply-To: References: Message-ID: On Thu, 10 Apr 2025 12:05:49 GMT, Afshin Zafari wrote: > At `uncommit` we change the state of the regions to `Reserved`. This is not acceptable to uncommit a `Released` region and change its state to `Reserved`. > This case is detected and an invalid `SummaryDiff` (all its contents are -1) is returned. > > Two test-cases added and run. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24572 From coleenp at openjdk.org Mon May 12 12:03:50 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 12 May 2025 12:03:50 GMT Subject: RFR: 8356756: Cleanup: Make ClassLoaderData::_deallocate_list an object In-Reply-To: References: Message-ID: On Thu, 8 May 2025 12:08:31 GMT, Johan Sj?len wrote: > A small cleanup in order to get rid of some branches checking for null. > > Testing: GHA Most CLD won't have a deallocate list, so why do this? It wastes another word per entry. ------------- PR Review: https://git.openjdk.org/jdk/pull/25117#pullrequestreview-2832964909 From adinn at openjdk.org Mon May 12 15:19:57 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Mon, 12 May 2025 15:19:57 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 5 May 2025 21:13:24 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - Fix win64 compile failures > > Signed-off-by: Ashutosh Mehra > - Fix AOTCodeFlags.java test > > Signed-off-by: Ashutosh Mehra > - Fix compile failure in minimal config > > Signed-off-by: Ashutosh Mehra > - Revert back changes that added AOTRuntimeConstants. > Ensure CompressedOops::base and CompressedKlssPointers::base does not > change in production run > > Signed-off-by: Ashutosh Mehra > - Fix merge conflicts > > Signed-off-by: Ashutosh Mehra > - Store/load AsmRemarks and DbgStrings in aot code cache > > Signed-off-by: Ashutosh Mehra > - Add missing external address in aarch64 > > Signed-off-by: Ashutosh Mehra > - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab Having discussed this with @fisk it appears that the weak reference load performed by the c2i adapters will not attempt a decode. The barrier load_at method only performs a decode when the decorators include `IN_HEAP`. `resolve_weak_handle` passes in the `IN_NATIVE` decorator which implies no decode should be performed. So, this means we can use the adapters even if the compressed oop base differs between training run and production run. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2872988728 From kvn at openjdk.org Mon May 12 15:39:52 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 15:39:52 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v4] In-Reply-To: References: Message-ID: On Wed, 7 May 2025 05:11:01 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java @dholmes-ora pointed that we forgot update Java man page with new AOT flags. @iklam, please do that here for this JEP and JEP 483. ------------- Changes requested by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2833694086 From kvn at openjdk.org Mon May 12 16:14:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 16:14:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833790759 From iklam at openjdk.org Mon May 12 17:20:56 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 17:20:56 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 6 May 2025 21:50:34 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments LGTM. Small nits about logging and testing. src/hotspot/share/cds/filemap.cpp line 1955: > 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, > 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); > 1955: return false; The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2833939411 PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085115469 From asmehra at openjdk.org Mon May 12 18:24:30 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 12 May 2025 18:24:30 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v3] In-Reply-To: References: Message-ID: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: - Add test for using AOTCodeCache with different CompressedOops configuration Signed-off-by: Ashutosh Mehra - Add check for compressed oops base address; minor refacotring Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25019/files - new: https://git.openjdk.org/jdk/pull/25019/files/ba612dab..9fcc91b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=01-02 Stats: 233 lines in 5 files changed: 202 ins; 14 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 From iveresov at openjdk.org Mon May 12 19:29:18 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 12 May 2025 19:29:18 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v15] In-Reply-To: References: Message-ID: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: - Merge branch 'master' into pp2 - Address review comments - Merge branch 'master' into pp2 - Fix compile - Fix additional issues - Make sure command line flags that affect MDO layout are consistent - Fix semantics change from the previous commit - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type - Fix flag behavior - Fix log tags - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14 Stats: 3226 lines in 59 files changed: 3011 ins; 100 del; 115 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From heidinga at openjdk.org Mon May 12 20:05:55 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 12 May 2025 20:05:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v15] In-Reply-To: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> References: <-1w2fZRYCt4wwXkNQAmceLjlcPrE8URSeJKzB43PWBQ=.cb013019-c6ae-4cce-b750-c0d38e420c92@github.com> Message-ID: <931WapeeMqp8gbb720PmF0inR4k_kD9CL9UL9SGDyWY=.2406d164-dc7e-49ce-9e26-78f0a7f3f9e6@github.com> On Mon, 12 May 2025 19:29:18 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 45 commits: > > - Merge branch 'master' into pp2 > - Address review comments > - Merge branch 'master' into pp2 > - Fix compile > - Fix additional issues > - Make sure command line flags that affect MDO layout are consistent > - Fix semantics change from the previous commit > - Port 8355915: [leyden] Crash in MDO clearing the unloaded array type > - Fix flag behavior > - Fix log tags > - ... and 35 more: https://git.openjdk.org/jdk/compare/45dfc2c6...ae332887 src/hotspot/share/cds/filemap.hpp line 120: > 118: bool _compressed_class_ptrs; // save the flag UseCompressedClassPointers > 119: int _narrow_klass_pointer_bits; // save number of bits in narrowKlass > 120: int _narrow_klass_shift; // save shift width used to pre-compute narrowKlass IDs in archived heap objectsa Suggestion: int _narrow_klass_shift; // save shift width used to pre-compute narrowKlass IDs in archived heap objects Minor typo, don't bother fixing if it will result in a re-review cycle ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085360465 From asmehra at openjdk.org Mon May 12 20:10:13 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Mon, 12 May 2025 20:10:13 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v4] In-Reply-To: References: Message-ID: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: - Remove more unused code Signed-off-by: Ashutosh Mehra - Fix whitespace issue. Remove unused code. Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25019/files - new: https://git.openjdk.org/jdk/pull/25019/files/9fcc91b3..98e5fa07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 10 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 From iklam at openjdk.org Mon May 12 21:17:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:17:10 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: References: Message-ID: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - Use one-step training by default in AOT testing - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java - @vnkozlov comments - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS - Remove %t restriction - Added %p substitution; clean up - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04 Stats: 1893 lines in 22 files changed: 1387 ins; 456 del; 50 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iveresov at openjdk.org Mon May 12 21:30:12 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Mon, 12 May 2025 21:30:12 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v16] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Make the test permute through default flag values too ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/ae332887..d75cb5dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=14-15 Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iklam at openjdk.org Mon May 12 21:35:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 12 May 2025 21:35:52 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e Per suggestion by @katyapav , I've updated RunTests.gmk to use the new "one step training" when creating the AOT cache for running jtreg test cases. `twostep` is the old behavior. E.g.: make test JTREG=AOT_JDK=onestep TEST=open/test/hotspot/jtreg/runtime/invokedynamic make test JTREG=AOT_JDK=twostep TEST=open/test/hotspot/jtreg/runtime/invokedynamic Also, for the existing CDS jtreg tests that use CDSAppTester, the default testing mode is to use "one step training" for creating the AOT cache. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24942#issuecomment-2874205674 From erikj at openjdk.org Mon May 12 21:43:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 12 May 2025 21:43:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: <8FryhUnn09RpstrSVIOwKLTPBwgh3HzS50dY2cMct5w=.b9e0840e-e585-4178-bd41-f19db4a6a016@github.com> On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e This change in functionality for the `JTREG=AOT_JDK` makefile argument should probably be mentioned somewhere in `doc/testing.md`. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834697107 From jiangli at openjdk.org Mon May 12 21:59:53 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Mon, 12 May 2025 21:59:53 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> Message-ID: <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> On Mon, 12 May 2025 04:44:32 GMT, Jiangli Zhou wrote: >> Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. >> >> These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. >> >> Tested all three tests on static-jdk. All three tests pass with the fix. > > Jiangli Zhou has updated the pull request incrementally with one additional commit since the last revision: > > Address David and Thomas comment: > - Set `-Dcompile.jdk= ...` for child process from `ProcessTools.createJavaProcessBuilder()`. > - Revert tests. The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option, https://github.com/jianglizhou/jdk/actions/runs/14963966012#user-content-jdk_internal_misc_vm_runtimearguments. Perhaps we can consider changing test/hotspot/jtreg/runtime/CommandLine/OptionsValidation/TestJcmdOutput.java and test/hotspot/jtreg/runtime/NMT/JcmdWithNMTDisabled.java to use `ProcessTools.createTestJavaProcessBuilder` and add the `-Dcompile.jdk=...` for child process created by `ProcessTools.createTestJavaProcessBuilder` only. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2874295065 From kvn at openjdk.org Mon May 12 22:51:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 22:51:55 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 20:10:13 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: > > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra src/hotspot/share/code/aotCodeCache.hpp line 169: > 167: class Config { > 168: uint _compressedOopShift; > 169: address _compressedOopBase; Put it fist to avoid gaps between fields. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2085638902 From kvn at openjdk.org Mon May 12 23:04:54 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 23:04:54 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 20:10:13 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: > > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra test/hotspot/jtreg/runtime/cds/appcds/aotCode/AOTCodeCompressedOopsTest.java line 48: > 46: import jdk.test.lib.process.OutputAnalyzer; > 47: > 48: public class AOTCodeCompressedOopsTest { Ioi also suggested test example which I attached to RFE in JBS. Looks like your test is very similar and more. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2085648044 From kvn at openjdk.org Mon May 12 23:09:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 23:09:55 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: <8W_FRkLbamdZ6l0Lkbn8WqXv_JXPjG-i5hBus2foor4=.4f80cd55-4141-46ff-8436-0cbbc9228461@github.com> References: <8W_FRkLbamdZ6l0Lkbn8WqXv_JXPjG-i5hBus2foor4=.4f80cd55-4141-46ff-8436-0cbbc9228461@github.com> Message-ID: On Thu, 8 May 2025 01:33:54 GMT, Ashutosh Mehra wrote: >> I think for these changes we should not use AOT code when the heap base does not match. >> Something changed in compressed oops code which prevents enforcing encoding. >> We can investigate and fix it later. > >> I think for these changes we should not use AOT code when the heap base does not match. > Something changed in compressed oops code which prevents enforcing encoding. > We can investigate and fix it later. > > @vnkozlov for this PR we are relying on having relocation for COOP base, not on enforcing encoding. And that should be able to handle cases where heap base is different in assembly vs prod. Why do you suggest to not use AOT code when the heap base does not match? @ashu-mehra, this looks good with few comments. After you address them, please merge latest jdk - I pushed small related change to limit platforms to run with AOT. After that I will submit new testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2874413950 From kvn at openjdk.org Mon May 12 23:09:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Mon, 12 May 2025 23:09:56 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 20:10:13 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: > > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra src/hotspot/share/code/aotCodeCache.hpp line 374: > 372: > 373: static bool is_dumping_stubs() NOT_CDS_RETURN_(false); > 374: static bool is_using_stubs() NOT_CDS_RETURN_(false); We have singular naming (`is_dumping_stub()`) for these methods in `premain` branch. I was debating to do separate RFE for renaming in mainline or may be you can do it here. It is up to you. I did not pay attention to these when I work on adapter caching. But now I have to merge from mainline to premain and I noticed difference. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2085650099 From epavlova at openjdk.org Mon May 12 23:24:04 2025 From: epavlova at openjdk.org (Ekaterina Pavlova) Date: Mon, 12 May 2025 23:24:04 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v5] In-Reply-To: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> References: <_LoKb_tcJ2FFbv6t-6lq91TJUVqpQeUU7dnyJ78Krr0=.3d31d979-4d49-4a7a-bb09-a8b96b6cda16@github.com> Message-ID: On Mon, 12 May 2025 21:17:10 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: > > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - Use one-step training by default in AOT testing > - Implemented JTREG=AOT_JDK=(onestep|twostep); default is onestep > - @ashu-mehra comments; renamed test to JavaAOTOptionsEnvVar.java > - @vnkozlov comments > - AOT_TOOL_OPTIONS -> JAVA_AOT_OPTIONS > - Remove %t restriction > - Added %p substitution; clean up > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 4 more: https://git.openjdk.org/jdk/compare/45dfc2c6...b044953e make/RunTests.gmk changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2834836628 From iklam at openjdk.org Tue May 13 00:01:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 00:01:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v6] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Allow one-step training even when -XX:AOTMode=auto is specified ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/b044953e..f33d5994 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=04-05 Stats: 81 lines in 3 files changed: 62 ins; 3 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Tue May 13 03:06:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 03:06:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Added param to makefile function SetupAOT for choosing onestep vs twostep ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/f33d5994..3cc2cb3a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=05-06 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iveresov at openjdk.org Tue May 13 03:31:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 03:31:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v17] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/cds/filemap.hpp Co-authored-by: Dan Heidinga ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/d75cb5dc..da4a3420 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=15-16 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iveresov at openjdk.org Tue May 13 03:34:54 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 03:34:54 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 17:13:55 GMT, Ioi Lam wrote: >> Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/hotspot/share/cds/filemap.cpp line 1955: > >> 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, >> 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); >> 1955: return false; > > The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) > > Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2085858973 From duke at openjdk.org Tue May 13 04:06:34 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Tue, 13 May 2025 04:06:34 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: > 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Update TestDockerMemoryMetricsSubgroup.java remove extra space ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24930/files - new: https://git.openjdk.org/jdk/pull/24930/files/1b131d86..ad855247 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930 PR: https://git.openjdk.org/jdk/pull/24930 From iklam at openjdk.org Tue May 13 07:36:04 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 07:36:04 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot Message-ID: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. ------------- Commit messages: - More clean up - added tests - Clean up; removed test code - step1 Changes: https://git.openjdk.org/jdk/pull/25199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356838 Stats: 147 lines in 8 files changed: 114 ins; 14 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/25199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25199/head:pull/25199 PR: https://git.openjdk.org/jdk/pull/25199 From dholmes at openjdk.org Tue May 13 07:38:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 13 May 2025 07:38:52 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> Message-ID: On Mon, 12 May 2025 21:56:46 GMT, Jiangli Zhou wrote: > The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option Interesting and very frustrating. It seems there are potentially other flags that could get passed already that would cause the same kind of failure. This really is not something that tests should need to be aware of. And to be honest the fact that -Dcompiler.jdk even exists and solves this problem is somewhat of a fortuitous accident (it was added way, way back to allow testing with JRE's that did not contain all the JDK tools). Doe a static JDK image not implicitly contain all the tools, if you invoked them directly rather than via their custom launchers? Or are they stripped out unless explicitly created as part of that image? I'm just wondering if there is a more direct way for JdkToolFinder to work with static images? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2875381470 From sjohanss at openjdk.org Tue May 13 07:41:50 2025 From: sjohanss at openjdk.org (Stefan Johansson) Date: Tue, 13 May 2025 07:41:50 GMT Subject: RFR: 8350596: [Linux] Increase default MaxRAMPercentage for containerized workloads In-Reply-To: <3zkVeUEqr_avGG1v8Q0Dp_0_FiZrXLxHJeU4KQ556sg=.77fbebb1-8bcf-40bb-95c0-664120321cbf@github.com> References: <3zkVeUEqr_avGG1v8Q0Dp_0_FiZrXLxHJeU4KQ556sg=.77fbebb1-8bcf-40bb-95c0-664120321cbf@github.com> Message-ID: On Fri, 9 May 2025 10:04:41 GMT, Severin Gehwolf wrote: > Thanks for looking at this, Stefan. > > > Thinking back to the discussions we had around this at OCW, I remember there were some concerns regarding different types of deployments. I think this really makes sense in the cases where we divide a machines memory using containers, but what if containers are just used to divide other resources. One use-case that was raised was containerized applications on Linux. > > Currently there is only the generic `is_containerized()` API which has been documented in the bug that fixed that: [JDK-8261242](https://bugs.openjdk.org/browse/JDK-8261242?focusedId=14685743&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14685743) > > So yes, this would update the RAM percentage for a) unprivileged container (no limits), b) some other container tech which sets the cgroup CPU limit for example. The JVM currently only looks at memory/cpu limits for privileged containers and takes that into consideration for `is_containerized()`. If there is consensus, we could add an API that returns true if only a memory limit is present. That doesn't exist yet, though. Happy to propose something going into that direction. The infra is already there. > This could be a good direction, we at least need some way to avoid desktop Java apps using too much memory out of the box. There was some talk about using 75% when containerized, but also looking at the machine total, so that if 75% of the container is more than 25% of the machine we fall back to 25% of the machine. For example, for an 8g container on a 16g machine, we would constrain the heap to 4g (25% of machine) rather than 6g (75% of the container). This would of course not be optimal in all situations either, but it would be a fall back to the old defaults for limit-less containers and still in some cases provide a higher default heap for memory configured container deployments. > > I'm not sure if such an application would report true for `is_containerized()`, but it would be nice to have some data around this. > > It would return true for any non-privileged container. I can see that this might be a concern. > Thanks for verifying this. > > Have you done any testing with containerized apps? > > I have done some basic testing so far, but would be happy to do more. What specific testing would you be interested in? I was mostly thinking about limitless containers (desktop apps) to see if we run into the problems of using way too much memory, but given your answer above I guess we would. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25086#issuecomment-2875389061 From iklam at openjdk.org Tue May 13 07:45:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 07:45:07 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:32:13 GMT, Igor Veresov wrote: >> src/hotspot/share/cds/filemap.cpp line 1955: >> >>> 1953: " does not equal the current SpecTrapLimitExtraEntries setting (%d).", file_type, >>> 1954: _spec_trap_limit_extra_entries, SpecTrapLimitExtraEntries); >>> 1955: return false; >> >> The `log_info(cds)` should be replaced with `MetaspaceShared::report_loading_error`. (The few `log_info` lines above this block will be fixed in [JDK-8356807](https://bugs.openjdk.org/browse/JDK-8356807)) >> >> Also, could you add a new jtreg test case for this? You can see examples in `negativeTests` in the existing AOTFlags.java test case. I think you can add your checks into the new AOTProfileFlags.java test. > > Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? You can leave the existing code and just fix the new code you added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2086143903 From heidinga at openjdk.org Tue May 13 14:15:57 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Tue, 13 May 2025 14:15:57 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v7] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 03:06:44 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Added param to makefile function SetupAOT for choosing onestep vs twostep src/java.base/share/man/java.md line 4073: > 4071: - `-XX:AOTMode=record` is specified, or > 4072: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode=auto` is specified, or > 4073: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specidied. Suggestion: - `-XX:AOTCacheOutput` is specified, and `-XX:AOTMode` is not specified. src/java.base/share/man/java.md line 4084: > 4082: - `record`: Execute the application in the Training phase. > 4083: At least one of `-XX:AOTConfiguration=`*configfile* and/or > 4084: `-XX:AOTCache=`*cachefile* must be specified. Suggestion: `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* must be specified. AOTCacheOutput is also a valid configuration for mode record, right? src/java.base/share/man/java.md line 4087: > 4085: If `-XX:AOTConfiguration=`*configfile* is specified, the JVM gathers > 4086: statistical data and stores them into *configfile*. > 4087: If `-XX:AOTCache=`*cachefile* is specified, a second JVM process is launched Suggestion: If `-XX:AOTCache=`*cachefile* or `-XX:AOTCacheOutput=`*cachefile* is specified, a second JVM process is launched ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086925261 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086929891 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2086934364 From duke at openjdk.org Tue May 13 14:48:55 2025 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 13 May 2025 14:48:55 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code The change looks good. There might be some issues with container engine version parsing. I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2876826791 From asmehra at openjdk.org Tue May 13 16:27:17 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 13 May 2025 16:27:17 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v5] In-Reply-To: References: Message-ID: <9SgUncbv-K1xeivpenkKeHg0EbjktycNXJp_ThrVfLM=.b2de51b8-468d-41bd-9173-27a22a45b32f@github.com> > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Ashutosh Mehra has updated the pull request incrementally with one additional commit since the last revision: Update test to make it more resilient Signed-off-by: Ashutosh Mehra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25019/files - new: https://git.openjdk.org/jdk/pull/25019/files/98e5fa07..c7341cde Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=03-04 Stats: 53 lines in 1 file changed: 48 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 From gziemski at openjdk.org Tue May 13 17:14:58 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 13 May 2025 17:14:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 11:21:41 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit > - fixed one case. > - test with random requests passes now. > - semantic text added. > - more tests for full coverage of update_region. > - fixes for cross-compilations > - removed print_on for release build success. > - complete code coverage for new impl. All tests pass. > - new version. All tests except one passed. > - second try > - ... and 17 more: https://git.openjdk.org/jdk/compare/90f4d0b8...043c11d6 We have a single state denoting free region currently in vmatree, i.e.`State::Released` - should we make a distinction between: never touched and free vs released and free ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2877335392 From jiangli at openjdk.org Tue May 13 17:20:52 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Tue, 13 May 2025 17:20:52 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> Message-ID: <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> On Tue, 13 May 2025 07:36:02 GMT, David Holmes wrote: > > The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option > > Interesting and very frustrating. It seems there are potentially other flags that could get passed already that would cause the same kind of failure. > > This really is not something that tests should need to be aware of. And to be honest the fact that -Dcompiler.jdk even exists and solves this problem is somewhat of a fortuitous accident (it was added way, way back to allow testing with JRE's that did not contain all the JDK tools). Hmmm, I have a different thought now after processing more on the findings/discussions. `JDKToolFinder` provides following three different methods for accessing JDK tools either from `test.jdk` or `compile.jdk` specified paths. Jtreg tests using `JDKToolFinder` directly or indirectly should be aware of how/where tools are searched. getJDKTool(String) // search `test.jdk` first then fall back to `compile.jdk` getCompileJDKTool(String) // search `compile.jdk` getTestJDKTool(String) // search `test.jdk` Generally tests don't need to provide `test.jdk` & `compile.jdk` settings when using `JDKToolFinder` since those are provided from the jtreg environment. The problem that we are facing are special cases where test-launched child processes require accessing JDK tools using `JDKToolFinder`. As the child processes don't automatically get the jtreg system properties, individual tests should pass `test.jdk` & `compile.jdk` jtreg system properties to the child process if `JDKToolFinder` is used to locate JDK tools. In fact the three affected tests already pass the `test.jdk` setting to the child process. It seems reasonable to also pass the additional `compile.jdk` value as long as there's no ill effect. > > Doe a static JDK image not implicitly contain all the tools, if you invoked them directly rather than via their custom launchers? Or are they stripped out unless explicitly created as part of that image? I'm just wondering if there is a more direct way for JdkToolFinder to work with static images? Currently the tools are not yet included in static-jdk, https://bugs.openjdk.org/browse/JDK-8346719 is going to include the tools (relauncher) in static-jdk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2877356005 From gziemski at openjdk.org Tue May 13 17:27:06 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 13 May 2025 17:27:06 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 11:21:41 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit > - fixed one case. > - test with random requests passes now. > - semantic text added. > - more tests for full coverage of update_region. > - fixes for cross-compilations > - removed print_on for release build success. > - complete code coverage for new impl. All tests pass. > - new version. All tests except one passed. > - second try > - ... and 17 more: https://git.openjdk.org/jdk/compare/ee6ab6ca...043c11d6 src/hotspot/share/nmt/vmatree.cpp line 654: > 652: }); > 653: out->cr(); > 654: } I have a different `print_on` function, called `print_timeline_on` which can produce output, such as: 1 2 3 4 5 01234567890123456789012345678901234567890123456789 ..........AAAAAAAAAA..........CCCCddddEE.......... Legend: A - GC (reserved) . - free C - Test (reserved) d - Test (committed) E - Test (reserved) . - free instead of: `10 (GC) - reserved [0, --]-> 20 (Unknown) - released [2147483646, --]-> 30 (Test) - reserved [0, --]-> 34 (Test) - committed [0, 0]-> 38 (Test) - reserved [0, --]-> 40 (Unknown) - released [2147483646, --]->` for tree: VMATree tree; Tree::RegionData gc(si, mtGC); Tree::RegionData test(si, mtTest); tree.reserve_mapping(10, 10, gc); tree.reserve_mapping(30, 10, test); tree.commit_mapping(34, 4, test); Which I personally find easier to parse. If you like, we can: 1. add this function to this fix, in case others find its output useful 2. add the output generated by this function to the comments for each of the cases in test_vmatree.cpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2087318994 From asmehra at openjdk.org Tue May 13 17:48:58 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 13 May 2025 17:48:58 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v4] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 23:04:54 GMT, Vladimir Kozlov wrote: >> Ashutosh Mehra has updated the pull request incrementally with two additional commits since the last revision: >> >> - Remove more unused code >> >> Signed-off-by: Ashutosh Mehra >> - Fix whitespace issue. Remove unused code. >> >> Signed-off-by: Ashutosh Mehra > > src/hotspot/share/code/aotCodeCache.hpp line 374: > >> 372: >> 373: static bool is_dumping_stubs() NOT_CDS_RETURN_(false); >> 374: static bool is_using_stubs() NOT_CDS_RETURN_(false); > > We have singular naming (`is_dumping_stub()`) for these methods in `premain` branch. > I was debating to do separate RFE for renaming in mainline or may be you can do it here. > It is up to you. > I did not pay attention to these when I work on adapter caching. But now I have to merge from mainline to premain and I noticed difference. I will make this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2087351871 From asmehra at openjdk.org Tue May 13 18:03:09 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 13 May 2025 18:03:09 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: - Merge branch 'master' into preserve-runtime-blobs-master - Address Vladimir's comments Signed-off-by: Ashutosh Mehra - Update test to make it more resilient Signed-off-by: Ashutosh Mehra - Remove more unused code Signed-off-by: Ashutosh Mehra - Fix whitespace issue. Remove unused code. Signed-off-by: Ashutosh Mehra - Add test for using AOTCodeCache with different CompressedOops configuration Signed-off-by: Ashutosh Mehra - Add check for compressed oops base address; minor refacotring Signed-off-by: Ashutosh Mehra - Merge branch 'master' into preserve-runtime-blobs-master - Address Vladimir's comments Signed-off-by: Ashutosh Mehra - Remove irrelevant comment Signed-off-by: Ashutosh Mehra - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 ------------- Changes: https://git.openjdk.org/jdk/pull/25019/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25019&range=05 Stats: 1360 lines in 31 files changed: 1100 ins; 125 del; 135 mod Patch: https://git.openjdk.org/jdk/pull/25019.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25019/head:pull/25019 PR: https://git.openjdk.org/jdk/pull/25019 From asmehra at openjdk.org Tue May 13 18:07:59 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Tue, 13 May 2025 18:07:59 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <8W_FRkLbamdZ6l0Lkbn8WqXv_JXPjG-i5hBus2foor4=.4f80cd55-4141-46ff-8436-0cbbc9228461@github.com> Message-ID: On Mon, 12 May 2025 23:07:02 GMT, Vladimir Kozlov wrote: >>> I think for these changes we should not use AOT code when the heap base does not match. >> Something changed in compressed oops code which prevents enforcing encoding. >> We can investigate and fix it later. >> >> @vnkozlov for this PR we are relying on having relocation for COOP base, not on enforcing encoding. And that should be able to handle cases where heap base is different in assembly vs prod. Why do you suggest to not use AOT code when the heap base does not match? > > @ashu-mehra, this looks good with few comments. After you address them, please merge latest jdk - I pushed small related change to limit platforms to run with AOT. > > After that I will submit new testing. @vnkozlov addressed your comments. I also noticed the newly added test `AOTCodeCompressedOopsTest` was consistently failing on macos-aarch64 because for some reason the CompressedOops::shift=3 even for heap size as low as for Xmx128m. So I have updated the test to make it more resilient by reading the 'actual' base and shift from Xlog:cds output. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2877494411 From kvn at openjdk.org Tue May 13 20:44:56 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 13 May 2025 20:44:56 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: <4S-Dtf0DIhtmch16UNF_ZpmnEZmRG1HsHukz6WxOkvs=.2a258cbb-79ec-4531-b308-6789bdda2a52@github.com> On Tue, 13 May 2025 18:03:09 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Update test to make it more resilient > > Signed-off-by: Ashutosh Mehra > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra > - Add test for using AOTCodeCache with different CompressedOops > configuration > > Signed-off-by: Ashutosh Mehra > - Add check for compressed oops base address; minor refacotring > > Signed-off-by: Ashutosh Mehra > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 Looks good. I submitted testing. ------------- PR Review: https://git.openjdk.org/jdk/pull/25019#pullrequestreview-2838072325 From amenkov at openjdk.org Tue May 13 20:54:07 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 13 May 2025 20:54:07 GMT Subject: RFR: 8356177: Regression after JDK-8352180 Message-ID: The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. Testing: tier1..4,hs-tier5-svc ------------- Commit messages: - fix Changes: https://git.openjdk.org/jdk/pull/25219/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25219&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356177 Stats: 82 lines in 2 files changed: 78 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/25219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25219/head:pull/25219 PR: https://git.openjdk.org/jdk/pull/25219 From iveresov at openjdk.org Tue May 13 22:37:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:37:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v18] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request incrementally with 34 additional commits since the last revision: - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component Reviewed-by: alanb - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context Reviewed-by: mcimadamore - 8355992: Add unsignedMultiplyExact and *powExact methods to Math and StrictMath Reviewed-by: darcy - ... and 24 more: https://git.openjdk.org/jdk/compare/da4a3420...72030a30 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/da4a3420..72030a30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=16-17 Stats: 7451 lines in 145 files changed: 4269 ins; 1931 del; 1251 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iveresov at openjdk.org Tue May 13 22:40:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:40:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component Reviewed-by: alanb - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context Reviewed-by: mcimadamore - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18 Stats: 3330 lines in 59 files changed: 3116 ins; 100 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iveresov at openjdk.org Tue May 13 22:44:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 22:44:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v14] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 07:42:33 GMT, Ioi Lam wrote: >> Do you want me to leave the existing `log_info` alone? Or should I fix everything in `FileMapHeader::validate()` ? > > You can leave the existing code and just fix the new code you added. Done. And changed the test. Please take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087730827 From iklam at openjdk.org Tue May 13 23:15:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 23:15:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 22:40:42 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: > > - Merge branch 'master' into pp2 > - Address Ioi's comments > - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off > > Reviewed-by: vlivanov, kvn > - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing > > Reviewed-by: naoto > - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() > > Reviewed-by: wkemper > - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default > > Reviewed-by: asemenyuk > - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property > > Reviewed-by: naoto, bpb > - 8356447: Change default for EagerJVMCI to true > > Reviewed-by: yzheng, kvn, never > - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component > > Reviewed-by: alanb > - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context > > Reviewed-by: mcimadamore > - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: > 113: > 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); > 115: out.shouldContain("does not equal"); Since all the flags have `Profile` in them, I think we should use this to match the intended output: String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; out.shouldNotMatch(errorPattern); ... out.shouldMatch(errorPattern); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087753972 From iveresov at openjdk.org Tue May 13 23:15:57 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:15:57 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: References: Message-ID: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> On Tue, 13 May 2025 23:10:53 GMT, Ioi Lam wrote: >> Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 82 commits: >> >> - Merge branch 'master' into pp2 >> - Address Ioi's comments >> - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off >> >> Reviewed-by: vlivanov, kvn >> - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing >> >> Reviewed-by: naoto >> - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() >> >> Reviewed-by: wkemper >> - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default >> >> Reviewed-by: asemenyuk >> - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property >> >> Reviewed-by: naoto, bpb >> - 8356447: Change default for EagerJVMCI to true >> >> Reviewed-by: yzheng, kvn, never >> - 8351415: (fs) Path::toAbsolutePath should specify if an absolute path has a root component >> >> Reviewed-by: alanb >> - 8356551: Javac rejects receiver parameter in constructor of local class in early construction context >> >> Reviewed-by: mcimadamore >> - ... and 72 more: https://git.openjdk.org/jdk/compare/10dcdf1b...1669f900 > > test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: > >> 113: >> 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); >> 115: out.shouldContain("does not equal"); > > Since all the flags have `Profile` in them, I think we should use this to match the intended output: > > > String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; > out.shouldNotMatch(errorPattern); > ... > out.shouldMatch(errorPattern); `SpecTrapLimitExtraEntries` does not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087755889 From iveresov at openjdk.org Tue May 13 23:46:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v20] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Address Ioi's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/1669f900..fd26cfe4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=18-19 Stats: 12 lines in 1 file changed: 2 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iklam at openjdk.org Tue May 13 23:46:42 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v20] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 23:43:01 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: > > Address Ioi's comments updates are good! ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2838347038 From iveresov at openjdk.org Tue May 13 23:46:42 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 13 May 2025 23:46:42 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v19] In-Reply-To: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> References: <-Y1WtA0iFbtvlUbZSni93xpK2TnribKtD-Hfl7YVML4=.85c93976-d723-40a2-b382-238c56a57148@github.com> Message-ID: On Tue, 13 May 2025 23:13:42 GMT, Igor Veresov wrote: >> test/hotspot/jtreg/runtime/cds/appcds/aotProfile/AOTProfileFlags.java line 115: >> >>> 113: >>> 114: out = CDSTestUtils.executeAndLog(pb, "production_failure"); >>> 115: out.shouldContain("does not equal"); >> >> Since all the flags have `Profile` in them, I think we should use this to match the intended output: >> >> >> String errorPattern = "Profile.* setting .* does not equal the current .*Profile.* setting"; >> out.shouldNotMatch(errorPattern); >> ... >> out.shouldMatch(errorPattern); > > `SpecTrapLimitExtraEntries` does not. Fixed. Take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24886#discussion_r2087775255 From dholmes at openjdk.org Wed May 14 00:46:50 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 May 2025 00:46:50 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> Message-ID: <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> On Tue, 13 May 2025 17:18:36 GMT, Jiangli Zhou wrote: > As the child processes don't automatically get the jtreg system properties, individual tests should pass test.jdk & compile.jdk jtreg system properties to the child process if JDKToolFinder is used to locate JDK tools. In fact the three affected tests already pass the test.jdk setting to the child process. It seems reasonable to also pass the additional compile.jdk value as long as there's no ill effect. Yes I agree, and I apologise for the unnecessary diversion from your original proposal. This isn't really about the static-image per-se but that code using JDKToolFinder must know that that the tool finder has been configured correctly, or else do that configuration itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2878280901 From jiangli at openjdk.org Wed May 14 01:00:54 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 01:00:54 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> Message-ID: On Wed, 14 May 2025 00:43:55 GMT, David Holmes wrote: > > As the child processes don't automatically get the jtreg system properties, individual tests should pass test.jdk & compile.jdk jtreg system properties to the child process if JDKToolFinder is used to locate JDK tools. In fact the three affected tests already pass the test.jdk setting to the child process. It seems reasonable to also pass the additional compile.jdk value as long as there's no ill effect. > > Yes I agree, and I apologise for the unnecessary diversion from your original proposal. This isn't really about the static-image per-se but that code using JDKToolFinder must know that that the tool finder has been configured correctly, or else do that configuration itself. No problem at all. Thanks for thinking though all details, @dholmes-ora ! I'll refresh the PR to restore the initial version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2878320179 From jiangli at openjdk.org Wed May 14 01:49:43 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 01:49:43 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v3] In-Reply-To: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: > Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. > > These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. > > Tested all three tests on static-jdk. All three tests pass with the fix. Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: - Revert to https://github.com/openjdk/jdk/pull/25018/commits/6fd8d7ef2de6f0b4f6bed50e4255e1091834b68b. - Revert test/lib/jdk/test/lib/process/ProcessTools.java. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25018/files - new: https://git.openjdk.org/jdk/pull/25018/files/dd23d795..6b1b6871 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25018&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25018&range=01-02 Stats: 13 lines in 4 files changed: 6 ins; 4 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25018.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25018/head:pull/25018 PR: https://git.openjdk.org/jdk/pull/25018 From jiangli at openjdk.org Wed May 14 01:53:56 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 01:53:56 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> Message-ID: On Wed, 14 May 2025 00:43:55 GMT, David Holmes wrote: >>> > The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option >>> >>> Interesting and very frustrating. It seems there are potentially other flags that could get passed already that would cause the same kind of failure. >>> >>> This really is not something that tests should need to be aware of. And to be honest the fact that -Dcompiler.jdk even exists and solves this problem is somewhat of a fortuitous accident (it was added way, way back to allow testing with JRE's that did not contain all the JDK tools). >> >> Hmmm, I have a different thought now after processing more on the findings/discussions. `JDKToolFinder` provides following three different methods for accessing JDK tools either from `test.jdk` or `compile.jdk` specified paths. Jtreg tests using `JDKToolFinder` directly or indirectly should be aware of how/where tools are searched. >> >> getJDKTool(String) // search `test.jdk` first then fall back to `compile.jdk` >> getCompileJDKTool(String) // search `compile.jdk` >> getTestJDKTool(String) // search `test.jdk` >> >> >> Generally tests don't need to provide `test.jdk` & `compile.jdk` settings when using `JDKToolFinder` since those are provided from the jtreg environment. The problem that we are facing are special cases where test-launched child processes require accessing JDK tools using `JDKToolFinder`. As the child processes don't automatically get the jtreg system properties, individual tests should pass `test.jdk` & `compile.jdk` jtreg system properties to the child process if `JDKToolFinder` is used to locate JDK tools. In fact the three affected tests already pass the `test.jdk` setting to the child process. It seems reasonable to also pass the additional `compile.jdk` value as long as there's no ill effect. >> >>> >>> Doe a static JDK image not implicitly contain all the tools, if you invoked them directly rather than via their custom launchers? Or are they stripped out unless explicitly created as part of that image? I'm just wondering if there is a more direct way for JdkToolFinder to work with static images? >> >> Currently the tools are not yet included in static-jdk, https://bugs.openjdk.org/browse/JDK-8346719 is going to include the tools (relauncher) in static-jdk. > >> As the child processes don't automatically get the jtreg system properties, individual tests should pass test.jdk & compile.jdk jtreg system properties to the child process if JDKToolFinder is used to locate JDK tools. In fact the three affected tests already pass the test.jdk setting to the child process. It seems reasonable to also pass the additional compile.jdk value as long as there's no ill effect. > > Yes I agree, and I apologise for the unnecessary diversion from your original proposal. This isn't really about the static-image per-se but that code using JDKToolFinder must know that that the tool finder has been configured correctly, or else do that configuration itself. Reverted the changes to the initial version. @dholmes-ora Please help take another look, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2878393091 From dholmes at openjdk.org Wed May 14 04:02:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 14 May 2025 04:02:54 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v3] In-Reply-To: References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Wed, 14 May 2025 01:49:43 GMT, Jiangli Zhou wrote: >> Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. >> >> These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. >> >> Tested all three tests on static-jdk. All three tests pass with the fix. > > Jiangli Zhou has updated the pull request incrementally with two additional commits since the last revision: > > - Revert to https://github.com/openjdk/jdk/pull/25018/commits/6fd8d7ef2de6f0b4f6bed50e4255e1091834b68b. > - Revert test/lib/jdk/test/lib/process/ProcessTools.java. Looks good. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25018#pullrequestreview-2838651553 From iklam at openjdk.org Wed May 14 06:16:15 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 06:16:15 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/3cc2cb3a..cd7a5a6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=06-07 Stats: 748 lines in 9 files changed: 369 ins; 327 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From azafari at openjdk.org Wed May 14 08:18:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 14 May 2025 08:18:04 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 17:23:47 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit >> - fixed one case. >> - test with random requests passes now. >> - semantic text added. >> - more tests for full coverage of update_region. >> - fixes for cross-compilations >> - removed print_on for release build success. >> - complete code coverage for new impl. All tests pass. >> - new version. All tests except one passed. >> - second try >> - ... and 17 more: https://git.openjdk.org/jdk/compare/07e97161...043c11d6 > > src/hotspot/share/nmt/vmatree.cpp line 654: > >> 652: }); >> 653: out->cr(); >> 654: } > > I have a different `print_on` function, called `print_timeline_on` which can produce output, such as: > > > 1 2 3 4 5 > 01234567890123456789012345678901234567890123456789 > ..........AAAAAAAAAA..........CCCCddddEE.......... > Legend: > A - GC (reserved) > . - free > C - Test (reserved) > d - Test (committed) > E - Test (reserved) > . - free > > > instead of: > > `10 (GC) - reserved [0, --]-> 20 (Unknown) - released [2147483646, --]-> 30 (Test) - reserved [0, --]-> 34 (Test) - committed [0, 0]-> 38 (Test) - reserved [0, --]-> 40 (Unknown) - released [2147483646, --]->` > > for tree: > > > VMATree tree; > Tree::RegionData gc(si, mtGC); > Tree::RegionData test(si, mtTest); > tree.reserve_mapping(10, 10, gc); > tree.reserve_mapping(30, 10, test); > tree.commit_mapping(34, 4, test); > > > Which I personally find easier to parse. > > If you like, we can: > > 1. add this function to this fix, in case others find its output useful > 2. add the output generated by this function to the comments for each of the cases in test_vmatree.cpp There are a few questions/concerns to use this new output: - the range of regions in tree may be 100-1000, then we need 1000 columns in print - not all the regions are used within that range, e.g., only 10-20 and 900-1000 are used. - when we use `print_on` for debugging a real tree, the ranges are 16 hexadecimal digits, it would be hard to show them efficiently I can add this visualization format to the test cases without changing the `print_on`. Is that OK? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2088347661 From tpushkin at openjdk.org Wed May 14 08:18:39 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 14 May 2025 08:18:39 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: Make supertype obstruction check easier to understand ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24223/files - new: https://git.openjdk.org/jdk/pull/24223/files/915987b0..a3b7dd96 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24223&range=10-11 Stats: 16 lines in 3 files changed: 3 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24223.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24223/head:pull/24223 PR: https://git.openjdk.org/jdk/pull/24223 From azafari at openjdk.org Wed May 14 08:22:04 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 14 May 2025 08:22:04 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 17:12:39 GMT, Gerard Ziemski wrote: > We have a single state denoting free region currently in vmatree, i.e.`State::Released` - should we make a distinction between: never touched and free vs released and free ? In current NMT reports, only reserved regions and committed regions inside them are printed out. If we want to distinguish `never touched` and ` released` regions, we have to track `release` operations as well. We don't keep released regions in the tree right now. I vote 'no' to adding this feature to NMT. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2879248173 From schernyshev at openjdk.org Wed May 14 09:31:53 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 14 May 2025 09:31:53 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk wrote: > I wrote 2 comments. but cold not post them. They are in "pending" state. Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? please go to `Files changed` panel and press Review Changes -> Submit review ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2879489346 From schernyshev at openjdk.org Wed May 14 09:44:52 2025 From: schernyshev at openjdk.org (Sergey Chernyshev) Date: Wed, 14 May 2025 09:44:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166: > 164: return null; > 165: } > 166: } Do you still need this method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2088524580 From tpushkin at openjdk.org Wed May 14 10:14:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Wed, 14 May 2025 10:14:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Sorry, had to pause working on this for some time because of other stuff. I believe I have addressed all the existing comments now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2879622953 From sspitsyn at openjdk.org Wed May 14 10:54:51 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 14 May 2025 10:54:51 GMT Subject: RFR: 8356177: Regression after JDK-8352180 In-Reply-To: References: Message-ID: On Tue, 13 May 2025 20:49:14 GMT, Alex Menkov wrote: > The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. > > Testing: tier1..4,hs-tier5-svc This looks good but posted one question. test/hotspot/jtreg/serviceability/attach/FailedDequeueTest.java line 64: > 62: } catch (IOException ex) { > 63: System.out.println("OK: setFlag thrown expected exception:"); > 64: ex.printStackTrace(System.out); Nit: If an `IOException` is expected then should we report a test failure after the line 61 in a case `IOException` was not thrown? ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2839712737 PR Review Comment: https://git.openjdk.org/jdk/pull/25219#discussion_r2088653595 From azafari at openjdk.org Wed May 14 13:28:02 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 14 May 2025 13:28:02 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker Message-ID: Renamed usage of 'category' for 'MemTag' cases. ------------- Commit messages: - 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker Changes: https://git.openjdk.org/jdk/pull/25226/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25226&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353444 Stats: 63 lines in 8 files changed: 0 ins; 1 del; 62 mod Patch: https://git.openjdk.org/jdk/pull/25226.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25226/head:pull/25226 PR: https://git.openjdk.org/jdk/pull/25226 From mhaessig at openjdk.org Wed May 14 14:45:04 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Wed, 14 May 2025 14:45:04 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" Message-ID: When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. ------------- Commit messages: - Add output to ease debugging, if the test fails - Fix test by searching for the beginning of a word Changes: https://git.openjdk.org/jdk/pull/25230/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356974 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230 PR: https://git.openjdk.org/jdk/pull/25230 From jiangli at openjdk.org Wed May 14 14:54:54 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 14:54:54 GMT Subject: RFR: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk [v2] In-Reply-To: <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> <9Mls_d-Hr16w_rD5htlrRDxMdm76MuLFXhFwf7b4EiY=.5d424bcd-423d-4792-b104-7b6bf34fb47c@github.com> <5e6Rka3jNXpaPy7QiQwQt_PvqQDfRNivhtNSXPa98dA=.ce34dcb3-36a5-455f-ab66-80a8d145a49a@github.com> <6FPf8-X1JjXJ-mpZgYFEov2YHuBVVXCfXBG8vAyMuk8=.152eedd0-ed16-40e4-a4a8-2f5cb6025afd@github.com> <5f7c0XdZmbIJE9cE64YZjk4NUCxeZwBdxNaj8ZNckYg=.3f3c441f-9af7-433a-9630-c08126171c06@github.com> Message-ID: On Wed, 14 May 2025 00:43:55 GMT, David Holmes wrote: >>> > The jdk/internal/misc/VM/RuntimeArguments.java test fails due the additional command-line option >>> >>> Interesting and very frustrating. It seems there are potentially other flags that could get passed already that would cause the same kind of failure. >>> >>> This really is not something that tests should need to be aware of. And to be honest the fact that -Dcompiler.jdk even exists and solves this problem is somewhat of a fortuitous accident (it was added way, way back to allow testing with JRE's that did not contain all the JDK tools). >> >> Hmmm, I have a different thought now after processing more on the findings/discussions. `JDKToolFinder` provides following three different methods for accessing JDK tools either from `test.jdk` or `compile.jdk` specified paths. Jtreg tests using `JDKToolFinder` directly or indirectly should be aware of how/where tools are searched. >> >> getJDKTool(String) // search `test.jdk` first then fall back to `compile.jdk` >> getCompileJDKTool(String) // search `compile.jdk` >> getTestJDKTool(String) // search `test.jdk` >> >> >> Generally tests don't need to provide `test.jdk` & `compile.jdk` settings when using `JDKToolFinder` since those are provided from the jtreg environment. The problem that we are facing are special cases where test-launched child processes require accessing JDK tools using `JDKToolFinder`. As the child processes don't automatically get the jtreg system properties, individual tests should pass `test.jdk` & `compile.jdk` jtreg system properties to the child process if `JDKToolFinder` is used to locate JDK tools. In fact the three affected tests already pass the `test.jdk` setting to the child process. It seems reasonable to also pass the additional `compile.jdk` value as long as there's no ill effect. >> >>> >>> Doe a static JDK image not implicitly contain all the tools, if you invoked them directly rather than via their custom launchers? Or are they stripped out unless explicitly created as part of that image? I'm just wondering if there is a more direct way for JdkToolFinder to work with static images? >> >> Currently the tools are not yet included in static-jdk, https://bugs.openjdk.org/browse/JDK-8346719 is going to include the tools (relauncher) in static-jdk. > >> As the child processes don't automatically get the jtreg system properties, individual tests should pass test.jdk & compile.jdk jtreg system properties to the child process if JDKToolFinder is used to locate JDK tools. In fact the three affected tests already pass the test.jdk setting to the child process. It seems reasonable to also pass the additional compile.jdk value as long as there's no ill effect. > > Yes I agree, and I apologise for the unnecessary diversion from your original proposal. This isn't really about the static-image per-se but that code using JDKToolFinder must know that that the tool finder has been configured correctly, or else do that configuration itself. Thanks, @dholmes-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25018#issuecomment-2880545389 From jiangli at openjdk.org Wed May 14 15:01:14 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 15:01:14 GMT Subject: Integrated: 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk In-Reply-To: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> References: <03-V87ZpTVkCg2xZN7D86a5wV2fiqSmdVCUXK3sQwaw=.2e7e5661-06f8-42ad-9732-ad0a72ae6515@github.com> Message-ID: On Fri, 2 May 2025 23:16:50 GMT, Jiangli Zhou wrote: > Please review the change to set `-Dcompile.jdk=` when launching child processes in TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests. > > These three tests fail on static-jdk as `jdk.test.lib.JDKToolFinder.getJDKTool()` fails to locate the `jcmd` tool. `JDKToolFinder.getJDKTool()` locates the requested tool from the path specified in 'test.jdk' system property first, then using the path specified in 'compile.jdk' system property. Currently when running jtreg tests on static-jdk, jtreg '-compilejdk' is set to a regular JDK binary. Populating the 'compile.jdk' system property from jtreg when creating the child process would allow `JDKToolFinder.getJDKTool()` (executing in the child process) to locate the tool from 'compile.jdk' path. > > Tested all three tests on static-jdk. All three tests pass with the fix. This pull request has now been integrated. Changeset: 1afd887b Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/1afd887b138ac2425289b6f863801774f050c23c Stats: 11 lines in 3 files changed: 6 ins; 2 del; 3 mod 8356102: TestJcmdOutput, JcmdWithNMTDisabled and DumpSharedDictionary hs/tier1 tests fail on static-jdk Reviewed-by: dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25018 From gziemski at openjdk.org Wed May 14 15:08:08 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 14 May 2025 15:08:08 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:14:47 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/vmatree.cpp line 654: >> >>> 652: }); >>> 653: out->cr(); >>> 654: } >> >> I have a different `print_on` function, called `print_timeline_on` which can produce output, such as: >> >> >> 1 2 3 4 5 >> 01234567890123456789012345678901234567890123456789 >> ..........AAAAAAAAAA..........CCCCddddEE.......... >> Legend: >> A - GC (reserved) >> . - free >> C - Test (reserved) >> d - Test (committed) >> E - Test (reserved) >> . - free >> >> >> instead of: >> >> `10 (GC) - reserved [0, --]-> 20 (Unknown) - released [2147483646, --]-> 30 (Test) - reserved [0, --]-> 34 (Test) - committed [0, 0]-> 38 (Test) - reserved [0, --]-> 40 (Unknown) - released [2147483646, --]->` >> >> for tree: >> >> >> VMATree tree; >> Tree::RegionData gc(si, mtGC); >> Tree::RegionData test(si, mtTest); >> tree.reserve_mapping(10, 10, gc); >> tree.reserve_mapping(30, 10, test); >> tree.commit_mapping(34, 4, test); >> >> >> Which I personally find easier to parse. >> >> If you like, we can: >> >> 1. add this function to this fix, in case others find its output useful >> 2. add the output generated by this function to the comments for each of the cases in test_vmatree.cpp > > There are a few questions/concerns to use this new output: > - the range of regions in tree may be 100-1000, then we need 1000 columns in print > - not all the regions are used within that range, e.g., only 10-20 and 900-1000 are used. > - when we use `print_on` for debugging a real tree, the ranges are 16 hexadecimal digits, it would be hard to show them efficiently > > I can add this visualization format to the test cases without changing the `print_on`. Is that OK? Sure, let's see it. Also, we can always change the ranges of our specific test cases to be kept [0..100] to make the print outs happy, can't we? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2089169269 From kvn at openjdk.org Wed May 14 15:10:08 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 May 2025 15:10:08 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:03:09 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Update test to make it more resilient > > Signed-off-by: Ashutosh Mehra > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra > - Add test for using AOTCodeCache with different CompressedOops > configuration > > Signed-off-by: Ashutosh Mehra > - Add check for compressed oops base address; minor refacotring > > Signed-off-by: Ashutosh Mehra > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 My testing passed. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25019#pullrequestreview-2840581163 From gziemski at openjdk.org Wed May 14 15:13:59 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 14 May 2025 15:13:59 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: <48AKWcw6hnU8p5y8PlvzaXB7KRcH412DjPateSGt6_8=.c47d3984-cfcb-4b04-98e7-839712a44b6b@github.com> On Wed, 14 May 2025 08:19:34 GMT, Afshin Zafari wrote: > > We have a single state denoting free region currently in vmatree, i.e.`State::Released` - should we make a distinction between: never touched and free vs released and free ? > > In current NMT reports, only reserved regions and committed regions inside them are printed out. If we want to distinguish `never touched` and ` released` regions, we have to track `release` operations as well. We don't keep released regions in the tree right now. I vote 'no' to adding this feature to NMT. No problem, this issue is related to the mtNone issue in my mind, i.e.: mtNone vs mtUnknown (or mtUnused) I think it would be nice to make distinction between, none never touched, and none don't care (we used it in the past, but now we don't care), but I'm not going to push for it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2880613289 From kvn at openjdk.org Wed May 14 16:08:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 14 May 2025 16:08:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: Message-ID: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> On Wed, 14 May 2025 06:16:15 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: > > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 Few comments. src/hotspot/share/cds/cds_globals.hpp line 123: > 121: product(ccstr, AOTCacheOutput, nullptr, \ > 122: "Write AOT cache into this file (overrides AOTCache when " \ > 123: "writing)") \ This looks not complete description. And "override AOTCache .." is confusing. src/hotspot/share/cds/metaspaceShared.cpp line 1150: > 1148: print_java_launcher(&ss); > 1149: const char* cmd = ss.freeze(); > 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. Was this discussed? src/hotspot/share/runtime/arguments.cpp line 3060: > 3058: } > 3059: > 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { I don't like that we pollute `Arguments` code with AOT specific flags processing. Can we move this into `CDSConfig`? Both these 2 new methods. But I will agree if you want to keep it here. It is not critical. src/java.base/share/man/java.md line 4141: > 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line > 4140: options are compatible with the AOT cache. An alternative is to run your application with > 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. `-Xlog:aot` test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > 164: "-XX:-AOTClassLinking", > 165: "-XX:AOTConfiguration=" + aotConfigFile, > 166: "-Xlog:cds=debug", `-Xlog:aot` I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2840679467 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089234532 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089261456 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089267274 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089274796 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2089279429 From iveresov at openjdk.org Wed May 14 16:13:50 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 May 2025 16:13:50 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot In-Reply-To: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: On Tue, 13 May 2025 07:30:30 GMT, Ioi Lam wrote: > When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. > > The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. > > I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. > > I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. Seems ok ------------- Marked as reviewed by iveresov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25199#pullrequestreview-2840781774 From asmehra at openjdk.org Wed May 14 16:34:55 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 14 May 2025 16:34:55 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:17:02 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - Fix win64 compile failures >> >> Signed-off-by: Ashutosh Mehra >> - Fix AOTCodeFlags.java test >> >> Signed-off-by: Ashutosh Mehra >> - Fix compile failure in minimal config >> >> Signed-off-by: Ashutosh Mehra >> - Revert back changes that added AOTRuntimeConstants. >> Ensure CompressedOops::base and CompressedKlssPointers::base does not >> change in production run >> >> Signed-off-by: Ashutosh Mehra >> - Fix merge conflicts >> >> Signed-off-by: Ashutosh Mehra >> - Store/load AsmRemarks and DbgStrings in aot code cache >> >> Signed-off-by: Ashutosh Mehra >> - Add missing external address in aarch64 >> >> Signed-off-by: Ashutosh Mehra >> - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab > > Having discussed this with @fisk it appears that the weak reference load performed by the c2i adapters will not attempt a decode. The barrier load_at method only performs a decode when the decorators include `IN_HEAP`. `resolve_weak_handle` passes in the `IN_NATIVE` decorator which implies no decode should be performed. > > So, this means we can use the adapters even if the compressed oop base differs between training run and production run. @adinn can you please review this as well? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2880863631 From asmehra at openjdk.org Wed May 14 16:39:56 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Wed, 14 May 2025 16:39:56 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: <8W_FRkLbamdZ6l0Lkbn8WqXv_JXPjG-i5hBus2foor4=.4f80cd55-4141-46ff-8436-0cbbc9228461@github.com> Message-ID: On Mon, 12 May 2025 23:07:02 GMT, Vladimir Kozlov wrote: >>> I think for these changes we should not use AOT code when the heap base does not match. >> Something changed in compressed oops code which prevents enforcing encoding. >> We can investigate and fix it later. >> >> @vnkozlov for this PR we are relying on having relocation for COOP base, not on enforcing encoding. And that should be able to handle cases where heap base is different in assembly vs prod. Why do you suggest to not use AOT code when the heap base does not match? > > @ashu-mehra, this looks good with few comments. After you address them, please merge latest jdk - I pushed small related change to limit platforms to run with AOT. > > After that I will submit new testing. @vnkozlov thank you for reviewing and testing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2880874827 From ccheung at openjdk.org Wed May 14 18:15:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 14 May 2025 18:15:55 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot In-Reply-To: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: <2-cd1TZ3tWGPF2Td41BJYR68p4DKIZvOmDWnSbNL_hA=.a3f4b7ce-3d4e-4c71-9f25-374136a34683@github.com> On Tue, 13 May 2025 07:30:30 GMT, Ioi Lam wrote: > When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. > > The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. > > I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. > > I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. Looks good. I have two comments. src/hotspot/share/classfile/classLoader.cpp line 1286: > 1284: const char* const class_name = ik->name()->as_C_string(); > 1285: const char* const file_name = file_name_for_class_name(class_name, > 1286: ik->name()->utf8_length()); Extra blank space added. test/hotspot/jtreg/runtime/cds/appcds/aotCache/AOTCacheSupportForCustomLoaders.java line 139: > 137: } > 138: if (c1.getModule() == c0.getModule()) { > 139: throw new RuntimeException("Unexpected class loader: " + c1.getClassLoader()); Should the `throw` statement be the following? `throw new RuntimeException("Unexpected module: " + c1.getModule());` ------------- PR Review: https://git.openjdk.org/jdk/pull/25199#pullrequestreview-2841072333 PR Review Comment: https://git.openjdk.org/jdk/pull/25199#discussion_r2089485297 PR Review Comment: https://git.openjdk.org/jdk/pull/25199#discussion_r2089473833 From iklam at openjdk.org Wed May 14 18:30:11 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 18:30:11 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot [v2] In-Reply-To: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: <_89jKFvSF9ScCxfnKSV86T0c93u714zuNPoRU4ng_bQ=.79ab16b7-f492-4c70-8b6d-1bf4d5b2667d@github.com> > When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. > > The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. > > I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. > > I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @calvinccheung comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25199/files - new: https://git.openjdk.org/jdk/pull/25199/files/542dc0c2..c419b4a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25199&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25199&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25199/head:pull/25199 PR: https://git.openjdk.org/jdk/pull/25199 From amenkov at openjdk.org Wed May 14 18:33:42 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 14 May 2025 18:33:42 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: > The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. > > Testing: tier1..4,hs-tier5-svc Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25219/files - new: https://git.openjdk.org/jdk/pull/25219/files/74c68070..ee6026a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25219&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25219&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25219.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25219/head:pull/25219 PR: https://git.openjdk.org/jdk/pull/25219 From ccheung at openjdk.org Wed May 14 18:34:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 14 May 2025 18:34:57 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot [v2] In-Reply-To: <_89jKFvSF9ScCxfnKSV86T0c93u714zuNPoRU4ng_bQ=.79ab16b7-f492-4c70-8b6d-1bf4d5b2667d@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> <_89jKFvSF9ScCxfnKSV86T0c93u714zuNPoRU4ng_bQ=.79ab16b7-f492-4c70-8b6d-1bf4d5b2667d@github.com> Message-ID: On Wed, 14 May 2025 18:30:11 GMT, Ioi Lam wrote: >> When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. >> >> The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. >> >> I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. >> >> I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @calvinccheung comments Marked as reviewed by ccheung (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25199#pullrequestreview-2841143335 From cjplummer at openjdk.org Wed May 14 18:44:51 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Wed, 14 May 2025 18:44:51 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov wrote: >> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Looks good. ------------- Marked as reviewed by cjplummer (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2841168920 From amenkov at openjdk.org Wed May 14 19:04:56 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Wed, 14 May 2025 19:04:56 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: <4fqz9rE_tJAI1cTGSLNrNICD9KY71P23jTqNmdIlXk0=.9bbcd940-7784-416e-8d47-95a40ce5f73f@github.com> On Wed, 14 May 2025 10:51:17 GMT, Serguei Spitsyn wrote: >> Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: >> >> feedback > > test/hotspot/jtreg/serviceability/attach/FailedDequeueTest.java line 64: > >> 62: } catch (IOException ex) { >> 63: System.out.println("OK: setFlag thrown expected exception:"); >> 64: ex.printStackTrace(System.out); > > Nit: If an `IOException` is expected then should we report a test failure after the line 61 in a case `IOException` was not thrown? Added ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25219#discussion_r2089558850 From gziemski at openjdk.org Wed May 14 19:44:07 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 14 May 2025 19:44:07 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: <1a447hHCw_0-kIv3pPHVBKNZahg2iWu-0M9qMXYV5Pw=.982d86ec-5133-4a58-a8dd-4dac53ce4388@github.com> On Mon, 12 May 2025 11:21:41 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 27 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit > - fixed one case. > - test with random requests passes now. > - semantic text added. > - more tests for full coverage of update_region. > - fixes for cross-compilations > - removed print_on for release build success. > - complete code coverage for new impl. All tests pass. > - new version. All tests except one passed. > - second try > - ... and 17 more: https://git.openjdk.org/jdk/compare/66c958b0...043c11d6 I reviewed a section of test_vmatree.cpp using my code to output the visual representation of the tree. So instead of: TEST_VM_F(NMTVMATreeTest, SummaryAccounting) { { // Fully enclosed re-reserving works correctly. Tree::RegionData rd(NCS::StackIndex(), mtTest); Tree::RegionData rd2(NCS::StackIndex(), mtNMT); Tree tree; VMATree::SummaryDiff all_diff = tree.reserve_mapping(0, 100, rd); VMATree::SingleDiff diff = all_diff.tag[NMTUtil::tag_to_index(mtTest)]; EXPECT_EQ(100, diff.reserve); all_diff = tree.reserve_mapping(50, 25, rd2); diff = all_diff.tag[NMTUtil::tag_to_index(mtTest)]; VMATree::SingleDiff diff2 = all_diff.tag[NMTUtil::tag_to_index(mtNMT)]; EXPECT_EQ(-25, diff.reserve); EXPECT_EQ(25, diff2.reserve); } I have: TEST_VM_F(NMTVMATreeTest, SummaryAccounting) { { // Fully enclosed re-reserving works correctly. Tree::RegionData rd(NCS::StackIndex(), mtTest); Tree::RegionData rd2(NCS::StackIndex(), mtNMT); Tree tree; VMATree::SummaryDiff all_diff = tree.reserve_mapping(0, 100, rd); // 1 2 3 4 5 6 7 8 9 10 11 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 // AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA.......... // Legend: // A - Test (reserved) // . - free VMATree::SingleDiff diff = all_diff.tag[NMTUtil::tag_to_index(mtTest)]; EXPECT_EQ(100, diff.reserve); all_diff = tree.reserve_mapping(50, 25, rd2); // 1 2 3 4 5 6 7 8 9 10 11 // 01234567890123456789012345678901234567890123456789012345678901234567890123456789012345678901234567890123456789 // AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAABBBBBBBBBBBBBBBBBBBBBBBBBCCCCCCCCCCCCCCCCCCCCCCCCC.......... // Legend: // A - Test (reserved) // B - Native Memory Tracking (reserved) // C - Test (reserved) // . - free diff = all_diff.tag[NMTUtil::tag_to_index(mtTest)]; VMATree::SingleDiff diff2 = all_diff.tag[NMTUtil::tag_to_index(mtNMT)]; EXPECT_EQ(-25, diff.reserve); EXPECT_EQ(25, diff2.reserve); } To help me with the review. I will be doing this to all the cases eventually, it just helps me visualize what's going on... Here is a diff file, in case you would like to apply such comments to all of the TEST_VM_F(NMTVMATreeTest, SummaryAccounting): [gerards_patch.diff.zip](https://github.com/user-attachments/files/20213445/gerards_patch.diff.zip) ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2881356093 From jiangli at openjdk.org Wed May 14 21:25:30 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Wed, 14 May 2025 21:25:30 GMT Subject: RFR: 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk Message-ID: Please review this PR for skipping runtime/jni/CalleeSavedRegisters/FPRegs.java on static-jdk. FPRegs.java uses a native test launcher executable (`exeFPRegs`) and has a similar situation as the tests described in [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276) and [JDK-8356904](https://bugs.openjdk.org/browse/JDK-8356904), although `exeFPRegs` doesn't have an explicit build-time created dependency on libjvm.so (i.e. linking against libjvm explicitly). FPRegs.java at runtime needs to find libjvm.so and pass it to the native launcher executable for creating the VM. Please see discussions on supporting custom launcher on static JDK in https://github.com/openjdk/jdk/pull/24103 review comments. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. ------------- Commit messages: - Update copyright year. - Add `@requires !jdk.static` to test/hotspot/jtreg/runtime/jni/CalleeSavedRegisters/FPRegs.java. Changes: https://git.openjdk.org/jdk/pull/25239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356892 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25239/head:pull/25239 PR: https://git.openjdk.org/jdk/pull/25239 From iklam at openjdk.org Wed May 14 21:38:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 21:38:01 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: <13z4Kl2z8Qz0d0NKNyx7gqZiQmfzBFcM6duqVyy2v5A=.877f712a-ad71-4d85-92f6-28c678425d22@github.com> On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841568752 From iklam at openjdk.org Wed May 14 21:38:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 21:38:02 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 10:12:11 GMT, Timofei Pushkin wrote: > Sorry, had to pause working on this for some time because of other stuff. > > I believe I have addressed all the existing comments now. Thanks for making the changes. Once this PR has 2 reviews and is final, I will run some tests in our test pipeline. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2881638567 From iklam at openjdk.org Wed May 14 21:44:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 21:44:38 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot [v3] In-Reply-To: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: > When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. > > The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. > > I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. > > I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. Ioi Lam 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 six additional commits since the last revision: - Merge branch 'master' into 8356838-aot-incorrectly-sets-loader-type-to-boot - @calvinccheung comments - More clean up - added tests - Clean up; removed test code - step1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25199/files - new: https://git.openjdk.org/jdk/pull/25199/files/c419b4a3..471cdafd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25199&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25199&range=01-02 Stats: 13681 lines in 477 files changed: 6318 ins; 4192 del; 3171 mod Patch: https://git.openjdk.org/jdk/pull/25199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25199/head:pull/25199 PR: https://git.openjdk.org/jdk/pull/25199 From mseledtsov at openjdk.org Wed May 14 22:25:52 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 22:25:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: On Fri, 2 May 2025 10:00:07 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Refactor container runtime version code Overall change looks good to me. Looks like this method is not in use anymore (as also noted by [sercher]), consider deleting it: private static String getDockerVersionStr() { ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2881725481 From mseledtsov at openjdk.org Wed May 14 22:44:51 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 22:44:51 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY wrote: >> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Update TestDockerMemoryMetricsSubgroup.java > > remove extra space Change looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24930#issuecomment-2881756560 From iklam at openjdk.org Wed May 14 23:14:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 23:14:09 GMT Subject: RFR: 8356838: AOT incorrectly sets a cached class's loader type to boot [v3] In-Reply-To: References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: On Wed, 14 May 2025 16:11:23 GMT, Igor Veresov wrote: >> Ioi Lam 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 six additional commits since the last revision: >> >> - Merge branch 'master' into 8356838-aot-incorrectly-sets-loader-type-to-boot >> - @calvinccheung comments >> - More clean up >> - added tests >> - Clean up; removed test code >> - step1 > > Seems ok Thanks @veresov @calvinccheung for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25199#issuecomment-2881796967 From iklam at openjdk.org Wed May 14 23:14:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 May 2025 23:14:09 GMT Subject: Integrated: 8356838: AOT incorrectly sets a cached class's loader type to boot In-Reply-To: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> References: <4mtwE4kclccCZtqkQSfsTQPWFLtvzr-CUdowWxQq6ys=.37a580f8-05ba-4dfc-a10b-c7b199300a9b@github.com> Message-ID: On Tue, 13 May 2025 07:30:30 GMT, Ioi Lam wrote: > When the AOT training run sees a class `X` loaded by a custom class loader, we should set `X`'s loader type to `unreg`. However, since [JDK-8348426](https://bugs.openjdk.org/browse/JDK-8348426), if the classfile for `X` can also be found under the module path, we will incorrectly set the loader type to `boot`. See `test3()` in the new test code. > > The fix is to check for custom class loaders in `ClassLoader::record_result()` before checking the `classpath_index`. > > I also cleaned up the code in `ClassLoader::record_result()` and `ClassLoaderExt::record_result_for_builtin_loader()` to reduce redundancy and improve readability. > > I added `AOTClassLocationConfig::print()` which can be called inside gdb for debugging purposes. This pull request has now been integrated. Changeset: 5e50a584 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/5e50a584744d316dd881c9404f75e65f31bb0e75 Stats: 146 lines in 8 files changed: 114 ins; 14 del; 18 mod 8356838: AOT incorrectly sets a cached class's loader type to boot Reviewed-by: ccheung, iveresov ------------- PR: https://git.openjdk.org/jdk/pull/25199 From ccheung at openjdk.org Wed May 14 23:29:58 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 14 May 2025 23:29:58 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Looks good. Thanks! ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24223#pullrequestreview-2841729544 From iveresov at openjdk.org Wed May 14 23:39:43 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 14 May 2025 23:39:43 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v21] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits: - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - 8356819: [macos] MacSign should use "openssl" and "faketime" from Homebrew by default Reviewed-by: asemenyuk - 8356107: [java.lang] Use @requires tag instead of exiting based on os.name or separatorChar property Reviewed-by: naoto, bpb - 8356447: Change default for EagerJVMCI to true Reviewed-by: yzheng, kvn, never - ... and 74 more: https://git.openjdk.org/jdk/compare/5e50a584...d3d51b00 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=20 Stats: 3332 lines in 59 files changed: 3118 ins; 100 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From mseledtsov at openjdk.org Wed May 14 23:49:50 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 14 May 2025 23:49:50 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v2] In-Reply-To: References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Tue, 13 May 2025 04:06:34 GMT, PAWAN CHAWDHARY wrote: >> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Update TestDockerMemoryMetricsSubgroup.java > > remove extra space Marked as reviewed by mseledtsov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2841749929 From ccheung at openjdk.org Thu May 15 00:16:32 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 00:16:32 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: References: Message-ID: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. Calvin Cheung 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: - @iklam comment - Merge branch 'master' into 8354083-add-reads - fix trailing whitespace - 8354083: Support --add-reads with -XX:+AOTClassLinking ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25109/files - new: https://git.openjdk.org/jdk/pull/25109/files/562fc591..327dc2d5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25109&range=00-01 Stats: 18384 lines in 682 files changed: 11198 ins; 4135 del; 3051 mod Patch: https://git.openjdk.org/jdk/pull/25109.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25109/head:pull/25109 PR: https://git.openjdk.org/jdk/pull/25109 From ccheung at openjdk.org Thu May 15 00:21:52 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 00:21:52 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking I have moved the three tests (AddExports.java, AddOpens.java, AddReads.java) to the `runtime/cds/appcds/aotClassLinking` directory. The AddOpens.java and AddReads.java were rewritten to make use of the `SimpleCDSAppTester` and `CDSAppTester` classes. The `TEST.groups` needs some adjustments as a result of the tests relocation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2881879075 From iklam at openjdk.org Thu May 15 02:07:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 02:07:07 GMT Subject: Withdrawn: 8355638: Allow -Xlog:aot to be used as an alias for -Xlog:cds when using AOT cache In-Reply-To: References: Message-ID: On Sat, 26 Apr 2025 05:55:34 GMT, Ioi Lam wrote: > *Specification:* > > When the JVM is started with any of the following options: AOTCache, AOTCacheOutput, AOTConfiguration, AOTMode: > > - Any `-Xlog` options that starts with the `aot` tag should also match any `LogTagSets` whose first tag is `LogTag::_cds` > - When printing a `LogTagSet` whose first tag is `LogTag::_cds`, if its `tags` decoration is to be printed, then the first tag in the decoration should be printed as `aot`. > > *Examples:* > > Control case -- this is an example of an old "cds" log. The decoration should be printed as "cds" to be backwards compatible > > $ java -Xshare:auto -Xlog:cds --version | grep trying > [0.003s][info][cds] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > "aot" can be used to select the "cds" log, but the log will be printed with "aot" as its decoration > > $ java -XX:AOTMode=auto -Xlog:aot --version | grep trying > [0.015s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, even if you specify -Xlog:cds, the output will use "aot" decoration > > $ java -XX:AOTMode=auto -Xlog:cds --version | grep tryi > [0.004s][info][aot] trying to map /jdk3/bld/vox/images/jdk/lib/server/classes.jsa > > > When using new -XX:AOT flags, error messages should be logged with "aot" decoration even when no -Xlog flags are specified > > $ java -XX:AOTMode=auto -XX:AOTCache=nofile.aot --version > [0.009s][error][aot] An error has occurred while processing the AOT cache. Run with -Xlog:aot for details. > [0.009s][error][aot] Loading AOT cache failed: nofile.aot > java 25-internal 2025-09-16 > Java(TM) SE Runtime Environment (build 25-internal-adhoc.iklam.vox) > Java HotSpot(TM) 64-Bit Server VM (build 25-internal-adhoc.iklam.vox, mixed mode) This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24895 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Update java man page - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=08 Stats: 2082 lines in 24 files changed: 1558 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Thu May 15 03:23:40 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 03:23:40 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Wed, 14 May 2025 15:38:06 GMT, Vladimir Kozlov wrote: >> Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: >> >> - java.md updates from @rose00 >> - Resolved differences with CSR JDK-8356010 > > src/hotspot/share/cds/cds_globals.hpp line 123: > >> 121: product(ccstr, AOTCacheOutput, nullptr, \ >> 122: "Write AOT cache into this file (overrides AOTCache when " \ >> 123: "writing)") \ > > This looks not complete description. And "override AOTCache .." is confusing. I changed it to "Specifies the file name for writing the AOT cache". Since the behavior is complex, I don't know how much detail I should put here. > src/hotspot/share/cds/metaspaceShared.cpp line 1150: > >> 1148: print_java_launcher(&ss); >> 1149: const char* cmd = ss.freeze(); >> 1150: tty->print_cr("Launching child process %s to assemble AOT cache %s using configuration %s", cmd, AOTCacheOutput, AOTConfiguration); > > I noticed that AOT produces outputs on TTY like this unconditionally. I think it is fine for development but for production we should use UL I think. > Was this discussed? Currently we print things that are important to the user. The other examples are: $ java -XX:AOTMode=record .... AOTConfiguration recorded: hw.aotconfig $ java -XX:AOTMode=create .... Reading AOTConfiguration hw.aotconfig and writing AOTCache hw.aot AOTCache creation is complete: hw.aot 10498048 bytes I think AOT is still a new feature so a small number of TTY prints would be helpful. If people complain about the verbosity we can change them to UL logs. > src/hotspot/share/runtime/arguments.cpp line 3060: > >> 3058: } >> 3059: >> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { > > I don't like that we pollute `Arguments` code with AOT specific flags processing. > Can we move this into `CDSConfig`? Both these 2 new methods. > > But I will agree if you want to keep it here. It is not critical. These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. > src/java.base/share/man/java.md line 4141: > >> 4139: mode should be used only as a "fail-fast" debugging aid to check if your command-line >> 4140: options are compatible with the AOT cache. An alternative is to run your application with >> 4141: `-XX:AOTMode=auto -Xlog:cds,aot` to see if the AOT cache can be used or not. > > `-Xlog:aot` `-Xlog:cds,aot` is correct for the current state of this PR. I'll change it after JDK-8356595 is integrated into the mainline. > test/hotspot/jtreg/runtime/cds/appcds/aotFlags/AOTFlags.java line 166: > >> 164: "-XX:-AOTClassLinking", >> 165: "-XX:AOTConfiguration=" + aotConfigFile, >> 166: "-Xlog:cds=debug", > > `-Xlog:aot` > I assume JDK-8356595: "Convert -Xlog:cds to -Xlog:aot " will be pushed first. `-Xlog:cds=debug` is correct for the current state of this PR (otherwise the test will fail). I'll change it after JDK-8356595 is integrated into the mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133925 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133649 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133612 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133585 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090133557 From kvn at openjdk.org Thu May 15 03:36:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:36:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v8] In-Reply-To: References: <2gn7SekvlmULcWgKYlo53IKbh8NdBpV0JfGTMc7SsHY=.02f6f7f2-3e30-4e8a-8d14-f187cc2d3c11@github.com> Message-ID: On Thu, 15 May 2025 03:15:23 GMT, Ioi Lam wrote: >> src/hotspot/share/runtime/arguments.cpp line 3060: >> >>> 3058: } >>> 3059: >>> 3060: static JavaVMOption* get_last_aotmode_arg(const JavaVMInitArgs* args) { >> >> I don't like that we pollute `Arguments` code with AOT specific flags processing. >> Can we move this into `CDSConfig`? Both these 2 new methods. >> >> But I will agree if you want to keep it here. It is not critical. > > These two functions are for parsing `JDK_AOT_VM_OPTIONS`, so I think they belong to arguments.cpp. cdsConfig.cpp is a consumer of the options parsed by arguments.cpp. okay ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2090168858 From kvn at openjdk.org Thu May 15 03:40:55 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 03:40:55 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b Looks good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2842120535 From iklam at openjdk.org Thu May 15 04:20:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 15 May 2025 04:20:51 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2842162246 From tpushkin at openjdk.org Thu May 15 06:45:54 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Thu, 15 May 2025 06:45:54 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Thank you! > Once this PR has 2 reviews and is final, I will run some tests in our test pipeline. @iklam It is final, please run the tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2882738562 From duke at openjdk.org Thu May 15 07:25:05 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 07:25:05 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows Message-ID: This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. Tested in tiers 1-3. A separate test added. ------------- Commit messages: - 8350869: Fixed whitespaces - 8350869: Added releasing of handles - Merge remote-tracking branch 'origin/master' into JDK-8350869 - 8350869: More work on test. - Merge remote-tracking branch 'origin/master' into JDK-8350869 - 8350869: More work - 8350869: Added handling of symlink on windows when loading a class. Changes: https://git.openjdk.org/jdk/pull/25233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350869 Stats: 176 lines in 2 files changed: 174 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From dholmes at openjdk.org Thu May 15 07:35:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 07:35:53 GMT Subject: RFR: 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk In-Reply-To: References: Message-ID: <2mk5HeF80Oix4rfLCvlxcuIK6Hr-t1H-xZ5RFfxj9Vw=.a4b1bc9e-83fe-4bce-be36-5bb7fdf5c5ca@github.com> On Wed, 14 May 2025 21:20:52 GMT, Jiangli Zhou wrote: > Please review this PR for skipping runtime/jni/CalleeSavedRegisters/FPRegs.java on static-jdk. > > FPRegs.java uses a native test launcher executable (`exeFPRegs`) and has a similar situation as the tests described in [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276) and [JDK-8356904](https://bugs.openjdk.org/browse/JDK-8356904), although `exeFPRegs` doesn't have an explicit build-time created dependency on libjvm.so (i.e. linking against libjvm explicitly). FPRegs.java at runtime needs to find libjvm.so and pass it to the native launcher executable for creating the VM. Please see discussions on supporting custom launcher on static JDK in https://github.com/openjdk/jdk/pull/24103 review comments. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. Ok ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25239#pullrequestreview-2842587602 From azafari at openjdk.org Thu May 15 08:28:51 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 15 May 2025 08:28:51 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v26] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Gerard's patch. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/043c11d6..e4bac73f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=24-25 Stats: 92 lines in 1 file changed: 79 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From dholmes at openjdk.org Thu May 15 08:52:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 08:52:56 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:54:48 GMT, Anton Artemov wrote: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. I've taken a first pass through this - disclaimer I don't know these Windows API's nor in general how to deal with symlinks. I have a lot of style issues that need correcting, but also an issue with error handling. Thanks. src/hotspot/os/windows/os_windows.cpp line 4614: > 4612: > 4613: // This method checks if a wide path is actually a symbolic link > 4614: static bool is_symbolic_link(const wchar_t* wide_path) This is a `bool` function but you also set `errno` upon errors - how will anyone know that an error occurred? src/hotspot/os/windows/os_windows.cpp line 4615: > 4613: // This method checks if a wide path is actually a symbolic link > 4614: static bool is_symbolic_link(const wchar_t* wide_path) > 4615: { Suggestion: static bool is_symbolic_link(const wchar_t* wide_path) { Hotspot-style says the { goes on the same line as the function declaration. src/hotspot/os/windows/os_windows.cpp line 4619: > 4617: HANDLE f = ::FindFirstFileW(wide_path, &fd); > 4618: const bool result = fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT && fd.dwReserved0 == IO_REPARSE_TAG_SYMLINK; > 4619: if (0 == ::FindClose(f)) { ```style-nit suggestion if (::FindClose(f) == 0) { src/hotspot/os/windows/os_windows.cpp line 4620: > 4618: const bool result = fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT && fd.dwReserved0 == IO_REPARSE_TAG_SYMLINK; > 4619: if (0 == ::FindClose(f)) { > 4620: errno = ::GetLastError(); I had not noticed this kind of error handling before. It is not obvious that `errno` is able to accept all the values `GetLastError` may report - or perhaps more accurately that anyone checking `errno` would expect to see them. https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170 src/hotspot/os/windows/os_windows.cpp line 4628: > 4626: // This method dereferences a symbolic link > 4627: static WCHAR* get_path_to_target(const wchar_t* wide_path) > 4628: { Suggestion: static WCHAR* get_path_to_target(const wchar_t* wide_path) { src/hotspot/os/windows/os_windows.cpp line 4632: > 4630: > 4631: hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > 4632: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Suggestion: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); src/hotspot/os/windows/os_windows.cpp line 4638: > 4636: > 4637: if (target_path_size == 0) > 4638: { Suggestion: if (target_path_size == 0) { test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 68: > 66: OutputAnalyzer output = new OutputAnalyzer(pb.start()); > 67: output.shouldContain("Hello World") > 68: .shouldHaveExitValue(0); Suggestion: output.shouldContain("Hello World") .shouldHaveExitValue(0); test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 81: > 79: output = new OutputAnalyzer(pb.start()); > 80: output.shouldContain("Hello World") > 81: .shouldHaveExitValue(0); Suggestion: output.shouldContain("Hello World") .shouldHaveExitValue(0); test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 89: > 87: public static void createLinkInSeparateFolder( final String pathToFolderForSymlink, final Path target, final String className) throws IOException { > 88: File theDir = new File(pathToFolderForSymlink); > 89: if (!theDir.exists()){ Suggestion: if (!theDir.exists()) { ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2842618311 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090632317 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090522324 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090510941 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090628885 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090523005 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090518969 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090520141 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090527145 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090536089 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090536587 From shade at openjdk.org Thu May 15 08:53:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 15 May 2025 08:53:51 GMT Subject: RFR: 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk In-Reply-To: References: Message-ID: On Wed, 14 May 2025 21:20:52 GMT, Jiangli Zhou wrote: > Please review this PR for skipping runtime/jni/CalleeSavedRegisters/FPRegs.java on static-jdk. > > FPRegs.java uses a native test launcher executable (`exeFPRegs`) and has a similar situation as the tests described in [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276) and [JDK-8356904](https://bugs.openjdk.org/browse/JDK-8356904), although `exeFPRegs` doesn't have an explicit build-time created dependency on libjvm.so (i.e. linking against libjvm explicitly). FPRegs.java at runtime needs to find libjvm.so and pass it to the native launcher executable for creating the VM. Please see discussions on supporting custom launcher on static JDK in https://github.com/openjdk/jdk/pull/24103 review comments. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25239#pullrequestreview-2842834074 From azafari at openjdk.org Thu May 15 09:07:08 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 15 May 2025 09:07:08 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v27] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 30 commits: - a merge glitch - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit - Gerard's patch. - Merge remote-tracking branch 'origin/master' into _8351661_separate_call_stack_reserve_commit - fixed one case. - test with random requests passes now. - semantic text added. - more tests for full coverage of update_region. - fixes for cross-compilations - removed print_on for release build success. - ... and 20 more: https://git.openjdk.org/jdk/compare/b8d2bdb4...276c545f ------------- Changes: https://git.openjdk.org/jdk/pull/24028/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=26 Stats: 2926 lines in 5 files changed: 2709 ins; 81 del; 136 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu May 15 09:31:13 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 15 May 2025 09:31:13 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: impl of new visualization in one test case, for getting feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/276c545f..831c1159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=26-27 Stats: 43 lines in 1 file changed: 31 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu May 15 09:35:53 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 15 May 2025 09:35:53 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v25] In-Reply-To: References: Message-ID: <2TBJSut4E110bnYEi6qDCa88akIvV61PpHvMC2kzUgI=.c65223fd-1586-4169-a8e5-14694d1eec11@github.com> On Wed, 14 May 2025 15:04:58 GMT, Gerard Ziemski wrote: >> There are a few questions/concerns to use this new output: >> - the range of regions in tree may be 100-1000, then we need 1000 columns in print >> - not all the regions are used within that range, e.g., only 10-20 and 900-1000 are used. >> - when we use `print_on` for debugging a real tree, the ranges are 16 hexadecimal digits, it would be hard to show them efficiently >> >> I can add this visualization format to the test cases without changing the `print_on`. Is that OK? > > Sure, let's see it. > > Also, we can always change the ranges of our specific test cases to be kept [0..100] to make the print outs happy, can't we? In [this](https://github.com/openjdk/jdk/pull/24028/commits/831c1159e21d740f85e523ca745726ec4701f657) commit, I impl an example of the new format for one test case "SeparateStacksForCommitAndReserve". IMHO, your previous suggestion for the format ( using '*', '-', '/' for states) is more readable than this new one with letters and legend. Which one is preferred? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2090726096 From duke at openjdk.org Thu May 15 09:57:18 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 09:57:18 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v4] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Remove unused method getDockerVersionStr ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/3b18431d..61ca55ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=02-03 Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Thu May 15 09:57:19 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 09:57:19 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> References: <7ZM5FpCXNDfRwU9qCLOnve_LH-Yboa2cNjkfgWBS2OU=.30453fda-38e2-4c9c-bb37-fe1330b21a80@github.com> Message-ID: <2ipbr_eKTB9-n_iHSSim1CqnM4thc3Yv6s5XuAvAKQE=.6a26fe01-853e-41fc-9090-182560004dd2@github.com> On Wed, 14 May 2025 09:41:58 GMT, Sergey Chernyshev wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 166: > >> 164: return null; >> 165: } >> 166: } > > Do you still need this method? Removed the method ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2090785990 From duke at openjdk.org Thu May 15 09:58:52 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 09:58:52 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows In-Reply-To: References: Message-ID: On Thu, 15 May 2025 08:45:11 GMT, David Holmes wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > src/hotspot/os/windows/os_windows.cpp line 4620: > >> 4618: const bool result = fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT && fd.dwReserved0 == IO_REPARSE_TAG_SYMLINK; >> 4619: if (0 == ::FindClose(f)) { >> 4620: errno = ::GetLastError(); > > I had not noticed this kind of error handling before. It is not obvious that `errno` is able to accept all the values `GetLastError` may report - or perhaps more accurately that anyone checking `errno` would expect to see them. > > https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170 This mechanism is used throughout the entire os_windows.cpp. For instance,`os::stat()` makes a call to `::GetLastError() `and stores the result in `errno`. Same with `os::open()` In other places, where the error type is known by the programmer, there are explicit assignments to `errno ` of particular error codes. For instance in `os::realpath()`. I just followed the existing pattern. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2090788857 From alanb at openjdk.org Thu May 15 10:02:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 10:02:54 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking Update to allow --add-reads is okay, no comments from me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2883257946 From duke at openjdk.org Thu May 15 10:03:11 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 10:03:11 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v3] In-Reply-To: References: Message-ID: <1elyKkFE2sZemPibqVeEswvApPKGWXVqeEMHc4rJpds=.9fff5366-2c8c-48b1-9523-a51b7f4a52ad@github.com> On Tue, 13 May 2025 14:46:00 GMT, Ivan Bereziuk wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactor container runtime version code > > The change looks good. There might be some issues with container engine version parsing. > > I wrote 2 comments. but cold not post them. They are in "pending" state. > Not sure why. Should the comments be first reviewed by {Committers|Reviewers}? @Domest0s I have tested against both docker and podman version and it was able to parse for eg `docker version 20.10.0` and `podman version 4.9.4-rhel` ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2883250455 From duke at openjdk.org Thu May 15 10:03:11 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 15 May 2025 10:03:11 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: Remove unused import ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/61ca55ee..b3ccffd7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From sspitsyn at openjdk.org Thu May 15 11:17:59 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Thu, 15 May 2025 11:17:59 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov wrote: >> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Marked as reviewed by sspitsyn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2843294716 From duke at openjdk.org Thu May 15 11:47:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex Message-ID: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Added a fence in the mutex code in order to make the critical section provided by the mutex follow the roach-motel semantics. No significant performance impact observed in an extending testing. Tested in tiers 1-3. ------------- Commit messages: - 8341544: Addressed reviwers comments. - 8341544: Removed fences in handshake, addressed comment style - 8341544: Added extended comment, removed fence in HandshakeState:process_by_self - Merge remote-tracking branch 'origin/master' into JDK-8341544 - 8341544: Refactored a call to OrderAccess::fence() and added a comment. - 8341544: Does Mutex need to also add a fence() Changes: https://git.openjdk.org/jdk/pull/25033/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25033&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341544 Stats: 13 lines in 2 files changed: 13 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25033.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25033/head:pull/25033 PR: https://git.openjdk.org/jdk/pull/25033 From dholmes at openjdk.org Thu May 15 11:47:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to make the critical section provided by the mutex follow the roach-motel semantics. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. src/hotspot/share/runtime/mutex.hpp line 218: > 216: // section provided by the mutex follow the Roach-Motel semantics. Having a fence does > 217: // not have any significant impact on peformance, as this is an internal VM > 218: // mutex and is generally not in hot code parts. Suggestion: // mutex and is generally not in hot code paths. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2875914339 PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2080488521 From duke at openjdk.org Thu May 15 11:47:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Tue, 13 May 2025 10:20:46 GMT, David Holmes wrote: > As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. @dholmes-ora Each and every implementation of storeload() is either calling fence() or is calling the same method as fence(), what exactly do you mean by the missing part? > src/hotspot/share/runtime/mutex.hpp line 218: > >> 216: // section provided by the mutex follow the Roach-Motel semantics. Having a fence does >> 217: // not have any significant impact on peformance, as this is an internal VM >> 218: // mutex and is generally not in hot code parts. > > Suggestion: > > // mutex and is generally not in hot code paths. Addressed in the latest commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2876359379 PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2084093703 From eosterlund at openjdk.org Thu May 15 11:47:30 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Tue, 13 May 2025 12:43:20 GMT, Anton Artemov wrote: > As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. Pretty sure the comment that the old mutex implementation we removed had, describing the API guarantees, said the semantics was fence() lock() acquire(). Since we are putting back what used to be there - shouldn't that simply be fence()? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2876938251 From dholmes at openjdk.org Thu May 15 11:47:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Tue, 13 May 2025 15:15:45 GMT, Erik ?sterlund wrote: > > As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. > > Pretty sure the comment that the old mutex implementation we removed had, describing the API guarantees, said the semantics was fence() lock() acquire(). Since we are putting back what used to be there - shouldn't that simply be fence()? @fisk you seemed to agree with my JBS comment that what we are missing is only the storeload part of the combined "fence". The sync primitives already provide the necessary roach-motel barriers, they just lack the storeload that would provide the full "fence". The old code simply used a CAS that had "full bi-directional fence semantics" which itself implemented the lock part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2879914423 From eosterlund at openjdk.org Thu May 15 11:47:30 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Wed, 14 May 2025 11:52:58 GMT, David Holmes wrote: > > > As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. > > > > > > Pretty sure the comment that the old mutex implementation we removed had, describing the API guarantees, said the semantics was fence() lock() acquire(). Since we are putting back what used to be there - shouldn't that simply be fence()? > > > > @fisk you seemed to agree with my JBS comment that what we are missing is only the storeload part of the combined "fence". The sync primitives already provide the necessary roach-motel barriers, they just lack the storeload that would provide the full "fence". The old code simply used a CAS that had "full bi-directional fence semantics" which itself implemented the lock part. While that's true, I'm more concerned with restoring the previously documented API contract than anything else. And it said fence() lock() acquire(). ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2879934740 From dholmes at openjdk.org Thu May 15 11:47:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Wed, 14 May 2025 12:00:34 GMT, Erik ?sterlund wrote: > And it said fence() lock() acquire(). Yes though I think you are being too literal - in the old code that was all wrapped up in a single CAS. And I don't see any suggestion that we need to add an explicit `acquire()` after taking the lock because acquire semantics is known to be part of lock acquisition. At the moment the barriers on the leading edge of the actual lock() have a gap in them so currently we have `not_quite_fence(); lock(); acquire();`. After this change we will have `fence(); not_quite_fence(); lock(); acquire();`. But okay lets just make this very explicit. To be honest mixing storeload style barrier descriptions with acquire/release semantics doesn't make sense anyway. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2881501952 From duke at openjdk.org Thu May 15 11:47:31 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> Message-ID: On Mon, 12 May 2025 07:31:14 GMT, Erik ?sterlund wrote: >> Added a fence in the mutex code in order to make the critical section provided by the mutex follow the roach-motel semantics. >> >> No significant performance impact observed in an extending testing. >> >> Tested in tiers 1-3. > > src/hotspot/share/runtime/handshake.cpp line 259: > >> 257: if (UseSystemMemoryBarrier) { >> 258: SystemMemoryBarrier::emit(); >> 259: } else { > > I don't think this change should mess around with random handshaking code. This PR is concerned with fortifying the memory ordering of Mutex, which is orthogonal. I agree with this point, addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2084093316 From dholmes at openjdk.org Thu May 15 11:47:30 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:30 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Tue, 13 May 2025 12:43:20 GMT, Anton Artemov wrote: > > As per JBS comment I still think we only need to add the missing storeload part of the full-fence, to complement the existing barriers the platform sync primitives provide. > > @dholmes-ora Each and every implementation of storeload() is either calling fence() or is calling the same method as fence(), what exactly do you mean by the missing part? It may be that the implementation on most platforms is equivalent, but semantically given the memory barriers present in the native sync operations the part missing to make them perform a "full fence" is the "storeload" part. I'm not hung up on this, but it seemed from JBS that there was some agreement that we did not need an explicit orderAccess::fence to achieve the goal of having a full fence in effect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2879931323 From eosterlund at openjdk.org Thu May 15 11:47:31 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to make the critical section provided by the mutex follow the roach-motel semantics. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. src/hotspot/share/runtime/handshake.cpp line 259: > 257: if (UseSystemMemoryBarrier) { > 258: SystemMemoryBarrier::emit(); > 259: } else { I don't think this change should mess around with random handshaking code. This PR is concerned with fortifying the memory ordering of Mutex, which is orthogonal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2084012400 From coleenp at openjdk.org Thu May 15 11:47:31 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> Message-ID: <50tcmUQCVeaHYOLbfyI8jAfqDYm8lNgkurbV_5QdkNE=.95393018-e5e2-4b12-9820-65ce221394da@github.com> On Mon, 12 May 2025 08:16:38 GMT, Anton Artemov wrote: >> src/hotspot/share/runtime/handshake.cpp line 259: >> >>> 257: if (UseSystemMemoryBarrier) { >>> 258: SystemMemoryBarrier::emit(); >>> 259: } else { >> >> I don't think this change should mess around with random handshaking code. This PR is concerned with fortifying the memory ordering of Mutex, which is orthogonal. > > I agree with this point, addressed in the latest commit. Okay good, I liked those there even if they're covered by the mutex fence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2085137170 From dholmes at openjdk.org Thu May 15 11:47:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <50tcmUQCVeaHYOLbfyI8jAfqDYm8lNgkurbV_5QdkNE=.95393018-e5e2-4b12-9820-65ce221394da@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> <50tcmUQCVeaHYOLbfyI8jAfqDYm8lNgkurbV_5QdkNE=.95393018-e5e2-4b12-9820-65ce221394da@github.com> Message-ID: On Mon, 12 May 2025 17:28:23 GMT, Coleen Phillimore wrote: >> I agree with this point, addressed in the latest commit. > > Okay good, I liked those there even if they're covered by the mutex fence. I'm conflicted. One the one hand we added the fence there because of the missing fence in the mutex, so if we fix mutex we should undo what we (only recently) did. On the other hand, the lack of a fence suggests to me we really don't need the SystemMemoryBarrier either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2086442038 From dholmes at openjdk.org Thu May 15 11:47:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> <50tcmUQCVeaHYOLbfyI8jAfqDYm8lNgkurbV_5QdkNE=.95393018-e5e2-4b12-9820-65ce221394da@github.com> Message-ID: On Thu, 15 May 2025 02:21:41 GMT, David Holmes wrote: >> I'm conflicted. One the one hand we added the fence there because of the missing fence in the mutex, so if we fix mutex we should undo what we (only recently) did. On the other hand, the lack of a fence suggests to me we really don't need the SystemMemoryBarrier either. > >> the lack of a fence suggests to me we really don't need the SystemMemoryBarrier either. > > No that is my ignorance/forgetfulness about what SMB does. On the platforms that set UseSMB true, they elide barriers in other parts of the code and then use the SMB here to account for that. Thanks @pchilano for refreshing my memory here. > if we fix mutex we should undo what we (only recently) did. Okay so I understand the argument for keeping these fences. The argument is that although we only discovered the missing mutex fence because of this code, this code (the handshake protocol) requires that a fence exist and it is better to be explicit about it rather than relying on the action-at-a-distance fence buried in the mutex code. We are fixing mutex to have the full fence, not so we can undo this change, but to ensure any other code that may be unknowingly broken by the missing mutex fence is now fixed again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2090086158 From dholmes at openjdk.org Thu May 15 11:47:31 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 11:47:31 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> <9hiXaj9rt6mTm8A3Af3lWz6N9-nflZZzWzZk4eP-u2A=.833caa60-bdf4-40a4-aa5b-f1a54b30f75b@github.com> <50tcmUQCVeaHYOLbfyI8jAfqDYm8lNgkurbV_5QdkNE=.95393018-e5e2-4b12-9820-65ce221394da@github.com> Message-ID: On Tue, 13 May 2025 10:09:11 GMT, David Holmes wrote: > the lack of a fence suggests to me we really don't need the SystemMemoryBarrier either. No that is my ignorance/forgetfulness about what SMB does. On the platforms that set UseSMB true, they elide barriers in other parts of the code and then use the SMB here to account for that. Thanks @pchilano for refreshing my memory here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25033#discussion_r2090079037 From dholmes at openjdk.org Thu May 15 12:21:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 15 May 2025 12:21:52 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:55:57 GMT, Anton Artemov wrote: >> src/hotspot/os/windows/os_windows.cpp line 4620: >> >>> 4618: const bool result = fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT && fd.dwReserved0 == IO_REPARSE_TAG_SYMLINK; >>> 4619: if (0 == ::FindClose(f)) { >>> 4620: errno = ::GetLastError(); >> >> I had not noticed this kind of error handling before. It is not obvious that `errno` is able to accept all the values `GetLastError` may report - or perhaps more accurately that anyone checking `errno` would expect to see them. >> >> https://learn.microsoft.com/en-us/cpp/c-runtime-library/errno-constants?view=msvc-170 > > This mechanism is used throughout the entire os_windows.cpp. For instance,`os::stat()` makes a call to `::GetLastError() `and stores the result in `errno`. Same with `os::open()` In other places, where the error type is known by the programmer, there are explicit assignments to `errno ` of particular error codes. For instance in `os::realpath()`. I just followed the existing pattern. Yes I can see you followed what already existed in a three places, but my concern is that the existing pattern is actually incorrect. As I said I had not noticed this usage before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091044524 From duke at openjdk.org Thu May 15 13:05:47 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 13:05:47 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v2] In-Reply-To: References: Message-ID: <8-3pY6Fvug5AkmCKQ2W-VdUdeeiQtQ-Z9C8a6SzDtoY=.25c6b2e3-e9c1-4312-82b6-68a609c382fe@github.com> > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8350869: Addressed reviewer's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25233/files - new: https://git.openjdk.org/jdk/pull/25233/files/5e2b9ac8..64d1f384 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=00-01 Stats: 31 lines in 2 files changed: 6 ins; 11 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From duke at openjdk.org Thu May 15 13:05:50 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 13:05:50 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v2] In-Reply-To: References: Message-ID: <5QP8mhN8sUHd0hx5inHiirKHtztrrfp5FvNi38e9Rww=.f58fa70b-07d5-4f51-afea-b77afd2bf5a4@github.com> On Thu, 15 May 2025 07:50:28 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments. > > src/hotspot/os/windows/os_windows.cpp line 4615: > >> 4613: // This method checks if a wide path is actually a symbolic link >> 4614: static bool is_symbolic_link(const wchar_t* wide_path) >> 4615: { > > Suggestion: > > static bool is_symbolic_link(const wchar_t* wide_path) { > > Hotspot-style says the { goes on the same line as the function declaration. Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4619: > >> 4617: HANDLE f = ::FindFirstFileW(wide_path, &fd); >> 4618: const bool result = fd.dwFileAttributes & FILE_ATTRIBUTE_REPARSE_POINT && fd.dwReserved0 == IO_REPARSE_TAG_SYMLINK; >> 4619: if (0 == ::FindClose(f)) { > > ```style-nit suggestion > if (::FindClose(f) == 0) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4632: > >> 4630: >> 4631: hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, >> 4632: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); > > Suggestion: > > HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Addressed in the latest commit. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 68: > >> 66: OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> 67: output.shouldContain("Hello World") >> 68: .shouldHaveExitValue(0); > > Suggestion: > > output.shouldContain("Hello World") > .shouldHaveExitValue(0); Addressed in the latest commit. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 81: > >> 79: output = new OutputAnalyzer(pb.start()); >> 80: output.shouldContain("Hello World") >> 81: .shouldHaveExitValue(0); > > Suggestion: > > output.shouldContain("Hello World") > .shouldHaveExitValue(0); Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091122419 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091121979 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091122129 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091122658 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091122814 From erikj at openjdk.org Thu May 15 13:06:59 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Thu, 15 May 2025 13:06:59 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v9] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 03:23:40 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JAVA_AOT_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> Picked up JAVA_TOOL_OPTIONS: -Djava.class.path=HelloWorld.jar -XX:AOTCacheOutput=foo.aot -XX:AOTConfiguration=foo.aot.config -XX:AOTMode=create >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - java.md updates from @rose00 > - Resolved differences with CSR JDK-8356010 > - Added param to makefile function SetupAOT for choosing onestep vs twostep > - Allow one-step training even when -XX:AOTMode=auto is specified > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - Update java man page > - ... and 12 more: https://git.openjdk.org/jdk/compare/5e50a584...7f4c0e8b doc/testing.md line 619: > 617: run existing jtreg test cases in a special "AOT_JDK" mode. Example: > 618: > 619: Is this extra newline intentional? doc/testing.md line 629: > 627: these classes (such as pre-linked lambda expressions, execution profiles, and pre-generated native code) > 628: are stored into an AOT cache file, which will be used by all the JVMs launched by the selected jtreg > 629: test cases. Some of these lines are >80 chars. Can you try to format line lengths in this file to stay under where reasonably feasible? It's ok if long markups such as links go over, just try to keep the normal text adhering to this. doc/testing.md line 640: > 638: Also, test cases that were written specifically to test AOT, such as the tests > 639: under [test/hotspot/jtreg/runtime/cds](../test/hotspot/jtreg/runtime/cds/), cannot > 640: be execute with the AOT_JDK mode. Suggestion: be executed with the AOT_JDK mode. doc/testing.md line 642: > 640: be execute with the AOT_JDK mode. > 641: > 642: Valid values for `AOT_JDK` are `one_step` and `two_step`. These control how Looks like the values are `onestep` and `twostep` in the makefile. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091117516 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091125422 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091121317 PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2091122470 From duke at openjdk.org Thu May 15 13:33:03 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 13:33:03 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v2] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 07:50:46 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments. > > src/hotspot/os/windows/os_windows.cpp line 4628: > >> 4626: // This method dereferences a symbolic link >> 4627: static WCHAR* get_path_to_target(const wchar_t* wide_path) >> 4628: { > > Suggestion: > > static WCHAR* get_path_to_target(const wchar_t* wide_path) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4638: > >> 4636: >> 4637: if (target_path_size == 0) >> 4638: { > > Suggestion: > > if (target_path_size == 0) { Addressed in the latest commmit. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 89: > >> 87: public static void createLinkInSeparateFolder( final String pathToFolderForSymlink, final Path target, final String className) throws IOException { >> 88: File theDir = new File(pathToFolderForSymlink); >> 89: if (!theDir.exists()){ > > Suggestion: > > if (!theDir.exists()) { Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091181371 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091180762 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091181892 From duke at openjdk.org Thu May 15 13:38:20 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 13:38:20 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: References: Message-ID: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8350869: Addressed reviewer's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25233/files - new: https://git.openjdk.org/jdk/pull/25233/files/64d1f384..5cf7f9ee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From duke at openjdk.org Thu May 15 13:41:56 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 13:41:56 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 08:47:02 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments > > src/hotspot/os/windows/os_windows.cpp line 4614: > >> 4612: >> 4613: // This method checks if a wide path is actually a symbolic link >> 4614: static bool is_symbolic_link(const wchar_t* wide_path) > > This is a `bool` function but you also set `errno` upon errors - how will anyone know that an error occurred? I verified, one does not have to set `errno` here, as in both use cases of `is_symbolic_link()` the further code in os::stat() and os::open() checks a return value of a corresponding method and returns -1 in case of a problem. By this one knows that something went wrong. In this particular place one only needs to close a search handle by calling `FindClose()`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091201158 From duke at openjdk.org Thu May 15 14:08:04 2025 From: duke at openjdk.org (duke) Date: Thu, 15 May 2025 14:08:04 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand @TimPushkin Your change (at version a3b7dd962a0b5ee32395c2b08232bf1cbd0ef0f9) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2883940576 From duke at openjdk.org Thu May 15 14:11:55 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 15 May 2025 14:11:55 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 13:39:19 GMT, Anton Artemov wrote: >> src/hotspot/os/windows/os_windows.cpp line 4614: >> >>> 4612: >>> 4613: // This method checks if a wide path is actually a symbolic link >>> 4614: static bool is_symbolic_link(const wchar_t* wide_path) >> >> This is a `bool` function but you also set `errno` upon errors - how will anyone know that an error occurred? > > I verified, one does not have to set `errno` here, as in both use cases of `is_symbolic_link()` the further code in `os::stat()` and `os::open()` checks a return value of a corresponding method and returns -1 in case of a problem. By this one knows that something went wrong. > > In this particular place one only needs to close a search handle by calling `FindClose()`. The only explicit way how to notify about the error I found is like this: `log_info(os)("CreateFileMapping() failed: GetLastError->%ld.", GetLastError());` Then one would not presumably need to set `errno`. The question is rather if we want to see this message or just rely on the existing logic. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2091266994 From jiangli at openjdk.org Thu May 15 14:42:59 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 14:42:59 GMT Subject: RFR: 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk In-Reply-To: <2mk5HeF80Oix4rfLCvlxcuIK6Hr-t1H-xZ5RFfxj9Vw=.a4b1bc9e-83fe-4bce-be36-5bb7fdf5c5ca@github.com> References: <2mk5HeF80Oix4rfLCvlxcuIK6Hr-t1H-xZ5RFfxj9Vw=.a4b1bc9e-83fe-4bce-be36-5bb7fdf5c5ca@github.com> Message-ID: On Thu, 15 May 2025 07:33:43 GMT, David Holmes wrote: >> Please review this PR for skipping runtime/jni/CalleeSavedRegisters/FPRegs.java on static-jdk. >> >> FPRegs.java uses a native test launcher executable (`exeFPRegs`) and has a similar situation as the tests described in [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276) and [JDK-8356904](https://bugs.openjdk.org/browse/JDK-8356904), although `exeFPRegs` doesn't have an explicit build-time created dependency on libjvm.so (i.e. linking against libjvm explicitly). FPRegs.java at runtime needs to find libjvm.so and pass it to the native launcher executable for creating the VM. Please see discussions on supporting custom launcher on static JDK in https://github.com/openjdk/jdk/pull/24103 review comments. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. > > Ok @dholmes-ora @shipilev Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25239#issuecomment-2884067858 From jiangli at openjdk.org Thu May 15 14:43:00 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 15 May 2025 14:43:00 GMT Subject: Integrated: 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk In-Reply-To: References: Message-ID: On Wed, 14 May 2025 21:20:52 GMT, Jiangli Zhou wrote: > Please review this PR for skipping runtime/jni/CalleeSavedRegisters/FPRegs.java on static-jdk. > > FPRegs.java uses a native test launcher executable (`exeFPRegs`) and has a similar situation as the tests described in [JDK-8352276](https://bugs.openjdk.org/browse/JDK-8352276) and [JDK-8356904](https://bugs.openjdk.org/browse/JDK-8356904), although `exeFPRegs` doesn't have an explicit build-time created dependency on libjvm.so (i.e. linking against libjvm explicitly). FPRegs.java at runtime needs to find libjvm.so and pass it to the native launcher executable for creating the VM. Please see discussions on supporting custom launcher on static JDK in https://github.com/openjdk/jdk/pull/24103 review comments. [JDK-8352305](https://bugs.openjdk.org/browse/JDK-8352305) will add tests using custom launcher executable on static JDK. This pull request has now been integrated. Changeset: 073af3bb Author: Jiangli Zhou URL: https://git.openjdk.org/jdk/commit/073af3bbaa3ee81b693136b2de7fee407d8ae04b Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8356892: runtime/jni/CalleeSavedRegisters/FPRegs.java fails on static-jdk Reviewed-by: dholmes, shade ------------- PR: https://git.openjdk.org/jdk/pull/25239 From adinn at openjdk.org Thu May 15 15:22:00 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 15 May 2025 15:22:00 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> On Tue, 13 May 2025 18:03:09 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Update test to make it more resilient > > Signed-off-by: Ashutosh Mehra > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra > - Add test for using AOTCodeCache with different CompressedOops > configuration > > Signed-off-by: Ashutosh Mehra > - Add check for compressed oops base address; minor refacotring > > Signed-off-by: Ashutosh Mehra > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2188: > 2186: #endif > 2187: const char* name = SharedRuntime::stub_name(SharedStubId::deopt_id); > 2188: CodeBlob* blob = AOTCodeCache::load_code_blob(AOTCodeEntry::SharedBlob, (uint)SharedStubId::deopt_id, name); For most shared blobs we have a single entry at offset 0. However, for the deopt blob we have 3 (or 5) extra entry points which are embedded in the deopt blob as field values. Saving and restoring the blob internal state removes the need to pass a count and array of entry offsets into load_code_blob and store_code_blob at this point. That makes we wonder if we need to do the same with AdapterBlob. If we embedded the offsets that are currently stored in AdapterHandlerEntry into AdapterBlob then we could also avoid having to explicitly pass the count and array of offsets at AOT load/store for adapters. The getters in AdapterHandlerEntry could fetch them indirectly or else the entry could cache them locally when it is initialized depending on whether we care about a memory indirection. Maybe this would make things more uniform? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091438273 From asmehra at openjdk.org Thu May 15 15:33:57 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 15 May 2025 15:33:57 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> References: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> Message-ID: On Thu, 15 May 2025 15:19:30 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Update test to make it more resilient >> >> Signed-off-by: Ashutosh Mehra >> - Remove more unused code >> >> Signed-off-by: Ashutosh Mehra >> - Fix whitespace issue. Remove unused code. >> >> Signed-off-by: Ashutosh Mehra >> - Add test for using AOTCodeCache with different CompressedOops >> configuration >> >> Signed-off-by: Ashutosh Mehra >> - Add check for compressed oops base address; minor refacotring >> >> Signed-off-by: Ashutosh Mehra >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 > > src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2188: > >> 2186: #endif >> 2187: const char* name = SharedRuntime::stub_name(SharedStubId::deopt_id); >> 2188: CodeBlob* blob = AOTCodeCache::load_code_blob(AOTCodeEntry::SharedBlob, (uint)SharedStubId::deopt_id, name); > > For most shared blobs we have a single entry at offset 0. However, for the deopt blob we have 3 (or 5) extra entry points which are embedded in the deopt blob as field values. Saving and restoring the blob internal state removes the need to pass a count and array of entry offsets into load_code_blob and store_code_blob at this point. > That makes we wonder if we need to do the same with AdapterBlob. If we embedded the offsets that are currently stored in AdapterHandlerEntry into AdapterBlob then we could also avoid having to explicitly pass the count and array of offsets at AOT load/store for adapters. The getters in AdapterHandlerEntry could fetch them indirectly or else the entry could cache them locally when it is initialized depending on whether we care about a memory indirection. Maybe this would make things more uniform? yup, I agree and I have the similar idea of storing entry points in AdapterBlob just like DeoptimizationBlob. Currently the pointer to AdapterBlob is not maintained anywhere. So the AdapterHandlerEntry would also have to maintain pointer to AdapterBlob. I was actually wondering if we can eliminate AdapterHandlerEntry by also storing AdapterFingerprint in the AdapterBlob. The Method can then have a pointer to AdapterBlob. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091465626 From mseledtsov at openjdk.org Thu May 15 15:48:52 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Thu, 15 May 2025 15:48:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import Marked as reviewed by mseledtsov (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844233145 From asmehra at openjdk.org Thu May 15 15:50:01 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 15 May 2025 15:50:01 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> Message-ID: On Thu, 15 May 2025 15:31:34 GMT, Ashutosh Mehra wrote: >> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2188: >> >>> 2186: #endif >>> 2187: const char* name = SharedRuntime::stub_name(SharedStubId::deopt_id); >>> 2188: CodeBlob* blob = AOTCodeCache::load_code_blob(AOTCodeEntry::SharedBlob, (uint)SharedStubId::deopt_id, name); >> >> For most shared blobs we have a single entry at offset 0. However, for the deopt blob we have 3 (or 5) extra entry points which are embedded in the deopt blob as field values. Saving and restoring the blob internal state removes the need to pass a count and array of entry offsets into load_code_blob and store_code_blob at this point. >> That makes we wonder if we need to do the same with AdapterBlob. If we embedded the offsets that are currently stored in AdapterHandlerEntry into AdapterBlob then we could also avoid having to explicitly pass the count and array of offsets at AOT load/store for adapters. The getters in AdapterHandlerEntry could fetch them indirectly or else the entry could cache them locally when it is initialized depending on whether we care about a memory indirection. Maybe this would make things more uniform? > > yup, I agree and I have the similar idea of storing entry points in AdapterBlob just like DeoptimizationBlob. Currently the pointer to AdapterBlob is not maintained anywhere. So the AdapterHandlerEntry would also have to maintain pointer to AdapterBlob. > I was actually wondering if we can eliminate AdapterHandlerEntry by also storing AdapterFingerprint in the AdapterBlob. The Method can then have a pointer to AdapterBlob. I will open an RFE to move entry points to AdapterBlob. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091498971 From kvn at openjdk.org Thu May 15 15:55:57 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Thu, 15 May 2025 15:55:57 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> Message-ID: On Thu, 15 May 2025 15:47:38 GMT, Ashutosh Mehra wrote: >> yup, I agree and I have the similar idea of storing entry points in AdapterBlob just like DeoptimizationBlob. Currently the pointer to AdapterBlob is not maintained anywhere. So the AdapterHandlerEntry would also have to maintain pointer to AdapterBlob. >> I was actually wondering if we can eliminate AdapterHandlerEntry by also storing AdapterFingerprint in the AdapterBlob. The Method can then have a pointer to AdapterBlob. > > I will open an RFE to move entry points to AdapterBlob. Yes, let's do that in follow up RFE. @adinn can you approve current changes so we can proceed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091509067 From lmesnik at openjdk.org Thu May 15 16:29:13 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 May 2025 16:29:13 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 10:03:11 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import Changes requested by lmesnik (Reviewer). test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73: > 71: return; > 72: } > 73: if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) { Better to replace this with `isContainerVersionSupported()` ... and implement all logic in the the ContainerRuntimeVersionTestUtils test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38: > 36: private final int micro; > 37: private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0); > 38: public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0); Please add comment about meaning of the version or even better rename DOCKER_MINIMAL_SUPPORTED_VERSION = .... test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53: > 51: } else if (this.major < other.major) { > 52: return -1; > 53: } else { // equal major no need to add `else {` here test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58: > 56: } else if (this.minor < other.minor) { > 57: return -1; > 58: } else { // equal majors and minors no need to add `else {` here test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81: > 79: } catch (Exception e) { > 80: System.out.println("Failed to parse container runtime version: " + version); > 81: return DEFAULT; Any reason to don't fail here? test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94: > 92: } catch (Exception e) { > 93: System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null"); > 94: return null; Any reason to don't fail here? ------------- PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2844326936 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091561369 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091564985 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555059 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091555200 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091567641 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2091566692 From lmesnik at openjdk.org Thu May 15 16:34:02 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 May 2025 16:34:02 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov wrote: >> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback Test looks good ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25219#pullrequestreview-2844363722 From adinn at openjdk.org Thu May 15 16:39:58 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 15 May 2025 16:39:58 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: On Tue, 13 May 2025 18:03:09 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Update test to make it more resilient > > Signed-off-by: Ashutosh Mehra > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra > - Add test for using AOTCodeCache with different CompressedOops > configuration > > Signed-off-by: Ashutosh Mehra > - Add check for compressed oops base address; minor refacotring > > Signed-off-by: Ashutosh Mehra > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 I looked through everything and could not spot any issues other than moving the adapter offsets into the blob. If we do decide to change that it can wait until we fold in the StubGen stub save/restore -- where we will need to save the blob plus extra info about the stubs within the blob and offsets to oner more entries within each stub. We will also eventually need to clean up registration of stub entry addresses in the address table but that has to wait until I have completed implementing generator code to produce an enum that identifies all generated entries. So I think this is ok to go in for now. ------------- Marked as reviewed by adinn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25019#pullrequestreview-2844379139 From jlahoda at openjdk.org Thu May 15 16:48:35 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 15 May 2025 16:48:35 GMT Subject: RFR: 8357016: Candidate main methods not computed properly Message-ID: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> A consider class like this: public class TwoMains { private static void main(String... args) {} static void main() { System.out.println("Should be called, but is not."); } } The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. Something similar happens if the return type is not `void`. This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). ------------- Commit messages: - 8357016: Candidate main methods not computed properly Changes: https://git.openjdk.org/jdk/pull/25256/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357016 Stats: 129 lines in 8 files changed: 103 ins; 10 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From adinn at openjdk.org Thu May 15 17:17:00 2025 From: adinn at openjdk.org (Andrew Dinn) Date: Thu, 15 May 2025 17:17:00 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: <78E_Q21KGNiVZ1EC_AeoZQYufPqYWnWkHJSoptXBnMY=.c2287602-9a6d-4ff1-9e47-297a11f82d46@github.com> Message-ID: <_MoyQbxwWIB15xC3tli43tJzruGl1QriOkfaBrjYasQ=.c22e5e6a-817f-4a82-9f9b-94045762cf46@github.com> On Thu, 15 May 2025 15:52:54 GMT, Vladimir Kozlov wrote: >> I will open an RFE to move entry points to AdapterBlob. > > Yes, let's do that in follow up RFE. > > @adinn can you approve current changes so we can proceed? Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25019#discussion_r2091645119 From asmehra at openjdk.org Thu May 15 17:22:04 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 15 May 2025 17:22:04 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v2] In-Reply-To: References: Message-ID: On Mon, 12 May 2025 15:17:02 GMT, Andrew Dinn wrote: >> Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits: >> >> - Merge branch 'master' into preserve-runtime-blobs-master >> - Address Vladimir's comments >> >> Signed-off-by: Ashutosh Mehra >> - Remove irrelevant comment >> >> Signed-off-by: Ashutosh Mehra >> - Fix win64 compile failures >> >> Signed-off-by: Ashutosh Mehra >> - Fix AOTCodeFlags.java test >> >> Signed-off-by: Ashutosh Mehra >> - Fix compile failure in minimal config >> >> Signed-off-by: Ashutosh Mehra >> - Revert back changes that added AOTRuntimeConstants. >> Ensure CompressedOops::base and CompressedKlssPointers::base does not >> change in production run >> >> Signed-off-by: Ashutosh Mehra >> - Fix merge conflicts >> >> Signed-off-by: Ashutosh Mehra >> - Store/load AsmRemarks and DbgStrings in aot code cache >> >> Signed-off-by: Ashutosh Mehra >> - Add missing external address in aarch64 >> >> Signed-off-by: Ashutosh Mehra >> - ... and 1 more: https://git.openjdk.org/jdk/compare/2a4f37cc...ba612dab > > Having discussed this with @fisk it appears that the weak reference load performed by the c2i adapters will not attempt a decode. The barrier load_at method only performs a decode when the decorators include `IN_HEAP`. `resolve_weak_handle` passes in the `IN_NATIVE` decorator which implies no decode should be performed. > > So, this means we can use the adapters even if the compressed oop base differs between training run and production run. @adinn thanks for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2884542516 From asmehra at openjdk.org Thu May 15 17:22:05 2025 From: asmehra at openjdk.org (Ashutosh Mehra) Date: Thu, 15 May 2025 17:22:05 GMT Subject: Integrated: 8354887: Preserve runtime blobs in AOT code cache In-Reply-To: References: Message-ID: On Sat, 3 May 2025 04:10:01 GMT, Ashutosh Mehra wrote: > [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. > This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. > `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. This pull request has now been integrated. Changeset: c59debb3 Author: Ashutosh Mehra URL: https://git.openjdk.org/jdk/commit/c59debb3844d009ac501a48c31822a07f00521e9 Stats: 1360 lines in 31 files changed: 1100 ins; 125 del; 135 mod 8354887: Preserve runtime blobs in AOT code cache Co-authored-by: Andrew Dinn Reviewed-by: kvn, adinn ------------- PR: https://git.openjdk.org/jdk/pull/25019 From alanb at openjdk.org Thu May 15 19:12:52 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 May 2025 19:12:52 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking [v2] In-Reply-To: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> References: <5Wenn9Nrux3bk0wWMS9skgOtd1zsHdvQjxaxLQ8gfq0=.832f371c-8131-4a8c-a961-51eb74033d4c@github.com> Message-ID: <71l9wpZh5nV-zhaS25IHhhovPGu1FqOAHBI8QUmUZhI=.f1a0620c-322a-4933-9438-ddfe1c0caa99@github.com> On Thu, 15 May 2025 00:16:32 GMT, Calvin Cheung wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > Calvin Cheung 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: > > - @iklam comment > - Merge branch 'master' into 8354083-add-reads > - fix trailing whitespace > - 8354083: Support --add-reads with -XX:+AOTClassLinking Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25109#pullrequestreview-2844740491 From amenkov at openjdk.org Thu May 15 20:43:02 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Thu, 15 May 2025 20:43:02 GMT Subject: Integrated: 8356177: Regression after JDK-8352180 In-Reply-To: References: Message-ID: <2ojKlB9PaFKSrAijSrKsQteEa_KULOmYem27EGDssJE=.dad1f09f-4b67-4451-b8a0-e95cf9737263@github.com> On Tue, 13 May 2025 20:49:14 GMT, Alex Menkov wrote: > The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. > > Testing: tier1..4,hs-tier5-svc This pull request has now been integrated. Changeset: fe790cb3 Author: Alex Menkov URL: https://git.openjdk.org/jdk/commit/fe790cb319243dc381f5f12f9010e33681ecb17a Stats: 84 lines in 2 files changed: 80 ins; 0 del; 4 mod 8356177: Regression after JDK-8352180 Reviewed-by: sspitsyn, cjplummer, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/25219 From ccheung at openjdk.org Thu May 15 21:17:03 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 21:17:03 GMT Subject: RFR: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 03:22:32 GMT, Ioi Lam wrote: >> This fix adds the `--add-reads` support for CDS and AOTClassLinking. >> Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: >> `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` >> During runtime, the archived full module graph will be disabled: >> `[0.021s][info][cds ] full module graph: disabled` >> >> With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. >> >> Testing: tiers 1 - 4. > > I think we need a test to validate that the `--add-reads` flag actually works. I wrote such a test when I implemented `--add-exports`: see [runtime/cds/appcds/jigsaw/modulepath/AddExports.java](https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/jigsaw/modulepath/AddExports.java) > > I think we need a similar test for `--add-opens` as well. > > Since the main reason for supporting `--add-{expors,opens,reads}` is for user of AOT class linking, I would suggest moving the above AddExports.java test to > > - runtime/cds/appcds/aotClassLinking/modules/AddExports.java > > And then add AddReads.java and AddOpens.java there as well. > > The reason for putting the tests inside aotClassLinking is that they will be excluded from the `hotspot_appcds_dynamic` and `hotspot_aot_classlinking` test groups, so you don't need to add special case code to handle those two test groups. Thanks @iklam @AlanBateman for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25109#issuecomment-2885067118 From ccheung at openjdk.org Thu May 15 21:17:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 15 May 2025 21:17:04 GMT Subject: Integrated: 8354083: Support --add-reads with -XX:+AOTClassLinking In-Reply-To: References: Message-ID: On Thu, 8 May 2025 00:19:17 GMT, Calvin Cheung wrote: > This fix adds the `--add-reads` support for CDS and AOTClassLinking. > Before the fix, if the `--add-reads` is specified during CDS archive dumping, the user will see the following log if `-Xlog:cds=info` is enabled: > `[0.000s][info][cds] optimized module handling: disabled due to incompatible property: jdk.module.addreads=com.norequires=org.astro` > During runtime, the archived full module graph will be disabled: > `[0.021s][info][cds ] full module graph: disabled` > > With the fix, the optimized module handling won't be disabled during dump time and the full module graph will be enabled during runtime provided the same --add-reads option is specified during dump time and runtime. > > Testing: tiers 1 - 4. This pull request has now been integrated. Changeset: efdbb6af Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/efdbb6afce4116140c066641128264ab42697912 Stats: 723 lines in 9 files changed: 443 ins; 277 del; 3 mod 8354083: Support --add-reads with -XX:+AOTClassLinking Reviewed-by: iklam, alanb ------------- PR: https://git.openjdk.org/jdk/pull/25109 From eosterlund at openjdk.org Thu May 15 21:40:54 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Thu, 15 May 2025 21:40:54 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: <0fJ2EcrKzjOTzmCp5vFSuFEh1IzPgS_0q7CPfzdiZac=.9fc06890-1d5a-49bf-8360-39994db5c25f@github.com> On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to restore the old documented semantics of fence - lock - acquire. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. Marked as reviewed by eosterlund (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25033#pullrequestreview-2845026168 From dholmes at openjdk.org Fri May 16 02:45:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 May 2025 02:45:53 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to restore the old documented semantics of fence - lock - acquire. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. Marked as reviewed by dholmes (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25033#pullrequestreview-2845369104 From dholmes at openjdk.org Fri May 16 04:26:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 May 2025 04:26:03 GMT Subject: RFR: 8354887: Preserve runtime blobs in AOT code cache [v6] In-Reply-To: References: Message-ID: <_7agKJ0ZAVaeBPGTHIK4jVbE8TX5TCeh2ZVAEu63CYI=.fa7dd58d-6dc6-41ef-a839-0133265d2339@github.com> On Tue, 13 May 2025 18:03:09 GMT, Ashutosh Mehra wrote: >> [8350209](https://bugs.openjdk.org/browse/JDK-8350209) introduced the framework for storing code in aot code cache and used it for caching i2c/c2i adapters. >> This PR extends the `AOTCodeCache` infrastructure and stores various runtime blobs (shared blobs, C1 and C2 runtime blobs) in the AOT code cache. It adds a new diagnostic flag `AOTStubCaching` to enable/disable the caching of these blobs. >> `AOTCodeFlags.java` test is extended to cover `AOTStubCaching`. > > Ashutosh Mehra has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits: > > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Update test to make it more resilient > > Signed-off-by: Ashutosh Mehra > - Remove more unused code > > Signed-off-by: Ashutosh Mehra > - Fix whitespace issue. Remove unused code. > > Signed-off-by: Ashutosh Mehra > - Add test for using AOTCodeCache with different CompressedOops > configuration > > Signed-off-by: Ashutosh Mehra > - Add check for compressed oops base address; minor refacotring > > Signed-off-by: Ashutosh Mehra > - Merge branch 'master' into preserve-runtime-blobs-master > - Address Vladimir's comments > > Signed-off-by: Ashutosh Mehra > - Remove irrelevant comment > > Signed-off-by: Ashutosh Mehra > - ... and 8 more: https://git.openjdk.org/jdk/compare/d1543429...5d7c3aa0 This change has broken the Zero build - https://bugs.openjdk.org/browse/JDK-8357084 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25019#issuecomment-2885595160 From iklam at openjdk.org Fri May 16 04:38:55 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 May 2025 04:38:55 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand I have merged your PR with the latest repo and running tiers 1-4 in our CI. Waiting for the results now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2885610681 From dholmes at openjdk.org Fri May 16 06:18:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 May 2025 06:18:57 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: References: Message-ID: <1JSZ5dvXkpOcX59TXSv6nRvHmJ11fj3byKI-Viqc5rM=.e9b34db3-0240-45cc-bcb3-893352fd13a5@github.com> On Thu, 15 May 2025 13:38:20 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Addressed reviewer's comments Thanks for the updates, a number of style issues remaining, and some more error checking queries/concerns. src/hotspot/os/windows/os_windows.cpp line 4616: > 4614: static bool is_symbolic_link(const wchar_t* wide_path) { > 4615: WIN32_FIND_DATAW fd; > 4616: HANDLE f = ::FindFirstFileW(wide_path, &fd); Do you need to check for errors here? src/hotspot/os/windows/os_windows.cpp line 4625: > 4623: static WCHAR* get_path_to_target(const wchar_t* wide_path) { > 4624: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > 4625: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Suggestion: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); src/hotspot/os/windows/os_windows.cpp line 4625: > 4623: static WCHAR* get_path_to_target(const wchar_t* wide_path) { > 4624: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > 4625: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Suggestion: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Parameters should line up src/hotspot/os/windows/os_windows.cpp line 4628: > 4626: > 4627: const size_t target_path_size = ::GetFinalPathNameByHandleW(hFile, nullptr, 0, > 4628: FILE_NAME_NORMALIZED); Suggestion: const size_t target_path_size = ::GetFinalPathNameByHandleW(hFile, nullptr, 0, FILE_NAME_NORMALIZED); Or else align parameters src/hotspot/os/windows/os_windows.cpp line 4637: > 4635: WCHAR* path_to_target = NEW_C_HEAP_ARRAY(WCHAR, target_path_size + 1, mtInternal); > 4636: > 4637: ::GetFinalPathNameByHandleW(hFile, path_to_target, static_cast(target_path_size + 1), Maybe save the return value and assert it is the expected one. src/hotspot/os/windows/os_windows.cpp line 4721: > 4719: > 4720: if (is_symlink) > 4721: { Suggestion: if (is_symlink) { src/hotspot/os/windows/os_windows.cpp line 4724: > 4722: path_to_target = get_path_to_target(wide_path); > 4723: if (path_to_target == nullptr) > 4724: { Suggestion: if (path_to_target == nullptr) { src/hotspot/os/windows/os_windows.cpp line 4733: > 4731: > 4732: WIN32_FILE_ATTRIBUTE_DATA file_data;; > 4733: BOOL bret = ::GetFileAttributesExW(is_symlink && path_to_target != nullptr ? path_to_target : wide_path, GetFileExInfoStandard, &file_data); Didn't we already return if `path_to_target` is null? src/hotspot/os/windows/os_windows.cpp line 4738: > 4736: > 4737: if (!bret) { > 4738: errno = ::GetLastError(); Pre-existing but `GetLastError` could have been reset by the time we get here depending on what is inside `os::free`. src/hotspot/os/windows/os_windows.cpp line 4931: > 4929: > 4930: if (is_symlink) > 4931: { Suggestion: if (is_symlink) { src/hotspot/os/windows/os_windows.cpp line 4934: > 4932: path_to_target = get_path_to_target(wide_path); > 4933: if (path_to_target == nullptr) > 4934: { Suggestion: if (path_to_target == nullptr) { src/hotspot/os/windows/os_windows.cpp line 4947: > 4945: > 4946: if (fd == -1) { > 4947: errno = ::GetLastError(); Again `GetLastError` may have been reset test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 67: > 65: OutputAnalyzer output = new OutputAnalyzer(pb.start()); > 66: output.shouldContain("Hello World") > 67: .shouldHaveExitValue(0); Style nit: The dots should align test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 67: > 65: OutputAnalyzer output = new OutputAnalyzer(pb.start()); > 66: output.shouldContain("Hello World") > 67: .shouldHaveExitValue(0); Please align dots on chained invocations. Thanks test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 80: > 78: output = new OutputAnalyzer(pb.start()); > 79: output.shouldContain("Hello World") > 80: .shouldHaveExitValue(0); Style nit: The dots should align ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2845575955 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092380983 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092376411 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092381874 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092382518 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092386369 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092386979 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092387226 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092388895 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092392278 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092392674 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092392964 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092393514 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092378056 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092394571 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092378608 From dholmes at openjdk.org Fri May 16 06:18:57 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 May 2025 06:18:57 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: References: Message-ID: <8fS-Ga5qx7EiRwZJwPu_FXjneBok4T5tmAaik_EvZmQ=.a284b12f-89f1-42ea-9604-a112a19ea260@github.com> On Thu, 15 May 2025 14:08:54 GMT, Anton Artemov wrote: >> I verified, one does not have to set `errno` here, as in both use cases of `is_symbolic_link()` the further code in `os::stat()` and `os::open()` checks a return value of a corresponding method and returns -1 in case of a problem. By this one knows that something went wrong. >> >> In this particular place one only needs to close a search handle by calling `FindClose()`. > > The only explicit way how to notify about the error I found is like this: > `log_info(os)("CreateFileMapping() failed: GetLastError->%ld.", GetLastError());` > Then one would not presumably need to set `errno`. > > The question is rather if we want to see this message or just rely on the existing logic. A log_debug to report any error would not be a bad thing IMO. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092397095 From jpai at openjdk.org Fri May 16 10:09:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:09:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). test/jdk/tools/launcher/Arrrghs.java line 607: > 605: //private method with parameter, usable method without parameter: > 606: createJar(new File("some.jar"), new File("Foo"), > 607: "private static void main(String[] args){}", Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case? test/jdk/tools/launcher/Arrrghs.java line 635: > 633: tr.contains("Error: abstract class Foo can not instantiated"); > 634: if (!tr.testStatus) > 635: System.out.println(tr); Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092758973 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092755321 From jpai at openjdk.org Fri May 16 10:13:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:13:52 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > 281: make inner class static or move inner class out to separate source file > 282: java.launcher.cls.error8=\ > 283: Error: abstract class {0} can not instantiated\n\ Nit - should this use a comma instead of the newline? src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113: > 111: # 0: string > 112: launcher.err.cant.find.main.method=\ > 113: can''t find main(String[]) or main() method in class: {0} Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092763055 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092765139 From duke at openjdk.org Fri May 16 10:21:40 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 16 May 2025 10:21:40 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v4] In-Reply-To: References: Message-ID: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8350869: Addressed reviewer's comments, added debug output. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25233/files - new: https://git.openjdk.org/jdk/pull/25233/files/5cf7f9ee..a444fa93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=02-03 Stats: 58 lines in 2 files changed: 34 ins; 9 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From duke at openjdk.org Fri May 16 10:21:42 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 16 May 2025 10:21:42 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: <1JSZ5dvXkpOcX59TXSv6nRvHmJ11fj3byKI-Viqc5rM=.e9b34db3-0240-45cc-bcb3-893352fd13a5@github.com> References: <1JSZ5dvXkpOcX59TXSv6nRvHmJ11fj3byKI-Viqc5rM=.e9b34db3-0240-45cc-bcb3-893352fd13a5@github.com> Message-ID: <8ESfGv0Drhrx1l2FppAyTuLk9eUO6PdnKh-gDOGA-y0=.91fdffb8-38c2-4c52-a15f-451ff8a37f65@github.com> On Fri, 16 May 2025 06:02:08 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments > > src/hotspot/os/windows/os_windows.cpp line 4616: > >> 4614: static bool is_symbolic_link(const wchar_t* wide_path) { >> 4615: WIN32_FIND_DATAW fd; >> 4616: HANDLE f = ::FindFirstFileW(wide_path, &fd); > > Do you need to check for errors here? Thanks for spotting this, I added error checking for every call to Windows API function. > src/hotspot/os/windows/os_windows.cpp line 4625: > >> 4623: static WCHAR* get_path_to_target(const wchar_t* wide_path) { >> 4624: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, >> 4625: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); > > Suggestion: > > HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); > > Parameters should line up Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4625: > >> 4623: static WCHAR* get_path_to_target(const wchar_t* wide_path) { >> 4624: HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, >> 4625: OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); > > Suggestion: > > HANDLE hFile = CreateFileW(wide_path, GENERIC_READ, FILE_SHARE_READ, nullptr, > OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4628: > >> 4626: >> 4627: const size_t target_path_size = ::GetFinalPathNameByHandleW(hFile, nullptr, 0, >> 4628: FILE_NAME_NORMALIZED); > > Suggestion: > > const size_t target_path_size = ::GetFinalPathNameByHandleW(hFile, nullptr, 0, FILE_NAME_NORMALIZED); > > Or else align parameters Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4637: > >> 4635: WCHAR* path_to_target = NEW_C_HEAP_ARRAY(WCHAR, target_path_size + 1, mtInternal); >> 4636: >> 4637: ::GetFinalPathNameByHandleW(hFile, path_to_target, static_cast(target_path_size + 1), > > Maybe save the return value and assert it is the expected one. We do not have an expected value here. > src/hotspot/os/windows/os_windows.cpp line 4721: > >> 4719: >> 4720: if (is_symlink) >> 4721: { > > Suggestion: > > if (is_symlink) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4724: > >> 4722: path_to_target = get_path_to_target(wide_path); >> 4723: if (path_to_target == nullptr) >> 4724: { > > Suggestion: > > if (path_to_target == nullptr) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4733: > >> 4731: >> 4732: WIN32_FILE_ATTRIBUTE_DATA file_data;; >> 4733: BOOL bret = ::GetFileAttributesExW(is_symlink && path_to_target != nullptr ? path_to_target : wide_path, GetFileExInfoStandard, &file_data); > > Didn't we already return if `path_to_target` is null? Correct, we only need to check if is_symlink is true or not. > src/hotspot/os/windows/os_windows.cpp line 4738: > >> 4736: >> 4737: if (!bret) { >> 4738: errno = ::GetLastError(); > > Pre-existing but `GetLastError` could have been reset by the time we get here depending on what is inside `os::free`. Yes, apparently one has to call `GetLastError` directly after calling the method whose errors we want to see. I addressed it in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4931: > >> 4929: >> 4930: if (is_symlink) >> 4931: { > > Suggestion: > > if (is_symlink) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4934: > >> 4932: path_to_target = get_path_to_target(wide_path); >> 4933: if (path_to_target == nullptr) >> 4934: { > > Suggestion: > > if (path_to_target == nullptr) { Addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4947: > >> 4945: >> 4946: if (fd == -1) { >> 4947: errno = ::GetLastError(); > > Again `GetLastError` may have been reset Yes, `GetLastError` should be called directly after the method whose errors we want to see. Addressed. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 67: > >> 65: OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> 66: output.shouldContain("Hello World") >> 67: .shouldHaveExitValue(0); > > Please align dots on chained invocations. Thanks Addressed in the latest commit. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 67: > >> 65: OutputAnalyzer output = new OutputAnalyzer(pb.start()); >> 66: output.shouldContain("Hello World") >> 67: .shouldHaveExitValue(0); > > Style nit: The dots should align Addressed in the latest commit. > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 80: > >> 78: output = new OutputAnalyzer(pb.start()); >> 79: output.shouldContain("Hello World") >> 80: .shouldHaveExitValue(0); > > Style nit: The dots should align Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775468 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775362 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775782 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775206 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775057 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774940 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774827 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774701 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774562 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774436 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774302 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774172 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092774006 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775677 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092775566 From jpai at openjdk.org Fri May 16 10:30:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 10:30:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794: > 792: """ > 793: public class WrongMainPrivate { > 794: private static void main(String[] args) {} Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092789314 From thartmann at openjdk.org Fri May 16 10:35:09 2025 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 May 2025 10:35:09 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Looks good to me but someone from core-libs should have a look as well. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2846233046 From jlahoda at openjdk.org Fri May 16 11:06:53 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:06:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 10:10:17 GMT, Jaikiran Pai wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > >> 281: make inner class static or move inner class out to separate source file >> 282: java.launcher.cls.error8=\ >> 283: Error: abstract class {0} can not instantiated\n\ > > Nit - should this use a comma instead of the newline? The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional. > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/launcher.properties line 113: > >> 111: # 0: string >> 112: launcher.err.cant.find.main.method=\ >> 113: can''t find main(String[]) or main() method in class: {0} > > Out of curiosity, why the double single quotes? I see it being used in other messages in this file as well, so it doesn't seem to be a typo. Pieces of text in `MessageFormat` can be quoted using `'...'`. So, a single `'` does not work, as that is considered to be part of quoting. Using `''` escapes that behavior. > test/jdk/tools/launcher/Arrrghs.java line 635: > >> 633: tr.contains("Error: abstract class Foo can not instantiated"); >> 634: if (!tr.testStatus) >> 635: System.out.println(tr); > > Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092836696 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092838074 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092835532 From duke at openjdk.org Fri May 16 11:07:54 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 16 May 2025 11:07:54 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v4] In-Reply-To: <8fS-Ga5qx7EiRwZJwPu_FXjneBok4T5tmAaik_EvZmQ=.a284b12f-89f1-42ea-9604-a112a19ea260@github.com> References: <8fS-Ga5qx7EiRwZJwPu_FXjneBok4T5tmAaik_EvZmQ=.a284b12f-89f1-42ea-9604-a112a19ea260@github.com> Message-ID: <8Vwy-33htz-48Qd07R4I-AXwz0RNpduYiCx8HOP8Kec=.d3a62400-d566-4dab-a72c-afb22033fa5c@github.com> On Fri, 16 May 2025 06:16:25 GMT, David Holmes wrote: >> The only explicit way how to notify about the error I found is like this: >> `log_info(os)("CreateFileMapping() failed: GetLastError->%ld.", GetLastError());` >> Then one would not presumably need to set `errno`. >> >> The question is rather if we want to see this message or just rely on the existing logic. > > A log_debug to report any error would not be a bad thing IMO. I added log_debug statements in all the places where we call `GetLastError`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2092838996 From jlahoda at openjdk.org Fri May 16 11:12:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:12:08 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adding tests as suggested. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/1c6a0123..a351686d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=00-01 Stats: 48 lines in 2 files changed: 48 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From jlahoda at openjdk.org Fri May 16 11:12:08 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:12:08 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 10:07:36 GMT, Jaikiran Pai wrote: >> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding tests as suggested. > > test/jdk/tools/launcher/Arrrghs.java line 607: > >> 605: //private method with parameter, usable method without parameter: >> 606: createJar(new File("some.jar"), new File("Foo"), >> 607: "private static void main(String[] args){}", > > Perhaps we should even include a instance method `private void main(String[] args) {}` to cover that case? Done: https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f > test/langtools/tools/javac/launcher/SourceLauncherTest.java line 794: > >> 792: """ >> 793: public class WrongMainPrivate { >> 794: private static void main(String[] args) {} > > Same comment as in the other place, perhaps we should include a `private void main(String[] args) {}` too? Done: https://github.com/openjdk/jdk/pull/25256/commits/a351686d1aeb7a82f52141558ca7d2590cb7689f ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844131 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092844245 From vromero at openjdk.org Fri May 16 11:25:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 May 2025 11:25:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: > 281: make inner class static or move inner class out to separate source file > 282: java.launcher.cls.error8=\ > 283: Error: abstract class {0} can not instantiated\n\ typo: can not `be` instantiated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092862512 From jpai at openjdk.org Fri May 16 11:49:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:49:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:02:54 GMT, Jan Lahoda wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 283: >> >>> 281: make inner class static or move inner class out to separate source file >>> 282: java.launcher.cls.error8=\ >>> 283: Error: abstract class {0} can not instantiated\n\ >> >> Nit - should this use a comma instead of the newline? > > The other errors here provide some advice on the second line, so I kept that pattern for this error as well. So, the newline is intentional. Sounds fine to me then. >> test/jdk/tools/launcher/Arrrghs.java line 635: >> >>> 633: tr.contains("Error: abstract class Foo can not instantiated"); >>> 634: if (!tr.testStatus) >>> 635: System.out.println(tr); >> >> Hello Jan, I think this is pre-existing, but it looks like we don't fail the test even when `tr.testStatus` indicates a failure? We seem to only write out to `System.out` and return from the test method. Am I misreading the test code? > > `tr.contains` marks the test as failing, and eventually `TestHelper.main` will fail the test. It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. Thank you for that. I didn't even realize that this was a "main()" test. I saw that there was a `@Test` annotation on these test methods and assumed it was either a testng or junit test. Turns out it's just another internal annotation of the `TestHelper`. > It is probably not how I would write the test from scratch, but re-writing an already existing test also does not seem like a good option. What you have in the current PR is fine with me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092893716 PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092892219 From jlahoda at openjdk.org Fri May 16 11:54:07 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 16 May 2025 11:54:07 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Review comment: correcting typo. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/a351686d..f63dab37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From jpai at openjdk.org Fri May 16 11:54:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:54:07 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v2] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Fri, 16 May 2025 11:12:08 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adding tests as suggested. I went through the JLS updates linked in the CSR for JEP 512 https://bugs.openjdk.org/browse/JDK-8353437. The proposed changes in this PR looks good to me. The additional test coverage being added is good too. I am not completely sure if the `Arrrghs.java` test and the `test/jdk/tools/launcher/InstanceMainTest.java` test fully cover all the scenarios of the new rules of determining a main method, but that's something that can be looked into as a separate activity. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25256#issuecomment-2886504200 From jpai at openjdk.org Fri May 16 11:57:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 16 May 2025 11:57:53 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> Message-ID: On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Review comment: correcting typo. test/jdk/tools/launcher/Arrrghs.java line 649: > 647: """); > 648: tr = doExec(javaCmd, "-jar", "some.jar"); > 649: tr.contains("Error: abstract class Foo can not instantiated"); After the latest typo fix, this check would also need an update. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25256#discussion_r2092905785 From vromero at openjdk.org Fri May 16 12:01:51 2025 From: vromero at openjdk.org (Vicente Romero) Date: Fri, 16 May 2025 12:01:51 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v3] In-Reply-To: <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> <-ixds9wuJxZnET-0HcHLy9rcYsQiDxdPsoCAxBPwKNA=.92ab285d-7b3f-4490-947a-01a0cbc10e5d@github.com> Message-ID: <9nkgB8f4tHZhM5HWcaivVzI7ibIZ0DfWlwRykr_uYrY=.8a0198cb-f35f-42ed-948d-2110a4694ef1@github.com> On Fri, 16 May 2025 11:54:07 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Review comment: correcting typo. lgtm ------------- Marked as reviewed by vromero (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2846416794 From iklam at openjdk.org Fri May 16 13:55:01 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 May 2025 13:55:01 GMT Subject: RFR: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive [v12] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 08:18:39 GMT, Timofei Pushkin wrote: >> If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. >> >> This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. > > Timofei Pushkin has updated the pull request incrementally with one additional commit since the last revision: > > Make supertype obstruction check easier to understand Tests passed. Thank you @TimPushkin for contributing this fix to OpenJDK! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24223#issuecomment-2886788769 From tpushkin at openjdk.org Fri May 16 13:55:02 2025 From: tpushkin at openjdk.org (Timofei Pushkin) Date: Fri, 16 May 2025 13:55:02 GMT Subject: Integrated: 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive In-Reply-To: References: Message-ID: <02V6k1T_kM2Aq8FAjh_iNUBd0XOytqkaR1Bk_g38iNc=.6abbc194-f49d-42de-9c96-3baf2857429f@github.com> On Tue, 25 Mar 2025 11:08:24 GMT, Timofei Pushkin wrote: > If a base class is package-private then its subclasses should have the same package name and defining class loader, otherwise `IllegalAccessError` is thrown when linking a subclass. Currently when dumping a static archive separate `URLClassLoader`s are used for each unregistered classes' source. Thus if two unregistered classes, a package-private base class and a sub class, from the same package reside in different sources `IllegalAccessError` will be thrown when linking the sub class. This can be unexpected because the app could have used a single class loader for both classes and thus not have seen the error ? see `DifferentSourcesApp.java` from this patch for an example of such app. > > This patch fixes the issue by using a single class loader for all unregistered classes. CDS does not allow classes with the same name making such solution possible. This pull request has now been integrated. Changeset: 46a12e78 Author: Timofei Pushkin Committer: Ioi Lam URL: https://git.openjdk.org/jdk/commit/46a12e781edcbe9da7bd39eb9e101fc680053cef Stats: 671 lines in 13 files changed: 486 ins; 122 del; 63 mod 8315130: java.lang.IllegalAccessError when processing classlist to create CDS archive Reviewed-by: iklam, ccheung ------------- PR: https://git.openjdk.org/jdk/pull/24223 From ccheung at openjdk.org Fri May 16 21:52:25 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 16 May 2025 21:52:25 GMT Subject: RFR: 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 Message-ID: Simple test fix to ensure the `-XX:+UnlockDiagnosticVMOptions` flag is specified before a diagnostic flag such as `-XX:+AOTAdapterCaching`. Tested with the following JDK builds on linux-x64: OpenJDK non-debug, OpenJDK debug, Oracle JDK non-debug, Oracle JDK debug. ------------- Commit messages: - 8351749: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 Changes: https://git.openjdk.org/jdk/pull/25275/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25275&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357149 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25275.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25275/head:pull/25275 PR: https://git.openjdk.org/jdk/pull/25275 From kvn at openjdk.org Fri May 16 21:59:50 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 16 May 2025 21:59:50 GMT Subject: RFR: 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 In-Reply-To: References: Message-ID: <8W8C2fmqFy-cGPWMGtMpyz9K4V_0nFw4aKMexQ2HOEY=.b75f251c-b5cf-4276-bf9e-5bc03865d106@github.com> On Fri, 16 May 2025 20:26:28 GMT, Calvin Cheung wrote: > Simple test fix to ensure the `-XX:+UnlockDiagnosticVMOptions` flag is specified before a diagnostic flag such as `-XX:+AOTAdapterCaching`. > > Tested with the following JDK builds on linux-x64: > OpenJDK non-debug, OpenJDK debug, Oracle JDK non-debug, Oracle JDK debug. Good and trivial. Thank you @calvinccheung for fixing it. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25275#pullrequestreview-2847683204 From iklam at openjdk.org Fri May 16 22:10:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 16 May 2025 22:10:50 GMT Subject: RFR: 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 20:26:28 GMT, Calvin Cheung wrote: > Simple test fix to ensure the `-XX:+UnlockDiagnosticVMOptions` flag is specified before a diagnostic flag such as `-XX:+AOTAdapterCaching`. > > Tested with the following JDK builds on linux-x64: > OpenJDK non-debug, OpenJDK debug, Oracle JDK non-debug, Oracle JDK debug. LGTM Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25275#pullrequestreview-2847695570 PR Review: https://git.openjdk.org/jdk/pull/25275#pullrequestreview-2847695761 From ccheung at openjdk.org Fri May 16 22:15:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 16 May 2025 22:15:55 GMT Subject: RFR: 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 In-Reply-To: <8W8C2fmqFy-cGPWMGtMpyz9K4V_0nFw4aKMexQ2HOEY=.b75f251c-b5cf-4276-bf9e-5bc03865d106@github.com> References: <8W8C2fmqFy-cGPWMGtMpyz9K4V_0nFw4aKMexQ2HOEY=.b75f251c-b5cf-4276-bf9e-5bc03865d106@github.com> Message-ID: On Fri, 16 May 2025 21:57:21 GMT, Vladimir Kozlov wrote: >> Simple test fix to ensure the `-XX:+UnlockDiagnosticVMOptions` flag is specified before a diagnostic flag such as `-XX:+AOTAdapterCaching`. >> >> Tested with the following JDK builds on linux-x64: >> OpenJDK non-debug, OpenJDK debug, Oracle JDK non-debug, Oracle JDK debug. > > Good and trivial. Thank you @calvinccheung for fixing it. Thanks @vnkozlov @iklam for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25275#issuecomment-2887761402 From ccheung at openjdk.org Fri May 16 22:15:55 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Fri, 16 May 2025 22:15:55 GMT Subject: Integrated: 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 In-Reply-To: References: Message-ID: On Fri, 16 May 2025 20:26:28 GMT, Calvin Cheung wrote: > Simple test fix to ensure the `-XX:+UnlockDiagnosticVMOptions` flag is specified before a diagnostic flag such as `-XX:+AOTAdapterCaching`. > > Tested with the following JDK builds on linux-x64: > OpenJDK non-debug, OpenJDK debug, Oracle JDK non-debug, Oracle JDK debug. This pull request has now been integrated. Changeset: 76570c62 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/76570c627db527f856f2394fb9ead02939eca621 Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod 8357149: Test runtime/cds/appcds/aotCode/AOTCodeFlags.java is broken after JDK-8354887 Reviewed-by: kvn, iklam ------------- PR: https://git.openjdk.org/jdk/pull/25275 From jlahoda at openjdk.org Mon May 19 03:49:20 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 03:49:20 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v4] In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: Adjusting message and tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25256/files - new: https://git.openjdk.org/jdk/pull/25256/files/f63dab37..db7e7ceb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25256&range=02-03 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25256.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25256/head:pull/25256 PR: https://git.openjdk.org/jdk/pull/25256 From jpai at openjdk.org Mon May 19 06:22:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 06:22:56 GMT Subject: RFR: 8357016: Candidate main methods not computed properly [v4] In-Reply-To: References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Mon, 19 May 2025 03:49:20 GMT, Jan Lahoda wrote: >> A consider class like this: >> >> >> public class TwoMains { >> private static void main(String... args) {} >> static void main() { >> System.out.println("Should be called, but is not."); >> } >> } >> >> >> The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. >> >> Something similar happens if the return type is not `void`. >> >> This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. >> >> It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). > > Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision: > > Adjusting message and tests. The updated changes look good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25256#pullrequestreview-2849510798 From jlahoda at openjdk.org Mon May 19 07:32:02 2025 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 May 2025 07:32:02 GMT Subject: Integrated: 8357016: Candidate main methods not computed properly In-Reply-To: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> References: <7KPGZvdkHWv28crEeL2Yjn9fTE3aUnkq7lYz6DdI7qk=.eeb1c248-dc47-4bc0-80dd-fe1471042f66@github.com> Message-ID: On Thu, 15 May 2025 16:42:48 GMT, Jan Lahoda wrote: > A consider class like this: > > > public class TwoMains { > private static void main(String... args) {} > static void main() { > System.out.println("Should be called, but is not."); > } > } > > > The `MethodFinder` will do lookup for the `main(String[])` method, and it finds one, so does not proceed with a lookup for `main()`. But then, it will check the access modifier, and will reject that method, never going back to the `main()` method. This is not what the JLS says about the lookup - the private method is not a candidate, and should be ignored. > > Something similar happens if the return type is not `void`. > > This PR is fixing that by checking whether the `main(String[])` method is usable early, and falling back to `main()` if it `main(String[])` is not usable. > > It also removes the check for the `abstract` method, as that, by itself, is not really backed by JLS, but adds a check for `abstract` class, producing a user-friendly message is trying to invoke an instance `main` method on an `abstract` class (which, obviously, cannot be instantiated). This pull request has now been integrated. Changeset: 77a3e04f Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/77a3e04ffc27554c14e3d45ba16ad0ee8f3c1eb1 Stats: 177 lines in 8 files changed: 151 ins; 10 del; 16 mod 8357016: Candidate main methods not computed properly Reviewed-by: jpai, vromero ------------- PR: https://git.openjdk.org/jdk/pull/25256 From fbredberg at openjdk.org Mon May 19 07:48:51 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 19 May 2025 07:48:51 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v5] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 22:59:51 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: > > Remove restrictive scopes src/hotspot/os/aix/os_aix.cpp line 773: > 771: } > 772: > 773: if (trials_remaining-- <= 0) { This if statement will break the loop after calling `pthread_create` four times, which is a bit confusing since `trials_remaining` was initialized to three. If you want to keep the current behavior I'd prefer if you initialize `trials_remaining` to `4` and change the if statement to `if (--trials_remaining <= 0) {` Don't forget to change all the other instances of this code in other platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2095063369 From jpai at openjdk.org Mon May 19 08:55:53 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 08:55:53 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Hello Manuel, > When passing -J-version to the patched javac, tools/launcher/ToolsOpts.java wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly The proposed change looks reasonable to me. A brief look through JEP-223 https://openjdk.org/jeps/223 suggests that a space character cannot appear in the JDK version, so this proposed change to use " -J-" won't run into the same issue as previously. The copyright year on this test will need an update. Please also add a "noreg-self" (https://openjdk.org/guide/#noreg) to the JBS issue. ------------- PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2849969430 From duke at openjdk.org Mon May 19 09:01:46 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Mon, 19 May 2025 09:01:46 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v6] In-Reply-To: References: Message-ID: > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. Yannik Stradmann 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 seven additional commits since the last revision: - Clean up initializaiton/use of trials_remaining - Merge remote-tracking branch 'upstream/master' into robust_pthread - Remove restrictive scopes - Reduce interim thread start log level to debug - Merge remote-tracking branch 'upstream/master' into robust_pthread - Fix build on Windows: Sleep() only accepts milliseconds - Exponentially delay native thread creation retries ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24682/files - new: https://git.openjdk.org/jdk/pull/24682/files/fede12c6..6d6c9f74 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24682&range=04-05 Stats: 40648 lines in 1309 files changed: 18277 ins; 15949 del; 6422 mod Patch: https://git.openjdk.org/jdk/pull/24682.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24682/head:pull/24682 PR: https://git.openjdk.org/jdk/pull/24682 From duke at openjdk.org Mon May 19 09:01:48 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Mon, 19 May 2025 09:01:48 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v5] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 07:46:20 GMT, Fredrik Bredberg wrote: >> Yannik Stradmann has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove restrictive scopes > > src/hotspot/os/aix/os_aix.cpp line 773: > >> 771: } >> 772: >> 773: if (trials_remaining-- <= 0) { > > This if statement will break the loop after calling `pthread_create` four times, which is a bit confusing since `trials_remaining` was initialized to three. > > If you want to keep the current behavior I'd prefer if you initialize `trials_remaining` to `4` and change the if statement to `if (--trials_remaining <= 0) {` > > Don't forget to change all the other instances of this code in other platforms. Thanks a lot for the review @fbredber! I have updated the PR according to your suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24682#discussion_r2095214554 From jpai at openjdk.org Mon May 19 09:13:14 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 May 2025 09:13:14 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:10:21 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thank you for the update. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25230#pullrequestreview-2850018076 From mhaessig at openjdk.org Mon May 19 09:13:14 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 09:13:14 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: Update copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25230/files - new: https://git.openjdk.org/jdk/pull/25230/files/a11ff5e5..388f3683 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25230&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25230.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25230/head:pull/25230 PR: https://git.openjdk.org/jdk/pull/25230 From mhaessig at openjdk.org Mon May 19 09:32:53 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 09:32:53 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890310647 From duke at openjdk.org Mon May 19 09:32:54 2025 From: duke at openjdk.org (duke) Date: Mon, 19 May 2025 09:32:54 GMT Subject: RFR: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" [v2] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:13:14 GMT, Manuel H?ssig wrote: >> When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: >> >> https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 >> >> This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. >> >> Testing: >> - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) >> - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing > > Manuel H?ssig has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright @mhaessig Your change (at version 388f36832198c72268a3302cacb3192e9e93cf21) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25230#issuecomment-2890316802 From dholmes at openjdk.org Mon May 19 09:35:56 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 May 2025 09:35:56 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:01:46 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 seven additional commits since the last revision: > > - Clean up initializaiton/use of trials_remaining > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Remove restrictive scopes > - Reduce interim thread start log level to debug > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries Still fine to me. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24682#pullrequestreview-2850092593 From fbredberg at openjdk.org Mon May 19 09:48:53 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Mon, 19 May 2025 09:48:53 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:01:46 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 seven additional commits since the last revision: > > - Clean up initializaiton/use of trials_remaining > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Remove restrictive scopes > - Reduce interim thread start log level to debug > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries Thanks for updates. ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/24682#pullrequestreview-2850141321 From mhaessig at openjdk.org Mon May 19 10:18:58 2025 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Mon, 19 May 2025 10:18:58 GMT Subject: Integrated: 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:40:41 GMT, Manuel H?ssig wrote: > When passing `-J-version` to the patched javac, `tools/launcher/ToolsOpts.java` wants to verify that the output corresponds to the expected version output. However, if the build id of the JDK running this test contains the substring "-J", then the test fails incorrectly at: > > https://github.com/openjdk/jdk/blob/97b0dd2167530b3d237e748cd5da0130e38e8af2/test/jdk/tools/launcher/ToolsOpts.java#L131-L134 > > This PR addresses this false positive by looking for the substring `" -J-"` instead. The preceding space to ensure that `-J` occurs at the beginning of a word as an argument would and a `-` suffix since `-J` options are always followed by a dash. Further, this PR adds a print of the output of the test result in case this condition fails, to be able to inspect what triggered the failure. > > Testing: > - [x] [Github Actions](https://github.com/mhaessig/jdk/actions/runs/15023438332) > - [x] tier1 and tier2 for Oracle supported platforms and OSs plus Oracle internal testing This pull request has now been integrated. Changeset: 36c9be70 Author: Manuel H?ssig Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/36c9be70e27eccdd2a156931fafa1f55dd3fb022 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod 8356974: tools/launcher/ToolsOpts.java fails if the build id contains "-J" Reviewed-by: jpai, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/25230 From jsjolen at openjdk.org Mon May 19 10:55:01 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 19 May 2025 10:55:01 GMT Subject: RFR: 8355608: Async UL should take the file lock of stream when outputting In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 13:01:44 GMT, Johan Sj?len wrote: > With the introduction of [JDK-8349755](https://bugs.openjdk.org/browse/JDK-8349755), it is not entirely clear any longer that the Async UL has exclusive access to the files which are being logged to in the JVM. We should take the file lock for the stream being logged to for safety's sake. > > If, for example, an unattached thread logs, then it will do so without the help of the Async UL thread. > > This is expected to very rarely, if ever, happen. Since taking an uncontested mutex is very cheap, I expect this to have a negligible performance impact. > > Testing: GHA, tier1 > > Cheers, > Johan I measured the performance on a Linux x64 build, around 60MiB/s both before and after this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24874#issuecomment-2890563174 From jsjolen at openjdk.org Mon May 19 10:55:03 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 19 May 2025 10:55:03 GMT Subject: Integrated: 8355608: Async UL should take the file lock of stream when outputting In-Reply-To: References: Message-ID: <54lEkJYAC56orvBmFRW8C7ZhZIBdUAbnBFdoq_NE2b0=.8b92935f-16f9-4d1d-8817-9bfe9251e791@github.com> On Fri, 25 Apr 2025 13:01:44 GMT, Johan Sj?len wrote: > With the introduction of [JDK-8349755](https://bugs.openjdk.org/browse/JDK-8349755), it is not entirely clear any longer that the Async UL has exclusive access to the files which are being logged to in the JVM. We should take the file lock for the stream being logged to for safety's sake. > > If, for example, an unattached thread logs, then it will do so without the help of the Async UL thread. > > This is expected to very rarely, if ever, happen. Since taking an uncontested mutex is very cheap, I expect this to have a negligible performance impact. > > Testing: GHA, tier1 > > Cheers, > Johan This pull request has now been integrated. Changeset: 7f7add1e Author: Johan Sj?len URL: https://git.openjdk.org/jdk/commit/7f7add1e56c4da18ce8fbbbf6e34e985c3054604 Stats: 5 lines in 1 file changed: 1 ins; 3 del; 1 mod 8355608: Async UL should take the file lock of stream when outputting Reviewed-by: aboldtch, iklam ------------- PR: https://git.openjdk.org/jdk/pull/24874 From dcherepanov at openjdk.org Mon May 19 11:15:11 2025 From: dcherepanov at openjdk.org (Dmitry Cherepanov) Date: Mon, 19 May 2025 11:15:11 GMT Subject: RFR: 8357244: Move class declarations from attachListener_posix.cpp to header files Message-ID: <6ParCD1eqRHVog8e3KB_kqWt6TJ3PoOWg5G5f21XZzs=.cd62ab5e-c040-4d06-b083-363e315f933a@github.com> The patch suggests moving class declarations from `attachListener_posix.cpp` to header files It's moved in `openjdk/crac` project ahead of upstream and this causes merge conflicts every time attachListener code changes (e.g. https://github.com/openjdk/crac/pull/224). It's therefore suggested that the changes are included in upstream. ------------- Commit messages: - attach listeners Changes: https://git.openjdk.org/jdk/pull/25300/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25300&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357244 Stats: 279 lines in 3 files changed: 178 ins; 101 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25300.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25300/head:pull/25300 PR: https://git.openjdk.org/jdk/pull/25300 From duke at openjdk.org Mon May 19 11:16:55 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Mon, 19 May 2025 11:16:55 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:01:46 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 seven additional commits since the last revision: > > - Clean up initializaiton/use of trials_remaining > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Remove restrictive scopes > - Reduce interim thread start log level to debug > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries Perfect, thanks a lot for your reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24682#issuecomment-2890621677 From duke at openjdk.org Mon May 19 11:16:56 2025 From: duke at openjdk.org (duke) Date: Mon, 19 May 2025 11:16:56 GMT Subject: RFR: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN [v6] In-Reply-To: References: Message-ID: On Mon, 19 May 2025 09:01:46 GMT, Yannik Stradmann wrote: >> This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. >> >> In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. >> >> The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. > > Yannik Stradmann 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 seven additional commits since the last revision: > > - Clean up initializaiton/use of trials_remaining > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Remove restrictive scopes > - Reduce interim thread start log level to debug > - Merge remote-tracking branch 'upstream/master' into robust_pthread > - Fix build on Windows: Sleep() only accepts milliseconds > - Exponentially delay native thread creation retries @ystradmann Your change (at version 6d6c9f74b490065347a51b76042e2ecd40818c72) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24682#issuecomment-2890624644 From duke at openjdk.org Mon May 19 12:06:58 2025 From: duke at openjdk.org (NeatGuyCoding) Date: Mon, 19 May 2025 12:06:58 GMT Subject: RFR: 8356177: Regression after JDK-8352180 [v2] In-Reply-To: References: Message-ID: On Wed, 14 May 2025 18:33:42 GMT, Alex Menkov wrote: >> The fix handles a special case when `AttachListener::dequeue()` fails to read/parse attach command request and 'PipeChannel' destructor is called when the current thread is `blocked`. >> >> Testing: tier1..4,hs-tier5-svc > > Alex Menkov has updated the pull request incrementally with one additional commit since the last revision: > > feedback @NeatGuyCoding ------------- PR Comment: https://git.openjdk.org/jdk/pull/25219#issuecomment-2890761017 From nbenalla at openjdk.org Mon May 19 18:11:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 19 May 2025 18:11:34 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v3] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - feedback: never bump ASM version - Update copyright years Note: any commit hashes below might be outdated due to subsequent history rewriting (e.g. git rebase). + update src/java.compiler/share/classes/javax/lang/model/SourceVersion.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/AbstractTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementKindVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScanner14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/ElementScannerPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleAnnotationValueVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleElementVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/SimpleTypeVisitorPreview.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitor14.java due to 6077665a274 + update src/java.compiler/share/classes/javax/lang/model/util/TypeKindVisitorPreview.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/jvm/ClassFile.java due to 6077665a274 + update src/jdk.compiler/share/classes/com/sun/tools/javac/processing/PrintingProcessor.java due to 6077665a274 + update test/langtools/tools/javac/api/TestGetSourceVersions.java due to 6077665a274 + update test/langtools/tools/javac/classfiles/ClassVersionChecker.java due to 6077665a274 + update test/langtools/tools/javac/options/HelpOutputColumnWidthTest.java due to 6077665a274 + update test/langtools/tools/javac/versions/Versions.java due to 6077665a274 - Update --release 25 symbol information for JDK 24 build 20 The macOS/AArch64 build 20 was taken from https://jdk.java.net/25/ - initial commit start-of-JDK-26 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=02 Stats: 1705 lines in 56 files changed: 1616 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From gziemski at openjdk.org Mon May 19 20:23:27 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Mon, 19 May 2025 20:23:27 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() Message-ID: To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock We avoid this, by printing using `UL` instead of using `tty` directly. ------------- Commit messages: - revert debug change - revert header change - convert to UL Changes: https://git.openjdk.org/jdk/pull/25308/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25308&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356233 Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/25308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25308/head:pull/25308 PR: https://git.openjdk.org/jdk/pull/25308 From dholmes at openjdk.org Mon May 19 20:40:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 May 2025 20:40:53 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests In-Reply-To: References: Message-ID: On Tue, 6 May 2025 17:43:51 GMT, Leonid Mesnik wrote: > Can you please review following PR that improve test groups. > The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. > 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. > 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) > 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds > > So tier1_common includes non-component tests that should be executed in tier1. > **all** sanity tests > **all** gttest tests (were not all of them) > testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) > source code checking tests (no need to run them an all builds, but it takes only few seconds) > > And it doesn't makes any sense to execute tier1_common with any external VM flags. > > While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. > > The new test groups were added mostly to add comments explaining their specific. I find it very hard to judge the necessity or merit of these changes. I guess it reflects the complexity of the overall testing system. But this really needs feedback from other "test system managers" to see how the changes would impact their test setup. test/hotspot/jtreg/TEST.groups line 29: > 27: :hotspot_all > 28: > 29: # The resourcehos tests might require a lot of resources and Suggestion: # The resourcehogs tests might require a lot of resources and test/hotspot/jtreg/TEST.groups line 36: > 34: > 35: hotspot_all = \ > 36: -:hotspot_resourcehogs \ When "all" was defined it was specifically intended to be all. If you want all-but-something then you define a group that is all-but -something. I don't know if these groups even get used regularly by anyone. test/hotspot/jtreg/TEST.groups line 161: > 159: # gtest and non_hotspot tests shouldn't be executed with VM flags > 160: # hotspot_misc includes sanity testing and might be used > 161: # for execution non-component tests with VM flags Suggestion: # for execution of non-component tests with VM flags test/hotspot/jtreg/TEST.groups line 165: > 163: sanity \ > 164: native_sanity \ > 165: :non_hotspot_tests \ Why should we want to execute the non-hotspot-tests in tier1 ?? ------------- PR Review: https://git.openjdk.org/jdk/pull/25070#pullrequestreview-2851932142 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096446181 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096445931 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096447774 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096449516 From dholmes at openjdk.org Mon May 19 21:15:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 19 May 2025 21:15:52 GMT Subject: RFR: 8357244: Move class declarations from attachListener_posix.cpp to header files In-Reply-To: <6ParCD1eqRHVog8e3KB_kqWt6TJ3PoOWg5G5f21XZzs=.cd62ab5e-c040-4d06-b083-363e315f933a@github.com> References: <6ParCD1eqRHVog8e3KB_kqWt6TJ3PoOWg5G5f21XZzs=.cd62ab5e-c040-4d06-b083-363e315f933a@github.com> Message-ID: On Mon, 19 May 2025 11:09:43 GMT, Dmitry Cherepanov wrote: > The patch suggests moving class declarations from `attachListener_posix.cpp` to header files > > It's moved in `openjdk/crac` project ahead of upstream and this causes merge conflicts every time attachListener code changes (e.g. https://github.com/openjdk/crac/pull/224). It's therefore suggested that the changes are included in upstream. I'm going to need to understand the motivation a bit better here. If these classes are not used by other code then they do not need to be in a header file. The fact they make merging easier in another project is not in itself sufficient motivation to me. src/hotspot/os/posix/attachListener_posix.hpp line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved. src/hotspot/os/posix/posixAttachOperation.hpp line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Suggestion: * Copyright (c) 2005, 2025, Oracle and/or its affiliates. All rights reserved. ------------- PR Review: https://git.openjdk.org/jdk/pull/25300#pullrequestreview-2852007496 PR Review Comment: https://git.openjdk.org/jdk/pull/25300#discussion_r2096494030 PR Review Comment: https://git.openjdk.org/jdk/pull/25300#discussion_r2096494554 From lmesnik at openjdk.org Mon May 19 21:15:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 19 May 2025 21:15:53 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:31:56 GMT, David Holmes wrote: >> Can you please review following PR that improve test groups. >> The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. >> 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. >> 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) >> 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds >> >> So tier1_common includes non-component tests that should be executed in tier1. >> **all** sanity tests >> **all** gttest tests (were not all of them) >> testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) >> source code checking tests (no need to run them an all builds, but it takes only few seconds) >> >> And it doesn't makes any sense to execute tier1_common with any external VM flags. >> >> While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. >> >> The new test groups were added mostly to add comments explaining their specific. > > test/hotspot/jtreg/TEST.groups line 36: > >> 34: >> 35: hotspot_all = \ >> 36: -:hotspot_resourcehogs \ > > When "all" was defined it was specifically intended to be all. If you want all-but-something then you define a group that is all-but -something. I don't know if these groups even get used regularly by anyone. There is a problem with resource_hogs, it is a specific group that might affect any other tests. It is not safe to execute :hotspot_resourcehogs with any other tests. I think that we don't have this problem know or we might have just rare intermittent failures/timeouts of random tests. Do we need any groups that are potentially unsafe at all? I don't think so and consider these tests like '/manually' that should be automatically ignored . > test/hotspot/jtreg/TEST.groups line 165: > >> 163: sanity \ >> 164: native_sanity \ >> 165: :non_hotspot_tests \ > > Why should we want to execute the non-hotspot-tests in tier1 ?? That's a good question. These tests are executed now in tier1. They include source verification and test library tests. We could introduce tier2_common for them, do you want to do it in this RFE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096482620 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096493630 From duke at openjdk.org Mon May 19 21:30:58 2025 From: duke at openjdk.org (Yannik Stradmann) Date: Mon, 19 May 2025 21:30:58 GMT Subject: Integrated: 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN In-Reply-To: References: Message-ID: On Wed, 16 Apr 2025 10:34:18 GMT, Yannik Stradmann wrote: > This change introduces an exponential backoff when hitting `EAGAIN` during native thread creation in hotspot. > > In contrast to the current solution, where we retry to create a native thread up to three times in a tight loop, hotspot will will thereby be more kind to an already depleted resource, reduce stress on the kernel and become more robust on systems under high load. > > The proposed modifications to `os_linux.cpp` have substantially improved system stability in a mid-sized Jenkins cluster and have been in production within our systems over the past three years. I have verbatim ported these to the other platforms, which previously also relied on identical logic. This pull request has now been integrated. Changeset: 27a42435 Author: Yannik Stradmann Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/27a4243561e31d6f2858dd0c0bd356e2849ed87c Stats: 68 lines in 4 files changed: 56 ins; 0 del; 12 mod 8354560: Exponentially delay subsequent native thread creation in case of EAGAIN Reviewed-by: dholmes, fbredberg ------------- PR: https://git.openjdk.org/jdk/pull/24682 From dholmes at openjdk.org Tue May 20 00:16:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 00:16:51 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests In-Reply-To: References: Message-ID: On Mon, 19 May 2025 21:10:23 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/TEST.groups line 165: >> >>> 163: sanity \ >>> 164: native_sanity \ >>> 165: :non_hotspot_tests \ >> >> Why should we want to execute the non-hotspot-tests in tier1 ?? > > That's a good question. These tests are executed now in tier1. They include source verification and test library tests. We could introduce tier2_common for them, do you want to do it in this RFE? It wasn't apparent to me that we already run the testlibrary_tests in tier1. That makes little sense to me - it is akin to running jtreg tests. The only time we need to run the testlibrary_tests is when we make changes to the test library, so a higher level tier would make more sense to me. That said, the intent of this PR is not, IIUC, to make that kind of change so that is perhaps better left to a separate change. The sources tests should be run in tier1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096635155 From iveresov at openjdk.org Tue May 20 00:37:14 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 20 May 2025 00:37:14 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v22] In-Reply-To: References: Message-ID: <_HjblHzZnDzpYl3gZrcQL7FWeqJ_7jxEY_LwHQV6AiU=.ad599c04-7bd1-48db-9485-dd0dab940930@github.com> > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 87 commits: - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - 8356667: GenShen: Eliminate races with ShenandoahFreeSet::available() Reviewed-by: wkemper - ... and 77 more: https://git.openjdk.org/jdk/compare/890456f0...2740c2f2 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=21 Stats: 3325 lines in 59 files changed: 3111 ins; 100 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iklam at openjdk.org Tue May 20 02:02:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 02:02:44 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v10] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 24 commits: - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - java.md updates from @rose00 - Resolved differences with CSR JDK-8356010 - Added param to makefile function SetupAOT for choosing onestep vs twostep - Allow one-step training even when -XX:AOTMode=auto is specified - ... and 14 more: https://git.openjdk.org/jdk/compare/890456f0...0956fcad ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09 Stats: 2088 lines in 24 files changed: 1564 ins; 459 del; 65 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From dholmes at openjdk.org Tue May 20 02:11:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 02:11:54 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests In-Reply-To: References: Message-ID: <5xXYTGva7bXjs43cbBTWgVpV2YkaSmKoPpJo-45gN-Y=.33159101-c356-4442-ace7-24190f6889df@github.com> On Mon, 19 May 2025 21:00:27 GMT, Leonid Mesnik wrote: >> test/hotspot/jtreg/TEST.groups line 36: >> >>> 34: >>> 35: hotspot_all = \ >>> 36: -:hotspot_resourcehogs \ >> >> When "all" was defined it was specifically intended to be all. If you want all-but-something then you define a group that is all-but -something. I don't know if these groups even get used regularly by anyone. > > There is a problem with resource_hogs, it is a specific group that might affect any other tests. It is not safe to execute :hotspot_resourcehogs with any other tests. I think that we don't have this problem know or we might have just rare intermittent failures/timeouts of random tests. > Do we need any groups that are potentially unsafe at all? I don't think so and consider these tests like '/manually' that should be automatically ignored . It is up to the people running "all" (see in particular JDK-8323515) to decide what makes sense, IMO. If we are running "all" and have an issue then we should change what we run. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2096721722 From dholmes at openjdk.org Tue May 20 02:15:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 02:15:53 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: <8ESfGv0Drhrx1l2FppAyTuLk9eUO6PdnKh-gDOGA-y0=.91fdffb8-38c2-4c52-a15f-451ff8a37f65@github.com> References: <1JSZ5dvXkpOcX59TXSv6nRvHmJ11fj3byKI-Viqc5rM=.e9b34db3-0240-45cc-bcb3-893352fd13a5@github.com> <8ESfGv0Drhrx1l2FppAyTuLk9eUO6PdnKh-gDOGA-y0=.91fdffb8-38c2-4c52-a15f-451ff8a37f65@github.com> Message-ID: <7zbvlT99N6unJyMtH0093Rr6sVP4ueD5IDQz--AoML0=.548416d3-7a53-4b1d-bfed-a2d9e0eeadda@github.com> On Fri, 16 May 2025 10:18:13 GMT, Anton Artemov wrote: >> src/hotspot/os/windows/os_windows.cpp line 4637: >> >>> 4635: WCHAR* path_to_target = NEW_C_HEAP_ARRAY(WCHAR, target_path_size + 1, mtInternal); >>> 4636: >>> 4637: ::GetFinalPathNameByHandleW(hFile, path_to_target, static_cast(target_path_size + 1), >> >> Maybe save the return value and assert it is the expected one. > > We do not have an expected value here. Well we could assert that the return value is >= 0 and not < target_path_size ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2096727107 From lmesnik at openjdk.org Tue May 20 02:33:39 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 02:33:39 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v2] In-Reply-To: References: Message-ID: > Can you please review following PR that improve test groups. > The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. > 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. > 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) > 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds > > So tier1_common includes non-component tests that should be executed in tier1. > **all** sanity tests > **all** gttest tests (were not all of them) > testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) > source code checking tests (no need to run them an all builds, but it takes only few seconds) > > And it doesn't makes any sense to execute tier1_common with any external VM flags. > > While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. > > The new test groups were added mostly to add comments explaining their specific. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated after David's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25070/files - new: https://git.openjdk.org/jdk/pull/25070/files/1ad0feb1..19f44eea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=00-01 Stats: 15 lines in 1 file changed: 6 ins; 8 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25070/head:pull/25070 PR: https://git.openjdk.org/jdk/pull/25070 From iklam at openjdk.org Tue May 20 03:43:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 20 May 2025 03:43:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24942/files - new: https://git.openjdk.org/jdk/pull/24942/files/0956fcad..502d1c07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=09-10 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From jsjolen at openjdk.org Tue May 20 07:02:53 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Tue, 20 May 2025 07:02:53 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:11:09 GMT, Gerard Ziemski wrote: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. Marked as reviewed by jsjolen (Reviewer). src/hotspot/share/nmt/virtualMemoryTracker.cpp line 404: > 402: } > 403: > 404: // Print some more details. Don't use UL here to avoid circularities. It seems unlikely that any circularities would occur, as UL doesn't use the VMT. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 411: > 409: " new region: [" INTPTR_FORMAT "-" INTPTR_FORMAT "), memory tag %s.", > 410: p2i(reserved_rgn->base()), p2i(reserved_rgn->end()), NMTUtil::tag_to_name(mem_tag_old), > 411: p2i(base_addr), p2i(base_addr + size), NMTUtil::tag_to_name(mem_tag_new)); This change also now prints the name instead of the index. If you do print the name, then you don't need to use `index_to_tag` as they already are `MemTag`s. src/hotspot/share/nmt/virtualMemoryTracker.cpp line 419: > 417: } > 418: const char* msg = ss.as_string(true /* on C-heap */); > 419: log_debug(nmt)("%s", msg); You can just do `log_debug(nmt)("%s", ss.freeze());` and skip the `as_string()`. ------------- PR Review: https://git.openjdk.org/jdk/pull/25308#pullrequestreview-2852901488 PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2097127250 PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2097133382 PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2097128142 From duke at openjdk.org Tue May 20 07:29:03 2025 From: duke at openjdk.org (duke) Date: Tue, 20 May 2025 07:29:03 GMT Subject: RFR: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: <0r0il-iFiLSNbwFADNg24Snii9-FkIA9PMqA5JMZUaQ=.ed48e0cc-3cc4-48bb-a056-729e90b6c4f1@github.com> On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to restore the old documented semantics of fence - lock - acquire. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. @toxaart Your change (at version 562a5f441174d89f2993989ea2daff9c96f3801d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25033#issuecomment-2893259616 From dholmes at openjdk.org Tue May 20 09:07:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 09:07:58 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v4] In-Reply-To: References: Message-ID: <0Fpboyw4jCOPbAkl_ikyGfL5zX_jDna_VyCdMwmsXtc=.9eb65b48-7d97-48c0-b5c8-00771bf40e98@github.com> On Fri, 16 May 2025 10:21:40 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Addressed reviewer's comments, added debug output. Thanks for updates! Not withstanding my lack of detailed knowledge of the API specifics this looks good to me. A couple of minor nits/queries with the test, but I will hit approve. test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 52: > 50: > 51: String subPath = "compiled"; > 52: destDir = Paths.get(System.getProperty("test.classes"), subPath); Suggestion: String subPath = "compiled"; Path destDir = Paths.get(System.getProperty("test.classes"), subPath); test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 54: > 52: destDir = Paths.get(System.getProperty("test.classes"), subPath); > 53: > 54: CompilerUtils.compile(sourceDir, destDir); What exactly is this compiling? ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2853351466 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2097422231 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2097425285 From dholmes at openjdk.org Tue May 20 10:21:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 10:21:54 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:11:09 GMT, Gerard Ziemski wrote: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. Overall conversion looks good. If there is no chance of UL using NMT in a way that leads to VMT then this is fine. Please fix the tag->unsigned->tag code. Thanks ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25308#pullrequestreview-2853599191 From dholmes at openjdk.org Tue May 20 10:21:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 10:21:55 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: <5jTRvyEF5ZOxF9JAswAQhMWAhdUtLcGIWplNXajlc54=.526f1b8a-f97a-4c8c-ac73-667cb0a8f614@github.com> On Tue, 20 May 2025 06:59:45 GMT, Johan Sj?len wrote: >> To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: >> >> >> # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 >> # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock >> >> >> We avoid this, by printing using `UL` instead of using `tty` directly. > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 411: > >> 409: " new region: [" INTPTR_FORMAT "-" INTPTR_FORMAT "), memory tag %s.", >> 410: p2i(reserved_rgn->base()), p2i(reserved_rgn->end()), NMTUtil::tag_to_name(mem_tag_old), >> 411: p2i(base_addr), p2i(base_addr + size), NMTUtil::tag_to_name(mem_tag_new)); > > This change also now prints the name instead of the index. If you do print the name, then you don't need to use `index_to_tag` as they already are `MemTag`s. +1 on Johan's comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2097585561 From duke at openjdk.org Tue May 20 10:47:01 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 20 May 2025 10:47:01 GMT Subject: Integrated: 8341544: Restore fence() in Mutex In-Reply-To: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> References: <_Icnq2X0lCxXeajXHv34RrNTDGdnzEEcC27-uYnadhA=.7bae923c-6e58-4b9b-90c5-e5eca9382a96@github.com> Message-ID: On Mon, 5 May 2025 11:13:05 GMT, Anton Artemov wrote: > Added a fence in the mutex code in order to restore the old documented semantics of fence - lock - acquire. > > No significant performance impact observed in an extending testing. > > Tested in tiers 1-3. This pull request has now been integrated. Changeset: ab985a7c Author: Anton Artemov Committer: David Holmes URL: https://git.openjdk.org/jdk/commit/ab985a7c5d313304e6d601571885dcb871967259 Stats: 13 lines in 2 files changed: 13 ins; 0 del; 0 mod 8341544: Restore fence() in Mutex Reviewed-by: eosterlund, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25033 From dholmes at openjdk.org Tue May 20 10:53:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 10:53:54 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 02:33:39 GMT, Leonid Mesnik wrote: >> Can you please review following PR that improve test groups. >> The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. >> 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. >> 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) >> 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds >> >> So tier1_common includes non-component tests that should be executed in tier1. >> **all** sanity tests >> **all** gttest tests (were not all of them) >> testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) >> source code checking tests (no need to run them an all builds, but it takes only few seconds) >> >> And it doesn't makes any sense to execute tier1_common with any external VM flags. >> >> While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. >> >> The new test groups were added mostly to add comments explaining their specific. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated after David's feedback test/hotspot/jtreg/TEST.groups line 158: > 156: > 157: # gtest and non_hotspot tests shouldn't be executed with VM flags > 158: # hotspot_misc includes sanity testing and might be used I don't understand the reference to hotspot_misc here. I don't see anything running/including hotspot_misc. ?? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2097650602 From duke at openjdk.org Tue May 20 11:19:56 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 20 May 2025 11:19:56 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v4] In-Reply-To: <0Fpboyw4jCOPbAkl_ikyGfL5zX_jDna_VyCdMwmsXtc=.9eb65b48-7d97-48c0-b5c8-00771bf40e98@github.com> References: <0Fpboyw4jCOPbAkl_ikyGfL5zX_jDna_VyCdMwmsXtc=.9eb65b48-7d97-48c0-b5c8-00771bf40e98@github.com> Message-ID: On Tue, 20 May 2025 09:02:20 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments, added debug output. > > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 54: > >> 52: destDir = Paths.get(System.getProperty("test.classes"), subPath); >> 53: >> 54: CompilerUtils.compile(sourceDir, destDir); > > What exactly is this compiling? It complies java source files found in the source dir (in this case test/hotspot/jtreg/runtime/LoadClass/test-classes) to class files and puts them to the destination directory. There is only one file called Hello.java in the source. It is compiled into Hello.class, which is then loaded by the test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2097696279 From duke at openjdk.org Tue May 20 12:22:37 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 20 May 2025 12:22:37 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v3] In-Reply-To: <7zbvlT99N6unJyMtH0093Rr6sVP4ueD5IDQz--AoML0=.548416d3-7a53-4b1d-bfed-a2d9e0eeadda@github.com> References: <1JSZ5dvXkpOcX59TXSv6nRvHmJ11fj3byKI-Viqc5rM=.e9b34db3-0240-45cc-bcb3-893352fd13a5@github.com> <8ESfGv0Drhrx1l2FppAyTuLk9eUO6PdnKh-gDOGA-y0=.91fdffb8-38c2-4c52-a15f-451ff8a37f65@github.com> <7zbvlT99N6unJyMtH0093Rr6sVP4ueD5IDQz--AoML0=.548416d3-7a53-4b1d-bfed-a2d9e0eeadda@github.com> Message-ID: On Tue, 20 May 2025 02:13:36 GMT, David Holmes wrote: >> We do not have an expected value here. > > Well we could assert that the return value is >= 0 and not < target_path_size Thanks for bringing this up. I checked the documentation for `GetFinalPathNameByHandleW`, this is a tricky method. When it is called with the null buffer, i.e. in order to get `target_path_size`, it returns the length with the terminating character. But, when you use it for the 2nd time, i.e. with already allocated buffer of sufficient length, it returns the length without the terminating character. So the failure check is `res != target_path_size - 1`. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2097808585 From duke at openjdk.org Tue May 20 12:22:36 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 20 May 2025 12:22:36 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v5] In-Reply-To: References: Message-ID: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8350869: Clean up of the test, error handling in get_path_to_target ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25233/files - new: https://git.openjdk.org/jdk/pull/25233/files/a444fa93..f541fd6b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=03-04 Stats: 14 lines in 2 files changed: 7 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From duke at openjdk.org Tue May 20 12:22:37 2025 From: duke at openjdk.org (Anton Artemov) Date: Tue, 20 May 2025 12:22:37 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v4] In-Reply-To: <0Fpboyw4jCOPbAkl_ikyGfL5zX_jDna_VyCdMwmsXtc=.9eb65b48-7d97-48c0-b5c8-00771bf40e98@github.com> References: <0Fpboyw4jCOPbAkl_ikyGfL5zX_jDna_VyCdMwmsXtc=.9eb65b48-7d97-48c0-b5c8-00771bf40e98@github.com> Message-ID: On Tue, 20 May 2025 09:00:49 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Addressed reviewer's comments, added debug output. > > test/hotspot/jtreg/runtime/LoadClass/TestSymlinkLoad.java line 52: > >> 50: >> 51: String subPath = "compiled"; >> 52: destDir = Paths.get(System.getProperty("test.classes"), subPath); > > Suggestion: > > String subPath = "compiled"; > > Path destDir = Paths.get(System.getProperty("test.classes"), subPath); Right, thanks for spotting, cleaned this up in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2097808934 From lmesnik at openjdk.org Tue May 20 14:44:48 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 14:44:48 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v3] In-Reply-To: References: Message-ID: > Can you please review following PR that improve test groups. > The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. > 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. > 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) > 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds > > So tier1_common includes non-component tests that should be executed in tier1. > **all** sanity tests > **all** gttest tests (were not all of them) > testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) > source code checking tests (no need to run them an all builds, but it takes only few seconds) > > And it doesn't makes any sense to execute tier1_common with any external VM flags. > > While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. > > The new test groups were added mostly to add comments explaining their specific. Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: updated comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25070/files - new: https://git.openjdk.org/jdk/pull/25070/files/19f44eea..9776720f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=01-02 Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25070/head:pull/25070 PR: https://git.openjdk.org/jdk/pull/25070 From lmesnik at openjdk.org Tue May 20 14:52:00 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 14:52:00 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v2] In-Reply-To: References: Message-ID: <_w62VY5Pn1sVlJOaOTZYsDmvIEXOuSGDk61vfityeNE=.2d3d669b-7b1f-4574-92f9-62b543dd10ec@github.com> On Tue, 20 May 2025 10:51:22 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> updated after David's feedback > > test/hotspot/jtreg/TEST.groups line 158: > >> 156: >> 157: # gtest and non_hotspot tests shouldn't be executed with VM flags >> 158: # hotspot_misc includes sanity testing and might be used > > I don't understand the reference to hotspot_misc here. I don't see anything running/including hotspot_misc. ?? The tier1_common seems to be quite specific test group. It contains mostly testing that ignores vm flags. It doesn't make any sense to run the with VM flags. While from other point it has all non-component tests that should be executed in tier1. So it is enough to run this groups once. While in all testing after tier1 the group hotspot_misc should be used instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098184101 From gziemski at openjdk.org Tue May 20 15:56:01 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 15:56:01 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: On Tue, 20 May 2025 06:56:16 GMT, Johan Sj?len wrote: >> To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: >> >> >> # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 >> # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock >> >> >> We avoid this, by printing using `UL` instead of using `tty` directly. > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 404: > >> 402: } >> 403: >> 404: // Print some more details. Don't use UL here to avoid circularities. > > It seems unlikely that any circularities would occur, as UL doesn't use the VMT. I think so too. I forced the code to go through this path early in the VM init sequence and didn't see NMT activity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2098327457 From gziemski at openjdk.org Tue May 20 16:05:38 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 16:05:38 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v2] In-Reply-To: References: Message-ID: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: Johan's feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25308/files - new: https://git.openjdk.org/jdk/pull/25308/files/b32dbbec..985856ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25308&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25308&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 3 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25308/head:pull/25308 PR: https://git.openjdk.org/jdk/pull/25308 From gziemski at openjdk.org Tue May 20 16:05:38 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 16:05:38 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: On Mon, 19 May 2025 20:11:09 GMT, Gerard Ziemski wrote: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. Thank you Johan and David for your feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25308#issuecomment-2895029701 From gziemski at openjdk.org Tue May 20 16:05:38 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 16:05:38 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v2] In-Reply-To: <5jTRvyEF5ZOxF9JAswAQhMWAhdUtLcGIWplNXajlc54=.526f1b8a-f97a-4c8c-ac73-667cb0a8f614@github.com> References: <5jTRvyEF5ZOxF9JAswAQhMWAhdUtLcGIWplNXajlc54=.526f1b8a-f97a-4c8c-ac73-667cb0a8f614@github.com> Message-ID: On Tue, 20 May 2025 10:18:18 GMT, David Holmes wrote: >> src/hotspot/share/nmt/virtualMemoryTracker.cpp line 411: >> >>> 409: " new region: [" INTPTR_FORMAT "-" INTPTR_FORMAT "), memory tag %s.", >>> 410: p2i(reserved_rgn->base()), p2i(reserved_rgn->end()), NMTUtil::tag_to_name(mem_tag_old), >>> 411: p2i(base_addr), p2i(base_addr + size), NMTUtil::tag_to_name(mem_tag_new)); >> >> This change also now prints the name instead of the index. If you do print the name, then you don't need to use `index_to_tag` as they already are `MemTag`s. > > +1 on Johan's comment Good catch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2098339826 From gziemski at openjdk.org Tue May 20 16:05:38 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 16:05:38 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 06:56:45 GMT, Johan Sj?len wrote: >> Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: >> >> Johan's feedback > > src/hotspot/share/nmt/virtualMemoryTracker.cpp line 419: > >> 417: } >> 418: const char* msg = ss.as_string(true /* on C-heap */); >> 419: log_debug(nmt)("%s", msg); > > You can just do `log_debug(nmt)("%s", ss.freeze());` and skip the `as_string()`. Sure, there are other cases of such usage, so I will file an issue in case we want to fix the other usage. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25308#discussion_r2098337807 From erikj at openjdk.org Tue May 20 19:50:53 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 May 2025 19:50:53 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v11] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 03:43:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed merge make/RunTests.gmk line 753: > 751: $$(call MakeDir, $$($1_AOT_JDK_OUTPUT_DIR)) > 752: > 753: ifeq ($$($1_TRAINING), onestep) Sorry for not noticing this earlier. This is a conditional within a recipe. The preferred style for those are to align the `ifeq`, `else` and `endif` with the recipe itself, using spaces (as it's not a recipe line), and then indent the body with 2 extra spaces for logical indentation. See points 5 and 6 in https://openjdk.org/groups/build/doc/code-conventions.html. You can find an example of this in `make/Bundles.gmk`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24942#discussion_r2098741011 From gziemski at openjdk.org Tue May 20 21:47:55 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Tue, 20 May 2025 21:47:55 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:31:13 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > impl of new visualization in one test case, for getting feedback. hi Afshin, When I run the updated code using `make test TEST="gtest:NMTVMATreeTest" MICRO="RESULTS_FORMAT=json" TEST_VM_OPTS="-XX:NativeMemoryTracking=detail"` I get these failures: test/hotspot/gtest/nmt/test_vmatree.cpp:905: Failure Expected equality of these values: td.reserve Which is: 0 sd.reserve Which is: -7024640 test/hotspot/gtest/nmt/test_vmatree.cpp:220: Failure Expected equality of these values: diff.tag[from].reserve Which is: 0 upd.reserve[0] Which is: -100 Ex. State: 1, op: 2, use-tag:0, from==to: 0 test/hotspot/gtest/nmt/test_vmatree.cpp:222: Failure Expected equality of these values: diff.tag[to].reserve Which is: 0 upd.reserve[1] Which is: 100 Ex. State: 1, op: 2, use-tag:0, from==to: 0 test/hotspot/gtest/nmt/test_vmatree.cpp:220: Failure Expected equality of these values: diff.tag[from].reserve Which is: 0 upd.reserve[0] Which is: -100 Ex. State: 2, op: 2, use-tag:0, from==to: 0 test/hotspot/gtest/nmt/test_vmatree.cpp:222: Failure Expected equality of these values: diff.tag[to].reserve Which is: 0 upd.reserve[1] Which is: 100 Ex. State: 2, op: 2, use-tag:0, from==to: 0 [ FAILED ] NMTVMATreeTest.UpdateRegionTest_vm (0 ms) [----------] 18 tests from NMTVMATreeTest (17 ms total) [----------] Global test environment tear-down [==========] 18 tests from 1 test suite ran. (17 ms total) [ PASSED ] 16 tests. [ FAILED ] 2 tests, listed below: [ FAILED ] NMTVMATreeTest.TestConsistencyWithSimpleTracker_vm [ FAILED ] NMTVMATreeTest.UpdateRegionTest_vm 2 FAILED TESTS ERROR: RUN_ALL_TESTS() failed. Error 1 Finished running test 'gtest:NMTVMATreeTest/server' Test report is stored in build/macosx-aarch64-server-release/test-results/gtest_NMTVMATreeTest_server ============================== Test summary ============================== TEST TOTAL PASS FAIL ERROR SKIP >> gtest:NMTVMATreeTest/server 18 16 2 0 0 << ============================== TEST FAILURE make[1]: *** [main] Error 1 make: *** [test] Error 2 ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2895904305 From dholmes at openjdk.org Tue May 20 22:16:55 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 22:16:55 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v3] In-Reply-To: References: Message-ID: <3Gzu2_LU363u8GyEfUFERMRGs7EeVe0oM1TXWIMBTzQ=.e0c983c7-cd74-472c-9eea-5fb66e9c457c@github.com> On Tue, 20 May 2025 14:44:48 GMT, Leonid Mesnik wrote: >> Can you please review following PR that improve test groups. >> The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. >> 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. >> 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) >> 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds >> >> So tier1_common includes non-component tests that should be executed in tier1. >> **all** sanity tests >> **all** gttest tests (were not all of them) >> testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) >> source code checking tests (no need to run them an all builds, but it takes only few seconds) >> >> And it doesn't makes any sense to execute tier1_common with any external VM flags. >> >> While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. >> >> The new test groups were added mostly to add comments explaining their specific. > > Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: > > updated comment I'm still somewhat unclear on the guidance being given here, but I tweaked some of the comments. test/hotspot/jtreg/TEST.groups line 67: > 65: # The resourcehogs tests might require a lot of resources and > 66: # shouldn't be executed concurrently with ANY other tests > 67: # So the group shouldn't be part of any other group Suggestion: # The resourcehogs tests might require a lot of resources and # shouldn't be executed concurrently with ANY other tests. # So the group shouldn't be part of any other group. test/hotspot/jtreg/TEST.groups line 72: > 70: > 71: # The other tests includes all tests that don't > 72: # test hotspot itself Suggestion: # The other tests includes all tests that don't # test hotspot itself. test/hotspot/jtreg/TEST.groups line 77: > 75: sources > 76: > 77: # Gtest unit-test with jtreg wrapper, VM flags are set by test Suggestion: # Gtest unit-test with jtreg wrapper, VM flags are set by test, # and so should not be executed with VM flags. ??? test/hotspot/jtreg/TEST.groups line 81: > 79: gtest > 80: > 81: hotspot_misc = \ What is actually left in this group after all the listed excluded? test/hotspot/jtreg/TEST.groups line 160: > 158: # non_hotspot and gtest ignore them, > 159: # hotspot_misc should be used for execution of > 160: # all non-component tests with VM flags Suggestion: # tier1_common shouldn't be executed with VM flags, because # non_hotspot and gtest ignore them. # hotspot_misc should be used for execution of # all non-component tests with VM flags. ------------- PR Review: https://git.openjdk.org/jdk/pull/25070#pullrequestreview-2855706612 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098952552 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098952750 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098953716 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098954609 PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098955209 From dholmes at openjdk.org Tue May 20 22:23:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 22:23:54 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v5] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 12:22:36 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Clean up of the test, error handling in get_path_to_target There is generally no need to include quotes from API documentation. Thanks src/hotspot/os/windows/os_windows.cpp line 4643: > 4641: // One does not need extra character in the end, from documentation: > 4642: // "If the function fails because lpszFilePath is too small to hold the string plus the terminating null character, > 4643: // the return value is the required buffer size, in TCHARs. This value INCLUDES the size of the terminating null character." A simple: // Returned value includes the terminating null character. will suffice. src/hotspot/os/windows/os_windows.cpp line 4657: > 4655: // "If the function succeeds, the return value is the length of the string received by lpszFilePath, > 4656: // in TCHARs.This value DOES NOT INCLUDE the size of the terminating null character." > 4657: // So the return value is ONE LESS than target_path_size if everything is ok Again please simplify: // The returned size is the length excluding the terminating null character. src/hotspot/os/windows/os_windows.cpp line 4672: > 4670: } > 4671: > 4672: path_to_target[target_path_size - 1] = '\0'; Why are we explicitly adding the null character ourselves? ------------- Changes requested by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2855715910 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2098959245 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2098960494 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2098961439 From dholmes at openjdk.org Tue May 20 22:28:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 20 May 2025 22:28:54 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:05:38 GMT, Gerard Ziemski wrote: >> To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: >> >> >> # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 >> # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock >> >> >> We avoid this, by printing using `UL` instead of using `tty` directly. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Johan's feedback LGTM. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25308#pullrequestreview-2855726330 From lmesnik at openjdk.org Tue May 20 22:40:07 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 22:40:07 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v4] In-Reply-To: References: Message-ID: > Can you please review following PR that improve test groups. > The bug was originally filed to eliminate duplication between tier1_common and hotspot_misc test groups. However while looked on the test content of these groups I realized that there are some other issues. > 1) hotspot_resourcehogs groups should be executed always separately from other tests to don't cause intermittent failures. > 2) it makes sense to run all gtest tests in tier1 but don't run in any other tiers (with any VM flags) > 3) testlibrary_tests and sources should be a separate groups that don't need to be executed with any VM flags, or event with all builds > > So tier1_common includes non-component tests that should be executed in tier1. > **all** sanity tests > **all** gttest tests (were not all of them) > testlibrary_tests (might be os/cpu specifc, so need to run them with all builds) > source code checking tests (no need to run them an all builds, but it takes only few seconds) > > And it doesn't makes any sense to execute tier1_common with any external VM flags. > > While hotspot_misc now includes on 2 sanity tests. It doesn't looks useful, but main purpose for this group would be to catch all tests that somehow missed from other groups. So let keep it. > > The new test groups were added mostly to add comments explaining their specific. Leonid Mesnik has updated the pull request incrementally with four additional commits since the last revision: - Update test/hotspot/jtreg/TEST.groups Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/TEST.groups Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/TEST.groups Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Update test/hotspot/jtreg/TEST.groups Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25070/files - new: https://git.openjdk.org/jdk/pull/25070/files/9776720f..a21d402d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25070&range=02-03 Stats: 8 lines in 1 file changed: 1 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25070.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25070/head:pull/25070 PR: https://git.openjdk.org/jdk/pull/25070 From lmesnik at openjdk.org Tue May 20 22:43:53 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Tue, 20 May 2025 22:43:53 GMT Subject: RFR: 8344270: Update tier1_common and hotspot_misc groups to better organize hotspot non-component tests [v3] In-Reply-To: <3Gzu2_LU363u8GyEfUFERMRGs7EeVe0oM1TXWIMBTzQ=.e0c983c7-cd74-472c-9eea-5fb66e9c457c@github.com> References: <3Gzu2_LU363u8GyEfUFERMRGs7EeVe0oM1TXWIMBTzQ=.e0c983c7-cd74-472c-9eea-5fb66e9c457c@github.com> Message-ID: On Tue, 20 May 2025 22:12:26 GMT, David Holmes wrote: >> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision: >> >> updated comment > > test/hotspot/jtreg/TEST.groups line 81: > >> 79: gtest >> 80: >> 81: hotspot_misc = \ > > What is actually left in this group after all the listed excluded? Really, it contains only few tests now. However it is going to contain anything that we might miss in the component and other specified groups. Sometimes it would be makes sense to rename it to hotspot_empty and verify that it has only expected tests during source testing, I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25070#discussion_r2098979608 From duke at openjdk.org Wed May 21 06:54:37 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Wed, 21 May 2025 06:54:37 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: References: Message-ID: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails PAWAN CHAWDHARY 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/24948/files - new: https://git.openjdk.org/jdk/pull/24948/files/b3ccffd7..5e1f9240 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24948&range=04-05 Stats: 51 lines in 3 files changed: 12 ins; 17 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/24948.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24948/head:pull/24948 PR: https://git.openjdk.org/jdk/pull/24948 From duke at openjdk.org Wed May 21 06:54:37 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Wed, 21 May 2025 06:54:37 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v5] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 16:21:56 GMT, Leonid Mesnik wrote: >> PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import > > test/hotspot/jtreg/containers/docker/TestMemoryWithSubgroups.java line 73: > >> 71: return; >> 72: } >> 73: if (IS_DOCKER && ContainerRuntimeVersionTestUtils.DOCKER_VERSION_20_10_0.compareTo(ContainerRuntimeVersionTestUtils.getContainerRuntimeVersion()) > 0) { > > Better to replace this with > `isContainerVersionSupported()` > ... > and implement all logic in the the ContainerRuntimeVersionTestUtils created checkContainerVersionSupported() > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 38: > >> 36: private final int micro; >> 37: private static final ContainerRuntimeVersionTestUtils DEFAULT = new ContainerRuntimeVersionTestUtils(0, 0, 0); >> 38: public static final ContainerRuntimeVersionTestUtils DOCKER_VERSION_20_10_0 = new ContainerRuntimeVersionTestUtils(20, 10, 0); > > Please add comment about meaning of the version or even better rename > DOCKER_MINIMAL_SUPPORTED_VERSION = .... updated name to DOCKER_MINIMAL_SUPPORTED_VERSION_CGROUPNS and PODMAN_MINIMAL_SUPPORTED_VERSION_CGROUPNS > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 53: > >> 51: } else if (this.major < other.major) { >> 52: return -1; >> 53: } else { // equal major > > no need to add `else {` here updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 58: > >> 56: } else if (this.minor < other.minor) { >> 57: return -1; >> 58: } else { // equal majors and minors > > no need to add `else {` here updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 81: > >> 79: } catch (Exception e) { >> 80: System.out.println("Failed to parse container runtime version: " + version); >> 81: return DEFAULT; > > Any reason to don't fail here? updated > test/lib/jdk/test/lib/containers/docker/ContainerRuntimeVersionTestUtils.java line 94: > >> 92: } catch (Exception e) { >> 93: System.out.println(Container.ENGINE_COMMAND + " --version command failed. Returning null"); >> 94: return null; > > Any reason to don't fail here? updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494838 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099496846 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494004 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099494142 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497419 PR Review Comment: https://git.openjdk.org/jdk/pull/24948#discussion_r2099497254 From jsjolen at openjdk.org Wed May 21 07:23:56 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 21 May 2025 07:23:56 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v2] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 16:05:38 GMT, Gerard Ziemski wrote: >> To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: >> >> >> # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 >> # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock >> >> >> We avoid this, by printing using `UL` instead of using `tty` directly. > > Gerard Ziemski has updated the pull request incrementally with one additional commit since the last revision: > > Johan's feedback LGTM ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25308#pullrequestreview-2856591824 From azafari at openjdk.org Wed May 21 09:24:05 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 21 May 2025 09:24:05 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: <6w4qlv61--deK895PvF_G3Zyi8tI_ruXR48hIko6uRg=.b1087fe1-092e-47f2-b056-66cccbf946b3@github.com> On Tue, 20 May 2025 21:45:10 GMT, Gerard Ziemski wrote: > hi Afshin, > > When I run the updated code using `make test TEST="gtest:NMTVMATreeTest" MICRO="RESULTS_FORMAT=json" TEST_VM_OPTS="-XX:NativeMemoryTracking=detail"` I get these failures: > > ``` > test/hotspot/gtest/nmt/test_vmatree.cpp:905: Failure > Expected equality of these values: > td.reserve > Which is: 0 > sd.reserve > Which is: -7024640 > > test/hotspot/gtest/nmt/test_vmatree.cpp:220: Failure > Expected equality of these values: > diff.tag[from].reserve > Which is: 0 > upd.reserve[0] > Which is: -100 > Ex. State: 1, op: 2, use-tag:0, from==to: 0 > > test/hotspot/gtest/nmt/test_vmatree.cpp:222: Failure > Expected equality of these values: > diff.tag[to].reserve > Which is: 0 > upd.reserve[1] > Which is: 100 > Ex. State: 1, op: 2, use-tag:0, from==to: 0 > > test/hotspot/gtest/nmt/test_vmatree.cpp:220: Failure > Expected equality of these values: > diff.tag[from].reserve > Which is: 0 > upd.reserve[0] > Which is: -100 > Ex. State: 2, op: 2, use-tag:0, from==to: 0 > > test/hotspot/gtest/nmt/test_vmatree.cpp:222: Failure > Expected equality of these values: > diff.tag[to].reserve > Which is: 0 > upd.reserve[1] > Which is: 100 > Ex. State: 2, op: 2, use-tag:0, from==to: 0 > > [ FAILED ] NMTVMATreeTest.UpdateRegionTest_vm (0 ms) > [----------] 18 tests from NMTVMATreeTest (17 ms total) > > [----------] Global test environment tear-down > [==========] 18 tests from 1 test suite ran. (17 ms total) > [ PASSED ] 16 tests. > [ FAILED ] 2 tests, listed below: > [ FAILED ] NMTVMATreeTest.TestConsistencyWithSimpleTracker_vm > [ FAILED ] NMTVMATreeTest.UpdateRegionTest_vm > > 2 FAILED TESTS > ERROR: RUN_ALL_TESTS() failed. Error 1 > Finished running test 'gtest:NMTVMATreeTest/server' > Test report is stored in build/macosx-aarch64-server-release/test-results/gtest_NMTVMATreeTest_server > > ============================== > Test summary > ============================== > TEST TOTAL PASS FAIL ERROR SKIP > >> gtest:NMTVMATreeTest/server 18 16 2 0 0 << > ============================== > TEST FAILURE > > make[1]: *** [main] Error 1 > make: *** [test] Error 2 > ``` Thanks for finding it. Work on it ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2897236062 From azafari at openjdk.org Wed May 21 10:15:15 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Wed, 21 May 2025 10:15:15 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: fixed a missed change in test. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/831c1159..7d10accc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=27-28 Stats: 125 lines in 1 file changed: 67 ins; 11 del; 47 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From jsjolen at openjdk.org Wed May 21 11:21:07 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Wed, 21 May 2025 11:21:07 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: On Thu, 15 May 2025 09:31:13 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > impl of new visualization in one test case, for getting feedback. If this passes all current tests then I'm fine with it. Please consider all of my comments. src/hotspot/share/nmt/vmatree.cpp line 34: > 32: // Semantics > 33: // This tree is used to store and track the state of virtual memory regions. > 34: // The nodes in the tree are key-value pairs where key is the memory address and the value is the State of the memory regions. the key src/hotspot/share/nmt/vmatree.cpp line 35: > 33: // This tree is used to store and track the state of virtual memory regions. > 34: // The nodes in the tree are key-value pairs where key is the memory address and the value is the State of the memory regions. > 35: // State of a region describes whether the region is released, reserved or committed, which MemTag it has and where in The state (State if it's a type) src/hotspot/share/nmt/vmatree.cpp line 46: > 44: // changes needed for the affected regions in the tree. For each operation a request > 45: // () is sent to the tree to handle. > 46: // `` `During these operations, the tree should handle the // changes needed for the affected regions in the tree I think that this can be removed without loss of information, it is clear that the tree must do this. src/hotspot/share/nmt/vmatree.cpp line 47: > 45: // () is sent to the tree to handle. > 46: // > 47: // The expected changes are described here for each operation: I agree with the semantics of these operations. src/hotspot/share/nmt/vmatree.cpp line 62: > 60: // - if the region is in Released state > 61: // - mark the region as both Reserved and Committed > 62: // - store the call-stack of the request to the reserve call-stack So if `mtNone` is provided in this case, we will end up with `mtNone` as the category for this committed region? OK. src/hotspot/share/nmt/vmatree.cpp line 102: > 100: {es, es, es} // op == Uncommit > 101: }; > 102: if (op == 2 && ex == StateType::Released) { This is using the information that `op == 2` is 'commit', this should be well-typed. It's better to do something like this: const Operation op = req.op(); if (op == Operation::Commit && ex == StateType::released) { return rq; } else { return result[opi][state_to_index(ex)]; } Also, just add a small comment on why we treat committed specially here. src/hotspot/share/nmt/vmatree.cpp line 113: > 111: const SIndex rq = req.callstack; > 112: const int op = req.op_to_index(); > 113: assert(op >= 0 && op < 4, "should be"); Add this assert to the method above as well? src/hotspot/share/nmt/vmatree.cpp line 140: > 138: } > 139: > 140: MemTag VMATree::get_new_tag(const MemTag ex, const RequestInfo& req) const { This code would also benefit from a `Operation RequestInfo::op()` method which separates the `use_tag_inplace` cases. src/hotspot/share/nmt/vmatree.cpp line 175: > 173: // - since we are reserving, then `a` will be added to t2. (`y` is `a`) > 174: // - since we uncommitting (by reserving) then `a` is to be subtracted from t1. (`x` is `-a`). > 175: // - amount of uncommitted size is in table `commit[1][4,5]` which is `-a,0` that means subtract `a` from t1. We can rename `t1` and `t2` to `current_tag`, `operation_tag` or `change_tag` src/hotspot/share/nmt/vmatree.cpp line 207: > 205: IntervalState exSt = n1->val().out; // existing state info > 206: assert(n1 != nullptr,"sanity"); > 207: assert(n2 != nullptr,"sanity"); Move these up, you'll have discovered that `n1` is nullptr when dereferencing it on line 205 otherwise. src/hotspot/share/nmt/vmatree.cpp line 380: > 378: } > 379: tty->print_cr(""); > 380: }; Convert to UL, under `trace` and a unique log tag for the VMATree src/hotspot/share/nmt/vmatree.cpp line 639: > 637: } > 638: > 639: // ************************************************************************************ Remove the 'noop' nodes that found inside the loop Remove the asterisks. src/hotspot/share/nmt/vmatree.hpp line 272: > 270: void compute_summary_diff(const SingleDiff::delta region_size, const MemTag t1, const StateType& ex, const RequestInfo& req, const MemTag new_tag, SummaryDiff& diff) const; > 271: void update_region(TreapNode* n1, TreapNode* n2, const RequestInfo& req, SummaryDiff& diff); > 272: int state_to_index(const StateType st) const { Can't this just use the enum values? `return static_cast(static_cast(st));` test/hotspot/gtest/nmt/test_vmatree.cpp line 254: > 252: else > 253: st.out.set_commit_stack(ES); > 254: tree.tree().upsert((VMATree::position)et.nodes[i], st); Please always use braces in if-stmts. ------------- Marked as reviewed by jsjolen (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2856676682 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099608295 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099608909 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099612695 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099618621 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099617515 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099631578 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099674188 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099691146 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099699625 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099711607 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2099785909 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2100006258 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2100013390 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2100015652 From rkennke at openjdk.org Wed May 21 11:32:23 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Wed, 21 May 2025 11:32:23 GMT Subject: RFR: 8350457: Implement JEP 519: Compact Object Headers [v4] In-Reply-To: References: Message-ID: > As title says. Roman Kennke 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 JDK-8350457 - Build COH CDS archives - Remove +UnlockExperimentalOptions from tests - 8350457: Support Compact Object Headers as product option ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24522/files - new: https://git.openjdk.org/jdk/pull/24522/files/ad389db3..0e3835a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24522&range=02-03 Stats: 349949 lines in 4000 files changed: 113733 ins; 216951 del; 19265 mod Patch: https://git.openjdk.org/jdk/pull/24522.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24522/head:pull/24522 PR: https://git.openjdk.org/jdk/pull/24522 From duke at openjdk.org Wed May 21 14:04:14 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 21 May 2025 14:04:14 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v6] In-Reply-To: References: Message-ID: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8350869: Fixed comments. Added skip exception to the test when symlinks are not supported. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25233/files - new: https://git.openjdk.org/jdk/pull/25233/files/f541fd6b..a6ff5001 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25233&range=04-05 Stats: 25 lines in 2 files changed: 10 ins; 10 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25233/head:pull/25233 PR: https://git.openjdk.org/jdk/pull/25233 From duke at openjdk.org Wed May 21 14:04:14 2025 From: duke at openjdk.org (Anton Artemov) Date: Wed, 21 May 2025 14:04:14 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v5] In-Reply-To: References: Message-ID: On Tue, 20 May 2025 22:17:47 GMT, David Holmes wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8350869: Clean up of the test, error handling in get_path_to_target > > src/hotspot/os/windows/os_windows.cpp line 4643: > >> 4641: // One does not need extra character in the end, from documentation: >> 4642: // "If the function fails because lpszFilePath is too small to hold the string plus the terminating null character, >> 4643: // the return value is the required buffer size, in TCHARs. This value INCLUDES the size of the terminating null character." > > A simple: > > // Returned value includes the terminating null character. > > will suffice. Thanks, addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4657: > >> 4655: // "If the function succeeds, the return value is the length of the string received by lpszFilePath, >> 4656: // in TCHARs.This value DOES NOT INCLUDE the size of the terminating null character." >> 4657: // So the return value is ONE LESS than target_path_size if everything is ok > > Again please simplify: > > // The returned size is the length excluding the terminating null character. Thanks, addressed in the latest commit. > src/hotspot/os/windows/os_windows.cpp line 4672: > >> 4670: } >> 4671: >> 4672: path_to_target[target_path_size - 1] = '\0'; > > Why are we explicitly adding the null character ourselves? It was not clear from the documentation if the termination character is copied. It does get copied. Addressed in the latest commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2100377116 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2100377397 PR Review Comment: https://git.openjdk.org/jdk/pull/25233#discussion_r2100380494 From lmesnik at openjdk.org Wed May 21 15:09:55 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 21 May 2025 15:09:55 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: <4L78FN5dBp6so8QWalypTvm2lnXb9GU6zl3Hw6hK6Go=.26715817-5092-4489-ba9a-bf3a9800c478@github.com> On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for fixing this! ------------- Marked as reviewed by lmesnik (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2858114150 From ccheung at openjdk.org Wed May 21 16:03:04 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 21 May 2025 16:03:04 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location Message-ID: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> This is to revert part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028) so that CDS archives can be found in the case that JVM is in a non-variant location. Also added a test case for this scenario. Sanity tested tiers 1 and 2. ------------- Commit messages: - 8353504: CDS archives are not found when JVM is in non-variant location Changes: https://git.openjdk.org/jdk/pull/25361/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25361&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353504 Stats: 99 lines in 3 files changed: 94 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25361/head:pull/25361 PR: https://git.openjdk.org/jdk/pull/25361 From mgronlun at openjdk.org Wed May 21 16:22:54 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 21 May 2025 16:22:54 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v6] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:04:14 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Fixed comments. Added skip exception to the test when symlinks are not supported. Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2858412795 From iklam at openjdk.org Wed May 21 18:23:54 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 21 May 2025 18:23:54 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location In-Reply-To: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: On Wed, 21 May 2025 15:54:39 GMT, Calvin Cheung wrote: > Although this fix reverts part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), gtestLauncher still works the way it was described in JDK-8348028. > Also added a test case to test the default CDS archive can be found from a non-variant location. > > Sanity tested tiers 1 and 2. LGTM. ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25361#pullrequestreview-2858729591 From shade at openjdk.org Wed May 21 19:05:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 21 May 2025 19:05:51 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location In-Reply-To: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: <1mNDdMMo8ffyVfOMeiqHI_5MIpIkW3BgGdqj6dBCJXw=.e9e4f421-8e24-41a7-b209-a0686a57ba67@github.com> On Wed, 21 May 2025 15:54:39 GMT, Calvin Cheung wrote: > Although this fix reverts part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), gtestLauncher still works the way it was described in JDK-8348028. > Also added a test case to test the default CDS archive can be found from a non-variant location. > > Sanity tested tiers 1 and 2. Thank you for doing this! I allocated some of my time to handle this in time for JDK 25 as well :) I am confused about the fix though. Let me see if I get it right: we end up calling `os::jvm_path`, which uses `Abstract_VM_Version::vm_variant()` only when `Arguments::executing_unit_tests()`. Otherwise it asks `dladdr` -> `realpath` from really running `libjvm.so`. It basically gets us to the state prior to [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), which is good. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25361#pullrequestreview-2858830596 From ccheung at openjdk.org Wed May 21 19:13:29 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 21 May 2025 19:13:29 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location [v2] In-Reply-To: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: > Although this fix reverts part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), gtestLauncher still works the way it was described in JDK-8348028. > Also added a test case to test the default CDS archive can be found from a non-variant location. > > Sanity tested tiers 1 and 2. Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: update test case comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25361/files - new: https://git.openjdk.org/jdk/pull/25361/files/7ab3b809..78ff224b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25361&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25361&range=00-01 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25361.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25361/head:pull/25361 PR: https://git.openjdk.org/jdk/pull/25361 From gziemski at openjdk.org Wed May 21 19:46:58 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 21 May 2025 19:46:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:15:15 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed a missed change in test. For this case: {// Check committing into a reserved region inherits the call stacks VMATree::RegionData call_stack_test(si_1, mtTest); VMATree::RegionData call_stack_none(si_2, mtNone); VMATree::RegionData call_stack_nmt(si_2, mtNMT); Tree tree; tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region tree.print_timeline_on(); } I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this: ``` 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123456789 AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... Legend: A - Test (reserved) b - Test (committed) C - Test (reserved) . - None (free/released) I was expecting this: ``` 1 2 3 4 5 6 0123456789012345678901234567890123456789012345678901234567890123456789 AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... Legend: A - Test (reserved) b - Native Memory Tracking (committed) C - Test (reserved) . - None (free/released) I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2899055965 From ccheung at openjdk.org Wed May 21 20:31:53 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 21 May 2025 20:31:53 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location [v2] In-Reply-To: <1mNDdMMo8ffyVfOMeiqHI_5MIpIkW3BgGdqj6dBCJXw=.e9e4f421-8e24-41a7-b209-a0686a57ba67@github.com> References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> <1mNDdMMo8ffyVfOMeiqHI_5MIpIkW3BgGdqj6dBCJXw=.e9e4f421-8e24-41a7-b209-a0686a57ba67@github.com> Message-ID: On Wed, 21 May 2025 19:02:55 GMT, Aleksey Shipilev wrote: > I am confused about the fix though. Let me see if I get it right: we end up calling `os::jvm_path`, which uses `Abstract_VM_Version::vm_variant()` only when `Arguments::executing_unit_tests()`. Otherwise it asks `dladdr` -> `realpath` from really running `libjvm.so`. > Yes, the code under the `Arguments::executing_unit_tests()` condition is for gtestLauncher. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25361#issuecomment-2899156240 From mseledtsov at openjdk.org Wed May 21 20:31:53 2025 From: mseledtsov at openjdk.org (Mikhailo Seledtsov) Date: Wed, 21 May 2025 20:31:53 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: <-rGf3Cfj34SX1QlPIp1vyVRWGc67aFxFmbAqNC2iMyo=.d6eaa386-b98f-45e8-8035-94b5cf5f159a@github.com> On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments Thanks for the updates. Changes look good to me. ------------- Marked as reviewed by mseledtsov (Committer). PR Review: https://git.openjdk.org/jdk/pull/24948#pullrequestreview-2859031087 From iklam at openjdk.org Wed May 21 21:33:29 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 21 May 2025 21:33:29 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element Message-ID: When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. The fix is simple: - if (do_substitute) { + if (do_substitute && remove_prefix_len > 0) { I also improved the logs to help debugging classpath mismatches when using the AOT cache. ------------- Commit messages: - 8356308: Assert with -Xlog:class+path when classpath has an empty element Changes: https://git.openjdk.org/jdk/pull/25372/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25372&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356308 Stats: 101 lines in 4 files changed: 89 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25372/head:pull/25372 PR: https://git.openjdk.org/jdk/pull/25372 From iklam at openjdk.org Wed May 21 21:43:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 21 May 2025 21:43:51 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location [v2] In-Reply-To: References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: On Wed, 21 May 2025 19:13:29 GMT, Calvin Cheung wrote: >> Although this fix reverts part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), gtestLauncher still works the way it was described in JDK-8348028. >> Also added a test case to test the default CDS archive can be found from a non-variant location. >> >> Sanity tested tiers 1 and 2. > > Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: > > update test case comment Marked as reviewed by iklam (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25361#pullrequestreview-2859191290 From ccheung at openjdk.org Wed May 21 22:15:56 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 21 May 2025 22:15:56 GMT Subject: RFR: 8353504: CDS archives are not found when JVM is in non-variant location [v2] In-Reply-To: References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: On Wed, 21 May 2025 21:41:14 GMT, Ioi Lam wrote: >> Calvin Cheung has updated the pull request incrementally with one additional commit since the last revision: >> >> update test case comment > > Marked as reviewed by iklam (Reviewer). Thanks @iklam @shipilev for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25361#issuecomment-2899376387 From ccheung at openjdk.org Wed May 21 22:15:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Wed, 21 May 2025 22:15:57 GMT Subject: Integrated: 8353504: CDS archives are not found when JVM is in non-variant location In-Reply-To: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> References: <1sxDu7VfhVFP8vHrWBM5fBI7fIL83sf8ns5vVzPhwKw=.20c956af-7fa9-41c1-8a50-774d44232ad1@github.com> Message-ID: On Wed, 21 May 2025 15:54:39 GMT, Calvin Cheung wrote: > Although this fix reverts part of the change for [JDK-8348028](https://bugs.openjdk.org/browse/JDK-8348028), gtestLauncher still works the way it was described in JDK-8348028. > Also added a test case to test the default CDS archive can be found from a non-variant location. > > Sanity tested tiers 1 and 2. This pull request has now been integrated. Changeset: f687cac8 Author: Calvin Cheung URL: https://git.openjdk.org/jdk/commit/f687cac88946b397d043e16ce3adc7b66a205af8 Stats: 100 lines in 3 files changed: 95 ins; 2 del; 3 mod 8353504: CDS archives are not found when JVM is in non-variant location Reviewed-by: iklam, shade ------------- PR: https://git.openjdk.org/jdk/pull/25361 From gziemski at openjdk.org Wed May 21 22:31:58 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 21 May 2025 22:31:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 10:15:15 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > fixed a missed change in test. Changes requested by gziemski (Reviewer). test/hotspot/gtest/nmt/test_vmatree.cpp line 318: > 316: Tree tree; > 317: VMATree::RegionData rd1(si[0], mtTest); > 318: VMATree::RegionData rd2(si[1], mtNone); We keep using those later in and it is hard to keep track of what `rd1` is. I suggest we use better names for those, such as `rd_Test`, then I know what mem_tag that region uses without having to go back. I renamed other instances, like `call_stack_2` as well. I have changed lots of those and here is a diff file with this change: [gerard.diff.zip](https://github.com/user-attachments/files/20376150/gerard.diff.zip) ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2859278402 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101279884 From duke at openjdk.org Thu May 22 03:56:52 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 03:56:52 GMT Subject: RFR: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails [v6] In-Reply-To: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> References: <6RndUQbIlGpa-ox2yM5CsgsvMn5VllcLz3pfU_lYxkQ=.eb7d1cb7-67d2-412a-a000-b5a01ec1cf2e@github.com> Message-ID: On Wed, 21 May 2025 06:54:37 GMT, PAWAN CHAWDHARY wrote: >> 8352926: New test TestDockerMemoryMetricsSubgroup.java fails > > PAWAN CHAWDHARY has updated the pull request incrementally with one additional commit since the last revision: > > address review comments @pawanchawdhary1 Your change (at version 5e1f9240b379356fb8d5e0db1587216d1cbeed0f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24948#issuecomment-2899823355 From azafari at openjdk.org Thu May 22 06:55:37 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 06:55:37 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v30] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: some comments changed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/7d10accc..e3242196 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=28-29 Stats: 443 lines in 1 file changed: 21 ins; 3 del; 419 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu May 22 07:36:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 07:36:59 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: <-OJagqOz5mi6hsyVkevfeCaw3_HoXUd0c_06abwhL8E=.fb09a2bd-ff99-403e-b6c7-2369e5f0cfe1@github.com> On Wed, 21 May 2025 08:22:06 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> impl of new visualization in one test case, for getting feedback. > > src/hotspot/share/nmt/vmatree.cpp line 113: > >> 111: const SIndex rq = req.callstack; >> 112: const int op = req.op_to_index(); >> 113: assert(op >= 0 && op < 4, "should be"); > > Add this assert to the method above as well? Done. > src/hotspot/share/nmt/vmatree.cpp line 140: > >> 138: } >> 139: >> 140: MemTag VMATree::get_new_tag(const MemTag ex, const RequestInfo& req) const { > > This code would also benefit from a `Operation RequestInfo::op()` method which separates the `use_tag_inplace` cases. Done. > src/hotspot/share/nmt/vmatree.cpp line 175: > >> 173: // - since we are reserving, then `a` will be added to t2. (`y` is `a`) >> 174: // - since we uncommitting (by reserving) then `a` is to be subtracted from t1. (`x` is `-a`). >> 175: // - amount of uncommitted size is in table `commit[1][4,5]` which is `-a,0` that means subtract `a` from t1. > > We can rename `t1` and `t2` to `current_tag`, `operation_tag` or `change_tag` Done. > src/hotspot/share/nmt/vmatree.cpp line 207: > >> 205: IntervalState exSt = n1->val().out; // existing state info >> 206: assert(n1 != nullptr,"sanity"); >> 207: assert(n2 != nullptr,"sanity"); > > Move these up, you'll have discovered that `n1` is nullptr when dereferencing it on line 205 otherwise. Done. > src/hotspot/share/nmt/vmatree.cpp line 639: > >> 637: } >> 638: >> 639: // ************************************************************************************ Remove the 'noop' nodes that found inside the loop > > Remove the asterisks. Done > src/hotspot/share/nmt/vmatree.hpp line 272: > >> 270: void compute_summary_diff(const SingleDiff::delta region_size, const MemTag t1, const StateType& ex, const RequestInfo& req, const MemTag new_tag, SummaryDiff& diff) const; >> 271: void update_region(TreapNode* n1, TreapNode* n2, const RequestInfo& req, SummaryDiff& diff); >> 272: int state_to_index(const StateType st) const { > > Can't this just use the enum values? `return static_cast(static_cast(st));` Unfortunately not. Later in the main PR for porting VMATree to NMT, we needed to redefine `Commit` to be `3` and now it is `2`. > test/hotspot/gtest/nmt/test_vmatree.cpp line 254: > >> 252: else >> 253: st.out.set_commit_stack(ES); >> 254: tree.tree().upsert((VMATree::position)et.nodes[i], st); > > Please always use braces in if-stmts. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101854213 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101851511 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101851150 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101850875 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101850463 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101850212 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101848047 From azafari at openjdk.org Thu May 22 07:43:09 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 07:43:09 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: <4mvXRiaACFXbMiQCUJQ_lyX6CIAyvy7A4Leuix7Fe4U=.3387a0f2-477f-4147-80dd-bcf196faf0ab@github.com> On Wed, 21 May 2025 07:50:18 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> impl of new visualization in one test case, for getting feedback. > > src/hotspot/share/nmt/vmatree.cpp line 34: > >> 32: // Semantics >> 33: // This tree is used to store and track the state of virtual memory regions. >> 34: // The nodes in the tree are key-value pairs where key is the memory address and the value is the State of the memory regions. > > the key Done. > src/hotspot/share/nmt/vmatree.cpp line 35: > >> 33: // This tree is used to store and track the state of virtual memory regions. >> 34: // The nodes in the tree are key-value pairs where key is the memory address and the value is the State of the memory regions. >> 35: // State of a region describes whether the region is released, reserved or committed, which MemTag it has and where in > > The state (State if it's a type) Done. > src/hotspot/share/nmt/vmatree.cpp line 46: > >> 44: // changes needed for the affected regions in the tree. For each operation a request >> 45: // () is sent to the tree to handle. >> 46: // > > `` > `During these operations, the tree should handle the > // changes needed for the affected regions in the tree > > > I think that this can be removed without loss of information, it is clear that the tree must do this. Done. Not sure as you wanted. Please double check! > src/hotspot/share/nmt/vmatree.cpp line 47: > >> 45: // () is sent to the tree to handle. >> 46: // >> 47: // The expected changes are described here for each operation: > > I agree with the semantics of these operations. Hmm, what should I do here? > src/hotspot/share/nmt/vmatree.cpp line 62: > >> 60: // - if the region is in Released state >> 61: // - mark the region as both Reserved and Committed >> 62: // - store the call-stack of the request to the reserve call-stack > > So if `mtNone` is provided in this case, we will end up with `mtNone` as the category for this committed region? OK. True. What is the proper thing to do for this case? > src/hotspot/share/nmt/vmatree.cpp line 102: > >> 100: {es, es, es} // op == Uncommit >> 101: }; >> 102: if (op == 2 && ex == StateType::Released) { > > This is using the information that `op == 2` is 'commit', this should be well-typed. > > It's better to do something like this: > > > const Operation op = req.op(); > if (op == Operation::Commit && ex == StateType::released) { > return rq; > } else { > return result[opi][state_to_index(ex)]; > } > > > Also, just add a small comment on why we treat committed specially here. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101866848 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101866548 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101866295 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101862999 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101865193 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101861180 From dholmes at openjdk.org Thu May 22 07:50:58 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 May 2025 07:50:58 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v6] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:04:14 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Fixed comments. Added skip exception to the test when symlinks are not supported. Updates look fine. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25233#pullrequestreview-2860155925 From duke at openjdk.org Thu May 22 07:50:58 2025 From: duke at openjdk.org (duke) Date: Thu, 22 May 2025 07:50:58 GMT Subject: RFR: 8350869: os::stat doesn't follow symlinks on Windows [v6] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 14:04:14 GMT, Anton Artemov wrote: >> This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. >> >> I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. >> >> Tested in tiers 1-3. A separate test added. > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8350869: Fixed comments. Added skip exception to the test when symlinks are not supported. @toxaart Your change (at version a6ff5001ea00b6b721cb6e65d6ce696dae5d45e4) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25233#issuecomment-2900243914 From duke at openjdk.org Thu May 22 07:59:08 2025 From: duke at openjdk.org (Anton Artemov) Date: Thu, 22 May 2025 07:59:08 GMT Subject: Integrated: 8350869: os::stat doesn't follow symlinks on Windows In-Reply-To: References: Message-ID: On Wed, 14 May 2025 14:54:48 GMT, Anton Artemov wrote: > This PR addresses an issue on Windows, where a class file could not be loaded by a symbolic link. > > I added a check if a wide path is a symbolic link (soft one) and a method for dereferencing. Both os::stat() and os::open() on Windows now can handle such links. > > Tested in tiers 1-3. A separate test added. This pull request has now been integrated. Changeset: 85b24c3c Author: Anton Artemov Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/85b24c3c4e93d0203a8cfcd5f029e18eebc93f47 Stats: 204 lines in 2 files changed: 200 ins; 3 del; 1 mod 8350869: os::stat doesn't follow symlinks on Windows Reviewed-by: dholmes, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/25233 From jsjolen at openjdk.org Thu May 22 08:04:55 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 22 May 2025 08:04:55 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: <4mvXRiaACFXbMiQCUJQ_lyX6CIAyvy7A4Leuix7Fe4U=.3387a0f2-477f-4147-80dd-bcf196faf0ab@github.com> References: <4mvXRiaACFXbMiQCUJQ_lyX6CIAyvy7A4Leuix7Fe4U=.3387a0f2-477f-4147-80dd-bcf196faf0ab@github.com> Message-ID: On Thu, 22 May 2025 07:38:13 GMT, Afshin Zafari wrote: >> src/hotspot/share/nmt/vmatree.cpp line 47: >> >>> 45: // () is sent to the tree to handle. >>> 46: // >>> 47: // The expected changes are described here for each operation: >> >> I agree with the semantics of these operations. > > Hmm, what should I do here? Nothing, I'm saying "good job, I agree with these definitions, good that we could get semantics that we agree on!" :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2101908180 From azafari at openjdk.org Thu May 22 08:22:48 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 08:22:48 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v31] In-Reply-To: References: Message-ID: <-7vvW74x4ah7gPHgRUNZn56Su1cUKBk3JO_tEOZ2kYQ=.f0f6e43f-52de-456b-93df-fb1cd63cfaf3@github.com> > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: Johan's comments. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/e3242196..e1a6bfff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=29-30 Stats: 77 lines in 4 files changed: 25 ins; 7 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu May 22 08:31:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 08:31:57 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski wrote: > For this case: > > ``` > {// Check committing into a reserved region inherits the call stacks > VMATree::RegionData call_stack_test(si_1, mtTest); > VMATree::RegionData call_stack_none(si_2, mtNone); > VMATree::RegionData call_stack_nmt(si_2, mtNMT); > Tree tree; > tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree > tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region > tree.print_timeline_on(); > } > ``` > > I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Test (committed) > C - Test (reserved) > . - None (free/released) > ``` > > I was expecting this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Native Memory Tracking (committed) > C - Test (reserved) > . - None (free/released) > ``` > > I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter? If we want to mtNMT tag be used for commit, we should pass `use_tag_inplace` as `false` or: `tree.commit_mapping(a,b call_stack_nmt);` commit + mtNone is an issue that Johan also mentioned/noticed. We have to define this new case, then I impl it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2900358436 From azafari at openjdk.org Thu May 22 08:57:57 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 08:57:57 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 22:28:21 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a missed change in test. > > test/hotspot/gtest/nmt/test_vmatree.cpp line 318: > >> 316: Tree tree; >> 317: VMATree::RegionData rd1(si[0], mtTest); >> 318: VMATree::RegionData rd2(si[1], mtNone); > > We keep using those later in and it is hard to keep track of what `rd1` is. I suggest we use better names for those, such as `rd_Test`, then I know what mem_tag that region uses without having to go back. > > I renamed other instances, like `call_stack_2` as well. > > I have changed lots of those and here is a diff file with this change: [gerard.diff.zip](https://github.com/user-attachments/files/20376150/gerard.diff.zip) Unfortunately, your patch couldn't be applied, since it cannot find some expected text in my local code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2102017148 From jsjolen at openjdk.org Thu May 22 09:04:00 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Thu, 22 May 2025 09:04:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Thu, 22 May 2025 08:55:30 GMT, Afshin Zafari wrote: >> test/hotspot/gtest/nmt/test_vmatree.cpp line 318: >> >>> 316: Tree tree; >>> 317: VMATree::RegionData rd1(si[0], mtTest); >>> 318: VMATree::RegionData rd2(si[1], mtNone); >> >> We keep using those later in and it is hard to keep track of what `rd1` is. I suggest we use better names for those, such as `rd_Test`, then I know what mem_tag that region uses without having to go back. >> >> I renamed other instances, like `call_stack_2` as well. >> >> I have changed lots of those and here is a diff file with this change: [gerard.diff.zip](https://github.com/user-attachments/files/20376150/gerard.diff.zip) > > Unfortunately, your patch couldn't be applied, since it cannot find some expected text in my local code. It's a lot easier to apply a patch by merging with git branches. Send the branch that's on your github instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2102028775 From azafari at openjdk.org Thu May 22 09:10:00 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 09:10:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: On Wed, 21 May 2025 19:44:18 GMT, Gerard Ziemski wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> fixed a missed change in test. > > For this case: > > > {// Check committing into a reserved region inherits the call stacks > VMATree::RegionData call_stack_test(si_1, mtTest); > VMATree::RegionData call_stack_none(si_2, mtNone); > VMATree::RegionData call_stack_nmt(si_2, mtNMT); > Tree tree; > tree.reserve_mapping(0, 50, call_stack_test); // reserve in an empty tree > tree.commit_mapping(25, 10, call_stack_nmt, true); // commit at the middle of the region > tree.print_timeline_on(); > } > > > I know that we are passing `true` for `use_tag_inplace` here, but it just does not feel right to get this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Test (committed) > C - Test (reserved) > . - None (free/released) > > > I was expecting this: > > ``` > 1 2 3 4 5 6 > 0123456789012345678901234567890123456789012345678901234567890123456789 > AAAAAAAAAAAAAAAAAAAAAAAAAbbbbbbbbbbCCCCCCCCCCCCCCC.................... > Legend: > A - Test (reserved) > b - Native Memory Tracking (committed) > C - Test (reserved) > . - None (free/released) > > > I don't think we should be allowing `use_tag_inplace` to modify the behavior this much. Instead of `use_tag_inplace` we could accept mtNone to inherit the tag already in place? No need for that extra parameter? @gerard-ziemski , in the new visualization format we write Legend with letters `A, a, B, b, C, c, D, d` that are not reflecting the meanings `Reserved, Released, Committed`. We could use `r, ., C` instead. And since they are not needed to repeat for every visualization, we can describe them at the top of the file once and avoid repeating them. We also may need to define letters for tags and/or call-stacks. I have the suggestion as: // 1 2 3 4 5 6 7 // 0123456789012345678901234567890123456789012345678901234567890123456789 // CCCCCCCCCCCCCCCCCCCCrrrrrCCCCCCCCCCrrrrrCCCCCCCCCC.................... // TTTTTTTTTTTTTTTTTTTTnnnnnGGGGGGGGGGdddddJJJJJJJJJJ // Legend: // T mtTest // n mtNMT // G mtGC // d mtClassShared(CDS) // J mtJavaHeap I used alternative capital and small letters just for better readability. This style can be used also for call-stacks. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24028#issuecomment-2900463147 From cnorrbin at openjdk.org Thu May 22 09:11:05 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Thu, 22 May 2025 09:11:05 GMT Subject: RFR: 8356868: Not all cgroup parameters are made available Message-ID: Hi everyone, This PR improves cgroup support by exposing additional parameters that are currently not available. These parameters would enable more advanced features that rely on CPU and memory usage data. The new parameters are: - CPU usage: `cpuacct.usage` (cgroup v1) and `cpu.stat` (cgroup v2), which allow precise tracking of consumed CPU time. - Peak memory usage: `memory.peak` (cgroup v2). While the cgroup v1 equivalent (`memory.max_usage_in_bytes`) was already available, cgroup v2 previously returned `OSCONTAINER_ERROR` ? this has now been fixed. - Memory throttle limit: `memory.high` (cgroup v2). There is no direct equivalent in cgroup v1, but since most systems use cgroup v2, exposing this parameter enables finer-grained memory control for those systems. Testing: - All container tests under `/test/hotspot/jtreg/containers/` - Manually inspected the new parameters in both cgroup v1 and v2 container environments with the relevant settings applied. ------------- Commit messages: - added cgroup parameters Changes: https://git.openjdk.org/jdk/pull/25388/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25388&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356868 Stats: 163 lines in 10 files changed: 148 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/25388.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25388/head:pull/25388 PR: https://git.openjdk.org/jdk/pull/25388 From dholmes at openjdk.org Thu May 22 09:50:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 22 May 2025 09:50:52 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element In-Reply-To: References: Message-ID: On Wed, 21 May 2025 21:28:16 GMT, Ioi Lam wrote: > When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. > > The fix is simple: > > > - if (do_substitute) { > + if (do_substitute && remove_prefix_len > 0) { > > > I also improved the logs to help debugging classpath mismatches when using the AOT cache. This sounds like a bug in `-cp` parsing to me! ------------- PR Comment: https://git.openjdk.org/jdk/pull/25372#issuecomment-2900591815 From rkennke at openjdk.org Thu May 22 10:51:17 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 22 May 2025 10:51:17 GMT Subject: RFR: 8350457: Implement JEP 519: Compact Object Headers [v4] In-Reply-To: References: Message-ID: <3fR6zX1qSuk3WEkTVaMsBExyTHBtglsOY6R4P2eMkhw=.aec9d90b-e370-49ed-8b0b-a4989606c0b8@github.com> On Wed, 21 May 2025 11:32:23 GMT, Roman Kennke wrote: >> As title says. > > Roman Kennke 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 JDK-8350457 > - Build COH CDS archives > - Remove +UnlockExperimentalOptions from tests > - 8350457: Support Compact Object Headers as product option JEP has been targeted, I think it is ready to go. Thank you all! ------------- PR Comment: https://git.openjdk.org/jdk/pull/24522#issuecomment-2900766164 From rkennke at openjdk.org Thu May 22 10:51:18 2025 From: rkennke at openjdk.org (Roman Kennke) Date: Thu, 22 May 2025 10:51:18 GMT Subject: Integrated: 8350457: Implement JEP 519: Compact Object Headers In-Reply-To: References: Message-ID: On Tue, 8 Apr 2025 19:32:02 GMT, Roman Kennke wrote: > As title says. This pull request has now been integrated. Changeset: 1e57648a Author: Roman Kennke URL: https://git.openjdk.org/jdk/commit/1e57648abd569295f42dc19c00edfcc90c00b1d3 Stats: 83 lines in 25 files changed: 0 ins; 13 del; 70 mod 8350457: Implement JEP 519: Compact Object Headers Reviewed-by: mdoerr, coleenp, zgu ------------- PR: https://git.openjdk.org/jdk/pull/24522 From azafari at openjdk.org Thu May 22 10:53:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 10:53:59 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v32] In-Reply-To: References: Message-ID: > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: 'rd*' ->'rd__cs' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/e1a6bfff..7c17dbb5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=30-31 Stats: 351 lines in 1 file changed: 0 ins; 0 del; 351 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From azafari at openjdk.org Thu May 22 13:37:39 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 13:37:39 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: References: Message-ID: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> > In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. > This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: visualizations added. 1st try. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24028/files - new: https://git.openjdk.org/jdk/pull/24028/files/7c17dbb5..14bfe06f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24028&range=31-32 Stats: 311 lines in 1 file changed: 283 ins; 1 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/24028.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24028/head:pull/24028 PR: https://git.openjdk.org/jdk/pull/24028 From duke at openjdk.org Thu May 22 17:11:08 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Thu, 22 May 2025 17:11:08 GMT Subject: Integrated: 8352926: New test TestDockerMemoryMetricsSubgroup.java fails In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 13:04:15 GMT, PAWAN CHAWDHARY wrote: > 8352926: New test TestDockerMemoryMetricsSubgroup.java fails This pull request has now been integrated. Changeset: 9ca1004e Author: pawan chawdhary Committer: Mikhailo Seledtsov URL: https://git.openjdk.org/jdk/commit/9ca1004e76a614328cd2eb7546143839c4d2f810 Stats: 118 lines in 3 files changed: 115 ins; 3 del; 0 mod 8352926: New test TestDockerMemoryMetricsSubgroup.java fails Reviewed-by: mseledtsov, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/24948 From azafari at openjdk.org Thu May 22 19:24:59 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 19:24:59 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v28] In-Reply-To: References: Message-ID: <-nZkWhaSNUa7LhzEFC51DtMkTHECfnMprEqYMzcQA04=.047a5ebf-edc8-4fe0-aab8-615de5fc21ad@github.com> On Wed, 21 May 2025 09:13:24 GMT, Johan Sj?len wrote: >> Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: >> >> impl of new visualization in one test case, for getting feedback. > > src/hotspot/share/nmt/vmatree.cpp line 380: > >> 378: } >> 379: tty->print_cr(""); >> 380: }; > > Convert to UL, under `trace` and a unique log tag for the VMATree Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2103252426 From azafari at openjdk.org Thu May 22 19:25:00 2025 From: azafari at openjdk.org (Afshin Zafari) Date: Thu, 22 May 2025 19:25:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v29] In-Reply-To: References: Message-ID: <-pNV1zmgyRlXn9PRdE2UMhBccvRhiIdDuarRu7ErbeY=.b1bb1282-7aed-4a24-aa38-464c48110088@github.com> On Thu, 22 May 2025 09:01:11 GMT, Johan Sj?len wrote: >> Unfortunately, your patch couldn't be applied, since it cannot find some expected text in my local code. > > It's a lot easier to apply a patch by merging with git branches. Send the branch that's on your github instead. Thanks for the advice. I have already made the changes in the patch in my own code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2103251355 From iveresov at openjdk.org Thu May 22 20:25:21 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Thu, 22 May 2025 20:25:21 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v23] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 88 commits: - Merge branch 'master' into pp2 - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - 8356885: Don't emit C1 profiling for casts if TypeProfileCasts is off Reviewed-by: vlivanov, kvn - 8352755: Misconceptions about j.text.DecimalFormat digits during parsing Reviewed-by: naoto - ... and 78 more: https://git.openjdk.org/jdk/compare/139a05d0...7a350671 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22 Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iveresov at openjdk.org Fri May 23 02:54:55 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Fri, 23 May 2025 02:54:55 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v24] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request incrementally with one additional commit since the last revision: Missing part of the merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24886/files - new: https://git.openjdk.org/jdk/pull/24886/files/7a350671..a1958ece Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=22-23 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From iklam at openjdk.org Fri May 23 04:31:39 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 23 May 2025 04:31:39 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: References: Message-ID: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: - Fixed merge - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @erikj79 comments -- makefile indentation - Fixed merge - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=11 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From duke at openjdk.org Fri May 23 04:33:36 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Fri, 23 May 2025 04:33:36 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v3] In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: > 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 PAWAN CHAWDHARY 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 branch 'master' into 8354475 - Update TestDockerMemoryMetricsSubgroup.java remove extra space - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 ------------- Changes: https://git.openjdk.org/jdk/pull/24930/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24930&range=02 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24930.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24930/head:pull/24930 PR: https://git.openjdk.org/jdk/pull/24930 From erikj at openjdk.org Fri May 23 13:15:58 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 23 May 2025 13:15:58 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v12] In-Reply-To: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> References: <4d8_PD1_wragYvfsjvrlwTubhP-Qeo1knf4inR5dWEM=.90cc62b2-1c80-4fbe-9413-afaed3d730a8@github.com> Message-ID: <7V06iTghjLDxbNUVkjjhLzZ8qNJ54W74R10Iy_HE6M8=.17c02df0-4cd6-4b9b-a7ad-d1404c17c817@github.com> On Fri, 23 May 2025 04:31:39 GMT, Ioi Lam wrote: >> This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) >> >> - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" >> - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache >> - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options >> >> Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. >> >> Examples: >> >> >> # Create an AOT cache with a single command: >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> Hello World >> Temporary AOTConfiguration recorded: foo.aot.config >> Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config >> [...] >> Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot >> AOTCache creation is complete: foo.aot 10240000 bytes >> >> # Create logging file for the AOT cache assembly phase >> $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt >> $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld >> >> >> Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). > > Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: > > - Fixed merge > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @erikj79 comments -- makefile indentation > - Fixed merge > - @erikj79 comments > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - @vnkozlov comments > - added info about JTREG/AOT_JDK testing > - fixed whitespace > - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 > - ... and 18 more: https://git.openjdk.org/jdk/compare/fdda7661...de16fdbd Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24942#pullrequestreview-2864370912 From duke at openjdk.org Sat May 24 05:23:45 2025 From: duke at openjdk.org (Lei Zhu) Date: Sat, 24 May 2025 05:23:45 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Message-ID: I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. ------------- Commit messages: - vm.flagless Changes: https://git.openjdk.org/jdk/pull/25427/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25427&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357408 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25427.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25427/head:pull/25427 PR: https://git.openjdk.org/jdk/pull/25427 From duke at openjdk.org Sat May 24 05:28:45 2025 From: duke at openjdk.org (Lei Zhu) Date: Sat, 24 May 2025 05:28:45 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v2] In-Reply-To: References: Message-ID: <5X9HUH8hOk-5re6kto7USC-nMsxk6zPt7YzDHuoO0cM=.e7592483-a70f-420d-857a-4a47f9fe6644@github.com> > I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. Lei Zhu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25427/files - new: https://git.openjdk.org/jdk/pull/25427/files/e1854747..4b47074f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25427&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25427&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25427.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25427/head:pull/25427 PR: https://git.openjdk.org/jdk/pull/25427 From duke at openjdk.org Mon May 26 07:35:30 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 26 May 2025 07:35:30 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState Message-ID: Hi, in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. Tested in tiers 1-4. ------------- Commit messages: - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Refactoring to static methods. - 8265754: Fixed indentation. - 8265754: Fixed indentation - 8265754: Fixed indentation and lost newline. - 8265754: Fixed whitespaces errors. - 8265754: More work. - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Refactoring suspend/resume in the HandshakeState away Changes: https://git.openjdk.org/jdk/pull/25407/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8265754 Stats: 206 lines in 3 files changed: 119 ins; 82 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From shade at openjdk.org Mon May 26 09:07:31 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 09:07:31 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v2] In-Reply-To: <5X9HUH8hOk-5re6kto7USC-nMsxk6zPt7YzDHuoO0cM=.e7592483-a70f-420d-857a-4a47f9fe6644@github.com> References: <5X9HUH8hOk-5re6kto7USC-nMsxk6zPt7YzDHuoO0cM=.e7592483-a70f-420d-857a-4a47f9fe6644@github.com> Message-ID: On Sat, 24 May 2025 05:28:45 GMT, Lei Zhu wrote: >> I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. > > Lei Zhu has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: > > 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Yes, it should be `vm.flagless`, since it runs in driver mode with `executeLimitedTestJava`. But it should also remain `vm.debug & vm.bits == "64"`, because `CountBytecodes` option is `develop` (so it is not available in release builds), and the counter would likely overflow in 32-bit modes ([JDK-8350642](https://bugs.openjdk.org/browse/JDK-8350642) made the counter 64-bit only for 64-bit platforms). So just add `@requires vm.flagless`, leaving the other `@requires` alone. Run the test with both fastdebug and release builds to confirm it still works. ------------- PR Review: https://git.openjdk.org/jdk/pull/25427#pullrequestreview-2867754154 From azeller at openjdk.org Mon May 26 10:23:31 2025 From: azeller at openjdk.org (Arno Zeller) Date: Mon, 26 May 2025 10:23:31 GMT Subject: RFR: 8357448: AOT crashes on linux musl with AddReads.java Message-ID: Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. ------------- Commit messages: - Fix use after free. Changes: https://git.openjdk.org/jdk/pull/25446/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25446&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357448 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25446.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25446/head:pull/25446 PR: https://git.openjdk.org/jdk/pull/25446 From mbaesken at openjdk.org Mon May 26 10:27:52 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 26 May 2025 10:27:52 GMT Subject: RFR: 8357448: AOT crashes on linux musl with AddReads.java In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:12:24 GMT, Arno Zeller wrote: > Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. Marked as reviewed by mbaesken (Reviewer). seems we get strange unrelated error in GHA `Failed to resolve action download info. Error: No MediaTypeFormatter is available to read an object of type 'ActionDownloadInfoResponseCollection' from content with media type 'text/plain'.` ------------- PR Review: https://git.openjdk.org/jdk/pull/25446#pullrequestreview-2867959260 PR Comment: https://git.openjdk.org/jdk/pull/25446#issuecomment-2909218502 From shade at openjdk.org Mon May 26 10:40:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Mon, 26 May 2025 10:40:50 GMT Subject: RFR: 8357448: AOT crashes on linux musl with AddReads.java In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:12:24 GMT, Arno Zeller wrote: > Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. The use-after-free fix is indeed trivial. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25446#pullrequestreview-2867998201 From nbenalla at openjdk.org Mon May 26 13:07:06 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 26 May 2025 13:07:06 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - Update --release 25 symbol information for JDK 25 build 21 The macOS/AArch64 build 21 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 # Conflicts: # test/langtools/tools/javac/versions/Versions.java - ... and 4 more: https://git.openjdk.org/jdk/compare/bd095896...b79e5022 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=03 Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From duke at openjdk.org Mon May 26 13:30:11 2025 From: duke at openjdk.org (Anton Artemov) Date: Mon, 26 May 2025 13:30:11 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: References: Message-ID: > Hi, > > in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. > > Tested in tiers 1-4. Anton Artemov 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 10 additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8265754 - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Refactoring to static methods. - 8265754: Fixed indentation. - 8265754: Fixed indentation - 8265754: Fixed indentation and lost newline. - 8265754: Fixed whitespaces errors. - 8265754: More work. - Merge remote-tracking branch 'origin/master' into JDK-8265754 - 8265754: Refactoring suspend/resume in the HandshakeState away ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25407/files - new: https://git.openjdk.org/jdk/pull/25407/files/b852ba9c..0ee1abf2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25407&range=00-01 Stats: 6334 lines in 76 files changed: 4311 ins; 1622 del; 401 mod Patch: https://git.openjdk.org/jdk/pull/25407.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25407/head:pull/25407 PR: https://git.openjdk.org/jdk/pull/25407 From mdoerr at openjdk.org Mon May 26 15:53:56 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 26 May 2025 15:53:56 GMT Subject: RFR: 8357448: AOT crashes on linux musl with AddReads.java In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:12:24 GMT, Arno Zeller wrote: > Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. Thanks for fixing it! ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25446#pullrequestreview-2868809380 From duke at openjdk.org Tue May 27 05:43:33 2025 From: duke at openjdk.org (Lei Zhu) Date: Tue, 27 May 2025 05:43:33 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v3] In-Reply-To: References: Message-ID: > I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25427/files - new: https://git.openjdk.org/jdk/pull/25427/files/4b47074f..f74a1385 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25427&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25427&range=01-02 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25427.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25427/head:pull/25427 PR: https://git.openjdk.org/jdk/pull/25427 From shade at openjdk.org Tue May 27 07:40:52 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 May 2025 07:40:52 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v3] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 05:43:33 GMT, Lei Zhu wrote: >> I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Looks fine to me, thanks. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25427#pullrequestreview-2869963871 From duke at openjdk.org Tue May 27 08:42:50 2025 From: duke at openjdk.org (Lei Zhu) Date: Tue, 27 May 2025 08:42:50 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v2] In-Reply-To: References: <5X9HUH8hOk-5re6kto7USC-nMsxk6zPt7YzDHuoO0cM=.e7592483-a70f-420d-857a-4a47f9fe6644@github.com> Message-ID: On Mon, 26 May 2025 09:00:20 GMT, Aleksey Shipilev wrote: > Yes, it should be `vm.flagless`, since it runs in driver mode with `executeLimitedTestJava`. But it should also remain `vm.debug & vm.bits == "64"`, because `CountBytecodes` option is `develop` (so it is not available in release builds), and the counter would likely overflow in 32-bit modes ([JDK-8350642](https://bugs.openjdk.org/browse/JDK-8350642) made the counter 64-bit only for 64-bit platforms). > > So just add `@requires vm.flagless`, leaving the other `@requires` alone. > > Run the test with both fastdebug and release builds to confirm it still works. Thank you for your correction. I have modified it and it has passed the test. Please review it again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25427#issuecomment-2911676670 From duke at openjdk.org Tue May 27 09:06:51 2025 From: duke at openjdk.org (duke) Date: Tue, 27 May 2025 09:06:51 GMT Subject: RFR: 8357448: AOT crashes on linux musl with AddReads.java In-Reply-To: References: Message-ID: On Mon, 26 May 2025 10:12:24 GMT, Arno Zeller wrote: > Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. @ArnoZeller Your change (at version 6e470d491e7fe84f78df3fe8746032954906470f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25446#issuecomment-2911753336 From azeller at openjdk.org Tue May 27 09:13:55 2025 From: azeller at openjdk.org (Arno Zeller) Date: Tue, 27 May 2025 09:13:55 GMT Subject: Integrated: 8357448: AOT crashes on linux musl with AddReads.java In-Reply-To: References: Message-ID: <6O7Mmq_HuUtfn4sQbuMcpDPKWJZXbEQyEnal5kJJexY=.a039fb55-4f4e-4384-8e01-52ca9291ef89@github.com> On Mon, 26 May 2025 10:12:24 GMT, Arno Zeller wrote: > Trivial fix for a use-after-free. It was only an issue when AOT logging was enabled. This pull request has now been integrated. Changeset: f62b9780 Author: Arno Zeller Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/f62b9780c38ed3caa64726be5ea47667847157e3 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod 8357448: AOT crashes on linux musl with AddReads.java Reviewed-by: mbaesken, shade, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/25446 From dholmes at openjdk.org Tue May 27 09:42:54 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 27 May 2025 09:42:54 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: References: Message-ID: On Mon, 26 May 2025 13:30:11 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov 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 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - 8265754: Refactoring to static methods. > - 8265754: Fixed indentation. > - 8265754: Fixed indentation > - 8265754: Fixed indentation and lost newline. > - 8265754: Fixed whitespaces errors. > - 8265754: More work. > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - 8265754: Refactoring suspend/resume in the HandshakeState away This refactoring seems okay to me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25407#pullrequestreview-2870394317 From syan at openjdk.org Tue May 27 12:02:55 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 27 May 2025 12:02:55 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v3] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 05:43:33 GMT, Lei Zhu wrote: >> I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/25427#pullrequestreview-2870784230 From iklam at openjdk.org Tue May 27 21:55:30 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 27 May 2025 21:55:30 GMT Subject: RFR: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception Message-ID: Please review this trivial patch for printing exceptions that happened during AOT cache dumping. We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. ------------- Commit messages: - 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception Changes: https://git.openjdk.org/jdk/pull/25473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357917 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25473/head:pull/25473 PR: https://git.openjdk.org/jdk/pull/25473 From kvn at openjdk.org Tue May 27 21:55:30 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Tue, 27 May 2025 21:55:30 GMT Subject: RFR: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:47:49 GMT, Ioi Lam wrote: > Please review this trivial patch for printing exceptions that happened during AOT cache dumping. > > We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. Good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25473#pullrequestreview-2872813938 From iveresov at openjdk.org Tue May 27 21:57:11 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Tue, 27 May 2025 21:57:11 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v25] In-Reply-To: References: Message-ID: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: - Merge branch 'master' into pp2 - Missing part of the merge - Merge branch 'master' into pp2 - Merge branch 'master' into pp2 - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache - Merge branch 'master' into pp2 - Address Ioi's comments - Merge branch 'master' into pp2 - Address Ioi's comments - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368 ------------- Changes: https://git.openjdk.org/jdk/pull/24886/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24886&range=24 Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod Patch: https://git.openjdk.org/jdk/pull/24886.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24886/head:pull/24886 PR: https://git.openjdk.org/jdk/pull/24886 From jrose at openjdk.org Tue May 27 21:59:50 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 27 May 2025 21:59:50 GMT Subject: RFR: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:47:49 GMT, Ioi Lam wrote: > Please review this trivial patch for printing exceptions that happened during AOT cache dumping. > > We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. Good point fix. 20% of all API uses (82) of `java_lang_String::` are `as_utf8_String`. We should consider moving the check for null, and substitution of `"(null)"`, into `as_utf8_String` on the grounds that (a) there is widespread use of this API point to build diagnostic strings, and (b) we'd like to close the door on this kind of NPE more consistently. That is not needed for this point fix. Should be a followup bug, so we can review the handling of null in diagnostics in a fuller manner. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25473#pullrequestreview-2872830484 From jrose at openjdk.org Tue May 27 22:11:52 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 27 May 2025 22:11:52 GMT Subject: RFR: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:47:49 GMT, Ioi Lam wrote: > Please review this trivial patch for printing exceptions that happened during AOT cache dumping. > > We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. I filed https://bugs.openjdk.org/browse/JDK-8357921 to follow up later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25473#issuecomment-2914279617 From amenkov at openjdk.org Tue May 27 23:17:55 2025 From: amenkov at openjdk.org (Alex Menkov) Date: Tue, 27 May 2025 23:17:55 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default In-Reply-To: References: Message-ID: On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov wrote: > The fix turns on streaming output for attach operations. > Change in HotSpotVirtualMachine.java sets attach client property. > Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). > > Testing: tier1..tier8 Ping. Looking for reviewers for the fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25192#issuecomment-2914409840 From iklam at openjdk.org Wed May 28 02:42:57 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 02:42:57 GMT Subject: RFR: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception In-Reply-To: References: Message-ID: On Tue, 27 May 2025 22:09:23 GMT, John R Rose wrote: >> Please review this trivial patch for printing exceptions that happened during AOT cache dumping. >> >> We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. > > I filed https://bugs.openjdk.org/browse/JDK-8357921 to follow up later. Thanks @rose00 @vnkozlov for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25473#issuecomment-2914714044 From iklam at openjdk.org Wed May 28 02:42:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 02:42:58 GMT Subject: Integrated: 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:47:49 GMT, Ioi Lam wrote: > Please review this trivial patch for printing exceptions that happened during AOT cache dumping. > > We observed the crash when running tests with [JEP 514](https://openjdk.org/jeps/514), but the root cause is pre-existing. This pull request has now been integrated. Changeset: 72b9aafd Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/72b9aafd5a0dfb379a979f554fa99a767eef3e50 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8357917: Assert in MetaspaceShared::preload_and_dump() when printing exception Reviewed-by: kvn, jrose ------------- PR: https://git.openjdk.org/jdk/pull/25473 From sspitsyn at openjdk.org Wed May 28 03:31:52 2025 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Wed, 28 May 2025 03:31:52 GMT Subject: RFR: 8354460: Streaming output for attach API should be turned on by default In-Reply-To: References: Message-ID: <0hu_9EF54wNHmxS5a0l_uynlRmGkxKVeIJCghNFbJ7E=.4a520beb-8e8b-42e9-822c-cab8294c5247@github.com> On Mon, 12 May 2025 19:55:58 GMT, Alex Menkov wrote: > The fix turns on streaming output for attach operations. > Change in HotSpotVirtualMachine.java sets attach client property. > Change in attachListener.cpp sets server property (used when client does not specify the property in the request - this is the case when attach tool from older release connects to new VM). > > Testing: tier1..tier8 Looks good. ------------- Marked as reviewed by sspitsyn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25192#pullrequestreview-2873444194 From vklang at openjdk.org Wed May 28 08:59:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 28 May 2025 08:59:52 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. Can confirm that this observably mitigates the reported issue with Exchanger in ExchangeLoops. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915523409 From aph at openjdk.org Wed May 28 09:30:51 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 09:30:51 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. Good catch. It's useful to look at how this mistake was made. The code was edited by four or five different authors, none of whom were intimately familiar with the port, leaving traps into which others fell. Silently clobbering a register in a convenience method is so dangerous that it (eh, probably) should never be done. `do_oop_store` does nothing useful. Please delete it and replace its usages with explicit calls to `store_heap_oop`, with clearly labelled parameters, like this: diff --git a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp index 4c1e4ce3a05..bf688cc01b7 100644 --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp @@ -1144,7 +1144,7 @@ void TemplateTable::aastore() { // Get the value we will store __ ldr(r0, at_tos()); // Now store using the appropriate barrier - do_oop_store(_masm, element_address, r0, IS_ARRAY); + __ store_heap_oop(element_address, r0, /*temps*/ r10, r11, r3, IS_ARRAY); __ b(done); // Have a null in r0, r3=array, r2=index. Store null at ary[idx] ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915620865 From eosterlund at openjdk.org Wed May 28 09:47:54 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 09:47:54 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: <-P-XBT8roTq_O-RLdl3zkzszNWEaocWa43u7aFixvm8=.075178a3-9b9a-4d6a-b40d-0d7465c15d39@github.com> On Wed, 28 May 2025 09:27:56 GMT, Andrew Haley wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Good catch. > > It's useful to look at how this mistake was made. The code was edited by four or five different authors, none of whom were intimately familiar with the port, leaving traps into which others fell. Silently clobbering a register in a convenience method is so dangerous that it (eh, probably) should never be done. > > `do_oop_store` does nothing useful. Please delete it and replace its usages with explicit calls to `store_heap_oop`, with clearly labelled parameters, like this: > > > diff --git a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > index 4c1e4ce3a05..bf688cc01b7 100644 > --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > @@ -1144,7 +1144,7 @@ void TemplateTable::aastore() { > // Get the value we will store > __ ldr(r0, at_tos()); > // Now store using the appropriate barrier > - do_oop_store(_masm, element_address, r0, IS_ARRAY); > + __ store_heap_oop(element_address, r0, /*temps*/ r10, r11, r3, IS_ARRAY); > __ b(done); > > // Have a null in r0, r3=array, r2=index. Store null at ary[idx] I agree with you @theRealAph, but I wonder if we should separate the bug fix (which probably needs extensive back porting), from the very reasonable refactoring you propose. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915681911 From eosterlund at openjdk.org Wed May 28 09:50:56 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 09:50:56 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. @robehn BTW looks like RISC-V has the same issue. Thanks @tschatzl for noticing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915689284 From aph at openjdk.org Wed May 28 09:57:52 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 09:57:52 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 09:27:56 GMT, Andrew Haley wrote: >> The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. >> >> My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. >> >> This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > > Good catch. > > It's useful to look at how this mistake was made. The code was edited by four or five different authors, none of whom were intimately familiar with the port, leaving traps into which others fell. Silently clobbering a register in a convenience method is so dangerous that it (eh, probably) should never be done. > > `do_oop_store` does nothing useful. Please delete it and replace its usages with explicit calls to `store_heap_oop`, with clearly labelled parameters, like this: > > > diff --git a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > index 4c1e4ce3a05..bf688cc01b7 100644 > --- a/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > +++ b/src/hotspot/cpu/aarch64/templateTable_aarch64.cpp > @@ -1144,7 +1144,7 @@ void TemplateTable::aastore() { > // Get the value we will store > __ ldr(r0, at_tos()); > // Now store using the appropriate barrier > - do_oop_store(_masm, element_address, r0, IS_ARRAY); > + __ store_heap_oop(element_address, r0, /*temps*/ r10, r11, r3, IS_ARRAY); > __ b(done); > > // Have a null in r0, r3=array, r2=index. Store null at ary[idx] > I agree with you @theRealAph, but I wonder if we should separate the bug fix (which probably needs extensive back porting), from the very reasonable refactoring you propose. I could live with that, but IMO it's reasonable to do it now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915710842 From tschatzl at openjdk.org Wed May 28 10:17:50 2025 From: tschatzl at openjdk.org (Thomas Schatzl) Date: Wed, 28 May 2025 10:17:50 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. Aarch64 code seems good. However, riscv code seems broken too but the others fine. @RealFYang , maybe you can have a look? ------------- Changes requested by tschatzl (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2874437721 From shade at openjdk.org Wed May 28 10:51:51 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 May 2025 10:51:51 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. Ouch. I think this is fine without further refactoring, especially since I see it should be backported into JDK 21 as well. I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2874530955 From aph at openjdk.org Wed May 28 11:06:51 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 11:06:51 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 10:48:51 GMT, Aleksey Shipilev wrote: > Ouch. I think this is fine without further refactoring, especially since I see it should be backported into JDK 21 as well. It's many things, but IMO fine is not one of them. It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter. > I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... It's interesting to see how to do that. One question for @fisk : did this problem manifest interpreter-only, or with a combination of interpreted in one thread, compiled in the other? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915895116 From aph at openjdk.org Wed May 28 11:06:52 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 11:06:52 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:02:22 GMT, Andrew Haley wrote: > It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter. Maybe a "here be dragons" warning would suffice. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915900095 From nbenalla at openjdk.org Wed May 28 11:16:53 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 28 May 2025 11:16:53 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: On Thu, 8 May 2025 13:15:35 GMT, Nizar Benalla wrote: >> It is to accommodate the now longer list of --release values in the javac help output,the addition of ", 26". >> >> Splitting the list of releases over two lines would be a better solution, but I didn't take that one when initially preparing the patch. > > I'll split the releases over two lines in the next update. The line is a little too long. Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111590538 From rehn at openjdk.org Wed May 28 11:21:52 2025 From: rehn at openjdk.org (Robbin Ehn) Date: Wed, 28 May 2025 11:21:52 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 09:47:59 GMT, Erik ?sterlund wrote: > @robehn BTW looks like RISC-V has the same issue. Thanks @tschatzl for noticing. Yes, thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2915936278 From cstein at openjdk.org Wed May 28 11:38:53 2025 From: cstein at openjdk.org (Christian Stein) Date: Wed, 28 May 2025 11:38:53 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v4] In-Reply-To: References: Message-ID: <3Ins14V5M3PnLXVBHH3sgqydHdmtaxrAERYbfG7egLc=.5ec6d31c-f442-482c-9f50-aa67f8e0f454@github.com> On Wed, 28 May 2025 11:14:22 GMT, Nizar Benalla wrote: >> I'll split the releases over two lines in the next update. The line is a little too long. > > Thinking about this again, could we represent the supported versions more concisely? like `8-26` or `from 8 to 26`. Another variant: Supported releases: 8, 9, 10, ..., 24, 25, 26 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25008#discussion_r2111627278 From fbredberg at openjdk.org Wed May 28 13:28:53 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 28 May 2025 13:28:53 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. I tried to follow the `r5` register to see if it's safe to use, and got a bit scared when I saw that that `r5` is used inside `TemplateTable::load_resolved_field_entry()` as a temp register when calling `MacroAssembler::resolve_oop_handle()`. But that's no problem since `is_static` is `false`. Doing manual register allocation in the interpreter is a roller coaster that travels between hope and despair. Maybe we should add an `assert_different_registers()` statement that includes both `r5` and `rscratch2` after `if (is_static)` in `TemplateTable::load_resolved_field_entry()`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916346376 From aph at openjdk.org Wed May 28 13:48:54 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 13:48:54 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 13:25:52 GMT, Fredrik Bredberg wrote: > I tried to follow the `r5` register to see if it's safe to use, and got a bit scared when I saw that that `r5` is used inside `TemplateTable::load_resolved_field_entry()` as a temp register when calling `MacroAssembler::resolve_oop_handle()`. But that's no problem since `is_static` is `false`. Doing manual register allocation in the interpreter is a roller coaster that travels between hope and despair. Indeed, yes. My only defence is that I was following the practice in the x86 port. It's not much of an excuse, but there it is... > Maybe we should add an `assert_different_registers()` statement that includes both `r5` and `rscratch2` after `if (is_static)` in `TemplateTable::load_resolved_field_entry()`? That wouldn't hurt. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916427018 From eosterlund at openjdk.org Wed May 28 14:07:51 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 14:07:51 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:02:22 GMT, Andrew Haley wrote: > Ouch. I think this is fine without further refactoring, especially since I see it should be backported into JDK 21 as well. Yeah it looks like this will need backporting all the way back to 8 - before the barrier registers were explicit at all at the use site, and before there was even an access API. > I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... I was also confused why jcstress hasn't caught this - seems like basic seq cst testing would have hashed this out. Great that you found out why. :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916488521 From kvn at openjdk.org Wed May 28 14:11:16 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 May 2025 14:11:16 GMT Subject: RFR: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling [v25] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 21:57:11 GMT, Igor Veresov wrote: >> Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. >> >> More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 > > Igor Veresov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits: > > - Merge branch 'master' into pp2 > - Missing part of the merge > - Merge branch 'master' into pp2 > - Merge branch 'master' into pp2 > - 8357284: runtime/cds/appcds/aotProfile/AOTProfileFlags.java fails on non-debug platform > - 8357283: compiler/debug/TestStressBailout.java hangs when running with AOT cache > - Merge branch 'master' into pp2 > - Address Ioi's comments > - Merge branch 'master' into pp2 > - Address Ioi's comments > - ... and 80 more: https://git.openjdk.org/jdk/compare/2e8b195a...ed213368 Re-approved ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/24886#pullrequestreview-2875268813 From eosterlund at openjdk.org Wed May 28 14:17:52 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 14:17:52 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:05:41 GMT, Erik ?sterlund wrote: >>> Ouch. I think this is fine without further refactoring, especially since I see it should be backported into JDK 21 as well. >> >> It's many things, but IMO fine is not one of them. It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter. >> >>> I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... >> >> It's interesting to see how to do that. One question for @fisk : did this problem manifest interpreter-only, or with a combination of interpreted in one thread, compiled in the other? > >> Ouch. I think this is fine without further refactoring, especially since I see it should be backported into JDK 21 as well. > > Yeah it looks like this will need backporting all the way back to 8 - before the barrier registers were explicit at all at the use site, and before there was even an access API. > >> I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... > > I was also confused why jcstress hasn't caught this - seems like basic seq cst testing would have hashed this out. Great that you found out why. :-) > One question for @fisk : did this problem manifest interpreter-only, or with a combination of interpreted in one thread, compiled in the other? It manifested with -Xint and with -XX:TieredStopAtLevel=1, but mysteriously not when allowing C2 compilation. I traced down the reason to be the extra dmb you added to the following conditional leading fence for volatile loads in the interpreter: // 8179954: We need to make sure that the code generated for // volatile accesses forms a sequentially-consistent set of // operations when combined with STLR and LDAR. Without a leading // membar it's possible for a simple Dekker test to fail if loads // use LDR;DMB but stores use STLR. This can happen if C2 compiles // the stores in one method and we interpret the loads in another. if (!CompilerConfig::is_c1_or_interpreter_only_no_jvmci()) { Label notVolatile; __ tbz(r3, ResolvedFieldEntry::is_volatile_shift, notVolatile); __ membar(MacroAssembler::AnyAny); __ bind(notVolatile); } This extra leading fence on volatile loads when C2 is available masked the lack of trailing fence on the store side. Therefore, the Dekker duality in the test that hung worked out anyway then. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916521838 From aph at openjdk.org Wed May 28 14:32:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 May 2025 14:32:53 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: <702EBHEl9Pkl1gMgUzMYq-klUn1a1nqoc4EiRV8AdT4=.1585b642-e654-4aee-9ce9-db13686eaed9@github.com> On Wed, 28 May 2025 14:15:43 GMT, Erik ?sterlund wrote: > This extra leading fence on volatile loads when C2 is available masked the lack of trailing fence on the store side. Therefore, the Dekker duality in the test that hung worked out anyway then. Ha, yes. It's a funny old world. For what it's worth, I wanted to use seq cst loads and stores for all volatile accesses in the interpreter, but I was talked out of it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916569792 From gziemski at openjdk.org Wed May 28 14:34:15 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 28 May 2025 14:34:15 GMT Subject: RFR: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() [v3] In-Reply-To: References: Message-ID: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. Gerard Ziemski 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 five additional commits since the last revision: - Merge remote-tracking branch 'upstream/master' into JDK-8356233 - Johan's feedback - revert debug change - revert header change - convert to UL ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25308/files - new: https://git.openjdk.org/jdk/pull/25308/files/985856ec..5b0e0f58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25308&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25308&range=01-02 Stats: 62258 lines in 1064 files changed: 41067 ins; 14979 del; 6212 mod Patch: https://git.openjdk.org/jdk/pull/25308.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25308/head:pull/25308 PR: https://git.openjdk.org/jdk/pull/25308 From shade at openjdk.org Wed May 28 14:38:54 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 May 2025 14:38:54 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:05:41 GMT, Erik ?sterlund wrote: > I was wondering why haven't we caught this in jcstress. jcstress runs in int/C1/C2 modes specifically to catch issues like these. I believe this slipped through because all of our seqcst tests, Dekker included, operate on primitives. So we never actually explore what happens with reference load/stores, and as this bug shows, there are _interesting_ interactions with GC barriers. I'll see how to amend jcstress to cover this... Yeah, here it is: @JCStressTest @Outcome(id = {"null, A", "B, null", "B, A"}, expect = ACCEPTABLE, desc = "Trivial under sequential consistency") @Outcome(id = "null, null", expect = FORBIDDEN, desc = "Violates sequential consistency") @State public class RefDekkerTest { volatile Object a; volatile Object b; @Actor public void actor1(LL_Result r) { a = new String("A"); r.r1 = b; } @Actor public void actor2(LL_Result r) { b = new String("B"); r.r2 = a; } } ...on Graviton 3: % build/linux-aarch64-server-release/images/jdk/bin/java -jar jcstress.jar -t RefDekker -tb 1m -f 10 -jvmArgs "-Xint" -sc false ...... [FAILED] o.o.j.t.volatiles.RefDekkerTest Results across all configurations: RESULT SAMPLES FREQ EXPECT DESCRIPTION B, A 377,670 0.06% Acceptable Trivial under sequential consistency B, null 288,159,312 46.22% Acceptable Trivial under sequential consistency null, A 331,478,806 53.17% Acceptable Trivial under sequential consistency null, null 3,385,362 0.54% Forbidden Violates sequential consistency Perhaps confusingly, this only reproduces when I supply `-jvmArgs "-Xint"`. A "normal" way for jcstress to separately compile/interpret methods is via compiler control. Which, I think, accidentally passes due to Erik's comment above: https://github.com/openjdk/jdk/pull/25483#issuecomment-2916521838 -- we still interpret in the mode that have extra fence. In retrospect, I think conditionalizing barrier emit scheme on the presence of particular compilers is counter-productive, especially when the default behavior (C2 is enabled) is to emit the barriers. In this instance, this would have made this bug a nuisance (that we _would like_ to fix eventually) rather than a seqcst violation (that we _now have_ to fix for C1-only users) :) Test starts to pass with the patch from this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916587396 From pchilanomate at openjdk.org Wed May 28 14:54:24 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 May 2025 14:54:24 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual Message-ID: Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/25496/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25496&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357910 Stats: 16 lines in 2 files changed: 4 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/25496.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25496/head:pull/25496 PR: https://git.openjdk.org/jdk/pull/25496 From eosterlund at openjdk.org Wed May 28 15:01:03 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 15:01:03 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 13:25:52 GMT, Fredrik Bredberg wrote: > I tried to follow the `r5` register to see if it's safe to use, and got a bit scared when I saw that that `r5` is used inside `TemplateTable::load_resolved_field_entry()` as a temp register when calling `MacroAssembler::resolve_oop_handle()`. But that's no problem since `is_static` is `false`. Doing manual register allocation in the interpreter is a roller coaster that travels between hope and despair. > > Maybe we should add an `assert_different_registers()` statement that includes both `r5` and `rscratch2` after `if (is_static)` in `TemplateTable::load_resolved_field_entry()`? That wouldn't hurt in that function, and indeed in most functions that have a bunch of register arguments. And even better would be to explicitly pass in that temp register instead of hard coding it. Having said that, I hesitate a bit mixing in orthogonal changes to this train that will have to go all the way back to JDK 8. But I'm happy to add that assert for the follow-up patch that tries to strengthen this code for the future. Hope that's okay. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916662319 From eosterlund at openjdk.org Wed May 28 15:10:56 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 15:10:56 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. > Perhaps confusingly, this only reproduces when I supply `-sc false`. A "normal" way for jcstress to separately compile/interpret methods is via compiler control, this is what `-sc true` (default) does. Which, I think, accidentally passes due to Erik's comment above: [#25483 (comment)](https://github.com/openjdk/jdk/pull/25483#issuecomment-2916521838) -- we still interpret in the mode that have extra fence. WIth `-sc false`, we have a more blunt `-Xint`, `-XX:TieredStopAtLevel=1` gets used and is seen to fail. Thanks for checking. > In retrospect, I think conditionalizing barrier emit scheme on the presence of particular compilers is counter-productive, especially when the default behavior (C2 is enabled) is to emit the barriers. In this instance, this would have simplified testing a bit, and maybe this bug less of a nuisance :) Yeah I got a bit confused about that too. On the one hand side it looks like a weird optimization for a mode of execution that seems to care less about optimizations. But I suppose the reason for making it conditional might have rather been to be more precise about what the actual constraints are and not try to conservatively mask cases that absolutely should not need the fence for correctness. Then we want to know if our understanding of what we need for correctness is off, then something is very wrong, which fortunately we now found that it was indeed. Otherwise we would probably never have noticed it, but it would still arguably be wrong. For example if the store is interpreted (but with bugged out missing trailing fence) and the load is C2 compiled, there is still a problem, right? Just less likely to happen to get that kind of mixed execution in code exercising the races. > Test starts to pass with the patch from this PR. Awesome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916691724 From eosterlund at openjdk.org Wed May 28 15:10:57 2025 From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=) Date: Wed, 28 May 2025 15:10:57 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: <702EBHEl9Pkl1gMgUzMYq-klUn1a1nqoc4EiRV8AdT4=.1585b642-e654-4aee-9ce9-db13686eaed9@github.com> References: <702EBHEl9Pkl1gMgUzMYq-klUn1a1nqoc4EiRV8AdT4=.1585b642-e654-4aee-9ce9-db13686eaed9@github.com> Message-ID: On Wed, 28 May 2025 14:30:08 GMT, Andrew Haley wrote: > > This extra leading fence on volatile loads when C2 is available masked the lack of trailing fence on the store side. Therefore, the Dekker duality in the test that hung worked out anyway then. > > Ha, yes. It's a funny old world. For what it's worth, I wanted to use seq cst loads and stores for all volatile accesses in the interpreter, but I was talked out of it. I would have liked that solution. We have MO_ decorators, so would have been pretty neat to do the right thing in the backend instead, and not have mixed seq cst bindings that are subtly different and have to play along with each other. Oh well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2916700725 From iveresov at openjdk.org Wed May 28 15:18:03 2025 From: iveresov at openjdk.org (Igor Veresov) Date: Wed, 28 May 2025 15:18:03 GMT Subject: Integrated: 8355003: Implement JEP 515: Ahead-of-Time Method Profiling In-Reply-To: References: Message-ID: On Fri, 25 Apr 2025 20:18:41 GMT, Igor Veresov wrote: > Improve warm-up time by making profile data from a previous run of an application instantly available, when the HotSpot Java Virtual Machine starts. Specifically, enhance the [AOT cache](https://openjdk.org/jeps/483) to store method execution profiles from training runs, reducing profiling delays in subsequent production runs. > > More details in the JEP: https://bugs.openjdk.org/browse/JDK-8325147 This pull request has now been integrated. Changeset: e3f85c96 Author: Igor Veresov URL: https://git.openjdk.org/jdk/commit/e3f85c961b4c1e5e01aedf3a0f4e1b0e6ff457fd Stats: 3324 lines in 59 files changed: 3111 ins; 100 del; 113 mod 8355003: Implement JEP 515: Ahead-of-Time Method Profiling Co-authored-by: John R Rose Co-authored-by: Vladimir Ivanov Co-authored-by: Ioi Lam Co-authored-by: Vladimir Kozlov Co-authored-by: Aleksey Shipilev Reviewed-by: kvn, ihse, cjplummer, iklam ------------- PR: https://git.openjdk.org/jdk/pull/24886 From lmesnik at openjdk.org Wed May 28 15:24:03 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 May 2025 15:24:03 GMT Subject: RFR: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 [v3] In-Reply-To: References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Fri, 23 May 2025 04:33:36 GMT, PAWAN CHAWDHARY wrote: >> 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 > > PAWAN CHAWDHARY 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 branch 'master' into 8354475 > - Update TestDockerMemoryMetricsSubgroup.java > > remove extra space > - 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/24930#pullrequestreview-2875529614 From duke at openjdk.org Wed May 28 16:02:56 2025 From: duke at openjdk.org (PAWAN CHAWDHARY) Date: Wed, 28 May 2025 16:02:56 GMT Subject: Integrated: 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 In-Reply-To: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> References: <9N622Jo_e1ORLj-OmaYEWBss5S59JAHhEvEhMFmIt6A=.b950e4d8-bbc0-4e71-bc98-4c90aac9ce18@github.com> Message-ID: On Mon, 28 Apr 2025 15:51:44 GMT, PAWAN CHAWDHARY wrote: > 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 This pull request has now been integrated. Changeset: e579cca6 Author: PAWAN CHAWDHARY Committer: Leonid Mesnik URL: https://git.openjdk.org/jdk/commit/e579cca619147aa51563dc00f374e02db49e1238 Stats: 18 lines in 1 file changed: 18 ins; 0 del; 0 mod 8354475: TestDockerMemoryMetricsSubgroup.java fails with exitValue = 1 Reviewed-by: lmesnik, mseledtsov ------------- PR: https://git.openjdk.org/jdk/pull/24930 From iklam at openjdk.org Wed May 28 16:47:46 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 16:47:46 GMT Subject: RFR: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics [v13] In-Reply-To: References: Message-ID: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 29 commits: - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - Fixed merge - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @erikj79 comments -- makefile indentation - Fixed merge - @erikj79 comments - Merge branch 'master' into 8355798-implement-leyden-ergo-jep-8350022 - @vnkozlov comments - added info about JTREG/AOT_JDK testing - fixed whitespace - ... and 19 more: https://git.openjdk.org/jdk/compare/b2a61a99...a8ce491e ------------- Changes: https://git.openjdk.org/jdk/pull/24942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24942&range=12 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/24942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24942/head:pull/24942 PR: https://git.openjdk.org/jdk/pull/24942 From fbredberg at openjdk.org Wed May 28 16:53:55 2025 From: fbredberg at openjdk.org (Fredrik Bredberg) Date: Wed, 28 May 2025 16:53:55 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 08:49:17 GMT, Erik ?sterlund wrote: > The optimized fast_aputfield bytecode on AArch64 stores the field flags in r3, and performs the leading and trailing fencing depending on its volatile bit being set or not. However, r3 is also the last temp register passed in to the barrier set for reference stores, and G1 clobbers it in a way that may clear the volatile bit. Then the trailing fence won't get executed, and sequential consistency is broken. > > My fix puts the flags in r5 instead, which is the register that was used by normal aputfield bytecodes. This way, barriers don't clobber the volatile bits. > > This bug has been observed to mess up a classic Dekker duality in the java.util.concurrent.Exchanger class, leading to a hang in the test/jdk/java/util/concurrent/Exchanger/ExchangeLoops.java test that exercises it. Using G1 and -Xint a reproducer hangs 30/100 times in mach5. With the fix, the same reproducer hangs 0/100 times. I think the problem is well understood by now, and I'm sure this will generate at least one follow-up patch. But for now, I'm happy with this PR as is. Great work! ------------- Marked as reviewed by fbredberg (Committer). PR Review: https://git.openjdk.org/jdk/pull/25483#pullrequestreview-2875793399 From pchilanomate at openjdk.org Wed May 28 18:38:56 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 May 2025 18:38:56 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: References: Message-ID: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> On Mon, 26 May 2025 13:30:11 GMT, Anton Artemov wrote: >> Hi, >> >> in this PR the suspend/resume methods are moved away from the HandshakeState class into a new separate class HandshakeSuspender. The idea is that the state class should be a state keeper and should not be responsible for actions which change the state. Such actions should be done by a separate class. >> >> Tested in tiers 1-4. > > Anton Artemov 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 10 additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - 8265754: Refactoring to static methods. > - 8265754: Fixed indentation. > - 8265754: Fixed indentation > - 8265754: Fixed indentation and lost newline. > - 8265754: Fixed whitespaces errors. > - 8265754: More work. > - Merge remote-tracking branch 'origin/master' into JDK-8265754 > - 8265754: Refactoring suspend/resume in the HandshakeState away In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2917264751 From gziemski at openjdk.org Wed May 28 19:16:57 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Wed, 28 May 2025 19:16:57 GMT Subject: Integrated: 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() In-Reply-To: References: Message-ID: <-w0uoHuh5EVWfXDxtallxNSM-3ySA6Zvfq2YCiBY17Y=.a8621b60-5d16-454d-bd39-1aa11812bf92@github.com> On Mon, 19 May 2025 20:11:09 GMT, Gerard Ziemski wrote: > To help with debugging NMT we added more info when an assert gets triggered, but we used `tty`, which is involved with locks and unfortunately it triggered: > > > # Internal Error (.../open/src/hotspot/share/runtime/mutex.cpp:457), pid=1088443, tid=1088520 > # assert(false) failed: Attempting to acquire lock tty_lock/tty out of order with lock NmtVirtualMemory_lock/service-4 -- possible deadlock > > > We avoid this, by printing using `UL` instead of using `tty` directly. This pull request has now been integrated. Changeset: 28f50931 Author: Gerard Ziemski URL: https://git.openjdk.org/jdk/commit/28f509317d477c5f4076658f9ae9995aa6c53631 Stats: 12 lines in 1 file changed: 3 ins; 0 del; 9 mod 8356233: NMT: tty->print_cr should not be used in VirtualMemoryTracker::add_reserved_region() Reviewed-by: jsjolen, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/25308 From lmesnik at openjdk.org Wed May 28 19:20:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 May 2025 19:20:46 GMT Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test Message-ID: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> Test scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797 that causes test failure. The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. I am removing it just to avoid spending time for anyone who can run test and observe this failure. ------------- Commit messages: - Removed scimark Changes: https://git.openjdk.org/jdk/pull/25316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358004 Stats: 58 lines in 1 file changed: 0 ins; 58 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25316/head:pull/25316 PR: https://git.openjdk.org/jdk/pull/25316 From lmesnik at openjdk.org Wed May 28 19:20:46 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 May 2025 19:20:46 GMT Subject: RFR: 8358004: Delete applications/scimark/Scimark.java test In-Reply-To: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> References: <_o6ne7B1-A7nSOva7Zns8IMv7rw0Ve4xTwqiSajNzcA=.755977c7-4376-415c-9f76-5acae9f12b5a@github.com> Message-ID: On Tue, 20 May 2025 02:55:44 GMT, Leonid Mesnik wrote: > Test > scimark has a bug, described in the https://bugs.openjdk.org/browse/JDK-8315797 > that causes test failure. > > The Scimark is not maintained. The main goal of test was to provide example of Artifact-based test with 3rd party binary. There are a couple of other tests using Artifactory. So this test is completely useless now. > I am removing it just to avoid spending time for anyone who can run test and observe this failure. I have update the issue. The bug contains description of the problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25316#issuecomment-2917363133 From pchilanomate at openjdk.org Wed May 28 19:49:32 2025 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 May 2025 19:49:32 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual Message-ID: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: public static void main(String[] args) or a JavaFX application class must extend javafx.application.Application The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) at java.base/java.lang.Class.getMethod(Class.java:2166) at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/25509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357914 Stats: 14 lines in 2 files changed: 10 ins; 3 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25509/head:pull/25509 PR: https://git.openjdk.org/jdk/pull/25509 From lmesnik at openjdk.org Wed May 28 20:04:52 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 May 2025 20:04:52 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: On Wed, 28 May 2025 19:31:17 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: > > > Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: > public static void main(String[] args) > or a JavaFX application class must extend javafx.application.Application > > > The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses > `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: > > > [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) > at java.base/java.lang.Class.getMethod(Class.java:2166) > at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) > > > The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. > > Thanks, > Patricio Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2876280531 From lmesnik at openjdk.org Wed May 28 20:08:54 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Wed, 28 May 2025 20:08:54 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v3] In-Reply-To: References: Message-ID: <-BsN2TQK6LS51WKb9FgTo79HcdwVsdHXK7fp7Uf1oYE=.a3d5da1a-ad43-4172-98b7-2eb4fa9cc88c@github.com> On Tue, 27 May 2025 05:43:33 GMT, Lei Zhu wrote: >> I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Marked as reviewed by lmesnik (Reviewer). Sorry, I mistakenly add integrate for this issue instead of approval. ------------- PR Review: https://git.openjdk.org/jdk/pull/25427#pullrequestreview-2876288038 PR Comment: https://git.openjdk.org/jdk/pull/25427#issuecomment-2917478408 From iklam at openjdk.org Wed May 28 22:15:02 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 22:15:02 GMT Subject: Integrated: 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics In-Reply-To: References: Message-ID: On Tue, 29 Apr 2025 04:50:42 GMT, Ioi Lam wrote: > This is the implementation of the draft [JEP: Ahead-of-time Command Line Ergonomics](https://bugs.openjdk.org/browse/JDK-8350022) > > - Implemented new flag `AOTCacheOutput`, which can be used to create an AOT cache using the "one-command workflow" > - Added processing of the `JDK_AOT_VM_OPTIONS` environment variable that can supply extra VM options when creating an AOT cache > - Added `%p` substitution for `AOTCache`, `AOTCacheOutput`, and `AOTConfiguration` options > > Please see the [JEP](https://bugs.openjdk.org/browse/JDK-8350022) and [CSR](https://bugs.openjdk.org/browse/JDK-8356010) for detailed specification. > > Examples: > > > # Create an AOT cache with a single command: > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > Hello World > Temporary AOTConfiguration recorded: foo.aot.config > Launching child process /usr/bin/java to assemble AOT cache foo.aot using configuration foo.aot.config > [...] > Reading AOTConfiguration foo.aot.config and writing AOTCache foo.aot > AOTCache creation is complete: foo.aot 10240000 bytes > > # Create logging file for the AOT cache assembly phase > $ export AOT_TOOL_COMMAND=-Xlog:cds:file=log.txt > $ java -cp HelloWorld.jar -XX:AOTMode=record -XX:AOTCacheOutput=foo.aot HelloWorld > > > Note: the child process is launched with Java API because the HotSpot native APIs are not sufficient (no way to set env vars for child process). This pull request has now been integrated. Changeset: dede3532 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/dede3532f7238d527fb89be41f1b8050bde02ee3 Stats: 2107 lines in 26 files changed: 1564 ins; 459 del; 84 mod 8355798: Implement JEP 514: Ahead-of-Time Command Line Ergonomics Reviewed-by: erikj, kvn, asmehra ------------- PR: https://git.openjdk.org/jdk/pull/24942 From iklam at openjdk.org Wed May 28 23:03:32 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 23:03:32 GMT Subject: RFR: 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages Message-ID: With `-XX:+UseLargePages`, memory mapping may fail on some OSes if the size is not large page aligned, so let's use `read()` instead. With this fix, the test cases passes. ------------- Commit messages: - 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages Changes: https://git.openjdk.org/jdk/pull/25508/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25508&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357693 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/25508.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25508/head:pull/25508 PR: https://git.openjdk.org/jdk/pull/25508 From kvn at openjdk.org Wed May 28 23:15:51 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Wed, 28 May 2025 23:15:51 GMT Subject: RFR: 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Wed, 28 May 2025 19:18:56 GMT, Ioi Lam wrote: > With `-XX:+UseLargePages`, memory mapping may fail on some OSes if the size is not large page aligned, so let's use `read()` instead. > > With this fix, the test cases passes. Good ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25508#pullrequestreview-2876667257 From iklam at openjdk.org Wed May 28 23:29:10 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 23:29:10 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v2] In-Reply-To: References: Message-ID: > When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. > > The fix is simple: > > > - if (do_substitute) { > + if (do_substitute && remove_prefix_len > 0) { > > > I also improved the logs to help debugging classpath mismatches when using the AOT cache. Ioi Lam 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: - @dholmes-ora comments -- fixed bug where ClasspathStream does not remove leading blank paths; cleaned up ClasspathStream and added docs/asserts - Merge branch 'master' into 8356308-assert-in-log-class-path - 8356308: Assert with -Xlog:class+path when classpath has an empty element ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25372/files - new: https://git.openjdk.org/jdk/pull/25372/files/c1818b89..400b93c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25372&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25372&range=00-01 Stats: 30700 lines in 716 files changed: 21119 ins; 5990 del; 3591 mod Patch: https://git.openjdk.org/jdk/pull/25372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25372/head:pull/25372 PR: https://git.openjdk.org/jdk/pull/25372 From iklam at openjdk.org Wed May 28 23:31:50 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 28 May 2025 23:31:50 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element In-Reply-To: References: Message-ID: On Thu, 22 May 2025 09:48:11 GMT, David Holmes wrote: > This sounds like a bug in `-cp` parsing to me! Yes, you're right. ClasspathStream throws away empty elements, but can't handle empty elements at the beginning of the string. Also the implementation of ClasspathStream is kind of ugly, so I rewrote it and fixed this bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25372#issuecomment-2917835772 From jiangli at openjdk.org Thu May 29 00:30:21 2025 From: jiangli at openjdk.org (Jiangli Zhou) Date: Thu, 29 May 2025 00:30:21 GMT Subject: RFR: 8357632: CDS test failures on static JDK Message-ID: Please review the fix in CDSConfig::default_archive_path to form the default .jsa path using Arguments::get_java_home on static-jdk. It basically reverts to the previous code before JDK-8353504, but for static-jdk case only. The change does not affect how default .jsa path is handled on regular JDK. The PR removes the affected CDS tests from hotspot/jtreg/ProblemList-StaticJdk.txt. It adds '@requires !jdk.static' to runtime/cds/NonJVMVariantLocation.java to skip the test on static-jdk. NonJVMVariantLocation.java tests with VM variants specified in jvm.cfg, which is not processed on static-jdk. Testing: Tested the affected tests locally on static-jdk. https://github.com/jianglizhou/jdk/actions/runs/15312986693 is in progress. ------------- Commit messages: - Remove affected tests from hotspot/jtreg/ProblemList-StaticJdk.txt. - - Change CDSConfig::default_archive_path to use Arguments::get_java_home when forming the path to default .jsa on static JDK. Changes: https://git.openjdk.org/jdk/pull/25516/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25516&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357632 Stats: 31 lines in 3 files changed: 17 ins; 13 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/25516.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25516/head:pull/25516 PR: https://git.openjdk.org/jdk/pull/25516 From duke at openjdk.org Thu May 29 02:36:51 2025 From: duke at openjdk.org (duke) Date: Thu, 29 May 2025 02:36:51 GMT Subject: RFR: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless [v3] In-Reply-To: References: Message-ID: On Tue, 27 May 2025 05:43:33 GMT, Lei Zhu wrote: >> I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. > > Lei Zhu has updated the pull request incrementally with one additional commit since the last revision: > > 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless @Korov Your change (at version f74a1385722d4fcea449c2eb114f34761ae1e532) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25427#issuecomment-2918062506 From duke at openjdk.org Thu May 29 05:42:55 2025 From: duke at openjdk.org (Lei Zhu) Date: Thu, 29 May 2025 05:42:55 GMT Subject: Integrated: 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless In-Reply-To: References: Message-ID: On Sat, 24 May 2025 05:18:57 GMT, Lei Zhu wrote: > I changed `@requires` to `vm.flagless` and it passed the test. If there is anything inappropriate, please let me know and I will modify it in time. This pull request has now been integrated. Changeset: 83a28048 Author: Lei Zhu Committer: SendaoYan URL: https://git.openjdk.org/jdk/commit/83a280485889573d5709b2bb59185d11ab6a38da Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8357408: runtime/interpreter/CountBytecodesTest.java should be flagless Reviewed-by: shade, syan, lmesnik ------------- PR: https://git.openjdk.org/jdk/pull/25427 From dholmes at openjdk.org Thu May 29 06:12:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 May 2025 06:12:53 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v2] In-Reply-To: References: Message-ID: On Wed, 28 May 2025 23:29:10 GMT, Ioi Lam wrote: >> When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. >> >> The fix is simple: >> >> >> - if (do_substitute) { >> + if (do_substitute && remove_prefix_len > 0) { >> >> >> I also improved the logs to help debugging classpath mismatches when using the AOT cache. > > Ioi Lam 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: > > - @dholmes-ora comments -- fixed bug where ClasspathStream does not remove leading blank paths; cleaned up ClasspathStream and added docs/asserts > - Merge branch 'master' into 8356308-assert-in-log-class-path > - 8356308: Assert with -Xlog:class+path when classpath has an empty element src/hotspot/share/cds/aotClassLocation.cpp line 910: > 908: if (!cs->from_cpattr()) { > 909: ls.print("%s", sep); > 910: if (do_substitute && remove_prefix_len > 0) { I had expected this would no longer be necessary once the cp parsing was fixed. ?? src/hotspot/share/utilities/classpathStream.cpp line 41: > 39: void ClasspathStream::skip_blank_paths() { > 40: while (*_cp == separator()) { > 41: _cp ++; Suggestion: _cp++; src/hotspot/share/utilities/classpathStream.cpp line 51: > 49: const char* end = _cp + 1; > 50: while (*end != separator() && *end != '\0') { > 51: end ++; Suggestion: end++; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25372#discussion_r2113274902 PR Review Comment: https://git.openjdk.org/jdk/pull/25372#discussion_r2113277100 PR Review Comment: https://git.openjdk.org/jdk/pull/25372#discussion_r2113277443 From shade at openjdk.org Thu May 29 07:00:50 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 29 May 2025 07:00:50 GMT Subject: RFR: 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Wed, 28 May 2025 19:18:56 GMT, Ioi Lam wrote: > With `-XX:+UseLargePages`, memory mapping may fail on some OSes if the size is not large page aligned, so let's use `read()` instead. > > With this fix, the test cases passes. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25508#pullrequestreview-2877302531 From dholmes at openjdk.org Thu May 29 07:23:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 May 2025 07:23:53 GMT Subject: RFR: 8357910: LoaderConstraintsTest.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: References: Message-ID: On Wed, 28 May 2025 14:42:10 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. When running LoaderConstraintsTest with `TEST_THREAD_FACTORY=Virtual` we load class `java.lang.Class` earlier than expected which causes the test to fail because of a missing loader constraint logging output. I added the full details of the issue in the JBS comments. > > The fix changes the constraint we look for to be on class `java.lang.String` between classloader `ClassUnloadCommonClassLoader` and the bootstrap classloader. This allows the test to be more robust and not depend on some hidden behavior. In fact, the only line that is currently needed for the test to pass for the platform thread case is the call to `ClassUnloadCommon.newClassLoader()`, which seems a bit obscure. Also as explained in JBS, the defining loader of `test.Empty` is currently the builtin system classloader, not `ClassUnloadCommonClassLoader` as the test would suggest. > > Thanks, > Patricio test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 53: > 51: ClassLoader cl = ClassUnloadCommon.newClassLoader(); > 52: Class c = cl.loadClass("test.Empty"); > 53: // Causes class test.Emtpy to be linked, which triggers the Suggestion: // Causes class test.Empty to be linked, which triggers the test/hotspot/jtreg/runtime/logging/LoaderConstraintsTest.java line 66: > 64: Collections.addAll(argsList, args); > 65: Collections.addAll(argsList, "-Xmn8m"); > 66: Collections.addAll(argsList, "-Xbootclasspath/a:."); Without use of `WhiteBox`, you don't need this. And this is probably what caused the class to be loaded by the boot-loader instead of the custom loader as expected. But the use of WB is needed by `ClassUnloadCommon` and these instructions are present to ensure it works - as added by JDK-8289184. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2113360652 PR Review Comment: https://git.openjdk.org/jdk/pull/25496#discussion_r2113363958 From qxing at openjdk.org Thu May 29 08:14:00 2025 From: qxing at openjdk.org (Qizheng Xing) Date: Thu, 29 May 2025 08:14:00 GMT Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` Message-ID: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. ------------- Commit messages: - Remove unused `compute_fingerprint` declaration in `ClassFileStream` Changes: https://git.openjdk.org/jdk/pull/25518/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25518&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8358035 Stats: 3 lines in 2 files changed: 0 ins; 3 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25518.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25518/head:pull/25518 PR: https://git.openjdk.org/jdk/pull/25518 From nbenalla at openjdk.org Thu May 29 13:42:34 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 29 May 2025 13:42:34 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v5] In-Reply-To: References: Message-ID: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> > Get JDK 26 underway. Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 24 The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - problem list some failing tests - Merge branch 'master' into jdk.8355746 - Merge branch 'master' into jdk.8355746 - Update --release 25 symbol information for JDK 25 build 23 The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ - Merge branch 'master' into jdk.8355746 - Update release date - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6 ------------- Changes: https://git.openjdk.org/jdk/pull/25008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25008&range=04 Stats: 1823 lines in 58 files changed: 1734 ins; 16 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/25008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25008/head:pull/25008 PR: https://git.openjdk.org/jdk/pull/25008 From syan at openjdk.org Thu May 29 14:11:50 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 29 May 2025 14:11:50 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: On Wed, 28 May 2025 19:31:17 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: > > > Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: > public static void main(String[] args) > or a JavaFX application class must extend javafx.application.Application > > > The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses > `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: > > > [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) > at java.base/java.lang.Class.getMethod(Class.java:2166) > at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) > > > The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. > > Thanks, > Patricio Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25509#pullrequestreview-2878454115 From coleenp at openjdk.org Thu May 29 15:50:54 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Thu, 29 May 2025 15:50:54 GMT Subject: RFR: 8355746: Start of release updates for JDK 26 [v5] In-Reply-To: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> References: <4gJngunxPmVPKGxIz_EFt0SMiFg4n2kMhzq2adsxuKU=.92733483-1132-456c-8fe3-85af89a105de@github.com> Message-ID: On Thu, 29 May 2025 13:42:34 GMT, Nizar Benalla wrote: >> Get JDK 26 underway. > > Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: > > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 24 > The macOS/AArch64 build 24 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - problem list some failing tests > - Merge branch 'master' into jdk.8355746 > - Merge branch 'master' into jdk.8355746 > - Update --release 25 symbol information for JDK 25 build 23 > The macOS/AArch64 build 23 was taken from https://jdk.java.net/25/ > - Merge branch 'master' into jdk.8355746 > - Update release date > - ... and 6 more: https://git.openjdk.org/jdk/compare/4cf729cf...6b0ce8b6 Hotspot changes look good. ------------- Marked as reviewed by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25008#pullrequestreview-2878772498 From iklam at openjdk.org Thu May 29 17:09:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 May 2025 17:09:58 GMT Subject: RFR: 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Wed, 28 May 2025 23:12:59 GMT, Vladimir Kozlov wrote: >> With `-XX:+UseLargePages`, memory mapping may fail on some OSes if the size is not large page aligned, so let's use `read()` instead. >> >> With this fix, the test cases passes. > > Good Thanks @vnkozlov @shipilev for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/25508#issuecomment-2920028198 From iklam at openjdk.org Thu May 29 17:09:59 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 May 2025 17:09:59 GMT Subject: Integrated: 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages In-Reply-To: References: Message-ID: On Wed, 28 May 2025 19:18:56 GMT, Ioi Lam wrote: > With `-XX:+UseLargePages`, memory mapping may fail on some OSes if the size is not large page aligned, so let's use `read()` instead. > > With this fix, the test cases passes. This pull request has now been integrated. Changeset: e3063678 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/e306367813db7c8a3ecac5e46740600b7ab04f9d Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8357693: AOTCodeCompressedOopsTest.java failed with -XX:+UseLargePages Reviewed-by: kvn, shade ------------- PR: https://git.openjdk.org/jdk/pull/25508 From ccheung at openjdk.org Thu May 29 18:56:57 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 29 May 2025 18:56:57 GMT Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> Message-ID: On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing wrote: > In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. Looks good. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25518#pullrequestreview-2879299604 From iklam at openjdk.org Thu May 29 20:01:35 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 May 2025 20:01:35 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v3] In-Reply-To: References: Message-ID: > When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. > > The fix is simple: > > > - if (do_substitute) { > + if (do_substitute && remove_prefix_len > 0) { > > > I also improved the logs to help debugging classpath mismatches when using the AOT cache. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @dholmes-ora comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/25372/files - new: https://git.openjdk.org/jdk/pull/25372/files/400b93c9..21e9a39c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=25372&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25372&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/25372.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25372/head:pull/25372 PR: https://git.openjdk.org/jdk/pull/25372 From iklam at openjdk.org Thu May 29 20:01:37 2025 From: iklam at openjdk.org (Ioi Lam) Date: Thu, 29 May 2025 20:01:37 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v2] In-Reply-To: References: Message-ID: <2-gjxyYCIG-7ACiqEoIWn99qQDeKIL1ZNJkt0M1FHoM=.c034e0ce-0f5a-48fd-8248-dc67239ca228@github.com> On Thu, 29 May 2025 06:06:47 GMT, David Holmes wrote: >> Ioi Lam 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: >> >> - @dholmes-ora comments -- fixed bug where ClasspathStream does not remove leading blank paths; cleaned up ClasspathStream and added docs/asserts >> - Merge branch 'master' into 8356308-assert-in-log-class-path >> - 8356308: Assert with -Xlog:class+path when classpath has an empty element > > src/hotspot/share/cds/aotClassLocation.cpp line 910: > >> 908: if (!cs->from_cpattr()) { >> 909: ls.print("%s", sep); >> 910: if (do_substitute && remove_prefix_len > 0) { > > I had expected this would no longer be necessary once the cp parsing was fixed. ?? I removed this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25372#discussion_r2114657271 From dholmes at openjdk.org Thu May 29 22:23:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 May 2025 22:23:52 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 20:01:35 GMT, Ioi Lam wrote: >> When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. >> >> The fix is simple: >> >> >> - if (do_substitute) { >> + if (do_substitute && remove_prefix_len > 0) { >> >> >> I also improved the logs to help debugging classpath mismatches when using the AOT cache. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments The new logging statements seem incidental to the actual fix, but presumably were useful in tracking down the issue. Please update the PR description to reflect the updated fix. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25372#pullrequestreview-2879741809 From dholmes at openjdk.org Thu May 29 22:29:51 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 May 2025 22:29:51 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> Message-ID: <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> On Wed, 28 May 2025 19:31:17 GMT, Patricio Chilano Mateo wrote: > Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: > > > Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: > public static void main(String[] args) > or a JavaFX application class must extend javafx.application.Application > > > The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses > `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: > > > [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) > at java.base/java.lang.Class.getMethod(Class.java:2166) > at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) > > > The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. > > Thanks, > Patricio test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58: > 56: output.shouldNotContain("java.lang.ClassFormatError"); > 57: output.shouldHaveExitValue(1); > 58: if (Thread.currentThread().isVirtual()) { Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual. FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2113384036 From ccheung at openjdk.org Thu May 29 22:41:51 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Thu, 29 May 2025 22:41:51 GMT Subject: RFR: 8356308: Assert with -Xlog:class+path when classpath has an empty element [v3] In-Reply-To: References: Message-ID: On Thu, 29 May 2025 20:01:35 GMT, Ioi Lam wrote: >> When the classpath has an element that's the empty string (e.g., `java -Xlog:class+path -cp :abc ...`, where the first element is `""` and the second element is `"abc"`), the VM asserts. >> >> The fix is simple: >> >> >> - if (do_substitute) { >> + if (do_substitute && remove_prefix_len > 0) { >> >> >> I also improved the logs to help debugging classpath mismatches when using the AOT cache. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @dholmes-ora comments LGTM. ------------- Marked as reviewed by ccheung (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25372#pullrequestreview-2879765447 From lmesnik at openjdk.org Thu May 29 22:50:51 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 29 May 2025 22:50:51 GMT Subject: RFR: 8357914: TestEmptyBootstrapMethodsAttr.java fails when run with TEST_THREAD_FACTORY=Virtual In-Reply-To: <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> References: <1pYf9yU72csoZg-MOQU3aQKcScB8P-FQmaiOUa_OzHE=.681a07c3-c65b-4c59-82db-0d21eb553b4b@github.com> <4sl7s3N2oAg-BHTxb6xPx2mcKTbKRstGsbbvwrH1Dvg=.aa858c34-a85f-4284-87ac-f748b7e9538c@github.com> Message-ID: On Thu, 29 May 2025 07:28:11 GMT, David Holmes wrote: >> Please review this small test fix. The test launches a child process with the only purpose of validating that the load of the main class (`emptynumbootstrapmethods1`/`emptynumbootstrapmethods2`) completes successfully and doesn?t throw `ClassFormatError`. The class doesn?t define a main method, so later during execution of `LauncherHelper.validateMainMethod` the child VM exits with the following error message which we check from the `OutputAnalyzer` output: >> >> >> Error: Main method not found in class emptynumbootstrapmethods1, please define the main method as: >> public static void main(String[] args) >> or a JavaFX application class must extend javafx.application.Application >> >> >> The issue when the test is run with `TEST_THREAD_FACTORY=Virtual` is that loading of `emptynumbootstrapmethods1` is done in `jdk.test.lib.process.ProcessTools.main` (the actual entry point), which instead of calling `MethodFinder.findMainMethod(mainClass)` and aborting if result is null like `LauncherHelper` uses >> `Method mainMethod = c.getMethod("main", new Class[] { String[].class });` which throws an exception instead and the test exits with the following error message: >> >> >> [Exception in thread "main" java.lang.NoSuchMethodException: emptynumbootstrapmethods1.main([Ljava.lang.String;) >> at java.base/java.lang.Class.getMethod(Class.java:2166) >> at jdk.test.lib.process.ProcessTools.main(ProcessTools.java:984) >> >> >> The proposed fix adjusts the output we check for based on whether the test was run on a platform thread or a virtual thread. >> >> Thanks, >> Patricio > > test/hotspot/jtreg/runtime/classFileParserBug/TestEmptyBootstrapMethodsAttr.java line 58: > >> 56: output.shouldNotContain("java.lang.ClassFormatError"); >> 57: output.shouldHaveExitValue(1); >> 58: if (Thread.currentThread().isVirtual()) { > > Just to be clear with `TEST_THREAD_FACTORY=Virtual` are all launched JVMs modified such that a virtual thread is created to invoke "main" instead of the normal platform thread? It just isn't clear why being virtual in the parent VM implies the child was also virtual, unless everything is virtual. > > FWIW I think this highlights a deficiency with how TEST_THREAD_FACTORY=Virtual actually works. Yes, the the main is executed in virtual thread and also it runs all forked processes with wrapper that run main in virtual thread. The another, might be more clear solution would to check it with `static final boolean vthreadMode = "Virtual".equals(System.getProperty("test.thread.factory"));` or even make library method for this in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/25509#discussion_r2114856783 From duke at openjdk.org Fri May 30 01:55:57 2025 From: duke at openjdk.org (duke) Date: Fri, 30 May 2025 01:55:57 GMT Subject: Withdrawn: 8353225: Add a way to iterate Klass inside the loaded CDS archive In-Reply-To: References: Message-ID: On Sat, 29 Mar 2025 07:53:37 GMT, Thomas Stuefe wrote: > Please consider. > > This patch adds a way to iterate all Klass structures in the loaded CDS archive (`SystemDictionaryShared::iterate_klasses_in_shared_archive(ConstKlassClosure* klassClosure, bool is_static);`). This uses the same mechanism that `PrintSharedArchiveAndExit` uses. I need this mechanism for some future GC work. > > Then, it re-implements `PrintSharedArchiveAndExit` to reuse the new iteration API instead. This also serves as a way to test, since there are pre-existing tests for this flag. > > It also adds a new, rather basic, gtest. > > Finally, the new gtest picked up a small pre-existing bug in the implementation of `PrintSharedArchiveAndExit`: it prints all array classes of all InstanceKlass inside the archive, for all dimensions, without testing if that array class is part of the archive. The array class may have been created dynamically, however. The patch fixes that. > > ---- > > Testing: > - I ensured that the output of `PrintSharedArchiveAndExit`, before and after this patch, are identical apart from the small error fix concerning array classes > - I ran all runtime/cds tests on Linux x64 > - GHAs This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24311 From dholmes at openjdk.org Fri May 30 06:36:39 2025 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 May 2025 06:36:39 GMT Subject: RFR: 8350029: Illegal invokespecial interface not caught by verification Message-ID: As described in the JBS problem statement there was a missing verification check for bad `invokespecial` call, though it did result in a runtime exception. That gap has now been closed by checking if the target of the invocation is an interface type, which we can check when the type gets loaded as part of the assignability check. The existing code was very difficult to follow so I have added significant commentary in the verifier. I also improved the naming in the assignability checking code to make it easier to follow. Finally, the existing linkage error was using an incorrect error message to describe the problem it was encountering. Testing: - new test case - tiers 1-3 Thanks ------------- Commit messages: - 8350029: Illegal invokespecial interface not caught by verification Changes: https://git.openjdk.org/jdk/pull/25538/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25538&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350029 Stats: 263 lines in 8 files changed: 209 ins; 1 del; 53 mod Patch: https://git.openjdk.org/jdk/pull/25538.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25538/head:pull/25538 PR: https://git.openjdk.org/jdk/pull/25538 From duke at openjdk.org Fri May 30 09:31:53 2025 From: duke at openjdk.org (Anton Artemov) Date: Fri, 30 May 2025 09:31:53 GMT Subject: RFR: 8265754: Move suspend/resume API from HandshakeState [v2] In-Reply-To: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> References: <8rbYs-5Z9kcgJUBijDk4zVmKFcCbCwAUp51c3OghOvs=.b8230169-50db-401e-8af8-ef4389a99e84@github.com> Message-ID: On Wed, 28 May 2025 18:36:05 GMT, Patricio Chilano Mateo wrote: >> Anton Artemov 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 10 additional commits since the last revision: >> >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring to static methods. >> - 8265754: Fixed indentation. >> - 8265754: Fixed indentation >> - 8265754: Fixed indentation and lost newline. >> - 8265754: Fixed whitespaces errors. >> - 8265754: More work. >> - Merge remote-tracking branch 'origin/master' into JDK-8265754 >> - 8265754: Refactoring suspend/resume in the HandshakeState away > > In order to fully move suspend/resume code outside of `HandshakeState` we should also move `_suspended`/`_async_suspend_handshake`, otherwise we are just adding an extra indirection with class `HandshakeSuspender` IMO. The idea behind this bug was to define suspend/resume and related HandshakeClosure definitions without needing extra knowledge in `HandshakeState`, like any other HandshakeClosures. The reason why this is not straightforward is because of the interaction with the `HandshakeState` lock. But if we are going to give access to it to `HandshakeSuspender` we might as well give it to `JavaThread` instead and move everything there as that?s where all methods naturally belong. Something like this: https://github.com/pchilano/jdk/commit/4e870069e207ad2e8ba11ab1904a8df04961cef3 Thanks @pchilano, I agree that the refactoring I proposed is adding an extra layer. What you propose is moving the functionality to JavaThread. I think we need to come to an agreement on where it should belong to. @dholmes-ora do you have an opinion on that? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25407#issuecomment-2921781253 From aph at openjdk.org Fri May 30 09:39:55 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 30 May 2025 09:39:55 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: <48oazWguEzhed-3DjNN-qBs9-Wkgt-FiUqhZfWG6p7I=.5eaf9da8-6e1b-4575-9208-8136c0d40038@github.com> On Wed, 28 May 2025 15:05:51 GMT, Erik ?sterlund wrote: > But I suppose the reason for making it conditional might have rather been to be more precise about what the actual constraints are and not try to conservatively mask cases that absolutely should not need the fence for correctness. I like to think so, but I can't rightly remember. At the time, I don't think I knew of any test failures: the problem was purely theoretical. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2921804618 From aph at openjdk.org Fri May 30 09:42:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 30 May 2025 09:42:53 GMT Subject: RFR: 8351997: AArch64: Interpreter volatile reference stores with G1 are not sequentially consistent In-Reply-To: References: Message-ID: On Wed, 28 May 2025 11:04:11 GMT, Andrew Haley wrote: > > It would surely be better if this evil were expunged from JDK 21 as well, lest it also confuse a backporter. > > Maybe a "here be dragons" warning would suffice. If you add the following comment above every call to `do_oop_store()` I'll approve this patch: `// Clobbers: r10, r11, r3` ------------- PR Comment: https://git.openjdk.org/jdk/pull/25483#issuecomment-2921812748 From jsjolen at openjdk.org Fri May 30 12:18:54 2025 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Fri, 30 May 2025 12:18:54 GMT Subject: RFR: 8353444: NMT: rename 'category' to 'MemTag' in malloc tracker In-Reply-To: References: Message-ID: On Wed, 14 May 2025 13:22:40 GMT, Afshin Zafari wrote: > Renamed usage of 'category' for 'MemTag' cases. Can we use `category` as the term for any user-facing things? I'm thinking output from tooling, input options, docs, etc. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25226#issuecomment-2922237831 From iklam at openjdk.org Fri May 30 17:03:52 2025 From: iklam at openjdk.org (Ioi Lam) Date: Fri, 30 May 2025 17:03:52 GMT Subject: RFR: 8358035: Remove unused `compute_fingerprint` declaration in `ClassFileStream` In-Reply-To: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> References: <-Ut5ijhasTXNWEj9TvWqwsA4lFHUGu7wvnYcWsHYLbk=.6a0f6b1f-aa8b-46d8-ae94-28e7a602ba68@github.com> Message-ID: On Thu, 29 May 2025 08:09:14 GMT, Qizheng Xing wrote: > In JDK-8264805 (part of JEP 410), the implementation of `compute_fingerprint` was removed from `ClassFileStream`, but its declaration was left in place, which was unused and should be removed. This patch removes that declaration. LGTM ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25518#pullrequestreview-2881914653 From gziemski at openjdk.org Fri May 30 17:10:58 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 30 May 2025 17:10:58 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> References: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> Message-ID: On Thu, 22 May 2025 13:37:39 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > visualizations added. 1st try. Changes requested by gziemski (Reviewer). test/hotspot/gtest/nmt/test_vmatree.cpp line 3211: > 3209: // 1 2 3 4 5 > 3210: // 012345678901234567890123456789012345678901234567890 > 3211: // rrrrrrrrrr..........rrrrrrrrrr What is this comment supposed to show? I cleaned up, some comments and created a branch https://github.com/openjdk/jdk/compare/master...gerard-ziemski:jdk:gerard-8351661 in case you want to see it. ------------- PR Review: https://git.openjdk.org/jdk/pull/24028#pullrequestreview-2881928654 PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2116279532 From gziemski at openjdk.org Fri May 30 17:41:00 2025 From: gziemski at openjdk.org (Gerard Ziemski) Date: Fri, 30 May 2025 17:41:00 GMT Subject: RFR: 8351661: NMT: VMATree should support separate call-stacks for reserve and commit operations [v33] In-Reply-To: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> References: <05uGliTh8Mrzf1dvbVtpNcg1blmcf-5Yz0GlGK0D7sQ=.654ea6e8-203a-443c-8b36-2af002b3f752@github.com> Message-ID: On Thu, 22 May 2025 13:37:39 GMT, Afshin Zafari wrote: >> In NMT detail mode, we need to have separate call-stacks for Reserve and Commit operations. >> This PR adds a second stack to every node that will be used when committing (and uncommitting) the start node of a reserved region. > > Afshin Zafari has updated the pull request incrementally with one additional commit since the last revision: > > visualizations added. 1st try. src/hotspot/share/nmt/vmatree.hpp line 249: > 247: }; > 248: > 249: enum Operation {Release, Reserve, Commit, Uncommit, Invalid}; Can we drop `Invalid` and simplify the code? ``` enum Operation {Release, Reserve, Commit, Uncommit}; struct RequestInfo { position A, B; StateType _op; MemTag tag; SIndex callstack; bool use_tag_inplace; Operation op() const { return _op == StateType::Reserved && !use_tag_inplace ? Operation::Reserve : _op == StateType::Committed ? Operation::Commit : _op == StateType::Reserved && use_tag_inplace ? Operation::Uncommit : Operation::Release; } size_t op_to_index() const { return _op == StateType::Reserved && !use_tag_inplace ? 1 : _op == StateType::Committed ? 2 : _op == StateType::Reserved && use_tag_inplace ? 3 : 0; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24028#discussion_r2116322780 From cjplummer at openjdk.org Fri May 30 20:06:02 2025 From: cjplummer at openjdk.org (Chris Plummer) Date: Fri, 30 May 2025 20:06:02 GMT Subject: RFR: 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 Message-ID: Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed. Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes. ------------- Commit messages: - Remove CreateCoredumpOnCrash.java from problem list Changes: https://git.openjdk.org/jdk/pull/25556/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25556&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357924 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/25556.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25556/head:pull/25556 PR: https://git.openjdk.org/jdk/pull/25556 From ccheung at openjdk.org Sat May 31 00:34:06 2025 From: ccheung at openjdk.org (Calvin Cheung) Date: Sat, 31 May 2025 00:34:06 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation Message-ID: If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. To avoid the exception, this fix is not to start the management agent when creating an AOT cache. Passed tiers 1 - 4 testing. ------------- Commit messages: - 8352187: Don't start management agent during AOT cache creation Changes: https://git.openjdk.org/jdk/pull/25562/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25562&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352187 Stats: 27 lines in 2 files changed: 20 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/25562.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25562/head:pull/25562 PR: https://git.openjdk.org/jdk/pull/25562 From kvn at openjdk.org Sat May 31 01:07:53 2025 From: kvn at openjdk.org (Vladimir Kozlov) Date: Sat, 31 May 2025 01:07:53 GMT Subject: RFR: 8352187: Don't start management agent during AOT cache creation In-Reply-To: References: Message-ID: On Sat, 31 May 2025 00:30:09 GMT, Calvin Cheung wrote: > If a management agent is specified when creating an AOT cache, it resulted in `java.lang.IllegalArgumentException`. > To avoid the exception, this fix is not to start the management agent when creating an AOT cache. > > Passed tiers 1 - 4 testing. Good. ------------- Marked as reviewed by kvn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/25562#pullrequestreview-2882992223 From syan at openjdk.org Sat May 31 03:22:52 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 31 May 2025 03:22:52 GMT Subject: RFR: 8357924: Remove runtime/ErrorHandling/CreateCoredumpOnCrash.java from problem list for macosx-x64 In-Reply-To: References: Message-ID: On Fri, 30 May 2025 19:57:37 GMT, Chris Plummer wrote: > Remove CreateCoredumpOnCrash.java from problem list. JDK-8267433 was closed because it only reproduced with OSX 11, which is no longer supported. SA core file tests were removed from the problem list, but this test was missed. > > Test by running 100 times on macosx-x64 and macosx-x64-debug. Also ran hotspot_tier2_runtime 5 tmes. Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/25556#pullrequestreview-2883233602