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