From swen at openjdk.org Mon Dec 1 00:17:11 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 1 Dec 2025 00:17:11 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v3] In-Reply-To: References: Message-ID: > This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. > > When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. > > Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. > > Parsing scenarios show improvements from 12% to 95% Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28471/files - new: https://git.openjdk.org/jdk/pull/28471/files/7137d9ec..9a0ad61a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=01-02 Stats: 49 lines in 2 files changed: 20 ins; 18 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471 From swen at openjdk.org Mon Dec 1 02:33:33 2025 From: swen at openjdk.org (Shaojin Wen) Date: Mon, 1 Dec 2025 02:33:33 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: > This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. > > When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. > > Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. > > Parsing scenarios show improvements from 12% to 95% Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: bug fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28471/files - new: https://git.openjdk.org/jdk/pull/28471/files/9a0ad61a..073e2b8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=02-03 Stats: 20 lines in 1 file changed: 15 ins; 3 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471 From dholmes at openjdk.org Mon Dec 1 04:21:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 1 Dec 2025 04:21:52 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 In-Reply-To: References: Message-ID: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com> On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin wrote: > Hi everyone, > > Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. > > To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). > > To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. > > Testing: > * Oracle tiers 1-5 > * Local testing: > - `hotspot/jtreg/containers/` > - `jdk/jdk/internal/platform/docker/` > on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142: > 140: * > 141: * @return true if resource limits are supported in the current configuration > 142: * @throws Exception I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true of throws. These should just be void functions with names like `check_canUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2575563949 From jpai at openjdk.org Mon Dec 1 06:19:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 06:19:05 GMT Subject: RFR: 8372787: ModulePatcher$PatchedModuleReader throws unspecified IllegalStateException upon being invoked after close() Message-ID: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. ------------- Commit messages: - 8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close() Changes: https://git.openjdk.org/jdk/pull/28569/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372787 Stats: 127 lines in 2 files changed: 124 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From alanb at openjdk.org Mon Dec 1 06:57:50 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 06:57:50 GMT Subject: RFR: 8372787: ModulePatcher$PatchedModuleReader throws unspecified IllegalStateException upon being invoked after close() In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 06:08:00 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. @jaikiran Would it be possible to update the bug with a summary as to how this arise when using --patch-module? The proposed test is using the internal ModulePatcher directly and I think the starting point for discussion is an outline as to how anything using --patch-module runs into this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3594856116 From nbenalla at openjdk.org Mon Dec 1 08:53:37 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 1 Dec 2025 08:53:37 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla 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 17 additional commits since the last revision: - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - revert MAX_COLUMNS to 80 - Update LATEST_MAJOR_VERSION in Versions.java - Merge branch 'master' into start-of-release-27 - Merge branch 'master' into start-of-release-27 - ... and 7 more: https://git.openjdk.org/jdk/compare/41b7823d...e5214614 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/78895b2b..e5214614 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=05-06 Stats: 11187 lines in 367 files changed: 7430 ins; 1793 del; 1964 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From vklang at openjdk.org Mon Dec 1 09:11:29 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 1 Dec 2025 09:11:29 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v2] In-Reply-To: References: Message-ID: On Sun, 30 Nov 2025 00:30:05 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Hi @kilink, This PR is currently missing a test case or two. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3595404156 From jpai at openjdk.org Mon Dec 1 10:22:19 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:22:19 GMT Subject: RFR: 8372787: ModulePatcher$PatchedModuleReader throws unspecified IllegalStateException upon being invoked after close() [v2] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/42cfa0aa..d0d261d1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=00-01 Stats: 239 lines in 4 files changed: 108 ins; 126 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Mon Dec 1 10:27:47 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:27:47 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:22:19 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed > - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" > > This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. Based on the discussion in the linked JBS issue, I have changed the proposed fix and also rewritten the new jtreg test case. The test fails without the source changes in this PR and passes with it. When it fails, it fails due to the IOException not being thrown after the ModuleReader has been closed. I think this addresses the underlying problem that you described in the issue. If not, please do let me know and I will discuss with you further. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3595768885 From jpai at openjdk.org Mon Dec 1 10:31:54 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:31:54 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:22:19 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed > - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" > > This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 314: > 312: */ > 313: public Resource findResource(String name) throws IOException { > 314: ensureOpen(); Unlike the other methods which have been updated to call the `ensureOpen()`, this `findResource(...)` method isn't part of the `ModuleReader` interface. This only gets called from the `BuiltinClassLoader` when defining a `Class`. I looked up that code in `BuiltinClassLoader` and it already has a catch clause to handle `IOException`, so it felt right to add the `ensureOpen()` check here too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576514762 From alanb at openjdk.org Mon Dec 1 10:43:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 10:43:57 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:22:19 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed > - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" > > This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 228: > 226: private final URL delegateCodeSourceURL; > 227: private volatile ModuleReader delegate; > 228: private volatile boolean closed; A ModuleReader is specified to not require to support async close, so need to think about whether the closed flag should be volatile or not. src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 420: > 418: } > 419: > 420: private void ensureOpen() throws IOException { Can you move this to after the delegate() method? test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 84: > 82: "ModuleReader.open(String)"); > 83: assertThrows(IOException.class, () -> reader.find(rn), > 84: "ModuleReader.find(String)"); Would it be possible to say which methods throw ISE or IOE? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576549408 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576545166 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576553111 From alanb at openjdk.org Mon Dec 1 10:44:00 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 10:44:00 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:28:39 GMT, Jaikiran Pai wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed >> - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" >> >> This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. > > src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 314: > >> 312: */ >> 313: public Resource findResource(String name) throws IOException { >> 314: ensureOpen(); > > Unlike the other methods which have been updated to call the `ensureOpen()`, this `findResource(...)` method isn't part of the `ModuleReader` interface. This only gets called from the `BuiltinClassLoader` when defining a `Class`. I looked up that code in `BuiltinClassLoader` and it already has a catch clause to handle `IOException`, so it felt right to add the `ensureOpen()` check here too. It would be a serious bug if we could somehow close the ModuleReader under the feet of the built-in class loaders. We could potentially use an assert here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576544760 From jpai at openjdk.org Mon Dec 1 10:55:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:55:59 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v3] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: <-jSRMmv69DTeeYrASA0-TJL2GhvNGFpiZEnm2zYv1KU=.9180154b-4684-49f1-ab6b-6c785c416b53@github.com> > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: - move ensureOpen() to a few lines up - assert instead of ensureOpen() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/d0d261d1..0037de29 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=01-02 Stats: 13 lines in 1 file changed: 6 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Mon Dec 1 10:56:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:56:02 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:38:39 GMT, Alan Bateman wrote: >> src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 314: >> >>> 312: */ >>> 313: public Resource findResource(String name) throws IOException { >>> 314: ensureOpen(); >> >> Unlike the other methods which have been updated to call the `ensureOpen()`, this `findResource(...)` method isn't part of the `ModuleReader` interface. This only gets called from the `BuiltinClassLoader` when defining a `Class`. I looked up that code in `BuiltinClassLoader` and it already has a catch clause to handle `IOException`, so it felt right to add the `ensureOpen()` check here too. > > It would be a serious bug if we could somehow close the ModuleReader under the feet of the built-in class loaders. We could potentially use an assert here. I have updated the PR to use an assert here instead of ensureOpen() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576588373 From jpai at openjdk.org Mon Dec 1 10:56:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 10:56:05 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:38:48 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed >> - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" >> >> This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. > > src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 420: > >> 418: } >> 419: >> 420: private void ensureOpen() throws IOException { > > Can you move this to after the delegate() method? Done, I've updated the PR to move this just after the delegate() method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576587433 From jpai at openjdk.org Mon Dec 1 11:00:58 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 11:00:58 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:41:15 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed >> - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" >> >> This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. > > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 84: > >> 82: "ModuleReader.open(String)"); >> 83: assertThrows(IOException.class, () -> reader.find(rn), >> 84: "ModuleReader.find(String)"); > > Would it be possible to say which methods throw ISE or IOE? (I mean in a PR comment, not in the test). Do you mean which of these 3 methods (find, read and open()) were failing without this fix? `find()` and `open()` were failing to throw an IOException before this fix, thus failing this test. Do note that the current updated test doesn't actually exercise the `JarResourceFinder`. So this failing test wasn't seeing a `IllegalStateException` from any of these methods. I can update this test to additionally include a JAR file as a path to --patch-module, if you suggest. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576605360 From jpai at openjdk.org Mon Dec 1 11:08:12 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 11:08:12 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 10:40:17 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed >> - Revert "8372787: ModulePatcher throws unspecified IllegalStateException upon being invoked after close()" >> >> This reverts commit 42cfa0aa40926b748c6d7bdf814d85ca1ccd8fed. > > src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 228: > >> 226: private final URL delegateCodeSourceURL; >> 227: private volatile ModuleReader delegate; >> 228: private volatile boolean closed; > > A ModuleReader is specified to not require to support async close, so need to think about whether the closed flag should be volatile or not. My original motivation to use `volatile` for `closed` was to match what we have for `delegate`. But the volatile on that, I believe, is for a different reason (for example: to avoid multiple `delegate` creations when different entry points into the `ModuleReader` are used concurrently). In the latest update of the PR I have retained the `volatile` on `closed`, but I'm leaning towards removing that. But I'll wait for your input. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576618790 From alanb at openjdk.org Mon Dec 1 11:08:17 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 11:08:17 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v3] In-Reply-To: <-jSRMmv69DTeeYrASA0-TJL2GhvNGFpiZEnm2zYv1KU=.9180154b-4684-49f1-ab6b-6c785c416b53@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <-jSRMmv69DTeeYrASA0-TJL2GhvNGFpiZEnm2zYv1KU=.9180154b-4684-49f1-ab6b-6c785c416b53@github.com> Message-ID: On Mon, 1 Dec 2025 10:55:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: > > - move ensureOpen() to a few lines up > - assert instead of ensureOpen() src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 295: > 293: } > 294: > 295: private void ensureOpen() throws IOException { The private methods have a short description so you'll want to do the same here. test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 44: > 42: * @run junit/othervm ${test.main.class} > 43: */ > 44: class PatchedModuleReaderTest { The suggests that it's a complete test for a ModuleReader when the module is patched but it is more specific so I think my main main is to rename and split up testIOExceptionUponClose so that it is a more complete test for a ModuleReader when the module has been patched with --patch-module. test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 54: > 52: */ > 53: @Test > 54: void testIOExceptionUponClose() throws Exception { "AfterClose" rather than "UponClose". test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 59: > 57: .orElseThrow(); > 58: final ModuleReader reader; > 59: final Stream resources; The use of finals on the locals to ensure a single assignment is a distraction here. Once this test method is split once into small tests then you can get rid of the finals. test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 64: > 62: try (var _ = reader = mref.open()) { > 63: // verify we are using the patched module > 64: final String resourceName = "java/lang/PatchedFoo.class"; This should be a separate test method. test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 71: > 69: assertTrue(reader.find(nonExistentResource).isEmpty(), > 70: "unexpected resource " + nonExistentResource + " in " > 71: + mref.descriptor().name() + " module"); This should be a separate test method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576595215 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576621876 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576600609 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576619469 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576615378 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576615962 From smonteith at openjdk.org Mon Dec 1 12:07:02 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 12:07:02 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. Message-ID: MemorySegments allocated from shared Arena from java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | After: | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | |---------|-------|-------|-------|-------|-------|-------| | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 | 16.52 | | 16 | 70.15 | 47.76 | 52.37 | 47.26 | 70.91 | 14.53 | | 24 | 77.38 | 78.14 | 81.67 | 71.98 | 87.20 | 21.70 | | 32 | 87.54 | 98.01 | 84.73 | 86.79 | 109.25 | 22.65 | | 48 | 121.54| 128.14 | 120.51 | 104.35 | 175.08 | 26.85 | ------------- Commit messages: - 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas Changes: https://git.openjdk.org/jdk/pull/28575/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28575&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371260 Stats: 628 lines in 33 files changed: 402 ins; 38 del; 188 mod Patch: https://git.openjdk.org/jdk/pull/28575.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28575/head:pull/28575 PR: https://git.openjdk.org/jdk/pull/28575 From cnorrbin at openjdk.org Mon Dec 1 12:45:06 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 12:45:06 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: > Hi everyone, > > Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. > > To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). > > To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. > > Testing: > * Oracle tiers 1-5 > * Local testing: > - `hotspot/jtreg/containers/` > - `jdk/jdk/internal/platform/docker/` > on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: reworked check docker/resourcelimit functions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28557/files - new: https://git.openjdk.org/jdk/pull/28557/files/e9297412..986b3923 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28557&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28557&range=00-01 Stats: 112 lines in 27 files changed: 0 ins; 69 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/28557.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28557/head:pull/28557 PR: https://git.openjdk.org/jdk/pull/28557 From jpai at openjdk.org Mon Dec 1 12:49:13 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 12:49:13 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v4] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: apply review suggestions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/0037de29..30ce204c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=02-03 Stats: 60 lines in 2 files changed: 42 ins; 14 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Mon Dec 1 12:49:16 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 12:49:16 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v3] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <-jSRMmv69DTeeYrASA0-TJL2GhvNGFpiZEnm2zYv1KU=.9180154b-4684-49f1-ab6b-6c785c416b53@github.com> Message-ID: On Mon, 1 Dec 2025 10:54:41 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision: >> >> - move ensureOpen() to a few lines up >> - assert instead of ensureOpen() > > src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 295: > >> 293: } >> 294: >> 295: private void ensureOpen() throws IOException { > > The private methods have a short description so you'll want to do the same here. Done. > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 59: > >> 57: .orElseThrow(); >> 58: final ModuleReader reader; >> 59: final Stream resources; > > The use of finals on the locals to ensure a single assignment is a distraction here. Once this test method is split once into small tests then you can get rid of the finals. I've updated the PR to refactor the test into more than one test method and also cleaned it up to remove the usage of `final`s. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576935542 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2576937567 From cnorrbin at openjdk.org Mon Dec 1 12:52:48 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 12:52:48 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com> References: <5wBcMRj8jDv-vnUNYD8CdotWx9x1UjUhboVdPE-zox4=.eb8d1086-de7b-4a0e-b61e-1cca3c768571@github.com> Message-ID: <4wL0GNT4iNlJ95Dt43mwpRYI82DIXa6mFfLGvaVpH0w=.a8643ade-7687-41e8-b378-d3faae4084b2@github.com> On Mon, 1 Dec 2025 04:18:47 GMT, David Holmes wrote: >> Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: >> >> reworked check docker/resourcelimit functions > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 142: > >> 140: * >> 141: * @return true if resource limits are supported in the current configuration >> 142: * @throws Exception > > I don't like this pattern of making a function seem like it is a query by declaring it returns a boolean when in reality it either returns true or else throws. These should just be void functions with names like `checkCanUseResourceLimits`, and we can elide the fake `if` conditions with unreachable `return` statements in the callers. I agree that it could be made clearer. I reworked both `canUseResourceLimits()` and `canTestDocker()` into `void` functions that only throw. So ```c++ if (!DockerTestUtils.canTestDocker() || !DockerTestUtils.canUseResourceLimits()) { return; } Instead becomes: ```c++ DockerTestUtils.checkCanTestDocker(); DockerTestUtils.checkCanUseResourceLimits(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28557#discussion_r2576955639 From alanb at openjdk.org Mon Dec 1 13:15:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:15:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596489652 From alanb at openjdk.org Mon Dec 1 13:20:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 13:20:49 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... src/java.base/windows/classes/sun/nio/ch/WindowsAsynchronousFileChannelImpl.java line 396: > 394: private final PendingFuture result; > 395: private volatile boolean released; > 396: private int ticket; // to release buffer scope This is for substitution, so needs to be declared with buf (further down), and needs to be volatile (can't use plain access as it may be released on different thread). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2577021290 From smonteith at openjdk.org Mon Dec 1 13:48:47 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 13:48:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: <49FGQkAhjaiL3NugHvEzFGQhwTOf1oOKIPAUihJDgF0=.f19c5f9b-fa41-4fbe-9223-cba043dfa1d0@github.com> On Mon, 1 Dec 2025 13:13:13 GMT, Alan Bateman wrote: > Can you confirm that you aren't planning to try to try to integrate this before the fork for JDK 26 this week? There are several discussion points, and some of the changes are in risky areas, will likely need back time in main line. I am not planning, and wouldn't want to integrate this just before a fork. While I've checked it the best I can, I'd appreciate some scrutiny. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3596636408 From rriggs at openjdk.org Mon Dec 1 14:15:00 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 Dec 2025 14:15:00 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen wrote: >> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. >> >> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. >> >> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. >> >> Parsing scenarios show improvements from 12% to 95% > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > bug fix Spreading out and duplicating the state across multiple classes isn't very satisfactory. Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed. Always create the initial EnumMap and refactor the `fieldValues.put()` calls to a private utility method to catch the ClassCatchException and upgrade the map to a HashMap. That should retain the performance improvements without any extra overhead or non-local code changes for all of the normal cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3596762057 From mli at openjdk.org Mon Dec 1 15:13:13 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 1 Dec 2025 15:13:13 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> Message-ID: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> > Hi, > > This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. > > This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. > > Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. > > # Test > ## Jtreg > > in progress... > > ## Performance > > Column names meanings: > * p: with patch > * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on > * m: without patch > * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on > > #### Average improvement > > NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. > > For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. > > Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) > -- | -- | -- | -- > 1.022782609 | 2.198717391 | 2.162673913 | 2.199 > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: - remove log_warning - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28309/files - new: https://git.openjdk.org/jdk/pull/28309/files/46b32186..077dc35c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28309&range=05-06 Stats: 226 lines in 2 files changed: 214 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28309.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28309/head:pull/28309 PR: https://git.openjdk.org/jdk/pull/28309 From mli at openjdk.org Mon Dec 1 15:13:15 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 1 Dec 2025 15:13:15 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v6] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <7kh5C9nj7bf6432cG35kDDvV6zhnKEspe8AcYetJ1do=.e1d9ebd3-d80d-4621-8c1e-c77dc721d0df@github.com> Message-ID: On Tue, 25 Nov 2025 09:39:26 GMT, Hamlin Li wrote: >> src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp line 2141: >> >>> 2139: case BoolTest::gt: >>> 2140: cmov_fp_cmp_fp_gt(op1, op2, dst, src, cmp_single, cmov_single); >>> 2141: log_warning(jit)("Float/Double BoolTest::gt path is not tested well, please report the test case!"); >> >> My local tests show this does happen. Try this: >> `$ make test TEST="./test/jdk/javax/sound/midi/Gervill/SoftFilter/TestProcessAudio.java" TEST_VM_OPTS="-XX:-TieredCompilation"` >> >> I think this could be a good reference if you want to add some extra tests for the two cases here. > > Thanks, I'll check it later. Sorry for the delayed response. I've added the test case to cover all the code paths. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2577477492 From sgehwolf at openjdk.org Mon Dec 1 15:33:10 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Dec 2025 15:33:10 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. >> >> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). >> >> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. >> >> Testing: >> * Oracle tiers 1-5 >> * Local testing: >> - `hotspot/jtreg/containers/` >> - `jdk/jdk/internal/platform/docker/` >> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > reworked check docker/resourcelimit functions This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK? ------------- PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525625824 From liach at openjdk.org Mon Dec 1 15:40:40 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 15:40:40 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v3] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Doc tweaks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/712dbf1c..7a1cfa4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=01-02 Stats: 25 lines in 1 file changed: 0 ins; 24 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From cnorrbin at openjdk.org Mon Dec 1 15:44:31 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Mon, 1 Dec 2025 15:44:31 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 15:30:04 GMT, Severin Gehwolf wrote: > This adds a dependency on `Metrics` for all the Hotspot container tests. I guess this is considered OK? I believe it's an acceptable trade-off. Many tests would need the dependancy anyway in addition to the full check for resource limits. I would rather abstract that away in a utility function, at the cost of a few other tests also requiring the module. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3597274354 From coleenp at openjdk.org Mon Dec 1 15:57:10 2025 From: coleenp at openjdk.org (Coleen Phillimore) Date: Mon, 1 Dec 2025 15:57:10 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v3] In-Reply-To: References: Message-ID: <379iBIu0uk_Af-5_RZUQBFNkGyFM7iYpe4B_hg93tn8=.95e6e771-31f5-4b89-8172-aa3d0837de25@github.com> On Mon, 1 Dec 2025 15:40:40 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Doc tweaks With one small change, the runtime part of this change looks good. src/hotspot/share/ci/ciField.cpp line 220: > 218: return false; > 219: // Explicit opt-in from system classes > 220: if (holder->trust_final_fields()) This is missing { } so not sure where it ends, especially that it encloses an if statement, and other code. ------------- Changes requested by coleenp (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3525748039 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2577662841 From alanb at openjdk.org Mon Dec 1 15:58:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 15:58:16 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v2] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 11:02:55 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 228: >> >>> 226: private final URL delegateCodeSourceURL; >>> 227: private volatile ModuleReader delegate; >>> 228: private volatile boolean closed; >> >> A ModuleReader is specified to not require to support async close, so need to think about whether the closed flag should be volatile or not. > > My original motivation to use `volatile` for `closed` was to match what we have for `delegate`. But the volatile on that, I believe, is for a different reason (for example: to avoid multiple `delegate` creations when different entry points into the `ModuleReader` are used concurrently). > > In the latest update of the PR I have retained the `volatile` on `closed`, but I'm leaning towards removing that. But I'll wait for your input. The access mode doesn't matter because it doesn't guard against an async close. That is okay because the spec doesn't require the ModuleReader to be asynchronously closeable. Give that --patch-module is mostly for testing then I think what you have is okay. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2577667780 From alanb at openjdk.org Mon Dec 1 15:58:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 15:58:11 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v4] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 12:49:13 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > apply review suggestions > The commit in this PR takes into account the `IllegalStateException` thrown by `JarFile` APIs and wraps them into a `IOException` to conform with the expectations of the `ModuleReader` APIs. Would it be possible to change the PR description as the current description pre-dates the discussion/diagnosis of the real issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3597344139 From alanb at openjdk.org Mon Dec 1 16:03:31 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 16:03:31 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v4] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 12:49:13 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > apply review suggestions test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 61: > 59: */ > 60: @Test > 61: void testPatchedResourcePresence() throws Exception { The exist tests use "found" and "not found" so maybe rename these to testResourceFound and testResourceNotFound. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2577685902 From liach at openjdk.org Mon Dec 1 16:03:38 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 16:03:38 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614 bin/generate-symbol-data.sh line 41: > 39: # - open a terminal program and run these commands: > 40: # cd "${JDK_CHECKOUT}"/src/jdk.compiler/share/data/symbols > 41: # bash ../../../../../bin/generate-symbol-data.sh "${JDK_N_INSTALL}" Same, extract to 26 doc/starting-next-release.md line 68: > 66: update annotation processor extended by `javac` tests to cover the new source version > 67: * `test/langtools/tools/javac/preview/classReaderTest/Client.nopreview.out` and `test/langtools/tools/javac/preview/classReaderTest/Client.preview.out`: update expected messages for preview errors and warnings > 68: * `test/langtools/tools/javac/versions/Versions.java`: add new source version to the set of valid sources and add new enum constant for the new class file version. Same remark, extract to 26 src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: > 380: * > 381: * @see 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1: > 1: /* Let's extract this change to 26 src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac.properties line 1: > 1: # Let's extract this for 26. src/jdk.compiler/share/data/symbols/README line 1: > 1: This directory contains history data for -release. Let's extract this for 26. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577666303 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577665823 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577662551 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577673512 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577675100 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577674956 From nbenalla at openjdk.org Mon Dec 1 16:03:40 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Mon, 1 Dec 2025 16:03:40 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> On Mon, 1 Dec 2025 15:52:42 GMT, Chen Liang wrote: >> Nizar Benalla 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 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/3c6406b2...e5214614 > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: > >> 380: * >> 381: * @see > 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> > > This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. Great idea Chen, I will open a PR for this today ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2577683094 From sgehwolf at openjdk.org Mon Dec 1 16:05:51 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Mon, 1 Dec 2025 16:05:51 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. >> >> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). >> >> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. >> >> Testing: >> * Oracle tiers 1-5 >> * Local testing: >> - `hotspot/jtreg/containers/` >> - `jdk/jdk/internal/platform/docker/` >> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > reworked check docker/resourcelimit functions OK ------------- Marked as reviewed by sgehwolf (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3525791884 From jpai at openjdk.org Mon Dec 1 16:08:35 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 16:08:35 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v5] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: rename test methods ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/30ce204c..adb01a65 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Mon Dec 1 16:08:38 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 16:08:38 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v4] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: <0cKD6oMYpfnc46_CTXYbKVaiCseCkkRpizuvDYdJA6k=.75637f5f-92f0-450f-b2a9-779af22ee041@github.com> On Mon, 1 Dec 2025 15:55:40 GMT, Alan Bateman wrote: > Would it be possible to change the PR description as the current description pre-dates the discussion/diagnosis of the real issue. Good point - I've updated it now. > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 61: > >> 59: */ >> 60: @Test >> 61: void testPatchedResourcePresence() throws Exception { > > The existing tests use "found" and "not found" so maybe rename these to testResourceFound and testResourceNotFound. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3597390016 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2577705747 From alanb at openjdk.org Mon Dec 1 16:29:39 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 16:29:39 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v5] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 16:08:35 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > rename test methods test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 66: > 64: Optional res = reader.find(resourceName); > 65: assertTrue(res.isPresent(), resourceName + " is missing in " > 66: + patchedModuleRef.descriptor().name() + " module"); A suggestion here is replace this assert with a more complete test to check that the URI's scheme is "file" and that its path component ends with "java/lang/PatchedFoo.class". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2577780963 From jpai at openjdk.org Mon Dec 1 16:44:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 16:44:06 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v6] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: Alan's suggestion - additional tests to the found resource URI ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/adb01a65..adf5feb1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=04-05 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Mon Dec 1 16:44:08 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 1 Dec 2025 16:44:08 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v5] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 16:27:20 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> rename test methods > > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 66: > >> 64: Optional res = reader.find(resourceName); >> 65: assertTrue(res.isPresent(), resourceName + " is missing in " >> 66: + patchedModuleRef.descriptor().name() + " module"); > > A suggestion here is replace this assert with a more complete test to check that the URI's scheme is "file" and that its path component ends with "java/lang/PatchedFoo.class". Done. The test continues to pass with this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2577830144 From darcy at openjdk.org Mon Dec 1 17:14:01 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 17:14:01 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v6] In-Reply-To: <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> Message-ID: On Mon, 1 Dec 2025 16:44:06 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - additional tests to the found resource URI Does this behavior change merit CSR review? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3597805989 From iris at openjdk.org Mon Dec 1 17:15:11 2025 From: iris at openjdk.org (Iris Clark) Date: Mon, 1 Dec 2025 17:15:11 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/3b597a10...e5214614 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3526121001 From naoto at openjdk.org Mon Dec 1 17:24:34 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 1 Dec 2025 17:24:34 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: <3QD5vRu2p1ZGb8VZtCa8RBVe1EWFLI3m77eV71g4fNY=.33964df0-b049-452b-95f5-e6e3d4439ef5@github.com> On Mon, 1 Dec 2025 14:12:42 GMT, Roger Riggs wrote: > Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed. +1. Never seen non-ChronoField in the wild ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3597853861 From alanb at openjdk.org Mon Dec 1 17:29:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 17:29:24 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v6] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> Message-ID: On Mon, 1 Dec 2025 17:11:18 GMT, Joe Darcy wrote: > Does this behavior change merit CSR review? The behavior change is hard to observe. You'd need use `--patch-module` to patch a module on the module path, create a ModuleReader to find/read resources from the patched module, and then attempt to do so after closing the reader. The expected IOException is not thrown, instead you will an unexpected IllegalStateException in the case of JAR files, or the success in the case of an exploded patch. I can't imagine anything depending on this behavor. It came up in the context of the Valhalla repo which has some temporary code that seem to be incorrectly closing a module reader. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3597882266 From jlu at openjdk.org Mon Dec 1 18:20:13 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 1 Dec 2025 18:20:13 GMT Subject: RFR: 8372609: Bug4944439 does not enforce locale correctly In-Reply-To: References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com> Message-ID: <-T8j-eEfRF-m62nZvr_cEgyBElcrxAypGREhVu_zHcY=.f3ff8846-8b68-4891-970f-dbefaf570753@github.com> On Thu, 27 Nov 2025 02:04:15 GMT, Jaikiran Pai wrote: >> This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one. >> >> In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method. >> >> I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer). > > Hello Justin, the change looks reasonable to me. I'm guessing the call to `NumberFormat.getInstance(...)` would still return and exercise a `DecimalFormat` instance, and thus the original intent of the test for JDK-4944439 would be preserved? @jaikiran Yes, `NumberFormat.getInstance` returns a plain `DecimalFormat` instance, so the original intent should remain the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28514#issuecomment-3598140797 From jlu at openjdk.org Mon Dec 1 18:20:14 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 1 Dec 2025 18:20:14 GMT Subject: RFR: 8372609: Bug4944439 does not enforce locale correctly In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com> References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com> Message-ID: <1j3MHRwT8pnGGEaJ-AwqVpwnjGYiIn6HZNYr8eNXmzw=.01884aac-c0eb-4f57-810e-db181d11c03a@github.com> On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu wrote: > This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one. > > In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method. > > I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer). Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28514#issuecomment-3598141354 From jlu at openjdk.org Mon Dec 1 18:20:15 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 1 Dec 2025 18:20:15 GMT Subject: Integrated: 8372609: Bug4944439 does not enforce locale correctly In-Reply-To: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com> References: <2VqV11GIXj4tLaLVuCgE5bpjin12Va6BH1GM2vd8VRw=.d05ea835-f7f2-4b24-bea4-cee7c2046595@github.com> Message-ID: On Wed, 26 Nov 2025 18:35:40 GMT, Justin Lu wrote: > This PR fixes a test bug where a `DecimalFormat` is instantiated in a static field (with the current default locale) before the test updates the system default to `Locale.US`. As a result, it may fail under various other locales, since a `Locale.US` configured `DecimalFormat` is not actually retrieved and the test expects one. > > In general, the preservation and restoring of the system locale is an obsolete process. The test is instead updated to just retrieve a `DecimalFormat` using a locale accepting factory method. > > I have manually confirmed that the tests passes with `-Duser.language=en -Duser.country=NL` on my machine, (which is the locale used in the reproducer). This pull request has now been integrated. Changeset: 45c0600d Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/45c0600d3abfa4bcd0338840523c0df69283afe2 Stats: 21 lines in 1 file changed: 0 ins; 17 del; 4 mod 8372609: Bug4944439 does not enforce locale correctly Reviewed-by: liach, jpai ------------- PR: https://git.openjdk.org/jdk/pull/28514 From alanb at openjdk.org Mon Dec 1 18:20:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 1 Dec 2025 18:20:51 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v6] In-Reply-To: <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> Message-ID: On Mon, 1 Dec 2025 16:44:06 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > Alan's suggestion - additional tests to the found resource URI src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 424: > 422: @Override > 423: public void close() throws IOException { > 424: closed = true; It might be a bit better to avoid the closeAll+delegate if already closed. test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 40: > 38: /* > 39: * @test > 40: * @bug 8372787 Can you fix the `@summary` so that it starts with "Test the .." or "Verify the ..." test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 110: > 108: > 109: // verify IOException is thrown by the closed ModuleReader > 110: resources.forEach(rn -> { The test should also check reader.list() throws IOException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2578160184 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2578158174 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2578154762 From mcimadamore at openjdk.org Mon Dec 1 18:26:47 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 1 Dec 2025 18:26:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... Thanks for working on this problem. At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598181959 From liach at openjdk.org Mon Dec 1 18:27:34 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 18:27:34 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: bracket styles ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/7a1cfa4a..d353bdbe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=02-03 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From heidinga at openjdk.org Mon Dec 1 18:55:09 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 1 Dec 2025 18:55:09 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: <-9yglNAoD81NuGyLSS0ehpkPZmqK66Qyd7h4UFcztGA=.56a84f5e-a29a-4fc0-b0d7-ce20cac37851@github.com> On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles A bit of meta-question about this PR and JEP 500: does this trust need to be rescinded if the user explicitly adds `--enable-final-field-mutation=` for the modules that contain these classes marked with the annotation? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598347264 From smonteith at openjdk.org Mon Dec 1 19:06:46 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Mon, 1 Dec 2025 19:06:46 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:24:07 GMT, Maurizio Cimadamore wrote: > Thanks for working on this problem. > > At the high level I understand your goal here. It is a bit unfortunate that we have to change the API for acquire/release which cascades in many smaller (but simple) changes throughout the JDK. But let's set that aside. Yes, that was regrettable. Originally I retained the "void release0()" that recalculated the "ticket", which resulted in fewer changes. However, it was felt the explicit ticket passing was less likely to introduce errors. > > The main (and more serious) issue with this PR is the decoupling of the liveness bit from the ref counting part. This is something that will require some time to work through to ensure correctness is preserved in all cases. > Yes, I had been grappling with the atomicity. The "acquireCount" and "state" are decoupled in the most recent revision of the, so this closing should either fail and not update state, or pass and complete the shutdown. However, the "state" and ScopedAccesses are complex, so I appreciate the scrutiny in that area. > More generally, it is generally advisable for such deep changes to perhaps reach out to panama-dev mailing list first, and maybe have a discussion/reach some consensus there, before moving ahead with a PR. That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3598403208 From darcy at openjdk.org Mon Dec 1 19:48:53 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 19:48:53 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/bec8ec07...e5214614 src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 394: > 392: * > 393: * @see 394: * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html"> Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578389248 From darcy at openjdk.org Mon Dec 1 19:52:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 19:52:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: <9vzVbgAOcM7Svoy5DoqhDVY4Tn2bysq9WAYpMsBcenc=.441a1ba8-3e46-41d2-bf77-afb86fe8515c@github.com> On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/04b667ed...e5214614 src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368: > 1366: } > 1367: > 1368: private static String formatAbbreviatedList(Collection values) { I think changing the policy here is okay, but it should be better documented in comments here. Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578399308 From liach at openjdk.org Mon Dec 1 20:23:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:23:49 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles This PR currently does not interact with JEP 500. However, as specified in `Field.set`, the result of setting a final field may be ignored, as Alan [commented](https://github.com/openjdk/jdk/pull/28540#discussion_r2573494589). So I don't think we need to rescind the current trusting even if users enable mutations. In addition, @DanHeidinga I made the same fault as you when I first saw `--enable-final-field-mutation=` - this actually represents the callers, instead of the target, of `Field.set`. The target of mutation is specified via `--add-opens`, if the target field is not public. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3598676839 From liach at openjdk.org Mon Dec 1 20:27:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:27:07 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required Message-ID: Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) ------------- Commit messages: - 8160821 Changes: https://git.openjdk.org/jdk/pull/28585/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8160821 Stats: 135 lines in 7 files changed: 104 ins; 20 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From liach at openjdk.org Mon Dec 1 20:27:07 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:27:07 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 20:09:38 GMT, Chen Liang wrote: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) java.lang.invoke tests all pass. New benchmark results for `VarHandleExact`: Benchmark Mode Cnt Score Error Units VarHandleExact.exact_exactInvocation avgt 30 0.380 ? 0.007 ns/op VarHandleExact.generic_exactInvocation avgt 30 0.389 ? 0.008 ns/op VarHandleExact.generic_genericInvocation avgt 30 0.384 ? 0.008 ns/op Submitting internal CI runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3598661038 From liach at openjdk.org Mon Dec 1 20:34:31 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 20:34:31 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v2] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Logical fallacy ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/522cbe9d..886d3918 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From rriggs at openjdk.org Mon Dec 1 21:19:30 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 1 Dec 2025 21:19:30 GMT Subject: RFR: 8367938: Test Serialization Compatibility of Class Objects Message-ID: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> ArchivedClassesTest is added to compare archived serialized class objects against current classes. Note: these are the serialized class objects themselves, for example `java.lang.String.class`, not instances of the class, for example "Hello". The archived classes reference was built against the latest released version: 25.0.1+8. The test fails if the serialized class reference archive is missing from the repository or if there are any incompatible changes to the serialized bytes. Normal output from the test includes: - The version of the serialized class archive - Listing (if any) of incompatible classes - Listing of classes with compatible changes - Listing of classes in the archive that are not in the current version - Listing of classes in the current version not found in the archive The change of java.nio.ByteOrder from a class to enum is reported as an approved incompatible change. ------------- Commit messages: - Add ArchivedClassesTest to compare archived serialized classes against Changes: https://git.openjdk.org/jdk/pull/28586/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28586&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8367938 Stats: 3145 lines in 2 files changed: 3145 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28586.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28586/head:pull/28586 PR: https://git.openjdk.org/jdk/pull/28586 From duke at openjdk.org Mon Dec 1 21:37:49 2025 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Mon, 1 Dec 2025 21:37:49 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v3] In-Reply-To: References: <-T2GCGJ65G8TIOOQKNBTv8ACbSZfRGQpcbPyP8OklJI=.01384c3d-e2ca-4b1e-90d3-051add584d6d@github.com> Message-ID: On Sun, 30 Nov 2025 23:41:36 GMT, Piotr Tarsa wrote: >> Hi all, >> >> Please find my latest changes: I improved mixed insertion sort >> (and therefore the whole sorting), added description of sorting logic >> and created code template to reduce the duplication. Also I >> added a generation script. >> >> @DougLea Doug Lea >> @jatin-bhateja, @jbhateja Jatin Bhateja >> @tarsa Piotr Tarsa >> >> Please look at the latest sources. > > @VladimirIaroslavski: the organization (code partitioning) of the template looks good overall. iiuc the template + generator together are more than twice shorter than the original full java code, so the gains are definitely there. one small extra suggestion (not well thought out so you can ignore it): maybe it would be beneficial to apply such templating to test code too, if that makes sense? > > i have one suggestion to test out, i.e. speeding up counting in case the store-to-load forwarding (or memory disambiguation in general) in the cpu is not good enough. the idea is described here: https://fastcompression.blogspot.com/2014/09/counting-bytes-fast-little-trick-from.html and in short it's about replacing one counter array with multiple counter arrays that are modified one after another. the problem only occurs when frequently modifying same counters (i.e. same memory locations) back-to-back, e.g. if you're making histogram of data which has runs of the same value or run of a very few different values (modern cpus perform multiple operations at once, so they can try to count multiple values in parallel). in short: it's all explained in the article. some extra theory as to what is the mechanism in the cpu that's relevant to the counting optimisation is https://en.wikipedia.org/wiki/Load-Hit-Store and https://en.wikipedia.org/wiki/Memory_disambiguation#Store_to_load_forward ing but it's probably enough to just test out the idea without going too deep into theory. using multiple counter arrays of course adds some constant overhead (for allocation at the beginning and merging counters at the end of counting), so it would be beneficial for big enough arrays only. @tarsa I think we can introduce template to test class as well. I will return very soon. I will look at idea to use multiple counter arrays, will see the results. Thank you for suggestions! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3599009439 From erikj at openjdk.org Mon Dec 1 22:24:07 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Mon, 1 Dec 2025 22:24:07 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 08:53:37 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 17 additional commits since the last revision: > > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - Merge branch 'master' into start-of-release-27 > - Changes required for hard 80 character line limit > - Update --release 26 symbol information for JDK 26 build 25 > The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ > - revert MAX_COLUMNS to 80 > - Update LATEST_MAJOR_VERSION in Versions.java > - Merge branch 'master' into start-of-release-27 > - Merge branch 'master' into start-of-release-27 > - ... and 7 more: https://git.openjdk.org/jdk/compare/193bb114...e5214614 make/conf/version-numbers.conf line 40: > 38: DEFAULT_VERSION_CLASSFILE_MINOR=0 > 39: DEFAULT_VERSION_DOCS_API_SINCE=11 > 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26" Need to add 27 to this line. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2578923651 From naoto at openjdk.org Mon Dec 1 23:09:54 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 1 Dec 2025 23:09:54 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > minor doc formatting update make/jdk/src/classes/build/tools/generatecharacter/GenerateCaseFolding.java line 79: > 77: // hack, hack, hack! the logic does not pick 0131. just add manually to support 'I's. > 78: // 0049; T; 0131; # LATIN CAPITAL LETTER I > 79: final String T_0x0131_0x49 = String.format(" entry(0x%04x, 0x%04x),\n", 0x0131, 0x49); The 'T' status reads (in CaseFolding.txt): # T: special case for uppercase I and dotted uppercase I # - For non-Turkic languages, this mapping is normally not used. # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. Since this casefold feature is locale independent, should this `T` status be ignored? It might be helpful if we mention in the spec if we do this `T` case folding. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2579019726 From dlsmith at openjdk.org Mon Dec 1 23:36:54 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Mon, 1 Dec 2025 23:36:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 15:58:38 GMT, Nizar Benalla wrote: >> src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 382: >> >>> 380: * >>> 381: * @see >> 382: * href="https://docs.oracle.com/en/java/javase/26/docs/specs/jvms/index.html"> >> >> This change should be included in the codebase for JDK 26. You can create a new issue for this, and commit this change before this PR is integrated. > > Great idea Chen, I will open a PR for this today Better to use a relative url now and stop bumping the version with each release: href="../../../../specs/jvms/index.html" (Check my work on the number of dots, may be one or two off.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579082529 From liach at openjdk.org Mon Dec 1 23:41:04 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 23:41:04 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Tweak VH usage in some classes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/886d3918..7bcdcbf3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=01-02 Stats: 9 lines in 1 file changed: 0 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From naoto at openjdk.org Mon Dec 1 23:47:49 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 1 Dec 2025 23:47:49 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > minor doc formatting update src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69: > 67: * | 1:2 mapping | 0002 | 0000 | xxxx | xxxx | FB02 => 0066 006C > 68: * +---+---------+--------+---------+--------+--------+ > 69: * | 1:3 mapping | 0003 | xxxx | xxxx | xxxx | FB03 => 0066 0066 0069 What if 1:2/3 mappings included non-BMP case folded forms? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2579098131 From darcy at openjdk.org Mon Dec 1 23:52:47 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 1 Dec 2025 23:52:47 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 23:34:16 GMT, Dan Smith wrote: >> Great idea Chen, I will open a PR for this today > > Better to use a relative url now and stop bumping the version with each release: > > > href="../../../../specs/jvms/index.html" > > > (Check my work on the number of dots, may be one or two off.) I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579106368 From liach at openjdk.org Mon Dec 1 23:53:46 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 1 Dec 2025 23:53:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. Updated the Java calling convention to fix it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3599477724 From jlu at openjdk.org Mon Dec 1 23:57:01 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 1 Dec 2025 23:57:01 GMT Subject: RFR: 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods Message-ID: This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test. The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g. > [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0] As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.) ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/28590/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28590&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372844 Stats: 223 lines in 12 files changed: 45 ins; 90 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/28590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28590/head:pull/28590 PR: https://git.openjdk.org/jdk/pull/28590 From darcy at openjdk.org Tue Dec 2 00:07:20 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 2 Dec 2025 00:07:20 GMT Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] In-Reply-To: References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com> Message-ID: On Thu, 27 Nov 2025 13:46:19 GMT, James Yuzawa wrote: >> I have noticed in Java 25 (and earlier versions) that calling `ThreadLocalRandom.current().nextGaussian()` uses the Random.nextGaussian() implementation, which is synchronized. Under heavy load in a multithreaded environment, I was detecting lock contention. >> >> Here is a very simple reproducer: >> >> ThreadLocalRandom r = ThreadLocalRandom.current(); >> // step into this call using a debugger >> r.nextGaussian(); >> >> >> It dispatches to the synchronized Random implementation, since ThreadLocalRandom extends Random, thus the default implementation (not synchronizing) on RandomGenerator is not used. >> >> Sketch: >> >> public interface RandomGenerator { >> default double nextGaussian() { >> // remove TAOCP comment since it is out of date, and this uses the ziggurat algorithm instead >> return RandomSupport.computeNextGaussian(this); >> } >> } >> >> public class Random implements RandomGenerator { >> @Override >> public synchronized double nextGaussian() { >> // synchronized version ... >> } >> } >> >> public class ThreadLocalRandom extends Random { >> >> // ADD THIS >> @Override >> public double nextGaussian() { >> return RandomSupport.computeNextGaussian(this); >> } >> } >> >> >> A comment on ThreadLocalRandom states "This implementation of ThreadLocalRandom overrides the definition of the nextGaussian() method in the class Random, and instead uses the ziggurat-based algorithm that is the default for the RandomGenerator interface.? However, there is none such override happening. It appears that prior to a0ec2cb289463969509fe508836e3faf789f46d8 the nextGaussian implementation was non-locking since it used proper ThreadLocals. >> >> I conducted an audit of all of the RandomGenerator and Random methods to see if there are any others: >> >> >> Set tlrMethods = new HashSet<>(); >> for (Method method : java.util.concurrent.ThreadLocalRandom.class.getDeclaredMethods()) { >> int mod = method.getModifiers(); >> if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) { >> String desc = >> method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters()); >> tlrMethods.add(desc); >> } >> } >> for (Method method : java.util.Random.class.getDeclaredMethods()) { >> int mod = method.getModifiers(); >> if (!Modifier.isStatic(mod) && Modifier.isPublic(mod)) { >> String desc = >> method.getReturnType() + " " + method.getName() + " " + Arrays.toString(method.getParameters()); >> if (!tlrMethods.contains(desc)) { >> System.out.println(... > > James Yuzawa has updated the pull request incrementally with one additional commit since the last revision: > > 8372134: ThreadLocalRandom no longer overrides nextGaussian > > Update copyright header Catching up after being OOTO, I was trying to see if there was a minor spec change here that should have a quick retroactive CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28483#issuecomment-3599513080 From vlivanov at openjdk.org Tue Dec 2 00:25:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 00:25:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: > 2031: > 2032: @ForceInline > 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { Can you elaborate, please, how this method is intended to behave? test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: > 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) > 77: public static void addB() { > 78: var _ = (byte) B.getAndAdd(b2); > Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. It has performance implications for user code, doesn't it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579149358 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579150006 From dlsmith at openjdk.org Tue Dec 2 00:35:54 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Tue, 2 Dec 2025 00:35:54 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: <5HSynSVF8e5q3hAhVruyigrrDmFzIlkNVKuQwYl67r0=.e151612e-9c71-4a15-96bb-3fc5391438b6@github.com> Message-ID: On Mon, 1 Dec 2025 23:50:29 GMT, Joe Darcy wrote: >> Better to use a relative url now and stop bumping the version with each release: >> >> >> href="../../../../specs/jvms/index.html" >> >> >> (Check my work on the number of dots, may be one or two off.) > > I assume there is going to be some canonical publication of the JLS and JVMS specs per release. If so, these URLs should refer to that release. In JDK ($N+1) will will still want the links to JLS $N to resolve to JLS $N and _not_ JLS ($N + 1). Oh, yes, thanks Joe, I'd missed that context. If the goal is to have a stable URL that will always point to the snapshot for a given version, yes, you want the full URL, and this updated URL looks like the correct one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2579166554 From bpb at openjdk.org Tue Dec 2 00:57:15 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Dec 2025 00:57:15 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call Message-ID: Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. ------------- Commit messages: - 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call Changes: https://git.openjdk.org/jdk/pull/28592/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28592&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372851 Stats: 16 lines in 1 file changed: 13 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28592/head:pull/28592 PR: https://git.openjdk.org/jdk/pull/28592 From liach at openjdk.org Tue Dec 2 01:12:48 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:12:48 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> Message-ID: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> On Tue, 2 Dec 2025 00:20:21 GMT, Vladimir Ivanov wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak VH usage in some classes > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: > >> 2031: >> 2032: @ForceInline >> 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { > > Can you elaborate, please, how this method is intended to behave? When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. > test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: > >> 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) >> 77: public static void addB() { >> 78: var _ = (byte) B.getAndAdd(b2); > >> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. > > It has performance implications for user code, doesn't it? The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579218324 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579221253 From naoto at openjdk.org Tue Dec 2 01:41:47 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 01:41:47 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. Looks fine test/jdk/java/io/File/GetXSpace.java line 418: > 416: try { > 417: return getSpace0(root, space); > 418: } catch (RuntimeException e) { Would it also be helpful to print the exception itself? ------------- PR Review: https://git.openjdk.org/jdk/pull/28592#pullrequestreview-3527774866 PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2579278479 From vlivanov at openjdk.org Tue Dec 2 01:45:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 01:45:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:08:19 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2033: >> >>> 2031: >>> 2032: @ForceInline >>> 2033: MethodHandle adaptedMethodHandle(VarHandle vh) { >> >> Can you elaborate, please, how this method is intended to behave? > > When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579287707 From liach at openjdk.org Tue Dec 2 01:51:47 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:51:47 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> On Tue, 2 Dec 2025 01:42:50 GMT, Vladimir Ivanov wrote: >> When this is compiled, `constant` will become either `1` for constant VH and `2` for non-constant VH. So for constant VH, this becomes a stable read. For a non-constant VH, this becomes `getMethodHandle(mode).asType(...)`, equivalent to before. > > What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579302480 From vlivanov at openjdk.org Tue Dec 2 01:51:49 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 01:51:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:09:59 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/c2/irTests/TestGetAndAdd.java line 78: >> >>> 76: @IR(counts = {IRNode.X86_LOCK_XADDB, "3"}, phase = CompilePhase.FINAL_CODE) >>> 77: public static void addB() { >>> 78: var _ = (byte) B.getAndAdd(b2); >> >>> Since I removed the return type dropping VarHandle bypass, TestGetAndAdd became affected because it can no longer access the x86 assembly. >> >> It has performance implications for user code, doesn't it? > > The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. > > The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java ` intact? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579300293 From swen at openjdk.org Tue Dec 2 01:53:46 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 2 Dec 2025 01:53:46 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 14:12:42 GMT, Roger Riggs wrote: > Spreading out and duplicating the state across multiple classes isn't very satisfactory. Since non-ChronoField is very unlikely, I'd suggest a more localized change confined to Parsed. Always create the initial EnumMap and refactor the `fieldValues.put()` calls to a private utility method to catch the ClassCatchException and upgrade the map to a HashMap. That should retain the performance improvements without any extra overhead or non-local code changes for all of the normal cases. I also plan to upgrade EnumMap to a custom ChronoFieldMap, like this: https://github.com/wenshao/jdk/commit/b1cbc6295aa339a666996e910f46ab351e44726a Keeping the current implementation would be easier. image ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3599787338 From liach at openjdk.org Tue Dec 2 01:54:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 01:54:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: On Tue, 2 Dec 2025 01:48:13 GMT, Vladimir Ivanov wrote: >> The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. >> >> The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. > > If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java > ` intact? No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579310315 From bpb at openjdk.org Tue Dec 2 01:58:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Dec 2025 01:58:46 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 01:38:42 GMT, Naoto Sato wrote: > Would it also be helpful to print the exception itself? I had thought of printing the stack trace, if that's what you mean. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2579320183 From vlivanov at openjdk.org Tue Dec 2 02:02:46 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:02:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> Message-ID: On Tue, 2 Dec 2025 01:49:04 GMT, Chen Liang wrote: >> What's the purpose of `constant == MethodHandleImpl.CONSTANT_YES ` and `constant != MethodHandleImpl.CONSTANT_NO` checks then? > > Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. > > `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. I still have a hard time reasoning about state transitions of the cache. 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579329673 From vlivanov at openjdk.org Tue Dec 2 02:08:44 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:08:44 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> Message-ID: <53uGo7JI87pm-cZmvxBiHniURB_bKryyfrWpewgZLP8=.bb97af75-8a6d-4aa8-8a90-e8c4cbc77ec8@github.com> On Tue, 2 Dec 2025 01:52:04 GMT, Chen Liang wrote: >> If I understand the IR test logic correctly, C2 was able to compile `(void) B.getAndAdd(b2)` call down to the desired instruction sequence. Is it still the case after the fix? What happens if you keep `TestGetAndAdd.java >> ` intact? > > No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579341027 From liach at openjdk.org Tue Dec 2 02:16:52 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 02:16:52 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> Message-ID: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> On Tue, 2 Dec 2025 02:00:08 GMT, Vladimir Ivanov wrote: >> Indeed, I should move the adaptedMh read into `constant == MethodHandleImpl.CONSTANT_YES` block. >> >> `constant != MethodHandleImpl.CONSTANT_NO` prevents capturing any further if the VH is known non-constant; we keep this branch in constant case in case the adapted MH is not ready when we know the VH is constant. > > I still have a hard time reasoning about state transitions of the cache. > > 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? > > 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. >> No. The old code worked because it implicitly depended on the backdoor path present in the now removed `GUARD_METHOD_TEMPLATE_V` in `VarHandleGuardMethodGenerator`. If this test is intact, now its IR compiles to doing something in adaptedMethodHandle and calling a MethodHandle. Not sure why it doesn't inline through that MethodHandle. > > Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579352226 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579353722 From swen at openjdk.org Tue Dec 2 02:19:51 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 2 Dec 2025 02:19:51 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: <-LT8YIM5AXrKFxx0ZdIwmZFdS4Sx3SsJ5ooYsUJctT8=.4fcf6ddb-e4dc-473a-a730-c0b16369b09c@github.com> On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen wrote: >> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. >> >> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. >> >> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. >> >> Parsing scenarios show improvements from 12% to 95% > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > bug fix We should place more processing logic in the pattern parsing stage, rather than the text parsing stage. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3599870510 From naoto at openjdk.org Tue Dec 2 02:21:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 02:21:51 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 01:56:21 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/GetXSpace.java line 418: >> >>> 416: try { >>> 417: return getSpace0(root, space); >>> 418: } catch (RuntimeException e) { >> >> Would it also be helpful to print the exception itself? > >> Would it also be helpful to print the exception itself? > > I had thought of printing the stack trace, if that's what you mean. Yes, that was what I meant. I thought the more information, the better for debugging. But if it won't provide any useful info, I am fine with the current version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2579359657 From vlivanov at openjdk.org Tue Dec 2 02:32:47 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 02:32:47 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:13:15 GMT, Chen Liang wrote: >> I still have a hard time reasoning about state transitions of the cache. >> >> 1) Why do you limit successful cache read (`cache != null`) to constant `vh` case (`constant == MethodHandleImpl.CONSTANT_YES`)? >> >> 2) Why do you avoid cache update in non-constant case (`constant != MethodHandleImpl.CONSTANT_NO`)? What happens if it runs compiled `adaptedMethodHandle` method? > > So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? >> Ok, so you eliminated a fast-path check for void-return case and now JIT can't fully optimize it anymore. Do I get it right? Since this particular bytecode shape is exposed through public API, I don't see why user code can't step on it. > > JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579374286 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579375565 From liach at openjdk.org Tue Dec 2 02:54:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 02:54:46 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:29:28 GMT, Vladimir Ivanov wrote: >> So an `AccessDescriptor` is created for each sigpoly VH site in the source code. Usually it is `VH.operation()`, but it is legal to use a non-constant VarHandle variable and call an operation on that. If `constant == MethodHandleImpl.CONSTANT_NO`, we are sure that we have the non-constant case, so we cannot trust that cached method handle, and there is no point further caching. We can only read that previous MH conversion cache if `constant == MethodHandleImpl.CONSTANT_YES` because this means our cache is always correct. > > So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update. The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2579405388 From bpb at openjdk.org Tue Dec 2 03:50:46 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Dec 2025 03:50:46 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: <87s2FYP5JFd3oKQOjsVn6K7PDZd6v_1YGsu4qKVYLxE=.5896d4e7-057d-4c3c-8952-ae96ff43bbf9@github.com> On Tue, 2 Dec 2025 02:18:55 GMT, Naoto Sato wrote: > [...] if it won't provide any useful info, I am fine with the current version. Re-throwing the caught exception should provide the stack trace, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2579483699 From jpai at openjdk.org Tue Dec 2 06:58:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 06:58:51 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v7] In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: <560peA71rirY0JfDr0O942HLXQgYwW4MTivo8WGXKfw=.eec0142f-4757-4785-b734-e04ff5521e27@github.com> > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: - return early if already closed() - fix summary line - even test for ModuleReader.list() on a closed ModuleReader ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28569/files - new: https://git.openjdk.org/jdk/pull/28569/files/adf5feb1..6359d3c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28569&range=05-06 Stats: 8 lines in 2 files changed: 7 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28569.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28569/head:pull/28569 PR: https://git.openjdk.org/jdk/pull/28569 From jpai at openjdk.org Tue Dec 2 07:02:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 07:02:51 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v6] In-Reply-To: References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <48_lxwfU3JPuisiPz46HpCnfchy4w7eHo5cwLmvc4gM=.e1afd965-4271-4a4b-a488-0a578f82ba33@github.com> Message-ID: On Mon, 1 Dec 2025 18:18:07 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> Alan's suggestion - additional tests to the found resource URI > > src/java.base/share/classes/jdk/internal/module/ModulePatcher.java line 424: > >> 422: @Override >> 423: public void close() throws IOException { >> 424: closed = true; > > It might be a bit better to avoid the closeAll+delegate if already closed. Hello Alan, I've now updated the PR to return early if already closed. I have kept it a simple check and it won't take into account concurrent calls to `close()`. I think that's OK given what we discussed in this PR about async close. However, if you would like to have this be a bit more stronger (like we do with the `delegate` creation), then let me know and I will adjust this check in `close()` accordingly. > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 40: > >> 38: /* >> 39: * @test >> 40: * @bug 8372787 > > Can you fix the `@summary` so that it starts with "Test the .." or "Verify the ..." Done. > test/jdk/java/lang/module/ModuleReader/patched/PatchedModuleReaderTest.java line 110: > >> 108: >> 109: // verify IOException is thrown by the closed ModuleReader >> 110: resources.forEach(rn -> { > > The test should also check reader.list() throws IOException. Good catch. It was there previously but I lost that check after I refactored the first version of this test. I've added it back now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2579872453 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2579873014 PR Review Comment: https://git.openjdk.org/jdk/pull/28569#discussion_r2579879350 From jpai at openjdk.org Tue Dec 2 07:49:38 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 07:49:38 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test Message-ID: Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). I have triggered a tier testing of this change in our CI and will run a test repeat too. ------------- Commit messages: - 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test Changes: https://git.openjdk.org/jdk/pull/28595/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28595&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372857 Stats: 78 lines in 1 file changed: 18 ins; 39 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28595/head:pull/28595 PR: https://git.openjdk.org/jdk/pull/28595 From hgreule at openjdk.org Tue Dec 2 07:54:01 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Tue, 2 Dec 2025 07:54:01 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: On Tue, 2 Dec 2025 02:30:28 GMT, Vladimir Ivanov wrote: >> JIT can fully optimize it in JMH benchmarks. I don't know why the IR in this test can't optimize it - I couldn't reproduce this CI failure locally on my linux-x64-debug profile, but this modified test passes on CI. > > I'd say it's a bad sign. Intermittent bugs manifest exactly in such a way. > The performance is measured by the existing `org.openjdk.bench.java.lang.invoke.VarHandleExact` benchmark, which originally expects `generic_genericInvocation` to be much slower. Now it instead has a performance on par with the exact invocations. > > The constant folding ability is verified with the new `VarHandleMismatchedTypeFold` IR test. The benchmark doesn't consider such inexact getAndAdd calls (with a void return type), I think it should cover that too. This is a very common pattern that really must not regress. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580041626 From alanb at openjdk.org Tue Dec 2 08:18:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 08:18:54 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v7] In-Reply-To: <560peA71rirY0JfDr0O942HLXQgYwW4MTivo8WGXKfw=.eec0142f-4757-4785-b734-e04ff5521e27@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <560peA71rirY0JfDr0O942HLXQgYwW4MTivo8WGXKfw=.eec0142f-4757-4785-b734-e04ff5521e27@github.com> Message-ID: On Tue, 2 Dec 2025 06:58:51 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - return early if already closed() > - fix summary line > - even test for ModuleReader.list() on a closed ModuleReader Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28569#pullrequestreview-3528805026 From alanb at openjdk.org Tue Dec 2 08:29:03 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 08:29:03 GMT Subject: RFR: 8372134: ThreadLocalRandom no longer overrides nextGaussian [v5] In-Reply-To: References: <0eTqH75H3PYCIoH2Bi5W0fZo3mYXFmqSB6-cFSP9Oso=.340fbd7e-5079-4860-b31e-3316b82d991b@github.com> Message-ID: On Tue, 2 Dec 2025 00:04:17 GMT, Joe Darcy wrote: > Catching up after being OOTO, I was trying to see if there was a minor spec change here that should have a quick retroactive CSR. In the JDK 25 API docs, TLR doesn't override nextGaussian but does link to both Random.nextGaussian and RandomGenerator.nextGaussian. Random.nextGaussian's implSpec is the polar method. RandomGenerator.nextGaussian's implSpec is the McFarland ziggurat algorithm. With the update. TLR override's nextGaussian will an implNote that it uses the McFarland ziggurat algorithm by way of invoking RandomGenerator.nextGaussian. So it is using a different algorithm to before. I don't expect TLR.nextGaussian is used much and hasn't been possible to tell from the API docs since JDK 17 (and the changes in JEP 356) which algorithm it used. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28483#issuecomment-3600810096 From pminborg at openjdk.org Tue Dec 2 09:04:53 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Dec 2025 09:04:53 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/hotspot/share/opto/library_call.cpp line 8926: > 8924: bool LibraryCallKit::inline_isCompileConstant() { > 8925: Node* n = argument(0); > 8926: set_result(n->is_Con() ? intcon(1) : intcon(2)); Can we get constants for these magic numbers on the C side as well? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580266341 From duke at openjdk.org Tue Dec 2 09:09:35 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 2 Dec 2025 09:09:35 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v3] In-Reply-To: References: Message-ID: <7J-z_iy59MbtjbxIAgZGXb5O3oMxOz9uPLoRORjZ8ho=.5d949768-e179-4be9-9dfe-226eda885e91@github.com> > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: Add unit test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28568/files - new: https://git.openjdk.org/jdk/pull/28568/files/bbce28c3..9e7a1c50 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=01-02 Stats: 81 lines in 1 file changed: 81 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568 PR: https://git.openjdk.org/jdk/pull/28568 From duke at openjdk.org Tue Dec 2 09:09:35 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 2 Dec 2025 09:09:35 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v2] In-Reply-To: References: Message-ID: <93gOpYxK9pDxDH5VjHvDWttUarTkE0gTZkEeCmQjpzM=.110c7b8c-e056-4155-ab87-4ee8e700863b@github.com> On Mon, 1 Dec 2025 09:09:07 GMT, Viktor Klang wrote: > Hi @kilink, > > This PR is currently missing a test case or two. I've added a basic unit test that verifies the spliterator characteristics as well as the encounter order, let me know if you think that's sufficient. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3600963590 From pminborg at openjdk.org Tue Dec 2 09:31:03 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Dec 2025 09:31:03 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > 2034: var constant = MethodHandleImpl.isCompileConstant(vh); > 2035: var cache = adaptedMh; > 2036: if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) { Rookie question: Is there multi-thread considerations here? How about visibility across threads? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580353068 From dholmes at openjdk.org Tue Dec 2 09:34:14 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 2 Dec 2025 09:34:14 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. >> >> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). >> >> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. >> >> Testing: >> * Oracle tiers 1-5 >> * Local testing: >> - `hotspot/jtreg/containers/` >> - `jdk/jdk/internal/platform/docker/` >> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > reworked check docker/resourcelimit functions Thanks for the updates. Seems reasonable. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28557#pullrequestreview-3529119616 From pminborg at openjdk.org Tue Dec 2 09:42:49 2025 From: pminborg at openjdk.org (Per Minborg) Date: Tue, 2 Dec 2025 09:42:49 GMT Subject: Integrated: 8372258: Improve TypeVariable support In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 13:06:12 GMT, Per Minborg wrote: > The `TypeVariableImpl::getGenericDeclaration` method should return copies of generic declarations where appropriate. This pull request has now been integrated. Changeset: 7278d2e8 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/7278d2e8e5835f090672f7625d391a1b4c1a6626 Stats: 84 lines in 3 files changed: 78 ins; 0 del; 6 mod 8372258: Improve TypeVariable support Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28429 From eddy at linux.ibm.com Tue Dec 2 09:46:41 2025 From: eddy at linux.ibm.com (Eduard Stefes) Date: Tue, 02 Dec 2025 10:46:41 +0100 Subject: state of openjdk-zlib on s390x In-Reply-To: <64425285-ff54-4352-b67c-d39da31c9a38@oracle.com> References: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com> <64425285-ff54-4352-b67c-d39da31c9a38@oracle.com> Message-ID: <3902d0a2aa1923942fb6489059bd4f5933cc8645.camel@linux.ibm.com> Hi, I am very sorry for the late answer. On Wed, 2025-11-05 at 18:59 +0530, Jaikiran Pai wrote: > I had a look at https://bugs.openjdk.org/browse/JDK-8339216. That JBS > issue lacks the actual failure/exception that happens for that test. > Would it be possible to attach the .jtr file from a test execution > where it fails? Depending on what the failure is, I think it could be > addressed in that test. I attached the .jtr and also wrote an analysis here: https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2109016/comments/2 > > ?I will have to read up the RFCs in detail, but these reproducibility > tests have intentionally be written to catch issues like these. We > want the ZIP/JAR artifacts generated for the JDK to be reproducible. > We have been fixing bugs in the JDK, wherever possible, to make these > artifacts reproducible. I will talk to the hardware designers maybe there is a possibility after all. > > ?I am not familiar with that zlib code linked in [5] and [6]. But if > you or anyone else is familiar with it, then instead of this being a > environment variable evaluated at runtime on the host where the JDK > runs, maybe it could be implemented as a build time macro(?) in that > project? That would then allow you to pass a specific value during > build time of that project and control this behaviour? You would then > still have to do the work of "bundling" this zlib with the vendor > specific JDK that you build, but at least for that, the OpenJDK build > has the necessary infrastructure, see "--with-zlib" option in the > build docs of OpenJDK. Yes we could try to overload the normal zlib calls with macros and then at compile and link time resolve to different functions. IMHO this is really ugly and I dont see a chance to get this upstream in the official zlib api. Maybe we should try to introduce a Z_REPRODUCIBLE strategy parameter flag like zlib-ng had done[1].? Unfortunately zlib is famous for being very conservative and slow regarding changes. -- Eduard Stefes IBM [1]: https://github.com/zlib-ng/zlib-ng/blob/develop/arch/s390/README.md?plain=1#L39-L44 -------------- next part -------------- #Test Results (version 2) #Mon Nov 24 15:12:07 GMT 2025 #-----testdescription----- $file=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java $root=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk keywords=bug8193682 bug8278794 bug8284771 testng run=USER_SPECIFIED testng CloseInflaterDeflaterTest\n source=CloseInflaterDeflaterTest.java title=Test Infinite loop while writing on closed Deflater and Inflater. #-----environment----- #-----testresult----- description=file\:/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java elapsed=795 0\:00\:00.795 end=Mon Nov 24 15\:12\:07 GMT 2025 environment=regtest execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.Exception\: failures\: 6 harnessLoaderMode=Classpath Loader harnessVariety=Full Bundle hostname=7756dc4cb5bd javatestOS=Linux 6.15.0-20250525.rc7.git0.b89df08fd7d2.63.fc42.s390x (s390x) javatestVersion=6.0-ea+b22-1970-01-03-${BUILT_FROM_COMMIT} jtregVersion=jtreg 7.3.1 src 1 script=com.sun.javatest.regtest.exec.RegressionScript sections=script_messages build compile testng start=Mon Nov 24 15\:12\:07 GMT 2025 test=java/util/zip/CloseInflaterDeflaterTest.java testJDK=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk testJDK_OS=[name\:Linux,arch\:s390x,version\:6.15.0-20250525.rc7.git0.b89df08fd7d2.63.fc42.s390x,family\:linux,simple_arch\:s390x,simple_version\:6.15,processors\:32,maxMemory\:135097769984,maxSwap\:30744256512] testJDK_os.arch=s390x testJDK_os.name=Linux testJDK_os.version=6.15.0-20250525.rc7.git0.b89df08fd7d2.63.fc42.s390x totalTime=796 user.name=root work=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/java/util/zip #section:script_messages ----------messages:(4/271)---------- JDK under test: /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk openjdk version "21.0.8" 2025-07-15 OpenJDK Runtime Environment (build 21.0.8+9-Ubuntu-0ubuntu122.04.1) OpenJDK 64-Bit Server VM (build 21.0.8+9-Ubuntu-0ubuntu122.04.1, mixed mode, sharing) #section:build ----------messages:(7/240)---------- command: build CloseInflaterDeflaterTest reason: Named class compiled on demand started: Mon Nov 24 15:12:07 GMT 2025 Test directory: compile: CloseInflaterDeflaterTest finished: Mon Nov 24 15:12:07 GMT 2025 elapsed time (seconds): 0.483 result: Passed. Build successful #section:compile ----------messages:(7/301)---------- command: compile /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java reason: .class file out of date or does not exist started: Mon Nov 24 15:12:07 GMT 2025 Mode: agentvm Agent id: 1 finished: Mon Nov 24 15:12:07 GMT 2025 elapsed time (seconds): 0.48 ----------configuration:(15/948)---------- Boot Layer (javac runtime environment) class path: /usr/share/jtreg/lib/javatest.jar /usr/share/jtreg/lib/jtreg.jar patch: java.base /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/patches/java.base javac compilation environment source path: /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip class path: /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d /usr/share/jtreg/lib/testng.jar /usr/share/jtreg/lib/guice.jar /usr/share/jtreg/lib/jcommander.jar /usr/share/jtreg/lib/slf4j-simple.jar /usr/share/jtreg/lib/slf4j-api.jar ----------rerun:(32/3757)*---------- cd /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/scratch/0 && \\ HOME=/root \\ LC_ALL=C \\ PATH=/bin:/usr/bin:/usr/sbin \\ TEST_IMAGE_DIR=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/test \\ _JVM_DWARF_PATH=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/symbols \\ /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk/bin/javac \\ -J-Xmx768m \\ -J-XX:MaxRAMPercentage=1.5625 \\ -J-Dtest.boot.jdk=/usr/lib/jvm/java-21-openjdk-s390x \\ -J-Djava.io.tmpdir=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/tmp \\ -J-ea \\ -J-esa \\ -J-Dtest.vm.opts='-Xmx768m -XX:MaxRAMPercentage=1.5625 -Dtest.boot.jdk=/usr/lib/jvm/java-21-openjdk-s390x -Djava.io.tmpdir=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/tmp -ea -esa' \\ -J-Dtest.tool.vm.opts='-J-Xmx768m -J-XX:MaxRAMPercentage=1.5625 -J-Dtest.boot.jdk=/usr/lib/jvm/java-21-openjdk-s390x -J-Djava.io.tmpdir=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/tmp -J-ea -J-esa' \\ -J-Dtest.compiler.opts= \\ -J-Dtest.java.opts= \\ -J-Dtest.jdk=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk \\ -J-Dcompile.jdk=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk \\ -J-Dtest.timeout.factor=4.0 \\ -J-Dtest.nativepath=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/test/jdk/jtreg/native \\ -J-Dtest.root=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk \\ -J-Dtest.name=java/util/zip/CloseInflaterDeflaterTest.java \\ -J-Dtest.file=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java \\ -J-Dtest.src=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -J-Dtest.src.path=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -J-Dtest.classes=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d \\ -J-Dtest.class.path=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d \\ -J-Dtest.class.path.prefix=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d:/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -d /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d \\ -sourcepath /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -classpath /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip:/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d:/usr/share/jtreg/lib/testng.jar:/usr/share/jtreg/lib/guice.jar:/usr/share/jtreg/lib/jcommander.jar:/usr/share/jtreg/lib/slf4j-simple.jar:/usr/share/jtreg/lib/slf4j-api.jar /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java result: Passed. Compilation successful #section:testng ----------messages:(7/244)---------- command: testng CloseInflaterDeflaterTest reason: User specified action: run testng CloseInflaterDeflaterTest started: Mon Nov 24 15:12:07 GMT 2025 Mode: agentvm Agent id: 2 finished: Mon Nov 24 15:12:07 GMT 2025 elapsed time (seconds): 0.274 ----------configuration:(15/887)---------- Boot Layer class path: /usr/share/jtreg/lib/javatest.jar /usr/share/jtreg/lib/jtreg.jar /usr/share/jtreg/lib/junit-platform-console-standalone.jar /usr/share/jtreg/lib/testng.jar /usr/share/jtreg/lib/guice.jar /usr/share/jtreg/lib/jcommander.jar /usr/share/jtreg/lib/slf4j-simple.jar /usr/share/jtreg/lib/slf4j-api.jar patch: java.base /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/patches/java.base Test Layer class path: /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip ----------rerun:(25/3209)*---------- cd /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/scratch/0 && \\ HOME=/root \\ LC_ALL=C \\ PATH=/bin:/usr/bin:/usr/sbin \\ TEST_IMAGE_DIR=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/test \\ _JVM_DWARF_PATH=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/symbols \\ /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk/bin/java \\ -Dtest.vm.opts='-Xmx768m -XX:MaxRAMPercentage=1.5625 -Dtest.boot.jdk=/usr/lib/jvm/java-21-openjdk-s390x -Djava.io.tmpdir=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/tmp -ea -esa' \\ -Dtest.tool.vm.opts='-J-Xmx768m -J-XX:MaxRAMPercentage=1.5625 -J-Dtest.boot.jdk=/usr/lib/jvm/java-21-openjdk-s390x -J-Djava.io.tmpdir=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/tmp -J-ea -J-esa' \\ -Dtest.compiler.opts= \\ -Dtest.java.opts= \\ -Dtest.jdk=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk \\ -Dcompile.jdk=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/jdk \\ -Dtest.timeout.factor=4.0 \\ -Dtest.nativepath=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/images/test/jdk/jtreg/native \\ -Dtest.root=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk \\ -Dtest.name=java/util/zip/CloseInflaterDeflaterTest.java \\ -Dtest.file=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip/CloseInflaterDeflaterTest.java \\ -Dtest.src=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -Dtest.src.path=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -Dtest.classes=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d \\ -Dtest.class.path=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d \\ -Dtest.class.path.prefix=/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d:/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip \\ -classpath /home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/build/test-support/jtreg_test_jdk_java_util_zip_CloseInflaterDeflaterTest_java/classes/0/java/util/zip/CloseInflaterDeflaterTest.d:/home/eddy/src/bugs/new/openjdk-21-21.0.8+9~us1/test/jdk/java/util/zip:/usr/share/jtreg/lib/testng.jar:/usr/share/jtreg/lib/guice.jar:/usr/share/jtreg/lib/jcommander.jar:/usr/share/jtreg/lib/slf4j-simple.jar:/usr/share/jtreg/lib/slf4j-api.jar:/usr/share/jtreg/lib/javatest.jar:/usr/share/jtreg/lib/jtreg.jar \\ com.sun.javatest.regtest.agent.TestNGRunner java/util/zip/CloseInflaterDeflaterTest.java false CloseInflaterDeflaterTest ----------System.out:(224/15815)---------- config CloseInflaterDeflaterTest.before_test(): success test CloseInflaterDeflaterTest.testDeflaterInputStream(): success test CloseInflaterDeflaterTest.testDeflaterOutputStream(true): failure java.lang.AssertionError: Expected NullPointerException to be thrown, but IOException was thrown at org.testng.Assert.expectThrows(Assert.java:2205) at org.testng.Assert.assertThrows(Assert.java:2176) at CloseInflaterDeflaterTest.testDeflaterOutputStream(CloseInflaterDeflaterTest.java:153) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: java.io.IOException: write beyond end of stream at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:222) at CloseInflaterDeflaterTest.lambda$testDeflaterOutputStream$4(CloseInflaterDeflaterTest.java:153) at org.testng.Assert.expectThrows(Assert.java:2195) ... 30 more test CloseInflaterDeflaterTest.testDeflaterOutputStream(false): failure java.lang.AssertionError: Expected NullPointerException to be thrown, but IOException was thrown at org.testng.Assert.expectThrows(Assert.java:2205) at org.testng.Assert.assertThrows(Assert.java:2176) at CloseInflaterDeflaterTest.testDeflaterOutputStream(CloseInflaterDeflaterTest.java:153) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) Caused by: java.io.IOException: write beyond end of stream at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:222) at CloseInflaterDeflaterTest.lambda$testDeflaterOutputStream$4(CloseInflaterDeflaterTest.java:153) at org.testng.Assert.expectThrows(Assert.java:2195) ... 30 more test CloseInflaterDeflaterTest.testGZip(true): failure java.io.IOException at CloseInflaterDeflaterTest$1.write(CloseInflaterDeflaterTest.java:54) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:284) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:232) at java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148) at CloseInflaterDeflaterTest.testGZip(CloseInflaterDeflaterTest.java:121) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) test CloseInflaterDeflaterTest.testGZip(false): failure java.io.IOException at CloseInflaterDeflaterTest$1.write(CloseInflaterDeflaterTest.java:54) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:284) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:232) at java.base/java.util.zip.GZIPOutputStream.write(GZIPOutputStream.java:148) at CloseInflaterDeflaterTest.testGZip(CloseInflaterDeflaterTest.java:121) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) test CloseInflaterDeflaterTest.testZipCloseEntry(java.util.jar.JarOutputStream at 4cf87c35): failure java.io.IOException at CloseInflaterDeflaterTest$1.write(CloseInflaterDeflaterTest.java:54) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:284) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:232) at java.base/java.util.zip.ZipOutputStream.write(ZipOutputStream.java:361) at CloseInflaterDeflaterTest.testZipCloseEntry(CloseInflaterDeflaterTest.java:203) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) test CloseInflaterDeflaterTest.testZipCloseEntry(java.util.zip.ZipOutputStream at 765155f): failure java.io.IOException at CloseInflaterDeflaterTest$1.write(CloseInflaterDeflaterTest.java:54) at java.base/java.util.zip.DeflaterOutputStream.deflate(DeflaterOutputStream.java:284) at java.base/java.util.zip.DeflaterOutputStream.write(DeflaterOutputStream.java:232) at java.base/java.util.zip.ZipOutputStream.write(ZipOutputStream.java:361) at CloseInflaterDeflaterTest.testZipCloseEntry(CloseInflaterDeflaterTest.java:203) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at org.testng.internal.invokers.MethodInvocationHelper.invokeMethod(MethodInvocationHelper.java:136) at org.testng.internal.invokers.TestInvoker.invokeMethod(TestInvoker.java:658) at org.testng.internal.invokers.TestInvoker.invokeTestMethod(TestInvoker.java:219) at org.testng.internal.invokers.MethodRunner.runInSequence(MethodRunner.java:50) at org.testng.internal.invokers.TestInvoker$MethodInvocationAgent.invoke(TestInvoker.java:923) at org.testng.internal.invokers.TestInvoker.invokeTestMethods(TestInvoker.java:192) at org.testng.internal.invokers.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:146) at org.testng.internal.invokers.TestMethodWorker.run(TestMethodWorker.java:128) at java.base/java.util.ArrayList.forEach(ArrayList.java:1596) at org.testng.TestRunner.privateRun(TestRunner.java:808) at org.testng.TestRunner.run(TestRunner.java:603) at org.testng.SuiteRunner.runTest(SuiteRunner.java:429) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:423) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:383) at org.testng.SuiteRunner.run(SuiteRunner.java:326) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:95) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1249) at org.testng.TestNG.runSuitesLocally(TestNG.java:1169) at org.testng.TestNG.runSuites(TestNG.java:1092) at org.testng.TestNG.run(TestNG.java:1060) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:102) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) =============================================== java/util/zip/CloseInflaterDeflaterTest.java Total tests run: 7, Passes: 1, Failures: 6, Skips: 0 =============================================== ----------System.err:(10/529)---------- java.lang.Exception: failures: 6 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:104) at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103) at java.base/java.lang.reflect.Method.invoke(Method.java:580) at com.sun.javatest.regtest.agent.MainActionHelper$AgentVMRunnable.run(MainActionHelper.java:333) at java.base/java.lang.Thread.run(Thread.java:1583) JavaTest Message: Test threw exception: java.lang.Exception JavaTest Message: shutting down test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 6 test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 6 From vklang at openjdk.org Tue Dec 2 10:08:39 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 2 Dec 2025 10:08:39 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: <8tnePBnWu5w86zsXUOVMd7R_oHsTVl_Gjug0QP7N_vw=.5ce0106a-a7bf-40a2-b6a4-76e5d816150e@github.com> On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/MethodHandleImpl.java line 632: > 630: @Hidden > 631: @jdk.internal.vm.annotation.IntrinsicCandidate > 632: static int isCompileConstant(Object obj) { nit: an "is"-question tends to indicate a yes/no answer, but in this case it is more of a compileConstantStatus. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2580489368 From qamai at openjdk.org Tue Dec 2 10:36:42 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 2 Dec 2025 10:36:42 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" Message-ID: Hi, This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. Please kindly review, thanks a lot. ------------- Commit messages: - Set jvms()->_reexecute to false during Parse::catch_inline_exceptions Changes: https://git.openjdk.org/jdk/pull/28597/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28597&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350208 Stats: 153 lines in 3 files changed: 152 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28597.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28597/head:pull/28597 PR: https://git.openjdk.org/jdk/pull/28597 From vklang at openjdk.org Tue Dec 2 11:02:53 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 2 Dec 2025 11:02:53 GMT Subject: RFR: 8360046: Scalability issue when submitting virtual threads with almost empty tasks [v23] In-Reply-To: References: Message-ID: <0keGyslpp5RTqR3c1e3cCFcDT2cmhyf70RmyN1TloHo=.85ad8f7f-8f26-4c6e-a1eb-da63806b587d@github.com> On Sun, 30 Nov 2025 17:51:45 GMT, Doug Lea
wrote: >> This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. > > Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 35 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8360046 > - Cleanup > - For testing > - Merge branch 'openjdk:master' into JDK-8360046 > - restore positioning of threadlocal clears > - Add comment > - Merge branch 'openjdk:master' into JDK-8360046 > - Signal on setParallelism > - Drop added Contended region; simplify accordingly > - Tweaks > - ... and 25 more: https://git.openjdk.org/jdk/compare/05c38cfc...654c1dc6 Thanks for all your work here, @DougLea! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26479#pullrequestreview-3529497943 From dl at openjdk.org Tue Dec 2 12:09:18 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 2 Dec 2025 12:09:18 GMT Subject: Integrated: 8360046: Scalability issue when submitting virtual threads with almost empty tasks In-Reply-To: References: Message-ID: On Fri, 25 Jul 2025 12:21:43 GMT, Doug Lea
wrote: > This set of updates reduces contention-based performance loss under heavy over-subscription, while also improving perfomance more generally. This pull request has now been integrated. Changeset: fd7283be Author: Doug Lea
URL: https://git.openjdk.org/jdk/commit/fd7283be47489d3297aac6ecf6658ee9500b2891 Stats: 466 lines in 3 files changed: 136 ins; 124 del; 206 mod 8360046: Scalability issue when submitting virtual threads with almost empty tasks Reviewed-by: vklang ------------- PR: https://git.openjdk.org/jdk/pull/26479 From jpai at openjdk.org Tue Dec 2 12:16:41 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 12:16:41 GMT Subject: RFR: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed [v7] In-Reply-To: <560peA71rirY0JfDr0O942HLXQgYwW4MTivo8WGXKfw=.eec0142f-4757-4785-b734-e04ff5521e27@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> <560peA71rirY0JfDr0O942HLXQgYwW4MTivo8WGXKfw=.eec0142f-4757-4785-b734-e04ff5521e27@github.com> Message-ID: On Tue, 2 Dec 2025 06:58:51 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? >> >> The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. >> >> A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with three additional commits since the last revision: > > - return early if already closed() > - fix summary line > - even test for ModuleReader.list() on a closed ModuleReader Thank you Alan for the review and also for helping narrow down this issue. tier1, tier2 and tier3 testing passed with these changes. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28569#issuecomment-3601730520 From jpai at openjdk.org Tue Dec 2 12:21:03 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 12:21:03 GMT Subject: Integrated: 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed In-Reply-To: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> References: <72WXt4Ldm1clQNkBOtSpWthdxNyrGvNdB0vcCqwkgxg=.ee9f9fcd-58ca-4c0d-ad69-ba0b4bdfe138@github.com> Message-ID: On Mon, 1 Dec 2025 06:08:00 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8372787? > > The commit in this PR updates several methods in the `jdk.internal.module.ModulePatcher$PatchedModuleReader` to throw an `IOException` if the `ModuleReader` has been closed. This updated implementation now matches the specification of the corresponding methods in `ModuleReader`. > > A new jtreg test has been introduced to reproduce the issue and verify the fix. CI testing is currently in progress with this change. This pull request has now been integrated. Changeset: 07856fce Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/07856fce34ba14a83fc1ac0faffe3b5ba883e0b5 Stats: 155 lines in 3 files changed: 151 ins; 2 del; 2 mod 8372787: ModuleReader should throw IOException consistently when using --patch-module and ModuleReader is closed Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/28569 From alanb at openjdk.org Tue Dec 2 13:04:57 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 13:04:57 GMT Subject: RFR: 8367938: Test Serialization Compatibility of Class Objects In-Reply-To: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> References: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> Message-ID: On Mon, 1 Dec 2025 20:30:30 GMT, Roger Riggs wrote: > ArchivedClassesTest is added to compare archived serialized class objects against current classes. > Note: these are the serialized class objects themselves, for example `java.lang.String.class`, not instances of the class, for example "Hello". > The archived classes reference was built against the latest released version: 25.0.1+8. > > The test fails if the serialized class reference archive is missing from the repository > or if there are any incompatible changes to the serialized bytes. > Normal output from the test includes: > - The version of the serialized class archive > - Listing (if any) of incompatible classes > - Listing of classes with compatible changes > - Listing of classes in the archive that are not in the current version > - Listing of classes in the current version not found in the archive > > The change of java.nio.ByteOrder from a class to enum is reported as an approved incompatible change. test/jdk/java/io/Serializable/ClassSerialization/ArchivedClassesTest.java line 476: > 474: * @return Stream of matching classes > 475: */ > 476: public static Stream> findAll() { Does this test have to be limited to the standard modules? I would think it should find all classes in packages that are exported unconditionally (to all modules). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28586#discussion_r2581080077 From alanb at openjdk.org Tue Dec 2 13:09:20 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 13:09:20 GMT Subject: RFR: 8367938: Test Serialization Compatibility of Class Objects In-Reply-To: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> References: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> Message-ID: On Mon, 1 Dec 2025 20:30:30 GMT, Roger Riggs wrote: > ArchivedClassesTest is added to compare archived serialized class objects against current classes. > Note: these are the serialized class objects themselves, for example `java.lang.String.class`, not instances of the class, for example "Hello". > The archived classes reference was built against the latest released version: 25.0.1+8. > > The test fails if the serialized class reference archive is missing from the repository > or if there are any incompatible changes to the serialized bytes. > Normal output from the test includes: > - The version of the serialized class archive > - Listing (if any) of incompatible classes > - Listing of classes with compatible changes > - Listing of classes in the archive that are not in the current version > - Listing of classes in the current version not found in the archive > > The change of java.nio.ByteOrder from a class to enum is reported as an approved incompatible change. test/jdk/java/io/Serializable/ClassSerialization/ArchivedClasses.txt line 4: > 2: # Version: 25.0.1+8-LTS-27 > 3: # Classes: 2620 > 4: # Module java.base I'm in two minds on the maintainability of having this file checked into the repo. As to where a golden file (or files) might live then maybe test/jdk/tools/sincechecker sets some precedence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28586#discussion_r2581099309 From duke at openjdk.org Tue Dec 2 13:10:09 2025 From: duke at openjdk.org (Igor Rudenko) Date: Tue, 2 Dec 2025 13:10:09 GMT Subject: RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v11] In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> Message-ID: <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> > Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: > - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases > - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision: Improvements according to reviewer's advices ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28124/files - new: https://git.openjdk.org/jdk/pull/28124/files/57b94806..6a896183 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28124&range=09-10 Stats: 16 lines in 1 file changed: 10 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28124/head:pull/28124 PR: https://git.openjdk.org/jdk/pull/28124 From msheppar at openjdk.org Tue Dec 2 13:32:21 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 2 Dec 2025 13:32:21 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 07:43:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. looks like a good cleanup of the test, adding the try with resources and the thread join is good job LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28595#pullrequestreview-3530143038 From thomas.stuefe at gmail.com Tue Dec 2 14:11:01 2025 From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=) Date: Tue, 2 Dec 2025 15:11:01 +0100 Subject: state of openjdk-zlib on s390x In-Reply-To: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com> References: <7c022649373db9fbfc4a8d2426316429d76c9d61.camel@linux.ibm.com> Message-ID: Hi Eddy, Thank you for the investigation and the informative mail. Just to clarify: There is no functional problem in that the archives could be invalid, unreadable, or not standard-conform? The problem would be reproducibility and failing tests that you argue are too strict? Reproducibility is obviously a problem for vendors doing reproducible builds. That could be helped with a switch. Other than that, I am not sure. I could imagine theoretical problems with database applications when compressed artifacts change unexpectedly given the same input, but nothing concrete comes to mind. Thanks, Thomas On Tue, Nov 4, 2025 at 8:49?AM Eduard Stefes wrote: > Hello, > > # TLDR > > zlib (and zlib-ng) on s390x use hardware compression. This > hardware compression implementation has currently some problems when > used by openjdk. > > > > # current situation > > - openjdk uses zlib(or zlib-ng) for most(all?) its data compression. > This includes also jar file creation. > - s390x has deflate implemented on hardware level(called dfltcc). This > implementation is up to 10x faster(empirical value) compared to the > standard software algorithm. > - The dfltcc implementation has some drawbacks vs the software > implementation: > - dfltcc will ALWAYS write to the output buffer, indifferent > of the flushing parameter passed to deflate() > - dfltcc does not generate reproducible output. This means > that it will always generate valid deflate data streams > that uncompress(inflate) to the same input. But the > compressed data may look different between two calls with > the same input data, because the hardware compressor depends > also on hardware variables that not visible to the external > api user. > > > > > # the problem > > due to the differences of the hardware implementation, some tests in > the openjdk JREG tests fail(tracked here[1][2]) > > - java/util/zip/CloseInflaterDeflaterTest.java > fails due to dfltcc's flushing behaviour. The test should check if > the openjdk wrapper around the jni and native library will > successfully detect writes to closed output streams. This was > created because there where bugs with and race conditions in the > write/close/flush. > > - tools/jlink/JLinkReproducibleTest.java: > - tools/jar/modularJar/JarToolModuleDescriptorReproducibilityTest.java: > This tests fail due to two calls to dfltcc will not generate the > same compressed data for the same input data. I want to > emphasize that RFC 1950 and 1951 do not guarantee the same output > for two deflate/zlib data streams if feed the same input data. > > > # proposed solutions > ## flushing problem > > IMHO the CloseInflaterDeflaterTest.java test relays on zlib behavior > where zlib explicitly has the freedom to change its behavior[3][1]. > As a quick and dirty solution i would propose to backport the > disablement[4] of this test to openjdk-17 21 and 24. > > I read and traced through the test, and for me it looks like the > behavior of the openjdk and jni wrappers will be the same regardless of > the underlying zlib. Therefor it seems ok to assume that: "If its okay > on x86 it will be ok on s390x" > > However I think that this test might need a redesign. It relies on > flushing behavior of zlib the the library explicitly stated can change. > > > > ## reproducible compression > > I don't know how much openjdk relies on reproducible data compression. > I assume it is preferable if its possible to create the same .jar twice > and get the same binary data. The zlib dfltcc implementation could be > controlled via an env variable to disable the hardware compression[5]. > Also usually dftcc will only be used for certain compression levels and > this can also be changed via env variables[6]. > > Unfortunately this env variables are evaluated at library load and can > not be adjusted during runtime. > > Moreover ubuntu sets the default LEVEL_MASK to 0x7e[7]. This means > that the compression level is also not a reliabl method in order to > force zlib to use software instead of hardware compression. > > Also zlib-ng lacks this env variables. Here the use of dfltcc cannot be > influenced at all. > > This all leads me to the conclusion that there has to be a decision if > and how openjdk on s390x will be able to generate reproducible jars. > For the time being I suppose to also disable this tests and backport > the disablements down till openjdk-17. > > > > # Finally > > I hope i did not overwhelm you all with this email. As I don't have a > bugs.openjdk.org account, I thought the mailing list is the best place > to discuss this mater. > > cheers Eddy > > > > [1] https://bugs.launchpad.net/ubuntu/+source/openjdk-21/+bug/2109016 > [2] https://bugs.openjdk.org/browse/JDK-8339216 > [3] https://github.com/madler/zlib/blob/develop/zlib.h#L286-L288 > [4] > > https://github.com/openjdk/jdk/commit/537447f8816129dad9a1edd21bd30f3edf69ea60 > [5] > https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L705-L706 > [6] > https://github.com/iii-i/zlib/blob/dfltcc/contrib/s390/dfltcc.c#L714-L715 > [7] https://git.launchpad.net/ubuntu/+source/zlib/tree/debian/rules#n53 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Tue Dec 2 14:23:57 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 14:23:57 GMT Subject: RFR: 8372939: Update JDK 26 spec URLs Message-ID: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com> Updating the JDK 26 JLS and JVMS links ------------- Commit messages: - update jdk 26 spec links Changes: https://git.openjdk.org/jdk/pull/28605/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28605&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372939 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28605.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28605/head:pull/28605 PR: https://git.openjdk.org/jdk/pull/28605 From jvernee at openjdk.org Tue Dec 2 14:55:59 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 2 Dec 2025 14:55:59 GMT Subject: RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v11] In-Reply-To: <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> Message-ID: On Tue, 2 Dec 2025 13:10:09 GMT, Igor Rudenko wrote: >> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: >> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases >> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach > > Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision: > > Improvements according to reviewer's advices Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28124#pullrequestreview-3530558824 From nbenalla at openjdk.org Tue Dec 2 14:57:43 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 14:57:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v8] In-Reply-To: References: Message-ID: <8Fxjqxz7uHKELjvLEjJg4Zvkbs38Bz52UcbJJYkkN4I=.09b0c42a-4b86-4ba9-9a31-d0a7b60af3fe@github.com> > Get JDK 27 underway. Nizar Benalla 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 18 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - revert MAX_COLUMNS to 80 - Update LATEST_MAJOR_VERSION in Versions.java - Merge branch 'master' into start-of-release-27 - ... and 8 more: https://git.openjdk.org/jdk/compare/759d7098...b47b9ee9 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/e5214614..b47b9ee9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=06-07 Stats: 7726 lines in 83 files changed: 2728 ins; 4423 del; 575 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Dec 2 15:07:11 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 15:07:11 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: References: Message-ID: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - revert changes to avoid conflict - add 27 to the acceptable boot versions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/b47b9ee9..1237304b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=07-08 Stats: 49 lines in 4 files changed: 8 ins; 29 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Tue Dec 2 15:07:16 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 15:07:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 22:20:34 GMT, Erik Joelsson wrote: >> Nizar Benalla 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 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/8736a894...e5214614 > > make/conf/version-numbers.conf line 40: > >> 38: DEFAULT_VERSION_CLASSFILE_MINOR=0 >> 39: DEFAULT_VERSION_DOCS_API_SINCE=11 >> 40: DEFAULT_ACCEPTABLE_BOOT_VERSIONS="25 26" > > Need to add 27 to this line. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/061986c2fa56bcf1411f479c5b76602f63dc93c3, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2581577462 From henryjen at openjdk.org Tue Dec 2 15:39:07 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Dec 2025 15:39:07 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> Message-ID: On Fri, 21 Nov 2025 15:39:12 GMT, Severin Gehwolf wrote: >> It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break. >> >> Overall I think the changes are looking good, the main thing is that the error message is clear. > >> It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break. > > Writhing the manifest entries for `jrt-fs.jar` break (header validation fails). Since the vendor populates to that jar file. The CSR is approved, and the one line signature is in the text. And since other things break with newline in the vendor name, I assume that vendor name is also limited, so are we good with current implementation? If it helps, I can add code to ensure compare the whole file. Or are we suggesting to add error message when there is more than one line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2581726793 From ogillespie at openjdk.org Tue Dec 2 15:39:27 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 2 Dec 2025 15:39:27 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive Message-ID: `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough. `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure. This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`. Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries. Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`): class java.util.TreeMap$KeySet .stream().limit(1).count() took 0.046ms spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView .stream().limit(1).count() took 218ms spliterator = IteratorSpliterator, estimateSize() = 9999999 After (entrySet is now fast, using `SubMapEntryIterator`): class java.util.TreeMap$KeySet .stream().limit(1).count() took 0.017ms spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView .stream().limit(1).count() took 0.013ms spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807 ------------- Commit messages: - Attempt to fix 8372946 Changes: https://git.openjdk.org/jdk/pull/28608/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372946 Stats: 70 lines in 1 file changed: 68 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608 PR: https://git.openjdk.org/jdk/pull/28608 From duke at openjdk.org Tue Dec 2 15:40:49 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Dec 2025 15:40:49 GMT Subject: Withdrawn: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction In-Reply-To: References: Message-ID: On Tue, 18 Mar 2025 20:51:46 GMT, Jatin Bhateja wrote: > Patch optimizes Vector. slice operation with constant index using x86 ALIGNR instruction. > It also adds a new hybrid call generator to facilitate lazy intrinsification or else perform procedural inlining to prevent call overhead and boxing penalties in case the fallback implementation expects to operate over vectors. The existing vector API-based slice implementation is now the fallback code that gets inlined in case intrinsification fails. > > Idea here is to add infrastructure support to enable intrinsification of fast path for selected vector APIs, else enable inlining of fall-back implementation if it's based on vector APIs. Existing call generators like PredictedCallGenerator, used to handle bi-morphic inlining, already make use of multiple call generators to handle hit/miss scenarios for a particular receiver type. The newly added hybrid call generator is lazy and called during incremental inlining optimization. It also relieves the inline expander to handle slow paths, which can easily be implemented library side (Java). > > Vector API jtreg tests pass at AVX level 2, remaining validation in progress. > > Performance numbers: > > > System : 13th Gen Intel(R) Core(TM) i3-1315U > > Baseline: > Benchmark (size) Mode Cnt Score Error Units > VectorSliceBenchmark.byteVectorSliceWithConstantIndex1 1024 thrpt 2 9444.444 ops/ms > VectorSliceBenchmark.byteVectorSliceWithConstantIndex2 1024 thrpt 2 10009.319 ops/ms > VectorSliceBenchmark.byteVectorSliceWithVariableIndex 1024 thrpt 2 9081.926 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex1 1024 thrpt 2 6085.825 ops/ms > VectorSliceBenchmark.intVectorSliceWithConstantIndex2 1024 thrpt 2 6505.378 ops/ms > VectorSliceBenchmark.intVectorSliceWithVariableIndex 1024 thrpt 2 6204.489 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex1 1024 thrpt 2 1651.334 ops/ms > VectorSliceBenchmark.longVectorSliceWithConstantIndex2 1024 thrpt 2 1642.784 ops/ms > VectorSliceBenchmark.longVectorSliceWithVariableIndex 1024 thrpt 2 1474.808 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex1 1024 thrpt 2 10399.394 ops/ms > VectorSliceBenchmark.shortVectorSliceWithConstantIndex2 1024 thrpt 2 10502.894 ops/ms > VectorSliceBenchmark.shortVectorSliceWithVariableIndex 1024 ... This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/24104 From jpai at openjdk.org Tue Dec 2 15:50:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 15:50:51 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile Message-ID: Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. ------------- Commit messages: - 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile Changes: https://git.openjdk.org/jdk/pull/28609/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28609&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366101 Stats: 38 lines in 1 file changed: 16 ins; 13 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28609/head:pull/28609 PR: https://git.openjdk.org/jdk/pull/28609 From vklang at openjdk.org Tue Dec 2 16:03:34 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 2 Dec 2025 16:03:34 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v3] In-Reply-To: <7J-z_iy59MbtjbxIAgZGXb5O3oMxOz9uPLoRORjZ8ho=.5d949768-e179-4be9-9dfe-226eda885e91@github.com> References: <7J-z_iy59MbtjbxIAgZGXb5O3oMxOz9uPLoRORjZ8ho=.5d949768-e179-4be9-9dfe-226eda885e91@github.com> Message-ID: On Tue, 2 Dec 2025 09:09:35 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Add unit test test/jdk/java/util/EnumSet/EnumSetSpliteratorTest.java line 79: > 77: assertTrue(spliterator.hasCharacteristics(Spliterator.SORTED), "Missing SORTED"); > 78: assertTrue(spliterator.hasCharacteristics(Spliterator.ORDERED), "Missing ORDERED"); > 79: assertTrue(spliterator.hasCharacteristics(Spliterator.NONNULL), "Missing NONNULL"); Thanks for adding the test. I think it makes sense to check the `enumSet.spliterator().characteristics()` being exactly `DISTINCT | SORTED | ORDERED | NONNULL` (since this test otherwise would still pass if further characteristics are added). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28568#discussion_r2581832277 From liach at openjdk.org Tue Dec 2 16:06:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 16:06:55 GMT Subject: RFR: 8372939: Update JDK 26 spec URLs In-Reply-To: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com> References: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com> Message-ID: On Tue, 2 Dec 2025 14:05:33 GMT, Nizar Benalla wrote: > Updating the JDK 26 JLS and JVMS links Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28605#pullrequestreview-3530947007 From henryjen at openjdk.org Tue Dec 2 16:11:02 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Dec 2025 16:11:02 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v9] In-Reply-To: References: Message-ID: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: - Merge openjdk/master - adapt review feedbacks - remove the extra space - Update the error message when not finding release signature - Treat missing release.txt as emptry release signature - Refactoring to clarify version checking cases - Address review feedbacks - Use release.txt from java.base module in current and target for comparison - JLink to check java build information - Build changes to generate release.txt for java.base and jdk.jlink. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28155/files - new: https://git.openjdk.org/jdk/pull/28155/files/a3edf9ac..2641504b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28155&range=07-08 Stats: 257641 lines in 2281 files changed: 172190 ins; 47655 del; 37796 mod Patch: https://git.openjdk.org/jdk/pull/28155.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28155/head:pull/28155 PR: https://git.openjdk.org/jdk/pull/28155 From alanb at openjdk.org Tue Dec 2 16:19:22 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 16:19:22 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v8] In-Reply-To: References: <4uJhQdFQQB6PBMzwbQAOry2qOwZVDQtQxsABgUzcZq8=.89dc80a2-86c7-4602-b0ff-81bb5832f121@github.com> <5LkTJ4u01K0fIFPRkCi-myrfMJ7xNZatsSs4Ig2H-dE=.dc2a9653-7c8b-45dc-8de3-2b08563df781@github.com> Message-ID: On Tue, 2 Dec 2025 15:36:46 GMT, Henry Jen wrote: >>> It might be useful to see what breaks if a JDK were built with a newline in the vendor name, I assume other things will break. >> >> Writhing the manifest entries for `jrt-fs.jar` break (header validation fails). Since the vendor populates to that jar file. > > The CSR is approved, and the one line signature is in the text. > And since other things break with newline in the vendor name, I assume that vendor name is also limited, so are we good with current implementation? > Are we suggesting to add error message when there is more than one line? I think current implementation is fine. I don't think we need to be concerned with this right now. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28155#discussion_r2581908452 From alanb at openjdk.org Tue Dec 2 16:23:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 16:23:51 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v9] In-Reply-To: References: Message-ID: <5Z5h1NVJGWQq6HuAc1PVd0c7Vgqqd4Wgv8IYk8LFPKU=.a86cec44-774b-42ed-8683-f179d6ac2f20@github.com> On Tue, 2 Dec 2025 16:11:02 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge openjdk/master > - adapt review feedbacks > - remove the extra space > - Update the error message when not finding release signature > - Treat missing release.txt as emptry release signature > - Refactoring to clarify version checking cases > - Address review feedbacks > - Use release.txt from java.base module in current and target for comparison > - JLink to check java build information > - Build changes to generate release.txt for java.base and jdk.jlink. Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3531039627 From alanb at openjdk.org Tue Dec 2 16:23:53 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 16:23:53 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v5] In-Reply-To: References: Message-ID: On Tue, 11 Nov 2025 17:56:18 GMT, Severin Gehwolf wrote: > I think this can be tested akin to `JLinkOptionsTest` by implementing a simple plugin that transforms the `release.txt` resource and uses `--keep-packaged-modules` and then attempts to perform a link on the resulting image. Similarly we could cover the case of `release.txt` missing by using the `--exclude-resources` plugin. Maybe we should have a follow-up issue to attempt to create a test for this. However, the bigger topic of testing the cross-linking scenario isn't really something we can do in a jtreg test. Instead it is something for "special testing", like the manual tests, as it needs builds from different platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3602889964 From ogillespie at openjdk.org Tue Dec 2 16:34:06 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 2 Dec 2025 16:34:06 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 15:31:43 GMT, Oli Gillespie wrote: > `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough. > > `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure. > > This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`. > > > Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries. > > Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`): > > class java.util.TreeMap$KeySet > .stream().limit(1).count() took 0.046ms > spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 > class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView > .stream().limit(1).count() took 218ms > spliterator = IteratorSpliterator, estimateSize() = 9999999 > > > After (entrySet is now fast, using `SubMapEntryIterator`): > > class java.util.TreeMap$KeySet > .stream().limit(1).count() took 0.017ms > spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 > class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView > .stream().limit(1).count() took 0.013ms > spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807 Tier2 test failure. I will investigate. java.util.ConcurrentModificationException at java.base/java.util.TreeMap$NavigableSubMap$SubMapIterator.prevEntry(TreeMap.java:2068) at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.next(TreeMap.java:2156) at java.base/java.util.TreeMap$NavigableSubMap$DescendingSubMapEntryIterator.forEachRemaining(TreeMap.java:2166) at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570) at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560) at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:635) at java.base/java.util.stream.AbstractPipeline.evaluateToArrayNode(AbstractPipeline.java:291) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:652) at java.base/java.util.stream.ReferencePipeline.toArray(ReferencePipeline.java:658) at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testEntrySetSizeRemove(CollectionAndMapModifyStreamTest.java:164) at org.openjdk.tests.java.util.stream.CollectionAndMapModifyStreamTest.testMapEntriesSizeRemove(CollectionAndMapModifyStreamTest.java:155) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28608#issuecomment-3602932282 From alanb at openjdk.org Tue Dec 2 16:37:02 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 16:37:02 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 15:44:26 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. > > The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. > > No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. src/java.base/share/classes/java/util/jar/JarFile.java line 1043: > 1041: // the JAR verifier > 1042: ScopedValue.where(IN_VERIFIER_INIT, true).call( > 1043: new ScopedValue.CallableOp() { ScopedValue.Carrier defines a run method so you could use `ScopedValue.where(IN_VERIFIER_INIT, true).run(..)` here and avoid the exception handling. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2581980625 From jpai at openjdk.org Tue Dec 2 16:56:18 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 16:56:18 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. > > The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. > > No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: use Runnable() instead of CallableOp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28609/files - new: https://git.openjdk.org/jdk/pull/28609/files/6bd7fa84..79539802 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28609&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28609&range=00-01 Stats: 16 lines in 1 file changed: 0 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28609.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28609/head:pull/28609 PR: https://git.openjdk.org/jdk/pull/28609 From jpai at openjdk.org Tue Dec 2 16:56:20 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 2 Dec 2025 16:56:20 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:34:00 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use Runnable() instead of CallableOp > > src/java.base/share/classes/java/util/jar/JarFile.java line 1043: > >> 1041: // the JAR verifier >> 1042: ScopedValue.where(IN_VERIFIER_INIT, true).call( >> 1043: new ScopedValue.CallableOp() { > > ScopedValue.Carrier defines a run method so you could use `ScopedValue.where(IN_VERIFIER_INIT, true).run(..)` here and avoid the exception handling. I hadn't spotted that API, much cleaner indeed. I've updated the PR with that change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582048687 From ogillespie at openjdk.org Tue Dec 2 17:00:54 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 2 Dec 2025 17:00:54 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: References: Message-ID: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> > `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough. > > `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure. > > This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`. > > > Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries. > > Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`): > > class java.util.TreeMap$KeySet > .stream().limit(1).count() took 0.046ms > spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 > class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView > .stream().limit(1).count() took 218ms > spliterator = IteratorSpliterator, estimateSize() = 9999999 > > > After (entrySet is now fast, using `SubMapEntryIterator`): > > class java.util.TreeMap$KeySet > .stream().limit(1).count() took 0.017ms > spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 > class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView > .stream().limit(1).count() took 0.013ms > spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807 Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: Fix failing test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28608/files - new: https://git.openjdk.org/jdk/pull/28608/files/7c7299c1..9e669145 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28608&range=00-01 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28608.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28608/head:pull/28608 PR: https://git.openjdk.org/jdk/pull/28608 From ogillespie at openjdk.org Tue Dec 2 17:09:26 2025 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 2 Dec 2025 17:09:26 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> References: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> Message-ID: On Tue, 2 Dec 2025 17:00:54 GMT, Oli Gillespie wrote: >> `TreeMap` sub-maps use the default `IteratorSpliterator` implementation for `TreeMap$EntrySetView` which is slow for some operations, because `EntrySetView.size()` iterates all elements. This is most trivially shown by something like `largeTreeMap.tailMap(0L, false).entrySet().limit(1).count()` taking a long time. This showed up in my application, where it was trivial to mitigate by switching to a for loop, but I think the fix is easy enough. >> >> `keySet()` does not have the same problem, as it provides a custom `Spliterator` implementation which is not `Spliterator.SIZED`, and returns `Long.MAX_VALUE` for `estimateSize()` (which is the recommended approach when the size is expensive to compute). I'm *assuming* this optimization was simply missed for the EntryIterator in the original implementation, but I don't know for sure. >> >> This patch fixes the issue by providing a custom spliterator for `EntrySetView`, which is not SIZED. The implementation is copied almost exactly from the equivalent `KeyIterator` classes in this file (`SubMapKeyIterator`, `DescendingSubMapKeyIterator`). The only difference is in `SubMapEntryIterator.getComparator`, for which I copied the implementation from `TreeMap$EntrySpliterator`. >> >> >> Basic performance test: `map.tailMap(0L, false).entrySet().stream().limit(1).count()` for a `TreeMap` with `10_000_000` entries. >> >> Before (keySet is fast using `SubMapKeyIterator`, entrySet is slow using `IteratorSpliterator`): >> >> class java.util.TreeMap$KeySet >> .stream().limit(1).count() took 0.046ms >> spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 >> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView >> .stream().limit(1).count() took 218ms >> spliterator = IteratorSpliterator, estimateSize() = 9999999 >> >> >> After (entrySet is now fast, using `SubMapEntryIterator`): >> >> class java.util.TreeMap$KeySet >> .stream().limit(1).count() took 0.017ms >> spliterator = SubMapKeyIterator, estimateSize() = 9223372036854775807 >> class java.util.TreeMap$AscendingSubMap$AscendingEntrySetView >> .stream().limit(1).count() took 0.013ms >> spliterator = SubMapEntryIterator, estimateSize() = 9223372036854775807 > > Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: > > Fix failing test Fixed the test failure by skipping that case. The test intentionally modifies the backing map while holding an iterator, which is not safe in general. It got away with it before, but the new implementation reasonably throws CME. The test only runs on EntrySets, but the equivalent test would already fail on the current `map.tailMap(...).keySet()` implementation, so I _think_ it's expected and reasonable that it now fails for `descendingMap.entrySet()`. Appreciate any second opinions, though. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28608#issuecomment-3603104114 From naoto at openjdk.org Tue Dec 2 17:11:28 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 17:11:28 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: <87s2FYP5JFd3oKQOjsVn6K7PDZd6v_1YGsu4qKVYLxE=.5896d4e7-057d-4c3c-8952-ae96ff43bbf9@github.com> References: <87s2FYP5JFd3oKQOjsVn6K7PDZd6v_1YGsu4qKVYLxE=.5896d4e7-057d-4c3c-8952-ae96ff43bbf9@github.com> Message-ID: On Tue, 2 Dec 2025 03:48:22 GMT, Brian Burkhalter wrote: >> Yes, that was what I meant. I thought the more information, the better for debugging. But if it won't provide any useful info, I am fine with the current version. > >> [...] if it won't provide any useful info, I am fine with the current version. > > Re-throwing the caught exception should provide the stack trace, right? Printing to err or re-throwing, I am fine either way. Just wanted to retrieve all the debug info to the user ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2582114049 From liach at openjdk.org Tue Dec 2 17:16:38 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 17:16:38 GMT Subject: RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v11] In-Reply-To: <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> Message-ID: On Tue, 2 Dec 2025 13:10:09 GMT, Igor Rudenko wrote: >> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: >> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases >> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach > > Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision: > > Improvements according to reviewer's advices Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28124#pullrequestreview-3531290809 From liach at openjdk.org Tue Dec 2 17:27:43 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 17:27:43 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 09:28:03 GMT, Per Minborg wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak VH usage in some classes > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > >> 2034: var constant = MethodHandleImpl.isCompileConstant(vh); >> 2035: var cache = adaptedMh; >> 2036: if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) { > > Rookie question: Is there multi-thread considerations here? How about visibility across threads? MethodHandle is immutable and can be safely published. So this is ok. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582166754 From bpb at openjdk.org Tue Dec 2 17:29:49 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 2 Dec 2025 17:29:49 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: <9klOjrVQSljTPeaM558V8YV1uGEBA_-Hpzau0A89Rek=.7e6d001e-65d0-4513-b6d7-b9f34d3f192c@github.com> On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. The modified test passed on the usual platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28592#issuecomment-3603184679 From mcimadamore at openjdk.org Tue Dec 2 17:35:00 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 2 Dec 2025 17:35:00 GMT Subject: RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v11] In-Reply-To: <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> Message-ID: On Tue, 2 Dec 2025 13:10:09 GMT, Igor Rudenko wrote: >> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: >> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases >> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach > > Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision: > > Improvements according to reviewer's advices I like the new approach! src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 421: > 419: @ForceInline > 420: private void checkBounds(long offset, long length) { > 421: if (length > 0) { Note: if we know we're not coming from a slice operation, we can just drop the if... so I wonder if we could split the impl in two to remove extra branches in the access case? ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28124#pullrequestreview-3531359065 PR Review Comment: https://git.openjdk.org/jdk/pull/28124#discussion_r2582188436 From naoto at openjdk.org Tue Dec 2 17:36:59 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 17:36:59 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: <1Hd48ax73IYcDVSDf8JRlSu4ai8JUmK62_2ugHX-Jgs=.4ee6fce2-b66b-4a74-8507-88cae25cbd87@github.com> On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. Looks good ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28592#pullrequestreview-3531365863 From mcimadamore at openjdk.org Tue Dec 2 17:54:15 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Tue, 2 Dec 2025 17:54:15 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: <5CMXCgWmWnuATMxROM1zVobe9dv-6FrwCN7hJHfC8dc=.e153adc5-f91f-4fba-9ffe-eced1ab9cac6@github.com> On Mon, 1 Dec 2025 19:03:50 GMT, Stuart Monteith wrote: > That was my mistake - I expected that with the foreign ABI being merged, discussions on internals would have reverted to here. In general they are -- but I find that one issue with PRs is that they tend to be very code-centric, whereas in some cases it might be useful to discuss design options more abstractly and _then_ converge towards an implementation. And doing design discussions via PR is suboptimal. But, you did right in bringing this up! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3603277207 From sherman at openjdk.org Tue Dec 2 18:05:52 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 2 Dec 2025 18:05:52 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Mon, 1 Dec 2025 23:03:17 GMT, Naoto Sato wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> minor doc formatting update > > make/jdk/src/classes/build/tools/generatecharacter/GenerateCaseFolding.java line 79: > >> 77: // hack, hack, hack! the logic does not pick 0131. just add manually to support 'I's. >> 78: // 0049; T; 0131; # LATIN CAPITAL LETTER I >> 79: final String T_0x0131_0x49 = String.format(" entry(0x%04x, 0x%04x),\n", 0x0131, 0x49); > > The 'T' status reads (in CaseFolding.txt): > > # T: special case for uppercase I and dotted uppercase I > # - For non-Turkic languages, this mapping is normally not used. > # - For Turkic languages (tr, az), this mapping can be used instead of the normal mapping for these characters. > # Note that the Turkic mappings do not maintain canonical equivalence without additional processing. > > Since this casefold feature is locale independent, should this `T` status be ignored? It might be helpful if we mention in the spec if we do this `T` case folding. T_0x0131_0x49 is for the table Expanded_Case_Map_Entries, which is used for the regex only. See: https://openjdk.github.io/cr/?repo=jdk&pr=26285&range=05#new-1-make/jdk/src/classes/build/tools/generatecharacter/CaseFolding.java The casefolding mapping for regex uses CTS, to match the existing behavior. We may want to do something later to "consolidate" the spec and implementation , but it's not within the scope of this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582279595 From erikj at openjdk.org Tue Dec 2 18:10:00 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 2 Dec 2025 18:10:00 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Build changes look good. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3531491706 From sgehwolf at openjdk.org Tue Dec 2 18:15:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 2 Dec 2025 18:15:04 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v5] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:20:49 GMT, Alan Bateman wrote: > > I think this can be tested akin to `JLinkOptionsTest` by implementing a simple plugin that transforms the `release.txt` resource and uses `--keep-packaged-modules` and then attempts to perform a link on the resulting image. Similarly we could cover the case of `release.txt` missing by using the `--exclude-resources` plugin. > > Maybe we should have a follow-up issue to attempt to create a test for this. That's OK with me. Creating jtreg tests verifying that it fails if the file doesn't match/does not exist can still be done. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28155#issuecomment-3603351075 From smarks at openjdk.org Tue Dec 2 18:16:02 2025 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 2 Dec 2025 18:16:02 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test In-Reply-To: References: Message-ID: <9ob7OWkAVDKCGqHOaRuJoPQrG6a33F3ZijMMlNXZc-k=.00909ed9-9332-4b9a-b5cd-012d326e28c9@github.com> On Tue, 2 Dec 2025 07:43:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. Marked as reviewed by smarks (Reviewer). Overall, good cleanup. A couple bits of history. The RMI tests are replete with these kind of ad-hoc timeouts. We've gotten rid of a lot of them over the years, but some of these are still lurking around, such as in this test. It's good to continue to remove them. One of the reasons this sort of stuff was probably added to individual tests was to facilitate running the tests standalone, that is, outsid the jtreg environment. Thus many tests didn't rely on jtreg to handle timeouts. I think we've moved away from this a long time ago. The priority needs to be reliability of tests run in CI systems, which happens many, many times every day. It's still possible, though somewhat inconvenient, to invoke a single test manually via jtreg, but I think this is the way it should be. I'd suggest renaming the `failure` field and the local variable into which its value is loaded after the thread is joined. The difficulty with "failure" is that it's ambiguous whether it means the _export_ has failed or that the _test_ has failed. (It means the former.) The field is expected to contain an ExportException, so something that suggests that would be preferable. ------------- PR Review: https://git.openjdk.org/jdk/pull/28595#pullrequestreview-3531522499 PR Comment: https://git.openjdk.org/jdk/pull/28595#issuecomment-3603353163 From kustos at gmx.net Tue Dec 2 18:23:40 2025 From: kustos at gmx.net (Philippe Marschall) Date: Tue, 2 Dec 2025 19:23:40 +0100 Subject: VarHandle get* and set* methods lack throws IndexOutOfBoundsException documentation Message-ID: <33e9512f-682f-4ed5-bb58-8cbb19e645dd@gmx.net> Hello The VarHandle #get* and #set* methods currently document the following three possible exceptions in their Javadoc - ClassCastException - WrongMethodTypeException - UnsupportedOperationException, only for #set* However, when a VarHandle was created using MethodHandles#byteArrayViewVarHandle or MethodHandles#byteBufferViewVarHandle and the index, the second argument, is incorrect then an IndexOutOfBoundsException is thrown. At some point between JDK 11 and JDK 17 a #byteArrayViewVarHandle was changed so that ArrayIndexOutOfBoundsException is thrown. The following code is an example: VarHandle LONG_BA_BE = MethodHandles.byteArrayViewVarHandle(long[].class, ByteOrder.BIG_ENDIAN); byte[] array = new byte[] {8, 7, 6, 5, 4, 3, 2, 1}; long l = (long) LONG_BA_BE.get(array, -1); System.out.println(l); Cheers Philippe From jlu at openjdk.org Tue Dec 2 18:25:09 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Dec 2025 18:25:09 GMT Subject: RFR: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 Message-ID: Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/28612/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28612&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8362428 Stats: 59 lines in 2 files changed: 53 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28612.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28612/head:pull/28612 PR: https://git.openjdk.org/jdk/pull/28612 From erikj at openjdk.org Tue Dec 2 18:33:07 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 2 Dec 2025 18:33:07 GMT Subject: RFR: 8347831: Re-examine version check when cross linking [v9] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:11:02 GMT, Henry Jen wrote: >> This PR include build changes from @magicus and jlink change to verify the build signature. >> >> Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. >> >> ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home >> >> ? java --version >> openjdk 26-internal 2026-03-17 >> OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) >> OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) >> >> ? jlink --version >> 26-internal >> >> ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux >> >> ? jlink --add-modules java.base --output macos >> >> ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A >> >> ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 >> Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - Merge openjdk/master > - adapt review feedbacks > - remove the extra space > - Update the error message when not finding release signature > - Treat missing release.txt as emptry release signature > - Refactoring to clarify version checking cases > - Address review feedbacks > - Use release.txt from java.base module in current and target for comparison > - JLink to check java build information > - Build changes to generate release.txt for java.base and jdk.jlink. Build change looks ok. ------------- Marked as reviewed by erikj (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28155#pullrequestreview-3531592519 From lancea at openjdk.org Tue Dec 2 18:33:58 2025 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 2 Dec 2025 18:33:58 GMT Subject: RFR: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 In-Reply-To: References: Message-ID: <7cE1BZn58zX8WuRsqseB_9lV6_sfS2Ag1hjiZM2a2cA=.3aa0204a-3e20-427b-a487-e6eab77951bb@github.com> On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu wrote: > Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. Changes look reasonable ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3531593095 From sherman at openjdk.org Tue Dec 2 18:38:29 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 2 Dec 2025 18:38:29 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Mon, 1 Dec 2025 23:44:52 GMT, Naoto Sato wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> minor doc formatting update > > src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69: > >> 67: * | 1:2 mapping | 0002 | 0000 | xxxx | xxxx | FB02 => 0066 006C >> 68: * +---+---------+--------+---------+--------+--------+ >> 69: * | 1:3 mapping | 0003 | xxxx | xxxx | xxxx | FB03 => 0066 0066 0069 > > What if 1:2/3 mappings included non-BMP case folded forms? 1:2 should be fine, we still have enough bits available. 1:3 will be more challenging, but in theory 21-bit x 3 = 63. we still have the msb to indicate it's 3 non-bmp. That said, I assume we might simply fallback to the char/int[] mode when the 'flag' byte indicates 0004 for 1:2 non-bmp or 0006 for 1:3 non-bmp, for example. I don't think we need to worry much about the performance for those 'special' cases, if the standard does add such mappings. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582390889 From naoto at openjdk.org Tue Dec 2 18:44:31 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 18:44:31 GMT Subject: RFR: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu wrote: > Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3531645229 From naoto at openjdk.org Tue Dec 2 18:49:42 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 18:49:42 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Tue, 25 Nov 2025 20:21:26 GMT, Xueming Shen wrote: >> ### Summary >> >> Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. >> >> Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: >> >> **String.equalsIgnoreCase(String)** >> >> - Unicode-aware, locale-independent. >> - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. >> - Limited: does not support 1:M mapping defined in Unicode case folding. >> >> **Character.toLowerCase(int) / Character.toUpperCase(int)** >> >> - Locale-independent, single code point only. >> - No support for 1:M mappings. >> >> **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** >> >> - Based on Unicode SpecialCasing.txt, supports 1:M mappings. >> - Intended primarily for presentation/display, not structural case-insensitive matching. >> - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. >> >> **1:M mapping example, U+00DF (?)** >> >> - String.toUpperCase(Locale.ROOT, "?") ? "SS" >> - Case folding produces "ss", matching Unicode caseless comparison rules. >> >> >> jshell> "\u00df".equalsIgnoreCase("ss") >> $22 ==> false >> >> jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") >> $24 ==> true >> >> >> ### Motivation & Direction >> >> Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. >> >> - Unicode-compliant **full** case folding. >> - Simpler, stable and more efficient case-less matching without workarounds. >> - Brings Java's string comparison handling in line with other programming languages/libraries. >> >> This PR proposes to introduce the following comparison methods in `String` class >> >> - boolean equalsFoldCase(String anotherString) >> - int compareToFoldCase(String anotherString) >> - Comparator UNICODE_CASEFOLD_ORDER >> >> These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. >> >> *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. >> However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then pass... > > Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: > > minor doc formatting update LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27628#pullrequestreview-3531664719 From naoto at openjdk.org Tue Dec 2 18:49:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 18:49:44 GMT Subject: RFR: 8365675: Add String Unicode Case-Folding Support [v11] In-Reply-To: References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Tue, 2 Dec 2025 18:35:40 GMT, Xueming Shen wrote: >> src/java.base/share/classes/jdk/internal/lang/CaseFolding.java.template line 69: >> >>> 67: * | 1:2 mapping | 0002 | 0000 | xxxx | xxxx | FB02 => 0066 006C >>> 68: * +---+---------+--------+---------+--------+--------+ >>> 69: * | 1:3 mapping | 0003 | xxxx | xxxx | xxxx | FB03 => 0066 0066 0069 >> >> What if 1:2/3 mappings included non-BMP case folded forms? > > 1:2 should be fine, we still have enough bits available. 1:3 will be more challenging, but in theory 21-bit x 3 = 63. we still have the msb to indicate it's 3 non-bmp. That said, I assume we might simply fallback to the char/int[] mode when the 'flag' byte indicates 0004 for 1:2 non-bmp or 0006 for 1:3 non-bmp, for example. I don't think we need to worry much about the performance for those 'special' cases, if the standard does add such mappings. Yeah, it is non-existent as of now, so the performance would not be an issue even if those cases were introduced in the future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27628#discussion_r2582428584 From naoto at openjdk.org Tue Dec 2 18:55:45 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 2 Dec 2025 18:55:45 GMT Subject: RFR: 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:51:11 GMT, Justin Lu wrote: > This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test. > > The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g. > >> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0] > > As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.) Looks good. A couple of comments follow test/jdk/java/text/Format/DateFormat/Bug4845901.java line 31: > 29: * time. > 30: * @library /java/text/testlib > 31: * @run junit Bug4845901 Specifying `othervm` is safer, as the test sets the default time zone test/jdk/java/text/Format/DateFormat/Bug6530336.java line 88: > 86: date.contains("\u07dc\u07ed\u07d5\u07d6") || // N?Ko > 87: date.contains("\ua2e7\ua0c5\ua395\ua3e6\ua12e\ua209") || // Sichuan Yi, Nuosu > 88: date.contains("\u06af\u0631\u06cc\u0646\u06cc\u0686")) { // Central Kurdish Could use non-escaped strings ------------- PR Review: https://git.openjdk.org/jdk/pull/28590#pullrequestreview-3531463420 PR Review Comment: https://git.openjdk.org/jdk/pull/28590#discussion_r2582270468 PR Review Comment: https://git.openjdk.org/jdk/pull/28590#discussion_r2582443358 From jlu at openjdk.org Tue Dec 2 19:14:02 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 2 Dec 2025 19:14:02 GMT Subject: RFR: 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods [v2] In-Reply-To: References: Message-ID: > This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test. > > The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g. > >> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0] > > As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.) Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Reflect Naoto's comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28590/files - new: https://git.openjdk.org/jdk/pull/28590/files/6de6b7fa..ed9f1ba7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28590&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28590&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28590.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28590/head:pull/28590 PR: https://git.openjdk.org/jdk/pull/28590 From vyazici at openjdk.org Tue Dec 2 19:40:04 2025 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 2 Dec 2025 19:40:04 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. >> >> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. >> >> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use Runnable() instead of CallableOp Marked as reviewed by vyazici (Committer). src/java.base/share/classes/java/util/jar/JarFile.java line 1047: > 1045: jvInitialized = true; > 1046: } > 1047: }); You can consider shortening this using a lambda: ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> { initializeVerifier(); jvInitialized = true; }); ------------- PR Review: https://git.openjdk.org/jdk/pull/28609#pullrequestreview-3531826580 PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582559476 From sherman at openjdk.org Tue Dec 2 19:50:49 2025 From: sherman at openjdk.org (Xueming Shen) Date: Tue, 2 Dec 2025 19:50:49 GMT Subject: Integrated: 8365675: Add String Unicode Case-Folding Support In-Reply-To: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> References: <3tMaotmLtDYKP4cADaC8DEISDKEJEaWHXr2dYDtZXY8=.22820982-951a-4e91-96a0-d21397c8494d@github.com> Message-ID: On Fri, 3 Oct 2025 19:56:22 GMT, Xueming Shen wrote: > ### Summary > > Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions. > > Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as: > > **String.equalsIgnoreCase(String)** > > - Unicode-aware, locale-independent. > - Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point. > - Limited: does not support 1:M mapping defined in Unicode case folding. > > **Character.toLowerCase(int) / Character.toUpperCase(int)** > > - Locale-independent, single code point only. > - No support for 1:M mappings. > > **String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)** > > - Based on Unicode SpecialCasing.txt, supports 1:M mappings. > - Intended primarily for presentation/display, not structural case-insensitive matching. > - Requires full string conversion before comparison, which is less efficient and not intended for structural matching. > > **1:M mapping example, U+00DF (?)** > > - String.toUpperCase(Locale.ROOT, "?") ? "SS" > - Case folding produces "ss", matching Unicode caseless comparison rules. > > > jshell> "\u00df".equalsIgnoreCase("ss") > $22 ==> false > > jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss") > $24 ==> true > > > ### Motivation & Direction > > Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching. > > - Unicode-compliant **full** case folding. > - Simpler, stable and more efficient case-less matching without workarounds. > - Brings Java's string comparison handling in line with other programming languages/libraries. > > This PR proposes to introduce the following comparison methods in `String` class > > - boolean equalsFoldCase(String anotherString) > - int compareToFoldCase(String anotherString) > - Comparator UNICODE_CASEFOLD_ORDER > > These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required. > > *Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string. > However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate. > > ### The New API > > See CSR https://bugs.openjd... This pull request has now been integrated. Changeset: b97ed667 Author: Xueming Shen URL: https://git.openjdk.org/jdk/commit/b97ed667db0bd527461b2b385af3001f53d71c19 Stats: 1452 lines in 13 files changed: 1240 ins; 207 del; 5 mod 8365675: Add String Unicode Case-Folding Support Reviewed-by: rriggs, naoto, ihse ------------- PR: https://git.openjdk.org/jdk/pull/27628 From alanb at openjdk.org Tue Dec 2 20:12:19 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 2 Dec 2025 20:12:19 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 19:36:49 GMT, Volkan Yazici wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use Runnable() instead of CallableOp > > src/java.base/share/classes/java/util/jar/JarFile.java line 1047: > >> 1045: jvInitialized = true; >> 1046: } >> 1047: }); > > You can consider shortening this using a lambda: > > > ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> { > initializeVerifier(); > jvInitialized = true; > }); Yes, but I think would be prudent to run startup benchmarks if you change that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2582636023 From duke at openjdk.org Tue Dec 2 20:21:31 2025 From: duke at openjdk.org (duke) Date: Tue, 2 Dec 2025 20:21:31 GMT Subject: RFR: 8346657: Improve out of bounds exception messages for MemorySegments [v11] In-Reply-To: <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> <872VVX4wiI6FIRwnTOEV-2oD-AKZ1jlXeNE2k1gtLYk=.af3fc91d-b864-479b-bb52-8967eb987cc7@github.com> Message-ID: On Tue, 2 Dec 2025 13:10:09 GMT, Igor Rudenko wrote: >> Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: >> - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases >> - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach > > Igor Rudenko has updated the pull request incrementally with one additional commit since the last revision: > > Improvements according to reviewer's advices @hextriclosan Your change (at version 6a89618346637e8412c7e5d4cb715838be634cfb) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28124#issuecomment-3603810406 From vlivanov at openjdk.org Tue Dec 2 20:21:29 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:21:29 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> Message-ID: <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0rbfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> On Tue, 2 Dec 2025 02:51:57 GMT, Chen Liang wrote: >> So, it seems like what you are trying to achieve is a 1-1 mapping from `AccessDescriptor` to `vh` through `adaptedMh`. So, once `cache != null` you can trust that it corresponds to the `vh` instance passed as a constant. But cache pollution can easily break the invariant, so you try to eliminate the pollution by avoiding cache updates when vh is not constant. Do I get it right? > > No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update. > > The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`. I still find it confusing, especially tri-state logic part. For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was: if (isCompileConstant(...)) { return ...; } else { ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) } In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582647097 From vlivanov at openjdk.org Tue Dec 2 20:21:33 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 2 Dec 2025 20:21:33 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:41:04 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Tweak VH usage in some classes src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2042: > 2040: // This is still a hot path if vh is not constant - in this case, > 2041: // asType is the bottleneck for constant folding, unfortunately > 2042: var result = vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker); `mode` and `symbolicMethodTypeInvoker` are part of `AccessDescriptor` while `vh` comes as an argument. What guarantees that a cached adapter is compatible with `vh` observed during subsequent calls? It means that `vh` shape stays exactly the same shape. Is it correct? Would be good to have it validated with asserts. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582661917 From nbenalla at openjdk.org Tue Dec 2 20:54:33 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Tue, 2 Dec 2025 20:54:33 GMT Subject: Integrated: 8372939: Update JDK 26 spec URLs In-Reply-To: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com> References: <0Zu0JpJyAJQRxsnczTb85i3Vm-kItFV2LVqEkFCqtjQ=.34022e58-3a1d-422a-b289-ae5fe0b18396@github.com> Message-ID: On Tue, 2 Dec 2025 14:05:33 GMT, Nizar Benalla wrote: > Updating the JDK 26 JLS and JVMS links This pull request has now been integrated. Changeset: a2ad5ca9 Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/a2ad5ca93ef82797ecf3141d00216ef639a9e92d Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod 8372939: Update JDK 26 spec URLs Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28605 From iris at openjdk.org Tue Dec 2 21:23:57 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 2 Dec 2025 21:23:57 GMT Subject: RFR: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu wrote: > Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28612#pullrequestreview-3532155522 From liach at openjdk.org Tue Dec 2 22:06:49 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 22:06:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:18:19 GMT, Vladimir Ivanov wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Tweak VH usage in some classes > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2042: > >> 2040: // This is still a hot path if vh is not constant - in this case, >> 2041: // asType is the bottleneck for constant folding, unfortunately >> 2042: var result = vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker); > > `mode` and `symbolicMethodTypeInvoker` are part of `AccessDescriptor` while `vh` comes as an argument. What guarantees that a cached adapter is compatible with `vh` observed during subsequent calls? It means that `vh` shape stays exactly the same shape. Is it correct? Would be good to have it validated with asserts. I am assuming that the previous `vh` observed is compatible with future ones if compiler can fold the `vh` into a constant. If it is not, we can drop the updates to the cache field in the C2 compiled slow code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582922472 From liach at openjdk.org Tue Dec 2 22:10:31 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 22:10:31 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0rbfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> Message-ID: On Tue, 2 Dec 2025 20:12:12 GMT, Vladimir Ivanov wrote: >> No. The avoidance of cache update simply trims down the generated code by throwing away the meaningless cache update. >> >> The access to cache is already safeguarded by `constant == MethodHandleImpl.CONSTANT_YES`. I should have moved `var cache = adaptedMh;` into the if block of `constant == CONSTANT_YES`. > > I still find it confusing, especially tri-state logic part. > > For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was: > > if (isCompileConstant(...)) { > return ...; > } else { > ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) > } > > > In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code? I am assuming that if C2 determines this `vh` is not a constant, we can drop it. Is that a right way to move along, or could C2 transition from "not a constant" to "is a constant" during the phases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2582931449 From henryjen at openjdk.org Tue Dec 2 22:15:48 2025 From: henryjen at openjdk.org (Henry Jen) Date: Tue, 2 Dec 2025 22:15:48 GMT Subject: Integrated: 8347831: Re-examine version check when cross linking In-Reply-To: References: Message-ID: <7D0ypC5sLcCaqWu0xrxBdbvDPF6pUOzKUmEZZaQh9eQ=.6b71d1dc-2147-41ed-81c2-e33a98620140@github.com> On Wed, 5 Nov 2025 17:41:44 GMT, Henry Jen wrote: > This PR include build changes from @magicus and jlink change to verify the build signature. > > Tested with local builds for MacOS and Linux as below shows that cross linking with same build is working while linking with different build failed with error message. > > ? export JAVA_HOME=./build/macosx-x86_64-server-fastdebug/images/jdk-bundle/jdk-26.jdk/Contents/Home > > ? java --version > openjdk 26-internal 2026-03-17 > OpenJDK Runtime Environment (fastdebug build 26-internal-adhoc.hjen.JDK-8347831) > OpenJDK 64-Bit Server VM (fastdebug build 26-internal-adhoc.hjen.JDK-8347831, mixed mode, sharing) > > ? jlink --version > 26-internal > > ? jlink --module-path ./build/linux-x86_64-server-release/images/jdk/jmods --add-modules java.base --output linux > > ? jlink --add-modules java.base --output macos > > ? jlink --module-path ~/linux/jdk-25.0.1/jmods --add-modules java.base --output linux25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A > > ? jlink --module-path /Library/Java/JavaVirtualMachines/jdk-25.jdk/Contents/Home/jmods --add-modules java.base --output macos25 > Error: jlink build N/A-26-internal-adhoc.hjen.JDK-8347831-2026-03-17 does not match target java.base build N/A This pull request has now been integrated. Changeset: 8f0cb57e Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/8f0cb57e439df87dee4c0ba7bbff0b981ebc3541 Stats: 85 lines in 5 files changed: 60 ins; 8 del; 17 mod 8347831: Re-examine version check when cross linking Co-authored-by: Magnus Ihse Bursie Reviewed-by: erikj, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28155 From duke at openjdk.org Tue Dec 2 22:20:54 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Tue, 2 Dec 2025 22:20:54 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays Message-ID: The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. ------------- Commit messages: - 8370688: Addressed review comments - 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays Changes: https://git.openjdk.org/jdk/pull/28615/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370688 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28615.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28615/head:pull/28615 PR: https://git.openjdk.org/jdk/pull/28615 From liach at openjdk.org Tue Dec 2 22:20:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 22:20:55 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur wrote: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. I don't think we need to go this far as to add a new paragraph. Looking at examples like `Class::getMethods`, I think we can just change the first sentences of "Returns the ... objects" to "Returns an array containing the ... objects", which means the returned array is not the same as the underlying storage format. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3604141759 From liach at openjdk.org Tue Dec 2 23:20:12 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:20:12 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v4] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang 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 eight additional commits since the last revision: - Rollback getAndAdd for now - Redundant change - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Stage - Review tweaks - Tweak VH usage in some classes - Logical fallacy - 8160821 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/7bcdcbf3..d49ad129 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=02-03 Stats: 4382 lines in 98 files changed: 2923 ins; 688 del; 771 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From duke at openjdk.org Tue Dec 2 23:29:54 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 2 Dec 2025 23:29:54 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v4] In-Reply-To: References: Message-ID: <_1A3X22p1nAzs5oWjBUuMghm1tQ4rFbubH1Gb_tlIow=.d6fa1e7e-e424-4311-ae9b-cc76a851b737@github.com> > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: Check for SIZED / SUBSIZED and absence of other flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28568/files - new: https://git.openjdk.org/jdk/pull/28568/files/9e7a1c50..5750b26a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=02-03 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568 PR: https://git.openjdk.org/jdk/pull/28568 From liach at openjdk.org Tue Dec 2 23:30:13 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:30:13 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v4] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 eight additional commits since the last revision: > > - Rollback getAndAdd for now > - Redundant change > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Stage > - Review tweaks > - Tweak VH usage in some classes > - Logical fallacy > - 8160821 After consulting with @iwanowww, I realized the non-constant status cannot be determined, that the C2 compiled method can even transition from 0 to 1, so I am simplifying this code to only handle the constant case. It seems the getAndAdd IR test no longer fails with this change, and I removed a lot of other redundant changes. I updated the VarHandleExact benchmark added by @JornVernee, and added a case of dropping return values by changing access mode to `getAndAdd` consistently. Now they have the following performance numbers: Benchmark Mode Cnt Score Error Units VarHandleExact.exact_exactInvocation avgt 30 3.843 ? 0.062 ns/op VarHandleExact.generic_exactInvocation avgt 30 3.797 ? 0.049 ns/op VarHandleExact.generic_genericInvocation avgt 30 3.757 ? 0.034 ns/op VarHandleExact.generic_returnDroppingInvocation avgt 30 3.754 ? 0.026 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3604377750 From duke at openjdk.org Tue Dec 2 23:35:33 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 2 Dec 2025 23:35:33 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v5] In-Reply-To: References: Message-ID: > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. Patrick Strawderman has refreshed the contents of this pull request, and previous commits have been removed. The incremental views will show differences compared to the previous content of the PR. The pull request contains one new commit since the last revision: Check for SIZED / SUBSIZED and absence of other flags ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28568/files - new: https://git.openjdk.org/jdk/pull/28568/files/5750b26a..bcc973eb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=03-04 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568 PR: https://git.openjdk.org/jdk/pull/28568 From duke at openjdk.org Tue Dec 2 23:35:36 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 2 Dec 2025 23:35:36 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v3] In-Reply-To: References: <7J-z_iy59MbtjbxIAgZGXb5O3oMxOz9uPLoRORjZ8ho=.5d949768-e179-4be9-9dfe-226eda885e91@github.com> Message-ID: On Tue, 2 Dec 2025 16:00:42 GMT, Viktor Klang wrote: >> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: >> >> Add unit test > > test/jdk/java/util/EnumSet/EnumSetSpliteratorTest.java line 79: > >> 77: assertTrue(spliterator.hasCharacteristics(Spliterator.SORTED), "Missing SORTED"); >> 78: assertTrue(spliterator.hasCharacteristics(Spliterator.ORDERED), "Missing ORDERED"); >> 79: assertTrue(spliterator.hasCharacteristics(Spliterator.NONNULL), "Missing NONNULL"); > > Thanks for adding the test. I think it makes sense to check the `enumSet.spliterator().characteristics()` being exactly `DISTINCT | SORTED | ORDERED | NONNULL` (since this test otherwise would still pass if further characteristics are added). Okay, I also check for SIZED / SUBSIZED since those get added by `Spliterators.spliterator`. I left each check split out though to make it easier to see exactly why the test fails if there's a regression. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28568#discussion_r2583116248 From liach at openjdk.org Tue Dec 2 23:39:33 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:39:33 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur wrote: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. Looks good in principle to indicate non-uniqueness. Please find security area reviewers to double check. You should also create a CSR for this specification change. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3532560572 From liach at openjdk.org Tue Dec 2 23:44:52 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 2 Dec 2025 23:44:52 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com> On Tue, 2 Dec 2025 20:08:54 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/jar/JarFile.java line 1047: >> >>> 1045: jvInitialized = true; >>> 1046: } >>> 1047: }); >> >> You can consider shortening this using a lambda: >> >> >> ScopedValue.where(IN_VERIFIER_INIT, true).run(() -> { >> initializeVerifier(); >> jvInitialized = true; >> }); > > Yes, but I think would be prudent to run startup benchmarks if you change that. Using a lambda is probably fine given the AOT cache can archive lambdas and avoid the bytecode generation cost. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583136671 From bchristi at openjdk.org Tue Dec 2 23:50:08 2025 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 2 Dec 2025 23:50:08 GMT Subject: RFR: 8367938: Test Serialization Compatibility of Class Objects In-Reply-To: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> References: <6QIykev7qW7_xiSl3MAD0nJJlIcixdMiW86KMNHuZAI=.47c4f854-2fc6-4b87-b241-88dcda29afee@github.com> Message-ID: On Mon, 1 Dec 2025 20:30:30 GMT, Roger Riggs wrote: > ArchivedClassesTest is added to compare archived serialized class objects against current classes. > Note: these are the serialized class objects themselves, for example `java.lang.String.class`, not instances of the class, for example "Hello". > The archived classes reference was built against the latest released version: 25.0.1+8. > > The test fails if the serialized class reference archive is missing from the repository > or if there are any incompatible changes to the serialized bytes. > Normal output from the test includes: > - The version of the serialized class archive > - Listing (if any) of incompatible classes > - Listing of classes with compatible changes > - Listing of classes in the archive that are not in the current version > - Listing of classes in the current version not found in the archive > > The change of java.nio.ByteOrder from a class to enum is reported as an approved incompatible change. A couple general comments: It seems useful for the test to also detect if new classes need to be added to the archive. Can a class have more than one "earlier version"? Could/should more than one earlier version be tested? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28586#issuecomment-3604417085 From liach at openjdk.org Wed Dec 3 00:21:21 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 00:21:21 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v4] In-Reply-To: References: Message-ID: <-t_SUbWpXqrXN4PhmG16FJrYc3s5hyMckypBpiClOew=.098c95ff-e17d-4e8a-b94d-f3f791b10f39@github.com> On Mon, 1 Dec 2025 02:33:33 GMT, Shaojin Wen wrote: >> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. >> >> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. >> >> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. >> >> Parsing scenarios show improvements from 12% to 95% > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > bug fix I think from your experiments, maintaining onlyChronoField is indeed way too painful. So I support updating the map in Parsed to use a custom implemented map. This should be not as risky as that map is never exposed to the public users. src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1825: > 1823: return this; > 1824: } > 1825: return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, fields, chrono, zone, onlyChronoField); Same check comment src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 1874: > 1872: resolverFields = Collections.unmodifiableSet(new HashSet<>(resolverFields)); > 1873: } > 1874: return new DateTimeFormatter(printerParser, locale, decimalStyle, resolverStyle, resolverFields, chrono, zone, onlyChronoField); Need to check if `resolverFields` has non-ChronoField ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3532627956 PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2583190506 PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2583190245 From darcy at openjdk.org Wed Dec 3 01:34:19 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 3 Dec 2025 01:34:19 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 483: > 481: */ > 482: RELEASE_26, > 483: At the top of the file where the per-release changes are all listed, please add a "27: tbd" entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2583333814 From vlivanov at openjdk.org Wed Dec 3 01:42:45 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Dec 2025 01:42:45 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> Message-ID: <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> On Tue, 2 Dec 2025 22:08:20 GMT, Chen Liang wrote: >> I still find it confusing, especially tri-state logic part. >> >> For background, `isCompileConstant` was introduced as part of LF sharing effort to get rid of Java-level profiling in optimized code. The pattern is was designed for was: >> >> if (isCompileConstant(...)) { >> return ...; >> } else { >> ... // do some extra work (either in interpreter, C1, or not-fully-optimized version in C2) >> } >> >> >> In this patch, you don't follow that pattern and aadd new state (`CONSTANT_PENDING`) to distinguish interpreter/C1 from C2. What's the motivation? Why do you want to avoid cache updates coming from C2-generated code? > > I am assuming that if C2 determines this `vh` is not a constant, we can drop it. Is that a right way to move along, or could C2 transition from "not a constant" to "is a constant" during the phases? Sorry, I still don't understand how it is intended to work. Why does `MethodHandleImpl.isCompileConstant(vh) == true` imply that the cached value is compatible with the constant `vh`? // Keep capturing - vh may suddenly get promoted to a constant by C2 Capturing happens outside compiler thread. It is not affected by C2 (except when it completely prunes the whole block). So, either any captured adaptation is valid/compatible or there's a concurrency issue when C2 kicks in and there's a concurrent cache update happening with incompatible version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583346750 From swen at openjdk.org Wed Dec 3 01:44:42 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 3 Dec 2025 01:44:42 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v5] In-Reply-To: References: Message-ID: > This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. > > When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. > > Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. > > Parsing scenarios show improvements from 12% to 95% Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: resolverFields, from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28471/files - new: https://git.openjdk.org/jdk/pull/28471/files/073e2b8d..b2b19e13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=03-04 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471 From vlivanov at openjdk.org Wed Dec 3 01:56:27 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Dec 2025 01:56:27 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v4] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 23:20:12 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 eight additional commits since the last revision: > > - Rollback getAndAdd for now > - Redundant change > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Stage > - Review tweaks > - Tweak VH usage in some classes > - Logical fallacy > - 8160821 test/micro/org/openjdk/bench/java/lang/invoke/VarHandleExact.java line 81: > 79: > 80: @Benchmark > 81: public void generic_returnDroppingInvocation() { What about "all-generic" case (` { generic.getAndAdd(data, 42); }`)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583363907 From iris at openjdk.org Wed Dec 3 02:12:00 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 3 Dec 2025 02:12:00 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3532863059 From almatvee at openjdk.org Wed Dec 3 03:29:14 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Dec 2025 03:29:14 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage Message-ID: - Added logging of sign commands. - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. - Renamed `unsign` to `removeSignature`. I think it is better name. - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. ------------- Commit messages: - 8356116: [macos] Add logging of sign commands in jpackage Changes: https://git.openjdk.org/jdk/pull/28623/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28623&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356116 Stats: 154 lines in 6 files changed: 112 ins; 32 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28623.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28623/head:pull/28623 PR: https://git.openjdk.org/jdk/pull/28623 From dlong at openjdk.org Wed Dec 3 03:38:59 2025 From: dlong at openjdk.org (Dean Long) Date: Wed, 3 Dec 2025 03:38:59 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 10:30:46 GMT, Quan Anh Mai wrote: > Hi, > > This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. > > I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. > > Please kindly review, thanks a lot. src/hotspot/share/opto/doCall.cpp line 958: > 956: ex_node = use_exception_state(ex_map); > 957: // The stack from before the throwing bytecode is gone, cannot reexecute here > 958: jvms()->set_should_reexecute(false); I agree there are situations where we need to set the reexecute flag explicitly and not base it on the bytecode. I recently fixed JDK-8370766 and filed JDK-8372846 as a followup for similar issues. I need to try out your test to understand this better. Does it cause a backwards-branch safepoint? I suspect that it may not be safe to set rexeecute to false here. If reexecute is false and -XX:+VerifyStack is set, deoptimization may fail if the operands are not on the stack. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28597#discussion_r2583510384 From dholmes at openjdk.org Wed Dec 3 04:12:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 3 Dec 2025 04:12:59 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Tue, 2 Dec 2025 15:07:11 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: > > - revert changes to avoid conflict > - add 27 to the acceptable boot versions Hotspot changes trivially fine. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3533103238 From liach at openjdk.org Wed Dec 3 04:13:55 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 04:13:55 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> Message-ID: On Wed, 3 Dec 2025 01:40:29 GMT, Vladimir Ivanov wrote: > any captured adaptation is valid/compatible Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible. For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583556067 From liach at openjdk.org Wed Dec 3 04:13:59 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 04:13:59 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v4] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 01:53:13 GMT, Vladimir Ivanov wrote: >> Chen Liang 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 eight additional commits since the last revision: >> >> - Rollback getAndAdd for now >> - Redundant change >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Stage >> - Review tweaks >> - Tweak VH usage in some classes >> - Logical fallacy >> - 8160821 > > test/micro/org/openjdk/bench/java/lang/invoke/VarHandleExact.java line 81: > >> 79: >> 80: @Benchmark >> 81: public void generic_returnDroppingInvocation() { > > What about "all-generic" case (` { generic.getAndAdd(data, 42); }`)? I can change the `generic_genericInvocation` to an all-generic case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2583556794 From jpai at openjdk.org Wed Dec 3 05:21:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 05:21:55 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com> References: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com> Message-ID: On Tue, 2 Dec 2025 23:42:10 GMT, Chen Liang wrote: >> Yes, but I think would be prudent to run startup benchmarks if you change that. > > Using a lambda is probably fine given the AOT cache can archive lambdas and avoid the bytecode generation cost. Hello Volkan, like Alan notes, for classes that get used very early in the startup, like the JarFile, we have avoided using lambdas so that it doesn't bring in additional lambda related infrastructure during the early startup. I don't plan to run any performance analysis for this change, so I'll let the change stay in its current form. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583654376 From stuart.marks at oracle.com Wed Dec 3 05:37:26 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Dec 2025 21:37:26 -0800 Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects In-Reply-To: References: Message-ID: Vote: yes (To be clear, this is a Yes vote for withdrawing sponsorship for all four of the listed projects.) s'marks On 11/20/25 10:37 PM, Alan Bateman wrote: > > I hereby propose that the Core Libraries group withdraw sponsorship of the Device > I/O [1], Kona [2], Penrose [3], and Verona [4] projects. These projects have been > inactive for a long time: > > - Device I/O has been inactive since 2018. > - Project Kona had some activity in 2015 but nothing since. > - Project Penrose had some activity in 2012 but nothing since. > - Project Verona defined the version-string scheme that integrated into main line > in 2015 for JDK 9 (JEP 223), its work is complete. > > These projects have only one group sponsor. A consequence of withdrawing > sponsorship is that these projects will be dissolved [5]. Votes are due by > December 5, 2025, 23.59 UTC. Only current Core Libraries group members [6] are > eligible to vote on this motion. Votes must be cast in the open by replying to > this mailing list. > > For Lazy Consensus voting instructions, see [7]. > -Alan > [1] https://openjdk.org/projects/dio > [2] https://openjdk.org/projects/kona > [3] https://openjdk.org/projects/penrose > [4] https://openjdk.org/projects/verona > [5] https://openjdk.org/bylaws#sponsor > [6] https://openjdk.org/census#core-libs > [7] https://openjdk.org/bylaws#lazy-consensus -------------- next part -------------- An HTML attachment was scrubbed... URL: From stuart.marks at oracle.com Wed Dec 3 05:43:11 2025 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 2 Dec 2025 21:43:11 -0800 Subject: [External] : Re: Could we add headList and tailList methods to j.u.List? In-Reply-To: References: <0cb56a20-466b-4513-8b37-a3686aade656@oracle.com> Message-ID: (Picking this up after the US holiday weekend) I wanted to ask you more specifically about the use cases. It's interesting to hear about the problem spaces you're working on (Pathfinding and NLP) but I'm more interested in specific cases about how you would use subList APIs. I can imagine how one would use subLists for such applications, but what I imagine might very well be different from what you're actually doing! So I'd like to hear about what you're actually doing. What would an enhanced subList API look like? What indexes, identifying which portions of the underlying List? If you created utility methods for your own use, it might be helpful to share what they do. Not necessarily as a proposal for what to add to the JDK, but rather to let me (and others) know concretely how you're using subLists. Thanks. s'marks On 11/19/25 3:54 AM, David Alayachew wrote: > Thanks for the response @Stuart Marks ! > > > A third concern is that people come along and ask whether we can > > have something in Java that's rather like Python's slices. > > Hah, this email started out as a request for Python slices lol. But I came to the > same conclusion as you. > > I am quite curious about what Project Amber has to say about this. Range patterns, > for example. > > > You had asked about List, not String, but I think similar issues apply. > > I'd guess that String and substring operations are a lot more frequent > > than subList operations. But maybe you have some subList use cases in > > mind. Could you give more details about what you're thinking of? > > I definitely agree that there is heavy overlap in the problem spaces of subList and > substring. > > As for use cases, mostly Path-Finding algorithms and NLP __https://en.wikipedia.org/wiki/Natural_language_processing__;!!ACWV5N9M2RV99hQ! > KWNVun1_iat8b30He5DRLBmNvnYa_gGWluOmusyxN8_0clx5nF5tUN8UmCyUTGhACrhYXSP- > ojovuKpFopr9DPvjAw$> work. The PFA is mostly self explanatory, but for NLP, I splice > up Strings in a bunch of different ways. You have to cycle through different > permutations of word groupings to anchor a phrase to a concept (so I get to use both > substring and subList lol). And each concept has an associated type for it -- a > permitted subtype of a sealed type (which may itself be another permitted subtype of > another). > > Since most of this is me trimming from the front or end, it became way more > manageable to make headList and subList for myself. So, I think that they could be > useful for others too. > > I will say -- zooming out (while thinking of the substring/subList duality), String > and List are just Sequences of X. Maybe there is value in making something more > broad here? Maybe some Sequence-like interface where we expose some helpful range > methods? It would all devolve to the statement forms you mentioned earlier. And in > an ideal world, Project Amber could latch onto that if/when range patterns go live. > I remember watching this video by Brian Goetz about Growing the Language urldefense.com/v3/__https://www.youtube.com/watch?v=Gz7Or9C0TpM__;!!ACWV5N9M2RV99hQ! > KWNVun1_iat8b30He5DRLBmNvnYa_gGWluOmusyxN8_0clx5nF5tUN8UmCyUTGhACrhYXSP- > ojovuKpFopqA6Cw60w$>. It kind of feels like an interface like this would be very > amenable, though I might also be thinking too far ahead lol. > > On Wed, Nov 19, 2025 at 12:48?AM Stuart Marks > wrote: > > > > On 11/16/25 10:51 AM, David Alayachew wrote: > > Could we add headList(int) and tailList(int) to j.u.List? I searched JBS and > found > > nothing. > > > > It's commonly what people want when doing subList(int, int), so this should be > > pretty well received. > > Maybe. :-) > > There's a nexus of diffuse concerns here. > > One concern is subranges of things in general, such as Strings, CharSequences, > Lists, and arrays. Subranges are all expressed as methods with (start, end) > parameters. These are powerful enough to do anything you need to do, but they're > sometimes inconvenient. > > One reason these can be inconvenient is related to the second concern, which is > that > sometimes the APIs require the creation of a local variable, which in turn > forces an > expression to turn into a statement. For example, consider a task of getting a > String from somewhere, taking the first three characters, and passing that > elsewhere > to perform further work. One can write that as > > ? ? ?furtherWork(getString().substring(0, 3)); > > But if you want to take the *last* three characters and pass them along, you > have to > do this: > > ? ? ?var tmp = getString(); > ? ? ?furtherWork(tmp.substring(tmp.length() - 3)); > > This isn't terrible, but sometimes it disrupts an expression to declare a local > variable. > > At least there is a one-arg substring method that takes characters to the end of > the > string. If this method weren't there, you'd have to call length() twice (or store > the length in another local variable). Again, not terrible, but yet another thing > that adds friction. > > A third concern is that people come along and ask whether we can have something in > Java that's rather like Python's slices. For a variety of reasons I don't think we > should accept negative indexes or step values other than 1, but there are some > things that probably occur frequently. For example, to get the last three > characters > of a string, one can write s[-3:]. That's pretty nice. > > You had asked about List, not String, but I think similar issues apply. I'd guess > that String and substring operations are a lot more frequent than subList > operations. But maybe you have some subList use cases in mind. Could you give more > details about what you're thinking of? > > > In that case, would be nice if we could add an entry to JBS with a Won't Fix, to > > make it easier for those looking to see why not. Maybe even link this thread for > > further reading. > > Heh, yeah I've done that a couple times -- filed a bug just to close it out with an > explanation why. I was wondering whether anybody would find that useful. I think > this topic is worth some discussion, though, so I won't do that quite yet. :-) > > s'marks > From jpai at openjdk.org Wed Dec 3 06:01:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 06:01:57 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: rename failure to registryExportFailure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28595/files - new: https://git.openjdk.org/jdk/pull/28595/files/71418e31..58cb9d59 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28595&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28595&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 1 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28595/head:pull/28595 PR: https://git.openjdk.org/jdk/pull/28595 From jpai at openjdk.org Wed Dec 3 06:01:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 06:01:59 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 07:43:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. Hello Stuart, > I'd suggest renaming the failure field and the local variable into which its value is loaded after the thread is joined. The difficulty with "failure" is that it's ambiguous whether it means the export has failed or that the test has failed. (It means the former.) The field is expected to contain an ExportException, so something that suggests that would be preferable. That's a good point. I've updated the PR to rename it to `registryExportFailure`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28595#issuecomment-3605218229 From jpai at openjdk.org Wed Dec 3 06:09:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 06:09:57 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: <9P0_umOsA83u_Bwj2h0HX5rQ9GDcfmtZ5b-Gd0uyinc=.032a12d1-35f1-4f25-830d-980f738c74e9@github.com> On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. test/jdk/java/io/File/GetXSpace.java line 187: > 185: out.format("%s (%d):%n", s.name(), s.size()); > 186: String fmt = " %-4s total = %12d free = %12d usable = %12d%n"; > 187: String method = Platform.isWindows() & isCDDrive(s.name()) ? "getCDDriveSpace" : "getSpace"; Hello Brian, pre-existing nit - for what this line is doing, the use of bitwise `&` operator looks like an oversight. Should it have been `&&`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2583760668 From jpai at openjdk.org Wed Dec 3 06:13:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 06:13:56 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: <19S17EitqITIIGsUqkNZ0nZXM6IJQYTa4d6yLf5ZorI=.1cb4d1f8-3bd9-4c5f-8ecd-db755baa46ce@github.com> On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28592#pullrequestreview-3533351567 From fyang at openjdk.org Wed Dec 3 07:06:05 2025 From: fyang at openjdk.org (Fei Yang) Date: Wed, 3 Dec 2025 07:06:05 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li wrote: >> Hi, >> >> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. >> >> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. >> >> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. >> >> # Test >> ## Jtreg >> >> in progress... >> >> ## Performance >> >> Column names meanings: >> * p: with patch >> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> * m: without patch >> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> >> #### Average improvement >> >> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. >> >> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. >> >> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) >> -- | -- | -- | -- >> 1.022782609 | 2.198717391 | 2.162673913 | 2.199 >> >> > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - remove log_warning > - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp Latest version seems fine to me. Thanks for the update. As we are very close to JDK 26 rampdown (2025/12/04), I suggest we postpone this to JDK 27. ------------- Marked as reviewed by fyang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3533498917 From stuefe at openjdk.org Wed Dec 3 07:29:43 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Dec 2025 07:29:43 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers Message-ID: _This patch is not intended for JDK 26_. I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. ### Implementation Notes With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. b) 64-bit, COH on c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. ### Testing - tier 1 2 3 locally on Linux x64 - SAP ran their whole set of tests for all the platforms they support. [1] https://bugs.openjdk.org/browse/JDK-8350754 [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February/101023.html [3] https://bugs.openjdk.org/browse/JDK-8363998 ------------- Commit messages: - Copyright fixes - Merge branch 'openjdk:master' into JDK-8363996-Obsolete-UseCompressedClassPointers - Review feedback - Fix after JDK-8372045 - fix riscv build - fix TestVMConfigInHsErrFile - remove switch from global - fix aarch64 build - wip - close to finish - ... and 39 more: https://git.openjdk.org/jdk/compare/6f2169ff...64d7984a Changes: https://git.openjdk.org/jdk/pull/28366/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8363996 Stats: 1735 lines in 139 files changed: 64 ins; 1198 del; 473 mod Patch: https://git.openjdk.org/jdk/pull/28366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366 PR: https://git.openjdk.org/jdk/pull/28366 From duke at openjdk.org Wed Dec 3 07:29:45 2025 From: duke at openjdk.org (ExE Boss) Date: Wed, 3 Dec 2025 07:29:45 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe wrote: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... These?comments probably?apply to?many?other locations: -------------------------------------------------------------------------------- But?the?changes should?probably be?done in?a?separate?PR, if?at?all. src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4919: > 4917: } else { > 4918: ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); > 4919: decode_klass_not_null(dst); The `decode_klass_not_null(dst)` call is?now?common to?all?branches, so?it?can be?moved outside: if (UseCompactObjectHeaders) { load_narrow_klass_compact(dst, src); } else { ldrw(dst, Address(src, oopDesc::klass_offset_in_bytes())); } decode_klass_not_null(dst); src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998: > 4996: ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes())); > 4997: ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes())); > 4998: cmpw(tmp1, tmp2); Same?here, but?with `cmpw(tmp1,?tmp2)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3484591668 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543442496 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2543444838 From stuefe at openjdk.org Wed Dec 3 07:29:47 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Wed, 3 Dec 2025 07:29:47 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: References: Message-ID: On Wed, 19 Nov 2025 20:22:19 GMT, ExE Boss wrote: >> _This patch is not intended for JDK 26_. >> >> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. >> >> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2... > > src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 4998: > >> 4996: ldrw(tmp1, Address(obj1, oopDesc::klass_offset_in_bytes())); >> 4997: ldrw(tmp2, Address(obj2, oopDesc::klass_offset_in_bytes())); >> 4998: cmpw(tmp1, tmp2); > > Same?here, but?with `cmpw(tmp1,?tmp2)`. I did your suggested changes, but will hold on doing similar changes (moving instructions out of now common branches) for now; I feel that this makes the diff less clear, and this PR will be annoying to review as it is; lots of onerous work. Let's hear what others think once I undrafted this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2581326249 From alanb at openjdk.org Wed Dec 3 07:31:04 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 07:31:04 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. >> >> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. >> >> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use Runnable() instead of CallableOp Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28609#pullrequestreview-3533568653 From alanb at openjdk.org Wed Dec 3 07:31:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 07:31:06 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: <7EghUFcjt2c0McjKvpqtG837D_SdF8cTDPjAY9zxr4M=.d6f5e2e3-b0d3-479e-8f19-94e0910283ad@github.com> Message-ID: On Wed, 3 Dec 2025 05:19:20 GMT, Jaikiran Pai wrote: > Hello Volkan, like Alan notes, for classes that get used very early in the startup, like the JarFile, we have avoided using lambdas so that it doesn't bring in additional lambda related infrastructure during the early startup. > > I don't plan to run any performance analysis for this change, so I'll let the change stay in its current form. Chen may be right but we could need to re-run startup benchmarks as the signed JAR cases are historically problematic and have bitten the fingers of everyone that has touched it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28609#discussion_r2583946844 From epeter at openjdk.org Wed Dec 3 08:01:06 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 3 Dec 2025 08:01:06 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: <4nP7XPYsi87jqsutMCdufFx4Jz6aa-X_pPpjd_uGoG0=.8ce4119b-c3bb-4cc3-b714-ccbeb9ac7f42@github.com> On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li wrote: >> Hi, >> >> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. >> >> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. >> >> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. >> >> # Test >> ## Jtreg >> >> in progress... >> >> ## Performance >> >> Column names meanings: >> * p: with patch >> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> * m: without patch >> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> >> #### Average improvement >> >> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. >> >> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. >> >> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) >> -- | -- | -- | -- >> 1.022782609 | 2.198717391 | 2.162673913 | 2.199 >> >> > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - remove log_warning > - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp I can help review this as well, but currently there is a lot going on with JDK26 bugs. Hopefully things settle down in a few weeks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3605543510 From alanb at openjdk.org Wed Dec 3 08:44:14 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 08:44:14 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 20:28:50 GMT, Koushik Muthukrishnan Thirupattur wrote: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. There are a lot of APIs that return an array. Some of them use an array internally and so need to make a defensive copy/clone to return. Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array? I don't think the proposed change addresses either concern. We could potentially change the `@return` description to say that it returns a new array, which makes it a testable assertion. There are many other methods that return arrays, including other methods that return arrays of certs and code signers so we might want to change these at the same time. @seanjmullan @wangweij Do you know if there has been any discussion about deprecating getCertificates? Developers have been re-directed to use getCodeSigners since JDK 5. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605690364 From amitkumar at openjdk.org Wed Dec 3 09:07:03 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Wed, 3 Dec 2025 09:07:03 GMT Subject: RFR: 8372710: Update ProcessBuilder/Basic regex In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 06:27:56 GMT, Harshit470250 wrote: > The exception format was changed by [JDK-8352533](https://github.com/openjdk/jdk/pull/24149). This pr implement those changes for the PERMISSION_DENIED_ERROR_MSG and NO_SUCH_FILE_ERROR_MSG. > Similar changes was also done here [ibmruntimes/openj9-openjdk-jdk25/commit/51102b1](https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/40) done by @theresa-m Marked as reviewed by amitkumar (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27244#pullrequestreview-3533914669 From duke at openjdk.org Wed Dec 3 09:07:04 2025 From: duke at openjdk.org (Harshit470250) Date: Wed, 3 Dec 2025 09:07:04 GMT Subject: Integrated: 8372710: Update ProcessBuilder/Basic regex In-Reply-To: References: Message-ID: On Fri, 12 Sep 2025 06:27:56 GMT, Harshit470250 wrote: > The exception format was changed by [JDK-8352533](https://github.com/openjdk/jdk/pull/24149). This pr implement those changes for the PERMISSION_DENIED_ERROR_MSG and NO_SUCH_FILE_ERROR_MSG. > Similar changes was also done here [ibmruntimes/openj9-openjdk-jdk25/commit/51102b1](https://github.com/ibmruntimes/openj9-openjdk-jdk25/pull/40) done by @theresa-m This pull request has now been integrated. Changeset: b3e063c2 Author: root Committer: Amit Kumar URL: https://git.openjdk.org/jdk/commit/b3e063c2c34ac12ae2a566617560ecc52253262d Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8372710: Update ProcessBuilder/Basic regex Reviewed-by: shade, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/27244 From jpai at openjdk.org Wed Dec 3 09:19:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 09:19:50 GMT Subject: RFR: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 16:56:18 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. >> >> The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. >> >> No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use Runnable() instead of CallableOp Thank you all for the reviews. tier1, tier2 and tier3 testing completed with this change without any issues. I'll integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28609#issuecomment-3605829370 From jpai at openjdk.org Wed Dec 3 09:19:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 09:19:51 GMT Subject: Integrated: 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile In-Reply-To: References: Message-ID: <9oz8VKJ7ugkDCVxXojRliR7aUcJV7B8OrQFHyQA2mvE=.befb8f56-a887-4ca7-9e25-e5a48f89084a@github.com> On Tue, 2 Dec 2025 15:44:26 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which removes the usage of `jdk.internal.misc.ThreadTracker` from the `java.util.jar.JarFile` code? This addresses https://bugs.openjdk.org/browse/JDK-8366101. > > The updated code replaces the usage of `ThreadTracker` with the standard `ScopedValue` API. > > No new tests have been introduced, given the nature of the change. tier testing is currently in progress with this change. This pull request has now been integrated. Changeset: e65fd45d Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/e65fd45dc7c9383a77fbd5171b541c2a003d30d2 Stats: 31 lines in 1 file changed: 11 ins; 15 del; 5 mod 8366101: Replace the use of ThreadTracker with ScopedValue in java.util.jar.JarFile Reviewed-by: vyazici, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28609 From jpai at openjdk.org Wed Dec 3 09:31:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 09:31:43 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman wrote: > Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array? What prompted me to file JDK-8370688 is that there's an internal class in the JDK (URLJarFileEntry) which extends `JarEntry` and overrides `getCodeSigners()` and `getCertificates()` to merely clone the returned array. With the way these 2 methods are implemented in `JarEntry`, the returned array is already cloned. So `URLJarFileEntry.getCodeSigners()/getCertificates()` ends up cloning that array twice. The intention of the JBS issue was to have JarEntry specify this current implementation, so that these sub classes of JarEntry can then rely on that specification and don't have to do the clone() themselves. The current proposed text in this PR, I think, needs to be more precise. The way it's worded currently doesn't allow for applications (or JDK internal classes) to rely on the returned array being a copy of the underlying one. As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605890862 From jpai at openjdk.org Wed Dec 3 09:46:07 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 09:46:07 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 09:28:39 GMT, Jaikiran Pai wrote: > As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance). `javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites() Returns: a copy of the array of ciphersuites or null if none have been set. https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols() This method will return a new array each time it is invoked. I prefer the "a copy of the array of ..." style, but I'll let Sean and others decide how to word this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3605950544 From cnorrbin at openjdk.org Wed Dec 3 10:08:50 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 3 Dec 2025 10:08:50 GMT Subject: RFR: 8372615: Many container tests fail when running rootless on cgroup v1 [v2] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 12:45:06 GMT, Casper Norrbin wrote: >> Hi everyone, >> >> Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. >> >> To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). >> >> To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. >> >> Testing: >> * Oracle tiers 1-5 >> * Local testing: >> - `hotspot/jtreg/containers/` >> - `jdk/jdk/internal/platform/docker/` >> on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations > > Casper Norrbin has updated the pull request incrementally with one additional commit since the last revision: > > reworked check docker/resourcelimit functions Thank you for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28557#issuecomment-3606036558 From cnorrbin at openjdk.org Wed Dec 3 10:08:51 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Wed, 3 Dec 2025 10:08:51 GMT Subject: Integrated: 8372615: Many container tests fail when running rootless on cgroup v1 In-Reply-To: References: Message-ID: On Fri, 28 Nov 2025 15:03:25 GMT, Casper Norrbin wrote: > Hi everyone, > > Many container tests verify that various resource limits work as expected. However, when running containers in rootless mode on both Docker and Podman with cgroup v1, resource limits are not supported. This causes tests to fail with error messages like: `Resource limits are not supported and ignored on cgroups V1 rootless systems`. > > To address this, we should skip these tests when running on configurations that don't support resource limits, similar to how we already handle other unsupported configurations (e.g., missing container engine or incompatibility with a specific cgroup version or container runtime). > > To check for this, we now need to use `Metrics.systemMetrics().getProvider()` from `jdk.internal.platform.Metrics` to detect cgroup v1. I've added this functionality to `DockerTestUtils`, which is already used by all container tests. As a result, all container tests now need to include the `java.base/jdk.internal.platform` module, even if they don't directly test resource limits. > > Testing: > * Oracle tiers 1-5 > * Local testing: > - `hotspot/jtreg/containers/` > - `jdk/jdk/internal/platform/docker/` > on cgroup v1/v2 with Podman and Docker in both rootful and rootless configurations This pull request has now been integrated. Changeset: f1a4d1bf Author: Casper Norrbin URL: https://git.openjdk.org/jdk/commit/f1a4d1bfde652cf758117b93bbd02ae8248e805e Stats: 154 lines in 27 files changed: 29 ins; 71 del; 54 mod 8372615: Many container tests fail when running rootless on cgroup v1 Reviewed-by: sgehwolf, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28557 From nbenalla at openjdk.org Wed Dec 3 10:18:16 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:18:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v10] In-Reply-To: References: Message-ID: <1NKVGfCOckDGbbnQKtz0LfvPFhh5SjyUauWyvbsw2yM=.ad2c7571-4ab3-4b1f-b8d7-5ab0814635c7@github.com> > Get JDK 27 underway. Nizar Benalla 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 21 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - revert changes to avoid conflict - add 27 to the acceptable boot versions - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - Merge branch 'master' into start-of-release-27 - Changes required for hard 80 character line limit - Update --release 26 symbol information for JDK 26 build 25 The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ - ... and 11 more: https://git.openjdk.org/jdk/compare/443e5643...8bbe15f2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/1237304b..8bbe15f2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=08-09 Stats: 3514 lines in 111 files changed: 2399 ins; 621 del; 494 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From qamai at openjdk.org Wed Dec 3 10:24:50 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Wed, 3 Dec 2025 10:24:50 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:36:13 GMT, Dean Long wrote: >> Hi, >> >> This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. >> >> I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. >> >> Please kindly review, thanks a lot. > > src/hotspot/share/opto/doCall.cpp line 958: > >> 956: ex_node = use_exception_state(ex_map); >> 957: // The stack from before the throwing bytecode is gone, cannot reexecute here >> 958: jvms()->set_should_reexecute(false); > > I agree there are situations where we need to set the reexecute flag explicitly and not base it on the bytecode. I recently fixed JDK-8370766 and filed JDK-8372846 as a followup for similar issues. I need to try out your test to understand this better. Does it cause a backwards-branch safepoint? I suspect that it may not be safe to set rexeecute to false here. If reexecute is false and -XX:+VerifyStack is set, deoptimization may fail if the operands are not on the stack. Yes, it is a backwards-branch safepoint. Tbh, after looking deeper, I don't really understand what is happening here. I modified the test a little bit so the final compiled code does not elide the safepoint in the loop, and ran with `-XX:+VerifyStack -XX:+DeoptimizeALot -XX:+SafepointALot`, but the test still passed after 100 repeats. I think that the state is correct, but I don't see how the compiled code notifies the deoptimizater and the interpreter that it is in an exception state, and the interpreter needs to find an exception handler instead of continuing with the next bytecode. My guess is that the compiled code should store the exception into `Thread::_pending_exception`, or the deoptimizer needs to do so, and the interpreter needs to check that when being handed the control. But I have not yet found that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28597#discussion_r2584505420 From viktor.klang at oracle.com Wed Dec 3 10:24:54 2025 From: viktor.klang at oracle.com (Viktor Klang) Date: Wed, 3 Dec 2025 11:24:54 +0100 Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects In-Reply-To: References: Message-ID: <62752e7b-1c18-410d-83ec-ee917286056a@oracle.com> Vote: yes On 2025-12-03 06:37, Stuart Marks wrote: > > Vote: yes > > (To be clear, this is a Yes vote for withdrawing sponsorship for all > four of the listed projects.) > > s'marks > > On 11/20/25 10:37 PM, Alan Bateman wrote: >> >> I hereby propose that the Core Libraries group withdraw sponsorship >> of the Device I/O [1], Kona [2], Penrose [3], and Verona [4] >> projects. These projects have been inactive for a long time: >> >> - Device I/O has been inactive since 2018. >> - Project Kona had some activity in 2015 but nothing since. >> - Project Penrose had some activity in 2012 but nothing since. >> - Project Verona defined the version-string scheme that integrated >> into main line in 2015 for JDK 9 (JEP 223), its work is complete. >> >> These projects have only one group sponsor. A consequence of >> withdrawing sponsorship is that these projects will be dissolved [5]. >> Votes are due by December 5, 2025, 23.59 UTC. Only current Core >> Libraries group members [6] are eligible to vote on this motion. >> Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [7]. >> -Alan >> [1] https://openjdk.org/projects/dio >> [2] https://openjdk.org/projects/kona >> [3] https://openjdk.org/projects/penrose >> [4] https://openjdk.org/projects/verona >> [5] https://openjdk.org/bylaws#sponsor >> [6] https://openjdk.org/census#core-libs >> [7] https://openjdk.org/bylaws#lazy-consensus -- Cheers, ? Viktor Klang Software Architect, Java Platform Group Oracle -------------- next part -------------- An HTML attachment was scrubbed... URL: From nbenalla at openjdk.org Wed Dec 3 10:31:18 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:18 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v11] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: - fix jls 27 link - fix typo and add entry for 27 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/8bbe15f2..4bf97a8a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=09-10 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From nbenalla at openjdk.org Wed Dec 3 10:31:24 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:24 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v7] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 19:46:37 GMT, Joe Darcy wrote: >> Nizar Benalla 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 17 additional commits since the last revision: >> >> - problem list failing test >> - Merge branch 'master' into start-of-release-27 >> - expand start of release documentation >> - Merge branch 'master' into start-of-release-27 >> - Changes required for hard 80 character line limit >> - Update --release 26 symbol information for JDK 26 build 25 >> The macOS/AArch64 build 25 was taken from https://jdk.java.net/26/ >> - revert MAX_COLUMNS to 80 >> - Update LATEST_MAJOR_VERSION in Versions.java >> - Merge branch 'master' into start-of-release-27 >> - Merge branch 'master' into start-of-release-27 >> - ... and 7 more: https://git.openjdk.org/jdk/compare/eae9329d...e5214614 > > src/java.base/share/classes/java/lang/reflect/ClassFileFormatVersion.java line 394: > >> 392: * >> 393: * @see > 394: * href="https://docs.oracle.com/en/java/javase/27/docs/specs/jvms/index.html"> > > Presumably the analagous URL update should be done here as in ClassFileFormatVersion for the JLS instead of the JVMS. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4bf97a8ab5a134ab592f7a84b7e1dc130d04a845; Good catch! > src/jdk.compiler/share/classes/com/sun/tools/javac/main/Option.java line 1368: > >> 1366: } >> 1367: >> 1368: private static String formatAbbreviatedList(Collection values) { > > I think changing the policy here is okay, but it should be better documented in comments here. > > Additionally, it assume there will be a dense collection of supported values between the 4 th and (n-3) rd. That is currently the de facto policy, but is not ironclad. This assumption should also be documented. Extracted and fixed in a separate issue https://github.com/openjdk/jdk/commit/8a28a76451b2bbde49c1c051cb66c784f9e3cdd2 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584514802 PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584513205 From nbenalla at openjdk.org Wed Dec 3 10:31:27 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 10:31:27 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v9] In-Reply-To: References: <1AN1mD0ieBM6vimoxvEYBpputw1jdAhSlZckB3JT2sw=.bacfe664-2db7-47eb-a1c5-1c6ab614420c@github.com> Message-ID: On Wed, 3 Dec 2025 01:32:00 GMT, Joe Darcy wrote: >> Nizar Benalla has updated the pull request incrementally with two additional commits since the last revision: >> >> - revert changes to avoid conflict >> - add 27 to the acceptable boot versions > > src/java.compiler/share/classes/javax/lang/model/SourceVersion.java line 483: > >> 481: */ >> 482: RELEASE_26, >> 483: > > At the top of the file where the per-release changes are all listed, please add a > > "27: tbd" > > entry after syncing in the changes from mainline which add an entry for JDK 26. (Also, as part of the sync please fix the "in in" stutter typo in the 26 entry. Fixed in https://github.com/openjdk/jdk/pull/28130/commits/4b14a7593c9cbc6f67d400e823d47d23e304d564 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28130#discussion_r2584507508 From pminborg at openjdk.org Wed Dec 3 10:34:41 2025 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 3 Dec 2025 10:34:41 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: Message-ID: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com> On Tue, 2 Dec 2025 17:24:41 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: >> >>> 2034: var constant = MethodHandleImpl.isCompileConstant(vh); >>> 2035: var cache = adaptedMh; >>> 2036: if (constant == MethodHandleImpl.CONSTANT_YES && cache != null) { >> >> Rookie question: Is there multi-thread considerations here? How about visibility across threads? > > MethodHandle is immutable and can be safely published. So this is ok. I meant that even though objects are immutable, plain semantics might not always do. Reference: https://shipilev.net/blog/2014/safe-public-construction/ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2584535309 From alanb at openjdk.org Wed Dec 3 10:38:25 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 10:38:25 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 09:43:27 GMT, Jaikiran Pai wrote: > > As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance). > > `javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways: > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites() > > ``` > Returns: > a copy of the array of ciphersuites or null if none have been set. > ``` A SSLParameters is optionally created with array of cipher suites so it works there. A JarEntry is not created with an array so I don't think this wording make sense. > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols() > > ``` > This method will return a new array each time it is invoked. > ``` That could work for JarEntry although debatable if we really need this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606176594 From duke at openjdk.org Wed Dec 3 10:40:47 2025 From: duke at openjdk.org (Igor Rudenko) Date: Wed, 3 Dec 2025 10:40:47 GMT Subject: Integrated: 8346657: Improve out of bounds exception messages for MemorySegments In-Reply-To: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> References: <4_ZZ_V1nUSotMvHLYKV-GyDYZgGSDLY6RJJM73BzfeI=.0e0c3f1d-3b6c-429d-a3e5-43934ddc93f8@github.com> Message-ID: <8gC9HIWuXF7PmSXJ75jVtg3mlRjbNu20n181wnb9bvY=.4b2b7a09-721d-49a9-b7ad-905d81f7983b@github.com> On Tue, 4 Nov 2025 09:17:27 GMT, Igor Rudenko wrote: > Logic for creating IndexOutOfBoundsException in MemorySegment is reworked: > - separate logic of checking bounds and constructing exception messages for both `access` and `slice` cases > - idea presented in [JDK-8288534](https://bugs.openjdk.org/browse/JDK-8288534) slightly reworked with preservation of the original approach This pull request has now been integrated. Changeset: 170ebdc5 Author: Igor Rudenko Committer: Per Minborg URL: https://git.openjdk.org/jdk/commit/170ebdc5b7b5e54cc7bec60944898d35a24d760b Stats: 65 lines in 4 files changed: 39 ins; 5 del; 21 mod 8346657: Improve out of bounds exception messages for MemorySegments Reviewed-by: jvernee, liach, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/28124 From jvernee at openjdk.org Wed Dec 3 13:26:28 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Dec 2025 13:26:28 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> Message-ID: <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com> On Wed, 3 Dec 2025 04:10:05 GMT, Chen Liang wrote: >> Sorry, I still don't understand how it is intended to work. Why does `MethodHandleImpl.isCompileConstant(vh) == true` imply that the cached value is compatible with the constant `vh`? >> >> >> // Keep capturing - vh may suddenly get promoted to a constant by C2 >> >> >> Capturing happens outside compiler thread. It is not affected by C2 (except when it completely prunes the whole block). >> >> So, either any captured adaptation is valid/compatible or there's a concurrency issue when C2 kicks in and there's a concurrent cache update happening with incompatible version. > >> any captured adaptation is valid/compatible > > Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible. > > For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way. Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved. For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell. The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585100537 From jvernee at openjdk.org Wed Dec 3 13:37:54 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 3 Dec 2025 13:37:54 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com> References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com> Message-ID: On Wed, 3 Dec 2025 13:23:18 GMT, Jorn Vernee wrote: >>> any captured adaptation is valid/compatible >> >> Yes, if `vh` is a constant, any captured adaptation from `vh.getMethodHandle(mode).asType(symbolicMethodTypeInvoker)` is valid/compatible. >> >> For thread safety, MethodHandle supports safe publication, so I think we are fine publishing this way. > > Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved. > > For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell. > > The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant. I think even without using an invoker, you could end up in a similar situation if you have something like: static Object m(VarHandle vh) { return vh.get(); } Which is called by several different threads. At some point this method may be inlined into one of its callees, where `vh` then becomes a constant. But at the same time, other threads are still writing to the cache. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585142665 From mullan at openjdk.org Wed Dec 3 14:00:48 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Dec 2025 14:00:48 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 10:35:40 GMT, Alan Bateman wrote: > > > As far as I remember, we have similar text in some API specification for methods that return a copy of the array, reusing that text might be useful (I'll try and find such an instance). > > > > > > `javax.net.ssl.SSLParameters` has a few APIs which word this in a couple of different ways: > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getCipherSuites() > > ``` > > Returns: > > a copy of the array of ciphersuites or null if none have been set. > > ``` > > A SSLParameters is optionally created with array of cipher suites so it works there. A JarEntry is not created with an array so I don't think this wording make sense. > > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/javax/net/ssl/SSLParameters.html#getApplicationProtocols() > > ``` > > This method will return a new array each time it is invoked. > > ``` > > That could work for JarEntry although debatable if we really need this. The second one looks good to me. This will need a CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606998031 From mullan at openjdk.org Wed Dec 3 14:00:47 2025 From: mullan at openjdk.org (Sean Mullan) Date: Wed, 3 Dec 2025 14:00:47 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 08:41:55 GMT, Alan Bateman wrote: > There are a lot of APIs that return an array. Some of them use an array internally and so need to make a defensive copy/clone to return. Jai may be able to say more on the motivation for JDK-8370688. Maybe a concern with code uses identity to check equality, or maybe the concern was that the caller could modify the JarEntry's certs/signers by modifying the array? > > I don't think the proposed change addresses either concern. We could potentially change the `@return` description to say that it returns a new array, which makes it a testable assertion. There are many other methods that return arrays, including other methods that return arrays of certs and code signers so we might want to change these at the same time. I agree. The original commit was more aligned with what should be done. For security related information like arrays of certificates, I think the caller often needs to know one way or the other whether mutating the returned value affects the original object's contents. And I think in general, `JarEntry` should be returning a new array each time these methods are called. We can at least ensure that the JDK implementation follows the specification. > @seanjmullan @wangweij Do you know if there has been any discussion about deprecating getCertificates? Developers have been re-directed to use getCodeSigners since JDK 5. Not specifically, although I agree that it probably should be deprecated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3606987622 From liach at openjdk.org Wed Dec 3 14:11:22 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 14:11:22 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com> References: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com> Message-ID: On Wed, 3 Dec 2025 10:31:07 GMT, Per Minborg wrote: >> MethodHandle is immutable and can be safely published. So this is ok. > > I meant that even though objects are immutable, plain semantics might not always do. > > Reference: https://shipilev.net/blog/2014/safe-public-construction/ MethodHandle is safe. All fields in Method Handle hierarchies are either lazy/stable or final. You can refer to the `invokers` field in `MethodType`, and the `MethodHandle` array in `Invokers` for precedents. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585263336 From liach at openjdk.org Wed Dec 3 14:11:23 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 14:11:23 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <4gKSL8hFAE2qSuTmhJa6JMfoB6JfUnK9fzwHAnH2Zzg=.9fc69461-bbe7-4242-b3b1-b4b004f35ce0@github.com> Message-ID: <4F_HqL-oY7z2ENI9yIAS7VS3NDjEljsqx4E2zK5HxJ0=.8f5ab39a-66e1-4ea3-ace2-226d6bd39d77@github.com> On Wed, 3 Dec 2025 14:06:00 GMT, Chen Liang wrote: >> I meant that even though objects are immutable, plain semantics might not always do. >> >> Reference: https://shipilev.net/blog/2014/safe-public-construction/ > > MethodHandle is safe. All fields in Method Handle hierarchies are either lazy/stable or final. You can refer to the `invokers` field in `MethodType`, and the `MethodHandle` array in `Invokers` for precedents. In extreme cases where a barrier is needed, java.lang.invoke already issue necessary barriers, most notably the storeStoreFence, such as https://github.com/openjdk/jdk/blob/135661b4389663b8c2e348d9e61e72cc628636bb/src/java.base/share/classes/java/lang/invoke/CallSite.java#L138 or https://github.com/openjdk/jdk/blob/135661b4389663b8c2e348d9e61e72cc628636bb/src/java.base/share/classes/java/lang/ClassValue.java#L411-L417 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2585270552 From syan at openjdk.org Wed Dec 3 14:46:23 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 3 Dec 2025 14:46:23 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 06:01:57 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. >> >> The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. >> >> The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). >> >> I have triggered a tier testing of this change in our CI and will run a test repeat too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > rename failure to registryExportFailure Marked as reviewed by syan (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28595#pullrequestreview-3535408076 From duke at openjdk.org Wed Dec 3 14:49:45 2025 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Wed, 3 Dec 2025 14:49:45 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v16] In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> References: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> Message-ID: On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Escape regex in properties. As the CSR looks finalized, I believe we can go ahead with: ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3607221191 From alanb at openjdk.org Wed Dec 3 14:53:30 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 3 Dec 2025 14:53:30 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v16] In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> References: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> Message-ID: On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Escape regex in properties. > As the CSR looks finalized, I believe we can go ahead with: > > /integrate I moved the CSR to finalized as it has already been reviewed. Joe (as CSR chair) will need to approve before the "csr" label is removed from the PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3607236416 From msheppar at openjdk.org Wed Dec 3 15:08:59 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 3 Dec 2025 15:08:59 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 06:01:57 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. >> >> The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. >> >> The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). >> >> I have triggered a tier testing of this change in our CI and will run a test repeat too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > rename failure to registryExportFailure a minor point on the @bug additions. Typically, this is reserved for a bug id which is an actual fix to JDK source code. There is some ambiguity on this policy, but generally that has been the practice. Maybe it is a topic which should be discussed at a jdk-dev level, and a clearer policy assertion established? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28595#issuecomment-3607307562 From jpai at openjdk.org Wed Dec 3 15:18:59 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 15:18:59 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: remove bug id ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28595/files - new: https://git.openjdk.org/jdk/pull/28595/files/58cb9d59..f0cef51b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28595&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28595&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28595.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28595/head:pull/28595 PR: https://git.openjdk.org/jdk/pull/28595 From jpai at openjdk.org Wed Dec 3 15:19:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 15:19:00 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:05:49 GMT, Mark Sheppard wrote: > a minor point on the @bug additions. Typically, this is reserved for a bug id which is an actual fix to JDK source code. There is some ambiguity on this policy, but generally that has been the practice. Thank you for reminding me about that, Mark. The OpenJDK dev guide has clear guidance on what the `@bug` tag should contain https://openjdk.org/guide/#jtreg : > You can add several bug ids in the same @bug tag, separated by a single space. These bug ids refer to product bugs for which a fix is verified by this test. JBS issues that track changes to the test itself are not listed here. (I think this might be a recent update to the guide) I've updated the PR to remove this test specific bug id. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28595#issuecomment-3607345574 From asemenyuk at openjdk.org Wed Dec 3 15:23:11 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:23:11 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java line 63: > 61: new AppImageSigner(Codesigners.create(signingCfg)).sign(app, appImage); > 62: } catch (CodesignException ex) { > 63: LOGGER.log(Level.ERROR, ex); This log statement is redundant. There is no point in logging exceptions being passed through. This catch block catches an exception, passes it to `handleCodesignException()` method, and then rethrows it. What additional information do we need about this "event"? src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java line 66: > 64: throw handleCodesignException(app, ex); > 65: } catch (ExceptionBox ex) { > 66: LOGGER.log(Level.ERROR, ex); This log statement is redundant. Same as above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585541827 PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585543304 From asemenyuk at openjdk.org Wed Dec 3 15:26:45 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:26:45 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java line 92: > 90: boolean result = testInternal(path); > 91: LOGGER.log(Level.TRACE, "{0}: {1}", path, result ? > 92: "Will be explicitely signed" : "Will be skipped from signing"); We will have detailed log statements for files that will be signed, right? We don't need an extra "Will be explicitely signed" log message for these files. I think "Will be skipped from signing" is sufficient for files that will be skipped in signing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585555883 From asemenyuk at openjdk.org Wed Dec 3 15:30:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:30:15 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java line 173: > 171: } > 172: } catch (IOException ex) { > 173: LOGGER.log(Level.ERROR, ex); This log statement is redundant as it duplicates information from the exception's stack trace. We'd rather log trapped exceptions in the cli.Main class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585568406 From msheppar at openjdk.org Wed Dec 3 15:36:33 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Wed, 3 Dec 2025 15:36:33 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v3] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:18:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. >> >> The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. >> >> The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). >> >> I have triggered a tier testing of this change in our CI and will run a test repeat too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28595#pullrequestreview-3535638841 From asemenyuk at openjdk.org Wed Dec 3 15:37:34 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:37:34 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: <-AaPRYEwqWu-FWfJnUoh3bNt2aNP_jG7YKDpja9Ij8I=.cae16575-442a-4be1-810a-e71689374165@github.com> On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/AppImageSigner.java line 237: > 235: findCodesigner(path).orElseThrow(() -> { > 236: LOGGER.log(Level.ERROR, "No codesigner for {0} path", > 237: PathUtils.normalizedAbsolutePathString(path)); This log statement is redundant. There is no point in logging exceptions being thrown. It is sufficient to log the caught exceptions if the log messages include exception stack traces. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585598635 From asemenyuk at openjdk.org Wed Dec 3 15:40:43 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:40:43 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java line 246: > 244: } > 245: > 246: static String createExecutionResultLogMessage(List args, What is the reason to bring this function from Log class? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585610643 From asemenyuk at openjdk.org Wed Dec 3 15:44:19 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 3 Dec 2025 15:44:19 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. Some changes required src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java line 1: > 1: /* The changes to this file imply that logging external commands that jpackage runs is optional. Is it? Why would we want to log some commands but not all? ------------- Changes requested by asemenyuk (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28623#pullrequestreview-3535683855 PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2585622467 From bpb at openjdk.org Wed Dec 3 15:45:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 15:45:34 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: <9P0_umOsA83u_Bwj2h0HX5rQ9GDcfmtZ5b-Gd0uyinc=.032a12d1-35f1-4f25-830d-980f738c74e9@github.com> References: <9P0_umOsA83u_Bwj2h0HX5rQ9GDcfmtZ5b-Gd0uyinc=.032a12d1-35f1-4f25-830d-980f738c74e9@github.com> Message-ID: <4gImNpjNT_fxuHkP8gfOlAjN65cjfRBHCB_xjz0UR9A=.65f8f047-f3a1-4c72-b71c-5edd04108629@github.com> On Wed, 3 Dec 2025 06:07:00 GMT, Jaikiran Pai wrote: >> Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. > > test/jdk/java/io/File/GetXSpace.java line 187: > >> 185: out.format("%s (%d):%n", s.name(), s.size()); >> 186: String fmt = " %-4s total = %12d free = %12d usable = %12d%n"; >> 187: String method = Platform.isWindows() & isCDDrive(s.name()) ? "getCDDriveSpace" : "getSpace"; > > Hello Brian, pre-existing nit - for what this line is doing, the use of bitwise `&` operator looks like an oversight. Should it have been `&&`? Hi @jaikiran. Indeed this looks like an ineffectual mistake but I'll fix it before integrating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2585632311 From nbenalla at openjdk.org Wed Dec 3 15:48:23 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 3 Dec 2025 15:48:23 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: > Get JDK 27 underway. Nizar Benalla 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 24 additional commits since the last revision: - Merge branch 'master' into start-of-release-27 - fix jls 27 link - fix typo and add entry for 27 - Merge branch 'master' into start-of-release-27 - revert changes to avoid conflict - add 27 to the acceptable boot versions - Merge branch 'master' into start-of-release-27 - problem list failing test - Merge branch 'master' into start-of-release-27 - expand start of release documentation - ... and 14 more: https://git.openjdk.org/jdk/compare/0351ed87...444cc1c8 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28130/files - new: https://git.openjdk.org/jdk/pull/28130/files/4bf97a8a..444cc1c8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28130&range=10-11 Stats: 819 lines in 34 files changed: 424 ins; 271 del; 124 mod Patch: https://git.openjdk.org/jdk/pull/28130.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28130/head:pull/28130 PR: https://git.openjdk.org/jdk/pull/28130 From liach at openjdk.org Wed Dec 3 15:54:30 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 15:54:30 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v5] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Fix problem identified by Jorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/d49ad129..89e21b4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=03-04 Stats: 40 lines in 3 files changed: 25 ins; 2 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From bpb at openjdk.org Wed Dec 3 16:04:43 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 16:04:43 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call [v2] In-Reply-To: References: Message-ID: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8372851: Incorrect bitwise AND to logical AND ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28592/files - new: https://git.openjdk.org/jdk/pull/28592/files/2bda30df..973ea83b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28592&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28592&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28592.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28592/head:pull/28592 PR: https://git.openjdk.org/jdk/pull/28592 From jpai at openjdk.org Wed Dec 3 16:04:43 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 3 Dec 2025 16:04:43 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 16:01:16 GMT, Brian Burkhalter wrote: >> Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8372851: Incorrect bitwise AND to logical AND Thank you for the update, Brian. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28592#pullrequestreview-3535771144 From bpb at openjdk.org Wed Dec 3 16:04:45 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 16:04:45 GMT Subject: RFR: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call [v2] In-Reply-To: <4gImNpjNT_fxuHkP8gfOlAjN65cjfRBHCB_xjz0UR9A=.65f8f047-f3a1-4c72-b71c-5edd04108629@github.com> References: <9P0_umOsA83u_Bwj2h0HX5rQ9GDcfmtZ5b-Gd0uyinc=.032a12d1-35f1-4f25-830d-980f738c74e9@github.com> <4gImNpjNT_fxuHkP8gfOlAjN65cjfRBHCB_xjz0UR9A=.65f8f047-f3a1-4c72-b71c-5edd04108629@github.com> Message-ID: On Wed, 3 Dec 2025 15:43:14 GMT, Brian Burkhalter wrote: >> test/jdk/java/io/File/GetXSpace.java line 187: >> >>> 185: out.format("%s (%d):%n", s.name(), s.size()); >>> 186: String fmt = " %-4s total = %12d free = %12d usable = %12d%n"; >>> 187: String method = Platform.isWindows() & isCDDrive(s.name()) ? "getCDDriveSpace" : "getSpace"; >> >> Hello Brian, pre-existing nit - for what this line is doing, the use of bitwise `&` operator looks like an oversight. Should it have been `&&`? > > Hi @jaikiran. Indeed this looks like an ineffectual mistake but I'll fix it before integrating. This and one other occurrence fixed in 973ea83. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28592#discussion_r2585679123 From darcy at openjdk.org Wed Dec 3 16:36:16 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 3 Dec 2025 16:36:16 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: <14VgrwjksW2UO1LtpHGyX6sTjHbaplRnV7ZgmcyiRIQ=.b06ebf9a-2f95-4e95-89b9-981562ceef06@github.com> On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/659ebef2...444cc1c8 Marked as reviewed by darcy (Reviewer). Marked as reviewed by darcy (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535940924 PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535946905 From liach at openjdk.org Wed Dec 3 16:43:24 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 16:43:24 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v6] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with two additional commits since the last revision: - Test from Jorn - Copyright years ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/89e21b4b..ff7b3629 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=04-05 Stats: 107 lines in 3 files changed: 105 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From liach at openjdk.org Wed Dec 3 16:44:15 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 16:44:15 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/c61f404d...444cc1c8 Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3535980615 From duke at openjdk.org Wed Dec 3 16:55:08 2025 From: duke at openjdk.org (fabioromano1) Date: Wed, 3 Dec 2025 16:55:08 GMT Subject: RFR: 8366478: BigDecimal roots [v30] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Added further tests and optimized result assertions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/97dbb083..83c4ff53 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=28-29 Stats: 191 lines in 2 files changed: 89 ins; 30 del; 72 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From iris at openjdk.org Wed Dec 3 16:56:43 2025 From: iris at openjdk.org (Iris Clark) Date: Wed, 3 Dec 2025 16:56:43 GMT Subject: RFR: 8370890: Start of release updates for JDK 27 [v12] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:48:23 GMT, Nizar Benalla wrote: >> Get JDK 27 underway. > > Nizar Benalla 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 24 additional commits since the last revision: > > - Merge branch 'master' into start-of-release-27 > - fix jls 27 link > - fix typo and add entry for 27 > - Merge branch 'master' into start-of-release-27 > - revert changes to avoid conflict > - add 27 to the acceptable boot versions > - Merge branch 'master' into start-of-release-27 > - problem list failing test > - Merge branch 'master' into start-of-release-27 > - expand start of release documentation > - ... and 14 more: https://git.openjdk.org/jdk/compare/afcc5cbc...444cc1c8 Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28130#pullrequestreview-3536041848 From naoto at openjdk.org Wed Dec 3 17:07:22 2025 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 3 Dec 2025 17:07:22 GMT Subject: RFR: 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods [v2] In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 19:14:02 GMT, Justin Lu wrote: >> This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test. >> >> The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g. >> >>> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0] >> >> As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.) > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect Naoto's comments LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28590#pullrequestreview-3536085126 From jlu at openjdk.org Wed Dec 3 17:28:24 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Dec 2025 17:28:24 GMT Subject: RFR: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu wrote: > Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. Thank you for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28612#issuecomment-3607960489 From jlu at openjdk.org Wed Dec 3 17:28:25 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 3 Dec 2025 17:28:25 GMT Subject: Integrated: 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 18:18:29 GMT, Justin Lu wrote: > Routine update to IANA subtag registry data with [latest data](https://www.iana.org/assignments/language-subtag-registry/language-subtag-registry). Version is bumped to 2025-08-25. This pull request has now been integrated. Changeset: fa6ca0bb Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/fa6ca0bbd14436cd3778a7a3383183cd73688123 Stats: 59 lines in 2 files changed: 53 ins; 0 del; 6 mod 8362428: Update IANA Language Subtag Registry to Version 2025-08-25 Reviewed-by: lancea, naoto, iris ------------- PR: https://git.openjdk.org/jdk/pull/28612 From smarks at openjdk.org Wed Dec 3 17:45:57 2025 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 3 Dec 2025 17:45:57 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v3] In-Reply-To: References: Message-ID: <9wHPwUMAuGAxcMiJ1LX-F7da-a0WlF2vAsSHVkKurZA=.fe959671-d6a0-4b37-b847-e302d6f22db5@github.com> On Wed, 3 Dec 2025 15:18:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. >> >> The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. >> >> The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). >> >> I have triggered a tier testing of this change in our CI and will run a test repeat too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id @msheppar Good point about the bug tag! I hadn't seen that before. @jaikiran Thanks for updates. Changes re-reviewed. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28595#pullrequestreview-3536224545 From duke at openjdk.org Wed Dec 3 18:46:40 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Wed, 3 Dec 2025 18:46:40 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v2] In-Reply-To: References: Message-ID: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8370688: Addressed review comments - add explicit note similar to SSLParameters ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28615/files - new: https://git.openjdk.org/jdk/pull/28615/files/c9c87bfa..59abe38b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=00-01 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28615.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28615/head:pull/28615 PR: https://git.openjdk.org/jdk/pull/28615 From duke at openjdk.org Wed Dec 3 18:58:26 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Wed, 3 Dec 2025 18:58:26 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v6] In-Reply-To: References: Message-ID: > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: Fix test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28568/files - new: https://git.openjdk.org/jdk/pull/28568/files/bcc973eb..98bcd8b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568 PR: https://git.openjdk.org/jdk/pull/28568 From vlivanov at openjdk.org Wed Dec 3 19:39:56 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 3 Dec 2025 19:39:56 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v6] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 16:43:24 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with two additional commits since the last revision: > > - Test from Jorn > - Copyright years src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > 2034: // from two writes (they must not be tearable) > 2035: private record Adaption(VarHandle vh, MethodHandle mh) {} > 2036: private @Stable Adaption adaption; Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2586374014 From bpb at openjdk.org Wed Dec 3 20:02:34 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 3 Dec 2025 20:02:34 GMT Subject: Integrated: 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 00:49:12 GMT, Brian Burkhalter wrote: > Change the test to print the pathname if `getSpace0` fails with a `RuntimeException`. This pull request has now been integrated. Changeset: ba777f66 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/ba777f6610fa3744d5f4bdfb87066b137ab543af Stats: 17 lines in 1 file changed: 13 ins; 0 del; 4 mod 8372851: Modify java/io/File/GetXSpace.java to print path on failure of native call Reviewed-by: jpai, naoto ------------- PR: https://git.openjdk.org/jdk/pull/28592 From aph at openjdk.org Wed Dec 3 20:40:45 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 3 Dec 2025 20:40:45 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: References: Message-ID: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com> On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe wrote: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3608746121 From aph at openjdk.org Wed Dec 3 20:45:53 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 3 Dec 2025 20:45:53 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe wrote: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... src/hotspot/share/oops/klass.cpp line 1063: > 1061: // This can be expensive, but it is worth checking that this klass is actually > 1062: // in the CLD graph but not in production. > 1063: Suggestion: Stray blank line? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2586552890 From almatvee at openjdk.org Wed Dec 3 23:17:39 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Dec 2025 23:17:39 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: <_CpqQVYjDeNT9SpPHjfM7c4VfG2IROGVnnXPodHK4ng=.a2786855-faf1-456f-bd18-98b442e274d5@github.com> On Wed, 3 Dec 2025 15:38:25 GMT, Alexey Semenyuk wrote: >> - Added logging of sign commands. >> - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. >> - Renamed `unsign` to `removeSignature`. I think it is better name. >> - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. >> - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java line 246: > >> 244: } >> 245: >> 246: static String createExecutionResultLogMessage(List args, > > What is the reason to bring this function from Log class? To reuse it between `Log.verbose` and `logger.log`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2586904640 From almatvee at openjdk.org Wed Dec 3 23:22:56 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Dec 2025 23:22:56 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:41:13 GMT, Alexey Semenyuk wrote: >> - Added logging of sign commands. >> - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. >> - Renamed `unsign` to `removeSignature`. I think it is better name. >> - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. >> - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java line 1: > >> 1: /* > > The changes to this file imply that logging external commands that jpackage runs is optional. Is it? Why would we want to log some commands but not all? MAIN("jdk.jpackage"), MAC_SIGN("jdk.jpackage.mac-sign"), LINUX_LIBS("jdk.jpackage.linux-libs"), In my understanding we have 3 types of loggers. MAIN and MAC_SIGN we need to log command executions. Not sure about LINUX_LIBS. If we log always using MAIN, then signing will be partially logged with MAIN and fully logged with MAC_SIGN. Not sure what is right solution here. Do we need to log sign commands for MAIN? or just with MAC_SIGN? If we log for MAIN, then when to log skipped files for example or execution of signature removal commands? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28623#discussion_r2586913001 From almatvee at openjdk.org Wed Dec 3 23:43:17 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Dec 2025 23:43:17 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage [v2] In-Reply-To: References: Message-ID: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8356116: [macos] Add logging of sign commands in jpackage [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28623/files - new: https://git.openjdk.org/jdk/pull/28623/files/eb34f609..d2f81fc3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28623&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28623&range=00-01 Stats: 10 lines in 1 file changed: 1 ins; 7 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28623.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28623/head:pull/28623 PR: https://git.openjdk.org/jdk/pull/28623 From almatvee at openjdk.org Wed Dec 3 23:43:18 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 3 Dec 2025 23:43:18 GMT Subject: RFR: 8356116: [macos] Add logging of sign commands in jpackage In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 03:20:45 GMT, Alexander Matveev wrote: > - Added logging of sign commands. > - Sign commands will be logged with `DEBUG` level. Skipped files and signature removal with `TRACE` to reduce amount of less important messages. > - Renamed `unsign` to `removeSignature`. I think it is better name. > - Removed `sign` and `codesigners.accept(path)` will be used instead. Not sure why we need function with one line and we using `codesigners.accept(path)` in other places anyway. > - Direct call to `codesigners.codesignDir().accept(path)` was changed to `codesigners.accept(path)`. In this case exception will be logged if `codesignDir` is not available and I think it is better for `codesigners.accept(path)` to select code signer vs calling it directly. 8356116: [macos] Add logging of sign commands in jpackage [v2] - Fixed latest comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28623#issuecomment-3609288372 From liach at openjdk.org Wed Dec 3 23:44:01 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 3 Dec 2025 23:44:01 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v6] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 19:37:25 GMT, Vladimir Ivanov wrote: >> Chen Liang has updated the pull request incrementally with two additional commits since the last revision: >> >> - Test from Jorn >> - Copyright years > > src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: > >> 2034: // from two writes (they must not be tearable) >> 2035: private record Adaption(VarHandle vh, MethodHandle mh) {} >> 2036: private @Stable Adaption adaption; > > Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long. I don't think we can use a SoftReference here if we need to achieve constant folding. Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null. I think that belongs to a separate RFE. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2586946357 From bchristi at openjdk.org Wed Dec 3 23:54:02 2025 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 3 Dec 2025 23:54:02 GMT Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method [v2] In-Reply-To: References: Message-ID: <_TuxsWZeGypUELREcXo9PVYMaqO6Ujpx91vQTq10tZY=.e67cd96e-9cbb-475a-8b43-6d57d3baaca1@github.com> On Thu, 20 Nov 2025 20:19:24 GMT, Brent Christian wrote: >> From the bug report: >> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to >> "[invoke] shutdown() when this executor is no longer referenced and it has no threads." >> >> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)). >> >> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)). >> >> The finalize() method can safely be removed from ThreadPoolExecutor. > > Brent Christian 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 8371748-TPE.f10n > - Remove ThreadPoolExecutor.finalize() I've created a Release Note for this change, if someone could have a look and review it: https://bugs.openjdk.org/browse/JDK-8373057 TIA ------------- PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3609314384 From jpai at openjdk.org Thu Dec 4 01:39:10 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 01:39:10 GMT Subject: RFR: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test [v3] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 15:18:59 GMT, Jaikiran Pai wrote: >> Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? >> >> As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. >> >> The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. >> >> The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). >> >> I have triggered a tier testing of this change in our CI and will run a test repeat too. > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > remove bug id Thank you Mark and Stuart for the reviews. The test continues to pass in our CI with these changes. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28595#issuecomment-3609575124 From jpai at openjdk.org Thu Dec 4 01:39:11 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 01:39:11 GMT Subject: Integrated: 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 07:43:01 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which improves the debuggability of the `java/rmi/server/RemoteServer/AddrInUse.java` test? > > As noted in https://bugs.openjdk.org/browse/JDK-8213699, this test fails intermittently. The test code launches a Thread which does a `LocateRegistry.createRegistry(port)`. The test then expects that call to return within (an arbitrary) 10 seconds and if it doesn't, then it considers that the test has ended up reproducing a bug which would cause a hang in the implementation of `LocateRegistry.createRegistry(...)` method. > > The 10 seconds is a reasonable timeout, I think even for busy hosts. But we have seen this test fail because the launched thread which does the `LocateRegistry.createRegistry(...)` has either not started or completed within that period. > > The changes in this PR updates that test code to remove the arbitrary 10 second timeout and instead just wait for the launched thread to complete. If the test doesn't complete within the configured jtreg test timeout (which by default is 2 minutes), then the jtreg and its failure handler infrastructure will gather the necessary thread dump and other states to help debug why the test timed out. This should help understand such intermittent failures in future (if it continues to fail). > > I have triggered a tier testing of this change in our CI and will run a test repeat too. This pull request has now been integrated. Changeset: 04c0f8d3 Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/04c0f8d359a3f450ac2070c6d41834145d9c75f7 Stats: 76 lines in 1 file changed: 17 ins; 39 del; 20 mod 8372857: Improve debuggability of java/rmi/server/RemoteServer/AddrInUse.java test Reviewed-by: msheppar, smarks, syan ------------- PR: https://git.openjdk.org/jdk/pull/28595 From liach at openjdk.org Thu Dec 4 01:48:31 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 4 Dec 2025 01:48:31 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v7] In-Reply-To: References: Message-ID: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com> > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/ff7b3629..8200fb28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=05-06 Stats: 23 lines in 1 file changed: 20 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From vlivanov at openjdk.org Thu Dec 4 01:58:56 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Thu, 4 Dec 2025 01:58:56 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v6] In-Reply-To: References: Message-ID: <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com> On Wed, 3 Dec 2025 23:41:01 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2036: >> >>> 2034: // from two writes (they must not be tearable) >>> 2035: private record Adaption(VarHandle vh, MethodHandle mh) {} >>> 2036: private @Stable Adaption adaption; >> >> Is a soft reference needed here? The situation looks similar to `MH.asTypeSoftCache`. It can keep some classes referred by `vh` alive for unnecessarily long. > > I don't think we can use a SoftReference here if we need to achieve constant folding. > > Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null. I think that belongs to a separate RFE. What do you think? Then it makes sense to limit the caching to safe cases only for now. Otherwise, it would functionally regress due to a possible memory leak. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2587156042 From dlong at openjdk.org Thu Dec 4 03:24:59 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 4 Dec 2025 03:24:59 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: <29opt6wmJqMaeTB-QbJWTMCndjSQH0ZhbTaD-ir6X4A=.b728d464-b7f1-44c5-a76c-c84f84f150f5@github.com> On Tue, 2 Dec 2025 10:30:46 GMT, Quan Anh Mai wrote: > Hi, > > This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. > > I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. > > Please kindly review, thanks a lot. It seems to be very difficult to force the back-edge safepoint to deoptimize. I tried creating a thread that calls System.gc(), but so far no crash. Still, I think the state is incorrect if reexecute=false. Setting reexecute to false means it will skip the current instruction. To correctly handle a deoptimization on the backwards branch, the debug state, bci, and exception location should match. I think we have 3 choices to prepare for maybe_add_safepoint(): 1. preserve stack inputs, use original bci, do not push exception oop, let interpreter reexecute and throw the exception (reexecute=true) This might be as simple as reversing the order of calls to push_ex_oop and maybe_add_safepoint. 2. trim stack, push exception object, use bci of exception handler (reexecute=true) This would require temporarily changing the bci for the maybe_add_safepoint call. 3. trim stack, throw exception (move to Thread) (reexecute=true) This requires extra unconditional overhead even though safepoint rarely happens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28597#issuecomment-3609883724 From dholmes at openjdk.org Thu Dec 4 05:15:03 2025 From: dholmes at openjdk.org (David Holmes) Date: Thu, 4 Dec 2025 05:15:03 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:17:37 GMT, Thomas Stuefe wrote: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... About a third of the way through. Mostly all pretty straight-forward but unclear why a number of _LP64 guards can be removed? src/hotspot/share/cds/aotMetaspace.cpp line 1853: > 1851: // > 1852: // The range encompassing both spaces will be suitable to en/decode narrow Klass > 1853: // pointers: the base will be valid for encoding, the range [Base, End) and not Suggestion: // pointers: the base will be valid for encoding the range [Base, End) and not src/hotspot/share/cds/archiveBuilder.cpp line 671: > 669: dump_region->allocate(sizeof(address)); > 670: } > 671: #ifdef _LP64 Not obvious this isn't still needed. src/hotspot/share/cds/archiveBuilder.cpp line 1140: > 1138: }; > 1139: > 1140: #ifdef _LP64 Again not clear why this can be removed. ------------- PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3538084962 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587534751 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587540478 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587563999 From darcy at openjdk.org Thu Dec 4 06:19:07 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 4 Dec 2025 06:19:07 GMT Subject: RFR: 8367603: Optimize exact division in BigDecimal [v15] In-Reply-To: References: <72ldQiki4ogBZVxWgqEuiyvSRWOEnxnvmVYOLS46ODQ=.aba22686-bd14-413c-b256-caee3a041603@github.com> Message-ID: On Thu, 25 Sep 2025 17:37:34 GMT, fabioromano1 wrote: >> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: >> >> Comments > > Master branch results: > > Benchmark Mode Cnt Score Error Units > BigDecimalDivide.testExactDivideL avgt 15 109800.570 ? 4612.510 ns/op > BigDecimalDivide.testExactDivideM avgt 15 18786.818 ? 725.330 ns/op > BigDecimalDivide.testExactDivideS avgt 15 9764.192 ? 98.841 ns/op > BigDecimalDivide.testExactDivideXL avgt 15 976249.610 ? 194313.150 ns/op > BigDecimalDivide.testExactDivideXS avgt 15 7782.170 ? 209.999 ns/op > ``` > > PR branch results: > > Benchmark Mode Cnt Score Error Units > BigDecimalDivide.testExactDivideL avgt 15 9323.939 ? 302.617 ns/op > BigDecimalDivide.testExactDivideM avgt 15 5367.752 ? 87.323 ns/op > BigDecimalDivide.testExactDivideS avgt 15 4514.351 ? 79.579 ns/op > BigDecimalDivide.testExactDivideXL avgt 15 37474.101 ? 601.947 ns/op > BigDecimalDivide.testExactDivideXS avgt 15 3983.560 ? 60.067 ns/op @fabioromano1, I'll finish reviewing this early in JDK 27. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27271#issuecomment-3610476173 From jpai at openjdk.org Thu Dec 4 06:29:00 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 06:29:00 GMT Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method [v2] In-Reply-To: References: Message-ID: <_ql-1ceUCJQKQJ4YOSPcsiNPeh-euKLId-ylw2Wddi4=.f4f4e425-2ccb-4d4f-a3a3-6fac289f4309@github.com> On Thu, 20 Nov 2025 20:19:24 GMT, Brent Christian wrote: >> From the bug report: >> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to >> "[invoke] shutdown() when this executor is no longer referenced and it has no threads." >> >> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)). >> >> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)). >> >> The finalize() method can safely be removed from ThreadPoolExecutor. > > Brent Christian 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 8371748-TPE.f10n > - Remove ThreadPoolExecutor.finalize() Hello Brent, the release note looks good to me. Just a minor suggestion, perhaps the following: > With the removal of `ThreadPoolExecutor.finalize()`, existing code that subclasses `ThreadPoolExecutor` ... could be replaced with > With the removal of `ThreadPoolExecutor.finalize()`, any existing class that extends `ThreadPoolExecutor` ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3610509368 From stuefe at openjdk.org Thu Dec 4 07:00:33 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 07:00:33 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v2] In-Reply-To: References: Message-ID: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/share/cds/aotMetaspace.cpp Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28366/files - new: https://git.openjdk.org/jdk/pull/28366/files/64d7984a..141113a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366 PR: https://git.openjdk.org/jdk/pull/28366 From stuefe at openjdk.org Thu Dec 4 07:06:49 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 07:06:49 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: Message-ID: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Apply suggestion from @theRealAph Co-authored-by: Andrew Haley ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28366/files - new: https://git.openjdk.org/jdk/pull/28366/files/141113a0..074a2337 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366 PR: https://git.openjdk.org/jdk/pull/28366 From stuefe at openjdk.org Thu Dec 4 07:06:52 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 07:06:52 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 04:59:51 GMT, David Holmes wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply suggestion from @theRealAph >> >> Co-authored-by: Andrew Haley > > src/hotspot/share/cds/archiveBuilder.cpp line 671: > >> 669: dump_region->allocate(sizeof(address)); >> 670: } >> 671: #ifdef _LP64 > > Not obvious this isn't still needed. That is a small simplification that should have been part of https://bugs.openjdk.org/browse/JDK-8363998. The test alignment = nth_bit(ArchiveBuilder::precomputed_narrow_klass_shift()); can be applied to 32-bit, too. There, precomputed_narrow_klass_shift() is zero. > src/hotspot/share/cds/archiveBuilder.cpp line 1140: > >> 1138: }; >> 1139: >> 1140: #ifdef _LP64 > > Again not clear why this can be removed. Same reasoning. 32-bit now also uses narrow Klass pointers, so that code can be made unconditionally compilable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587823782 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2587825926 From jpai at openjdk.org Thu Dec 4 07:07:56 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 07:07:56 GMT Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS In-Reply-To: References: Message-ID: On Sat, 22 Nov 2025 13:25:01 GMT, SendaoYan wrote: >> Hi all, >> >> Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS). >> >> Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check. >> >> But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time. >> >> Change has been verified locally on XFS file system and ext4 file system. > > I create a demo to explain what utimes linux system call works on XFS file system. > > When the time value bigger or equals the maximum of signed integer, then the time will set to UNIX epoch time. > > > #include > #include > #include > #include > > int main(int argc, char** argv) { > if (argc != 3) { > printf("usage: ./a.out file seconds\n"); > return 1; > } > const char *filename = argv[1]; > struct timeval times[2]; > long time = atol(argv[2]); > > times[0].tv_sec = time; // atime > times[0].tv_usec = 0; > > times[1].tv_sec = time; // mtime > times[1].tv_usec = 0; > > int ret = utimes(filename, times); > printf("utimes to file %s as %ld return code is %d\n", filename, time, ret); > > return 0; > } > > > Test command and result: > > >> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483646 ; stat --format %y a.out > utimes to file a.out as 2147483646 return code is 0 > 2038-01-19 11:14:06.000000000 +0800 >> gcc -Wall -Wextra ~/compiler-test/zzkk/utimes-test.c ; ./a.out a.out 2147483647 ; stat --format %y a.out > utimes to file a.out as 2147483647 return code is 0 > 1970-01-01 08:00:00.000000000 +0800 Hello @sendaoYan, do you plan to integrate this before the rampdown fork today? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3610610847 From stuefe at openjdk.org Thu Dec 4 07:09:01 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 07:09:01 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers In-Reply-To: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com> References: <1ylERIxcH47S_3TkReUXaGLfMgYBVrvniM-2qMcReMg=.4a242937-c1db-45e9-b905-9df0dece3cc4@github.com> Message-ID: On Wed, 3 Dec 2025 20:37:25 GMT, Andrew Haley wrote: > https://github.com/openjdk/jdk/pull/28366/files?w=1 makes this PR easier to read. Yes, "hide widespaces" is useful. Github is still surprisingly bad at managing large patches. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28366#issuecomment-3610611623 From jpai at openjdk.org Thu Dec 4 07:13:01 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 07:13:01 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:46:40 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8370688: Addressed review comments - add explicit note similar to SSLParameters Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3538474729 From syan at openjdk.org Thu Dec 4 07:38:07 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 4 Dec 2025 07:38:07 GMT Subject: Integrated: 8371978: tools/jar/ReproducibleJar.java fails on XFS In-Reply-To: References: Message-ID: On Tue, 18 Nov 2025 08:24:13 GMT, SendaoYan wrote: > Hi all, > > Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS). > > Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check. > > But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time. > > Change has been verified locally on XFS file system and ext4 file system. This pull request has now been integrated. Changeset: 828498c5 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/828498c54b3b1089af9e076cb45f3cf3bea58e2f Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod 8371978: tools/jar/ReproducibleJar.java fails on XFS Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/28367 From syan at openjdk.org Thu Dec 4 07:38:07 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 4 Dec 2025 07:38:07 GMT Subject: RFR: 8371978: tools/jar/ReproducibleJar.java fails on XFS In-Reply-To: References: Message-ID: <5gEtN0BOppQqD5PL0Pk_z-T0RSL6saxaySgC6avd0o4=.385b1d01-9d28-451a-8e95-2f0cd239e37f@github.com> On Tue, 18 Nov 2025 08:24:13 GMT, SendaoYan wrote: > Hi all, > > Test tools/jar/ReproducibleJar.java fails when running on a file system that only supports to 2038(e.g. XFS). > > Before this PR, test check if the input test time after "2038-01-19T03:14:07Z" and the extracted time created by jar is equal to "2038-01-19T03:14:07Z", then test will skip that check. > > But the extraced time created by jar equal to "1970-01-01T00:00:00Z" actually. I think the extracted time set to unix epoch time is acceptable, so this PR fix the test make test check skip when the extracted time is unix epoch time. > > Change has been verified locally on XFS file system and ext4 file system. Sorry for the delay response. Thanks for the test and reviews @jaikiran . ------------- PR Comment: https://git.openjdk.org/jdk/pull/28367#issuecomment-3610690265 From duke at openjdk.org Thu Dec 4 08:14:48 2025 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 4 Dec 2025 08:14:48 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v17] In-Reply-To: References: Message-ID: > This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: > > - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. > - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. > - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. > - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. > - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. > > Some implementation details and choices: > - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. > - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). > - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). > - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28359/files - new: https://git.openjdk.org/jdk/pull/28359/files/41c291b4..d4f08884 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28359&range=15-16 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28359.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28359/head:pull/28359 PR: https://git.openjdk.org/jdk/pull/28359 From duke at openjdk.org Thu Dec 4 08:14:50 2025 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 4 Dec 2025 08:14:50 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v16] In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> References: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> Message-ID: On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Escape regex in properties. As the CSR is now approved, can you please ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3610789826 From duke at openjdk.org Thu Dec 4 08:14:51 2025 From: duke at openjdk.org (duke) Date: Thu, 4 Dec 2025 08:14:51 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v16] In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> References: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> Message-ID: On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Escape regex in properties. @ammbra Your change (at version d4f08884fd45a3830632ac07deb002587636784f) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3610793431 From jpai at openjdk.org Thu Dec 4 08:14:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 08:14:51 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v16] In-Reply-To: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> References: <6oVIlmN-2U7Vlh3SF2VfMT3hK5P7d7jJkW_hxsj7Dug=.167f8492-cb17-4fd2-9fd7-9f2322f91c75@github.com> Message-ID: On Wed, 26 Nov 2025 19:50:09 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Escape regex in properties. Thank you for this fix Ana. I've triggered a CI run with these changes. I'll sponsor this once that completes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3610795837 From duke at openjdk.org Thu Dec 4 10:13:05 2025 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Thu, 4 Dec 2025 10:13:05 GMT Subject: Integrated: 8321139: jlink's compression plugin doesn't handle -c option correctly In-Reply-To: References: Message-ID: On Mon, 17 Nov 2025 17:54:21 GMT, Ana Maria Mihalceanu wrote: > This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: > > - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. > - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. > - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. > - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. > - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. > > Some implementation details and choices: > - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. > - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). > - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). > - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. This pull request has now been integrated. Changeset: df0165bd Author: Ana-Maria Mihalceanu Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/df0165bd6933728fdcf1956323401afdc47b3f78 Stats: 110 lines in 6 files changed: 85 ins; 4 del; 21 mod 8321139: jlink's compression plugin doesn't handle -c option correctly Reviewed-by: jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28359 From jpai at openjdk.org Thu Dec 4 10:13:04 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 4 Dec 2025 10:13:04 GMT Subject: RFR: 8321139: jlink's compression plugin doesn't handle -c option correctly [v17] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 08:14:48 GMT, Ana Maria Mihalceanu wrote: >> This PR looks into aligning the behavior and documentation for `--compress` option and plugin of `jlink`: >> >> - When an user provides `-c {0|1|2}` to `jlink`, then the tool should process it as when receiving `--compress={0|1|2}`. As these values are now deprecated, a warning should be issued to the end user. >> - When an user provides `-c zip-{0-9}` to `jlink`, then the tool should process it as when receiving `--compress=zip-{0-9}`. >> - When no compression level is given, meaning the `jlink` command does not contain either `-c` or `--compress` with a value, the default level selected is `zip-6`. >> - The `--compress` option description reflects above behavior and warns that previous compression levels are deprecated to be removed in a future release. >> - The `--plugin` option description reflects the implementation behavior and warns that previous compression levels are deprecated to be removed in a future release. >> >> Some implementation details and choices: >> - While current `jlink` man page states that the tool supports `-c={0|1|2}`, I inspired myself on how `javac` supports the shortened options https://docs.oracle.com/en/java/javase/25/docs/specs/man/javac.html#options. >> - While `-c 0` and `--compress=0` produce the same compression level as of `zip-0`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - While `-c 2` and `--compress=2` produce the same compression level as of `zip-6`, I preferred not to tie the new compression level to the old value for the option. I believe that this approach would make it easier/cleaner to remove the code for the deprecated values (when their time comes). >> - As I didn't affect the actual compression implementation, only the options, I tested only how the options are mapped. The actual set and validation of the options was not affected, hence I didn't change those tests. > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Update full name tier1, tier2, tier3 testing completed without any related failures. I'll go ahead and sponsor this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28359#issuecomment-3611273363 From swen at openjdk.org Thu Dec 4 10:57:52 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 4 Dec 2025 10:57:52 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v23] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 42 commits: - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 - Merge remote-tracking branch 'origin/optim_parse_int_long_202501' into optim_parse_int_long_202501 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 - Merge remote-tracking branch 'upstream/master' into optim_parse_int_long_202501 # Conflicts: # src/java.base/share/classes/java/lang/Integer.java # src/java.base/share/classes/java/lang/Long.java - remove ForceInline - fix comments - fix comments - Update src/java.base/share/classes/jdk/internal/util/DecimalDigits.java Co-authored-by: Raffaello Giulietti - copyright - ... and 32 more: https://git.openjdk.org/jdk/compare/b5970c97...c58aa707 ------------- Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=22 Stats: 179 lines in 6 files changed: 101 ins; 26 del; 52 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From aph at openjdk.org Thu Dec 4 12:02:30 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Dec 2025 12:02:30 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe wrote: >> _This patch is not intended for JDK 26_. >> >> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. >> >> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestion from @theRealAph > > Co-authored-by: Andrew Haley src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 1281: > 1279: Rtmp1 = op->tmp3()->as_register(); > 1280: select_different_registers(obj, dst, k_RInfo, klass_RInfo, Rtmp1); > 1281: Suggestion: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588781883 From aph at openjdk.org Thu Dec 4 12:06:05 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Dec 2025 12:06:05 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: Message-ID: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com> On Thu, 4 Dec 2025 07:06:49 GMT, Thomas Stuefe wrote: >> _This patch is not intended for JDK 26_. >> >> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. >> >> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestion from @theRealAph > > Co-authored-by: Andrew Haley src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55: > 53: static bool can_use() { return can_map() || can_load(); } > 54: > 55: // Can this VM map archived heap region? Currently only G1+compressed{oops,cp} Suggestion: // Can this VM map archived heap region? Currently only G1. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2588797500 From stuefe at openjdk.org Thu Dec 4 13:36:43 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 13:36:43 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: > _This patch is not intended for JDK 26_. > > I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. > > This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. > > For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. > > This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. > > ### Implementation Notes > > With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): > a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. > b) 64-bit, COH on > c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. > > I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). > > I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. > > Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. > > ### Testing > > - tier 1 2 3 locally on Linux x64 > - SAP ran their whole set of tests for all the platforms they support. > > > [1] https://bugs.openjdk.org/browse/JDK-8350754 > [2] https://mail.openjdk.org/pipermail/hotspot-dev/2025-February... Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp Co-authored-by: Andrew Haley ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28366/files - new: https://git.openjdk.org/jdk/pull/28366/files/074a2337..9e85a653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28366&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28366.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28366/head:pull/28366 PR: https://git.openjdk.org/jdk/pull/28366 From mullan at openjdk.org Thu Dec 4 13:39:35 2025 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 4 Dec 2025 13:39:35 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v2] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:46:40 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8370688: Addressed review comments - add explicit note similar to SSLParameters src/java.base/share/classes/java/util/jar/JarEntry.java line 117: > 115: * to trust the entry signed by the signers. > 116: * > 117: *

This method will return a new array each time it is invoked. This sentence is not completely true, because the method may also return `null`. I suggest moving this sentence to the @return label (as the second sentence), and rephrasing it as "If non-null, this method returns a new array each time it is invoked". I removed "will" as I think present tense sounds better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28615#discussion_r2589119626 From swen at openjdk.org Thu Dec 4 14:02:16 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 4 Dec 2025 14:02:16 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v24] In-Reply-To: References: Message-ID: > This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: > 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. > 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. > 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: remove unsafe ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/c58aa707..cebefd7b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=22-23 Stats: 37 lines in 1 file changed: 0 ins; 33 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/22919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22919/head:pull/22919 PR: https://git.openjdk.org/jdk/pull/22919 From stuefe at openjdk.org Thu Dec 4 14:06:20 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 14:06:20 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com> References: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com> Message-ID: On Thu, 4 Dec 2025 12:03:25 GMT, Andrew Haley wrote: >> Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: >> >> Apply suggestion from @theRealAph >> >> Co-authored-by: Andrew Haley > > src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55: > >> 53: static bool can_use() { return can_map() || can_load(); } >> 54: >> 55: // Can this VM map archived heap region? Currently only G1+compressed{oops,cp} > > Suggestion: > > // Can this VM map archived heap region? Currently only G1. After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time... That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g. I'll take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589215456 From aph at openjdk.org Thu Dec 4 14:43:06 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 4 Dec 2025 14:43:06 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com> Message-ID: On Thu, 4 Dec 2025 14:03:26 GMT, Thomas Stuefe wrote: >> src/hotspot/share/cds/aotMappedHeapLoader.hpp line 55: >> >>> 53: static bool can_use() { return can_map() || can_load(); } >>> 54: >>> 55: // Can this VM map archived heap region? Currently only G1+compressed{oops,cp} >> >> Suggestion: >> >> // Can this VM map archived heap region? Currently only G1. > > After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time... > > That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g. > > I'll take a look. Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates Rule 1: Comments should not duplicate the code ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589349492 From swen at openjdk.org Thu Dec 4 14:45:12 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 4 Dec 2025 14:45:12 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v24] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 14:02:16 GMT, Shaojin Wen wrote: >> This is an optimization for decimal Integer.parseInt and Long.parseLong, which improves performance by about 10%. The optimization includes: >> 1. Improve performance by parsing 2 numbers at a time, which has performance improvements for numbers with length >= 3. >> 2. It uses charAt(0) for the first number. Assuming that the optimization can eliminate boundary checks, this will be more friendly to parsing numbers with length 1. >> 3. It removes the reliance on the Character.digit method and eliminates the reliance on the CharacterDataLatin1#DIGITS cache array, which avoids performance degradation caused by cache misses. > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove unsafe In my latest implementation, I removed `Unsafe` from the `DecimalDigits::digit2` method, which resulted in a performance decrease, but it's still better than the master branch. Below are my performance tests on x64 and aarch64: # 1. Test Script git remote add wenshao git at github.com:wenshao/jdk.git git fetch wenshao # base (master banch) git checkout 9ea0dcd3eaf07658aeb92ba0defb5098e1f7b192 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # Digit2 (current) git checkout cebefd7b89f2dbf29bb13c4903060707a5574e67 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # Digit2_Unsafe (before) git checkout c58aa7071867f386407f33defe2b346176fc1e91 make test TEST="micro:java.lang.Longs.parseLong" make test TEST="micro:java.lang.Integers.parseInt" # 2. Performance Results on MacBook M1 Pro * Raw Data # base Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.371 ? 0.012 us/op Longs.parseLong 500 avgt 15 2.731 ? 0.030 us/op # digit2 Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.221 ? 0.009 us/op Longs.parseLong 500 avgt 15 2.517 ? 0.016 us/op # digit2_unsafe Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.114 ? 0.012 us/op Longs.parseLong 500 avgt 15 2.344 ? 0.028 us/op * Comparison | Benchmark | base | Digit2 | Digit2_Unsafe | base vs Digit2 (%) | Digit2 vs Digit2_Unsafe (%) | |-----------|--------|--------|---------------|----------------------|------------------------------| | Integers.parseInt | 2.371 | 2.221 | 2.114 | +6.33% | +4.82% | | Longs.parseLong | 2.731 | 2.517 | 2.344 | +7.84% | +6.87% | # 3. Performance Results on Aliyun_ECS_c9a (x64, AMD AMD EPYC? Turin) * Row Data # base Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.541 ? 0.022 us/op Longs.parseLong 500 avgt 15 2.941 ? 0.014 us/op # digit2 Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.542 ? 0.003 us/op Longs.parseLong 500 avgt 15 2.527 ? 0.014 us/op # digit2_unsafe Benchmark (size) Mode Cnt Score Error Units Integers.parseInt 500 avgt 15 2.244 ? 0.010 us/op Longs.parseLong 500 avgt 15 2.432 ? 0.033 us/op * Comparison | benchmark | master | digit2 | digit2_unsafe | master vs digit2 | digit2 vs digit2_unsafe | |-----------|--------|--------|---------------|------------------|------------------------| | Integers.parseInt | 2.541 | 2.542 | 2.244 | -0.04% | 13.28% | | Longs.parseLong | 2.941 | 2.527 | 2.432 | 16.38% | 3.91% | ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-3612587178 From rgiulietti at openjdk.org Thu Dec 4 14:49:27 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 4 Dec 2025 14:49:27 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v24] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 14:42:32 GMT, Shaojin Wen wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove unsafe > > In my latest implementation, I removed `Unsafe` from the `DecimalDigits::digit2` method, which resulted in a performance decrease, but it's still better than the master branch. Below are my performance tests on x64 and aarch64: > > > # 1. Test Script > > git remote add wenshao git at github.com:wenshao/jdk.git > git fetch wenshao > > # base (master banch) > git checkout 9ea0dcd3eaf07658aeb92ba0defb5098e1f7b192 > make test TEST="micro:java.lang.Longs.parseLong" > make test TEST="micro:java.lang.Integers.parseInt" > > # Digit2 (current) > git checkout cebefd7b89f2dbf29bb13c4903060707a5574e67 > make test TEST="micro:java.lang.Longs.parseLong" > make test TEST="micro:java.lang.Integers.parseInt" > > # Digit2_Unsafe (before) > git checkout c58aa7071867f386407f33defe2b346176fc1e91 > make test TEST="micro:java.lang.Longs.parseLong" > make test TEST="micro:java.lang.Integers.parseInt" > > > # 2. Performance Results on MacBook M1 Pro > > * Raw Data > > # base > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.371 ? 0.012 us/op > Longs.parseLong 500 avgt 15 2.731 ? 0.030 us/op > > # digit2 > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.221 ? 0.009 us/op > Longs.parseLong 500 avgt 15 2.517 ? 0.016 us/op > > # digit2_unsafe > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.114 ? 0.012 us/op > Longs.parseLong 500 avgt 15 2.344 ? 0.028 us/op > > > * Comparison > > | Benchmark | base | Digit2 | Digit2_Unsafe | base vs Digit2 (%) | Digit2 vs Digit2_Unsafe (%) | > |-----------|--------|--------|---------------|----------------------|------------------------------| > | Integers.parseInt | 2.371 | 2.221 | 2.114 | +6.33% | +4.82% | > | Longs.parseLong | 2.731 | 2.517 | 2.344 | +7.84% | +6.87% | > > > # 3. Performance Results on Aliyun_ECS_c9a (x64, AMD AMD EPYC? Turin) > > * Row Data > > # base > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.541 ? 0.022 us/op > Longs.parseLong 500 avgt 15 2.941 ? 0.014 us/op > > # digit2 > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.542 ? 0.003 us/op > Longs.parseLong 500 avgt 15 2.527 ? 0.014 us/op > > # digit2_unsafe > Benchmark (size) Mode Cnt Score Error Units > Integers.parseInt 500 avgt 15 2.244 ? 0.010 us/op > Longs.parseLong 500 avgt 15 2.432 ? 0.033 us/op > > > * Comparison > > | benchmark |... Thanks @wenshao for trying out without making use of `Unsafe`! I'll have another look sometimes next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-3612606581 From duke at openjdk.org Thu Dec 4 14:59:33 2025 From: duke at openjdk.org (jengebr) Date: Thu, 4 Dec 2025 14:59:33 GMT Subject: RFR: 8371656: HashMap.putAll() optimizations [v3] In-Reply-To: References: Message-ID: > # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks > > ## Summary > > This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used. > > ## Problem Context > > ### Megamorphic Call Site Overhead in Map Iteration > `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types: > > 1. `m.entrySet()` becomes megamorphic across different map implementations > 2. `entrySet().iterator()` creates different iterator types > 3. `entry.getKey()` and `entry.getValue()` calls vary by map type > 4. Individual `putVal()` calls for each entry > > When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization. > > ## Optimized Methods > > ### HashMap > - **`putMapEntries(Map m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying > - **`putMapEntries(HashMap src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing. Avoids polymorphic issues and eliminates redundant calls to HashMap.hash(). > > ## Implementation Details > > ### HashMap-to-HashMap Fast Path > Directly iterates over `src.table` to eliminate entrySet() allocation and polymorphic iterator calls, using the internal Node structure for maximum efficiency. > > ### UnmodifiableMap Unwrapping > Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access. > > ## Performance Impact > > | Source Type | Size | Poisoned | Baseline | Optimized | Improvement | > |-------------|------|----------|----------|-----------|-------------| > | HashMap | 0 | true | 9.429 ns/op | 8.875 ns/op |... jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge branch 'openjdk:master' into putMapEntriesOptimizations - Unit test revisions - Bug fix & unit test - fixing whitespace - Optimizing HashMap.putAll() and . for HashMap and C$UM ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28243/files - new: https://git.openjdk.org/jdk/pull/28243/files/edfc6a2f..1b09326c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28243&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28243&range=01-02 Stats: 278820 lines in 2741 files changed: 185925 ins; 52931 del; 39964 mod Patch: https://git.openjdk.org/jdk/pull/28243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28243/head:pull/28243 PR: https://git.openjdk.org/jdk/pull/28243 From stuefe at openjdk.org Thu Dec 4 15:04:51 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Thu, 4 Dec 2025 15:04:51 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v3] In-Reply-To: References: <3GE775UHXUoDMOLKl9C7Ao52gXf3U-_cfiC5ruJBz2w=.66997f1e-6dce-4803-903a-a787b3496183@github.com> Message-ID: <6t_cgEV2UcFEf5C148g7aIj9AObCmwJI_YMfJ_s7VUs=.6681d5cc-4c69-46dd-9d17-89a2d2d723ea@github.com> On Thu, 4 Dec 2025 14:39:39 GMT, Andrew Haley wrote: >> After thinking about this, I got confused. Should heap archiving not actually depend on CompressedOops, too, in addition to CompressedClassPointers? Otherwise we would have the heap region at runtime at exactly the same address as at compile time... >> >> That would be a preexisting bug. It may just be one of the old "UseCompressedClassPointers is tied to UseCompressedOops" bugs. But if true, we would have seen CDT crashes e.g. with G1 and heaps > 32g. >> >> I'll take a look. > > Sorry, my mistake. Just compressed CP. Maybe just delete the comment, which violates > > Rule 1: Comments should not duplicate the code Ashu just reminded me that we do relocate uncompressed oops when loading the CDS archive at runtime. We never got around to do that for uncompressed Klass pointers in object headers, and it was also never really necessary. So you are right, the comment should either just be removed or explain the G1 restriction. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2589430925 From smonteith at openjdk.org Thu Dec 4 16:24:25 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Thu, 4 Dec 2025 16:24:25 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3613061007 From nbenalla at openjdk.org Thu Dec 4 17:06:54 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Thu, 4 Dec 2025 17:06:54 GMT Subject: Integrated: 8370890: Start of release updates for JDK 27 In-Reply-To: References: Message-ID: On Tue, 4 Nov 2025 11:45:04 GMT, Nizar Benalla wrote: > Get JDK 27 underway. This pull request has now been integrated. Changeset: c55287d1 Author: Nizar Benalla Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/c55287d197ef024033f8dfbb5a365cb091bc67fb Stats: 1233 lines in 50 files changed: 1157 ins; 0 del; 76 mod 8370890: Start of release updates for JDK 27 8370893: Add SourceVersion.RELEASE_27 8370894: Add source 27 and target 27 to javac Reviewed-by: darcy, iris, liach, erikj, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28130 From vklang at openjdk.org Thu Dec 4 17:41:48 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 4 Dec 2025 17:41:48 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v6] In-Reply-To: References: Message-ID: On Wed, 3 Dec 2025 18:58:26 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Fix test test/jdk/java/util/EnumSet/EnumSetSpliteratorTest.java line 66: > 64: assertSpliteratorCharacteristics(EnumSet.allOf(Empty.class)); > 65: assertSpliteratorCharacteristics(EnumSet.allOf(Small.class)); > 66: assertSpliteratorCharacteristics(EnumSet.allOf(Large.class)); For the sake of completeness, it probably makes sense to test the characteristics of `EnumSet.of(?)`, `EnumSet.range(?)`, and `EnumSet.noneOf(?)` as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28568#discussion_r2589995448 From jlu at openjdk.org Thu Dec 4 18:38:57 2025 From: jlu at openjdk.org (Justin Lu) Date: Thu, 4 Dec 2025 18:38:57 GMT Subject: Integrated: 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 23:51:11 GMT, Justin Lu wrote: > This PR updates the call sites of `TestUtils::usesGregorianCalendar`, `TestUtils::usesAsciiDigits`, and `TestUtils::hasSpecialVariant` to use `Assumptions` to properly abort the test. > > The existing usage of these methods involve printing to output and returning when locale conditions are not met. Some of these tests do lots of printing, so identifying when a test is skipped due to inadequate locale conditions may not be obvious. Instead of simply printing to output, it would be better for test diagnostics to abort the tests, which is easy to identify in the Jtreg output. E.g. > >> [ JUnit Tests: found 1189, started 1189, succeeded 1185, failed 0, aborted 4, skipped 0] > > As a result of this change, Bug4407042, Bug4845901, Bug6530336, and LocaleCategory were converted to JUnit based tests. (I could have decided to throw jtreg.SkippedException for those tests, but decided to just convert as well.) This pull request has now been integrated. Changeset: c7aa1033 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/c7aa10339aa40d37dc52e6dcec102f8dca114634 Stats: 223 lines in 12 files changed: 45 ins; 90 del; 88 mod 8372844: Improve usage of test/jdk/java/text/testlib/TestUtils.java locale methods Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/28590 From bchristi at openjdk.org Thu Dec 4 20:05:15 2025 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 4 Dec 2025 20:05:15 GMT Subject: RFR: 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method [v2] In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 20:19:24 GMT, Brent Christian wrote: >> From the bug report: >> Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to >> "[invoke] shutdown() when this executor is no longer referenced and it has no threads." >> >> In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)). >> >> In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)). >> >> The finalize() method can safely be removed from ThreadPoolExecutor. > > Brent Christian 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 8371748-TPE.f10n > - Remove ThreadPoolExecutor.finalize() Thanks, Jai - RN updated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28311#issuecomment-3614118183 From duke at openjdk.org Thu Dec 4 21:28:30 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 4 Dec 2025 21:28:30 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v3] In-Reply-To: References: Message-ID: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8370688: Addressed review comments-moved the sentence to return label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28615/files - new: https://git.openjdk.org/jdk/pull/28615/files/59abe38b..d53fe8ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28615.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28615/head:pull/28615 PR: https://git.openjdk.org/jdk/pull/28615 From duke at openjdk.org Thu Dec 4 22:37:34 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Thu, 4 Dec 2025 22:37:34 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: Add coverage for other factory methods: noneOf, of, etc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28568/files - new: https://git.openjdk.org/jdk/pull/28568/files/98bcd8b4..adb01836 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28568&range=05-06 Stats: 9 lines in 1 file changed: 8 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28568.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28568/head:pull/28568 PR: https://git.openjdk.org/jdk/pull/28568 From darcy at openjdk.org Fri Dec 5 05:21:25 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 5 Dec 2025 05:21:25 GMT Subject: RFR: 8373125: Add defensive screening of modifiers for Field and Parameter toString() results Message-ID: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> The modifiers in core reflection and just modeled using the bits of an int. For methods and constructors, there are collisions on the reuse of modifier bits on different kinds of constructs. Printing misleading information is avoid by masking out the modfiers using information from the Modifer class. While Field and Parameter don't currently have such collisions, they may under Valhalla and adding defensive screenings now would add robustness. ------------- Commit messages: - JDK-8373125: Add defensive screening of modifiers for Field and Parameter toString() results Changes: https://git.openjdk.org/jdk/pull/28672/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28672&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373125 Stats: 52 lines in 3 files changed: 35 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/28672.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28672/head:pull/28672 PR: https://git.openjdk.org/jdk/pull/28672 From erfang at openjdk.org Fri Dec 5 08:13:19 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 5 Dec 2025 08:13:19 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v3] In-Reply-To: References: Message-ID: > `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. > 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. > > This PR does the following optimizations: > 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. > 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th... Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Refine the test code and comments - Merge branch 'master' into JDK-8370863-mask-cast-opt - Don't read and write the same memory in the JMH benchmarks - Merge branch 'master' into JDK-8370863-mask-cast-opt - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. Current optimizations related to `VectorMaskCastNode` include: 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. This PR does the following optimizations: 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as the vector length remains the same, and this is guranteed in the api level. I conducted some simple research on different mask generation methods and mask operations, and obtained the following table, which includes some potential optimization opportunities that may use this `uncast_mask` function. ``` mask_gen\op toLong anyTrue allTrue trueCount firstTrue lastTrue compare N/A N/A N/A N/A N/A N/A maskAll TBI TBI TBI TBI TBI TBI fromLong TBI TBI N/A TBI TBI TBI mask_gen\op and or xor andNot not laneIsSet compare N/A N/A N/A N/A TBI N/A maskAll TBI TBI TBI TBI TBI TBI fromLong N/A N/A N/A N/A TBI TBI ``` `TBI` indicated that there may be potential optimizations here that require further investigation. Benchmarks: On a Nvidia Grace machine with 128-bit SVE2: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 59.23 0.21 148.12 0.07 2.50 microMaskLoadCastStoreDouble128 ops/us 2.43 0.00 38.31 0.01 15.73 microMaskLoadCastStoreFloat128 ops/us 6.19 0.00 75.67 0.11 12.22 microMaskLoadCastStoreInt128 ops/us 6.19 0.00 75.67 0.03 12.22 microMaskLoadCastStoreLong128 ops/us 2.43 0.00 38.32 0.01 15.74 microMaskLoadCastStoreShort64 ops/us 28.89 0.02 75.60 0.09 2.62 ``` On a Nvidia Grace machine with 128-bit NEON: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 75.75 0.19 149.74 0.08 1.98 microMaskLoadCastStoreDouble128 ops/us 8.71 0.03 38.71 0.05 4.44 microMaskLoadCastStoreFloat128 ops/us 24.05 0.03 76.49 0.05 3.18 microMaskLoadCastStoreInt128 ops/us 24.06 0.02 76.51 0.05 3.18 microMaskLoadCastStoreLong128 ops/us 8.72 0.01 38.71 0.02 4.44 microMaskLoadCastStoreShort64 ops/us 24.64 0.01 76.43 0.06 3.10 ``` On an AMD EPYC 9124 16-Core Processor with AVX3: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 82.13 0.31 115.14 0.08 1.40 microMaskLoadCastStoreDouble128 ops/us 0.32 0.00 0.32 0.00 1.01 microMaskLoadCastStoreFloat128 ops/us 42.18 0.05 57.56 0.07 1.36 microMaskLoadCastStoreInt128 ops/us 42.19 0.01 57.53 0.08 1.36 microMaskLoadCastStoreLong128 ops/us 0.30 0.01 0.32 0.00 1.05 microMaskLoadCastStoreShort64 ops/us 42.18 0.05 57.59 0.01 1.37 ``` On an AMD EPYC 9124 16-Core Processor with AVX2: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 73.53 0.20 114.98 0.03 1.56 microMaskLoadCastStoreDouble128 ops/us 0.29 0.01 0.30 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 30.78 0.14 57.50 0.01 1.87 microMaskLoadCastStoreInt128 ops/us 30.65 0.26 57.50 0.01 1.88 microMaskLoadCastStoreLong128 ops/us 0.30 0.00 0.30 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 24.92 0.00 57.49 0.01 2.31 ``` On an AMD EPYC 9124 16-Core Processor with AVX1: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 79.68 0.01 248.49 0.91 3.12 microMaskLoadCastStoreDouble128 ops/us 0.28 0.00 0.28 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 31.11 0.04 95.48 2.27 3.07 microMaskLoadCastStoreInt128 ops/us 31.10 0.03 99.94 1.87 3.21 microMaskLoadCastStoreLong128 ops/us 0.28 0.00 0.28 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 31.11 0.02 94.97 2.30 3.05 ``` This PR was tested on 128-bit, 256-bit, and 512-bit (QEMU) aarch64 environments, and two 512-bit x64 machines with various configurations, including sve2, sve1, neon, avx3, avx2, avx1, sse4 and sse3, all tests passed. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28313/files - new: https://git.openjdk.org/jdk/pull/28313/files/3b0ff7d6..c04039ce Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=01-02 Stats: 64625 lines in 1066 files changed: 42561 ins; 15516 del; 6548 mod Patch: https://git.openjdk.org/jdk/pull/28313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313 PR: https://git.openjdk.org/jdk/pull/28313 From erfang at openjdk.org Fri Dec 5 08:13:20 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 5 Dec 2025 08:13:20 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v3] In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 08:10:32 GMT, Eric Fang wrote: >> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. >> >> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: >> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` >> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. >> >> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. >> >> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. >> >> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. >> >> Current optimizations related to `VectorMaskCastNode` include: >> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. >> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. >> >> This PR does the following optimizations: >> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. >> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect... > > Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Refine the test code and comments > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Don't read and write the same memory in the JMH benchmarks > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns > > `VectorMaskCastNode` is used to cast a vector mask from one type to > another type. The cast may be generated by calling the vector API `cast` > or generated by the compiler. For example, some vector mask operations > like `trueCount` require the input mask to be integer types, so for > floating point type masks, the compiler will cast the mask to the > corresponding integer type mask automatically before doing the mask > operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` > don't generate code, otherwise code will be generated to extend or narrow > the mask. This IR node is not free no matter it generates code or not > because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` > The middle `VectorMaskCast` prevented the following optimization: > `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which > blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we > can safely do the optimization. But if the input value is changed, we > can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper > function, which can be used to uncast a chain of `VectorMaskCastNode`, > like the existing `Node::uncast(bool)` function. The funtion returns > the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may > contain one or more consecutive `VectorMaskCastNode` and this does not > affect the correctness of the optimization. Then this function can be > called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. > 2. `(XorV... Thanks for your review! @galderz ------------- PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3537647873 From erfang at openjdk.org Fri Dec 5 08:13:24 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 5 Dec 2025 08:13:24 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v2] In-Reply-To: References: <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com> Message-ID: On Fri, 28 Nov 2025 09:09:28 GMT, Galder Zamarre?o wrote: >> Eric Fang 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: >> >> - Don't read and write the same memory in the JMH benchmarks >> - Merge branch 'master' into JDK-8370863-mask-cast-opt >> - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns >> >> `VectorMaskCastNode` is used to cast a vector mask from one type to >> another type. The cast may be generated by calling the vector API `cast` >> or generated by the compiler. For example, some vector mask operations >> like `trueCount` require the input mask to be integer types, so for >> floating point type masks, the compiler will cast the mask to the >> corresponding integer type mask automatically before doing the mask >> operation. This kind of cast is very common. >> >> If the vector element size is not changed, the `VectorMaskCastNode` >> don't generate code, otherwise code will be generated to extend or narrow >> the mask. This IR node is not free no matter it generates code or not >> because it may block some optimizations. For example: >> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` >> The middle `VectorMaskCast` prevented the following optimization: >> `(VectorStoremask (VectorLoadMask x)) => (x)` >> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which >> blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. >> >> In these IR patterns, the value of the input `x` is not changed, so we >> can safely do the optimization. But if the input value is changed, we >> can't eliminate the cast. >> >> The general idea of this PR is introducing an `uncast_mask` helper >> function, which can be used to uncast a chain of `VectorMaskCastNode`, >> like the existing `Node::uncast(bool)` function. The funtion returns >> the first non `VectorMaskCastNode`. >> >> The intended use case is when the IR pattern to be optimized may >> contain one or more consecutive `VectorMaskCastNode` and this does not >> affect the correctness of the optimization. Then this function can be >> called to eliminate the `VectorMaskCastNode` chain. >> >> Current optimizations related to `VectorMaskCastNode` include: >> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. >> 2. `(XorV (VectorMa... > > src/hotspot/share/opto/vectornode.cpp line 1056: > >> 1054: // x remains to be a bool vector with no changes. >> 1055: // This function can be used to eliminate the VectorMaskCast in such patterns. >> 1056: Node* VectorNode::uncast_mask(Node* n) { > > Could this be a static method instead? Yeah it's already a static method. See https://github.com/openjdk/jdk/pull/28313/files#diff-ba9e2d10a50a01316946660ec9f68321eb864fd9c815616c10abbec39360efe5R141 Or you mean a static method limited to this file ? If so, I prefer not, it may be used at other places. Thanks~ > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 57: > >> 55: applyIfCPUFeatureAnd = {"asimd", "true", "sve", "false"}) >> 56: public static int testTwoCastToDifferentType() { >> 57: // The types before and after the two casts are not the same, so the cast cannot be eliminated. > > Outdated comment. Also please expand assertion comments Done, thanks! > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 79: > >> 77: applyIfCPUFeatureAnd = {"avx2", "true", "avx512", "false"}) >> 78: public static int testTwoCastToDifferentType2() { >> 79: // The types before and after the two casts are not the same, so the cast cannot be eliminated. > > Could you expand the documentation on the IR assertions? It's not immediately clear why with AVX-512 the cast remains but with AVX-2 it's removed. Also, this comment is outdated. This is because the following optimization on AVX2 affects this optimization: `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => x` On AVX2 `trueCount()` requires converting the mask to a **boolean vector** first via `VectorStoreMask`. So `VectorStoreMask` can apply the above optimization, which eliminates all `VectorMaskCast `nodes as a side effect. On AVX-512, masks use dedicated mask registers (k registers), `VectorStoreMask` is not generated for `trueCount()`, so `VectorMaskCast` nodes remain. I reorganised this file, please take another look, thanks~ > test/hotspot/jtreg/compiler/vectorapi/VectorMaskToLongTest.java line 240: > >> 238: >> 239: @Test >> 240: @IR(counts = { IRNode.VECTOR_LONG_TO_MASK, "= 0", > > Could you add some assertion comments here as well to understand what causes the differences with different architectures? Done > test/hotspot/jtreg/compiler/vectorapi/VectorMaskToLongTest.java line 260: > >> 258: >> 259: @Test >> 260: @IR(counts = { IRNode.VECTOR_LONG_TO_MASK, "= 0", > > Same here Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2587209533 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2587250313 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2587250610 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2587250972 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2587251084 From erfang at openjdk.org Fri Dec 5 09:14:41 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 5 Dec 2025 09:14:41 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v4] In-Reply-To: References: Message-ID: > `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. > 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. > > This PR does the following optimizations: > 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. > 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th... Eric Fang has updated the pull request incrementally with one additional commit since the last revision: Add MaxVectorSize IR test condition for VectorStoreMaskIdentityTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28313/files - new: https://git.openjdk.org/jdk/pull/28313/files/c04039ce..aa9a08a9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=02-03 Stats: 18 lines in 1 file changed: 6 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313 PR: https://git.openjdk.org/jdk/pull/28313 From bkilambi at openjdk.org Fri Dec 5 10:55:01 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 5 Dec 2025 10:55:01 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Cleanups src/hotspot/share/opto/vectorIntrinsics.cpp line 341: > 339: laneType == nullptr || !laneType->is_con() || > 340: vector_klass == nullptr || vector_klass->const_oop() == nullptr || > 341: laneType == nullptr || !laneType->is_con() || is this repeating the same condition on line 339? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2592254926 From per-ake.minborg at oracle.com Fri Dec 5 11:05:49 2025 From: per-ake.minborg at oracle.com (Per-Ake Minborg) Date: Fri, 5 Dec 2025 11:05:49 +0000 Subject: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: Hi David, Thank you for trying out LazyConstant and providing feedback. That is precisely what previews are for! If you take a closer look at the specification of LazyConstant::orElse, it says that the method will never trigger initialization. And so, you can actually be sure that in your first example, foo is always initialized to "hello" (if ever initialized). It is only if foo is not initialized that the method will return "hello2" (again, without initializing foo). This is similar to how Optional works. It would be possible to entirely remove the orElse() method from the API, and in the rare cases where an equivalent functionality is called for, rely on LazyConstant::isInitialized instead. Best, Per Confidential- Oracle Internal ________________________________ From: amber-dev on behalf of david Grajales Sent: Friday, December 5, 2025 5:38 AM To: amber-dev ; core-libs-dev at openjdk.org Subject: Feedback about LazyConstants API (JEP526) Dear Java Dev Team, I am writing to provide feedback and two specific observations regarding the LazyConstant API, which is currently a preview feature in OpenJDK 26. I appreciate the API's direction and I think it's a good improvement compared to its first iteration; however, I see potential for improved expressiveness, particularly in conditional scenarios. 1. Proposal: Zero-Parameter `LazyConstant.of()` Overload: Currently, the mandatory use of a factory method receiving a `Supplier` (due to the lack of a public constructor) can obscure the expressiveness of conditional or multiple-value initialization paths. **The Issue:** When looking at the declaration: LazyConstant foo = LazyConstant.of(() -> "hello"); the code gives the strong, immediate impression that the value is always initialized to "hello". This makes it difficult to infer that the constant might ultimately resolve to an alternative value set later via orElse() or another conditional path, especially when skimming the code: LazyConstant foo = LazyConstant.of(() -> "hello"); // When skimming the code it's not always obvious that this may not be the actual value void main() { if (someCondition()) { foo.get(); // Trigger initialization to "hello" } // If someCondition is false, the final value of foo is determined here: var res1 = foo.orElse("hello2"); // ... } My Suggestion: I propose introducing a zero-parameter overloaded static factory method of(): LazyConstant foo = LazyConstant.of(); This form explicitly communicates that the constant is initialized to an unresolved state, suggesting that the value will be determined downstream by the first invocation of an initialization/computation method. LazyConstant foo = LazyConstant.of(); // Clearly unresolved void main() { if (someCondition()) { foo.orElse("hello"); } var res1 = foo.orElse("hello2"); // ... } This is specially useful for clarity when one has conditional initialization in places such as the constructor of a class. For example private class Bar{ LazyConstant foo = LazyConstant.of(); private Bar(Some some){ if(some.condition()){ foo.orElse("foo"); } foo.orElse("foo2"); } String computeValue() { return "hello"; } String computeValue2(){ return "hello2"; } } 2. Method Naming Suggestion and and supplier in instance method for consistency in the API My second, much more minor observation relates to the instance method orElse(T t). While orElse fits a retrieval pattern, I personally feel that compute or computeIfAbsent would better express the intent of this method, as its primary function is not just to retrieve, but to trigger the computation and set the final value of the constant if it is currently uninitialized. Also, as the factory of() has a supplier i think this instance method should also receive a Supplier, This not only keeps the API consistent in the usage but makes more ergonomic the declaration of complex initialization logic inside the method. private class Bar{ LazyConstant foo = LazyConstant.of(InitParam::default); // Under the current API this is mandatory but in reality the value is set in the constructor, default is never really used. private Bar(Some some){ foo.compute(some::executeCallToCacheDBAndBringInitializationParams) //Real configuration happens here } } This last it's very common for initialization of configuration classes and singletons. Thank you so much for your attention, I hope you find this feedback useful. Always yours. David Grajales -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernee at openjdk.org Fri Dec 5 11:10:27 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 5 Dec 2025 11:10:27 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v7] In-Reply-To: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com> References: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com> Message-ID: On Thu, 4 Dec 2025 01:48:31 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure Latest version looks much better to me (as mentioned offline). What was the issue with the failing test around the removal of the _V guard template? Also, looks like the new IR test is failing in GHA test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 48: > 46: public static void main(String[] args) { > 47: TestFramework.runWithFlags( > 48: "-XX:+UnlockExperimentalVMOptions" Why is this flag needed? ------------- PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3544230655 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2592287594 From mullan at openjdk.org Fri Dec 5 13:51:29 2025 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 5 Dec 2025 13:51:29 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 21:28:30 GMT, Koushik Muthukrishnan Thirupattur wrote: >> The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. > > Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: > > 8370688: Addressed review comments-moved the sentence to return label src/java.base/share/classes/java/util/jar/JarEntry.java line 118: > 116: * > 117: * @return the {@code Certificate} objects for this entry, or > 118: * {@code null} if none. If non-null, this method returns a new I think you can remove the "this method" words as it is implied by being in the "@return". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28615#discussion_r2592754088 From davidalayachew at gmail.com Fri Dec 5 13:51:46 2025 From: davidalayachew at gmail.com (David Alayachew) Date: Fri, 5 Dec 2025 08:51:46 -0500 Subject: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: Caveat -- I have only used the Java 25 version of this library. I agree that the name orElse() is not intuitive. It was made more intuitive by the existence of orElseSet(). In its absence, changing the name makes sense. Though, I'm definitely open to just removing the method. This is easy enough to accomplish ourselves. Would prefer a rename though. On Fri, Dec 5, 2025, 8:32?AM Red IO wrote: > Hi David, > As par already said the orElse method doesn't initializes the > LazyConstant. > It just checks rather the value is init and if not calls the supplier to > get a substitute for the missing constant. > Example: > LazyConstant x = LazyConstant.of(() -> "Const"); > var uninit1 = x.orElse(() -> "substitute 1"); > var uninit2 = x.orElse(() -> "substitute 2"); > var init1 = x.get(); > var init2 = x.orElse(() -> "substitute 3"); > uninit1 and uninit2 get the substitute 1/2 > And init1 and init2 get Const. > > This is surprising if you expect it to be a way to init it with an > alternative value. > > My suggestion would to make the separation clear and allow for another use > case by spliting this api in 2 parts: > One class LazyConstant > Takes a Supplier in static factory and exposes get() > > And > Class LazyInit > Which takes no arguments in the static factory and takes a supplier in the > get method that gets called when get is called for the first time. > In this case the source for the constant can be any piece of code that has > access to the LazyConstant. This might be desired in some cases. In cases > where it's not the other version can be used. > > This split makes it clear from which context the constant is initialized > from (consumer or at declaration) > > Mixing those 2 or having methods that appear to do this is rather > confusing. > > > > One solution for the "i might not want to init the constant" case the > "orElse" method is meant to be is to have a method "tryGet" which returns > Optional instead. This makes it clear that the value might not be there and > is not initialized when calling the method. Nobody expects to init the > constant when calling orElse on a returned Optional. > > My 2 suggestions here are completely independent and should be viewed as > such. > > Great regards > RedIODev > > On Fri, Dec 5, 2025, 13:55 david Grajales > wrote: > >> HI Per. I pleasure to talk with you. >> >> You are right about one thing but this actually makes the API less >> intuitive and harder to read and reason about. >> >> LazyConstant foo = LazyConstant.of(() -> "hello"); >> >> void main() { >> if (someCondition()) {// asume false >> foo.get(); >> } >> foo.orElse("hello2"); // ... >> >> println(foo.get()); // This prints "hello" >> } >> >> But if one assigns foo.orElse("hello2") to a variable, the variable >> actually gets the "hello2" value. >> >> void main() { >> if (someCondition()) {// asume false >> foo.get(); >> } >> var res = foo.orElse("hello2"); // ... >> var res2 = foo.orElse("hello3"); >> println(res); // This prints "hello2" >> println(res2);//This prints "hello3" >> } >> >> This is actually even more confusing and makes the API more error prone. >> I personally think once initialized the lazy constant should always return >> the same value (maybe through the .get() method only), and there should not >> be any possibility of getting a different values from the same instance >> either in the .of() static method or in any hypothetical instance method >> for conditional downstream logic. I guess one could achieve the latter >> with the static factory method through something like this (although less >> elegant) >> >> private class Bar{ >> private final LazyConstant foo; >> private Bar(Some some){ >> >> if(some.condition){ >> foo = LazyConstant.of(() -> "hello"); >> }else { >> foo = LazyConstant.of(() -> "hello2"); >> } >> } >> } >> >> Thank you for reading. This is all I have to report. >> >> Best regards. >> >> >> >> El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg ( >> per-ake.minborg at oracle.com) escribi?: >> >>> Hi David, >>> >>> Thank you for trying out LazyConstant and providing feedback. That is >>> precisely what previews are for! >>> >>> If you take a closer look at the specification of LazyConstant::orElse, it >>> says that the method will *never trigger initialization.* And so, you >>> *can* actually be sure that in your first example, foo is always >>> initialized to "hello" (if ever initialized). It is only if foo is not >>> initialized that the method will return "hello2" (again, without >>> initializing foo). This is similar to how Optional works. >>> >>> It would be possible to entirely remove the orElse() method from the >>> API, and in the rare cases where an equivalent functionality is called for, >>> rely on LazyConstant::isInitialized instead. >>> >>> Best, Per >>> >>> >>> Confidential- Oracle Internal >>> ------------------------------ >>> *From:* amber-dev on behalf of david >>> Grajales >>> *Sent:* Friday, December 5, 2025 5:38 AM >>> *To:* amber-dev ; core-libs-dev at openjdk.org < >>> core-libs-dev at openjdk.org> >>> *Subject:* Feedback about LazyConstants API (JEP526) >>> >>> Dear Java Dev Team, >>> >>> I am writing to provide feedback and two specific observations >>> regarding the LazyConstant API, which is currently a preview feature in >>> OpenJDK 26. >>> >>> I appreciate the API's direction and I think it's a good improvement >>> compared to its first iteration; however, I see potential for improved >>> expressiveness, particularly in conditional scenarios. >>> >>> >>> *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* >>> >>> Currently, the mandatory use of a factory method receiving a `Supplier` >>> (due to the lack of a public constructor) can obscure the expressiveness of >>> conditional or multiple-value initialization paths. **The Issue:** When >>> looking at the declaration: >>> >>> LazyConstant foo = LazyConstant.of(() -> "hello"); >>> >>> the code gives the strong, immediate impression that the value is >>> *always* initialized to "hello". This makes it difficult to infer that >>> the constant might ultimately resolve to an alternative value set later via >>> orElse() or another conditional path, especially when skimming the code: >>> >>> LazyConstant foo = LazyConstant.of(() -> "hello"); // When >>> skimming the code it's not always obvious that this may not be the actual >>> value >>> >>> void main() { >>> if (someCondition()) { >>> foo.get(); // Trigger initialization to "hello" >>> } >>> // If someCondition is false, the final value of foo is determined >>> here: >>> var res1 = foo.orElse("hello2"); // ... >>> } >>> >>> *My Suggestion:* I propose introducing a *zero-parameter overloaded >>> static factory method* of(): >>> >>> LazyConstant foo = LazyConstant.of(); >>> >>> This form explicitly communicates that the constant is initialized to an * >>> unresolved* state, suggesting that the value will be determined >>> downstream by the first invocation of an initialization/computation method. >>> >>> LazyConstant foo = LazyConstant.of(); // Clearly unresolved >>> void main() { >>> if (someCondition()) { >>> foo.orElse("hello"); >>> } >>> var res1 = foo.orElse("hello2"); // ... >>> } >>> >>> This is specially useful for clarity when one has conditional >>> initialization in places such as the constructor of a class. For example >>> >>> private class Bar{ >>> LazyConstant foo = LazyConstant.of(); >>> private Bar(Some some){ >>> if(some.condition()){ >>> foo.orElse("foo"); >>> } >>> foo.orElse("foo2"); >>> } >>> >>> String computeValue() { >>> return "hello"; >>> } >>> >>> String computeValue2(){ >>> return "hello2"; >>> } >>> } >>> 2. Method Naming Suggestion and and supplier in instance method for >>> consistency in the API >>> >>> My second, much more minor observation relates to the instance method orElse(T >>> t). >>> >>> While orElse fits a retrieval pattern, I personally feel that * compute* >>> or *computeIfAbsent* would better express the intent of this method, as >>> its primary function is not just to retrieve, but to trigger the >>> computation and *set the final value* of the constant if it is >>> currently uninitialized. Also, as the factory of() has a supplier i think >>> this instance method should also receive a Supplier, This not only keeps >>> the API consistent in the usage but makes more ergonomic the declaration of >>> complex initialization logic inside the method. >>> >>> >>> private class Bar{ >>> LazyConstant foo = LazyConstant.of(InitParam::default); >>> // Under the current API this is mandatory but in reality the value is set >>> in the constructor, default is never really used. >>> private Bar(Some some){ >>> >>> foo.compute(some::executeCallToCacheDBAndBringInitializationParams) //Real >>> configuration happens here >>> >>> } >>> } >>> >>> This last it's very common for initialization of configuration classes >>> and singletons. >>> >>> >>> Thank you so much for your attention, I hope you find this feedback >>> useful. >>> >>> Always yours. David Grajales >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From vklang at openjdk.org Fri Dec 5 14:09:35 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 5 Dec 2025 14:09:35 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 22:37:34 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Add coverage for other factory methods: noneOf, of, etc Thanks for this, @kilink! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28568#pullrequestreview-3544920190 From roger.riggs at oracle.com Fri Dec 5 14:35:18 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Fri, 5 Dec 2025 09:35:18 -0500 Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects In-Reply-To: References: Message-ID: Vote: Yes On 11/21/25 1:37 AM, Alan Bateman wrote: > I hereby propose that the Core Libraries group withdraw sponsorship of > the Device I/O [1], Kona [2], Penrose [3], and Verona [4] projects. From bkilambi at openjdk.org Fri Dec 5 14:45:10 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 5 Dec 2025 14:45:10 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) Message-ID: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation. For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass. The SVE path is enabled by default for int type. For float type, it is available through the experimental flag : `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP ` Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default). Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1. Following are the performance numbers for **ArraysSort JMH benchmark** - **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default). **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats). **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).** On Neoverse V1: Benchmark (size) Mode Cnt A B ArraysSort.floatParallelSort 10 avgt 3 0.98 0.98 ArraysSort.floatParallelSort 25 avgt 3 1.01 0.83 ArraysSort.floatParallelSort 50 avgt 3 0.99 0.55 ArraysSort.floatParallelSort 75 avgt 3 0.99 0.66 ArraysSort.floatParallelSort 100 avgt 3 0.98 0.66 ArraysSort.floatParallelSort 1000 avgt 3 1.00 0.84 ArraysSort.floatParallelSort 10000 avgt 3 1.03 1.52 ArraysSort.floatParallelSort 100000 avgt 3 1.03 1.46 ArraysSort.floatParallelSort 1000000 avgt 3 0.98 1.81 ArraysSort.floatSort 10 avgt 3 1.00 0.98 ArraysSort.floatSort 25 avgt 3 1.00 0.81 ArraysSort.floatSort 50 avgt 3 0.99 0.56 ArraysSort.floatSort 75 avgt 3 0.99 0.65 ArraysSort.floatSort 100 avgt 3 0.98 0.70 ArraysSort.floatSort 1000 avgt 3 0.99 0.84 ArraysSort.floatSort 10000 avgt 3 0.99 1.72 ArraysSort.floatSort 100000 avgt 3 1.00 1.94 ArraysSort.floatSort 1000000 avgt 3 1.00 2.13 ArraysSort.intParallelSort 10 avgt 3 1.08 1.08 ArraysSort.intParallelSort 25 avgt 3 1.04 1.05 ArraysSort.intParallelSort 50 avgt 3 1.29 1.30 ArraysSort.intParallelSort 75 avgt 3 1.16 1.16 ArraysSort.intParallelSort 100 avgt 3 1.07 1.07 ArraysSort.intParallelSort 1000 avgt 3 1.13 1.13 ArraysSort.intParallelSort 10000 avgt 3 1.49 1.38 ArraysSort.intParallelSort 100000 avgt 3 1.64 1.62 ArraysSort.intParallelSort 1000000 avgt 3 2.26 2.27 ArraysSort.intSort 10 avgt 3 1.08 1.08 ArraysSort.intSort 25 avgt 3 1.02 1.02 ArraysSort.intSort 50 avgt 3 1.25 1.25 ArraysSort.intSort 75 avgt 3 1.16 1.20 ArraysSort.intSort 100 avgt 3 1.07 1.07 ArraysSort.intSort 1000 avgt 3 1.12 1.13 ArraysSort.intSort 10000 avgt 3 1.94 1.95 ArraysSort.intSort 100000 avgt 3 1.86 1.86 ArraysSort.intSort 1000000 avgt 3 2.09 2.09 On Neoverse V2: Benchmark (size) Mode Cnt A B ArraysSort.floatParallelSort 10 avgt 3 1.02 1.02 ArraysSort.floatParallelSort 25 avgt 3 0.97 0.71 ArraysSort.floatParallelSort 50 avgt 3 0.94 0.65 ArraysSort.floatParallelSort 75 avgt 3 0.96 0.82 ArraysSort.floatParallelSort 100 avgt 3 0.95 0.84 ArraysSort.floatParallelSort 1000 avgt 3 1.01 0.94 ArraysSort.floatParallelSort 10000 avgt 3 1.01 1.25 ArraysSort.floatParallelSort 100000 avgt 3 1.01 1.09 ArraysSort.floatParallelSort 1000000 avgt 3 1.00 1.10 ArraysSort.floatSort 10 avgt 3 1.02 1.00 ArraysSort.floatSort 25 avgt 3 0.99 0.76 ArraysSort.floatSort 50 avgt 3 0.97 0.66 ArraysSort.floatSort 75 avgt 3 1.01 0.83 ArraysSort.floatSort 100 avgt 3 1.00 0.85 ArraysSort.floatSort 1000 avgt 3 0.99 0.93 ArraysSort.floatSort 10000 avgt 3 1.00 1.28 ArraysSort.floatSort 100000 avgt 3 1.00 1.37 ArraysSort.floatSort 1000000 avgt 3 1.00 1.48 ArraysSort.intParallelSort 10 avgt 3 1.05 1.05 ArraysSort.intParallelSort 25 avgt 3 0.99 0.84 ArraysSort.intParallelSort 50 avgt 3 1.03 1.14 ArraysSort.intParallelSort 75 avgt 3 0.91 0.99 ArraysSort.intParallelSort 100 avgt 3 0.98 0.96 ArraysSort.intParallelSort 1000 avgt 3 1.32 1.30 ArraysSort.intParallelSort 10000 avgt 3 1.40 1.40 ArraysSort.intParallelSort 100000 avgt 3 1.00 1.04 ArraysSort.intParallelSort 1000000 avgt 3 1.15 1.14 ArraysSort.intSort 10 avgt 3 1.05 1.05 ArraysSort.intSort 25 avgt 3 1.03 1.03 ArraysSort.intSort 50 avgt 3 1.08 1.14 ArraysSort.intSort 75 avgt 3 0.88 0.98 ArraysSort.intSort 100 avgt 3 1.01 0.99 ArraysSort.intSort 1000 avgt 3 1.3 1.32 ArraysSort.intSort 10000 avgt 3 1.43 1.43 ArraysSort.intSort 100000 avgt 3 1.30 1.30 ArraysSort.intSort 1000000 avgt 3 1.37 1.37 ------------- Commit messages: - AArch64 SVE implementation for Arrays.sort - Prepare base for SVE implementation in libsimdsort Changes: https://git.openjdk.org/jdk/pull/28675/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28675&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371711 Stats: 1109 lines in 26 files changed: 1092 ins; 12 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28675.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28675/head:pull/28675 PR: https://git.openjdk.org/jdk/pull/28675 From alan.bateman at oracle.com Fri Dec 5 16:52:23 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Fri, 5 Dec 2025 16:52:23 +0000 Subject: CFV: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects In-Reply-To: References: Message-ID: <0550df2f-5246-4208-a322-ba8fdbf3bb2e@oracle.com> Vote: yes From alanb at openjdk.org Fri Dec 5 16:53:36 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 5 Dec 2025 16:53:36 GMT Subject: RFR: 8373125: Add defensive screening of modifiers for Field and Parameter toString() results In-Reply-To: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> References: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> Message-ID: On Fri, 5 Dec 2025 05:14:05 GMT, Joe Darcy wrote: > The modifiers in core reflection and just modeled using the bits of an int. For methods and constructors, there are collisions on the reuse of modifier bits on different kinds of constructs. Printing misleading information is avoid by masking out the modfiers using information from the Modifer class. > > While Field and Parameter don't currently have such collisions, they may under Valhalla and adding defensive screenings now would add robustness. Maybe a bit mature to be concerned with this but I think the change looks okay. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28672#pullrequestreview-3545569951 From duke at openjdk.org Fri Dec 5 16:53:38 2025 From: duke at openjdk.org (duke) Date: Fri, 5 Dec 2025 16:53:38 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: <3jyApSZ2sXUAKOGsUOpOPGjDWV-iTc-9vyUbo-I0Ud8=.03fef6fb-9447-4f2f-aa2b-d1a9872235ee@github.com> On Thu, 4 Dec 2025 22:37:34 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Add coverage for other factory methods: noneOf, of, etc @kilink Your change (at version adb01836993565721192904bf2de558a561d3233) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3617693610 From duke at openjdk.org Fri Dec 5 17:12:49 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Fri, 5 Dec 2025 17:12:49 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v2] In-Reply-To: References: Message-ID: <1P0ljCui0u-yGo6xGAPsLETRdMc_UTlg5-4tzPPJSCA=.28d97c42-bf23-49b0-99ee-7868cece1b17@github.com> On Mon, 1 Dec 2025 09:09:07 GMT, Viktor Klang wrote: >> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > Hi @kilink, > > This PR is currently missing a test case or two. Thank you for the review / feedback @viktorklang-ora . Would you be willing to sponsor this change? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3617760804 From duke at openjdk.org Fri Dec 5 17:17:25 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 5 Dec 2025 17:17:25 GMT Subject: RFR: 8366478: BigDecimal roots [v31] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: <_NnLSuTxt2n9ZSeqD58Twes0-SKzp3mbrgFuqW_sHqg=.96d646f5-8a7f-472d-be16-d456b0d4db5e@github.com> > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Some code simplifications ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/83c4ff53..9ac75762 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=30 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=29-30 Stats: 12 lines in 1 file changed: 0 ins; 6 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From liach at openjdk.org Fri Dec 5 17:34:59 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Dec 2025 17:34:59 GMT Subject: RFR: 8373125: Add defensive screening of modifiers for Field and Parameter toString() results In-Reply-To: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> References: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> Message-ID: On Fri, 5 Dec 2025 05:14:05 GMT, Joe Darcy wrote: > The modifiers in core reflection and just modeled using the bits of an int. For methods and constructors, there are collisions on the reuse of modifier bits on different kinds of constructs. Printing misleading information is avoid by masking out the modfiers using information from the Modifer class. > > While Field and Parameter don't currently have such collisions, they may under Valhalla and adding defensive screenings now would add robustness. Looks right that we should continue to use `Modifer.xxxModifiers` to filter non-source modifier bits from access flags. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28672#pullrequestreview-3545707132 From duke at openjdk.org Fri Dec 5 17:36:44 2025 From: duke at openjdk.org (fabioromano1) Date: Fri, 5 Dec 2025 17:36:44 GMT Subject: RFR: 8366478: BigDecimal roots [v32] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Simplified result's assertions for n < 0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/9ac75762..97502734 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=31 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=30-31 Stats: 35 lines in 1 file changed: 7 ins; 14 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From darcy at openjdk.org Fri Dec 5 17:38:09 2025 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 5 Dec 2025 17:38:09 GMT Subject: Integrated: 8373125: Add defensive screening of modifiers for Field and Parameter toString() results In-Reply-To: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> References: <5N-5dPVfLijaU0am9jPWcpuvPCrVTtejZJdza7FaY94=.fb7ef295-c257-448e-98a0-011b96bbef26@github.com> Message-ID: On Fri, 5 Dec 2025 05:14:05 GMT, Joe Darcy wrote: > The modifiers in core reflection and just modeled using the bits of an int. For methods and constructors, there are collisions on the reuse of modifier bits on different kinds of constructs. Printing misleading information is avoid by masking out the modfiers using information from the Modifer class. > > While Field and Parameter don't currently have such collisions, they may under Valhalla and adding defensive screenings now would add robustness. This pull request has now been integrated. Changeset: a20b7eb9 Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/a20b7eb943c19f9852bfaaec1fbbff647f1f5273 Stats: 52 lines in 3 files changed: 35 ins; 0 del; 17 mod 8373125: Add defensive screening of modifiers for Field and Parameter toString() results Reviewed-by: alanb, liach ------------- PR: https://git.openjdk.org/jdk/pull/28672 From david.1993grajales at gmail.com Fri Dec 5 04:38:14 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Thu, 4 Dec 2025 23:38:14 -0500 Subject: Feedback about LazyConstants API (JEP526) Message-ID: Dear Java Dev Team, I am writing to provide feedback and two specific observations regarding the LazyConstant API, which is currently a preview feature in OpenJDK 26. I appreciate the API's direction and I think it's a good improvement compared to its first iteration; however, I see potential for improved expressiveness, particularly in conditional scenarios. *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* Currently, the mandatory use of a factory method receiving a `Supplier` (due to the lack of a public constructor) can obscure the expressiveness of conditional or multiple-value initialization paths. **The Issue:** When looking at the declaration: LazyConstant foo = LazyConstant.of(() -> "hello"); the code gives the strong, immediate impression that the value is *always* initialized to "hello". This makes it difficult to infer that the constant might ultimately resolve to an alternative value set later via orElse() or another conditional path, especially when skimming the code: LazyConstant foo = LazyConstant.of(() -> "hello"); // When skimming the code it's not always obvious that this may not be the actual value void main() { if (someCondition()) { foo.get(); // Trigger initialization to "hello" } // If someCondition is false, the final value of foo is determined here: var res1 = foo.orElse("hello2"); // ... } *My Suggestion:* I propose introducing a *zero-parameter overloaded static factory method* of(): LazyConstant foo = LazyConstant.of(); This form explicitly communicates that the constant is initialized to an *unresolved* state, suggesting that the value will be determined downstream by the first invocation of an initialization/computation method. LazyConstant foo = LazyConstant.of(); // Clearly unresolved void main() { if (someCondition()) { foo.orElse("hello"); } var res1 = foo.orElse("hello2"); // ... } This is specially useful for clarity when one has conditional initialization in places such as the constructor of a class. For example private class Bar{ LazyConstant foo = LazyConstant.of(); private Bar(Some some){ if(some.condition()){ foo.orElse("foo"); } foo.orElse("foo2"); } String computeValue() { return "hello"; } String computeValue2(){ return "hello2"; } } 2. Method Naming Suggestion and and supplier in instance method for consistency in the API My second, much more minor observation relates to the instance method orElse(T t). While orElse fits a retrieval pattern, I personally feel that *compute* or *computeIfAbsent* would better express the intent of this method, as its primary function is not just to retrieve, but to trigger the computation and *set the final value* of the constant if it is currently uninitialized. Also, as the factory of() has a supplier i think this instance method should also receive a Supplier, This not only keeps the API consistent in the usage but makes more ergonomic the declaration of complex initialization logic inside the method. private class Bar{ LazyConstant foo = LazyConstant.of(InitParam::default); // Under the current API this is mandatory but in reality the value is set in the constructor, default is never really used. private Bar(Some some){ foo.compute(some::executeCallToCacheDBAndBringInitializationParams) //Real configuration happens here } } This last it's very common for initialization of configuration classes and singletons. Thank you so much for your attention, I hope you find this feedback useful. Always yours. David Grajales -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Fri Dec 5 12:54:39 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Fri, 5 Dec 2025 07:54:39 -0500 Subject: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: HI Per. I pleasure to talk with you. You are right about one thing but this actually makes the API less intuitive and harder to read and reason about. LazyConstant foo = LazyConstant.of(() -> "hello"); void main() { if (someCondition()) {// asume false foo.get(); } foo.orElse("hello2"); // ... println(foo.get()); // This prints "hello" } But if one assigns foo.orElse("hello2") to a variable, the variable actually gets the "hello2" value. void main() { if (someCondition()) {// asume false foo.get(); } var res = foo.orElse("hello2"); // ... var res2 = foo.orElse("hello3"); println(res); // This prints "hello2" println(res2);//This prints "hello3" } This is actually even more confusing and makes the API more error prone. I personally think once initialized the lazy constant should always return the same value (maybe through the .get() method only), and there should not be any possibility of getting a different values from the same instance either in the .of() static method or in any hypothetical instance method for conditional downstream logic. I guess one could achieve the latter with the static factory method through something like this (although less elegant) private class Bar{ private final LazyConstant foo; private Bar(Some some){ if(some.condition){ foo = LazyConstant.of(() -> "hello"); }else { foo = LazyConstant.of(() -> "hello2"); } } } Thank you for reading. This is all I have to report. Best regards. El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg ( per-ake.minborg at oracle.com) escribi?: > Hi David, > > Thank you for trying out LazyConstant and providing feedback. That is > precisely what previews are for! > > If you take a closer look at the specification of LazyConstant::orElse, it > says that the method will *never trigger initialization.* And so, you > *can* actually be sure that in your first example, foo is always > initialized to "hello" (if ever initialized). It is only if foo is not > initialized that the method will return "hello2" (again, without > initializing foo). This is similar to how Optional works. > > It would be possible to entirely remove the orElse() method from the API, > and in the rare cases where an equivalent functionality is called for, rely > on LazyConstant::isInitialized instead. > > Best, Per > > > Confidential- Oracle Internal > ------------------------------ > *From:* amber-dev on behalf of david > Grajales > *Sent:* Friday, December 5, 2025 5:38 AM > *To:* amber-dev ; core-libs-dev at openjdk.org < > core-libs-dev at openjdk.org> > *Subject:* Feedback about LazyConstants API (JEP526) > > Dear Java Dev Team, > > I am writing to provide feedback and two specific observations regarding > the LazyConstant API, which is currently a preview feature in OpenJDK 26. > > I appreciate the API's direction and I think it's a good improvement > compared to its first iteration; however, I see potential for improved > expressiveness, particularly in conditional scenarios. > > > *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* > > Currently, the mandatory use of a factory method receiving a `Supplier` > (due to the lack of a public constructor) can obscure the expressiveness of > conditional or multiple-value initialization paths. **The Issue:** When > looking at the declaration: > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > the code gives the strong, immediate impression that the value is *always* > initialized to "hello". This makes it difficult to infer that the > constant might ultimately resolve to an alternative value set later via > orElse() or another conditional path, especially when skimming the code: > > LazyConstant foo = LazyConstant.of(() -> "hello"); // When > skimming the code it's not always obvious that this may not be the actual > value > > void main() { > if (someCondition()) { > foo.get(); // Trigger initialization to "hello" > } > // If someCondition is false, the final value of foo is determined here: > > var res1 = foo.orElse("hello2"); // ... > } > > *My Suggestion:* I propose introducing a *zero-parameter overloaded > static factory method* of(): > > LazyConstant foo = LazyConstant.of(); > > This form explicitly communicates that the constant is initialized to an * > unresolved* state, suggesting that the value will be determined > downstream by the first invocation of an initialization/computation method. > > LazyConstant foo = LazyConstant.of(); // Clearly unresolved > void main() { > if (someCondition()) { > foo.orElse("hello"); > } > var res1 = foo.orElse("hello2"); // ... > } > > This is specially useful for clarity when one has conditional > initialization in places such as the constructor of a class. For example > > private class Bar{ > LazyConstant foo = LazyConstant.of(); > private Bar(Some some){ > if(some.condition()){ > foo.orElse("foo"); > } > foo.orElse("foo2"); > } > > String computeValue() { > return "hello"; > } > > String computeValue2(){ > return "hello2"; > } > } > 2. Method Naming Suggestion and and supplier in instance method for > consistency in the API > > My second, much more minor observation relates to the instance method orElse(T > t). > > While orElse fits a retrieval pattern, I personally feel that * compute* > or *computeIfAbsent* would better express the intent of this method, as > its primary function is not just to retrieve, but to trigger the > computation and *set the final value* of the constant if it is currently > uninitialized. Also, as the factory of() has a supplier i think this > instance method should also receive a Supplier, This not only keeps the API > consistent in the usage but makes more ergonomic the declaration of complex > initialization logic inside the method. > > > private class Bar{ > LazyConstant foo = LazyConstant.of(InitParam::default); // > Under the current API this is mandatory but in reality the value is set in > the constructor, default is never really used. > private Bar(Some some){ > foo.compute(some::executeCallToCacheDBAndBringInitializationParams) > //Real configuration happens here > > } > } > > This last it's very common for initialization of configuration classes and > singletons. > > > Thank you so much for your attention, I hope you find this feedback useful. > > Always yours. David Grajales > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redio.development at gmail.com Fri Dec 5 13:31:56 2025 From: redio.development at gmail.com (Red IO) Date: Fri, 5 Dec 2025 14:31:56 +0100 Subject: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: Hi David, As par already said the orElse method doesn't initializes the LazyConstant. It just checks rather the value is init and if not calls the supplier to get a substitute for the missing constant. Example: LazyConstant x = LazyConstant.of(() -> "Const"); var uninit1 = x.orElse(() -> "substitute 1"); var uninit2 = x.orElse(() -> "substitute 2"); var init1 = x.get(); var init2 = x.orElse(() -> "substitute 3"); uninit1 and uninit2 get the substitute 1/2 And init1 and init2 get Const. This is surprising if you expect it to be a way to init it with an alternative value. My suggestion would to make the separation clear and allow for another use case by spliting this api in 2 parts: One class LazyConstant Takes a Supplier in static factory and exposes get() And Class LazyInit Which takes no arguments in the static factory and takes a supplier in the get method that gets called when get is called for the first time. In this case the source for the constant can be any piece of code that has access to the LazyConstant. This might be desired in some cases. In cases where it's not the other version can be used. This split makes it clear from which context the constant is initialized from (consumer or at declaration) Mixing those 2 or having methods that appear to do this is rather confusing. One solution for the "i might not want to init the constant" case the "orElse" method is meant to be is to have a method "tryGet" which returns Optional instead. This makes it clear that the value might not be there and is not initialized when calling the method. Nobody expects to init the constant when calling orElse on a returned Optional. My 2 suggestions here are completely independent and should be viewed as such. Great regards RedIODev On Fri, Dec 5, 2025, 13:55 david Grajales wrote: > HI Per. I pleasure to talk with you. > > You are right about one thing but this actually makes the API less > intuitive and harder to read and reason about. > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > foo.orElse("hello2"); // ... > > println(foo.get()); // This prints "hello" > } > > But if one assigns foo.orElse("hello2") to a variable, the variable > actually gets the "hello2" value. > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > var res = foo.orElse("hello2"); // ... > var res2 = foo.orElse("hello3"); > println(res); // This prints "hello2" > println(res2);//This prints "hello3" > } > > This is actually even more confusing and makes the API more error prone. I > personally think once initialized the lazy constant should always return > the same value (maybe through the .get() method only), and there should not > be any possibility of getting a different values from the same instance > either in the .of() static method or in any hypothetical instance method > for conditional downstream logic. I guess one could achieve the latter > with the static factory method through something like this (although less > elegant) > > private class Bar{ > private final LazyConstant foo; > private Bar(Some some){ > > if(some.condition){ > foo = LazyConstant.of(() -> "hello"); > }else { > foo = LazyConstant.of(() -> "hello2"); > } > } > } > > Thank you for reading. This is all I have to report. > > Best regards. > > > > El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg ( > per-ake.minborg at oracle.com) escribi?: > >> Hi David, >> >> Thank you for trying out LazyConstant and providing feedback. That is >> precisely what previews are for! >> >> If you take a closer look at the specification of LazyConstant::orElse, it >> says that the method will *never trigger initialization.* And so, you >> *can* actually be sure that in your first example, foo is always >> initialized to "hello" (if ever initialized). It is only if foo is not >> initialized that the method will return "hello2" (again, without >> initializing foo). This is similar to how Optional works. >> >> It would be possible to entirely remove the orElse() method from the >> API, and in the rare cases where an equivalent functionality is called for, >> rely on LazyConstant::isInitialized instead. >> >> Best, Per >> >> >> Confidential- Oracle Internal >> ------------------------------ >> *From:* amber-dev on behalf of david >> Grajales >> *Sent:* Friday, December 5, 2025 5:38 AM >> *To:* amber-dev ; core-libs-dev at openjdk.org < >> core-libs-dev at openjdk.org> >> *Subject:* Feedback about LazyConstants API (JEP526) >> >> Dear Java Dev Team, >> >> I am writing to provide feedback and two specific observations regarding >> the LazyConstant API, which is currently a preview feature in OpenJDK 26. >> >> I appreciate the API's direction and I think it's a good improvement >> compared to its first iteration; however, I see potential for improved >> expressiveness, particularly in conditional scenarios. >> >> >> *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* >> >> Currently, the mandatory use of a factory method receiving a `Supplier` >> (due to the lack of a public constructor) can obscure the expressiveness of >> conditional or multiple-value initialization paths. **The Issue:** When >> looking at the declaration: >> >> LazyConstant foo = LazyConstant.of(() -> "hello"); >> >> the code gives the strong, immediate impression that the value is >> *always* initialized to "hello". This makes it difficult to infer that >> the constant might ultimately resolve to an alternative value set later via >> orElse() or another conditional path, especially when skimming the code: >> >> LazyConstant foo = LazyConstant.of(() -> "hello"); // When >> skimming the code it's not always obvious that this may not be the actual >> value >> >> void main() { >> if (someCondition()) { >> foo.get(); // Trigger initialization to "hello" >> } >> // If someCondition is false, the final value of foo is determined >> here: >> var res1 = foo.orElse("hello2"); // ... >> } >> >> *My Suggestion:* I propose introducing a *zero-parameter overloaded >> static factory method* of(): >> >> LazyConstant foo = LazyConstant.of(); >> >> This form explicitly communicates that the constant is initialized to an * >> unresolved* state, suggesting that the value will be determined >> downstream by the first invocation of an initialization/computation method. >> >> LazyConstant foo = LazyConstant.of(); // Clearly unresolved >> void main() { >> if (someCondition()) { >> foo.orElse("hello"); >> } >> var res1 = foo.orElse("hello2"); // ... >> } >> >> This is specially useful for clarity when one has conditional >> initialization in places such as the constructor of a class. For example >> >> private class Bar{ >> LazyConstant foo = LazyConstant.of(); >> private Bar(Some some){ >> if(some.condition()){ >> foo.orElse("foo"); >> } >> foo.orElse("foo2"); >> } >> >> String computeValue() { >> return "hello"; >> } >> >> String computeValue2(){ >> return "hello2"; >> } >> } >> 2. Method Naming Suggestion and and supplier in instance method for >> consistency in the API >> >> My second, much more minor observation relates to the instance method orElse(T >> t). >> >> While orElse fits a retrieval pattern, I personally feel that * compute* >> or *computeIfAbsent* would better express the intent of this method, as >> its primary function is not just to retrieve, but to trigger the >> computation and *set the final value* of the constant if it is currently >> uninitialized. Also, as the factory of() has a supplier i think this >> instance method should also receive a Supplier, This not only keeps the API >> consistent in the usage but makes more ergonomic the declaration of complex >> initialization logic inside the method. >> >> >> private class Bar{ >> LazyConstant foo = LazyConstant.of(InitParam::default); >> // Under the current API this is mandatory but in reality the value is set >> in the constructor, default is never really used. >> private Bar(Some some){ >> >> foo.compute(some::executeCallToCacheDBAndBringInitializationParams) //Real >> configuration happens here >> >> } >> } >> >> This last it's very common for initialization of configuration classes >> and singletons. >> >> >> Thank you so much for your attention, I hope you find this feedback >> useful. >> >> Always yours. David Grajales >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From erikj at openjdk.org Fri Dec 5 19:00:55 2025 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 5 Dec 2025 19:00:55 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) In-Reply-To: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> Message-ID: On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi wrote: > This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation. > > For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass. > > The SVE path is enabled by default for int type. For float type, it is available through the experimental flag : > > `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP > ` > Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default). > > Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1. > > Following are the performance numbers for **ArraysSort JMH benchmark** - > > **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default). > **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats). > **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).** > > On Neoverse V1: > > > Benchmark (size) Mode Cnt A B > ArraysSort.floatParallelSort 10 avgt 3 0.98 0.98 > ArraysSort.floatParallelSort 25 avgt 3 1.01 0.83 > ArraysSort.floatParallelSort 50 avgt 3 0.99 0.55 > ArraysSort.floatParallelSort 75 avgt 3 0.99 0.66 > ArraysSort.floatParallelSort 100 avgt 3 0.98 0.66 > ArraysSort.floatParallelSort 1000 avgt 3 1.00 0.84 > ArraysSort.floatParallelSort 10000 avgt 3 1.03 1.52 > ArraysSort.floatParallelSort 100000 avgt 3 1.03 1.46 > ArraysSort.floatParallelSort 1000000 avgt 3 0.98 1.81 > ArraysSort.floatSort 10 avgt 3 1.00 0.98 > ArraysSort.floatSort 25 avgt 3 1.00 0.81 > ArraysSort.floatSort 50 avgt 3 0.99 0.56 > ArraysSort.floatSort 75 avgt 3 0.99 0.65 > ArraysSort.floatSort 100 avgt 3 0.98 0.70 > ArraysSort.floatSort 1000 avgt 3 0.99 0.84 > ArraysSort.floatSort ... make/modules/java.base/Lib.gmk line 225: > 223: > 224: TARGETS += $(BUILD_LIBSIMD_SORT) > 225: endif This whole block should be combined with the existing block above, something like this: ifeq ($(call isTargetOs, linux)+$(call isTargetCpu, x86_64 aarch64)+$(INCLUDE_COMPILER2)+$(filter $(TOOLCHAIN_TYPE), gcc), true+true+true+gcc) ############################################################################## ## Build libsimdsort ############################################################################## $(eval $(call SetupJdkLibrary, BUILD_LIBSIMD_SORT, \ NAME := simdsort, \ LINK_TYPE := C++, \ OPTIMIZATION := HIGH, \ INCLUDES := $(OPENJDK_TARGET_CPU_ARCH), \ CXXFLAGS := -std=c++17, \ CXXFLAGS_linux_aarch64 := -march=armv8.2-a+sve, \ DISABLED_WARNINGS_gcc := unused-variable, \ LIBS_linux := $(LIBM), \ )) TARGETS += $(BUILD_LIBSIMD_SORT) endif Unfortunately we don't currently support CXXFLAGS__, just CFLAGS__, but this can be fixed and I think it should be since we now have a need for it. diff --git a/make/common/native/Flags.gmk b/make/common/native/Flags.gmk index efb4c08e74c..2f3680af7c7 100644 --- a/make/common/native/Flags.gmk +++ b/make/common/native/Flags.gmk @@ -106,10 +106,12 @@ define SetupCompilerFlags $1_EXTRA_CFLAGS += -DSTATIC_BUILD=1 endif - # Pickup extra OPENJDK_TARGET_OS_TYPE, OPENJDK_TARGET_OS and/or TOOLCHAIN_TYPE - # dependent variables for CXXFLAGS. + # Pickup extra OPENJDK_TARGET_OS_TYPE, OPENJDK_TARGET_OS, TOOLCHAIN_TYPE and + # OPENJDK_TARGET_OS plus OPENJDK_TARGET_CPU pair dependent variables for + # CXXFLAGS. $1_EXTRA_CXXFLAGS := $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS_TYPE)) $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS)) \ - $$($1_CXXFLAGS_$(TOOLCHAIN_TYPE)) + $$($1_CXXFLAGS_$(TOOLCHAIN_TYPE)) \ + $$($1_CXXFLAGS_$(OPENJDK_TARGET_OS)_$(OPENJDK_TARGET_CPU)) ifneq ($(DEBUG_LEVEL), release) # Pickup extra debug dependent variables for CXXFLAGS The above at least compiles for me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28675#discussion_r2593665862 From sherman at openjdk.org Fri Dec 5 19:26:15 2025 From: sherman at openjdk.org (Xueming Shen) Date: Fri, 5 Dec 2025 19:26:15 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values Message-ID: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> ### Summary - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result - Add additional test data to the existing VectorMask from/toLong tests. - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template ------------- Commit messages: - update - update - update - update - update - update - 8371446: VectorAPI: Add unit tests for masks from various long values Changes: https://git.openjdk.org/jdk/pull/28593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371446 Stats: 9468 lines in 39 files changed: 5794 ins; 3334 del; 340 mod Patch: https://git.openjdk.org/jdk/pull/28593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28593/head:pull/28593 PR: https://git.openjdk.org/jdk/pull/28593 From bchristi at openjdk.org Fri Dec 5 19:33:05 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 5 Dec 2025 19:33:05 GMT Subject: Integrated: 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method In-Reply-To: References: Message-ID: <71GnnoWpSvtcYZi1O_uOaw6P-kpCqkZLf7VP_PJOHrg=.f1674f61-6bc2-481f-b022-43d8bab11d86@github.com> On Thu, 13 Nov 2025 23:10:59 GMT, Brent Christian wrote: > From the bug report: > Prior to JDK 11, ThreadPoolExecutor.finalize() was specified to > "[invoke] shutdown() when this executor is no longer referenced and it has no threads." > > In JDK 11, ThreadPoolExecutor.finalize() was re-specified to do nothing, leaving the finalize() method empty. ([JDK-8190324](https://bugs.openjdk.org/browse/JDK-8190324)). > > In JDK 18, finalize() was deprecated for removal ([JDK-8276447](https://bugs.openjdk.org/browse/JDK-8276447)), after first being "standard" deprecated in JDK 9 ([JDK-8165641](https://bugs.openjdk.org/browse/JDK-8165641)). > > The finalize() method can safely be removed from ThreadPoolExecutor. This pull request has now been integrated. Changeset: f3dd8daa Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/f3dd8daaa92896be51254e5abf3e0ec5b1ff5173 Stats: 17 lines in 1 file changed: 0 ins; 17 del; 0 mod 8371748: Remove the (empty) ThreadPoolExecutor.finalize() method Reviewed-by: vklang, jpai, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28311 From psandoz at openjdk.org Fri Dec 5 20:23:58 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 5 Dec 2025 20:23:58 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values In-Reply-To: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> On Tue, 2 Dec 2025 00:53:40 GMT, Xueming Shen wrote: > ### Summary > > - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result > - Add additional test data to the existing VectorMask from/toLong tests. > - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template test/jdk/jdk/incubator/vector/AbstractVectorTest.java line 123: > 121: boolean[] a = new boolean[l]; > 122: for (int i = 0; i < l; i++) { > 123: a[i] = (i % 2 == 0); Suggestion: a[i] = (i % 5 == 0); test/jdk/jdk/incubator/vector/templates/Unit-BoolUnary-op.template line 6: > 4: } > 5: > 6: @Test(dataProvider = "maskBinaryOpProvider") There is already "boolUnaryOpProvider" data provider can we use that and align the naming? test/jdk/jdk/incubator/vector/templates/Unit-Mask-FromToLong.template line 20: > 18: long[] r = new long[a.length]; > 19: > 20: for (int ic = 0; ic < INVOC_COUNT * INVOC_COUNT; ic++) { Suggestion: for (int ic = 0; ic < INVOC_COUNT; ic++) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2593845901 PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2593883228 PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2593848113 From duke at openjdk.org Fri Dec 5 22:07:18 2025 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Fri, 5 Dec 2025 22:07:18 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v4] In-Reply-To: References: Message-ID: > The implementation of JarEntry.getCodeSigners() and getCertificates() both return a copy of the original array. However, the documentation of these 2 methods currently doesn't specify this. Koushik Muthukrishnan Thirupattur has updated the pull request incrementally with one additional commit since the last revision: 8370688: Addressed review comments-removed this method in the return label ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28615/files - new: https://git.openjdk.org/jdk/pull/28615/files/d53fe8ff..cc77e339 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=02-03 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28615.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28615/head:pull/28615 PR: https://git.openjdk.org/jdk/pull/28615 From mcimadamore at openjdk.org Fri Dec 5 22:25:56 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Fri, 5 Dec 2025 22:25:56 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 16:22:08 GMT, Stuart Monteith wrote: > I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3618818702 From liach at openjdk.org Fri Dec 5 23:13:28 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Dec 2025 23:13:28 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance Message-ID: The 3 methods to determine conversions and subtyping on `java.lang.Class`, which are `isInstance`, `cast`, and `isAssignableFrom`, have their documentation from the earliest days of the Java Platform. During the language evolution, a lot of terms have become inaccurate, such as "assignment-compatible", which does not apply for primitive types, and the out-of-date instanceof analogy with the upcoming patterns, in `isInstance`; `isAssignableFrom` is not very clear about arrays; `cast` would also benefit from more detailed explanations. In my facelift, I moved the subtyping description to `isAssignableFrom`, and left the conversion stuff in `isInstance` and `cast`. I intentionally avoided linking to too many JLS chapters to reduce confusions. I believe in this shape, we have a good amount of easily comprehensible yet accurate specification for all 3 methods, and users are welcome to read the linked JLS chapters for more details and context. ------------- Commit messages: - Improve documentation of Class.isInstance Changes: https://git.openjdk.org/jdk/pull/28684/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371795 Stats: 90 lines in 1 file changed: 35 ins; 16 del; 39 mod Patch: https://git.openjdk.org/jdk/pull/28684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28684/head:pull/28684 PR: https://git.openjdk.org/jdk/pull/28684 From liach at openjdk.org Fri Dec 5 23:28:35 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 5 Dec 2025 23:28:35 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance [v2] In-Reply-To: References: Message-ID: > The 3 methods to determine conversions and subtyping on `java.lang.Class`, which are `isInstance`, `cast`, and `isAssignableFrom`, have their documentation from the earliest days of the Java Platform. During the language evolution, a lot of terms have become inaccurate, such as "assignment-compatible", which does not apply for primitive types, and the out-of-date instanceof analogy with the upcoming patterns, in `isInstance`; `isAssignableFrom` is not very clear about arrays; `cast` would also benefit from more detailed explanations. > > In my facelift, I moved the subtyping description to `isAssignableFrom`, and left the conversion stuff in `isInstance` and `cast`. I intentionally avoided linking to too many JLS chapters to reduce confusions. I believe in this shape, we have a good amount of easily comprehensible yet accurate specification for all 3 methods, and users are welcome to read the linked JLS chapters for more details and context. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Primitive type or void ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28684/files - new: https://git.openjdk.org/jdk/pull/28684/files/3d5e795f..4a4f2867 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=00-01 Stats: 11 lines in 1 file changed: 1 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28684/head:pull/28684 PR: https://git.openjdk.org/jdk/pull/28684 From liach at openjdk.org Sat Dec 6 00:03:13 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Dec 2025 00:03:13 GMT Subject: RFR: 4517644: Core reflection setter type conversion spec bugs [v3] In-Reply-To: <__a7AqZo67VmQO-iJ7d7rX1MtgbEaKyj6osuOtyYSDs=.5301f110-5d13-4008-8bc1-2684c73bf547@github.com> References: <__a7AqZo67VmQO-iJ7d7rX1MtgbEaKyj6osuOtyYSDs=.5301f110-5d13-4008-8bc1-2684c73bf547@github.com> Message-ID: <5l_yIIEw8MdATIXHPVNYj-zsvczrtykyTOgysyPEwvU=.e769c2da-fb8c-4579-b4ae-3d27e667f4d3@github.com> On Thu, 6 Nov 2025 20:43:37 GMT, Chen Liang wrote: >> ### Current Status >> In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process: >> >> 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object. >> 2. Perform identity or (primitive/reference, depending on destination type) widening conversions. >> >> For each step, they can fail with IllegalArgumentException, which has been the long standing behavior. >> >> Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them. >> >> ### Problems >> There are some problems with current specs: >> 1. No mention that boxing is never done for primitive-typed setters >> 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition >> 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors >> 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body) >> 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion >> 6. Field primitive setters refer to nonsense "unwrapping conversion" >> >> ### Solutions >> 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set >> 2. Add that boxing is absent for all primitive setters >> 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only >> 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters >> 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision: > > - Link > - Update > - Redundant > - Stuff for the class spec > - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-set > - the narrowing conversion restriction is primitive-only > - 4517644: (reflect spec) Array.set documentation hole for array/value ref type mismatch Abandoned in favor of #28685. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28029#issuecomment-3618993321 From liach at openjdk.org Sat Dec 6 00:03:14 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Dec 2025 00:03:14 GMT Subject: Withdrawn: 4517644: Core reflection setter type conversion spec bugs In-Reply-To: References: Message-ID: <9veOXLd8RO-4AB9qNAgRWHUXAuID-iZvcJh_jGNRWH8=.1fbe7907-35d6-4944-b178-9d1a3ada64c6@github.com> On Tue, 28 Oct 2025 22:23:59 GMT, Chen Liang wrote: > ### Current Status > In core reflection, there are a few holes with the documentation on the type conversions performed on the different setters. They generally follow this process: > > 1. The Object-valued setters checks the destination type. If that type is primitive, unbox the object. > 2. Perform identity or (primitive/reference, depending on destination type) widening conversions. > > For each step, they can fail with IllegalArgumentException, which has been the long standing behavior. > > Note that this process is more restrictive than the JLS 5.2 assignment context, which allows boxing conversions, while the primitive reflective setters consistently reject them. > > ### Problems > There are some problems with current specs: > 1. No mention that boxing is never done for primitive-typed setters > 2. Array.set missing description for the final identity or widening conversion (reference or primitive) and the associated IAE condition > 3. Class specification of field mentions widening/narrowing conversion rules that is not sensible for get/set Object accessors > 4. Field.set misses the identity or widening in IAE clause (but mentioned in main body) > 5. Field primitive setters incorrectly claim they are equivalent to set(instance, wrapper) which is wrong due to lack of boxing conversion > 6. Field primitive setters refer to nonsense "unwrapping conversion" > > ### Solutions > 1. Make sure the unbox -> identity/widen process and the IAE conditions are present in both Field and Array.set > 2. Add that boxing is absent for all primitive setters > 3. Update Field class spec to mention the narrowing/widening conversion limits are for primitive accessors only > 4. Fix the Field primitive setters' "unwrapping conversion" to be "identity or primitive widening conversion" as in Array primitive setters > 5. Qualify the Field primitive setters assertion with "if this field is of a primitive type" to make it correct This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28029 From liach at openjdk.org Sat Dec 6 00:21:12 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 6 Dec 2025 00:21:12 GMT Subject: RFR: 8373196: Core reflection overview update for access check and conversions Message-ID: Core reflection has its own type conversion behavior that is somewhat poorly specified; it is scattered around a few places, and its boxing and unboxing deviates from that of Java language assignment contexts. In addition, core reflection has a somewhat erroneous access check system. We can improve the overview of java.lang.reflect to address these shortcomings and recommend users to use java.lang.invoke for better functionality in these areas. ------------- Commit messages: - formatting - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - More stuff - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - Links - Tweak again - Merge branch 'master' of https://github.com/openjdk/jdk into doc/reflect-accessor-conversion - ... and 2 more: https://git.openjdk.org/jdk/compare/a20b7eb9...7cd59b24 Changes: https://git.openjdk.org/jdk/pull/28685/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28685&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373196 Stats: 374 lines in 7 files changed: 158 ins; 73 del; 143 mod Patch: https://git.openjdk.org/jdk/pull/28685.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28685/head:pull/28685 PR: https://git.openjdk.org/jdk/pull/28685 From sherman at openjdk.org Sat Dec 6 00:27:26 2025 From: sherman at openjdk.org (Xueming Shen) Date: Sat, 6 Dec 2025 00:27:26 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v2] In-Reply-To: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: <0eLUVqXbCSjwaofX0nKgEMrfbZ04gT5i5ltwV4w8KrE=.afa44fcf-6748-4d8d-9c63-d6900ae2db75@github.com> > ### Summary > > - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result > - Add additional test data to the existing VectorMask from/toLong tests. > - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28593/files - new: https://git.openjdk.org/jdk/pull/28593/files/1fc7923f..07019055 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=00-01 Stats: 887 lines in 37 files changed: 249 ins; 192 del; 446 mod Patch: https://git.openjdk.org/jdk/pull/28593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28593/head:pull/28593 PR: https://git.openjdk.org/jdk/pull/28593 From sherman at openjdk.org Sat Dec 6 00:34:20 2025 From: sherman at openjdk.org (Xueming Shen) Date: Sat, 6 Dec 2025 00:34:20 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v3] In-Reply-To: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: > ### Summary > > - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result > - Add additional test data to the existing VectorMask from/toLong tests. > - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: minor update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28593/files - new: https://git.openjdk.org/jdk/pull/28593/files/07019055..da7cea23 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=01-02 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28593/head:pull/28593 PR: https://git.openjdk.org/jdk/pull/28593 From sherman at openjdk.org Sat Dec 6 00:38:03 2025 From: sherman at openjdk.org (Xueming Shen) Date: Sat, 6 Dec 2025 00:38:03 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v3] In-Reply-To: <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> Message-ID: On Fri, 5 Dec 2025 20:07:31 GMT, Paul Sandoz wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> minor update > > test/jdk/jdk/incubator/vector/AbstractVectorTest.java line 123: > >> 121: boolean[] a = new boolean[l]; >> 122: for (int i = 0; i < l; i++) { >> 123: a[i] = (i % 2 == 0); > > Suggestion: > > a[i] = (i % 5 == 0); fixed > test/jdk/jdk/incubator/vector/templates/Unit-Mask-FromToLong.template line 20: > >> 18: long[] r = new long[a.length]; >> 19: >> 20: for (int ic = 0; ic < INVOC_COUNT * INVOC_COUNT; ic++) { > > Suggestion: > > for (int ic = 0; ic < INVOC_COUNT; ic++) { fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2594284950 PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2594285037 From sherman at openjdk.org Sat Dec 6 00:43:00 2025 From: sherman at openjdk.org (Xueming Shen) Date: Sat, 6 Dec 2025 00:43:00 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v3] In-Reply-To: <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> Message-ID: On Fri, 5 Dec 2025 20:20:45 GMT, Paul Sandoz wrote: >> Xueming Shen has updated the pull request incrementally with one additional commit since the last revision: >> >> minor update > > test/jdk/jdk/incubator/vector/templates/Unit-BoolUnary-op.template line 6: > >> 4: } >> 5: >> 6: @Test(dataProvider = "maskBinaryOpProvider") > > There is already "boolUnaryOpProvider" data provider can we use that and align the naming? "boolUnaryOpProvider" is used only by the mask reduction/Unit-BoolReduction-op.template. Renamed it to "boolMaskUnaryOpProvider" to be used by both reduction and unary-op/Unit-BoolUnary-op.template. - boolMaskUnaryOpProvider - boolMaskBinaryOpProvider - longMaskProvider - maskProvider ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2594291609 From duke at openjdk.org Sat Dec 6 13:02:56 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 6 Dec 2025 13:02:56 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith wrote: > MemorySegments allocated from shared Arena from > java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. > > The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . > > The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | > | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | > | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | > | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | > | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | > | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | > | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | > | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | > > After: > > | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | > |---------|-------|-------|-------|-------|-------|-------| > | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | > | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | > | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | > | 8 | 58.22 | 31.60 | 36.87 | 31.72 | 47.09 |... src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89: > 87: @ForceInline > 88: private int getCounter() { > 89: return Thread.currentThread().hashCode() & mask; Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses. Suggestion: return System.identityHashCode(Thread.currentThread()) & mask; [`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2594828923 From duke at openjdk.org Sat Dec 6 15:37:07 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Sat, 6 Dec 2025 15:37:07 GMT Subject: Integrated: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL In-Reply-To: References: Message-ID: On Sat, 29 Nov 2025 21:48:43 GMT, Patrick Strawderman wrote: > I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. > > The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. This pull request has now been integrated. Changeset: 5f083aba Author: Patrick Strawderman Committer: Viktor Klang URL: https://git.openjdk.org/jdk/commit/5f083abafc7abfaa46ddd053668cdfbfd2ad8a87 Stats: 104 lines in 2 files changed: 103 ins; 0 del; 1 mod 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL Reviewed-by: vklang ------------- PR: https://git.openjdk.org/jdk/pull/28568 From darcy at openjdk.org Sat Dec 6 19:57:11 2025 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 6 Dec 2025 19:57:11 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 22:37:34 GMT, Patrick Strawderman wrote: >> I noticed that the Spliterator for EnumSet does not report SORTED, ORDERED, or NONNULL characteristics, all of which are inherent to API of EnumSet. I found there's an existing ticket for this as well. >> >> The ticket also mentions optimized `forEach`, etc, which I presume means avoiding the default implementation that uses the iterator and just iterating over the bitset directly; I can add that here or perhaps in a follow up if it's still deemed worthwhile. > > Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: > > Add coverage for other factory methods: noneOf, of, etc Hmm. Catching up on reviews, should the behavior change here get a CSR? More broader, should there be an implSpec change under a follow-up bug and CSR that requires this behavior? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3621060470 From darcy at openjdk.org Sat Dec 6 21:42:27 2025 From: darcy at openjdk.org (Joe Darcy) Date: Sat, 6 Dec 2025 21:42:27 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications Message-ID: Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. ------------- Commit messages: - JDK-8373186: Improve readability of core reflection toString specifications Changes: https://git.openjdk.org/jdk/pull/28688/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28688&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373186 Stats: 33 lines in 1 file changed: 9 ins; 6 del; 18 mod Patch: https://git.openjdk.org/jdk/pull/28688.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28688/head:pull/28688 PR: https://git.openjdk.org/jdk/pull/28688 From vklang at openjdk.org Sun Dec 7 00:06:11 2025 From: vklang at openjdk.org (Viktor Klang) Date: Sun, 7 Dec 2025 00:06:11 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 19:54:28 GMT, Joe Darcy wrote: >> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: >> >> Add coverage for other factory methods: noneOf, of, etc > > Hmm. Catching up on reviews, should the behavior change here get a CSR? More broader, should there be an implSpec change under a follow-up bug and CSR that requires this behavior? @jddarcy Seems reasonable! Chasing down the super-implementation, [Set::spliterator()](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Set.html#spliterator()) states that overloads should report their characteristics (even if the documentation linked does seem to unnecessarily convolutedly state which characteristics the default implementation provides). I can open up a new Issue and handle the CSR-bits if @kilink doesn't mind? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3621388432 From duke at openjdk.org Sun Dec 7 00:22:10 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Sun, 7 Dec 2025 00:22:10 GMT Subject: RFR: 8179918: EnumSet spliterator should report SORTED, ORDERED, NONNULL [v7] In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 19:54:28 GMT, Joe Darcy wrote: >> Patrick Strawderman has updated the pull request incrementally with one additional commit since the last revision: >> >> Add coverage for other factory methods: noneOf, of, etc > > Hmm. Catching up on reviews, should the behavior change here get a CSR? More broader, should there be an implSpec change under a follow-up bug and CSR that requires this behavior? > @jddarcy Seems reasonable! Chasing down the super-implementation, [Set::spliterator()](https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/util/Set.html#spliterator()) states that overloads should report their characteristics (even if the documentation linked does seem to unnecessarily convolutedly state which characteristics the default implementation provides). I can open up a new Issue and handle the CSR-bits if @kilink doesn't mind? Sounds good to me, thanks! Also, apologies, it hadn't occurred to me that this would require an update to the javadocs. The existing docs do specify that the Iterator returns elements in their natural order, and that null is not permitted, so one could say that it's implied that the spliterator would also have those characteristics. But I do see now that you pointed it out that Set indicates implementations should document any additional characteristics. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28568#issuecomment-3621405033 From swen at openjdk.org Sun Dec 7 02:06:10 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 7 Dec 2025 02:06:10 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v3] In-Reply-To: References: Message-ID: > In PR #22928, UUID introduced long-based vectorized hexadecimal to string conversion, which can also be used in Integer::toHexString and Long::toHexString to eliminate table lookups. The benefit of eliminating table lookups is that the performance is better when cache misses occur. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits: - Merge branch 'master' into optim_to_hex_202501 - Update src/java.base/share/classes/java/util/UUID.java Co-authored-by: ExE Boss <3889017+ExE-Boss at users.noreply.github.com> - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - use right shift - use right shift - fix benchmark - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 # Conflicts: # src/java.base/share/classes/jdk/internal/util/HexDigits.java - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - reverseBytes - ... and 11 more: https://git.openjdk.org/jdk/compare/5f083aba...d2d9e556 ------------- Changes: https://git.openjdk.org/jdk/pull/22942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=02 Stats: 262 lines in 6 files changed: 177 ins; 77 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/22942.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22942/head:pull/22942 PR: https://git.openjdk.org/jdk/pull/22942 From duke at openjdk.org Sun Dec 7 02:36:05 2025 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 7 Dec 2025 02:36:05 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Sat, 26 Jul 2025 10:10:40 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with four additional commits since the last revision: > > - Update `@bug` in correct file > - Add default implementation on codePointCount in CharSequence > - Update `@bug` entries in test class doc comments > - Discard changes on code whose form is not `str.codePointCount(0, str.length())` Other tasks have higher priorities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3621301718 From alan.bateman at oracle.com Sun Dec 7 08:37:51 2025 From: alan.bateman at oracle.com (Alan Bateman) Date: Sun, 7 Dec 2025 08:37:51 +0000 Subject: Result: Withdraw sponsorship of Device I/O, Kona, Penrose, and Verona projects Message-ID: <0bc242b9-d891-47c5-88cc-a46d3a1edf99@oracle.com> Voting on this motion [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definitions of Lazy Consensus [2], this is sufficient to approve the motion and the Core Libraries group withdraws sponsorship of the Device I/O, Kona, Penrose, and Verona projects. -Alan [1] https://mail.openjdk.org/pipermail/core-libs-dev/2025-November/155429.html [2] https://openjdk.org/bylaws#lazy-consensus From duke at openjdk.org Sun Dec 7 16:57:54 2025 From: duke at openjdk.org (fabioromano1) Date: Sun, 7 Dec 2025 16:57:54 GMT Subject: RFR: 8366478: BigDecimal roots [v33] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Handle negative degrees differently to simplify and optimize code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/97502734..592c4776 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=32 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=31-32 Stats: 133 lines in 2 files changed: 37 ins; 72 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From liach at openjdk.org Mon Dec 8 01:17:02 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 01:17:02 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: <6ZuASnynjlCyDB6vbAMxgvAo5p4TuLHV5XldK_zcSZQ=.86870a1b-a29b-419f-af8b-bef93546e3ad@github.com> On Sat, 6 Dec 2025 21:35:57 GMT, Joe Darcy wrote: > Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. src/java.base/share/classes/java/lang/reflect/Field.java line 360: > 358: * private int java.io.FileDescriptor.fd > 359: * public static java.util.List Foo.bar > 360: * Having such examples here means this method has a specified output that users can parse. We should move this to some non-normative section like an implementation note. (Don't know why github mobile didn't capture my comment before, I already commented yesterday) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2596780908 From xgong at openjdk.org Mon Dec 8 02:03:25 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 8 Dec 2025 02:03:25 GMT Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 01:42:07 GMT, Xiaohong Gong wrote: > The current subword (`byte`/`short`) gather load API implementation is not well-suited for platforms that provide native vector instructions for these operations. As **discussed in PR [1]**, we'd like to re-implement these APIs with a **unified cross-platform** solution. > > The main idea is to re-implement the API at Java-level, by performing multiple sub-gather operations. Each sub-gather operation loads a portion of elements using a specific index vector by calling the HotSpot intrinsic API. The partial results are then merged using vector `slice` and `or` operations. This design simplifies the VM compiler intrinsic implementation and better aligns with the Vector API design principles. > > Key changes: > 1. Re-implement the subword gather load API at the Java level. The HotSpot intrinsic `VectorSupport.loadWithMap` is simplified by reducing the vector index parameters from four (vix1-vix4) to a single parameter. > 2. Adjust the compiler intrinsic implementation to support the new Java API, including updates to the x86 backend implementation. > > The performance impact varies across different scenarios on X86. I tested the performance with different AVX levels on an X86 machine that supports AVX512. To achieve optimal performance, I also **applied PR [2]**, which improves the performance of the **`slice()`** API on X86. Following is the summarized performance gains, where: > > - "non masked" means the gather operation is not the masked gather API. > - "masked" means the gather operation is the masked gather API. > - "1 gather cases" means the gather API is implemented with a single gather operation. E.g. Load `Short128Vector` with `MaxVectorSize=256`. > - "2 gather cases" means the gather API is implemented with 2 parts of gather operations. E.g. Load `Short256Vector` with `MaxVectorSize=256`. > - "4 gather cases" means the gather API is implemented with 4 parts of gather operations. E.g. Load `Byte256Vector` with `MaxVectorSize=256`. > - "Un-intrinsified" means the gather operation is not supported to be intrinsified by hotspot. E.g. Load `Byte512Vector` with `MaxVectorSize=256`. The singificant performance uplifts comes from the Java-level changes which removes the vector index generation and range checks for such cases. > > > ---------------------------------------------------------------------------- > | UseAVX=3 | UseAVX=2 | > |-----------------------------|-----------------------------| > | non maske... ping ------------- PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3624161715 From liach at openjdk.org Mon Dec 8 02:08:37 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 02:08:37 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang 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 15 additional commits since the last revision: - Bugs and verify loader leak - Try to avoid loader leak - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure - Test from Jorn - Copyright years - Fix problem identified by Jorn - Rollback getAndAdd for now - Redundant change - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - ... and 5 more: https://git.openjdk.org/jdk/compare/295928d3...eebb8ff7 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/8200fb28..eebb8ff7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=06-07 Stats: 10547 lines in 389 files changed: 7296 ins; 2024 del; 1227 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From liach at openjdk.org Mon Dec 8 02:08:37 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 02:08:37 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v3] In-Reply-To: References: <7vA3xcZlxI6Z7C50Uopc-L4zaPa1opq-c-fy4ln34rQ=.7e4f1fd7-530b-41c1-8a04-9d024db31978@github.com> <5k9_zS-hTubx9WMd8lq30Ajq8xRDAjIEhmKaqnyrsCw=.09a5b646-6115-45f1-be39-f5a54b9dbdd4@github.com> <3OE37qXGHhLAhnRQM188hhygrLYBtI3FLBMK0tGVH30=.5d1b4406-3bb3-4788-8059-e78260b79ec1@github.com> <7WF8DlorrU_B2__G2wr43w1PZwJh8mEhD5dY10YDIOo=.ec416c38-1aff-4dd6-8792-d6a0e01f91ce@github.com> <_Z6KpxCYH2n3sHuT6-kRP4cSTAN3-s5UA0r bfrJSIgA=.e9d4089c-8329-406b-9a0a-167a24311c13@github.com> <5CADH75ZjadKttOKwsykRFUPlQKLiwCW8E5WkM_75a4=.fd992c8f-e8bc-4775-9ea3-d5212664e3df@github.com> <5QPAetQEkrBgFKtMt0i9Ku_4s2GCirMl2uqLH3j8x7g=.e5fc8964-0080-45f7-9005-31922ec06ba1@github.com> Message-ID: On Wed, 3 Dec 2025 13:34:40 GMT, Jorn Vernee wrote: >> Looking at this, I'm not sure we can assume that we only see one mode and type when the VH is constant. There seems to be a lot of non-local reasoning involved. >> >> For example, you could have a var handle invoker created with `MethodHandless::varHandleInvoker`, which is cached, so the `AccessDescriptor` can be shared among many different use sites. For an individual use-site, the receiver VH may well be a constant, but that doesn't mean that the cache isn't polluted by the var handle from another use site, as far as I can tell. >> >> The thread safety issue comes from a C2 thread racing to read the `lastAdaption` cache vs another Java thread writing to the cache. AFAICS, this race is still possible even when `vh` is a compile time constant. > > I think even without using an invoker, you could end up in a similar situation if you have something like: > > > static Object m(VarHandle vh) { > return vh.get(); > } > > > Which is called by several different threads. At some point this method may be inlined into one of its callees, where `vh` then becomes a constant. But at the same time, other threads are still writing to the cache. This issue should have been fixed, and there's a unit test to verify. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596829589 From liach at openjdk.org Mon Dec 8 02:08:37 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 02:08:37 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v6] In-Reply-To: <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com> References: <8tu3HIArCw2cdoYR2SjI0b-TWYQxQLKkjQgucJEj8D4=.10946ec2-4958-48df-add4-b29d11c09448@github.com> Message-ID: On Thu, 4 Dec 2025 01:55:57 GMT, Vladimir Ivanov wrote: >> I don't think we can use a SoftReference here if we need to achieve constant folding. >> >> Looking at inline_reference_get0, I think we might introduce another field property to trust a reference (potentially in an array) if both that reference and the referent within the reference is non-null. I think that belongs to a separate RFE. What do you think? > > Then it makes sense to limit the caching to safe cases only for now. Otherwise, it would functionally regress due to a possible memory leak. I have added a primitive checking system to ensure safety for most cases and added a unit test to ensure there is no memory leak due to this cache. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596829153 From liach at openjdk.org Mon Dec 8 02:08:38 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 02:08:38 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v7] In-Reply-To: References: <7ayMTZ4nXMyB1SXNRcYGjdxidNHDcAUNv_8fQZDUaPI=.a558d3a2-1d3e-4b45-8ba7-393c55a52785@github.com> Message-ID: On Fri, 5 Dec 2025 11:03:18 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > > test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 48: > >> 46: public static void main(String[] args) { >> 47: TestFramework.runWithFlags( >> 48: "-XX:+UnlockExperimentalVMOptions" > > Why is this flag needed? Indeed, simplified this to `TestFramework.run()` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2596827495 From erfang at openjdk.org Mon Dec 8 03:28:30 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 8 Dec 2025 03:28:30 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions Message-ID: The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. Problem: -------- UMIN was using MAX_OR_INF (signed maximum value) as the identity: - Byte.MAX_VALUE (127) instead of max unsigned byte (255) - Short.MAX_VALUE (32767) instead of max unsigned short (65535) - Integer.MAX_VALUE instead of max unsigned int (-1) - Long.MAX_VALUE instead of max unsigned long (-1) UMAX was using MIN_OR_INF (signed minimum value) as the identity: - Byte.MIN_VALUE (-128) instead of 0 - Short.MIN_VALUE (-32768) instead of 0 - Integer.MIN_VALUE instead of 0 - Long.MIN_VALUE instead of 0 This caused incorrect result. For example: UMAX([42,42,...,42]) returned 128 instead of 42 Solution: --------- Use correct unsigned identity values: - UMIN: ($type$)-1 (maximum unsigned value) - UMAX: ($type$)0 (minimum unsigned value) Changes: -------- - X-Vector.java.template: Fixed identity values in reductionOperations - gen-template.sh: Fixed identity values for test code generation - templates/Unit-header.template: Updated copyright year to 2025 - Regenerated all Vector classes and test files Testing: -------- All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. ------------- Commit messages: - 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions Changes: https://git.openjdk.org/jdk/pull/28692/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372978 Stats: 364 lines in 37 files changed: 0 ins; 0 del; 364 mod Patch: https://git.openjdk.org/jdk/pull/28692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28692/head:pull/28692 PR: https://git.openjdk.org/jdk/pull/28692 From erfang at openjdk.org Mon Dec 8 03:35:50 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 8 Dec 2025 03:35:50 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations Message-ID: This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance. Changes: -------- 1. C2 mid-end: - Added UMinReductionVNode and UMaxReductionVNode 2. AArch64 Backend: - Added uminp/umaxp/sve_uminv/sve_umaxv instructions - Updated match rules for all vector sizes and element types - Both NEON and SVE implementation are supported 3. Test: - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java - Added assembly tests in aarch64-asmtest.py for new instructions - Added a JTReg test file VectorUMinMaxReductionTest.java Different configurations were tested on aarch64 and x86 machines, and all tests passed. Test results of JMH benchmarks from the panama-vector project: -------- On a Nvidia Grace machine with 128-bit SVE: Benchmark Unit Before Error After Error Uplift Byte128Vector.UMAXLanes ops/ms 411.60 42.18 25226.51 33.92 61.29 Byte128Vector.UMAXMaskedLanes ops/ms 558.56 85.12 25182.90 28.74 45.09 Byte128Vector.UMINLanes ops/ms 645.58 780.76 28396.29 103.11 43.99 Byte128Vector.UMINMaskedLanes ops/ms 621.09 718.27 26122.62 42.68 42.06 Byte64Vector.UMAXLanes ops/ms 296.33 34.44 14357.74 15.95 48.45 Byte64Vector.UMAXMaskedLanes ops/ms 376.54 44.01 14269.24 21.41 37.90 Byte64Vector.UMINLanes ops/ms 373.45 426.51 15425.36 66.20 41.31 Byte64Vector.UMINMaskedLanes ops/ms 353.32 346.87 14201.37 13.79 40.19 Int128Vector.UMAXLanes ops/ms 174.79 192.51 9906.07 286.93 56.67 Int128Vector.UMAXMaskedLanes ops/ms 157.23 206.68 10246.77 11.44 65.17 Int64Vector.UMAXLanes ops/ms 95.30 126.49 4719.30 98.57 49.52 Int64Vector.UMAXMaskedLanes ops/ms 88.19 87.44 4693.18 19.76 53.22 Long128Vector.UMAXLanes ops/ms 80.62 97.82 5064.01 35.52 62.82 Long128Vector.UMAXMaskedLanes ops/ms 78.15 102.91 5028.24 8.74 64.34 Long64Vector.UMAXLanes ops/ms 47.56 62.01 46.76 52.28 0.98 Long64Vector.UMAXMaskedLanes ops/ms 45.44 46.76 45.79 42.91 1.01 Short128Vector.UMAXLanes ops/ms 316.65 410.30 14814.82 23.65 46.79 Short128Vector.UMAXMaskedLanes ops/ms 308.90 351.78 15155.26 31.03 49.06 Short64Vector.UMAXLanes ops/ms 190.38 245.09 8022.46 14.30 42.14 Short64Vector.UMAXMaskedLanes ops/ms 195.54 36.15 7930.28 11.88 40.56 On a Nvidia Grace machine with 128-bit NEON: Benchmark Unit Before Error After Error Uplift Byte128Vector.UMAXLanes ops/ms 414.69 42.52 25257.61 25.91 60.91 Byte128Vector.UMAXMaskedLanes ops/ms 552.00 56.61 23063.14 304.45 41.78 Byte128Vector.UMINLanes ops/ms 634.98 849.04 28444.37 180.80 44.80 Byte128Vector.UMINMaskedLanes ops/ms 612.88 735.18 26127.07 27.99 42.63 Byte64Vector.UMAXLanes ops/ms 291.53 32.19 13893.62 28.09 47.66 Byte64Vector.UMAXMaskedLanes ops/ms 363.34 48.17 13290.59 12.53 36.58 Byte64Vector.UMINLanes ops/ms 368.70 433.60 15416.90 15.80 41.81 Byte64Vector.UMINMaskedLanes ops/ms 350.46 371.05 14524.29 121.63 41.44 Int128Vector.UMAXLanes ops/ms 177.67 201.38 10182.82 20.21 57.31 Int128Vector.UMAXMaskedLanes ops/ms 155.25 187.88 9194.13 393.35 59.22 Int64Vector.UMAXLanes ops/ms 93.93 115.02 5106.79 4.54 54.37 Int64Vector.UMAXMaskedLanes ops/ms 87.01 88.50 4405.87 8.06 50.63 Long128Vector.UMAXLanes ops/ms 80.32 98.50 3229.80 40.53 40.21 Long128Vector.UMAXMaskedLanes ops/ms 77.65 103.25 3161.50 4.45 40.72 Long64Vector.UMAXLanes ops/ms 47.72 65.38 46.41 50.38 0.97 Long64Vector.UMAXMaskedLanes ops/ms 45.26 47.46 45.13 47.23 1.00 Short128Vector.UMAXLanes ops/ms 316.09 429.34 14748.07 14.78 46.66 Short128Vector.UMAXMaskedLanes ops/ms 307.70 342.54 14359.11 44.99 46.67 Short64Vector.UMAXLanes ops/ms 187.67 253.01 8180.63 178.65 43.59 Short64Vector.UMAXMaskedLanes ops/ms 191.10 33.51 7949.19 108.65 41.60 ------------- Commit messages: - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations - 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions Changes: https://git.openjdk.org/jdk/pull/28693/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372980 Stats: 1607 lines in 49 files changed: 835 ins; 16 del; 756 mod Patch: https://git.openjdk.org/jdk/pull/28693.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28693/head:pull/28693 PR: https://git.openjdk.org/jdk/pull/28693 From qamai at openjdk.org Mon Dec 8 05:17:57 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 8 Dec 2025 05:17:57 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: Message-ID: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> On Mon, 8 Dec 2025 03:22:31 GMT, Eric Fang wrote: > The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. > > Problem: > -------- > UMIN was using MAX_OR_INF (signed maximum value) as the identity: > - Byte.MAX_VALUE (127) instead of max unsigned byte (255) > - Short.MAX_VALUE (32767) instead of max unsigned short (65535) > - Integer.MAX_VALUE instead of max unsigned int (-1) > - Long.MAX_VALUE instead of max unsigned long (-1) > > UMAX was using MIN_OR_INF (signed minimum value) as the identity: > - Byte.MIN_VALUE (-128) instead of 0 > - Short.MIN_VALUE (-32768) instead of 0 > - Integer.MIN_VALUE instead of 0 > - Long.MIN_VALUE instead of 0 > > This caused incorrect result. For example: > UMAX([42,42,...,42]) returned 128 instead of 42 > > Solution: > --------- > Use correct unsigned identity values: > - UMIN: ($type$)-1 (maximum unsigned value) > - UMAX: ($type$)0 (minimum unsigned value) > > Changes: > -------- > - X-Vector.java.template: Fixed identity values in reductionOperations > - gen-template.sh: Fixed identity values for test code generation > - templates/Unit-header.template: Updated copyright year to 2025 > - Regenerated all Vector classes and test files > > Testing: > -------- > All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 4191: > 4189: } > 4190: > 4191: static byte UMINReduce(byte[] a, int idx) { We should test the reduction operations in a better manner by using `a[idx]` as the starting value instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2597076507 From erfang at openjdk.org Mon Dec 8 05:41:04 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 8 Dec 2025 05:41:04 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 05:15:24 GMT, Quan Anh Mai wrote: >> The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. >> >> Problem: >> -------- >> UMIN was using MAX_OR_INF (signed maximum value) as the identity: >> - Byte.MAX_VALUE (127) instead of max unsigned byte (255) >> - Short.MAX_VALUE (32767) instead of max unsigned short (65535) >> - Integer.MAX_VALUE instead of max unsigned int (-1) >> - Long.MAX_VALUE instead of max unsigned long (-1) >> >> UMAX was using MIN_OR_INF (signed minimum value) as the identity: >> - Byte.MIN_VALUE (-128) instead of 0 >> - Short.MIN_VALUE (-32768) instead of 0 >> - Integer.MIN_VALUE instead of 0 >> - Long.MIN_VALUE instead of 0 >> >> This caused incorrect result. For example: >> UMAX([42,42,...,42]) returned 128 instead of 42 >> >> Solution: >> --------- >> Use correct unsigned identity values: >> - UMIN: ($type$)-1 (maximum unsigned value) >> - UMAX: ($type$)0 (minimum unsigned value) >> >> Changes: >> -------- >> - X-Vector.java.template: Fixed identity values in reductionOperations >> - gen-template.sh: Fixed identity values for test code generation >> - templates/Unit-header.template: Updated copyright year to 2025 >> - Regenerated all Vector classes and test files >> >> Testing: >> -------- >> All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. > > test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 4191: > >> 4189: } >> 4190: >> 4191: static byte UMINReduce(byte[] a, int idx) { > > We should test the reduction operations in a better manner by using `a[idx]` as the starting value instead. Hi @merykitty thanks for the review, `a[idx]` is already the starting value for the reduction operation of this function, see line 4193. What do you mean by `a better manner` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2597109217 From dholmes at openjdk.org Mon Dec 8 05:46:11 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 8 Dec 2025 05:46:11 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe wrote: >> _This patch is not intended for JDK 26_. >> >> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. >> >> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp > > Co-authored-by: Andrew Haley I've completed a pass through everything and have a couple of comments on the functional changes. The tests were quite hard to follow in places and I've flagged a few where you seemed to have done a more extensive rewrite than what was actually needed for the obsoletion - making it hard to assess the changes. Thanks src/hotspot/share/memory/metaspace.cpp line 661: > 659: MaxMetaspaceSize = MAX2(MaxMetaspaceSize, commit_alignment()); > 660: > 661: if (using_class_space()) { Shouldn't this now just be a build-time `ifdef _LP64` check? src/hotspot/share/memory/metaspace.cpp line 728: > 726: } > 727: > 728: // a) if CDS is active (runtime, Xshare=on), it will create the class space You have left descriptions of a) and b) but now we have no idea what they are referring to. ??? src/hotspot/share/runtime/arguments.cpp line 1591: > 1589: > 1590: size_t heap_end = HeapBaseMinAddress + MaxHeapSize; > 1591: size_t max_coop_heap = max_heap_for_compressed_oops(); Please don't change the types in this PR. test/hotspot/jtreg/runtime/CompressedOops/CompressedClassPointers.java line 294: > 292: } > 293: > 294: public static void heapBaseMinAddressTestNoCoop() throws Exception { It is not obvious to me why this test case was deleted. test/hotspot/jtreg/runtime/ErrorHandling/TestVMConfigInHsErrFile.java line 59: > 57: switch (args[0]) { > 58: case "coh-on" -> testCompactObjectHeaders(); > 59: case "coh-off" -> testCompressedClassPointers(); You seem to have done a complete test rewrite here and it is not obvious to me it follows as part of the obsoletion of UCCP. test/hotspot/jtreg/runtime/cds/appcds/TestCombinedCompressedFlags.java line 67: > 65: private void initExecArgs() { > 66: // We fail this test if the UseCompressedOops setting used at dumptime differs from runtime, > 67: // succeed if it is identical This test seems to reduce to pretty much nothing. ?? test/hotspot/jtreg/runtime/cds/appcds/TestZGCWithCDS.java line 44: > 42: private final static String UNABLE_TO_USE_ARCHIVE = "Unable to use shared archive."; > 43: private final static String ERR_MSG = "The saved state of UseCompressedOops (0) is different from runtime (1), CDS will be disabled."; > 44: private final static String COMPACT_OBJECT_HEADERS = "-XX:+UseCompactObjectHeaders"; Again this test seems to have a lot of unrelated changes. This is obscuring the actual differences and makes the review harder. test/jdk/java/lang/instrument/GetObjectSizeIntrinsicsTest.java line 318: > 316: > 317: // Includes length, excludes alignment gap to base > 318: static final int ARRAY_HEADER_SIZE = Platform.is64bit() ? 16 : 12; Again unrelated change. test/jdk/jdk/jfr/event/gc/objectcount/ObjectCountEventVerifier.java line 75: > 73: final int bytesPerWord = runsOn32Bit ? 4 : 8; > 74: final int objectHeaderSize = runsOn32Bit ? 12 : 16; > 75: final int alignmentGap = runsOn32Bit ? 4 : 0; Again unrelated changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/28366#pullrequestreview-3550086639 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597013211 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597014493 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597023027 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597045861 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597050708 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597102266 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597107079 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597110703 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2597114451 From qamai at openjdk.org Mon Dec 8 05:46:56 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Mon, 8 Dec 2025 05:46:56 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 05:37:54 GMT, Eric Fang wrote: >> test/jdk/jdk/incubator/vector/Byte128VectorTests.java line 4191: >> >>> 4189: } >>> 4190: >>> 4191: static byte UMINReduce(byte[] a, int idx) { >> >> We should test the reduction operations in a better manner by using `a[idx]` as the starting value instead. > > Hi @merykitty thanks for the review, `a[idx]` is already the starting value for the reduction operation of this function, see line 4193. What do you mean by `a better manner` ? No, the starting value is `-1`, this test depends on the fact that we choose the correct identity value for this particular operation as the starting value, which this issue is about. As a result, it would be better to write the test so that we do not depend on the identity value. byte res = a[idx]; for (int i = idx + 1; i < (idx + SPECIES.length()); i++) { res = (byte) VectorMath.minUnsigned(res, a[i]); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2597119232 From varadam at openjdk.org Mon Dec 8 05:50:09 2025 From: varadam at openjdk.org (Varada M) Date: Mon, 8 Dec 2025 05:50:09 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error Message-ID: This change fixes incorrect lane ordering in reinterpretation operations on big-endian platforms. When converting from wider to narrower lane types like Long to Int, Long to Short, big-endian systems produced reversed sub-lanes. The patch adds a maybeSwapOnConverted() and a generic normalizeSubLanesForSpecies() shuffle builder to correct the sub-lane order based on element sizes on big-endian JBS: [JDK-8371187](https://bugs.openjdk.org/browse/JDK-8371187) ------------- Commit messages: - fix for vector alignment issue on big-endian Changes: https://git.openjdk.org/jdk/pull/28425/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371187 Stats: 114 lines in 7 files changed: 113 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28425.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28425/head:pull/28425 PR: https://git.openjdk.org/jdk/pull/28425 From amitkumar at openjdk.org Mon Dec 8 05:50:10 2025 From: amitkumar at openjdk.org (Amit Kumar) Date: Mon, 8 Dec 2025 05:50:10 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 12:05:36 GMT, Varada M wrote: > This change fixes incorrect lane ordering in reinterpretation operations on big-endian platforms. When converting from wider to narrower lane types like Long to Int, Long to Short, big-endian systems produced reversed sub-lanes. > The patch adds a maybeSwapOnConverted() and a generic normalizeSubLanesForSpecies() shuffle builder to correct the sub-lane order based on element sizes on big-endian > > JBS: [JDK-8371187](https://bugs.openjdk.org/browse/JDK-8371187) Fixes the issue for s390x. Tier1 with fastdebug vm doesn't show any regression. ------------- Marked as reviewed by amitkumar (Committer). PR Review: https://git.openjdk.org/jdk/pull/28425#pullrequestreview-3528984905 From erfang at openjdk.org Mon Dec 8 05:58:57 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 8 Dec 2025 05:58:57 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 05:43:38 GMT, Quan Anh Mai wrote: >> Hi @merykitty thanks for the review, `a[idx]` is already the starting value for the reduction operation of this function, see line 4193. What do you mean by `a better manner` ? > > No, the starting value is `-1`, this test depends on the fact that we choose the correct identity value for this particular operation as the starting value, which this issue is about. As a result, it would be better to write the test so that we do not depend on the identity value. > > byte res = a[idx]; > for (int i = idx + 1; i < (idx + SPECIES.length()); i++) { > res = (byte) VectorMath.minUnsigned(res, a[i]); > } Okay, I got your point. I think this might be to maintain consistency with `UMINReduceMasked`; for the masked version, if no element is selected, it returns the identity value. I'm okay with both approaches, maybe let?s hear what @PaulSandoz thinks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2597141410 From duke at openjdk.org Mon Dec 8 08:15:00 2025 From: duke at openjdk.org (ExE Boss) Date: Mon, 8 Dec 2025 08:15:00 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 02:08:37 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 15 additional commits since the last revision: > > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - Redundant change > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - ... and 5 more: https://git.openjdk.org/jdk/compare/17ebc456...eebb8ff7 make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 145: > 143: MethodHandle.linkToStatic(); > 144: } else { > 145: ad.adaptedMethodHandle(handle).invokeBasic(); The?old?version didn?t?use?`` in?`GUARD_METHOD_TEMPLATE_V`: Suggestion: ad.adaptedMethodHandle(handle).invokeBasic(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2597461675 From alanb at openjdk.org Mon Dec 8 09:09:16 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 09:09:16 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 21:35:57 GMT, Joe Darcy wrote: > Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. src/java.base/share/classes/java/lang/reflect/Field.java line 349: > 347: > 348: /** > 349: * {@return a string describing this {@code Field}} Field::toString has been specified this way since JDK 1.1 and we have to assume there are frameworks or libraries that would break if we were ever change the format of the String representation. Would it be possible to put more context for the proposal in the JBS or PR? I think I'm mostly trying to understand if this is just about readability or whether an incompatible change to the string representation might follow. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2597701327 From bkilambi at openjdk.org Mon Dec 8 10:38:12 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 8 Dec 2025 10:38:12 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Cleanups test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134: > 132: .intoArray(output, i); > 133: } > 134: for (; i < LEN; i++) { Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598040108 From epeter at openjdk.org Mon Dec 8 10:43:01 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 8 Dec 2025 10:43:01 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 10:35:23 GMT, Bhavana Kilambi wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Cleanups > > test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134: > >> 132: .intoArray(output, i); >> 133: } >> 134: for (; i < LEN; i++) { > > Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed? Yes: there could be auto-vectorization. No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right? It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598054314 From bkilambi at openjdk.org Mon Dec 8 11:27:59 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 8 Dec 2025 11:27:59 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 10:39:51 GMT, Emanuel Peter wrote: >> test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 134: >> >>> 132: .intoArray(output, i); >>> 133: } >>> 134: for (; i < LEN; i++) { >> >> Will this not result in autovectorization instead and also overwrite the `output` array results from vectorapi which were previously computed? > > Yes: there could be auto-vectorization. > No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right? > > It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization. Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598233546 From vklang at openjdk.org Mon Dec 8 11:36:25 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 8 Dec 2025 11:36:25 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics Message-ID: Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. ------------- Commit messages: - Adding Javadoc and specification for EnumSet::spliterator() Changes: https://git.openjdk.org/jdk/pull/28696/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28696&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373243 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28696/head:pull/28696 PR: https://git.openjdk.org/jdk/pull/28696 From vklang at openjdk.org Mon Dec 8 11:36:25 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 8 Dec 2025 11:36:25 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics In-Reply-To: References: Message-ID: <8x4NlMLRrGrrLh-S7f2Jf1PLKGE2bDXNjlJ0sK1gfZI=.288ee5f6-3c0c-4711-a53e-e9ddcf42c04c@github.com> On Mon, 8 Dec 2025 11:30:21 GMT, Viktor Klang wrote: > Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 > > Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. Tagging @jddarcy here since this issue was raised by him. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3626445267 From alanb at openjdk.org Mon Dec 8 12:16:56 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 12:16:56 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 11:30:21 GMT, Viktor Klang wrote: > Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 > > Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. src/java.base/share/classes/java/util/EnumSet.java line 512: > 510: * {@link Spliterator#DISTINCT}, {@link Spliterator#SORTED}, > 511: * {@link Spliterator#NONNULL}, and {@link Spliterator#ORDERED}. > 512: * Implementations should document the reporting of additional characteristic values. EnumSet is sealed and the permitted implementations are non-public/JDK-internal. I'm wondering if the override should be specified "as if" the class were final. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2598395899 From per-ake.minborg at oracle.com Mon Dec 8 12:31:37 2025 From: per-ake.minborg at oracle.com (Per-Ake Minborg) Date: Mon, 8 Dec 2025 12:31:37 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: So, it is nice that folks seem to agree that LazyConstant should only compute and initialize its contents from the Supplier/lambda given at declaration time. The orElse method seems to blur the contours of LazyConstant , and so, as previously said, we might consider removing the method altogether in the next preview. It is also a fact that many have identified a need for "something else more low-level" that supports a more imperative programming model when working with constants that are lazily set. We do not rule out that such a thing might appear in a future JDK version. Best, Per Confidential- Oracle Internal ________________________________ From: David Alayachew Sent: Friday, December 5, 2025 2:51 PM To: Red IO Cc: david Grajales ; Per-Ake Minborg ; amber-dev ; core-libs-dev Subject: [External] : Re: Feedback about LazyConstants API (JEP526) Caveat -- I have only used the Java 25 version of this library. I agree that the name orElse() is not intuitive. It was made more intuitive by the existence of orElseSet(). In its absence, changing the name makes sense. Though, I'm definitely open to just removing the method. This is easy enough to accomplish ourselves. Would prefer a rename though. On Fri, Dec 5, 2025, 8:32?AM Red IO > wrote: Hi David, As par already said the orElse method doesn't initializes the LazyConstant. It just checks rather the value is init and if not calls the supplier to get a substitute for the missing constant. Example: LazyConstant x = LazyConstant.of(() -> "Const"); var uninit1 = x.orElse(() -> "substitute 1"); var uninit2 = x.orElse(() -> "substitute 2"); var init1 = x.get(); var init2 = x.orElse(() -> "substitute 3"); uninit1 and uninit2 get the substitute 1/2 And init1 and init2 get Const. This is surprising if you expect it to be a way to init it with an alternative value. My suggestion would to make the separation clear and allow for another use case by spliting this api in 2 parts: One class LazyConstant Takes a Supplier in static factory and exposes get() And Class LazyInit Which takes no arguments in the static factory and takes a supplier in the get method that gets called when get is called for the first time. In this case the source for the constant can be any piece of code that has access to the LazyConstant. This might be desired in some cases. In cases where it's not the other version can be used. This split makes it clear from which context the constant is initialized from (consumer or at declaration) Mixing those 2 or having methods that appear to do this is rather confusing. One solution for the "i might not want to init the constant" case the "orElse" method is meant to be is to have a method "tryGet" which returns Optional instead. This makes it clear that the value might not be there and is not initialized when calling the method. Nobody expects to init the constant when calling orElse on a returned Optional. My 2 suggestions here are completely independent and should be viewed as such. Great regards RedIODev On Fri, Dec 5, 2025, 13:55 david Grajales > wrote: HI Per. I pleasure to talk with you. You are right about one thing but this actually makes the API less intuitive and harder to read and reason about. LazyConstant foo = LazyConstant.of(() -> "hello"); void main() { if (someCondition()) {// asume false foo.get(); } foo.orElse("hello2"); // ... println(foo.get()); // This prints "hello" } But if one assigns foo.orElse("hello2") to a variable, the variable actually gets the "hello2" value. void main() { if (someCondition()) {// asume false foo.get(); } var res = foo.orElse("hello2"); // ... var res2 = foo.orElse("hello3"); println(res); // This prints "hello2" println(res2);//This prints "hello3" } This is actually even more confusing and makes the API more error prone. I personally think once initialized the lazy constant should always return the same value (maybe through the .get() method only), and there should not be any possibility of getting a different values from the same instance either in the .of() static method or in any hypothetical instance method for conditional downstream logic. I guess one could achieve the latter with the static factory method through something like this (although less elegant) private class Bar{ private final LazyConstant foo; private Bar(Some some){ if(some.condition){ foo = LazyConstant.of(() -> "hello"); }else { foo = LazyConstant.of(() -> "hello2"); } } } Thank you for reading. This is all I have to report. Best regards. El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg (per-ake.minborg at oracle.com) escribi?: Hi David, Thank you for trying out LazyConstant and providing feedback. That is precisely what previews are for! If you take a closer look at the specification of LazyConstant::orElse, it says that the method will never trigger initialization. And so, you can actually be sure that in your first example, foo is always initialized to "hello" (if ever initialized). It is only if foo is not initialized that the method will return "hello2" (again, without initializing foo). This is similar to how Optional works. It would be possible to entirely remove the orElse() method from the API, and in the rare cases where an equivalent functionality is called for, rely on LazyConstant::isInitialized instead. Best, Per Confidential- Oracle Internal ________________________________ From: amber-dev > on behalf of david Grajales > Sent: Friday, December 5, 2025 5:38 AM To: amber-dev >; core-libs-dev at openjdk.org > Subject: Feedback about LazyConstants API (JEP526) Dear Java Dev Team, I am writing to provide feedback and two specific observations regarding the LazyConstant API, which is currently a preview feature in OpenJDK 26. I appreciate the API's direction and I think it's a good improvement compared to its first iteration; however, I see potential for improved expressiveness, particularly in conditional scenarios. 1. Proposal: Zero-Parameter `LazyConstant.of()` Overload: Currently, the mandatory use of a factory method receiving a `Supplier` (due to the lack of a public constructor) can obscure the expressiveness of conditional or multiple-value initialization paths. **The Issue:** When looking at the declaration: LazyConstant foo = LazyConstant.of(() -> "hello"); the code gives the strong, immediate impression that the value is always initialized to "hello". This makes it difficult to infer that the constant might ultimately resolve to an alternative value set later via orElse() or another conditional path, especially when skimming the code: LazyConstant foo = LazyConstant.of(() -> "hello"); // When skimming the code it's not always obvious that this may not be the actual value void main() { if (someCondition()) { foo.get(); // Trigger initialization to "hello" } // If someCondition is false, the final value of foo is determined here: var res1 = foo.orElse("hello2"); // ... } My Suggestion: I propose introducing a zero-parameter overloaded static factory method of(): LazyConstant foo = LazyConstant.of(); This form explicitly communicates that the constant is initialized to an unresolved state, suggesting that the value will be determined downstream by the first invocation of an initialization/computation method. LazyConstant foo = LazyConstant.of(); // Clearly unresolved void main() { if (someCondition()) { foo.orElse("hello"); } var res1 = foo.orElse("hello2"); // ... } This is specially useful for clarity when one has conditional initialization in places such as the constructor of a class. For example private class Bar{ LazyConstant foo = LazyConstant.of(); private Bar(Some some){ if(some.condition()){ foo.orElse("foo"); } foo.orElse("foo2"); } String computeValue() { return "hello"; } String computeValue2(){ return "hello2"; } } 2. Method Naming Suggestion and and supplier in instance method for consistency in the API My second, much more minor observation relates to the instance method orElse(T t). While orElse fits a retrieval pattern, I personally feel that compute or computeIfAbsent would better express the intent of this method, as its primary function is not just to retrieve, but to trigger the computation and set the final value of the constant if it is currently uninitialized. Also, as the factory of() has a supplier i think this instance method should also receive a Supplier, This not only keeps the API consistent in the usage but makes more ergonomic the declaration of complex initialization logic inside the method. private class Bar{ LazyConstant foo = LazyConstant.of(InitParam::default); // Under the current API this is mandatory but in reality the value is set in the constructor, default is never really used. private Bar(Some some){ foo.compute(some::executeCallToCacheDBAndBringInitializationParams) //Real configuration happens here } } This last it's very common for initialization of configuration classes and singletons. Thank you so much for your attention, I hope you find this feedback useful. Always yours. David Grajales -------------- next part -------------- An HTML attachment was scrubbed... URL: From luhenry at openjdk.org Mon Dec 8 13:13:00 2025 From: luhenry at openjdk.org (Ludovic Henry) Date: Mon, 8 Dec 2025 13:13:00 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li wrote: >> Hi, >> >> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. >> >> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. >> >> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. >> >> # Test >> ## Jtreg >> >> in progress... >> >> ## Performance >> >> Column names meanings: >> * p: with patch >> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> * m: without patch >> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> >> #### Average improvement >> >> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. >> >> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. >> >> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) >> -- | -- | -- | -- >> 1.022782609 | 2.198717391 | 2.162673913 | 2.199 >> >> > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - remove log_warning > - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp Marked as reviewed by luhenry (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3552013870 From iwalulya at openjdk.org Mon Dec 8 13:31:12 2025 From: iwalulya at openjdk.org (Ivan Walulya) Date: Mon, 8 Dec 2025 13:31:12 GMT Subject: RFR: 8363996: Obsolete UseCompressedClassPointers [v4] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 13:36:43 GMT, Thomas Stuefe wrote: >> _This patch is not intended for JDK 26_. >> >> I'm posting it now to collect feedback and, barring any objections, plan to push it once JDK 27 opens. >> >> This change removes the uncompressed Klass pointer mode and, with compressed Klass pointers remaining as the only option, the `UseCompressedClassPointers` switch. >> >> For motivation, please take a look at CSR associated with the deprecation (which we did for JDK 25) and the preparatory discussion we had at the start of the year around this topic [2]. >> >> This patch is quite invasive and touches many parts of the JVM, since its goal is to remove most traces of the uncompressed Klass path and to take advantage of opportunities for simplification. In some cases, I did not take opportunities for further simplification to keep the patch somewhat legible; it will be onerous enough to review. >> >> ### Implementation Notes >> >> With uncompressed Klass pointers removed, we have three modes of operation left (including 32-bit): >> a) 64-bit, COH off - this is the old `+UseCompressedClassPointers` mode. This is now the standard mode until we run with COH by default. >> b) 64-bit, COH on >> c) 32-bit - Here, we run with a "fake" narrow Klass pointer mode. We run with hardcoded narrowKlass base == NULL and shift = 0, so nKlass == Klass*. The difference to (a, b) is that we don't use a class space. This was implemented with JDK-8363998 [3] - for more details, please see that issue and its PR. >> >> I ensured *arm32* builds and I performed some rudimentary checks (selected metaspace/gc tests, and a simple Spring PetClinic run). Vendors with an interest in arm32 will have to step up and do their own, more thorough unit testing. Also, I did not see anyone doing follow-up work after JDK-8363998 [3] - so some issues may still lurk from that patch as well (but maybe JDK-8363998 was just not breaking anything). >> >> I did not check *zero 32-bit*, the only other platform supporting 32-bit. Anyone with an interest in 32-bit zero should chip in. >> >> Pre-existing errors: While working on this patch, I stumbled over a few occurrences of old but benign bugs. Mostly old code assuming CompressedClassPointers and CompressedOops were still tied together (example: Arguments::set_heap_size()). These bugs are implicitly fixed with this patch. >> >> ### Testing >> >> - tier 1 2 3 locally on Linux x64 >> - SAP ran their whole set of tests for all the platforms they support. >> >> >> [1] https://bugs.openjdk.org/browse/JDK-8350754 >> [2... > > Thomas Stuefe has updated the pull request incrementally with one additional commit since the last revision: > > Update src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp > > Co-authored-by: Andrew Haley src/hotspot/share/oops/instanceKlass.cpp line 492: > 490: assert(CompressedKlassPointers::is_encodable(ik), > 491: "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik)); > 492: } Suggestion: assert(ik == nullptr || CompressedKlassPointers::is_encodable(ik), "Klass " PTR_FORMAT "needs a narrow Klass ID, but is not encodable", p2i(ik)); src/hotspot/share/oops/oop.inline.hpp line 104: > 102: return CompressedKlassPointers::decode_not_null(_metadata._compressed_klass); > 103: default: > 104: return _metadata._klass; Suggestion: ShouldNotReachHere(); src/hotspot/share/oops/oop.inline.hpp line 115: > 113: return CompressedKlassPointers::decode(_metadata._compressed_klass); > 114: default: > 115: return _metadata._klass; Suggestion: ShouldNotReachHere(); src/hotspot/share/oops/oop.inline.hpp line 128: > 126: } > 127: default: > 128: return AtomicAccess::load_acquire(&_metadata._klass); Suggestion: ShouldNotReachHere(); src/hotspot/share/oops/oop.inline.hpp line 139: > 137: return CompressedKlassPointers::decode_without_asserts(_metadata._compressed_klass); > 138: default: > 139: return _metadata._klass; klass_mode() is either `Compact` or `Compressed` Should be changed to: Suggestion: ShouldNotReachHere(); src/hotspot/share/oops/oop.inline.hpp line 157: > 155: assert(Universe::is_bootstrapping() || (k != nullptr && k->is_klass()), "incorrect Klass"); > 156: assert(!UseCompactObjectHeaders, "don't set Klass* with compact headers"); > 157: _metadata._compressed_klass = CompressedKlassPointers::encode_not_null(k); We might have to reconsider if we need to maintain the`union _metadata` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598158553 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598641735 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598409080 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598413848 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598407527 PR Review Comment: https://git.openjdk.org/jdk/pull/28366#discussion_r2598474672 From epeter at openjdk.org Mon Dec 8 13:42:14 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 8 Dec 2025 13:42:14 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 1 Dec 2025 15:13:13 GMT, Hamlin Li wrote: >> Hi, >> >> This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. >> >> This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. >> >> Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. >> >> # Test >> ## Jtreg >> >> in progress... >> >> ## Performance >> >> Column names meanings: >> * p: with patch >> * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> * m: without patch >> * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on >> >> #### Average improvement >> >> NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. >> >> For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. >> >> Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) >> -- | -- | -- | -- >> 1.022782609 | 2.198717391 | 2.162673913 | 2.199 >> >> > > Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: > > - remove log_warning > - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :) I have a few comments below, to consider for improvement. test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39: > 37: * @summary Auto-vectorization enhancement to support vector conditional move. > 38: * @library /test/lib / > 39: * @run driver compiler.c2.irTests.TestConditionalMove Suggestion: * @run driver ${test.main.class} Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run. test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 1564: > 1562: // @IR(counts = {IRNode.CMOVE_I, ">0", IRNode.CMP_L, ">0"}, > 1563: // applyIf = {"UseVectorCmov", "false"}, > 1564: // applyIfPlatform = {"riscv64", "true"}) Why are these all commented out? test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 34: > 32: * @test > 33: * @summary Test conditional move + compare object. > 34: * @requires vm.simpleArch == "riscv64" It would be really nice if we generally have no platform requirements at the top of the file, but just IR test applyIf instead. That way, everyone benefits from everyone else's tests and we have less test duplication down the line. test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 356: > 354: }; > 355: } > 356: } You could use `Generators.java`, it creates "interesting" distributions, and makes sure we use sufficient special case values. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28309#pullrequestreview-3552071451 PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598623788 PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598632136 PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598660768 PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598654446 From mli at openjdk.org Mon Dec 8 13:42:15 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Dec 2025 13:42:15 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:10:28 GMT, Ludovic Henry wrote: >> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove log_warning >> - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp > > Marked as reviewed by luhenry (Committer). @luhenry Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626985436 From epeter at openjdk.org Mon Dec 8 13:42:16 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 8 Dec 2025 13:42:16 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:36:24 GMT, Hamlin Li wrote: >> Marked as reviewed by luhenry (Committer). > > @luhenry Thank you! @Hamlin-Li Oh bummer, I was just a few seconds too slow ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626995177 From mli at openjdk.org Mon Dec 8 13:42:17 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Dec 2025 13:42:17 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:36:38 GMT, Emanuel Peter wrote: > Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :) > > I have a few comments below, to consider for improvement. @eme64 Thanks for having a look. Seems there is a race condition here. :) I just triggered the integration. I'll file new bug to address your comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3626997007 From epeter at openjdk.org Mon Dec 8 13:42:19 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 8 Dec 2025 13:42:19 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:21:12 GMT, Emanuel Peter wrote: >> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove log_warning >> - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp > > test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39: > >> 37: * @summary Auto-vectorization enhancement to support vector conditional move. >> 38: * @library /test/lib / >> 39: * @run driver compiler.c2.irTests.TestConditionalMove > > Suggestion: > > * @run driver ${test.main.class} > > Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run. Also: if you are already renaming these tests, you might move them to a better directory as well. We want to avoid the `irTests` directory in the future, and sort by topic instead. Idea: put it under a `compiler/c2/cmove` directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2598664764 From mli at openjdk.org Mon Dec 8 13:42:20 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Dec 2025 13:42:20 GMT Subject: Integrated: 8357551: RISC-V: support CMoveF/D vectorization In-Reply-To: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> Message-ID: On Thu, 13 Nov 2025 21:34:30 GMT, Hamlin Li wrote: > Hi, > > This pr add CMoveF/D on riscv, which enable vectorization of statement like: `op_1 bop op_2 ? res_f_d_1 : res_f_d_2 in a loop`. > > This pr is also a preparation for further vectorization in https://github.com/openjdk/jdk/pull/28231. > > Previously it's https://github.com/openjdk/jdk/pull/25341, but at that time, C2 SLP has some issue with unsigned comparison, which is now fixed, so it's good to continue the work. > > # Test > ## Jtreg > > in progress... > > ## Performance > > Column names meanings: > * p: with patch > * p+v: with patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on > * m: without patch > * m+v: without patch, `-XX:+UseVectorCmov -XX:+UseCMoveUnconditionally` turned on > > #### Average improvement > > NOTE: With only this PR, it brings performance benefit in case of `CMoveF+CmpF`, `CMoveD+ComD`, `CMoveF+CmpI`, `CMoveD+CmpL`. The data below is based on fullly implmenting the vectorization of `CMoveI/L/F/D+CmpI/L/F/D`, which will be achieved by https://github.com/openjdk/jdk/pull/28231. > > For details, check the performance data in https://github.com/openjdk/jdk/pull/25341 on riscv. > > Opt (m/p) | Opt (m+v/p+v) | Opt (p/p+v) | Opt (m/p+v) > -- | -- | -- | -- > 1.022782609 | 2.198717391 | 2.162673913 | 2.199 > > This pull request has now been integrated. Changeset: 6700baa5 Author: Hamlin Li URL: https://git.openjdk.org/jdk/commit/6700baa5052046f53eb1b04ed3205bbd8e9e9070 Stats: 10199 lines in 15 files changed: 6731 ins; 3270 del; 198 mod 8357551: RISC-V: support CMoveF/D vectorization Reviewed-by: fyang, luhenry ------------- PR: https://git.openjdk.org/jdk/pull/28309 From epeter at openjdk.org Mon Dec 8 13:45:10 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 8 Dec 2025 13:45:10 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:39:23 GMT, Hamlin Li wrote: >> Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :) >> >> I have a few comments below, to consider for improvement. > >> Nice work! I did not review the RISC-V specific changes, but had a look at the tests. Wow, there are a lot of them, and that's a good thing :) >> >> I have a few comments below, to consider for improvement. > > @eme64 Thanks for having a look. > Seems there is a race condition here. :) I just triggered the integration. > I'll file new bug to address your comment. @Hamlin-Li Sounds good. I don't blame you, you had 2 reviewers ;) I also did not run internal testing. Most likely everything will be fine. Thanks for addressing my comments in the future, much appreciated! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28309#issuecomment-3627007431 From bkilambi at openjdk.org Mon Dec 8 14:14:17 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 8 Dec 2025 14:14:17 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: <9l2GpacNaxOlYFPSJe-nRiAm1cPWcxYxg65R0o0ElgE=.59208f2f-df36-4eb3-93ac-62ada0eca4d6@github.com> On Wed, 26 Nov 2025 11:34:11 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Cleanups test/hotspot/jtreg/compiler/vectorapi/TestFloat16VectorOperations.java line 82: > 80: output = new short[LEN]; > 81: > 82: short min_value = float16ToRawShortBits(Float16.MIN_VALUE); `min_value` and `max_value` not being used anywhere? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2598793109 From vklang at openjdk.org Mon Dec 8 14:18:39 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 8 Dec 2025 14:18:39 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics In-Reply-To: References: Message-ID: <8uZqnJf2WPrG7XovlDV4bLVkG2dIdI9jxT19LmpT5lo=.641cb9f1-f825-4458-ac15-f2542aee927d@github.com> On Mon, 8 Dec 2025 12:14:46 GMT, Alan Bateman wrote: >> Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 >> >> Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. > > src/java.base/share/classes/java/util/EnumSet.java line 512: > >> 510: * {@link Spliterator#DISTINCT}, {@link Spliterator#SORTED}, >> 511: * {@link Spliterator#NONNULL}, and {@link Spliterator#ORDERED}. >> 512: * Implementations should document the reporting of additional characteristic values. > > EnumSet is sealed and the permitted implementations are non-public/JDK-internal. I'm wondering if the override should be specified "as if" the class were final. I think I agree. So that'd mean removing "Implementations should document the reporting of additional characteristic values." _and_ making spliterator() **final** to ensure that it doesn't get invalidated by "accident". Does that sound reasonable to you? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2598805320 From alanb at openjdk.org Mon Dec 8 15:41:09 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 8 Dec 2025 15:41:09 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics In-Reply-To: <8uZqnJf2WPrG7XovlDV4bLVkG2dIdI9jxT19LmpT5lo=.641cb9f1-f825-4458-ac15-f2542aee927d@github.com> References: <8uZqnJf2WPrG7XovlDV4bLVkG2dIdI9jxT19LmpT5lo=.641cb9f1-f825-4458-ac15-f2542aee927d@github.com> Message-ID: On Mon, 8 Dec 2025 14:15:16 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/EnumSet.java line 512: >> >>> 510: * {@link Spliterator#DISTINCT}, {@link Spliterator#SORTED}, >>> 511: * {@link Spliterator#NONNULL}, and {@link Spliterator#ORDERED}. >>> 512: * Implementations should document the reporting of additional characteristic values. >> >> EnumSet is sealed and the permitted implementations are non-public/JDK-internal. I'm wondering if the override should be specified "as if" the class were final. > > I think I agree. So that'd mean removing "Implementations should document the reporting of additional characteristic values." _and_ making spliterator() **final** to ensure that it doesn't get invalidated by "accident". Does that sound reasonable to you? Yes, I think that would work. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2599095003 From jvernee at openjdk.org Mon Dec 8 17:54:02 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Dec 2025 17:54:02 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 02:08:37 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 15 additional commits since the last revision: > > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - Redundant change > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - ... and 5 more: https://git.openjdk.org/jdk/compare/513d3327...eebb8ff7 src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114: > 112: // but checking the signature type of MH mostly works > 113: return MethodHandle.isReachableFrom(vform.getMethodType(0), cl) > 114: && target.isReachableFrom(cl); Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well. FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem. Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check. src/java.base/share/classes/java/lang/invoke/MethodHandle.java line 983: > 981: } > 982: > 983: static boolean isBuiltinLoader(ClassLoader loader) { I think this can still be private? src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2018: > 2016: // Call MethodHandle.isReachableFrom for the used classes > 2017: return true; > 2018: } Can you make this `abstract`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599553053 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599496891 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599488329 From mli at openjdk.org Mon Dec 8 18:01:25 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Dec 2025 18:01:25 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:32:54 GMT, Emanuel Peter wrote: >> Hamlin Li has updated the pull request incrementally with two additional commits since the last revision: >> >> - remove log_warning >> - add test cases: BoolTest::ge/gt in enc_cmove_fp_cmp_fp > > test/hotspot/jtreg/compiler/c2/irTests/TestScalarConditionalMoveCmpObj.java line 34: > >> 32: * @test >> 33: * @summary Test conditional move + compare object. >> 34: * @requires vm.simpleArch == "riscv64" > > It would be really nice if we generally have no platform requirements at the top of the file, but just IR test applyIf instead. That way, everyone benefits from everyone else's tests and we have less test duplication down the line. addressed in https://github.com/openjdk/jdk/pull/28702. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2599583136 From mli at openjdk.org Mon Dec 8 18:01:22 2025 From: mli at openjdk.org (Hamlin Li) Date: Mon, 8 Dec 2025 18:01:22 GMT Subject: RFR: 8357551: RISC-V: support CMoveF/D vectorization [v7] In-Reply-To: References: <0errm4F59Sa9JdJZKdAGBnt9cF1DKkUUv1XmUtMmHI8=.ab9c0d54-799c-4385-b96c-d7c698ffe965@github.com> <4-PqNRUxM-80k4mQdYNzc0HrirtkTCjfVAzgRewW08M=.d2fe4512-16cd-4abf-8a7f-e91341c37110@github.com> Message-ID: On Mon, 8 Dec 2025 13:34:10 GMT, Emanuel Peter wrote: >> test/hotspot/jtreg/compiler/c2/irTests/TestConditionalMove.java line 39: >> >>> 37: * @summary Auto-vectorization enhancement to support vector conditional move. >>> 38: * @library /test/lib / >>> 39: * @run driver compiler.c2.irTests.TestConditionalMove >> >> Suggestion: >> >> * @run driver ${test.main.class} >> >> Might as well do that now. Avoids wrong copy of class name, which can lead to wrong test being run. > > Also: if you are already renaming these tests, you might move them to a better directory as well. We want to avoid the `irTests` directory in the future, and sort by topic instead. > > Idea: put it under a `compiler/c2/cmove` directory. addressed in https://github.com/openjdk/jdk/pull/28702. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28309#discussion_r2599583943 From jlu at openjdk.org Mon Dec 8 18:11:21 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 8 Dec 2025 18:11:21 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v4] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com> On Wed, 23 Jul 2025 17:39:12 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Further wording refinement Now that PR is open again, did another take and looks good as before. Minor test comments. test/jdk/java/util/Locale/LocaleTest.java line 712: > 710: Locale indonesianNew = Locale.of("id"); > 711: > 712: if (!hebrewOld.getLanguage().equals("he")) { Since we are using JUnit, these assertions would be cleaner as `assertEquals`. test/jdk/java/util/Locale/LocaleTest.java line 714: > 712: if (!hebrewOld.getLanguage().equals("he")) { > 713: fail("Got back wrong language code for old Hebrew: expected \"he\", got \"" > 714: + hebrewNew.getLanguage() + "\""); Here and below, I think these errors should be including the old language in the fail message, not the new language. i.e. `hebrewOld.getLanguage` instead of `hebrewNew.getLanguage`. ------------- PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3553326987 PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599560414 PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599581669 From liach at openjdk.org Mon Dec 8 18:29:05 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 18:29:05 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 17:49:41 GMT, Jorn Vernee wrote: >> Chen Liang 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 15 additional commits since the last revision: >> >> - Bugs and verify loader leak >> - Try to avoid loader leak >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure >> - Test from Jorn >> - Copyright years >> - Fix problem identified by Jorn >> - Rollback getAndAdd for now >> - Redundant change >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - ... and 5 more: https://git.openjdk.org/jdk/compare/50bcb546...eebb8ff7 > > src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114: > >> 112: // but checking the signature type of MH mostly works >> 113: return MethodHandle.isReachableFrom(vform.getMethodType(0), cl) >> 114: && target.isReachableFrom(cl); > > Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well. > > FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem. > > Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check. I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2599683049 From naoto at openjdk.org Mon Dec 8 19:08:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Dec 2025 19:08:46 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v5] In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: > This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Reflects review comments - Merge branch 'master' into JDK-8355522-Remove-useOldISOCodes - Further wording refinement - Obsolete comment correction - Reflects review comments - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26419/files - new: https://git.openjdk.org/jdk/pull/26419/files/c68a63be..965830aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=03-04 Stats: 664985 lines in 7465 files changed: 452015 ins; 138570 del; 74400 mod Patch: https://git.openjdk.org/jdk/pull/26419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419 PR: https://git.openjdk.org/jdk/pull/26419 From liach at openjdk.org Mon Dec 8 19:10:48 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 19:10:48 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: Message-ID: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> > Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) Chen Liang 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 17 additional commits since the last revision: - Review - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Bugs and verify loader leak - Try to avoid loader leak - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure - Test from Jorn - Copyright years - Fix problem identified by Jorn - Rollback getAndAdd for now - ... and 7 more: https://git.openjdk.org/jdk/compare/1f095c6b...d734e8a6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/eebb8ff7..d734e8a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=07-08 Stats: 11891 lines in 51 files changed: 8198 ins; 3438 del; 255 mod Patch: https://git.openjdk.org/jdk/pull/28585.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28585/head:pull/28585 PR: https://git.openjdk.org/jdk/pull/28585 From naoto at openjdk.org Mon Dec 8 19:13:02 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Dec 2025 19:13:02 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v4] In-Reply-To: <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com> References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> <4JtmPp-mY7Vcef5pgsZ-9eX5amI1v6om6WiFGFVTVE8=.63399559-e6b8-4e48-87e0-b0632e800f6b@github.com> Message-ID: On Mon, 8 Dec 2025 17:51:46 GMT, Justin Lu wrote: >> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: >> >> Further wording refinement > > test/jdk/java/util/Locale/LocaleTest.java line 712: > >> 710: Locale indonesianNew = Locale.of("id"); >> 711: >> 712: if (!hebrewOld.getLanguage().equals("he")) { > > Since we are using JUnit, these assertions would be cleaner as `assertEquals`. In this test file, there are other locations that use `fail`. Although it would be preferred to replace them with `assertEquals`, probably better be cleaned up with a separate issue. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2599806334 From sherman at openjdk.org Mon Dec 8 20:00:28 2025 From: sherman at openjdk.org (Xueming Shen) Date: Mon, 8 Dec 2025 20:00:28 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v4] In-Reply-To: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: > ### Summary > > - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result > - Add additional test data to the existing VectorMask from/toLong tests. > - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - update: restore boolUnaryOpProvider for reduction/Unit-BoolReduction-op.template - minor update - update - update - update - update - update - update - update - 8371446: VectorAPI: Add unit tests for masks from various long values ------------- Changes: https://git.openjdk.org/jdk/pull/28593/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28593&range=03 Stats: 9997 lines in 39 files changed: 6064 ins; 3550 del; 383 mod Patch: https://git.openjdk.org/jdk/pull/28593.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28593/head:pull/28593 PR: https://git.openjdk.org/jdk/pull/28593 From sherman at openjdk.org Mon Dec 8 20:08:57 2025 From: sherman at openjdk.org (Xueming Shen) Date: Mon, 8 Dec 2025 20:08:57 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v4] In-Reply-To: References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> <-neDMSn-oP4iH1Oq-iwoEbCBfSlIDxQqa95RcV-j_6U=.ecce34bf-c527-4de3-b410-997b127076e2@github.com> Message-ID: On Sat, 6 Dec 2025 00:40:32 GMT, Xueming Shen wrote: >> test/jdk/jdk/incubator/vector/templates/Unit-BoolUnary-op.template line 6: >> >>> 4: } >>> 5: >>> 6: @Test(dataProvider = "maskBinaryOpProvider") >> >> There is already "boolUnaryOpProvider" data provider can we use that and align the naming? > > "boolUnaryOpProvider" is used only by the mask reduction/Unit-BoolReduction-op.template. Renamed it to "boolMaskUnaryOpProvider" to be used by both reduction and unary-op/Unit-BoolUnary-op.template. > > - boolMaskUnaryOpProvider > - boolMaskBinaryOpProvider > - longMaskProvider > - maskProvider It appears adding "mask[i % 5]" to BOOLEAN_MASK_GENERATORS/boolMaskUnaryOpProvider may have exposed a potential bug in ByteVector.reduceLanes(VectorOperators.MUL, vmask). I have made the following updates to separate the "ByteVector.reduceLanes(VectorOperators.MUL, vmask)" issue from this PR. (1) Removed "mask[i % 5]" from BOOLEAN_MASK_GENERATORS (2) Restored boolUnaryOpProvider for reduction/Unit-BoolReduction-op.template ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28593#discussion_r2599967667 From aturbanov at openjdk.org Mon Dec 8 20:21:04 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 8 Dec 2025 20:21:04 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v5] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: On Mon, 8 Dec 2025 19:08:46 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Reflects review comments > - Merge branch 'master' into JDK-8355522-Remove-useOldISOCodes > - Further wording refinement > - Obsolete comment correction > - Reflects review comments > - initial commit src/java.base/share/classes/sun/util/locale/BaseLocale.java line 116: > 114: */ > 115: static { > 116: if (!System.getProperty("java.locale.useOldISOCodes", "").isEmpty()) { Hm. Why don't we compare result with null? Do we want to allow empty values `-Djava.locale.useOldISOCodes=` ? Suggestion: if (System.getProperty("java.locale.useOldISOCodes") != null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26419#discussion_r2600000217 From jvernee at openjdk.org Mon Dec 8 20:21:59 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 8 Dec 2025 20:21:59 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 1 Dec 2025 18:27:34 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > bracket styles I had a look at the document you wrote, but I think it still needs some work. I suggest maybe splitting that out into a separate PR. src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12: > 10: > 11: Constant folding means a read of a variable of a constant value can be replaced > 12: by the read constant value, during the construction of an IR graph. The I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran. We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated. Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field. I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples. ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3553830433 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2599952662 From liach at openjdk.org Mon Dec 8 20:51:00 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 20:51:00 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v4] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 20:00:20 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> bracket styles > > src/java.base/share/classes/jdk/internal/vm/annotation/constant-folding.md line 12: > >> 10: >> 11: Constant folding means a read of a variable of a constant value can be replaced >> 12: by the read constant value, during the construction of an IR graph. The > > I think think constant folding encompasses much more than just field loads. E.g. folding `3 + 4` into `7` is also constant folding. More abstractly, I'd say that constant folding is essentially running a computation at compile time. The JIT compiler tries to do some of the computations in the code that it is compiling at compile time, so that they don't have to be done over and over when the compiled code is ran. > > We can think of instance field loads as a computation that takes in an instance of an object, and returns the value of one of the fields. If the _input_ is a constant, it is that _computation_ that may be folded, and the _result_ of that computation is then also a constant. To do that fold, the JIT essentially has to determine if the computation will always return the same result when evaluated. > > Another important condition for folding field loads is that the input to that computation is always the same: namely the instance from which the field is loaded. Even if a field is a trusted final, if the instance from which that field is loaded may vary, the JIT will not treat the value of that field as 'constant'. I don't think it's necessarily wrong to say that a field 'is constant', but that doesn't guarantee that the JIT is able to constant fold loads from that field. > > I think the word 'constant' is a bit too vague on its own, and used to mean several different things. I detect some tension when reading the rest of this doc, where you say for instance 'may be constant', rather than the more decisive 'is constant'. For instance, a 'constant' is just a fixed value (such as '3'), but a 'constant field' is a field that can not be changed, and a load from a 'constant field' is not guaranteed to produce a (JIT) compile time 'constant'. I think you need to clearly define 'constant' earlier in the document, and potentially use different terms for these examples. Sure, I have created https://bugs.openjdk.org/browse/JDK-8373286 to track that effort instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2600090805 From naoto at openjdk.org Mon Dec 8 20:54:34 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 8 Dec 2025 20:54:34 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v6] In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: > This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26419/files - new: https://git.openjdk.org/jdk/pull/26419/files/965830aa..c427e188 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26419&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26419.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26419/head:pull/26419 PR: https://git.openjdk.org/jdk/pull/26419 From liach at openjdk.org Mon Dec 8 21:14:24 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 21:14:24 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v5] In-Reply-To: References: Message-ID: > Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. > > They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. > > We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. > > Paging @minborg who requested Optional folding for review. > > I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. Chen Liang 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 11 additional commits since the last revision: - Jorn review - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - bracket styles - Doc tweaks - Essay - Spurious change - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - Issue number and test update - Fixed optional and unit test - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - ... and 1 more: https://git.openjdk.org/jdk/compare/383203c0...b20b7f5b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/d353bdbe..b20b7f5b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=03-04 Stats: 38514 lines in 729 files changed: 24382 ins; 11087 del; 3045 mod Patch: https://git.openjdk.org/jdk/pull/28540.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28540/head:pull/28540 PR: https://git.openjdk.org/jdk/pull/28540 From jlu at openjdk.org Mon Dec 8 22:05:58 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 8 Dec 2025 22:05:58 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v6] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Andrey Turbanov Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3554248730 From fmatte at openjdk.org Mon Dec 8 22:13:20 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Mon, 8 Dec 2025 22:13:20 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Message-ID: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated ------------- Commit messages: - 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Changes: https://git.openjdk.org/jdk/pull/28708/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373270 Stats: 6 lines in 1 file changed: 5 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28708.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28708/head:pull/28708 PR: https://git.openjdk.org/jdk/pull/28708 From rriggs at openjdk.org Mon Dec 8 22:30:57 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 8 Dec 2025 22:30:57 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 21:35:57 GMT, Joe Darcy wrote: > Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. src/java.base/share/classes/java/lang/reflect/Field.java line 349: > 347: > 348: /** > 349: * {@return a string describing this {@code Field}} I don't see a compelling reason to backtrack on the format of toString. Its likely to break some application or description of the field to a user. src/java.base/share/classes/java/lang/reflect/Field.java line 365: > 363: * Specific information about {@linkplain #getModifiers() > 364: * modifiers} or other aspects of the field should be retrieved > 365: * using methods for that purpose. This is needlessly vague and gives an opportunity to reinforce the preferred order of modifiers. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600352283 PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600354349 From duke at openjdk.org Mon Dec 8 22:33:21 2025 From: duke at openjdk.org (fabioromano1) Date: Mon, 8 Dec 2025 22:33:21 GMT Subject: RFR: 8366478: BigDecimal roots [v34] In-Reply-To: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> References: <0x-ikTPM4Hq5VtgBqkdjfIhOShfjGpt5gtCH8X9vUes=.cf66834a-fbed-4f94-9f8b-f3c2e7ae64fd@github.com> Message-ID: > An implementation of `BigDecimal.nthRoot(int, MathContext)`. fabioromano1 has updated the pull request incrementally with one additional commit since the last revision: Update since version ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27148/files - new: https://git.openjdk.org/jdk/pull/27148/files/592c4776..ba4e2404 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=33 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27148&range=32-33 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27148.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27148/head:pull/27148 PR: https://git.openjdk.org/jdk/pull/27148 From psandoz at openjdk.org Mon Dec 8 23:31:57 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 8 Dec 2025 23:31:57 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 05:56:16 GMT, Eric Fang wrote: >> No, the starting value is `-1`, this test depends on the fact that we choose the correct identity value for this particular operation as the starting value, which this issue is about. As a result, it would be better to write the test so that we do not depend on the identity value. >> >> byte res = a[idx]; >> for (int i = idx + 1; i < (idx + SPECIES.length()); i++) { >> res = (byte) VectorMath.minUnsigned(res, a[i]); >> } > > Okay, I got your point. I think this might be to maintain consistency with `UMINReduceMasked`; for the masked version, if no element is selected, it returns the identity value. I'm okay with both approaches, maybe let?s hear what @PaulSandoz thinks. For masking we need to start with the identity or otherwise use the identify when no mask bits are set. It would be better to declare as constants and refer to them e.g., `UMAX_VALUE`, `UMIN_VALUE`. There are also other cases where we use identity values for reduction and they follow the same pattern of declaration and use. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2600503579 From liach at openjdk.org Mon Dec 8 23:46:58 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 8 Dec 2025 23:46:58 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 22:27:21 GMT, Roger Riggs wrote: >> Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. > > src/java.base/share/classes/java/lang/reflect/Field.java line 349: > >> 347: >> 348: /** >> 349: * {@return a string describing this {@code Field}} > > I don't see a compelling reason to backtrack on the format of toString. > Its likely to break some application or description of the field to a user. I think the reason to change the format is some future modifiers, like ACC_STRICT_INIT, won't get printed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600533536 From darcy at openjdk.org Mon Dec 8 23:56:56 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Dec 2025 23:56:56 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 09:06:13 GMT, Alan Bateman wrote: >> Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. > > src/java.base/share/classes/java/lang/reflect/Field.java line 349: > >> 347: >> 348: /** >> 349: * {@return a string describing this {@code Field}} > > Field::toString has been specified this way since JDK 1.1 and we have to assume there are frameworks or libraries that would break if we were ever change the format of the String representation. Would it be possible to put more context for the proposal in the JBS or PR? I think I'm mostly trying to understand if this is just about readability or whether an incompatible change to the string representation might follow. I don't have any implementation changes planned, but if there are new kinds of things added, I prefer to avoid treating the toString() method as a home for a context free grammar to provide all the necessary information about the item. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600550124 From darcy at openjdk.org Mon Dec 8 23:56:58 2025 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 8 Dec 2025 23:56:58 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: <6ZuASnynjlCyDB6vbAMxgvAo5p4TuLHV5XldK_zcSZQ=.86870a1b-a29b-419f-af8b-bef93546e3ad@github.com> References: <6ZuASnynjlCyDB6vbAMxgvAo5p4TuLHV5XldK_zcSZQ=.86870a1b-a29b-419f-af8b-bef93546e3ad@github.com> Message-ID: <_O4VKKmCxfUM66glOJACx8evoUVAyenm3pyx7Bk3i3g=.32539556-252b-4cc8-884c-2f4b76eaedc9@github.com> On Mon, 8 Dec 2025 01:14:19 GMT, Chen Liang wrote: >> Partial implementation of a spec refactoring to get some feedback before writing similar changes for other core reflection types. > > src/java.base/share/classes/java/lang/reflect/Field.java line 360: > >> 358: * private int java.io.FileDescriptor.fd >> 359: * public static java.util.List Foo.bar >> 360: * > > Having such examples here means this method has a specified output that users can parse. We should move this to some non-normative section like an implementation note. > > (Don't know why github mobile didn't capture my comment before, I already commented yesterday) Hmm. it is possible to move the examples so they are more clearly _informative_ rather than _normative_. As a counterpoint, the toString() spec for java.lang.annotation.Annotation states: > Returns a string representation of this annotation. The details of the representation are implementation-dependent, but the following may be regarded as typical: > > ` @com.example.Name(first="Duke", middle="of", last="Java")` Developers used this string successfully for informative purposes, even though the exact details have been changed (improved and corrected) a number of times over the years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600548329 From vlivanov at openjdk.org Tue Dec 9 00:03:57 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Tue, 9 Dec 2025 00:03:57 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) In-Reply-To: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> Message-ID: On Fri, 5 Dec 2025 09:44:16 GMT, Bhavana Kilambi wrote: > This patch adds an SVE implementation of primitive array sorting (Arrays.sort()) on AArch64 systems that support SVE. On non-SVE machines, we fall back to the existing Java implementation. > > For smaller arrays (length <= 64), we use insertion sort; for larger arrays we use an SVE-vectorized quicksort partitioner followed by an odd-even transposition cleanup pass. > > The SVE path is enabled by default for int type. For float type, it is available through the experimental flag : > > `-XX:+UnlockExperimentalVMOptions -XX:+UseSVELibSimdSortForFP > ` > Without this flag being enabled, the default Java implementation would be executed for floats (the flag is disabled by default). > > Float is gated due to observed regressions on some small/medium sizes. On larger arrays, the SVE float path shows upto 1.47x speedup on Neoverse V2 and 2.12x on Neoverse V1. > > Following are the performance numbers for **ArraysSort JMH benchmark** - > > **Case A:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag disabled (which is the default). > **Case B:** Ratio between the scores of master branch and `UseSVELibSimdSortForFP` flag enabled (the int numbers will be the same but this now enables SVE vectorized sorting for floats). > **We would want the ratios to be >= 1 to be at par or better than the default Java implementation (master branch).** > > On Neoverse V1: > > > Benchmark (size) Mode Cnt A B > ArraysSort.floatParallelSort 10 avgt 3 0.98 0.98 > ArraysSort.floatParallelSort 25 avgt 3 1.01 0.83 > ArraysSort.floatParallelSort 50 avgt 3 0.99 0.55 > ArraysSort.floatParallelSort 75 avgt 3 0.99 0.66 > ArraysSort.floatParallelSort 100 avgt 3 0.98 0.66 > ArraysSort.floatParallelSort 1000 avgt 3 1.00 0.84 > ArraysSort.floatParallelSort 10000 avgt 3 1.03 1.52 > ArraysSort.floatParallelSort 100000 avgt 3 1.03 1.46 > ArraysSort.floatParallelSort 1000000 avgt 3 0.98 1.81 > ArraysSort.floatSort 10 avgt 3 1.00 0.98 > ArraysSort.floatSort 25 avgt 3 1.00 0.81 > ArraysSort.floatSort 50 avgt 3 0.99 0.56 > ArraysSort.floatSort 75 avgt 3 0.99 0.65 > ArraysSort.floatSort 100 avgt 3 0.98 0.70 > ArraysSort.floatSort 1000 avgt 3 0.99 0.84 > ArraysSort.floatSort ... Good work, Bhavana! I reminds me of an effort I started a year ago to migrate native libraries to FFM. `vectormath` got integrated, but `libsimdsort` is still a draft: https://github.com/iwanowww/jdk/tree/libsimdsort.1 Since you do profound refactorings in the libsimdsort library code, I suggest to introduce SVE variant on top of FFM from the beginning. Let me finalize the PR and post it for review. What do you think? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3629564612 From darcy at openjdk.org Tue Dec 9 00:27:54 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 9 Dec 2025 00:27:54 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 23:44:02 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/reflect/Field.java line 349: >> >>> 347: >>> 348: /** >>> 349: * {@return a string describing this {@code Field}} >> >> I don't see a compelling reason to backtrack on the format of toString. >> Its likely to break some application or description of the field to a user. > > I think the reason to change the format is some future modifiers, like ACC_STRICT_INIT, won't get printed. Also, it helps avoid "attractive nuisance" questions like "how does the toString() of a bridge method indicate it is a bridge method"? (There is no such indication in the toString output, other than indirectly via the return type, but there is a Method.isBridge() predicate.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2600613169 From liach at openjdk.org Tue Dec 9 00:38:34 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Dec 2025 00:38:34 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance [v3] In-Reply-To: References: Message-ID: > The 3 methods to determine conversions and subtyping on `java.lang.Class`, which are `isInstance`, `cast`, and `isAssignableFrom`, have their documentation from the earliest days of the Java Platform. During the language evolution, a lot of terms have become inaccurate, such as "assignment-compatible", which does not apply for primitive types, and the out-of-date instanceof analogy with the upcoming patterns, in `isInstance`; `isAssignableFrom` is not very clear about arrays; `cast` would also benefit from more detailed explanations. > > In my facelift, I moved the subtyping description to `isAssignableFrom`, and left the conversion stuff in `isInstance` and `cast`. I intentionally avoided linking to too many JLS chapters to reduce confusions. I believe in this shape, we have a good amount of easily comprehensible yet accurate specification for all 3 methods, and users are welcome to read the linked JLS chapters for more details and context. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Non-null more straightforward than object - Merge branch 'master' of https://github.com/openjdk/jdk into doc/class-casts - Primitive type or void - Improve documentation of Class.isInstance ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28684/files - new: https://git.openjdk.org/jdk/pull/28684/files/4a4f2867..5fd09962 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=01-02 Stats: 12070 lines in 58 files changed: 8333 ins; 3439 del; 298 mod Patch: https://git.openjdk.org/jdk/pull/28684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28684/head:pull/28684 PR: https://git.openjdk.org/jdk/pull/28684 From fmatte at openjdk.org Tue Dec 9 00:49:22 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Tue, 9 Dec 2025 00:49:22 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: Message-ID: > 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: Correcting return from error condition ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28708/files - new: https://git.openjdk.org/jdk/pull/28708/files/2a9daf8b..046e8181 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28708.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28708/head:pull/28708 PR: https://git.openjdk.org/jdk/pull/28708 From liach at openjdk.org Tue Dec 9 00:52:27 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Dec 2025 00:52:27 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance [v4] In-Reply-To: References: Message-ID: > The 3 methods to determine conversions and subtyping on `java.lang.Class`, which are `isInstance`, `cast`, and `isAssignableFrom`, have their documentation from the earliest days of the Java Platform. During the language evolution, a lot of terms have become inaccurate, such as "assignment-compatible", which does not apply for primitive types, and the out-of-date instanceof analogy with the upcoming patterns, in `isInstance`; `isAssignableFrom` is not very clear about arrays; `cast` would also benefit from more detailed explanations. > > In my facelift, I moved the subtyping description to `isAssignableFrom`, and left the conversion stuff in `isInstance` and `cast`. I intentionally avoided linking to too many JLS chapters to reduce confusions. I believe in this shape, we have a good amount of easily comprehensible yet accurate specification for all 3 methods, and users are welcome to read the linked JLS chapters for more details and context. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Rewording from Kevin ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28684/files - new: https://git.openjdk.org/jdk/pull/28684/files/5fd09962..8dc4e31e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=02-03 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28684.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28684/head:pull/28684 PR: https://git.openjdk.org/jdk/pull/28684 From vklang at openjdk.org Tue Dec 9 01:18:48 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 9 Dec 2025 01:18:48 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: > Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 > > Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Removing verbiage around implementations documenting additional characteristics as well as making EnumSet::spliterator() final ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28696/files - new: https://git.openjdk.org/jdk/pull/28696/files/3b485d7c..780252ca Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28696&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28696&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28696/head:pull/28696 PR: https://git.openjdk.org/jdk/pull/28696 From vklang at openjdk.org Tue Dec 9 01:18:50 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 9 Dec 2025 01:18:50 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: <8uZqnJf2WPrG7XovlDV4bLVkG2dIdI9jxT19LmpT5lo=.641cb9f1-f825-4458-ac15-f2542aee927d@github.com> Message-ID: On Mon, 8 Dec 2025 15:38:22 GMT, Alan Bateman wrote: >> I think I agree. So that'd mean removing "Implementations should document the reporting of additional characteristic values." _and_ making spliterator() **final** to ensure that it doesn't get invalidated by "accident". Does that sound reasonable to you? > > Yes, I think that would work. Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2600702728 From liach at openjdk.org Tue Dec 9 01:31:46 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Dec 2025 01:31:46 GMT Subject: RFR: 8364588: Export the NPE backtracking functionality to general null-checking APIs [v5] In-Reply-To: References: Message-ID: <2QctOO9M2yu2_4OimyQAAcqcgK9MEfR-K99SsLl5Hno=.af6a8636-020e-4a7a-8cf2-263b966164cd@github.com> > Provide a general facility for our null check APIs like Objects::requireNonNull or future Checks::nullCheck (void), converting the existing infrastructure to start tracking from a given stack site (depth offset) and a given stack slot (offset value). > > This is a necessary prerequisite for https://bugs.openjdk.org/browse/JDK-8233268, which proposes enhanced null messages to `Objects::requireNonNull`. Chen Liang 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 18 additional commits since the last revision: - Update, review - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Update NPE per roger review - Use c++ enum classes per jdksjolen - Merge branch 'exp/requireNonNull-message-hacks' of github.com:liachmodded/jdk into exp/requireNonNull-message-hacks - Web review Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> - Merge branch 'master' of https://github.com/openjdk/jdk into exp/requireNonNull-message-hacks - Years - Roll back Objects.rNN for now - ... and 8 more: https://git.openjdk.org/jdk/compare/5fccdccb...2dafe83a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26600/files - new: https://git.openjdk.org/jdk/pull/26600/files/4ba1f17c..2dafe83a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26600&range=03-04 Stats: 636041 lines in 7152 files changed: 435596 ins; 128248 del; 72197 mod Patch: https://git.openjdk.org/jdk/pull/26600.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26600/head:pull/26600 PR: https://git.openjdk.org/jdk/pull/26600 From jvernee at openjdk.org Tue Dec 9 01:55:03 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 9 Dec 2025 01:55:03 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 17 additional commits since the last revision: > > - Review > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - ... and 7 more: https://git.openjdk.org/jdk/compare/b009bdb3...d734e8a6 Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3554899910 From erfang at openjdk.org Tue Dec 9 02:29:54 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 9 Dec 2025 02:29:54 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: <_E1Mhm4XOF5iCu2A_8lEksFtYVyQdafPIg9B97MUppk=.e40ab548-a72f-4eae-b197-e81841aee7d8@github.com> On Mon, 8 Dec 2025 23:29:33 GMT, Paul Sandoz wrote: >> Okay, I got your point. I think this might be to maintain consistency with `UMINReduceMasked`; for the masked version, if no element is selected, it returns the identity value. I'm okay with both approaches, maybe let?s hear what @PaulSandoz thinks. > > For masking we need to start with the identity or otherwise use the identify when no mask bits are set. It would be better to declare as constants and refer to them e.g., `UMAX_VALUE`, `UMIN_VALUE`. There are also other cases where we use identity values for reduction and they follow the same pattern of declaration and use. Hi @PaulSandoz thanks for your input. > It would be better to declare as constants and refer to them e.g., UMAX_VALUE, UMIN_VALUE. Do you mean adding two **public** constants to `Byte/Short/Integer/Long.java` ? Like `Byte.MIN_VALUE`. In this way, these two constants can be used in anywhere. Or just two **private** constants in `ByteVector.java`? Like `MAX_OR_INF`. I think you're referring to the former, right? To add a public constant, we need to go through the **CSR (Compatibility & Specification Review) process**, right? I haven't gone through that process before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2600838156 From darcy at openjdk.org Tue Dec 9 03:09:58 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 9 Dec 2025 03:09:58 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 01:18:48 GMT, Viktor Klang wrote: >> Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 >> >> Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Removing verbiage around implementations documenting additional characteristics as well as making EnumSet::spliterator() final src/java.base/share/classes/java/util/EnumSet.java line 505: > 503: } > 504: > 505: /** Hmm. Okay, the situation with LinkedHashSet is a bit different since it is a subclassable class and has the "talk about properties of the general contract of this method for this class and its subclasses" vs "talk about properties of _this_ particular method in _this_ class." Since this method in EnumSet is not overridden by the concrete non-visiable subclasses I agree it is fine to add a `final` modifier to the method. Since the method is `final` I think it would be fine to either elevate all the "The Spliterator is X, Y, and Z" is normal specification or to have an `impl*Spec*` tag where the properties are listed out, the distinction being that implSpec is normative rather than just informative like `implNote`. HTH ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2600907508 From darcy at openjdk.org Tue Dec 9 03:17:56 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 9 Dec 2025 03:17:56 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 01:18:48 GMT, Viktor Klang wrote: >> Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 >> >> Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Removing verbiage around implementations documenting additional characteristics as well as making EnumSet::spliterator() final PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3630044671 From joehw at openjdk.org Tue Dec 9 04:53:58 2025 From: joehw at openjdk.org (Joe Wang) Date: Tue, 9 Dec 2025 04:53:58 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v6] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Andrey Turbanov Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26419#pullrequestreview-3555443566 From kbarrett at openjdk.org Tue Dec 9 05:33:58 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Tue, 9 Dec 2025 05:33:58 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: Message-ID: <07Lh9_7S--m8fbhk_3OAOyxeP9s0PNPB9yYYFs4Bw4c=.f05b1e1d-cd5e-4528-9fb6-c0145f9e542a@github.com> On Tue, 9 Dec 2025 00:49:22 GMT, Fairoz Matte wrote: >> 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated > > Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: > > Correcting return from error condition src/java.base/unix/native/libjli/java_md_common.c line 286: > 284: return (0); > 285: } > 286: Why not just delete this no longer used function? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28708#discussion_r2601150598 From swen at openjdk.org Tue Dec 9 06:15:41 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 9 Dec 2025 06:15:41 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v6] In-Reply-To: References: Message-ID: > This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. > > When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. > > Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. > > Parsing scenarios show improvements from 12% to 95% Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: Revert "resolverFields, from @liach" This reverts commit b2b19e1368ef9b295876e6b79f8bfb163f3b3f1c. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28471/files - new: https://git.openjdk.org/jdk/pull/28471/files/b2b19e13..90dca377 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=04-05 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471 From duke at openjdk.org Tue Dec 9 06:18:57 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 9 Dec 2025 06:18:57 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 01:18:48 GMT, Viktor Klang wrote: >> Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 >> >> Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. > > Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: > > Removing verbiage around implementations documenting additional characteristics as well as making EnumSet::spliterator() final src/java.base/share/classes/java/util/EnumSet.java line 507: > 505: /** > 506: * Creates a late-binding > 507: * and fail-fast {@code Spliterator} over the elements in this set. I don't think the `EnumSet` spliterator is fail-fast, since its iterator is [weakly consistent](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/EnumSet.java#L41-L46). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2601245522 From erfang at openjdk.org Tue Dec 9 07:09:54 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 9 Dec 2025 07:09:54 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 05:43:38 GMT, Quan Anh Mai wrote: >> Hi @merykitty thanks for the review, `a[idx]` is already the starting value for the reduction operation of this function, see line 4193. What do you mean by `a better manner` ? > > No, the starting value is `-1`, this test depends on the fact that we choose the correct identity value for this particular operation as the starting value, which this issue is about. As a result, it would be better to write the test so that we do not depend on the identity value. > > byte res = a[idx]; > for (int i = idx + 1; i < (idx + SPECIES.length()); i++) { > res = (byte) VectorMath.minUnsigned(res, a[i]); > } Hi @merykitty , I feel it's better to start the reduction operation from `the identity value`, because `firstNonZero`, `min/max`, and `umin/umax` all reuse the same template function `gen_reduction_op_func`. If we start from `a[idx]` for `umin/umax` (`min/max` is also possible), then we have to create a new template function. Considering we've already correctly fixed this issue, I think the current approach might be more maintainable. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601369650 From qamai at openjdk.org Tue Dec 9 07:13:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 9 Dec 2025 07:13:54 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Tue, 9 Dec 2025 07:07:04 GMT, Eric Fang wrote: >> No, the starting value is `-1`, this test depends on the fact that we choose the correct identity value for this particular operation as the starting value, which this issue is about. As a result, it would be better to write the test so that we do not depend on the identity value. >> >> byte res = a[idx]; >> for (int i = idx + 1; i < (idx + SPECIES.length()); i++) { >> res = (byte) VectorMath.minUnsigned(res, a[i]); >> } > > Hi @merykitty , I feel it's better to start the reduction operation from `the identity value`, because `firstNonZero`, `min/max`, and `umin/umax` all reuse the same template function `gen_reduction_op_func`. If we start from `a[idx]` for `umin/umax` (`min/max` is also possible), then we have to create a new template function. Considering we've already correctly fixed this issue, I think the current approach might be more maintainable. What do you think? @erifan I don't see why `firstNonZero` cannot do the same and start from `a[idx]` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601379419 From erfang at openjdk.org Tue Dec 9 07:56:59 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 9 Dec 2025 07:56:59 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Tue, 9 Dec 2025 07:11:09 GMT, Quan Anh Mai wrote: >> Hi @merykitty , I feel it's better to start the reduction operation from `the identity value`, because `firstNonZero`, `min/max`, and `umin/umax` all reuse the same template function `gen_reduction_op_func`. If we start from `a[idx]` for `umin/umax` (`min/max` is also possible), then we have to create a new template function. Considering we've already correctly fixed this issue, I think the current approach might be more maintainable. What do you think? > > @erifan I don't see why `firstNonZero` cannot do the same and start from `a[idx]` here? @merykitty I apologize for not being clear. Actually, It's `SUADDReduce` that doesn't allow starting with `a[idx]` because that would result in `a[idx]` being added twice. Specifically, this happens as follows: `gen_saturating_reduction_op` (used to generate `SUADDReduce`) and `gen_reduction_op_func` (used to generate `umin/umax, etc.`) both use the `Unit-Reduction-Scalar-op.template` template. When we modify it, `SUADDReduce` is also affected. Therefore, a new template needs to be defined. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601494745 From qamai at openjdk.org Tue Dec 9 08:03:57 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 9 Dec 2025 08:03:57 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Tue, 9 Dec 2025 07:54:05 GMT, Eric Fang wrote: >> @erifan I don't see why `firstNonZero` cannot do the same and start from `a[idx]` here? > > @merykitty I apologize for not being clear. Actually, It's `SUADDReduce` that doesn't allow starting with `a[idx]` because that would result in `a[idx]` being added twice. > > Specifically, this happens as follows: `gen_saturating_reduction_op` (used to generate `SUADDReduce`) and `gen_reduction_op_func` (used to generate `umin/umax, etc.`) both use the `Unit-Reduction-Scalar-op.template` template. When we modify it, `SUADDReduce` is also affected. Therefore, a new template needs to be defined. But then the loop can start from `idx + 1` instead of `idx`, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601512724 From erfang at openjdk.org Tue Dec 9 08:15:55 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 9 Dec 2025 08:15:55 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: <0bwGyj9aBfdGLdQAow6xycUfR2px4JelBI_mwKJaFSY=.ccc4a30c-fdca-4e9c-8d8a-78dc73efca7d@github.com> On Tue, 9 Dec 2025 08:01:07 GMT, Quan Anh Mai wrote: >> @merykitty I apologize for not being clear. Actually, It's `SUADDReduce` that doesn't allow starting with `a[idx]` because that would result in `a[idx]` being added twice. >> >> Specifically, this happens as follows: `gen_saturating_reduction_op` (used to generate `SUADDReduce`) and `gen_reduction_op_func` (used to generate `umin/umax, etc.`) both use the `Unit-Reduction-Scalar-op.template` template. When we modify it, `SUADDReduce` is also affected. Therefore, a new template needs to be defined. > > But then the loop can start from `idx + 1` instead of `idx`, right? What I really wanted to talk about was code consistency and maintainability. There are many ways to handle this problem if we want to. I just think the current code style might be more maintainable, since the masked version is written this way too. The code looks more consistent. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601545153 From qamai at openjdk.org Tue Dec 9 08:25:05 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 9 Dec 2025 08:25:05 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: <0bwGyj9aBfdGLdQAow6xycUfR2px4JelBI_mwKJaFSY=.ccc4a30c-fdca-4e9c-8d8a-78dc73efca7d@github.com> References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> <0bwGyj9aBfdGLdQAow6xycUfR2px4JelBI_mwKJaFSY=.ccc4a30c-fdca-4e9c-8d8a-78dc73efca7d@github.com> Message-ID: On Tue, 9 Dec 2025 08:13:33 GMT, Eric Fang wrote: >> But then the loop can start from `idx + 1` instead of `idx`, right? > > What I really wanted to talk about was code consistency and maintainability. There are many ways to handle this problem if we want to. I just think the current code style might be more maintainable, since the masked version is written this way too. The code looks more consistent. Consistency does not mean much if the test does not actually do its job adequately, though. Since the very reason this test does not catch this issue is that it is just a repetition of the thing it supposedly verifies, I think it is necessary to write the test in a different way. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601571064 From jbhateja at openjdk.org Tue Dec 9 08:30:14 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 9 Dec 2025 08:30:14 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v6] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Optimizing tail handling - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Cleanups - Fix failing jtreg test in CI - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Cleanups - Adding support for custom basic type T_FLOAT16, passing BasicType lane types to inline expander entries - Cleaning up interface as per review suggestions - Some cleanups - Fix some JTREG failures - ... and 9 more: https://git.openjdk.org/jdk/compare/5f083aba...e830d855 ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 509573 lines in 231 files changed: 281304 ins; 226541 del; 1728 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From jbhateja at openjdk.org Tue Dec 9 08:30:15 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 9 Dec 2025 08:30:15 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v5] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 11:25:22 GMT, Bhavana Kilambi wrote: >> Yes: there could be auto-vectorization. >> No: `i` is not reset, it keeps counting from where `i < SPECIES.loopBound(LEN)` fails, and handles the tail, right? >> >> It could be good to run this test once with and once without auto vectorization, just to make sure the vectors you see are from the Vector API, and not auto vectorization. > > Thanks. I missed that `i` isn't being reinitialised/reset again. Do we even need the tail loop in this case when the `LEN = 2048`? We may not even have any tail iterations? @Bhavana-Kilambi vectorDim is a parameterizable parameter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2601582561 From erfang at openjdk.org Tue Dec 9 08:33:11 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 9 Dec 2025 08:33:11 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Mon, 8 Dec 2025 23:29:33 GMT, Paul Sandoz wrote: >> Okay, I got your point. I think this might be to maintain consistency with `UMINReduceMasked`; for the masked version, if no element is selected, it returns the identity value. I'm okay with both approaches, maybe let?s hear what @PaulSandoz thinks. > > For masking we need to start with the identity or otherwise use the identify when no mask bits are set. It would be better to declare as constants and refer to them e.g., `UMAX_VALUE`, `UMIN_VALUE`. There are also other cases where we use identity values for reduction and they follow the same pattern of declaration and use. Okay, I understand, thank you for your insight! I'll wait for @PaulSandoz 's comment and see if we should add two **public** constants to this PR. Then I'll modify it accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2601593342 From swen at openjdk.org Tue Dec 9 10:02:36 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 9 Dec 2025 10:02:36 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: > This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. > > When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. > > Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. > > Parsing scenarios show improvements from 12% to 95% Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: remove redundant checkField ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28471/files - new: https://git.openjdk.org/jdk/pull/28471/files/90dca377..9a13e51e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28471&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28471/head:pull/28471 PR: https://git.openjdk.org/jdk/pull/28471 From maurizio.cimadamore at oracle.com Tue Dec 9 10:25:26 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 10:25:26 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: Message-ID: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> I agree with most of the conclusions in this thread. One small nit is that, in reality, `orElse` is a "primitive" in disguise. E.g. you can implement `get` in terms of `orElse` but not the other way around (unless you are willing to do _two_ accessed to the underlying value). So, while we could drop it, we would also lose something (which is why we decided to keep it, at least for now). Maurizio On 08/12/2025 12:31, Per-Ake Minborg wrote: > So, it is nice that folks seem to agree that |LazyConstant|?should > only compute and initialize its contents from the Supplier/lambda > given at declaration time. The |orElse|?method seems to blur the > contours of |LazyConstant|?, and so, as previously said, we might > consider removing the method altogether in the next preview. > > It is also a fact that many have identified a need for "something else > more low-level" that supports a more imperative programming model when > working with constants that are lazily set. We do not rule out that > such a thing might appear in a future JDK version. > > Best, Per > > Confidential- Oracle Internal > ------------------------------------------------------------------------ > *From:* David Alayachew > *Sent:* Friday, December 5, 2025 2:51 PM > *To:* Red IO > *Cc:* david Grajales ; Per-Ake Minborg > ; amber-dev ; > core-libs-dev > *Subject:* [External] : Re: Feedback about LazyConstants API (JEP526) > Caveat -- I have only used the Java 25 version of this library. > > I agree that the name orElse() is not intuitive. It was made more > intuitive by the existence of orElseSet(). In its absence, changing > the name makes sense. > > Though, I'm definitely open to just removing the method. This is easy > enough to accomplish ourselves. Would prefer a rename though. > > On Fri, Dec 5, 2025, 8:32?AM Red IO wrote: > > Hi David, > As par already said the orElse method doesn't initializes the > LazyConstant. > It just checks rather the value is init and if not calls the > supplier to get a substitute for the missing constant. > Example: > LazyConstant x = LazyConstant.of(() -> "Const"); > var uninit1 = x.orElse(() -> "substitute 1"); > var uninit2 = x.orElse(() -> "substitute 2"); > var init1 = x.get(); > var init2 = x.orElse(() -> "substitute 3"); > uninit1 and uninit2 get the substitute 1/2 > And init1 and init2 get Const. > > This is surprising if you expect it to be a way to init it with an > alternative value. > > My suggestion would to make the separation clear and allow for > another use case by spliting this api in 2 parts: > One class LazyConstant > Takes a Supplier in static factory and exposes get() > > And > Class LazyInit > Which takes no arguments in the static factory and takes a > supplier in the get method that gets called when get is called for > the first time. > In this case the source for the constant can be any piece of code > that has access to the LazyConstant. This might be desired in some > cases. In cases where it's not the other version can be used. > > This split makes it clear from which context the constant is > initialized from (consumer or at declaration) > > Mixing those 2 or having methods that appear to do this is rather > confusing. > > > > One solution for the "i might not want to init the constant" case > the "orElse" method is meant to be is to have a method "tryGet" > which returns Optional instead. This makes it clear that the value > might not be there and is not initialized when calling the method. > Nobody expects to init the constant when calling orElse on a > returned Optional. > > My 2 suggestions here are completely independent and should be > viewed as such. > > Great regards > RedIODev > > On Fri, Dec 5, 2025, 13:55 david Grajales > wrote: > > HI Per. I pleasure to talk with you. > > You are right about one thing but this actually makes the API > less intuitive and harder to read and reason about. > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > void main() { > ? ? if (someCondition()) {// asume false > ? ? ? ? foo.get(); > ? ? } > ? ? foo.orElse("hello2"); // ... > > ? ? println(foo.get()); // This prints "hello" > } > > But if one assigns foo.orElse("hello2") to a variable, the > variable actually gets the "hello2" value. > > void main() { > ? ? if (someCondition()) {// asume false > ? ? ? ? foo.get(); > ? ? } > ? ? var res = foo.orElse("hello2"); // ... > ? ? var res2 = foo.orElse("hello3"); > ? ? println(res); // This prints "hello2" > ? ? println(res2);//This prints "hello3" > } > > This is actually even more confusing and makes the API more > error prone. I personally think once initialized the lazy > constant should always return the same value (maybe through > the .get() method only), and there should not be any > possibility of getting a different values?from the same > instance either in the .of() static method or in any > hypothetical instance method for conditional downstream > logic.? I guess one could achieve the latter with the static > factory method through?something like this (although?less elegant) > > private class Bar{ > ? ? private final LazyConstant foo; > ? ? private Bar(Some some){ > > ? ? ? ? if(some.condition){ > ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello"); > ? ? ? ? }else { > ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello2"); > ? ? ? ? } > ? ? } > } > > Thank you for reading. This is all I have to report. > > Best regards. > > > > El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg > (per-ake.minborg at oracle.com) escribi?: > > Hi David, > > Thank you for trying out LazyConstant and providing > feedback. That is precisely what previews are for! > > If you take a closer look at the specification of > |LazyConstant::orElse,|?it says that the method will > /never trigger initialization./?And so, you /can/?actually > be sure that in your first example, |foo|?is always > initialized to "hello" (if ever initialized). It is only > if foo is not initialized that the method will return > "hello2" (again, without initializing foo). This is > similar to how |Optional|?works. > > It would be possible to entirely remove the > |orElse()|?method from the API, and in the rare cases > where an equivalent functionality is called for, rely on > |LazyConstant::isInitialized|?instead. > > Best, Per > > > Confidential- Oracle Internal > ------------------------------------------------------------------------ > *From:* amber-dev on behalf > of david Grajales > *Sent:* Friday, December 5, 2025 5:38 AM > *To:* amber-dev ; > core-libs-dev at openjdk.org > *Subject:* Feedback about LazyConstants API (JEP526) > Dear Java Dev Team, > > ?I am writing to provide feedback and two specific > observations regarding the LazyConstant API, which is > currently a preview feature in OpenJDK 26. > > ?I appreciate the API's direction and I think it's a good > improvement compared to its first iteration; however, I > see potential for improved expressiveness, particularly in > conditional scenarios. > > > *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* > > Currently, the mandatory use of a factory method receiving > a `Supplier` (due to the lack of a public constructor) can > obscure the expressiveness of conditional or > multiple-value initialization paths. **The Issue:** When > looking at the declaration: > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > the code gives the strong, immediate impression that the > value is *always* initialized to |"hello"|. This makes it > difficult to infer that the constant might ultimately > resolve to an alternative value set later via |orElse()| > or another conditional path, especially when skimming the > code: > > LazyConstant foo = LazyConstant.of(() -> "hello"); > // When skimming the code it's not always obvious that > this may not be the actual value > void main() { > if (someCondition()) { > ? ? ? ? ? foo.get(); // Trigger initialization to "hello" > ?} > // If someCondition is false, the final value of foo is > determined here: > var res1 = foo.orElse("hello2"); // ... > } > > *My Suggestion:* I propose introducing a *zero-parameter > overloaded static factory method* |of()|: > > LazyConstant foo = LazyConstant.of(); > > This form explicitly communicates that the constant is > initialized to an *unresolved* state, suggesting that the > value will be determined downstream by the first > invocation of an initialization/computation method. > > LazyConstant foo = LazyConstant.of(); // Clearly > unresolved > void main() { > if (someCondition()) { > ? ? ? foo.orElse("hello"); > ?} > var res1 = foo.orElse("hello2"); // ... > } > > This is specially useful for clarity when one has > conditional initialization in places such as the > constructor of a class. For example > > private class Bar{ > ? ? LazyConstant foo = LazyConstant.of(); > ? ? private Bar(Some some){ > ? ? ? ? if(some.condition()){ > ? ? ? ? ? ? foo.orElse("foo"); > ? ? ? ? } > ? ? ? ? foo.orElse("foo2"); > ? ? } > > ? ? String computeValue() { > ? ? ? ? return "hello"; > ? ? } > > ? ? String computeValue2(){ > ? ? ? ? return "hello2"; > ? ? } > } > > > 2. Method Naming Suggestion and and supplier in > instance method for consistency in the API > > My second, much more minor observation relates to the > instance method |orElse(T t)|. > > While |orElse| fits a retrieval pattern, I personally feel > that *|compute|* or *|computeIfAbsent|* would better > express the intent of this method, as its primary function > is not just to retrieve, but to trigger the computation > and *set the final value* of the constant if it is > currently uninitialized. Also, as the factory of() has a > supplier i think this instance method should also receive > a Supplier, This not only keeps the API consistent in the > usage but makes more ergonomic the declaration of complex > initialization logic inside the method. > > > private class Bar{ > ? ? LazyConstant foo = > LazyConstant.of(InitParam::default); // Under the current > API this is mandatory but in reality the value is set in > the constructor, default is never really used. > ? ? private Bar(Some some){ > ?foo.compute(some::executeCallToCacheDBAndBringInitializationParams) > //Real configuration happens here > > ? ? } > } > > This last it's very common for initialization of > configuration classes and singletons. > > > Thank you so much for your attention, I hope you find this > feedback useful. > > Always yours. David Grajales > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vklang at openjdk.org Tue Dec 9 11:17:18 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 9 Dec 2025 11:17:18 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v3] In-Reply-To: References: Message-ID: > Addresses https://bugs.openjdk.org/browse/JDK-8373243 by copying and adapting the specification from https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/util/LinkedHashSet.java#L186-L204 > > Since EnumSet is sealed and only permits two final classes, the verbiage around "Implementations should document the reporting of additional characteristic values." may be considered to get removed from this PR. Kept, for now, for symmetry reasons. Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: Documenting that the EnumSet::spliterator() is non-fail-fast, and change implNote to implSpec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28696/files - new: https://git.openjdk.org/jdk/pull/28696/files/780252ca..6a588fcd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28696&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28696&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28696.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28696/head:pull/28696 PR: https://git.openjdk.org/jdk/pull/28696 From vklang at openjdk.org Tue Dec 9 11:17:21 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 9 Dec 2025 11:17:21 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 03:07:24 GMT, Joe Darcy wrote: >> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision: >> >> Removing verbiage around implementations documenting additional characteristics as well as making EnumSet::spliterator() final > > src/java.base/share/classes/java/util/EnumSet.java line 505: > >> 503: } >> 504: >> 505: /** > > Hmm. Okay, the situation with LinkedHashSet is a bit different since it is a subclassable class and has the "talk about properties of the general contract of this method for this class and its subclasses" vs "talk about properties of _this_ particular method in _this_ class." > > Since this method in EnumSet is not overridden by the concrete non-visiable subclasses I agree it is fine to add a `final` modifier to the method. Since the method is `final` I think it would be fine to either elevate all the "The Spliterator is X, Y, and Z" is normal specification or to have an `impl*Spec*` tag where the properties are listed out, the distinction being that implSpec is normative rather than just informative like `implNote`. HTH @jddarcy Done! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2602195542 From maurizio.cimadamore at oracle.com Tue Dec 9 11:22:13 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 11:22:13 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> Message-ID: <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> On 09/12/2025 11:15, Anatoly Kupriyanov wrote: > That's seems exactly opposite. The `get` returns initial value always > making the constant initialised by calling compute. > The `orElse(v)` is a shortcut for `c.isInitialized() ? c.get() : v`. Not really :-) c.isInitialized also calls `getAcquire` internally (so your snippet would end up calling getAcquire twice in some? paths, once for isInitialized, and another for get). Technically, get() can be explained as: V value = lazyConstant.orElse(sentinel) if (value == sentinel) throw new NoSuchElementException That performs only one call to getAcquire, not two. (We don't implement it exactly this way, but we could). Maurizio > > WBR, Anatoly. > > On Tue, 9 Dec 2025, 10:25 Maurizio Cimadamore, > wrote: > > I agree with most of the conclusions in this thread. > > > One small nit is that, in reality, `orElse` is a "primitive" in > disguise. E.g. you can implement `get` in terms of `orElse` but > not the other way around (unless you are willing to do _two_ > accessed to the underlying value). So, while we could drop it, we > would also lose something (which is why we decided to keep it, at > least for now). > > > Maurizio > > > > On 08/12/2025 12:31, Per-Ake Minborg wrote: >> So, it is nice that folks seem to agree that >> |LazyConstant|?should only compute and initialize its contents >> from the Supplier/lambda given at declaration time. The >> |orElse|?method seems to blur the contours of |LazyConstant|?, >> and so, as previously said, we might consider removing the method >> altogether in the next preview. >> >> It is also a fact that many have identified a need for "something >> else more low-level" that supports a more imperative programming >> model when working with constants that are lazily set. We do not >> rule out that such a thing might appear in a future JDK version. >> >> Best, Per >> >> Confidential- Oracle Internal >> ------------------------------------------------------------------------ >> *From:* David Alayachew >> >> *Sent:* Friday, December 5, 2025 2:51 PM >> *To:* Red IO >> >> *Cc:* david Grajales >> ; Per-Ake Minborg >> ; >> amber-dev ; >> core-libs-dev >> >> *Subject:* [External] : Re: Feedback about LazyConstants API >> (JEP526) >> Caveat -- I have only used the Java 25 version of this library. >> >> I agree that the name orElse() is not intuitive. It was made more >> intuitive by the existence of orElseSet(). In its absence, >> changing the name makes sense. >> >> Though, I'm definitely open to just removing the method. This is >> easy enough to accomplish ourselves. Would prefer a rename though. >> >> On Fri, Dec 5, 2025, 8:32?AM Red IO >> wrote: >> >> Hi David, >> As par already said the orElse method doesn't initializes the >> LazyConstant. >> It just checks rather the value is init and if not calls the >> supplier to get a substitute for the missing constant. >> Example: >> LazyConstant x = LazyConstant.of(() -> "Const"); >> var uninit1 = x.orElse(() -> "substitute 1"); >> var uninit2 = x.orElse(() -> "substitute 2"); >> var init1 = x.get(); >> var init2 = x.orElse(() -> "substitute 3"); >> uninit1 and uninit2 get the substitute 1/2 >> And init1 and init2 get Const. >> >> This is surprising if you expect it to be a way to init it >> with an alternative value. >> >> My suggestion would to make the separation clear and allow >> for another use case by spliting this api in 2 parts: >> One class LazyConstant >> Takes a Supplier in static factory and exposes get() >> >> And >> Class LazyInit >> Which takes no arguments in the static factory and takes a >> supplier in the get method that gets called when get is >> called for the first time. >> In this case the source for the constant can be any piece of >> code that has access to the LazyConstant. This might be >> desired in some cases. In cases where it's not the other >> version can be used. >> >> This split makes it clear from which context the constant is >> initialized from (consumer or at declaration) >> >> Mixing those 2 or having methods that appear to do this is >> rather confusing. >> >> >> >> One solution for the "i might not want to init the constant" >> case the "orElse" method is meant to be is to have a method >> "tryGet" which returns Optional instead. This makes it clear >> that the value might not be there and is not initialized when >> calling the method. Nobody expects to init the constant when >> calling orElse on a returned Optional. >> >> My 2 suggestions here are completely independent and should >> be viewed as such. >> >> Great regards >> RedIODev >> >> On Fri, Dec 5, 2025, 13:55 david Grajales >> wrote: >> >> HI Per. I pleasure to talk with you. >> >> You are right about one thing but this actually makes the >> API less intuitive and harder to read and reason about. >> >> LazyConstant foo = LazyConstant.of(() -> "hello"); >> >> void main() { >> ? ? if (someCondition()) {// asume false >> ? ? ? ? foo.get(); >> ? ? } >> ? ? foo.orElse("hello2"); // ... >> >> ? ? println(foo.get()); // This prints "hello" >> } >> >> But if one assigns foo.orElse("hello2") to a variable, >> the variable actually gets the "hello2" value. >> >> void main() { >> ? ? if (someCondition()) {// asume false >> ? ? ? ? foo.get(); >> ? ? } >> ? ? var res = foo.orElse("hello2"); // ... >> ? ? var res2 = foo.orElse("hello3"); >> ? ? println(res); // This prints "hello2" >> ? ? println(res2);//This prints "hello3" >> } >> >> This is actually even more confusing and makes the API >> more error prone. I personally think once initialized the >> lazy constant should always return the same value (maybe >> through the .get() method only), and there should not be >> any possibility of getting a different values?from the >> same instance either in the .of() static method or in any >> hypothetical instance method for conditional downstream >> logic.? I guess one could achieve the latter with the >> static factory method through?something like this >> (although?less elegant) >> >> private class Bar{ >> ? ? private final LazyConstant foo; >> ? ? private Bar(Some some){ >> >> ? ? ? ? if(some.condition){ >> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello"); >> ? ? ? ? }else { >> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello2"); >> ? ? ? ? } >> ? ? } >> } >> >> Thank you for reading. This is all I have to report. >> >> Best regards. >> >> >> >> El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg >> (per-ake.minborg at oracle.com) escribi?: >> >> Hi David, >> >> Thank you for trying out LazyConstant and providing >> feedback. That is precisely what previews are for! >> >> If you take a closer look at the specification of >> |LazyConstant::orElse,|?it says that the method will >> /never trigger initialization./?And so, you >> /can/?actually be sure that in your first example, >> |foo|?is always initialized to "hello" (if ever >> initialized). It is only if foo is not initialized >> that the method will return "hello2" (again, without >> initializing foo). This is similar to how >> |Optional|?works. >> >> It would be possible to entirely remove the >> |orElse()|?method from the API, and in the rare cases >> where an equivalent functionality is called for, rely >> on |LazyConstant::isInitialized|?instead. >> >> Best, Per >> >> >> Confidential- Oracle Internal >> ------------------------------------------------------------------------ >> *From:* amber-dev on >> behalf of david Grajales >> *Sent:* Friday, December 5, 2025 5:38 AM >> *To:* amber-dev ; >> core-libs-dev at openjdk.org >> *Subject:* Feedback about LazyConstants API (JEP526) >> Dear Java Dev Team, >> >> ?I am writing to provide feedback and two specific >> observations regarding the LazyConstant API, which is >> currently a preview feature in OpenJDK 26. >> >> ?I appreciate the API's direction and I think it's a >> good improvement compared to its first iteration; >> however, I see potential for improved expressiveness, >> particularly in conditional scenarios. >> >> >> *1. Proposal: Zero-Parameter `LazyConstant.of()` >> Overload:* >> >> Currently, the mandatory use of a factory method >> receiving a `Supplier` (due to the lack of a public >> constructor) can obscure the expressiveness of >> conditional or multiple-value initialization paths. >> **The Issue:** When looking at the declaration: >> >> LazyConstant foo = LazyConstant.of(() -> >> "hello"); >> >> the code gives the strong, immediate impression that >> the value is *always* initialized to |"hello"|. This >> makes it difficult to infer that the constant might >> ultimately resolve to an alternative value set later >> via |orElse()| or another conditional path, >> especially when skimming the code: >> >> LazyConstant foo = LazyConstant.of(() -> >> "hello"); // When skimming the code it's not always >> obvious that this may not be the actual value >> void main() { >> if (someCondition()) { >> ? ? ? ? ? foo.get(); // Trigger initialization to >> "hello" >> ?} >> // If someCondition is false, the final value of foo >> is determined here: >> var res1 = foo.orElse("hello2"); // ... >> } >> >> *My Suggestion:* I propose introducing a >> *zero-parameter overloaded static factory method* |of()|: >> >> LazyConstant foo = LazyConstant.of(); >> >> This form explicitly communicates that the constant >> is initialized to an *unresolved* state, suggesting >> that the value will be determined downstream by the >> first invocation of an initialization/computation method. >> >> LazyConstant foo = LazyConstant.of(); // >> Clearly unresolved >> void main() { >> if (someCondition()) { >> ? ? ? foo.orElse("hello"); >> ?} >> var res1 = foo.orElse("hello2"); // ... >> } >> >> This is specially useful for clarity when one has >> conditional initialization in places such as the >> constructor of a class. For example >> >> private class Bar{ >> ? ? LazyConstant foo = LazyConstant.of(); >> ? ? private Bar(Some some){ >> ? ? ? ? if(some.condition()){ >> ? ? ? ? ? ? foo.orElse("foo"); >> ? ? ? ? } >> ? ? ? ? foo.orElse("foo2"); >> ? ? } >> >> ? ? String computeValue() { >> ? ? ? ? return "hello"; >> ? ? } >> >> ? ? String computeValue2(){ >> ? ? ? ? return "hello2"; >> ? ? } >> } >> >> >> 2. Method Naming Suggestion and and supplier in >> instance method for consistency in the API >> >> My second, much more minor observation relates to the >> instance method |orElse(T t)|. >> >> While |orElse| fits a retrieval pattern, I personally >> feel that *|compute|* or *|computeIfAbsent|* would >> better express the intent of this method, as its >> primary function is not just to retrieve, but to >> trigger the computation and *set the final value* of >> the constant if it is currently uninitialized. Also, >> as the factory of() has a supplier i think this >> instance method should also receive a Supplier, This >> not only keeps the API consistent in the usage but >> makes more ergonomic the declaration of complex >> initialization logic inside the method. >> >> >> private class Bar{ >> LazyConstant foo = >> LazyConstant.of(InitParam::default); // Under the >> current API this is mandatory but in reality the >> value is set in the constructor, default is never >> really used. >> ? ? private Bar(Some some){ >> ?foo.compute(some::executeCallToCacheDBAndBringInitializationParams) >> //Real configuration happens here >> >> ? ? } >> } >> >> This last it's very common for initialization of >> configuration classes and singletons. >> >> >> Thank you so much for your attention, I hope you find >> this feedback useful. >> >> Always yours. David Grajales >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Dec 9 11:25:07 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 11:25:07 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> Message-ID: <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Hit send too fast... Yes, orElse alone can't set/compute the uninitialized value. So that's a problem (as you observed) But orElse can't also be explained in terms of get() -- unless you accept doing a double access of the underlying storage. Uplevelling, I believe the fact that, in the current form, neither API sits cleanly on top of the other is probably a part of the problem highlighted in this discussion. Maurizio On 09/12/2025 11:22, Maurizio Cimadamore wrote: > > > On 09/12/2025 11:15, Anatoly Kupriyanov wrote: >> That's seems exactly opposite. The `get` returns initial value always >> making the constant initialised by calling compute. >> The `orElse(v)` is a shortcut for `c.isInitialized() ? c.get() : v`. > > Not really :-) > > c.isInitialized also calls `getAcquire` internally (so your snippet > would end up calling getAcquire twice in some? paths, once for > isInitialized, and another for get). > > Technically, get() can be explained as: > > V value = lazyConstant.orElse(sentinel) > if (value == sentinel) throw new NoSuchElementException > > That performs only one call to getAcquire, not two. > > (We don't implement it exactly this way, but we could). > > Maurizio > >> >> WBR, Anatoly. >> >> On Tue, 9 Dec 2025, 10:25 Maurizio Cimadamore, >> wrote: >> >> I agree with most of the conclusions in this thread. >> >> >> One small nit is that, in reality, `orElse` is a "primitive" in >> disguise. E.g. you can implement `get` in terms of `orElse` but >> not the other way around (unless you are willing to do _two_ >> accessed to the underlying value). So, while we could drop it, we >> would also lose something (which is why we decided to keep it, at >> least for now). >> >> >> Maurizio >> >> >> >> On 08/12/2025 12:31, Per-Ake Minborg wrote: >>> So, it is nice that folks seem to agree that >>> |LazyConstant|?should only compute and initialize its contents >>> from the Supplier/lambda given at declaration time. The >>> |orElse|?method seems to blur the contours of |LazyConstant|?, >>> and so, as previously said, we might consider removing the >>> method altogether in the next preview. >>> >>> It is also a fact that many have identified a need for >>> "something else more low-level" that supports a more imperative >>> programming model when working with constants that are lazily >>> set. We do not rule out that such a thing might appear in a >>> future JDK version. >>> >>> Best, Per >>> >>> Confidential- Oracle Internal >>> ------------------------------------------------------------------------ >>> *From:* David Alayachew >>> >>> *Sent:* Friday, December 5, 2025 2:51 PM >>> *To:* Red IO >>> >>> *Cc:* david Grajales >>> ; Per-Ake Minborg >>> >>> ; amber-dev >>> ; >>> core-libs-dev >>> >>> *Subject:* [External] : Re: Feedback about LazyConstants API >>> (JEP526) >>> Caveat -- I have only used the Java 25 version of this library. >>> >>> I agree that the name orElse() is not intuitive. It was made >>> more intuitive by the existence of orElseSet(). In its absence, >>> changing the name makes sense. >>> >>> Though, I'm definitely open to just removing the method. This is >>> easy enough to accomplish ourselves. Would prefer a rename though. >>> >>> On Fri, Dec 5, 2025, 8:32?AM Red IO >>> wrote: >>> >>> Hi David, >>> As par already said the orElse method doesn't initializes >>> the LazyConstant. >>> It just checks rather the value is init and if not calls the >>> supplier to get a substitute for the missing constant. >>> Example: >>> LazyConstant x = LazyConstant.of(() -> "Const"); >>> var uninit1 = x.orElse(() -> "substitute 1"); >>> var uninit2 = x.orElse(() -> "substitute 2"); >>> var init1 = x.get(); >>> var init2 = x.orElse(() -> "substitute 3"); >>> uninit1 and uninit2 get the substitute 1/2 >>> And init1 and init2 get Const. >>> >>> This is surprising if you expect it to be a way to init it >>> with an alternative value. >>> >>> My suggestion would to make the separation clear and allow >>> for another use case by spliting this api in 2 parts: >>> One class LazyConstant >>> Takes a Supplier in static factory and exposes get() >>> >>> And >>> Class LazyInit >>> Which takes no arguments in the static factory and takes a >>> supplier in the get method that gets called when get is >>> called for the first time. >>> In this case the source for the constant can be any piece of >>> code that has access to the LazyConstant. This might be >>> desired in some cases. In cases where it's not the other >>> version can be used. >>> >>> This split makes it clear from which context the constant is >>> initialized from (consumer or at declaration) >>> >>> Mixing those 2 or having methods that appear to do this is >>> rather confusing. >>> >>> >>> >>> One solution for the "i might not want to init the constant" >>> case the "orElse" method is meant to be is to have a method >>> "tryGet" which returns Optional instead. This makes it clear >>> that the value might not be there and is not initialized >>> when calling the method. Nobody expects to init the constant >>> when calling orElse on a returned Optional. >>> >>> My 2 suggestions here are completely independent and should >>> be viewed as such. >>> >>> Great regards >>> RedIODev >>> >>> On Fri, Dec 5, 2025, 13:55 david Grajales >>> wrote: >>> >>> HI Per. I pleasure to talk with you. >>> >>> You are right about one thing but this actually makes >>> the API less intuitive and harder to read and reason about. >>> >>> LazyConstant foo = LazyConstant.of(() -> "hello"); >>> >>> void main() { >>> ? ? if (someCondition()) {// asume false >>> ? ? ? ? foo.get(); >>> ? ? } >>> ? ? foo.orElse("hello2"); // ... >>> >>> ? ? println(foo.get()); // This prints "hello" >>> } >>> >>> But if one assigns foo.orElse("hello2") to a variable, >>> the variable actually gets the "hello2" value. >>> >>> void main() { >>> ? ? if (someCondition()) {// asume false >>> ? ? ? ? foo.get(); >>> ? ? } >>> ? ? var res = foo.orElse("hello2"); // ... >>> ? ? var res2 = foo.orElse("hello3"); >>> ? ? println(res); // This prints "hello2" >>> ? ? println(res2);//This prints "hello3" >>> } >>> >>> This is actually even more confusing and makes the API >>> more error prone. I personally think once initialized >>> the lazy constant should always return the same value >>> (maybe through the .get() method only), and there should >>> not be any possibility of getting a different >>> values?from the same instance either in the .of() static >>> method or in any hypothetical instance method for >>> conditional downstream logic.? I guess one could achieve >>> the latter with the static factory method >>> through?something like this (although?less elegant) >>> >>> private class Bar{ >>> ? ? private final LazyConstant foo; >>> ? ? private Bar(Some some){ >>> >>> ? ? ? ? if(some.condition){ >>> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello"); >>> ? ? ? ? }else { >>> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello2"); >>> ? ? ? ? } >>> ? ? } >>> } >>> >>> Thank you for reading. This is all I have to report. >>> >>> Best regards. >>> >>> >>> >>> El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg >>> (per-ake.minborg at oracle.com) escribi?: >>> >>> Hi David, >>> >>> Thank you for trying out LazyConstant and providing >>> feedback. That is precisely what previews are for! >>> >>> If you take a closer look at the specification of >>> |LazyConstant::orElse,|?it says that the method will >>> /never trigger initialization./?And so, you >>> /can/?actually be sure that in your first example, >>> |foo|?is always initialized to "hello" (if ever >>> initialized). It is only if foo is not initialized >>> that the method will return "hello2" (again, without >>> initializing foo). This is similar to how >>> |Optional|?works. >>> >>> It would be possible to entirely remove the >>> |orElse()|?method from the API, and in the rare >>> cases where an equivalent functionality is called >>> for, rely on |LazyConstant::isInitialized|?instead. >>> >>> Best, Per >>> >>> >>> Confidential- Oracle Internal >>> ------------------------------------------------------------------------ >>> *From:* amber-dev on >>> behalf of david Grajales >>> *Sent:* Friday, December 5, 2025 5:38 AM >>> *To:* amber-dev ; >>> core-libs-dev at openjdk.org >>> *Subject:* Feedback about LazyConstants API (JEP526) >>> Dear Java Dev Team, >>> >>> ?I am writing to provide feedback and two specific >>> observations regarding the LazyConstant API, which >>> is currently a preview feature in OpenJDK 26. >>> >>> ?I appreciate the API's direction and I think it's a >>> good improvement compared to its first iteration; >>> however, I see potential for improved >>> expressiveness, particularly in conditional scenarios. >>> >>> >>> *1. Proposal: Zero-Parameter `LazyConstant.of()` >>> Overload:* >>> >>> Currently, the mandatory use of a factory method >>> receiving a `Supplier` (due to the lack of a public >>> constructor) can obscure the expressiveness of >>> conditional or multiple-value initialization paths. >>> **The Issue:** When looking at the declaration: >>> >>> LazyConstant foo = LazyConstant.of(() -> >>> "hello"); >>> >>> the code gives the strong, immediate impression that >>> the value is *always* initialized to |"hello"|. This >>> makes it difficult to infer that the constant might >>> ultimately resolve to an alternative value set later >>> via |orElse()| or another conditional path, >>> especially when skimming the code: >>> >>> LazyConstant foo = LazyConstant.of(() -> >>> "hello"); // When skimming the code it's not always >>> obvious that this may not be the actual value >>> void main() { >>> if (someCondition()) { >>> ? ? ? ? ? foo.get(); // Trigger initialization to >>> "hello" >>> ?} >>> // If someCondition is false, the final value of foo >>> is determined here: >>> var res1 = foo.orElse("hello2"); // ... >>> } >>> >>> *My Suggestion:* I propose introducing a >>> *zero-parameter overloaded static factory method* >>> |of()|: >>> >>> LazyConstant foo = LazyConstant.of(); >>> >>> This form explicitly communicates that the constant >>> is initialized to an *unresolved* state, suggesting >>> that the value will be determined downstream by the >>> first invocation of an initialization/computation >>> method. >>> >>> LazyConstant foo = LazyConstant.of(); // >>> Clearly unresolved >>> void main() { >>> if (someCondition()) { >>> ? ? ? foo.orElse("hello"); >>> ?} >>> var res1 = foo.orElse("hello2"); // ... >>> } >>> >>> This is specially useful for clarity when one has >>> conditional initialization in places such as the >>> constructor of a class. For example >>> >>> private class Bar{ >>> ? ? LazyConstant foo = LazyConstant.of(); >>> ? ? private Bar(Some some){ >>> ? ? ? ? if(some.condition()){ >>> ? ? ? ? ? ? foo.orElse("foo"); >>> ? ? ? ? } >>> ? ? ? ? foo.orElse("foo2"); >>> ? ? } >>> >>> ? ? String computeValue() { >>> ? ? ? ? return "hello"; >>> ? ? } >>> >>> ? ? String computeValue2(){ >>> ? ? ? ? return "hello2"; >>> ? ? } >>> } >>> >>> >>> 2. Method Naming Suggestion and and supplier >>> in instance method for consistency in the API >>> >>> My second, much more minor observation relates to >>> the instance method |orElse(T t)|. >>> >>> While |orElse| fits a retrieval pattern, I >>> personally feel that *|compute|* or >>> *|computeIfAbsent|* would better express the intent >>> of this method, as its primary function is not just >>> to retrieve, but to trigger the computation and *set >>> the final value* of the constant if it is currently >>> uninitialized. Also, as the factory of() has a >>> supplier i think this instance method should also >>> receive a Supplier, This not only keeps the API >>> consistent in the usage but makes more ergonomic the >>> declaration of complex initialization logic inside >>> the method. >>> >>> >>> private class Bar{ >>> LazyConstant foo = >>> LazyConstant.of(InitParam::default); // Under the >>> current API this is mandatory but in reality the >>> value is set in the constructor, default is never >>> really used. >>> ? ? private Bar(Some some){ >>> ?foo.compute(some::executeCallToCacheDBAndBringInitializationParams) >>> //Real configuration happens here >>> >>> ? ? } >>> } >>> >>> This last it's very common for initialization of >>> configuration classes and singletons. >>> >>> >>> Thank you so much for your attention, I hope you >>> find this feedback useful. >>> >>> Always yours. David Grajales >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Dec 9 11:36:00 2025 From: duke at openjdk.org (ExE Boss) Date: Tue, 9 Dec 2025 11:36:00 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 18:26:19 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/invoke/IndirectVarHandle.java line 114: >> >>> 112: // but checking the signature type of MH mostly works >>> 113: return MethodHandle.isReachableFrom(vform.getMethodType(0), cl) >>> 114: && target.isReachableFrom(cl); >> >> Right... one of the filters may also keep a class loader alive. But to check them, we'd have to eagerly instantiate all of them as well. >> >> FWIW, I don't think this is an issue we can just ignore. If a filter keeps a class loader alive, we'd still have a problem. >> >> Maybe it's possible to collect all the types involved from the filter when creating an IndirectVarHandle instead, and save those in a separate list for this check. > > I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers. Also, it?s?possible for?intermediate `MethodHandle`s used?as?part of?`MethodHandle` combinators to?refer to?types from?different class?loaders. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2602260725 From maurizio.cimadamore at oracle.com Tue Dec 9 11:50:48 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 11:50:48 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> Message-ID: An optional-returning tryGet is one of the possible ideas floating around, yes. Maurizio On 09/12/2025 11:37, Red IO wrote: > You can implement orElse in combination with a test function that > returns a boolean rather the value is there already. I don't see > orElse as such a great primitive. > At this point I want to advertise my tryGet suggestion that returns an > Option again as I think it would satisfy the people wanting orElse > without the confusion orElse created in this discussion alone. > Also in this sense tryGet is the more pure form of the "primitive" as > it returns basically a tuple of the value and a boolean rather the > value is there. Which is pretty much the entire state the LazyConstant > is carrying without any transformation of information. > > Great regards > RedIODev > > > On Tue, Dec 9, 2025, 11:25 Maurizio Cimadamore > wrote: > > I agree with most of the conclusions in this thread. > > > One small nit is that, in reality, `orElse` is a "primitive" in > disguise. E.g. you can implement `get` in terms of `orElse` but > not the other way around (unless you are willing to do _two_ > accessed to the underlying value). So, while we could drop it, we > would also lose something (which is why we decided to keep it, at > least for now). > > > Maurizio > > > > On 08/12/2025 12:31, Per-Ake Minborg wrote: >> So, it is nice that folks seem to agree that >> |LazyConstant|?should only compute and initialize its contents >> from the Supplier/lambda given at declaration time. The >> |orElse|?method seems to blur the contours of |LazyConstant|?, >> and so, as previously said, we might consider removing the method >> altogether in the next preview. >> >> It is also a fact that many have identified a need for "something >> else more low-level" that supports a more imperative programming >> model when working with constants that are lazily set. We do not >> rule out that such a thing might appear in a future JDK version. >> >> Best, Per >> >> Confidential- Oracle Internal >> ------------------------------------------------------------------------ >> *From:* David Alayachew >> >> *Sent:* Friday, December 5, 2025 2:51 PM >> *To:* Red IO >> >> *Cc:* david Grajales >> ; Per-Ake Minborg >> ; >> amber-dev ; >> core-libs-dev >> >> *Subject:* [External] : Re: Feedback about LazyConstants API >> (JEP526) >> Caveat -- I have only used the Java 25 version of this library. >> >> I agree that the name orElse() is not intuitive. It was made more >> intuitive by the existence of orElseSet(). In its absence, >> changing the name makes sense. >> >> Though, I'm definitely open to just removing the method. This is >> easy enough to accomplish ourselves. Would prefer a rename though. >> >> On Fri, Dec 5, 2025, 8:32?AM Red IO >> wrote: >> >> Hi David, >> As par already said the orElse method doesn't initializes the >> LazyConstant. >> It just checks rather the value is init and if not calls the >> supplier to get a substitute for the missing constant. >> Example: >> LazyConstant x = LazyConstant.of(() -> "Const"); >> var uninit1 = x.orElse(() -> "substitute 1"); >> var uninit2 = x.orElse(() -> "substitute 2"); >> var init1 = x.get(); >> var init2 = x.orElse(() -> "substitute 3"); >> uninit1 and uninit2 get the substitute 1/2 >> And init1 and init2 get Const. >> >> This is surprising if you expect it to be a way to init it >> with an alternative value. >> >> My suggestion would to make the separation clear and allow >> for another use case by spliting this api in 2 parts: >> One class LazyConstant >> Takes a Supplier in static factory and exposes get() >> >> And >> Class LazyInit >> Which takes no arguments in the static factory and takes a >> supplier in the get method that gets called when get is >> called for the first time. >> In this case the source for the constant can be any piece of >> code that has access to the LazyConstant. This might be >> desired in some cases. In cases where it's not the other >> version can be used. >> >> This split makes it clear from which context the constant is >> initialized from (consumer or at declaration) >> >> Mixing those 2 or having methods that appear to do this is >> rather confusing. >> >> >> >> One solution for the "i might not want to init the constant" >> case the "orElse" method is meant to be is to have a method >> "tryGet" which returns Optional instead. This makes it clear >> that the value might not be there and is not initialized when >> calling the method. Nobody expects to init the constant when >> calling orElse on a returned Optional. >> >> My 2 suggestions here are completely independent and should >> be viewed as such. >> >> Great regards >> RedIODev >> >> On Fri, Dec 5, 2025, 13:55 david Grajales >> wrote: >> >> HI Per. I pleasure to talk with you. >> >> You are right about one thing but this actually makes the >> API less intuitive and harder to read and reason about. >> >> LazyConstant foo = LazyConstant.of(() -> "hello"); >> >> void main() { >> ? ? if (someCondition()) {// asume false >> ? ? ? ? foo.get(); >> ? ? } >> ? ? foo.orElse("hello2"); // ... >> >> ? ? println(foo.get()); // This prints "hello" >> } >> >> But if one assigns foo.orElse("hello2") to a variable, >> the variable actually gets the "hello2" value. >> >> void main() { >> ? ? if (someCondition()) {// asume false >> ? ? ? ? foo.get(); >> ? ? } >> ? ? var res = foo.orElse("hello2"); // ... >> ? ? var res2 = foo.orElse("hello3"); >> ? ? println(res); // This prints "hello2" >> ? ? println(res2);//This prints "hello3" >> } >> >> This is actually even more confusing and makes the API >> more error prone. I personally think once initialized the >> lazy constant should always return the same value (maybe >> through the .get() method only), and there should not be >> any possibility of getting a different values?from the >> same instance either in the .of() static method or in any >> hypothetical instance method for conditional downstream >> logic.? I guess one could achieve the latter with the >> static factory method through?something like this >> (although?less elegant) >> >> private class Bar{ >> ? ? private final LazyConstant foo; >> ? ? private Bar(Some some){ >> >> ? ? ? ? if(some.condition){ >> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello"); >> ? ? ? ? }else { >> ? ? ? ? ? ? foo = LazyConstant.of(() -> "hello2"); >> ? ? ? ? } >> ? ? } >> } >> >> Thank you for reading. This is all I have to report. >> >> Best regards. >> >> >> >> El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg >> (per-ake.minborg at oracle.com) escribi?: >> >> Hi David, >> >> Thank you for trying out LazyConstant and providing >> feedback. That is precisely what previews are for! >> >> If you take a closer look at the specification of >> |LazyConstant::orElse,|?it says that the method will >> /never trigger initialization./?And so, you >> /can/?actually be sure that in your first example, >> |foo|?is always initialized to "hello" (if ever >> initialized). It is only if foo is not initialized >> that the method will return "hello2" (again, without >> initializing foo). This is similar to how >> |Optional|?works. >> >> It would be possible to entirely remove the >> |orElse()|?method from the API, and in the rare cases >> where an equivalent functionality is called for, rely >> on |LazyConstant::isInitialized|?instead. >> >> Best, Per >> >> >> Confidential- Oracle Internal >> ------------------------------------------------------------------------ >> *From:* amber-dev on >> behalf of david Grajales >> *Sent:* Friday, December 5, 2025 5:38 AM >> *To:* amber-dev ; >> core-libs-dev at openjdk.org >> *Subject:* Feedback about LazyConstants API (JEP526) >> Dear Java Dev Team, >> >> ?I am writing to provide feedback and two specific >> observations regarding the LazyConstant API, which is >> currently a preview feature in OpenJDK 26. >> >> ?I appreciate the API's direction and I think it's a >> good improvement compared to its first iteration; >> however, I see potential for improved expressiveness, >> particularly in conditional scenarios. >> >> >> *1. Proposal: Zero-Parameter `LazyConstant.of()` >> Overload:* >> >> Currently, the mandatory use of a factory method >> receiving a `Supplier` (due to the lack of a public >> constructor) can obscure the expressiveness of >> conditional or multiple-value initialization paths. >> **The Issue:** When looking at the declaration: >> >> LazyConstant foo = LazyConstant.of(() -> >> "hello"); >> >> the code gives the strong, immediate impression that >> the value is *always* initialized to |"hello"|. This >> makes it difficult to infer that the constant might >> ultimately resolve to an alternative value set later >> via |orElse()| or another conditional path, >> especially when skimming the code: >> >> LazyConstant foo = LazyConstant.of(() -> >> "hello"); // When skimming the code it's not always >> obvious that this may not be the actual value >> void main() { >> if (someCondition()) { >> ? ? ? ? ? foo.get(); // Trigger initialization to >> "hello" >> ?} >> // If someCondition is false, the final value of foo >> is determined here: >> var res1 = foo.orElse("hello2"); // ... >> } >> >> *My Suggestion:* I propose introducing a >> *zero-parameter overloaded static factory method* |of()|: >> >> LazyConstant foo = LazyConstant.of(); >> >> This form explicitly communicates that the constant >> is initialized to an *unresolved* state, suggesting >> that the value will be determined downstream by the >> first invocation of an initialization/computation method. >> >> LazyConstant foo = LazyConstant.of(); // >> Clearly unresolved >> void main() { >> if (someCondition()) { >> ? ? ? foo.orElse("hello"); >> ?} >> var res1 = foo.orElse("hello2"); // ... >> } >> >> This is specially useful for clarity when one has >> conditional initialization in places such as the >> constructor of a class. For example >> >> private class Bar{ >> ? ? LazyConstant foo = LazyConstant.of(); >> ? ? private Bar(Some some){ >> ? ? ? ? if(some.condition()){ >> ? ? ? ? ? ? foo.orElse("foo"); >> ? ? ? ? } >> ? ? ? ? foo.orElse("foo2"); >> ? ? } >> >> ? ? String computeValue() { >> ? ? ? ? return "hello"; >> ? ? } >> >> ? ? String computeValue2(){ >> ? ? ? ? return "hello2"; >> ? ? } >> } >> >> >> 2. Method Naming Suggestion and and supplier in >> instance method for consistency in the API >> >> My second, much more minor observation relates to the >> instance method |orElse(T t)|. >> >> While |orElse| fits a retrieval pattern, I personally >> feel that *|compute|* or *|computeIfAbsent|* would >> better express the intent of this method, as its >> primary function is not just to retrieve, but to >> trigger the computation and *set the final value* of >> the constant if it is currently uninitialized. Also, >> as the factory of() has a supplier i think this >> instance method should also receive a Supplier, This >> not only keeps the API consistent in the usage but >> makes more ergonomic the declaration of complex >> initialization logic inside the method. >> >> >> private class Bar{ >> LazyConstant foo = >> LazyConstant.of(InitParam::default); // Under the >> current API this is mandatory but in reality the >> value is set in the constructor, default is never >> really used. >> ? ? private Bar(Some some){ >> ?foo.compute(some::executeCallToCacheDBAndBringInitializationParams) >> //Real configuration happens here >> >> ? ? } >> } >> >> This last it's very common for initialization of >> configuration classes and singletons. >> >> >> Thank you so much for your attention, I hope you find >> this feedback useful. >> >> Always yours. David Grajales >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From maurizio.cimadamore at oracle.com Tue Dec 9 12:05:28 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 12:05:28 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: On 09/12/2025 11:59, Anatoly Kupriyanov wrote: > To be honest, I don't really see why this method causes such confusion. In part I agree. E.g. when we added this, what we had in mind was just https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) E.g. other APIs have `orElse` method that return a user-provided value if some condition isn't met. I believe the problem we're discussing here is likely also related to the fact that the API used to have a side-effecting `orElseSet`, which is now removed, and I wonder if, because of that, folks are reading too much into what orElse does? Maurizio From syan at openjdk.org Tue Dec 9 12:12:00 2025 From: syan at openjdk.org (SendaoYan) Date: Tue, 9 Dec 2025 12:12:00 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 00:49:22 GMT, Fairoz Matte wrote: >> 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated > > Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: > > Correcting return from error condition Do we need update the copyright year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28708#issuecomment-3631928236 From swen at openjdk.org Tue Dec 9 13:35:00 2025 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 9 Dec 2025 13:35:00 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 10:02:36 GMT, Shaojin Wen wrote: >> This PR optimizes the parsing performance of DateTimeFormatter by replacing HashMap with EnumMap in scenarios where the keys are exclusively ChronoField enum values. >> >> When parsing date/time strings, DateTimeFormatter creates HashMaps to store intermediate parsed values. HashMap has more overhead for operations compared to specialized map implementations. >> >> Since ChronoField is an enum and all keys in these maps are ChronoField instances, we can use EnumMap instead, which provides better performance for enum keys due to its optimized internal structure. >> >> Parsing scenarios show improvements from 12% to 95% > > Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: > > remove redundant checkField image As shown in the image above, the `DateTimeFormatterBuilder#appendValue` method does not need to call `checkField`; it only needs to be called within `appendInternal`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3632289875 From maurizio.cimadamore at oracle.com Tue Dec 9 14:23:22 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 14:23:22 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: <6c9909d2-3412-4cb2-9944-80f43854bfb5@oracle.com> I believe there is definitively possible overthinking at play here. Some notes: * in any case, we have at least _two_ primitives (either orElse + get, or tryGet + get). That's because one primitives triggers initialization, the other doesn't. * orElse is similar to what we do in ScopedValue. There's not many other APIs that do this. * creating an optional is more expensive -- but with Valhalla costs will likely go down and be comparable * returning an Optional might also be confusing because the Optional is a _snapshot_ at some point in the lifecycle of the lazy constant -- e.g. you can get an empty optional with tryGet(), then call get(). Now the previously returned optional is not in sync with the lazy constant (not sure how much this is a concern -- but listing it here as a possible element of confusion) * in all possible worlds, it seems that `isInitialized` can be derived, either from orElse, or from tryGet. That said, for a construct called LazyConstant, I think asking whether the constant is initialized or not seems a good method to have, and can also be used to explain some of the behavior of the API (e.g. in the javadoc). So I'm not sure I'd be ok with going the full way and drop it. Given all this, possible way forwards would be: 1. keep everything as is (after all, we got here for a reason) 2. drop orElse, and keep just get/isInitialzied (on the basis that the internal optimization of orElse is not really worth it. We can also always add it at a later point compatibly) 3. drop orElse and replace it with tryGet or some Optional-returning equivalent I don't have strong opinions on either of these. Perhaps, the "if in doubt leave it out" angle should win (2). Maurizio On 09/12/2025 14:12, Anatoly Kupriyanov wrote: > My idea is not an optional /interface/, but an interface for something > which is convertible to the Optional /type/. In other words, neither > the LazyConstant nor to ScopedVariable *is not*?an optional itself, > but could be converted?to it uniformly. > Something like this: > > interface Optionable {// need to think about the better naming! > ? T orElse(T other); > > ? ?// and maybe even: > ?default?Optional asOptional() { > ? ? return Optional.ofNullable(this.orElse(null)); > ? ?}; > } > > and then?LazyConstant,?ScopedVariable, etc could just implement the > interface to?unify on the notion of "return a user-provided value > if some condition isn't met". Sounds like a decent path to abolish nulls. > > But I feel I am overthinking this... > > > On Tue, 9 Dec 2025 at 13:35, Red IO wrote: > > I initially thought I agree with your statement that orElse is a > common pattern in the jdk. But then I failed to come up with a > second example. I then searched the jdk github repo for the > method. And I only found Optional and it's specializations and > ClassHierarchyResolver. > So I would suggest yes, it's an often used method ... of the > Optional class. Not many apis seem to expose it. The case of > exposing an accessor that returns an Optional on the other hand is > incredibly common across the jdk. This is exactly the case > Optional was designed for. In this sense Optional is the > "Interface" you are suggesting. > > My main argument against reusing orElse here is that the context > is a completely different one. > An Optional orElse method is a pure function that always returns > the same value. It signals that the value is not there. > LazyConstant is different in this regard. The LazyConstant orElse > is not pure at all. It depends on rather someone else already > initialized the value or not. It signals that the value is not > there YET. > > Great regards > RedIODev > > > > On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov > wrote: > > Right, the ScopedValue is another good example I've forgotten. > In that case I am even more inclined to keep the `orElse` as > it looks like a repeating pattern across JDK libraries. > Consistency is the way to go! > And maybe even consider having a new interface for?the method > to make this pattern explicit?.. > > I am glad that `orElseSet` is removed, the side-effecting is > bad; also in other parts of JDK we already have > `computeIfAbsent` for the same idea. I did not hear about it, > and yeah, sounds like the source of this confusion. > > > On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore > wrote: > > > On 09/12/2025 11:59, Anatoly Kupriyanov wrote: > > To be honest, I don't really see why this method causes > such confusion. > > In part I agree. E.g. when we added this, what we had in > mind was just > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) > > E.g. other APIs have `orElse` method that return a > user-provided value > if some condition isn't met. > > I believe the problem we're discussing here is likely also > related to > the fact that the API used to have a side-effecting > `orElseSet`, which > is now removed, and I wonder if, because of that, folks > are reading too > much into what orElse does? > > Maurizio > > > > -- > WBR, Anatoly. > > > > -- > WBR, Anatoly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Tue Dec 9 14:42:22 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 9 Dec 2025 14:42:22 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v8] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 11:33:31 GMT, ExE Boss wrote: >> I mean a filter method handle may keep other classes alive in addition to just its types. This is not possible from just checking the types. The vform method type is sufficient, because the types from the filter method type is always in one of the indirect layers. > > Also, it?s?possible for?intermediate `MethodHandle`s used?as?part of?`MethodHandle` combinators to?refer to?types from?different class?loaders. It is, but after all, there can be similar resource leak risks from calling LambdaMetafactory or other APIs too. We expect AccessDescriptor construction to be mostly limited to specific sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2602958025 From maurizio.cimadamore at oracle.com Tue Dec 9 15:18:33 2025 From: maurizio.cimadamore at oracle.com (Maurizio Cimadamore) Date: Tue, 9 Dec 2025 15:18:33 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: <1dc510fe-f85a-432e-b258-80bd9a8f4cab@oracle.com> Hi David, I think what you suggest is outside the scope of the LazyConstant API (as Per has already said). The goal of LazyConstant is to provide an easy to use abstraction for lazy initialization that addresses the 90% use case (e.g. deferred initialization using a lambda). There will be another, more imperative API that can be used to build what you want. But what we have learned when working on this project, is that if we increase the scope/reach of LazyConstant to include more imperative aspects, it ends up with confusion pretty quickly. The design you proposed was considered -- and rejected. While it holds together, the fact that the initialization action provided at creation acts now as a "fallback" initialization action, and can be overridden by use sites calling computeIfAbsent was deemed surprising and/or confusing. Regards Maurizio On 09/12/2025 14:46, david Grajales wrote: > I am glad my feedback was helpful and sparkled such a great > discussion. I would like to put 2 cents more, looking for these to be > helpful. > > My main concern with "orElse" is that most of the?time (at least for > my how I would use this API in my job) most of the time I need a > reliable way to set the constant and use that particular constant > along the life cycle of the class, **not** declaring an alternative > local variable in replacement because most of the time there is no > good "burned in the code" alternatives? that I could use . The use > cases I have for this API are usually about deferred initialization of > values that often require some time costly operation, some of those > may involve calls to external services (IO operations) thus having a > "burned" constant in these cases is not useful. Instead I propose a > "computeIfAbsent" (I am not against orElse naming) method that allows > for alternative downstream conditional initialization of the Lazy > constant. > > private class Bar{ > LazyCosntanweatherUrl = LazyCosntant.of(this::checkAndGetWeatherUrl); > > public Bar(){} > > private String checkAndGetWeatherUrl(){ > return Executors.newVirtualThreadPerTaskExecutor() > .submit(() ->/*Some query to check if the weather server is up*/); > } > > private String checkAndGetAltWeatherUrl(){ > return Executors.newVirtualThreadPerTaskExecutor() > .submit(() ->/*Some query to check if the alt weather server is up*/); > } > > public WeathergetWeather(){ > > var url =weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); > // logic to get the weather here using the lazy constants// } > public voidsendWeather(){ > var url =weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); > Executors.newVirtualThreadPerTaskExecutor() > .submit(() ->/*Send the weather url to somewhere else* using weatherUrl*/); > } > } > > This pattern is very common, either for a trivial weather or to check > or a conf and alternatives in case the regular one is not available > (for example a conf file that may be missing and one may set a method > that downloads it from a remote server first in case it is absent) > > So for me the issue is not the concept of "orElse" but how the current > implementation returns me an alternative value instead of SETTING an > alternative value in case the regular attempt fails or hasn't been > called still because the program followed an alternative path before > the obvious regular initialization path. If the orElse (or any other > name that fits) changes the behaviour to set a value instead of > returning something it would be the best approach IMHO. > > > > > El mar, 9 dic 2025 a la(s) 9:13?a.m., Anatoly Kupriyanov > (kan.izh at gmail.com) escribi?: > > My idea is not an optional /interface/, but an interface for > something which is convertible to the Optional /type/. In other > words, neither the LazyConstant nor to ScopedVariable *is not*?an > optional itself, but could be converted?to it uniformly. > Something like this: > > interface Optionable {// need to think about the better naming! > ? T orElse(T other); > > ? ?// and maybe even: > ?default?Optional asOptional() { > ? ? return Optional.ofNullable(this.orElse(null)); > ? ?}; > } > > and then?LazyConstant,?ScopedVariable, etc could just implement > the interface to?unify on the notion of "return a user-provided value > if some condition isn't met". Sounds like a decent path to abolish > nulls. > > But I feel I am overthinking this... > > > On Tue, 9 Dec 2025 at 13:35, Red IO > wrote: > > I initially thought I agree with your statement that orElse is > a common pattern in the jdk. But then I failed to come up with > a second example. I then searched the jdk github repo for the > method. And I only found Optional and it's specializations and > ClassHierarchyResolver. > So I would suggest yes, it's an often used method ... of the > Optional class. Not many apis seem to expose it. The case of > exposing an accessor that returns an Optional on the other > hand is incredibly common across the jdk. This is exactly the > case Optional was designed for. In this sense Optional is the > "Interface" you are suggesting. > > My main argument against reusing orElse here is that the > context is a completely different one. > An Optional orElse method is a pure function that always > returns the same value. It signals that the value is not there. > LazyConstant is different in this regard. The LazyConstant > orElse is not pure at all. It depends on rather someone else > already initialized the value or not. It signals that the > value is not there YET. > > Great regards > RedIODev > > > > On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov > wrote: > > Right, the ScopedValue is another good example I've > forgotten. In that case I am even more inclined to keep > the `orElse` as it looks like a repeating pattern across > JDK libraries. Consistency is the way to go! > And maybe even consider having a new interface for?the > method to make this pattern explicit?.. > > I am glad that `orElseSet` is removed, the side-effecting > is bad; also in other parts of JDK we already have > `computeIfAbsent` for the same idea. I did not hear about > it, and yeah, sounds like the source of this confusion. > > > On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore > wrote: > > > On 09/12/2025 11:59, Anatoly Kupriyanov wrote: > > To be honest, I don't really see why this method > causes such confusion. > > In part I agree. E.g. when we added this, what we had > in mind was just > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) > > E.g. other APIs have `orElse` method that return a > user-provided value > if some condition isn't met. > > I believe the problem we're discussing here is likely > also related to > the fact that the API used to have a side-effecting > `orElseSet`, which > is now removed, and I wonder if, because of that, > folks are reading too > much into what orElse does? > > Maurizio > > > > -- > WBR, Anatoly. > > > > -- > WBR, Anatoly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Tue Dec 9 14:46:39 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 9 Dec 2025 09:46:39 -0500 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: I am glad my feedback was helpful and sparkled such a great discussion. I would like to put 2 cents more, looking for these to be helpful. My main concern with "orElse" is that most of the time (at least for my how I would use this API in my job) most of the time I need a reliable way to set the constant and use that particular constant along the life cycle of the class, **not** declaring an alternative local variable in replacement because most of the time there is no good "burned in the code" alternatives that I could use . The use cases I have for this API are usually about deferred initialization of values that often require some time costly operation, some of those may involve calls to external services (IO operations) thus having a "burned" constant in these cases is not useful. Instead I propose a "computeIfAbsent" (I am not against orElse naming) method that allows for alternative downstream conditional initialization of the Lazy constant. private class Bar{ LazyCosntan weatherUrl = LazyCosntant.of(this::checkAndGetWeatherUrl); public Bar(){} private String checkAndGetWeatherUrl(){ return Executors.newVirtualThreadPerTaskExecutor() .submit(() -> /*Some query to check if the weather server is up*/); } private String checkAndGetAltWeatherUrl(){ return Executors.newVirtualThreadPerTaskExecutor() .submit(() -> /*Some query to check if the alt weather server is up*/); } public Weather getWeather(){ var url = weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); // logic to get the weather here using the lazy constants// } public void sendWeather(){ var url = weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); Executors.newVirtualThreadPerTaskExecutor() .submit(() -> /*Send the weather url to somewhere else* using weatherUrl*/); } } This pattern is very common, either for a trivial weather or to check or a conf and alternatives in case the regular one is not available (for example a conf file that may be missing and one may set a method that downloads it from a remote server first in case it is absent) So for me the issue is not the concept of "orElse" but how the current implementation returns me an alternative value instead of SETTING an alternative value in case the regular attempt fails or hasn't been called still because the program followed an alternative path before the obvious regular initialization path. If the orElse (or any other name that fits) changes the behaviour to set a value instead of returning something it would be the best approach IMHO. El mar, 9 dic 2025 a la(s) 9:13?a.m., Anatoly Kupriyanov (kan.izh at gmail.com) escribi?: > My idea is not an optional *interface*, but an interface for something > which is convertible to the Optional *type*. In other words, neither the > LazyConstant nor to ScopedVariable *is not* an optional itself, but could > be converted to it uniformly. > Something like this: > > interface Optionable {// need to think about the better naming! > T orElse(T other); > > // and maybe even: > default Optional asOptional() { > return Optional.ofNullable(this.orElse(null)); > }; > } > > and then LazyConstant, ScopedVariable, etc could just implement the > interface to unify on the notion of "return a user-provided value > if some condition isn't met". Sounds like a decent path to abolish nulls. > > But I feel I am overthinking this... > > > On Tue, 9 Dec 2025 at 13:35, Red IO wrote: > >> I initially thought I agree with your statement that orElse is a common >> pattern in the jdk. But then I failed to come up with a second example. I >> then searched the jdk github repo for the method. And I only found Optional >> and it's specializations and ClassHierarchyResolver. >> So I would suggest yes, it's an often used method ... of the Optional >> class. Not many apis seem to expose it. The case of exposing an accessor >> that returns an Optional on the other hand is incredibly common across the >> jdk. This is exactly the case Optional was designed for. In this sense >> Optional is the "Interface" you are suggesting. >> >> My main argument against reusing orElse here is that the context is a >> completely different one. >> An Optional orElse method is a pure function that always returns the same >> value. It signals that the value is not there. >> LazyConstant is different in this regard. The LazyConstant orElse is not >> pure at all. It depends on rather someone else already initialized the >> value or not. It signals that the value is not there YET. >> >> Great regards >> RedIODev >> >> >> >> On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov wrote: >> >>> Right, the ScopedValue is another good example I've forgotten. In that >>> case I am even more inclined to keep the `orElse` as it looks like a >>> repeating pattern across JDK libraries. Consistency is the way to go! >>> And maybe even consider having a new interface for the method to make >>> this pattern explicit?.. >>> >>> I am glad that `orElseSet` is removed, the side-effecting is bad; also >>> in other parts of JDK we already have `computeIfAbsent` for the same idea. >>> I did not hear about it, and yeah, sounds like the source of this confusion. >>> >>> >>> On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore < >>> maurizio.cimadamore at oracle.com> wrote: >>> >>>> >>>> On 09/12/2025 11:59, Anatoly Kupriyanov wrote: >>>> > To be honest, I don't really see why this method causes such >>>> confusion. >>>> >>>> In part I agree. E.g. when we added this, what we had in mind was just >>>> >>>> >>>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) >>>> >>>> E.g. other APIs have `orElse` method that return a user-provided value >>>> if some condition isn't met. >>>> >>>> I believe the problem we're discussing here is likely also related to >>>> the fact that the API used to have a side-effecting `orElseSet`, which >>>> is now removed, and I wonder if, because of that, folks are reading too >>>> much into what orElse does? >>>> >>>> Maurizio >>>> >>>> >>> >>> -- >>> WBR, Anatoly. >>> >> > > -- > WBR, Anatoly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.1993grajales at gmail.com Tue Dec 9 15:23:43 2025 From: david.1993grajales at gmail.com (david Grajales) Date: Tue, 9 Dec 2025 10:23:43 -0500 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: <1dc510fe-f85a-432e-b258-80bd9a8f4cab@oracle.com> References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> <1dc510fe-f85a-432e-b258-80bd9a8f4cab@oracle.com> Message-ID: Hi Maurizio. Understandable. Thank you for the clarification. Best regards. El mar, 9 de dic de 2025, 10:18?a.m., Maurizio Cimadamore < maurizio.cimadamore at oracle.com> escribi?: > Hi David, > I think what you suggest is outside the scope of the LazyConstant API (as > Per has already said). > > The goal of LazyConstant is to provide an easy to use abstraction for lazy > initialization that addresses the 90% use case (e.g. deferred > initialization using a lambda). > > There will be another, more imperative API that can be used to build what > you want. > > But what we have learned when working on this project, is that if we > increase the scope/reach of LazyConstant to include more imperative > aspects, it ends up with confusion pretty quickly. > > The design you proposed was considered -- and rejected. While it holds > together, the fact that the initialization action provided at creation acts > now as a "fallback" initialization action, and can be overridden by use > sites calling computeIfAbsent was deemed surprising and/or confusing. > > Regards > Maurizio > On 09/12/2025 14:46, david Grajales wrote: > > I am glad my feedback was helpful and sparkled such a great discussion. I > would like to put 2 cents more, looking for these to be helpful. > > My main concern with "orElse" is that most of the time (at least for my > how I would use this API in my job) most of the time I need a reliable way > to set the constant and use that particular constant along the life cycle > of the class, **not** declaring an alternative local variable in > replacement because most of the time there is no good "burned in the code" > alternatives that I could use . The use cases I have for this API are > usually about deferred initialization of values that often require some > time costly operation, some of those may involve calls to external services > (IO operations) thus having a "burned" constant in these cases is not > useful. Instead I propose a "computeIfAbsent" (I am not against orElse > naming) method that allows for alternative downstream conditional > initialization of the Lazy constant. > > private class Bar{ > LazyCosntan weatherUrl = LazyCosntant.of(this::checkAndGetWeatherUrl); > > > public Bar(){} > > private String checkAndGetWeatherUrl(){ > return Executors.newVirtualThreadPerTaskExecutor() > .submit(() -> /*Some query to check if the weather server is up*/); > } > > private String checkAndGetAltWeatherUrl(){ > return Executors.newVirtualThreadPerTaskExecutor() > .submit(() -> /*Some query to check if the alt weather server is up*/); > } > > public Weather getWeather(){ > > var url = weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); > > // logic to get the weather here using the lazy constants// } > > public void sendWeather(){ > > var url = weatherUrl.computeIfAbsent(this::checkAndGetAltWeatherUrl).get(); > > Executors.newVirtualThreadPerTaskExecutor() > .submit(() -> /*Send the weather url to somewhere else* using weatherUrl*/); > } > > > } > > > This pattern is very common, either for a trivial weather or to check or a > conf and alternatives in case the regular one is not available (for example > a conf file that may be missing and one may set a method that downloads it > from a remote server first in case it is absent) > > So for me the issue is not the concept of "orElse" but how the current > implementation returns me an alternative value instead of SETTING an > alternative value in case the regular attempt fails or hasn't been called > still because the program followed an alternative path before the obvious > regular initialization path. If the orElse (or any other name that fits) > changes the behaviour to set a value instead of returning something it > would be the best approach IMHO. > > > > > El mar, 9 dic 2025 a la(s) 9:13?a.m., Anatoly Kupriyanov ( > kan.izh at gmail.com) escribi?: > >> My idea is not an optional *interface*, but an interface for something >> which is convertible to the Optional *type*. In other words, neither the >> LazyConstant nor to ScopedVariable *is not* an optional itself, but >> could be converted to it uniformly. >> Something like this: >> >> interface Optionable {// need to think about the better naming! >> T orElse(T other); >> >> // and maybe even: >> default Optional asOptional() { >> return Optional.ofNullable(this.orElse(null)); >> }; >> } >> >> and then LazyConstant, ScopedVariable, etc could just implement the >> interface to unify on the notion of "return a user-provided value >> if some condition isn't met". Sounds like a decent path to abolish nulls. >> >> But I feel I am overthinking this... >> >> >> On Tue, 9 Dec 2025 at 13:35, Red IO wrote: >> >>> I initially thought I agree with your statement that orElse is a common >>> pattern in the jdk. But then I failed to come up with a second example. I >>> then searched the jdk github repo for the method. And I only found Optional >>> and it's specializations and ClassHierarchyResolver. >>> So I would suggest yes, it's an often used method ... of the Optional >>> class. Not many apis seem to expose it. The case of exposing an accessor >>> that returns an Optional on the other hand is incredibly common across the >>> jdk. This is exactly the case Optional was designed for. In this sense >>> Optional is the "Interface" you are suggesting. >>> >>> My main argument against reusing orElse here is that the context is a >>> completely different one. >>> An Optional orElse method is a pure function that always returns the >>> same value. It signals that the value is not there. >>> LazyConstant is different in this regard. The LazyConstant orElse is not >>> pure at all. It depends on rather someone else already initialized the >>> value or not. It signals that the value is not there YET. >>> >>> Great regards >>> RedIODev >>> >>> >>> >>> On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov wrote: >>> >>>> Right, the ScopedValue is another good example I've forgotten. In that >>>> case I am even more inclined to keep the `orElse` as it looks like a >>>> repeating pattern across JDK libraries. Consistency is the way to go! >>>> And maybe even consider having a new interface for the method to make >>>> this pattern explicit?.. >>>> >>>> I am glad that `orElseSet` is removed, the side-effecting is bad; also >>>> in other parts of JDK we already have `computeIfAbsent` for the same idea. >>>> I did not hear about it, and yeah, sounds like the source of this confusion. >>>> >>>> >>>> On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore < >>>> maurizio.cimadamore at oracle.com> wrote: >>>> >>>>> >>>>> On 09/12/2025 11:59, Anatoly Kupriyanov wrote: >>>>> > To be honest, I don't really see why this method causes such >>>>> confusion. >>>>> >>>>> In part I agree. E.g. when we added this, what we had in mind was just >>>>> >>>>> >>>>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) >>>>> >>>>> E.g. other APIs have `orElse` method that return a user-provided value >>>>> if some condition isn't met. >>>>> >>>>> I believe the problem we're discussing here is likely also related to >>>>> the fact that the API used to have a side-effecting `orElseSet`, which >>>>> is now removed, and I wonder if, because of that, folks are reading >>>>> too >>>>> much into what orElse does? >>>>> >>>>> Maurizio >>>>> >>>>> >>>> >>>> -- >>>> WBR, Anatoly. >>>> >>> >> >> -- >> WBR, Anatoly. >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kan.izh at gmail.com Tue Dec 9 11:15:03 2025 From: kan.izh at gmail.com (Anatoly Kupriyanov) Date: Tue, 9 Dec 2025 11:15:03 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> Message-ID: That's seems exactly opposite. The `get` returns initial value always making the constant initialised by calling compute. The `orElse(v)` is a shortcut for `c.isInitialized() ? c.get() : v`. WBR, Anatoly. On Tue, 9 Dec 2025, 10:25 Maurizio Cimadamore, < maurizio.cimadamore at oracle.com> wrote: > I agree with most of the conclusions in this thread. > > > One small nit is that, in reality, `orElse` is a "primitive" in disguise. > E.g. you can implement `get` in terms of `orElse` but not the other way > around (unless you are willing to do _two_ accessed to the underlying > value). So, while we could drop it, we would also lose something (which is > why we decided to keep it, at least for now). > > > Maurizio > > > > On 08/12/2025 12:31, Per-Ake Minborg wrote: > > So, it is nice that folks seem to agree that LazyConstant should only > compute and initialize its contents from the Supplier/lambda given at > declaration time. The orElse method seems to blur the contours of > LazyConstant , and so, as previously said, we might consider removing the > method altogether in the next preview. > > It is also a fact that many have identified a need for "something else > more low-level" that supports a more imperative programming model when > working with constants that are lazily set. We do not rule out that such a > thing might appear in a future JDK version. > > Best, Per > > Confidential- Oracle Internal > ------------------------------ > *From:* David Alayachew > > *Sent:* Friday, December 5, 2025 2:51 PM > *To:* Red IO > *Cc:* david Grajales > ; Per-Ake Minborg > ; amber-dev > ; core-libs-dev > > *Subject:* [External] : Re: Feedback about LazyConstants API (JEP526) > > Caveat -- I have only used the Java 25 version of this library. > > I agree that the name orElse() is not intuitive. It was made more > intuitive by the existence of orElseSet(). In its absence, changing the > name makes sense. > > Though, I'm definitely open to just removing the method. This is easy > enough to accomplish ourselves. Would prefer a rename though. > > On Fri, Dec 5, 2025, 8:32?AM Red IO wrote: > > Hi David, > As par already said the orElse method doesn't initializes the > LazyConstant. > It just checks rather the value is init and if not calls the supplier to > get a substitute for the missing constant. > Example: > LazyConstant x = LazyConstant.of(() -> "Const"); > var uninit1 = x.orElse(() -> "substitute 1"); > var uninit2 = x.orElse(() -> "substitute 2"); > var init1 = x.get(); > var init2 = x.orElse(() -> "substitute 3"); > uninit1 and uninit2 get the substitute 1/2 > And init1 and init2 get Const. > > This is surprising if you expect it to be a way to init it with an > alternative value. > > My suggestion would to make the separation clear and allow for another use > case by spliting this api in 2 parts: > One class LazyConstant > Takes a Supplier in static factory and exposes get() > > And > Class LazyInit > Which takes no arguments in the static factory and takes a supplier in the > get method that gets called when get is called for the first time. > In this case the source for the constant can be any piece of code that has > access to the LazyConstant. This might be desired in some cases. In cases > where it's not the other version can be used. > > This split makes it clear from which context the constant is initialized > from (consumer or at declaration) > > Mixing those 2 or having methods that appear to do this is rather > confusing. > > > > One solution for the "i might not want to init the constant" case the > "orElse" method is meant to be is to have a method "tryGet" which returns > Optional instead. This makes it clear that the value might not be there and > is not initialized when calling the method. Nobody expects to init the > constant when calling orElse on a returned Optional. > > My 2 suggestions here are completely independent and should be viewed as > such. > > Great regards > RedIODev > > On Fri, Dec 5, 2025, 13:55 david Grajales > wrote: > > HI Per. I pleasure to talk with you. > > You are right about one thing but this actually makes the API less > intuitive and harder to read and reason about. > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > foo.orElse("hello2"); // ... > > println(foo.get()); // This prints "hello" > } > > But if one assigns foo.orElse("hello2") to a variable, the variable > actually gets the "hello2" value. > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > var res = foo.orElse("hello2"); // ... > var res2 = foo.orElse("hello3"); > println(res); // This prints "hello2" > println(res2);//This prints "hello3" > } > > This is actually even more confusing and makes the API more error prone. I > personally think once initialized the lazy constant should always return > the same value (maybe through the .get() method only), and there should not > be any possibility of getting a different values from the same instance > either in the .of() static method or in any hypothetical instance method > for conditional downstream logic. I guess one could achieve the latter > with the static factory method through something like this (although less > elegant) > > private class Bar{ > private final LazyConstant foo; > private Bar(Some some){ > > if(some.condition){ > foo = LazyConstant.of(() -> "hello"); > }else { > foo = LazyConstant.of(() -> "hello2"); > } > } > } > > Thank you for reading. This is all I have to report. > > Best regards. > > > > El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg ( > per-ake.minborg at oracle.com) escribi?: > > Hi David, > > Thank you for trying out LazyConstant and providing feedback. That is > precisely what previews are for! > > If you take a closer look at the specification of LazyConstant::orElse, it > says that the method will *never trigger initialization.* And so, you > *can* actually be sure that in your first example, foo is always > initialized to "hello" (if ever initialized). It is only if foo is not > initialized that the method will return "hello2" (again, without > initializing foo). This is similar to how Optional works. > > It would be possible to entirely remove the orElse() method from the API, > and in the rare cases where an equivalent functionality is called for, rely > on LazyConstant::isInitialized instead. > > Best, Per > > > Confidential- Oracle Internal > ------------------------------ > *From:* amber-dev on behalf of david > Grajales > *Sent:* Friday, December 5, 2025 5:38 AM > *To:* amber-dev ; core-libs-dev at openjdk.org < > core-libs-dev at openjdk.org> > *Subject:* Feedback about LazyConstants API (JEP526) > > Dear Java Dev Team, > > I am writing to provide feedback and two specific observations regarding > the LazyConstant API, which is currently a preview feature in OpenJDK 26. > > I appreciate the API's direction and I think it's a good improvement > compared to its first iteration; however, I see potential for improved > expressiveness, particularly in conditional scenarios. > > > *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* > > Currently, the mandatory use of a factory method receiving a `Supplier` > (due to the lack of a public constructor) can obscure the expressiveness of > conditional or multiple-value initialization paths. **The Issue:** When > looking at the declaration: > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > the code gives the strong, immediate impression that the value is *always* > initialized to "hello". This makes it difficult to infer that the > constant might ultimately resolve to an alternative value set later via > orElse() or another conditional path, especially when skimming the code: > > LazyConstant foo = LazyConstant.of(() -> "hello"); // When > skimming the code it's not always obvious that this may not be the actual > value > > void main() { > if (someCondition()) { > foo.get(); // Trigger initialization to "hello" > } > // If someCondition is false, the final value of foo is determined here: > > var res1 = foo.orElse("hello2"); // ... > } > > *My Suggestion:* I propose introducing a *zero-parameter overloaded > static factory method* of(): > > LazyConstant foo = LazyConstant.of(); > > This form explicitly communicates that the constant is initialized to an * > unresolved* state, suggesting that the value will be determined > downstream by the first invocation of an initialization/computation method. > > LazyConstant foo = LazyConstant.of(); // Clearly unresolved > void main() { > if (someCondition()) { > foo.orElse("hello"); > } > var res1 = foo.orElse("hello2"); // ... > } > > This is specially useful for clarity when one has conditional > initialization in places such as the constructor of a class. For example > > private class Bar{ > LazyConstant foo = LazyConstant.of(); > private Bar(Some some){ > if(some.condition()){ > foo.orElse("foo"); > } > foo.orElse("foo2"); > } > > String computeValue() { > return "hello"; > } > > String computeValue2(){ > return "hello2"; > } > } > 2. Method Naming Suggestion and and supplier in instance method for > consistency in the API > > My second, much more minor observation relates to the instance method orElse(T > t). > > While orElse fits a retrieval pattern, I personally feel that * compute* > or *computeIfAbsent* would better express the intent of this method, as > its primary function is not just to retrieve, but to trigger the > computation and *set the final value* of the constant if it is currently > uninitialized. Also, as the factory of() has a supplier i think this > instance method should also receive a Supplier, This not only keeps the API > consistent in the usage but makes more ergonomic the declaration of complex > initialization logic inside the method. > > > private class Bar{ > LazyConstant foo = LazyConstant.of(InitParam::default); // > Under the current API this is mandatory but in reality the value is set in > the constructor, default is never really used. > private Bar(Some some){ > foo.compute(some::executeCallToCacheDBAndBringInitializationParams) > //Real configuration happens here > > } > } > > This last it's very common for initialization of configuration classes and > singletons. > > > Thank you so much for your attention, I hope you find this feedback useful. > > Always yours. David Grajales > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kan.izh at gmail.com Tue Dec 9 11:59:46 2025 From: kan.izh at gmail.com (Anatoly Kupriyanov) Date: Tue, 9 Dec 2025 11:59:46 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: I don't think it's a problem. To be honest, I don't really see why this method causes such confusion.. It behaves very similarly to the Optional's method of the same name. I would support the Red IO suggestion to have a `tryGet` method returning Optional as a way to tackle the confusion. If you read javadoc for orElse it says "Returns the constant if initialized, otherwise, returns other", which is quite literally what I did show in my code snippet. Logically it is the same, but you are right, from implementation perspective it uses getAcquire twice, which potentially could have performance penalty. Your code snippet is incorrect, as the `get` never throws. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kan.izh at gmail.com Tue Dec 9 12:51:14 2025 From: kan.izh at gmail.com (Anatoly Kupriyanov) Date: Tue, 9 Dec 2025 12:51:14 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: Right, the ScopedValue is another good example I've forgotten. In that case I am even more inclined to keep the `orElse` as it looks like a repeating pattern across JDK libraries. Consistency is the way to go! And maybe even consider having a new interface for the method to make this pattern explicit?.. I am glad that `orElseSet` is removed, the side-effecting is bad; also in other parts of JDK we already have `computeIfAbsent` for the same idea. I did not hear about it, and yeah, sounds like the source of this confusion. On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > > On 09/12/2025 11:59, Anatoly Kupriyanov wrote: > > To be honest, I don't really see why this method causes such confusion. > > In part I agree. E.g. when we added this, what we had in mind was just > > > https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) > > E.g. other APIs have `orElse` method that return a user-provided value > if some condition isn't met. > > I believe the problem we're discussing here is likely also related to > the fact that the API used to have a side-effecting `orElseSet`, which > is now removed, and I wonder if, because of that, folks are reading too > much into what orElse does? > > Maurizio > > -- WBR, Anatoly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redio.development at gmail.com Tue Dec 9 11:37:23 2025 From: redio.development at gmail.com (Red IO) Date: Tue, 9 Dec 2025 12:37:23 +0100 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> Message-ID: You can implement orElse in combination with a test function that returns a boolean rather the value is there already. I don't see orElse as such a great primitive. At this point I want to advertise my tryGet suggestion that returns an Option again as I think it would satisfy the people wanting orElse without the confusion orElse created in this discussion alone. Also in this sense tryGet is the more pure form of the "primitive" as it returns basically a tuple of the value and a boolean rather the value is there. Which is pretty much the entire state the LazyConstant is carrying without any transformation of information. Great regards RedIODev On Tue, Dec 9, 2025, 11:25 Maurizio Cimadamore < maurizio.cimadamore at oracle.com> wrote: > I agree with most of the conclusions in this thread. > > > One small nit is that, in reality, `orElse` is a "primitive" in disguise. > E.g. you can implement `get` in terms of `orElse` but not the other way > around (unless you are willing to do _two_ accessed to the underlying > value). So, while we could drop it, we would also lose something (which is > why we decided to keep it, at least for now). > > > Maurizio > > > > On 08/12/2025 12:31, Per-Ake Minborg wrote: > > So, it is nice that folks seem to agree that LazyConstant should only > compute and initialize its contents from the Supplier/lambda given at > declaration time. The orElse method seems to blur the contours of > LazyConstant , and so, as previously said, we might consider removing the > method altogether in the next preview. > > It is also a fact that many have identified a need for "something else > more low-level" that supports a more imperative programming model when > working with constants that are lazily set. We do not rule out that such a > thing might appear in a future JDK version. > > Best, Per > > Confidential- Oracle Internal > ------------------------------ > *From:* David Alayachew > > *Sent:* Friday, December 5, 2025 2:51 PM > *To:* Red IO > *Cc:* david Grajales > ; Per-Ake Minborg > ; amber-dev > ; core-libs-dev > > *Subject:* [External] : Re: Feedback about LazyConstants API (JEP526) > > Caveat -- I have only used the Java 25 version of this library. > > I agree that the name orElse() is not intuitive. It was made more > intuitive by the existence of orElseSet(). In its absence, changing the > name makes sense. > > Though, I'm definitely open to just removing the method. This is easy > enough to accomplish ourselves. Would prefer a rename though. > > On Fri, Dec 5, 2025, 8:32?AM Red IO wrote: > > Hi David, > As par already said the orElse method doesn't initializes the > LazyConstant. > It just checks rather the value is init and if not calls the supplier to > get a substitute for the missing constant. > Example: > LazyConstant x = LazyConstant.of(() -> "Const"); > var uninit1 = x.orElse(() -> "substitute 1"); > var uninit2 = x.orElse(() -> "substitute 2"); > var init1 = x.get(); > var init2 = x.orElse(() -> "substitute 3"); > uninit1 and uninit2 get the substitute 1/2 > And init1 and init2 get Const. > > This is surprising if you expect it to be a way to init it with an > alternative value. > > My suggestion would to make the separation clear and allow for another use > case by spliting this api in 2 parts: > One class LazyConstant > Takes a Supplier in static factory and exposes get() > > And > Class LazyInit > Which takes no arguments in the static factory and takes a supplier in the > get method that gets called when get is called for the first time. > In this case the source for the constant can be any piece of code that has > access to the LazyConstant. This might be desired in some cases. In cases > where it's not the other version can be used. > > This split makes it clear from which context the constant is initialized > from (consumer or at declaration) > > Mixing those 2 or having methods that appear to do this is rather > confusing. > > > > One solution for the "i might not want to init the constant" case the > "orElse" method is meant to be is to have a method "tryGet" which returns > Optional instead. This makes it clear that the value might not be there and > is not initialized when calling the method. Nobody expects to init the > constant when calling orElse on a returned Optional. > > My 2 suggestions here are completely independent and should be viewed as > such. > > Great regards > RedIODev > > On Fri, Dec 5, 2025, 13:55 david Grajales > wrote: > > HI Per. I pleasure to talk with you. > > You are right about one thing but this actually makes the API less > intuitive and harder to read and reason about. > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > foo.orElse("hello2"); // ... > > println(foo.get()); // This prints "hello" > } > > But if one assigns foo.orElse("hello2") to a variable, the variable > actually gets the "hello2" value. > > void main() { > if (someCondition()) {// asume false > foo.get(); > } > var res = foo.orElse("hello2"); // ... > var res2 = foo.orElse("hello3"); > println(res); // This prints "hello2" > println(res2);//This prints "hello3" > } > > This is actually even more confusing and makes the API more error prone. I > personally think once initialized the lazy constant should always return > the same value (maybe through the .get() method only), and there should not > be any possibility of getting a different values from the same instance > either in the .of() static method or in any hypothetical instance method > for conditional downstream logic. I guess one could achieve the latter > with the static factory method through something like this (although less > elegant) > > private class Bar{ > private final LazyConstant foo; > private Bar(Some some){ > > if(some.condition){ > foo = LazyConstant.of(() -> "hello"); > }else { > foo = LazyConstant.of(() -> "hello2"); > } > } > } > > Thank you for reading. This is all I have to report. > > Best regards. > > > > El vie, 5 dic 2025 a la(s) 6:05?a.m., Per-Ake Minborg ( > per-ake.minborg at oracle.com) escribi?: > > Hi David, > > Thank you for trying out LazyConstant and providing feedback. That is > precisely what previews are for! > > If you take a closer look at the specification of LazyConstant::orElse, it > says that the method will *never trigger initialization.* And so, you > *can* actually be sure that in your first example, foo is always > initialized to "hello" (if ever initialized). It is only if foo is not > initialized that the method will return "hello2" (again, without > initializing foo). This is similar to how Optional works. > > It would be possible to entirely remove the orElse() method from the API, > and in the rare cases where an equivalent functionality is called for, rely > on LazyConstant::isInitialized instead. > > Best, Per > > > Confidential- Oracle Internal > ------------------------------ > *From:* amber-dev on behalf of david > Grajales > *Sent:* Friday, December 5, 2025 5:38 AM > *To:* amber-dev ; core-libs-dev at openjdk.org < > core-libs-dev at openjdk.org> > *Subject:* Feedback about LazyConstants API (JEP526) > > Dear Java Dev Team, > > I am writing to provide feedback and two specific observations regarding > the LazyConstant API, which is currently a preview feature in OpenJDK 26. > > I appreciate the API's direction and I think it's a good improvement > compared to its first iteration; however, I see potential for improved > expressiveness, particularly in conditional scenarios. > > > *1. Proposal: Zero-Parameter `LazyConstant.of()` Overload:* > > Currently, the mandatory use of a factory method receiving a `Supplier` > (due to the lack of a public constructor) can obscure the expressiveness of > conditional or multiple-value initialization paths. **The Issue:** When > looking at the declaration: > > LazyConstant foo = LazyConstant.of(() -> "hello"); > > the code gives the strong, immediate impression that the value is *always* > initialized to "hello". This makes it difficult to infer that the > constant might ultimately resolve to an alternative value set later via > orElse() or another conditional path, especially when skimming the code: > > LazyConstant foo = LazyConstant.of(() -> "hello"); // When > skimming the code it's not always obvious that this may not be the actual > value > > void main() { > if (someCondition()) { > foo.get(); // Trigger initialization to "hello" > } > // If someCondition is false, the final value of foo is determined here: > > var res1 = foo.orElse("hello2"); // ... > } > > *My Suggestion:* I propose introducing a *zero-parameter overloaded > static factory method* of(): > > LazyConstant foo = LazyConstant.of(); > > This form explicitly communicates that the constant is initialized to an * > unresolved* state, suggesting that the value will be determined > downstream by the first invocation of an initialization/computation method. > > LazyConstant foo = LazyConstant.of(); // Clearly unresolved > void main() { > if (someCondition()) { > foo.orElse("hello"); > } > var res1 = foo.orElse("hello2"); // ... > } > > This is specially useful for clarity when one has conditional > initialization in places such as the constructor of a class. For example > > private class Bar{ > LazyConstant foo = LazyConstant.of(); > private Bar(Some some){ > if(some.condition()){ > foo.orElse("foo"); > } > foo.orElse("foo2"); > } > > String computeValue() { > return "hello"; > } > > String computeValue2(){ > return "hello2"; > } > } > 2. Method Naming Suggestion and and supplier in instance method for > consistency in the API > > My second, much more minor observation relates to the instance method orElse(T > t). > > While orElse fits a retrieval pattern, I personally feel that * compute* > or *computeIfAbsent* would better express the intent of this method, as > its primary function is not just to retrieve, but to trigger the > computation and *set the final value* of the constant if it is currently > uninitialized. Also, as the factory of() has a supplier i think this > instance method should also receive a Supplier, This not only keeps the API > consistent in the usage but makes more ergonomic the declaration of complex > initialization logic inside the method. > > > private class Bar{ > LazyConstant foo = LazyConstant.of(InitParam::default); // > Under the current API this is mandatory but in reality the value is set in > the constructor, default is never really used. > private Bar(Some some){ > foo.compute(some::executeCallToCacheDBAndBringInitializationParams) > //Real configuration happens here > > } > } > > This last it's very common for initialization of configuration classes and > singletons. > > > Thank you so much for your attention, I hope you find this feedback useful. > > Always yours. David Grajales > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redio.development at gmail.com Tue Dec 9 13:36:09 2025 From: redio.development at gmail.com (Red IO) Date: Tue, 9 Dec 2025 14:36:09 +0100 Subject: Fwd: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: Missed the CC ---------- Forwarded message --------- From: Red IO Date: Tue, Dec 9, 2025, 14:34 Subject: Re: [External] : Re: Feedback about LazyConstants API (JEP526) To: Anatoly Kupriyanov I initially thought I agree with your statement that orElse is a common pattern in the jdk. But then I failed to come up with a second example. I then searched the jdk github repo for the method. And I only found Optional and it's specializations and ClassHierarchyResolver. So I would suggest yes, it's an often used method ... of the Optional class. Not many apis seem to expose it. The case of exposing an accessor that returns an Optional on the other hand is incredibly common across the jdk. This is exactly the case Optional was designed for. In this sense Optional is the "Interface" you are suggesting. My main argument against reusing orElse here is that the context is a completely different one. An Optional orElse method is a pure function that always returns the same value. It signals that the value is not there. LazyConstant is different in this regard. The LazyConstant orElse is not pure at all. It depends on rather someone else already initialized the value or not. It signals that the value is not there YET. Great regards RedIODev On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov wrote: > Right, the ScopedValue is another good example I've forgotten. In that > case I am even more inclined to keep the `orElse` as it looks like a > repeating pattern across JDK libraries. Consistency is the way to go! > And maybe even consider having a new interface for the method to make this > pattern explicit?.. > > I am glad that `orElseSet` is removed, the side-effecting is bad; also in > other parts of JDK we already have `computeIfAbsent` for the same idea. I > did not hear about it, and yeah, sounds like the source of this confusion. > > > On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore < > maurizio.cimadamore at oracle.com> wrote: > >> >> On 09/12/2025 11:59, Anatoly Kupriyanov wrote: >> > To be honest, I don't really see why this method causes such confusion. >> >> In part I agree. E.g. when we added this, what we had in mind was just >> >> >> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) >> >> E.g. other APIs have `orElse` method that return a user-provided value >> if some condition isn't met. >> >> I believe the problem we're discussing here is likely also related to >> the fact that the API used to have a side-effecting `orElseSet`, which >> is now removed, and I wonder if, because of that, folks are reading too >> much into what orElse does? >> >> Maurizio >> >> > > -- > WBR, Anatoly. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kan.izh at gmail.com Tue Dec 9 14:12:44 2025 From: kan.izh at gmail.com (Anatoly Kupriyanov) Date: Tue, 9 Dec 2025 14:12:44 +0000 Subject: [External] : Re: Feedback about LazyConstants API (JEP526) In-Reply-To: References: <10add665-86f5-4a5e-9b4b-d4ceb20b4494@oracle.com> <37152b24-6f4c-4fb9-a2f8-c444d3be58e6@oracle.com> <7f79f147-c9f1-4411-94dc-81b737def634@oracle.com> Message-ID: My idea is not an optional *interface*, but an interface for something which is convertible to the Optional *type*. In other words, neither the LazyConstant nor to ScopedVariable *is not* an optional itself, but could be converted to it uniformly. Something like this: interface Optionable {// need to think about the better naming! T orElse(T other); // and maybe even: default Optional asOptional() { return Optional.ofNullable(this.orElse(null)); }; } and then LazyConstant, ScopedVariable, etc could just implement the interface to unify on the notion of "return a user-provided value if some condition isn't met". Sounds like a decent path to abolish nulls. But I feel I am overthinking this... On Tue, 9 Dec 2025 at 13:35, Red IO wrote: > I initially thought I agree with your statement that orElse is a common > pattern in the jdk. But then I failed to come up with a second example. I > then searched the jdk github repo for the method. And I only found Optional > and it's specializations and ClassHierarchyResolver. > So I would suggest yes, it's an often used method ... of the Optional > class. Not many apis seem to expose it. The case of exposing an accessor > that returns an Optional on the other hand is incredibly common across the > jdk. This is exactly the case Optional was designed for. In this sense > Optional is the "Interface" you are suggesting. > > My main argument against reusing orElse here is that the context is a > completely different one. > An Optional orElse method is a pure function that always returns the same > value. It signals that the value is not there. > LazyConstant is different in this regard. The LazyConstant orElse is not > pure at all. It depends on rather someone else already initialized the > value or not. It signals that the value is not there YET. > > Great regards > RedIODev > > > > On Tue, Dec 9, 2025, 13:51 Anatoly Kupriyanov wrote: > >> Right, the ScopedValue is another good example I've forgotten. In that >> case I am even more inclined to keep the `orElse` as it looks like a >> repeating pattern across JDK libraries. Consistency is the way to go! >> And maybe even consider having a new interface for the method to make >> this pattern explicit?.. >> >> I am glad that `orElseSet` is removed, the side-effecting is bad; also in >> other parts of JDK we already have `computeIfAbsent` for the same idea. I >> did not hear about it, and yeah, sounds like the source of this confusion. >> >> >> On Tue, 9 Dec 2025 at 12:05, Maurizio Cimadamore < >> maurizio.cimadamore at oracle.com> wrote: >> >>> >>> On 09/12/2025 11:59, Anatoly Kupriyanov wrote: >>> > To be honest, I don't really see why this method causes such confusion. >>> >>> In part I agree. E.g. when we added this, what we had in mind was just >>> >>> >>> https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/ScopedValue.html#orElse(T) >>> >>> E.g. other APIs have `orElse` method that return a user-provided value >>> if some condition isn't met. >>> >>> I believe the problem we're discussing here is likely also related to >>> the fact that the API used to have a side-effecting `orElseSet`, which >>> is now removed, and I wonder if, because of that, folks are reading too >>> much into what orElse does? >>> >>> Maurizio >>> >>> >> >> -- >> WBR, Anatoly. >> > -- WBR, Anatoly. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Dec 9 15:56:39 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Dec 2025 15:56:39 GMT Subject: RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message Message-ID: Can I please get a review of this test-only change which proposes to address the intermittent failures in `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`? As noted in https://bugs.openjdk.org/browse/JDK-8287062, this test fails intermittently. This test was introduced in https://bugs.openjdk.org/browse/JDK-8277795 with the goal to verify that the LDAP connection timeout was honoured when concurrent connections were attempted. The test itself is simple and launches the LDAP connection attempts concurrently and expects each attempt to fail with an exception. In order to verify that the failure is for the right reasons, it tries its best to check the exception type and exception message. If they don't match the exception messages this test knows of, the exception is propagated to fail the test. It so happens that different parts of LDAP connection management code and some other parts of java.net.Socket code might emit different exception messages and in some cases the java.net.Socket might emit the right exception type but without any exception message. Some of the recent sightings of this test failure have this stacktrace: javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.SocketTimeoutException] at java.naming/com.sun.jndi.ldap.Connection.(Connection.java:251) at java.naming/com.sun.jndi.ldap.LdapClient.(LdapClient.java:136) at java.naming/com.sun.jndi.ldap.LdapClientFactory.createPooledConnection(LdapClientFactory.java:71) at java.naming/com.sun.jndi.ldap.pool.Connections.createConnection(Connections.java:184) at java.naming/com.sun.jndi.ldap.pool.Connections.getAvailableConnection(Connections.java:150) at java.naming/com.sun.jndi.ldap.pool.Pool.getOrCreatePooledConnection(Pool.java:196) at java.naming/com.sun.jndi.ldap.pool.Pool.getPooledConnection(Pool.java:152) at java.naming/com.sun.jndi.ldap.LdapPoolManager.getLdapClient(LdapPoolManager.java:339) ... at java.naming/javax.naming.directory.InitialDirContext.(InitialDirContext.java:130) at LdapPoolTimeoutTest.lambda$attemptConnect$0(LdapPoolTimeoutTest.java:114) at LdapTimeoutTest.lambda$assertCompletion$0(LdapTimeoutTest.java:361) at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:330) at java.base/java.lang.Thread.run(Thread.java:1516) Caused by: java.net.SocketTimeoutException at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:93) at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:284) at java.base/java.net.Socket.connect(Socket.java:668) at java.naming/com.sun.jndi.ldap.Connection.createConnectionSocket(Connection.java:341) at java.naming/com.sun.jndi.ldap.Connection.createSocket(Connection.java:283) at java.naming/com.sun.jndi.ldap.Connection.(Connection.java:230) ... 24 more So it did fail for the right reason, but the test is unaware that one part of the java.net.Socket implementation throws the specified `java.net.SocketTimeoutException`, but without any exception message in that exception (https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/net/SocksSocketImpl.java#L93). This causes the test to fail. The commit in this PR cleans up the exception handling code in the test to make it simpler. The updated code continues to expect a `NamingException` with a `cause` which is either a `SocketTimeoutException` type or has one of the known exception messages. This change continues to test the original expectations for which it was introduced in JDK-8277795. tier2 testing with this change is in progress. ------------- Commit messages: - missed an exception message in previous commit - 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message Changes: https://git.openjdk.org/jdk/pull/28725/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28725&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287062 Stats: 58 lines in 1 file changed: 25 ins; 13 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/28725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28725/head:pull/28725 PR: https://git.openjdk.org/jdk/pull/28725 From jpai at openjdk.org Tue Dec 9 16:03:15 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 9 Dec 2025 16:03:15 GMT Subject: RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this test-only change which proposes to address the intermittent failures in `com/sun/jndi/ldap/LdapPoolTimeoutTest.java`? > > As noted in https://bugs.openjdk.org/browse/JDK-8287062, this test fails intermittently. This test was introduced in https://bugs.openjdk.org/browse/JDK-8277795 with the goal to verify that the LDAP connection timeout was honoured when concurrent connections were attempted. The test itself is simple and launches the LDAP connection attempts concurrently and expects each attempt to fail with an exception. In order to verify that the failure is for the right reasons, it tries its best to check the exception type and exception message. If they don't match the exception messages this test knows of, the exception is propagated to fail the test. > > It so happens that different parts of LDAP connection management code and some other parts of java.net.Socket code might emit different exception messages and in some cases the java.net.Socket might emit the right exception type but without any exception message. Some of the recent sightings of this test failure have this stacktrace: > > > javax.naming.CommunicationException: example.com:1234 [Root exception is java.net.SocketTimeoutException] > at java.naming/com.sun.jndi.ldap.Connection.(Connection.java:251) > at java.naming/com.sun.jndi.ldap.LdapClient.(LdapClient.java:136) > at java.naming/com.sun.jndi.ldap.LdapClientFactory.createPooledConnection(LdapClientFactory.java:71) > at java.naming/com.sun.jndi.ldap.pool.Connections.createConnection(Connections.java:184) > at java.naming/com.sun.jndi.ldap.pool.Connections.getAvailableConnection(Connections.java:150) > at java.naming/com.sun.jndi.ldap.pool.Pool.getOrCreatePooledConnection(Pool.java:196) > at java.naming/com.sun.jndi.ldap.pool.Pool.getPooledConnection(Pool.java:152) > at java.naming/com.sun.jndi.ldap.LdapPoolManager.getLdapClient(LdapPoolManager.java:339) > ... > at java.naming/javax.naming.directory.InitialDirContext.(InitialDirContext.java:130) > at LdapPoolTimeoutTest.lambda$attemptConnect$0(LdapPoolTimeoutTest.java:114) > at LdapTimeoutTest.lambda$assertCompletion$0(LdapTimeoutTest.java:361) > at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:330) > at java.base/java.lang.Thread.run(Thread.java:1516) > Caused by: java.net.SocketTimeoutException > at java.base/java.net.SocksSocketImpl.remainingMillis(SocksSocketImpl.java:93) > at java.base/java.net.SocksSocketImpl.connect(SocksSocketImpl.java:28... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: fail if InitialDirContext() construction completes normally ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28725/files - new: https://git.openjdk.org/jdk/pull/28725/files/6b45cfe8..a9eb3fef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28725&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28725&range=00-01 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28725.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28725/head:pull/28725 PR: https://git.openjdk.org/jdk/pull/28725 From duke at openjdk.org Tue Dec 9 16:41:34 2025 From: duke at openjdk.org (jengebr) Date: Tue, 9 Dec 2025 16:41:34 GMT Subject: RFR: 8371656: HashMap.putAll() optimizations [v3] In-Reply-To: References: Message-ID: On Thu, 4 Dec 2025 14:59:33 GMT, jengebr wrote: >> # HashMap.putAll() optimizations: Eliminating Megamorphic Call Site Bottlenecks >> >> ## Summary >> >> This PR addresses performance bottlenecks in `HashMap.putMapEntries()` by implementing direct optimizations for specific input types: `j.u.HashMap` and `j.u.Collections$UnmodifiableMap`. The optimizations target `HashMap(Map)` constructor and `putAll()` operations based on the real-world megamorphic behavior identified in [JDK-8368292](https://bugs.openjdk.org/browse/JDK-8368292), delivering significant performance improvements when multiple `Map` subtypes are used. >> >> ## Problem Context >> >> ### Megamorphic Call Site Overhead in Map Iteration >> `HashMap.putMapEntries()` currently uses a generic approach that suffers from megamorphic call site overhead when applications perform bulk creation or population of HashMaps from various source map types: >> >> 1. `m.entrySet()` becomes megamorphic across different map implementations >> 2. `entrySet().iterator()` creates different iterator types >> 3. `entry.getKey()` and `entry.getValue()` calls vary by map type >> 4. Individual `putVal()` calls for each entry >> >> When the source is `Collections$UnmodifiableMap`, the problem is compounded by megamorphic wrappers around the already-megamorphic iteration methods. In cases where the unwrapped map is also a HashMap, both the wrapper overhead and the iteration overhead can be eliminated with a single optimization. >> >> ## Optimized Methods >> >> ### HashMap >> - **`putMapEntries(Map m, boolean evict)`**: Added fast paths for UnmodifiableMap unwrapping and HashMap-to-HashMap copying >> - **`putMapEntries(HashMap src, boolean evict)`**: copies HashMap-to-HashMap via direct Node processing. Avoids polymorphic issues and eliminates redundant calls to HashMap.hash(). >> >> ## Implementation Details >> >> ### HashMap-to-HashMap Fast Path >> Directly iterates over `src.table` to eliminate entrySet() allocation and polymorphic iterator calls, using the internal Node structure for maximum efficiency. >> >> ### UnmodifiableMap Unwrapping >> Detects UnmodifiableMap instances and accesses the underlying map directly via the `m` field, eliminating wrapper-induced megamorphic call sites. UnmodifiableMap visibility changed from `private` to package-private to enable this direct access. >> >> ## Performance Impact >> >> | Source Type | Size | Poisoned | Baseline | Optimized | Improvement | >> |-------------|------|----------|----------|-----... > > jengebr has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge branch 'openjdk:master' into putMapEntriesOptimizations > - Unit test revisions > - Bug fix & unit test > - fixing whitespace > - Optimizing HashMap.putAll() and . for HashMap and C$UM @stuart-marks would you mind reviewing this one? It's conceptually similar to the ArrayList modifications, but applied to different classes and most details differ. I incorporated lessons about MOAT so that part should be cleaner. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28243#issuecomment-3633197823 From psandoz at openjdk.org Tue Dec 9 17:49:48 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 9 Dec 2025 17:49:48 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Tue, 9 Dec 2025 08:30:01 GMT, Eric Fang wrote: >> For masking we need to start with the identity or otherwise use the identify when no mask bits are set. It would be better to declare as constants and refer to them e.g., `UMAX_VALUE`, `UMIN_VALUE`. There are also other cases where we use identity values for reduction and they follow the same pattern of declaration and use. > > Okay, I understand, thank you for your insight! I'll wait for @PaulSandoz 's comment and see if we should add two **public** constants to this PR. Then I'll modify it accordingly. I would prefer to declare identity constants, but **only** in tests [1] , such as `MUL_IDENTITY`, `UMAX_IDENTITY` etc, that we consistently refer to and then add basic tests to verify that identity with respect to the scalar operation. The identity values are also embedded in the JDK and HotSpot compiler and i want to ensure they are clearly compared against the expected identity when an all-false mask is used. [1] later we could place these in some internal JDK class so we can use the same values in the JDK code, then adjust the tests to grant access to the internal JDK class to use those values. A more general place to surface up scalar identity values is in `VectorOperators` for the associative operators, something to consider later on perhaps, and that would require a CSR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2603648258 From fmatte at openjdk.org Tue Dec 9 17:54:26 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Tue, 9 Dec 2025 17:54:26 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: <07Lh9_7S--m8fbhk_3OAOyxeP9s0PNPB9yYYFs4Bw4c=.f05b1e1d-cd5e-4528-9fb6-c0145f9e542a@github.com> References: <07Lh9_7S--m8fbhk_3OAOyxeP9s0PNPB9yYYFs4Bw4c=.f05b1e1d-cd5e-4528-9fb6-c0145f9e542a@github.com> Message-ID: <05DmE7i5Mg9BccJia6gJNLwZfKH8JXpMn4ZQHf6aXVM=.6b3ad21a-03c0-4a98-8b2b-e0ff49c42d3e@github.com> On Tue, 9 Dec 2025 05:30:52 GMT, Kim Barrett wrote: >> Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: >> >> Correcting return from error condition > > src/java.base/unix/native/libjli/java_md_common.c line 286: > >> 284: return (0); >> 285: } >> 286: > > Why not just delete this no longer used function? Thanks Kim for looking into it, yes we can remove this, I wasn't sure why this was kept and not removed. Removing is good, as this was unused since JDK 9 times. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28708#discussion_r2603703727 From fmatte at openjdk.org Tue Dec 9 18:01:00 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Tue, 9 Dec 2025 18:01:00 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v3] In-Reply-To: References: Message-ID: > 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: removing unused CheckSanity function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28708/files - new: https://git.openjdk.org/jdk/pull/28708/files/046e8181..1fe110f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=01-02 Stats: 28 lines in 1 file changed: 0 ins; 28 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28708.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28708/head:pull/28708 PR: https://git.openjdk.org/jdk/pull/28708 From fmatte at openjdk.org Tue Dec 9 18:01:02 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Tue, 9 Dec 2025 18:01:02 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: Message-ID: <0bBftBPkAlr8nm-29W8RD_vjGVxGOddsypk-SkKh4i4=.af491baf-2dfa-4e96-9a61-a774366fe95a@github.com> On Tue, 9 Dec 2025 12:09:06 GMT, SendaoYan wrote: > Do we need update the copyright year. I am not sure, this is just a trivial cleanup change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28708#issuecomment-3633529349 From naoto at openjdk.org Tue Dec 9 18:24:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Dec 2025 18:24:44 GMT Subject: RFR: 8355522: Remove the `java.locale.useOldISOCodes` system property [v6] In-Reply-To: References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: On Mon, 8 Dec 2025 20:54:34 GMT, Naoto Sato wrote: >> This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Andrey Turbanov Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/26419#issuecomment-3633629881 From naoto at openjdk.org Tue Dec 9 18:24:46 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 9 Dec 2025 18:24:46 GMT Subject: Integrated: 8355522: Remove the `java.locale.useOldISOCodes` system property In-Reply-To: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> References: <6Ca8zNdgZWlcivQkpZjjp3rBFWIdyYzQEyKLeXDloVc=.4a5f20b8-49cf-4cea-962f-5b8e99f7b0af@github.com> Message-ID: <9lj9uqEfY1OCrmtV5GPDGQYFdJZEadvzidDCxoHLcJQ=.78ceb2cc-e229-4aac-84de-8e61cdc2394c@github.com> On Mon, 21 Jul 2025 22:56:50 GMT, Naoto Sato wrote: > This PR removes the system property deprecated in JDK 25. If the property is specified at runtime, a warning will be emitted at startup to inform the user that the value is ignored. A corresponding CSR has been drafted as well This pull request has now been integrated. Changeset: b2daf9de Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/b2daf9de3097de4d3b3c7d565e29a48b4aae19ee Stats: 106 lines in 6 files changed: 2 ins; 68 del; 36 mod 8355522: Remove the `java.locale.useOldISOCodes` system property Reviewed-by: jlu, joehw ------------- PR: https://git.openjdk.org/jdk/pull/26419 From duke at openjdk.org Tue Dec 9 21:18:09 2025 From: duke at openjdk.org (Trevor Bond) Date: Tue, 9 Dec 2025 21:18:09 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments Message-ID: Add a new factory method to `IncrementInstruction` that allows the explicit creation of a wide iinc instruction, even with a `slot` and `constant` that could fit into a normal iinc instruction. Previously, only one factory for iinc instructions existed, which inferred the type of instruction needed given the size of `slot` and `constant`. Add additional test cases for the new factory as well. All tier 1 tests and classfile tests have passed with these changes. ------------- Commit messages: - JDK-8341272 Changes: https://git.openjdk.org/jdk/pull/28729/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28729&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341272 Stats: 71 lines in 4 files changed: 66 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28729/head:pull/28729 PR: https://git.openjdk.org/jdk/pull/28729 From psandoz at openjdk.org Wed Dec 10 00:00:47 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 10 Dec 2025 00:00:47 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v4] In-Reply-To: References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: On Mon, 8 Dec 2025 20:00:28 GMT, Xueming Shen wrote: >> ### Summary >> >> - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result >> - Add additional test data to the existing VectorMask from/toLong tests. >> - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template > > Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision: > > - update: restore boolUnaryOpProvider for reduction/Unit-BoolReduction-op.template > - minor update > - update > - update > - update > - update > - update > - update > - update > - 8371446: VectorAPI: Add unit tests for masks from various long values Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28593#pullrequestreview-3560166776 From fmatte at openjdk.org Wed Dec 10 00:03:03 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Wed, 10 Dec 2025 00:03:03 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v4] In-Reply-To: References: Message-ID: > 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: updated the copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28708/files - new: https://git.openjdk.org/jdk/pull/28708/files/1fe110f4..0f80a1fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28708&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28708.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28708/head:pull/28708 PR: https://git.openjdk.org/jdk/pull/28708 From kbarrett at openjdk.org Wed Dec 10 00:03:05 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Dec 2025 00:03:05 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: <0bBftBPkAlr8nm-29W8RD_vjGVxGOddsypk-SkKh4i4=.af491baf-2dfa-4e96-9a61-a774366fe95a@github.com> References: <0bBftBPkAlr8nm-29W8RD_vjGVxGOddsypk-SkKh4i4=.af491baf-2dfa-4e96-9a61-a774366fe95a@github.com> Message-ID: On Tue, 9 Dec 2025 17:54:43 GMT, Fairoz Matte wrote: > > Do we need update the copyright year. > > I am not sure, this is just a trivial cleanup change. I think you should update the copyright year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28708#issuecomment-3634741749 From kbarrett at openjdk.org Wed Dec 10 00:03:04 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 10 Dec 2025 00:03:04 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v4] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 23:49:32 GMT, Fairoz Matte wrote: >> 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated > > Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: > > updated the copyright year Looks good. ------------- Marked as reviewed by kbarrett (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28708#pullrequestreview-3560167672 From fmatte at openjdk.org Wed Dec 10 00:03:07 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Wed, 10 Dec 2025 00:03:07 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: <0bBftBPkAlr8nm-29W8RD_vjGVxGOddsypk-SkKh4i4=.af491baf-2dfa-4e96-9a61-a774366fe95a@github.com> Message-ID: On Tue, 9 Dec 2025 23:40:57 GMT, Kim Barrett wrote: > > > Do we need update the copyright year. > > > > > > I am not sure, this is just a trivial cleanup change. > > I think you should update the copyright year. I have updated the copyright year! Thanks, ------------- PR Comment: https://git.openjdk.org/jdk/pull/28708#issuecomment-3634758480 From liach at openjdk.org Wed Dec 10 00:00:48 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 00:00:48 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 20:59:58 GMT, Trevor Bond wrote: > Add a new factory method to `IncrementInstruction` that allows the explicit creation of a wide iinc instruction, even with a `slot` and `constant` that could fit into a normal iinc instruction. Previously, only one factory for iinc instructions existed, which inferred the type of instruction needed given the size of `slot` and `constant`. Add additional test cases for the new factory as well. All tier 1 tests and classfile tests have passed with these changes. Since this is an API addition, this will require a CSR. Once we have settled with the javadocs, I can create a CSR (which requires a JBS account) src/java.base/share/classes/java/lang/classfile/instruction/IncrementInstruction.java line 95: > 93: *

> 94: * The ranges of {@code slot} and {@code constant} are restricted by the > 95: * {@code op} and its {@linkplain Opcode#sizeIfFixed() size}: Since there are only two possible Opcodes `IINC` and `IINC_W`, you can just name them instead of specifying by their size. I know you copied from the load and store instructions; I had to use size there because listing all of `ILOAD_0`, `ILOAD_1`, `ILOAD_2`, `ILOAD_3` is less concise than using the size. You can look at `DiscontinuedInstruction.RetInstruction` for a better template to follow. src/java.base/share/classes/java/lang/classfile/instruction/IncrementInstruction.java line 118: > 116: * {@link Opcode.Kind#INCREMENT} or {@code slot} or > 117: * {@code constant} is out of range > 118: */ Suggestion: * {@code constant} is out of range * @since 27 */ src/java.base/share/classes/jdk/internal/classfile/impl/BytecodeHelpers.java line 456: > 454: boolean requiresWide = validateAndIsWideIinc(slot, constant); > 455: int size = opcode.sizeIfFixed(); > 456: if ((size == 3 && requiresWide)) { Suggestion: if (validateAndIsWideIinc(slot, constant) && opcode != Opcode.IINC_W) { test/jdk/jdk/classfile/InstructionValidationTest.java line 265: > 263: > 264: @Test > 265: void testExplicitIincConstant() { Each method tests one instruction interface, so I think you should merge this into `testIincConstant()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28729#issuecomment-3634775601 PR Review Comment: https://git.openjdk.org/jdk/pull/28729#discussion_r2604710736 PR Review Comment: https://git.openjdk.org/jdk/pull/28729#discussion_r2604730390 PR Review Comment: https://git.openjdk.org/jdk/pull/28729#discussion_r2604718223 PR Review Comment: https://git.openjdk.org/jdk/pull/28729#discussion_r2604727924 From sherman at openjdk.org Wed Dec 10 00:54:17 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 10 Dec 2025 00:54:17 GMT Subject: Integrated: 8371446: VectorAPI: Add unit tests for masks from various long values In-Reply-To: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: On Tue, 2 Dec 2025 00:53:40 GMT, Xueming Shen wrote: > ### Summary > > - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result > - Add additional test data to the existing VectorMask from/toLong tests. > - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template This pull request has now been integrated. Changeset: eef9813a Author: Xueming Shen URL: https://git.openjdk.org/jdk/commit/eef9813ad42b02db5fc636e661a751d5120a639e Stats: 9997 lines in 39 files changed: 6064 ins; 3550 del; 383 mod 8371446: VectorAPI: Add unit tests for masks from various long values Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/28593 From duke at openjdk.org Wed Dec 10 01:37:06 2025 From: duke at openjdk.org (Trevor Bond) Date: Wed, 10 Dec 2025 01:37:06 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 20:59:58 GMT, Trevor Bond wrote: > Add a new factory method to `IncrementInstruction` that allows the explicit creation of a wide iinc instruction, even with a `slot` and `constant` that could fit into a normal iinc instruction. Previously, only one factory for iinc instructions existed, which inferred the type of instruction needed given the size of `slot` and `constant`. Add additional test cases for the new factory as well. All tier 1 tests and classfile tests have passed with these changes. Thank you for your comments and review. I have made some changes that should address those. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28729#issuecomment-3634977206 From duke at openjdk.org Wed Dec 10 01:37:05 2025 From: duke at openjdk.org (Trevor Bond) Date: Wed, 10 Dec 2025 01:37:05 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments [v2] In-Reply-To: References: Message-ID: > Add a new factory method to `IncrementInstruction` that allows the explicit creation of a wide iinc instruction, even with a `slot` and `constant` that could fit into a normal iinc instruction. Previously, only one factory for iinc instructions existed, which inferred the type of instruction needed given the size of `slot` and `constant`. Add additional test cases for the new factory as well. All tier 1 tests and classfile tests have passed with these changes. Trevor Bond has updated the pull request incrementally with one additional commit since the last revision: Clean up javadocs and address other review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28729/files - new: https://git.openjdk.org/jdk/pull/28729/files/4acc5b44..44612c5f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28729&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28729&range=00-01 Stats: 33 lines in 3 files changed: 8 ins; 19 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28729.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28729/head:pull/28729 PR: https://git.openjdk.org/jdk/pull/28729 From erfang at openjdk.org Wed Dec 10 02:35:07 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 10 Dec 2025 02:35:07 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v4] In-Reply-To: References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: On Mon, 8 Dec 2025 20:00:28 GMT, Xueming Shen wrote: >> ### Summary >> >> - Update the existing unit tests for VectorMask to verify the correctness of the hotspot compiler result >> - Add additional test data to the existing VectorMask from/toLong tests. >> - Move the VectorMask binary-op & unary-op tests from Unit-Miscellaneous.template to unit-kernel-template > > Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - update: restore boolUnaryOpProvider for reduction/Unit-BoolReduction-op.template > - minor update > - update > - update > - update > - update > - update > - update > - update > - 8371446: VectorAPI: Add unit tests for masks from various long values The `bash gen-tests.sh` command was not run, resulting in inconsistencies between the template and the generated test code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28593#issuecomment-3635092131 From sherman at openjdk.org Wed Dec 10 07:29:41 2025 From: sherman at openjdk.org (Xueming Shen) Date: Wed, 10 Dec 2025 07:29:41 GMT Subject: RFR: 8371446: VectorAPI: Add unit tests for masks from various long values [v4] In-Reply-To: References: <-InNgIGCP8bzIGZyfZC5YfcUij1J0ZH_vJwcNmlwd1M=.0d48a4c2-b0bc-44d6-b8a4-777d3f7a37e1@github.com> Message-ID: <1xgYYms_X-P5yIKgO-IbGb181rrw7F-_Sywgec9WoPM=.0a925160-3762-4b0e-9d49-f866f329be3a@github.com> On Wed, 10 Dec 2025 02:32:05 GMT, Eric Fang wrote: >> Xueming Shen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: >> >> - update: restore boolUnaryOpProvider for reduction/Unit-BoolReduction-op.template >> - minor update >> - update >> - update >> - update >> - update >> - update >> - update >> - update >> - 8371446: VectorAPI: Add unit tests for masks from various long values > > The `bash gen-tests.sh` command was not run, resulting in inconsistencies between the template and the generated test code. @erifan JDK-8373390 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28593#issuecomment-3635744959 From epeter at openjdk.org Wed Dec 10 07:38:33 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 07:38:33 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 17 additional commits since the last revision: > > - Review > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - ... and 7 more: https://git.openjdk.org/jdk/compare/edba0887...d734e8a6 Was asked on slack to review IR tests, so that's all I'm doing here - won't review the whole patch ;) test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;) test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 41: > 39: * @summary Verify constant folding is possible for mismatched VarHandle access > 40: * @library /test/lib / > 41: * @requires vm.compiler2.enabled What would happen if you removed this? Is the test expected to fail anywhere? IR rules are executed only if C2 is available anyway, so probably you don't need this restriction. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3561137086 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605521507 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605526968 From epeter at openjdk.org Wed Dec 10 07:42:29 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 07:42:29 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v5] In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 21:14:24 GMT, Chen Liang wrote: >> Currently, the hotspot compiler (as in ciField) trusts final fields in hidden classes, record classes, and selected jdk packages. Some classes in the JDK wish to be trusted, but they cannot apply package-wide opt-in due to other legacy classes in the package, such as java.util. >> >> They currently can use `@Stable` as a workaround, but this is fragile because a stable final field may hold a trusted null, zero, or false value, which is currently treated as non-constant by ciField. >> >> We should add an annotation to opt-in for a whole class, mainly for legacy packages. This would benefit greatly some of our classes already using a lot of Stable, such as java.util.Optional, whose empty instance is now constant-foldable, as demonstrated in a new IR test. >> >> Paging @minborg who requested Optional folding for review. >> >> I think we can remove redundant Stable in a few other java.util classes after this patch is integrated. I plan to do that in subsequent patches. > > Chen Liang 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 11 additional commits since the last revision: > > - Jorn review > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - bracket styles > - Doc tweaks > - Essay > - Spurious change > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Issue number and test update > - Fixed optional and unit test > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - ... and 1 more: https://git.openjdk.org/jdk/compare/f4fe3397...b20b7f5b Drive-by comments about IR test only ;) test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. We would like to move all tests away from `irTests`. It would be better to sort tests by topic, rather than by the method we test them. test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 39: > 37: * @summary Verify constant folding for Optional > 38: * @library /test/lib / > 39: * @requires vm.compiler2.enabled I doubt you actually need the C2 restriction here. IR tests could still run verification for results without C2. IR rules only run if C2 is available, otherwise the test can still pass, just no IR rules are run. test/hotspot/jtreg/compiler/c2/irTests/constantFold/TestOptional.java line 40: > 38: * @library /test/lib / > 39: * @requires vm.compiler2.enabled > 40: * @run driver compiler.c2.irTests.constantFold.TestOptional Suggestion: * @run driver ${test.main.class} Since this is now possible, we should use this templated approach now, to avoid invoking the wrong test classes by accident. ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3561154527 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605537189 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605543019 PR Review Comment: https://git.openjdk.org/jdk/pull/28540#discussion_r2605539633 From dholmes at openjdk.org Wed Dec 10 07:56:26 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 10 Dec 2025 07:56:26 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v4] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 00:03:03 GMT, Fairoz Matte wrote: >> 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated > > Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: > > updated the copyright year Looks good. FTR we always update the copyright year, regardless of the size of the change to the file. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28708#pullrequestreview-3561200674 From chagedorn at openjdk.org Wed Dec 10 08:09:27 2025 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 10 Dec 2025 08:09:27 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: <7__4QGMz-5idIedYYk-0HrQnnMfTa4d-Gl75gvajV0A=.ecba821d-731d-420f-a3f6-9feeb869b20b@github.com> On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 17 additional commits since the last revision: > > - Review > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - ... and 7 more: https://git.openjdk.org/jdk/compare/45fb0e07...d734e8a6 test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 70: > 68: > 69: @Check(test = "testSum") > 70: public void runTestSum() { Drive-by comment: From the method name, it seems that you want to have a runner method. For that, you need to switch to `@Run`. But you can also do result verification with `@Check`. In the latter case, you do not need to call `testSum()` again but you can just add a `long result` as parameter. The IR framework will then call this `@Check` method with the result of `testSum()`. Example: https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/test/hotspot/jtreg/testlibrary_tests/ir_framework/examples/CheckedTestExample.java#L94-L102 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2605606400 From smonteith at openjdk.org Wed Dec 10 09:06:32 2025 From: smonteith at openjdk.org (Stuart Monteith) Date: Wed, 10 Dec 2025 09:06:32 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: On Sat, 6 Dec 2025 12:55:37 GMT, ExE Boss wrote: >> MemorySegments allocated from shared Arena from >> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over. >> >> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op . >> >> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654. >> >> | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | >> |---------|-------|-------|-------|-------|-------|-------| >> | 1 | 30.88 | 32.15 | 33.54 | 32.82 | 27.46 | 8.45 | >> | 2 | 142.56 | 134.48 | 132.01 | 131.50 | 116.68 | 46.53 | >> | 4 | 310.18 | 282.75 | 287.59 | 271.82 | 251.88 | 86.11 | >> | 8 | 702.02 | 710.29 | 736.72 | 670.63 | 533.46 | 194.60 | >> | 16 | 1,436.17 | 1,684.80 | 1,833.69 | 1,782.78 | 1,100.15 | 827.28 | >> | 24 | 2,185.55 | 2,508.86 | 2,732.22 | 2,815.26 | 1,646.09 | 1,530.28 | >> | 32 | 2,942.48 | 3,432.84 | 3,643.64 | 3,782.23 | 2,236.81 | 2,278.52 | >> | 48 | 4,466.56 | 5,174.72 | 5,401.95 | 5,621.41 | 4,926.30 | 3,026.58 | >> >> After: >> >> | Threads | N1 | N2 | V1 | V2 | Xeon | Epyc | >> |---------|-------|-------|-------|-------|-------|-------| >> | 1 | 32.41 | 32.11 | 34.43 | 31.32 | 27.94 | 9.82 | >> | 2 | 32.64 | 33.72 | 35.11 | 31.30 | 28.02 | 9.81 | >> | 4 | 32.71 | 36.84 | 34.67 | 31.35 | 28.12 | 10.49 | >> | 8 | 58... > > src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 89: > >> 87: @ForceInline >> 88: private int getCounter() { >> 89: return Thread.currentThread().hashCode() & mask; > > Maybe use?[`System?::identityHashCode`] here?instead, as?the?`hashCode()`?method of?a?`Thread` can?be?overridden by?subclasses. > Suggestion: > > return System.identityHashCode(Thread.currentThread()) & mask; > > > [`System?::identityHashCode`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/System.html#identityHashCode%28java.lang.Object%29 Thanks - that's a good suggestion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2605783455 From iklam at openjdk.org Wed Dec 10 09:39:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Dec 2025 09:39:58 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer Message-ID: In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs" https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171 Examples of subgraphs: - `java.lang.Integer$IntegerCache::cache` - `jdk.internal.module.ArchivedBootLayer::bootLayer` The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand. To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes. Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with `@AOTSafeClassInitializer`. ------------- Commit messages: - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer Changes: https://git.openjdk.org/jdk/pull/28736/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373392 Stats: 602 lines in 29 files changed: 368 ins; 186 del; 48 mod Patch: https://git.openjdk.org/jdk/pull/28736.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28736/head:pull/28736 PR: https://git.openjdk.org/jdk/pull/28736 From alanb at openjdk.org Wed Dec 10 09:46:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 10 Dec 2025 09:46:27 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v4] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 00:03:03 GMT, Fairoz Matte wrote: >> 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated > > Fairoz Matte has updated the pull request incrementally with one additional commit since the last revision: > > updated the copyright year Looks okay, maybe consider renaming the JBS issue to make it clear that this is just removing unused code. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28708#pullrequestreview-3561613649 From mbaesken at openjdk.org Wed Dec 10 10:19:08 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Wed, 10 Dec 2025 10:19:08 GMT Subject: RFR: 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler Message-ID: test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp fails with VS2019 and some versions of VS2022 compilers as follows ========================8<------------------------ * For target support_test_jdk_jtreg_native_support_libSharedCloseAgent_libSharedCloseAgent.obj: libSharedCloseAgent.cpp z:\BuildAgent\work\23f345c5c4b56004\test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp(105): fatal error C1001: Internal compiler error. (compiler file 'msc1.cpp', line 1603) ------------- Commit messages: - JDK-8371871 Changes: https://git.openjdk.org/jdk/pull/28739/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28739&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371871 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28739.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28739/head:pull/28739 PR: https://git.openjdk.org/jdk/pull/28739 From jbhateja at openjdk.org Wed Dec 10 10:23:30 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 10 Dec 2025 10:23:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v7] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Optimizing tail handling - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Cleanups - Fix failing jtreg test in CI - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Cleanups - Adding support for custom basic type T_FLOAT16, passing BasicType lane types to inline expander entries - Cleaning up interface as per review suggestions - Some cleanups - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 515190 lines in 231 files changed: 284426 ins; 229037 del; 1727 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From bkilambi at openjdk.org Wed Dec 10 11:24:28 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 10 Dec 2025 11:24:28 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v7] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Fix failing jtreg test in CI > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Adding support for custom basic type T_FLOAT16, passing BasicType lane types to inline expander entries > - Cleaning up interface as per review suggestions > - Some cleanups > - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d This patch results in two of the JTREG tests failing on aarch64 machines- jdk/incubator/vector/Float16Vector512Tests.java compiler/vectorapi/TestFloat16VectorOperations.java which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test. @jatin-bhateja Could you please add the attached fix to this patch? Thanks! [fix.patch](https://github.com/user-attachments/files/24076067/fix.patch) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3636610190 From epeter at openjdk.org Wed Dec 10 13:07:34 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 10 Dec 2025 13:07:34 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: <98EVpJFhkgWbAayPsHQB3j1TC3pcedou1EcHBdepAew=.f3560f11-b69c-4e4b-b50e-127a029598e8@github.com> On Tue, 2 Dec 2025 10:30:46 GMT, Quan Anh Mai wrote: > Hi, > > This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. > > I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. > > Please kindly review, thanks a lot. test/hotspot/jtreg/compiler/exceptions/TestDebugDuringExceptionCatching.java line 45: > 43: * @build test.java.lang.invoke.lib.InstructionHelper > 44: * > 45: * @run main/othervm compiler.exceptions.TestDebugDuringExceptionCatching Suggestion: * @run main/othervm ${test.main.class} Drive-by comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28597#discussion_r2606588199 From jvernee at openjdk.org Wed Dec 10 13:31:33 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 10 Dec 2025 13:31:33 GMT Subject: RFR: 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:12:07 GMT, Matthias Baesken wrote: > test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp fails with VS2019 and some versions of VS2022 compilers as follows > > > ========================8<------------------------ > * For target support_test_jdk_jtreg_native_support_libSharedCloseAgent_libSharedCloseAgent.obj: > libSharedCloseAgent.cpp > z:\BuildAgent\work\23f345c5c4b56004\test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp(105): fatal error C1001: Internal compiler error. > (compiler file 'msc1.cpp', line 1603) Marked as reviewed by jvernee (Reviewer). test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp line 106: > 104: > 105: jvmtiCapabilities capabilities; > 106: memset(&capabilities, 0, sizeof(jvmtiCapabilities)); I used `{}` to zero initialize all the fields of this struct. I see other use cases are also using `memset` to zero out the struct. ------------- PR Review: https://git.openjdk.org/jdk/pull/28739#pullrequestreview-3562554074 PR Review Comment: https://git.openjdk.org/jdk/pull/28739#discussion_r2606668513 From mdoerr at openjdk.org Wed Dec 10 13:54:46 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 10 Dec 2025 13:54:46 GMT Subject: RFR: 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler In-Reply-To: References: Message-ID: <4VluRGFdRUWlzx4SzceJA3j2x_77zdkswHGYl7YR9hQ=.906a10da-33c0-4ea6-9c87-71d458a2195f@github.com> On Wed, 10 Dec 2025 10:12:07 GMT, Matthias Baesken wrote: > test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp fails with VS2019 and some versions of VS2022 compilers as follows > > > ========================8<------------------------ > * For target support_test_jdk_jtreg_native_support_libSharedCloseAgent_libSharedCloseAgent.obj: > libSharedCloseAgent.cpp > z:\BuildAgent\work\23f345c5c4b56004\test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp(105): fatal error C1001: Internal compiler error. > (compiler file 'msc1.cpp', line 1603) LGTM. ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28739#pullrequestreview-3562654159 From liach at openjdk.org Wed Dec 10 15:27:56 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 15:27:56 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam wrote: > In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs" > > https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171 > > Examples of subgraphs: > > - `java.lang.Integer$IntegerCache::cache` > - `jdk.internal.module.ArchivedBootLayer::bootLayer` > > The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand. > > To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes. > > Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with `@AOTSafeClassInitializer`. Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive? src/java.base/share/classes/java/util/ImmutableCollections.java line 80: > 78: @AOTRuntimeSetup > 79: private static void runtimeSetup() { > 80: // to generate a reasonably random and well-mixed SALT, use an arbitrary Suggestion: // to generate a reasonably random and well-mixed SALT, use an arbitrary ------------- PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563043067 PR Review Comment: https://git.openjdk.org/jdk/pull/28736#discussion_r2607052565 From liach at openjdk.org Wed Dec 10 15:41:05 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 15:41:05 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Wed, 10 Dec 2025 07:32:59 GMT, Emanuel Peter wrote: >> Chen Liang 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 17 additional commits since the last revision: >> >> - Review >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Bugs and verify loader leak >> - Try to avoid loader leak >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure >> - Test from Jorn >> - Copyright years >> - Fix problem identified by Jorn >> - Rollback getAndAdd for now >> - ... and 7 more: https://git.openjdk.org/jdk/compare/bdc0543f...d734e8a6 > > test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;) What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607162521 From hgreule at openjdk.org Wed Dec 10 16:13:42 2025 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 10 Dec 2025 16:13:42 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Wed, 10 Dec 2025 15:38:12 GMT, Chen Liang wrote: >> test/hotspot/jtreg/compiler/c2/irTests/constantFold/VarHandleMismatchedTypeFold.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. >> >> We want to eventually migrate all tests from `c2/irTests` to more "topic based" directories, so it would be great if you already migrated them now, since you probably would know a better name/place now already ;) > > What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification. Maybe something like `c2/methodhandles` would be a good fit? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607297537 From liach at openjdk.org Wed Dec 10 16:38:21 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 16:38:21 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: <7XWutFIFgBWASCLSHH0XdEurVGgfX14HwelxQttnbr8=.9d92b47a-3313-46c1-822d-79a55cfb7d04@github.com> On Wed, 10 Dec 2025 16:11:07 GMT, Hannes Greule wrote: >> What would be a good directory? I used `c2/irTests/constantFold` as a topic. Maybe you can find a more straightforward directory for constant folding verification. > > Maybe something like `c2/methodhandles` would be a good fit? There is `compiler/jsr292` directory, that might work I think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2607392582 From iklam at openjdk.org Wed Dec 10 17:32:38 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 10 Dec 2025 17:32:38 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 15:25:29 GMT, Chen Liang wrote: > Is IntegerCache.cache the only field that need to be adjusted according to system properties after loading from AOT archive? I think so. The cache size for all other Number types are fixed and cannot be modified by the command-line. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3638192576 From liach at openjdk.org Wed Dec 10 17:39:46 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 17:39:46 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 09:31:37 GMT, Ioi Lam wrote: > In legacy CDS, Java objects used by certain classes are computed ahead of time using "object subgraphs" > > https://github.com/openjdk/jdk/blob/1bbbce75c5e68429c2a32519eb3c36d964dcdf57/src/hotspot/share/cds/heapShared.cpp#L168-L171 > > Examples of subgraphs: > > - `java.lang.Integer$IntegerCache::cache` > - `jdk.internal.module.ArchivedBootLayer::bootLayer` > > The implementation requires special code (in both Java and C++) to be executed when a CDS archive is created or loaded. As a result, we have an execution model that's difficult to implement/extend and the behavior is hard to understand. > > To move towards the AOT Cache Snapshot Model ([JDK-8365645](https://bugs.openjdk.org/browse/JDK-8365645)) we should replace the subgraphs with the use of `@AOTSafeClassInitializer`, and if necessary, `@AOTRuntimeSetup`. This will simplify the current implementation, and make it possible to extend AOT-initializations to more core classes. > > Note, the use of `@AOTSafeClassInitializer` requires `-XX:+AOTClassLinking`. For the time being, we retain the old CDS object subgraph code to cover the `-XX:-AOTClassLinking` cases. Such code will be marked with comments like `/* Legacy CDS archive support (to be deprecated) */`. All future AOT creation of Java objects will be done with `@AOTSafeClassInitializer`. The Java code changes look reasonable. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3563746741 From fmatte at openjdk.org Wed Dec 10 18:20:09 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Wed, 10 Dec 2025 18:20:09 GMT Subject: RFR: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated [v2] In-Reply-To: References: <0bBftBPkAlr8nm-29W8RD_vjGVxGOddsypk-SkKh4i4=.af491baf-2dfa-4e96-9a61-a774366fe95a@github.com> Message-ID: On Tue, 9 Dec 2025 23:40:57 GMT, Kim Barrett wrote: >>> Do we need update the copyright year. >> >> I am not sure, this is just a trivial cleanup change. > >> > Do we need update the copyright year. >> >> I am not sure, this is just a trivial cleanup change. > > I think you should update the copyright year. @kimbarrett @dholmes-ora and @AlanBateman thanks for the reviews, I have updated the JBS issue to reflect the change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28708#issuecomment-3638369678 From fmatte at openjdk.org Wed Dec 10 18:20:10 2025 From: fmatte at openjdk.org (Fairoz Matte) Date: Wed, 10 Dec 2025 18:20:10 GMT Subject: Integrated: 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 22:06:20 GMT, Fairoz Matte wrote: > 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated This pull request has now been integrated. Changeset: 11aa6e10 Author: Fairoz Matte URL: https://git.openjdk.org/jdk/commit/11aa6e10c017a7257c60eb7395d728d32b2006d4 Stats: 24 lines in 1 file changed: 0 ins; 23 del; 1 mod 8373270: GCC 14.2.0 reports warning: '%s' directive output may be truncated Reviewed-by: kbarrett, dholmes, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28708 From vlivanov at openjdk.org Wed Dec 10 19:51:06 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Dec 2025 19:51:06 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Mon, 8 Dec 2025 19:10:48 GMT, Chen Liang wrote: >> Since access descriptor is created for each VH operation site, we can optimistically cache the adapted method handle in a site if the site operates on a constant VH. Used a C2 IR test to verify such a setup through an inexact VarHandle invocation can be constant folded through (previously, it was blocked by `asType`) > > Chen Liang 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 17 additional commits since the last revision: > > - Review > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Bugs and verify loader leak > - Try to avoid loader leak > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure > - Test from Jorn > - Copyright years > - Fix problem identified by Jorn > - Rollback getAndAdd for now > - ... and 7 more: https://git.openjdk.org/jdk/compare/8da6ec63...d734e8a6 make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132: > 130: // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails > 131: // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and > 132: // testArrayAtomicThenAtomicAtUnknownIndices works It doesn't look right. Was is the root cause of the failure? Can it be a test bug? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608010297 From liach at openjdk.org Wed Dec 10 22:11:49 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 10 Dec 2025 22:11:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Wed, 10 Dec 2025 19:48:49 GMT, Vladimir Ivanov wrote: >> Chen Liang 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 17 additional commits since the last revision: >> >> - Review >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Bugs and verify loader leak >> - Try to avoid loader leak >> - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache >> - Revert void special case removal due to C2 shortage causing TestZGCBarrierElision::testAtomicThenAtomicAnotherField failure >> - Test from Jorn >> - Copyright years >> - Fix problem identified by Jorn >> - Rollback getAndAdd for now >> - ... and 7 more: https://git.openjdk.org/jdk/compare/f510a486...d734e8a6 > > make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132: > >> 130: // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails >> 131: // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and >> 132: // testArrayAtomicThenAtomicAtUnknownIndices works > > It doesn't look right. What is the root cause of the failure? Can it be a test bug? I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608390544 From vlivanov at openjdk.org Wed Dec 10 22:16:22 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Wed, 10 Dec 2025 22:16:22 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v9] In-Reply-To: References: <4YumBpbA2k8DC13H1s808_5OJx-1FMxD9CbIUfRTb8Q=.742f90c9-0d93-43b7-abe7-76422a0c8359@github.com> Message-ID: On Wed, 10 Dec 2025 22:09:21 GMT, Chen Liang wrote: >> make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 132: >> >>> 130: // TestZGCBarrierElision.testAtomicThenAtomicAnotherField fails >>> 131: // However, testArrayAtomicThenAtomic, testAtomicThenAtomic, and >>> 132: // testArrayAtomicThenAtomicAtUnknownIndices works >> >> It doesn't look right. What is the root cause of the failure? Can it be a test bug? > > I think that is when two different VarHandles are both invoked non-exactly in two call sites in one method, the 2nd one fails to be inlined, that the compare-and-exchange from the 2nd one is not present in the final IR. The deoptimization reason is either "unstable-if" or "too many null checks", I think I will try look into it in another effort. If it's a test problem, then it's better to comment out the problematic test case instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2608398869 From duke at openjdk.org Wed Dec 10 22:25:36 2025 From: duke at openjdk.org (duke) Date: Wed, 10 Dec 2025 22:25:36 GMT Subject: Withdrawn: 8360025: (se) Convert kqueue Selector Implementation to use FFM APIs In-Reply-To: References: Message-ID: On Tue, 14 Oct 2025 10:38:01 GMT, Darragh Clarke wrote: > This PR was originally part of #25546, though that PR has been split in 2, the first chunk was https://github.com/openjdk/jdk/pull/27590. > > This PR aims to convert KQueue to use FFM apis, the first PR in this area added all the jextract generated code needed, while this PR modifies some of the jextract code and then uses it with Kqueue. > > A brief rundown of the changes: > - The files `errno_h$shared.java` , `kqueue_h$shared.java`, `timespec_h$shared.java` and `timespec_h.java` have all been deleted. This is because they all contained shared elements that could be moved into the Utility file `FFMUtils.java` > - `Kqueue.c` has been deleted, and all native methods in the other `KQueue` files have been replaced with references to the generated files kevent and kqueue. This is the bulk of the changes > - Both the `Kqueue()` and `Kevent()` methods in `kqueue_h.java` were modified to use adapted method handles that will return the errno value This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27796 From sherman at openjdk.org Thu Dec 11 00:46:51 2025 From: sherman at openjdk.org (Xueming Shen) Date: Thu, 11 Dec 2025 00:46:51 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 Message-ID: Test case ByteNNNVectorTests.MULReduceByteNNNVectorTestsMasked (specifically **_av.reduceLanes(VectorOperators.MUL, vmask)_**) fails "intermittently" with the newly added test data **mask[random]** on certain CPUs, likely those using AVX-512. For example, AMD_EPYC_9J14_96-Core is the one consistently fails. This new mask data was added to **_BOOLEAN_MASK_GENERATORS_** as part of the changes for JDK-8371446 https://github.com/openjdk/jdk/pull/28593 withToString("mask[random]", (int s) -> { return fill_boolean(s,_i -> RAND.nextBoolean()); }) Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. This change temporarily remove this data entry from BOOLEAN_MASK_GENERATORS to reduce the the test instability. This change also includes the regenerated test updates from gen-test.sh to sync the template and the generated test code, addressing the issue reported in JDK-8373390. ------------- Commit messages: - 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 Changes: https://git.openjdk.org/jdk/pull/28757/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28757&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373389 Stats: 224 lines in 31 files changed: 180 ins; 3 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/28757.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28757/head:pull/28757 PR: https://git.openjdk.org/jdk/pull/28757 From dlong at openjdk.org Thu Dec 11 02:11:25 2025 From: dlong at openjdk.org (Dean Long) Date: Thu, 11 Dec 2025 02:11:25 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 10:30:46 GMT, Quan Anh Mai wrote: > Hi, > > This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. > > I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. > > Please kindly review, thanks a lot. @merykitty , I tried solution 1) and it seems to work, but I think I prefer solution 2) because it aligns better with my idea from JDK-8372846 of canonicalized exception states. If you like, I can take over this bug. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28597#issuecomment-3639722831 From duke at openjdk.org Thu Dec 11 02:59:23 2025 From: duke at openjdk.org (Jason Mehrens) Date: Thu, 11 Dec 2025 02:59:23 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: Message-ID: <8GKD0B-nZxJ14FeYp451dWqlY5Lkxmj-qOZ1ELkqREU=.5d442970-b20b-4220-be79-77a33f9f3e46@github.com> On Tue, 9 Dec 2025 03:15:10 GMT, Joe Darcy wrote: > PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3639835059 From china.weigao at gmail.com Thu Dec 11 03:21:16 2025 From: china.weigao at gmail.com (weigao) Date: Thu, 11 Dec 2025 11:21:16 +0800 Subject: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow Message-ID: Hello, I would like to report a potential design issue in the JDK 25 implementation of MessageFormat. While working with java.util.Locale#getDisplayName(), I found that JDK internals throw and catch an IllegalArgumentException due to the following pattern added in the resource bundles: - sun.util.resources.cldr.LocaleNames - sun.util.resources.LocaleNames The pattern in question is: DisplayNamePattern: {0,choice,0#|1#{1}|2#{1} ({2})} This change originates from the following commit: adoptium/jdk at 00ffc42 ? which adds a pattern for MessageFormat. However, choice is *not* a valid type for FormatStyle. As a result, calling Locale#getDisplayName() triggers the following exception inside JDK code: java.lang.IllegalArgumentException at java.base/java.text.MessageFormat$FormatStyle.fromString(MessageFormat.java:2013) at java.base/java.text.MessageFormat.formatFromPattern(MessageFormat.java:1718) at java.base/java.text.MessageFormat.setFormatFromPattern(MessageFormat.java:1679) at java.base/java.text.MessageFormat.applyPatternImpl(MessageFormat.java:660) at java.base/java.text.MessageFormat.(MessageFormat.java:516) at java.base/java.util.Locale.getDisplayName(Locale.java:2309) The implementation currently relies on exception-based logic: try { fStyle = FormatStyle.fromString(style); } catch (IllegalArgumentException iae) { fStyle = FormatStyle.SUBFORMATPATTERN; } I understand that MessageFormat catches this exception and falls back to SUBFORMATPATTERN, but using exceptions to control expected logic paths may not be ideal?especially since FormatStyle.fromString() is only used by MessageFormat. A potentially cleaner approach could be to have FormatStyle.fromString() return FormatStyle.SUBFORMATPATTERN directly when encountering unknown style identifiers, instead of throwing an exception. *JDK Version Observed:* OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS) Please let me know if this behavior is intentional, or if it should be considered for improvement. Best regards, vincent gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From china.weigao at gmail.com Thu Dec 11 03:31:11 2025 From: china.weigao at gmail.com (weigao) Date: Thu, 11 Dec 2025 11:31:11 +0800 Subject: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow In-Reply-To: References: Message-ID: hi , because of ``private static FormatStyle fromString(String text)` throw exception and the try catch exception just set the deault value ` FormatStyle.SUBFORMATPATTERN` , so why just make this function retuen this value like ? Is it better , right ? ``` private static FormatStyle fromString(String text) { for (FormatStyle style : values()) { // Also check trimmed case-insensitive for historical reasons if (style != FormatStyle.SUBFORMATPATTERN && text.trim().compareToIgnoreCase(style.text) == 0) { return style; } } return FormatStyle.SUBFORMATPATTERN; } ``` weigao ?2025?12?11??? 11:21??? > Hello, > > I would like to report a potential design issue in the JDK 25 > implementation of MessageFormat. > > While working with java.util.Locale#getDisplayName(), I found that JDK > internals throw and catch an IllegalArgumentException due to the > following pattern added in the resource bundles: > > - > > sun.util.resources.cldr.LocaleNames > - > > sun.util.resources.LocaleNames > > The pattern in question is: > > DisplayNamePattern: {0,choice,0#|1#{1}|2#{1} ({2})} > > This change originates from the following commit: > adoptium/jdk at 00ffc42 ? which adds a pattern for MessageFormat. > However, choice is *not* a valid type for FormatStyle. > > As a result, calling Locale#getDisplayName() triggers the following > exception inside JDK code: > > java.lang.IllegalArgumentException > at java.base/java.text.MessageFormat$FormatStyle.fromString(MessageFormat.java:2013) > at java.base/java.text.MessageFormat.formatFromPattern(MessageFormat.java:1718) > at java.base/java.text.MessageFormat.setFormatFromPattern(MessageFormat.java:1679) > at java.base/java.text.MessageFormat.applyPatternImpl(MessageFormat.java:660) > at java.base/java.text.MessageFormat.(MessageFormat.java:516) > at java.base/java.util.Locale.getDisplayName(Locale.java:2309) > > The implementation currently relies on exception-based logic: > > try { > fStyle = FormatStyle.fromString(style); > } catch (IllegalArgumentException iae) { > fStyle = FormatStyle.SUBFORMATPATTERN; > } > > I understand that MessageFormat catches this exception and falls back to > SUBFORMATPATTERN, but using exceptions to control expected logic paths > may not be ideal?especially since FormatStyle.fromString() is only used > by MessageFormat. > > A potentially cleaner approach could be to have FormatStyle.fromString() > return FormatStyle.SUBFORMATPATTERN directly when encountering unknown > style identifiers, instead of throwing an exception. > > *JDK Version Observed:* > > OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS) > > Please let me know if this behavior is intentional, or if it should be > considered for improvement. > > Best regards, > vincent gao > -------------- next part -------------- An HTML attachment was scrubbed... URL: From qamai at openjdk.org Thu Dec 11 03:33:25 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 11 Dec 2025 03:33:25 GMT Subject: RFR: 8350208: CTW: GraphKit::add_safepoint_edges asserts "not enough operands for reexecution" In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 02:09:08 GMT, Dean Long wrote: >> Hi, >> >> This PR fixes the issue of the compiler crashing with "not enough operands for reexecution". The issue here is that during `Parse::catch_inline_exceptions`, the old stack is gone, and we cannot reexecute the current bytecode anymore. However, there are some places where we try to insert safepoints into the graph, such as if the handler is a backward jump, or if one of the exceptions in the handlers is not loaded. Since the `_reexecute` state of the current jvms is "undefined", it is inferred automatically that it should reexecute for some bytecodes such as `putfield`. The solution then is to explicitly set `_reexecute` to false. >> >> I can manage to write a unit test for the case of a backward handler, for the other cases, since the exceptions that can be thrown for a bytecode that is inferred to reexecute are `NullPointerException`, `ArrayIndexOutOfBoundsException`, and `ArrayStoreException`. I find it hard to construct such a test in which one of them is not loaded. >> >> Please kindly review, thanks a lot. > > @merykitty , I tried solution 1) and it seems to work, but I think I prefer solution 2) because it aligns better with my idea from JDK-8372846 of canonicalized exception states. If you like, I can take over this bug. @dean-long Thanks a lot, please take over this bug then. > trim stack, throw exception (move to Thread) (reexecute=true) This requires extra unconditional overhead even though safepoint rarely happens. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28597#issuecomment-3639912845 From duke at openjdk.org Thu Dec 11 04:48:21 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Thu, 11 Dec 2025 04:48:21 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: <8GKD0B-nZxJ14FeYp451dWqlY5Lkxmj-qOZ1ELkqREU=.5d442970-b20b-4220-be79-77a33f9f3e46@github.com> References: <8GKD0B-nZxJ14FeYp451dWqlY5Lkxmj-qOZ1ELkqREU=.5d442970-b20b-4220-be79-77a33f9f3e46@github.com> Message-ID: On Thu, 11 Dec 2025 02:56:13 GMT, Jason Mehrens wrote: > > PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? > > In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. I actually already cut a [ticket](https://bugs.openjdk.org/browse/JDK-8373288) for this, and was planning to open a PR. I hadn't thought of Collections.newSetFromMap but I think the spliterator characteristics should be fixed regardless. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3640093123 From darcy at openjdk.org Thu Dec 11 04:56:33 2025 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 11 Dec 2025 04:56:33 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: <8GKD0B-nZxJ14FeYp451dWqlY5Lkxmj-qOZ1ELkqREU=.5d442970-b20b-4220-be79-77a33f9f3e46@github.com> Message-ID: On Thu, 11 Dec 2025 04:45:37 GMT, Patrick Strawderman wrote: > > > PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? > > > > > > In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. > > I actually already cut a [ticket](https://bugs.openjdk.org/browse/JDK-8373288) for this, and was planning to open a PR. I hadn't thought of Collections.newSetFromMap but I think the spliterator characteristics should be fixed regardless. Thanks; yes, I added a link between the two bugs in JBS. I think it is fine to either two separate PRs for the two issues or to combine them into one as long as both changes get into the same release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3640113506 From jbhateja at openjdk.org Thu Dec 11 06:12:29 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 11 Dec 2025 06:12:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v7] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:23:30 GMT, Jatin Bhateja wrote: >> Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. >> - Add necessary inline expander support. >> - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. >> - Use existing Float16 vector IR and backend support. >> - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. >> >> The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). >> >> The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. >> >> image >> >> Initial RFP[1] was floated on the panama-dev mailing list. >> >> Kindly review the draft PR and share your feedback. >> >> Best Regards, >> Jatin >> >> [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html > > Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Optimizing tail handling > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Fix failing jtreg test in CI > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Cleanups > - Adding support for custom basic type T_FLOAT16, passing BasicType lane types to inline expander entries > - Cleaning up interface as per review suggestions > - Some cleanups > - ... and 10 more: https://git.openjdk.org/jdk/compare/b60ac710...44ac727d > jdk/incubator/vector/Float16Vector512Tests.java > This patch results in two of the JTREG tests failing on aarch64 machines- > > ``` > jdk/incubator/vector/Float16Vector512Tests.java > compiler/vectorapi/TestFloat16VectorOperations.java > ``` > > which is due to an issue in the `aarch64.ad` file. Fixed the failures and also added aarch64 specific IR rules which were missing for some of the tests in the `compiler/vectorapi/TestFloat16VectorOperations.java` test. > > @jatin-bhateja Could you please add the attached fix to this patch? Thanks! [fix.patch](https://github.com/user-attachments/files/24076067/fix.patch) Hi @Bhavana-Kilambi , Thanks for running this thorugh your setup, I am also able to reproduce it on Google AXION, your fix fills the gap in instruction selector, I suggest creating a seperate PR for this ? You can either create a smaller standalone reproducer testcase or mention about the tests part of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3640370652 From shade at openjdk.org Thu Dec 11 06:48:23 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Thu, 11 Dec 2025 06:48:23 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 23:59:00 GMT, Xueming Shen wrote: > Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. Does that mean we should problem-list the tests, instead of changing them? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28757#issuecomment-3640484173 From xgong at openjdk.org Thu Dec 11 06:51:26 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 11 Dec 2025 06:51:26 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 03:29:03 GMT, Eric Fang wrote: > This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance. > > Changes: > -------- > > 1. C2 mid-end: > - Added UMinReductionVNode and UMaxReductionVNode > > 2. AArch64 Backend: > - Added uminp/umaxp/sve_uminv/sve_umaxv instructions > - Updated match rules for all vector sizes and element types > - Both NEON and SVE implementation are supported > > 3. Test: > - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java > - Added assembly tests in aarch64-asmtest.py for new instructions > - Added a JTReg test file VectorUMinMaxReductionTest.java > > Different configurations were tested on aarch64 and x86 machines, and all tests passed. > > Test results of JMH benchmarks from the panama-vector project: > -------- > > On a Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Error After Error Uplift > Byte128Vector.UMAXLanes ops/ms 411.60 42.18 25226.51 33.92 61.29 > Byte128Vector.UMAXMaskedLanes ops/ms 558.56 85.12 25182.90 28.74 45.09 > Byte128Vector.UMINLanes ops/ms 645.58 780.76 28396.29 103.11 43.99 > Byte128Vector.UMINMaskedLanes ops/ms 621.09 718.27 26122.62 42.68 42.06 > Byte64Vector.UMAXLanes ops/ms 296.33 34.44 14357.74 15.95 48.45 > Byte64Vector.UMAXMaskedLanes ops/ms 376.54 44.01 14269.24 21.41 37.90 > Byte64Vector.UMINLanes ops/ms 373.45 426.51 15425.36 66.20 41.31 > Byte64Vector.UMINMaskedLanes ops/ms 353.32 346.87 14201.37 13.79 40.19 > Int128Vector.UMAXLanes ops/ms 174.79 192.51 9906.07 286.93 56.67 > Int128Vector.UMAXMaskedLanes ops/ms 157.23 206.68 10246.77 11.44 65.17 > Int64Vector.UMAXLanes ops/ms 95.30 126.49 4719.30 98.57 49.52 > Int64Vector.UMAXMaskedLanes ops/ms 88.19 87.44 4693.18 19.76 53.22 > Long128Vector.UMAXLanes ops/ms 80.62 97.82 5064.01 35.52 62.82 > Long128Vector.UMAXMaskedLanes ops/ms 78.15 102.91 5028.24 8.74 64.34 > Long64Vector.UMAXLanes ops/ms 47.56 62.01 46.76 52.28 0.98 > Long64Vector.UMAXMaskedLanes ops/ms 45.44 46.76 45.79 42.91 1.01 > Short128Vector.UMAXLanes ops/ms 316.65 410.30 14814.82 23.65 46.79 > Short128Vector.UMAXMaskedLanes ops/ms 308.90 351.78 15155.26 31.03 49.06 > Sh... Nice work. Thanks for your support! I noticed that this PR contains the same commit of https://github.com/openjdk/jdk/pull/28692. Could you please split the change from this PR? If this PR depends on https://github.com/openjdk/jdk/pull/28692, I wonder whether we can change the target merge branch to `pr/28692` instead of `master` please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3640490083 From jbhateja at openjdk.org Thu Dec 11 07:32:58 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 11 Dec 2025 07:32:58 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v8] In-Reply-To: References: Message-ID: > Add a new Float16lVector type and corresponding concrete vector classes, in addition to existing primitive vector types, maintaining operation parity with the FloatVector type. > - Add necessary inline expander support. > - Enable intrinsification for a few vector operations, namely ADD/SUB/MUL/DIV/MAX/MIN/FMA. > - Use existing Float16 vector IR and backend support. > - Extended the existing VectorAPI JTREG test suite for the newly added Float16Vector operations. > > The idea here is to first be at par with Float16 auto-vectorization support before intrinsifying new operations (conversions, reduction, etc). > > The following are the performance numbers for some of the selected Float16Vector benchmarking kernels compared to equivalent auto-vectorized Float16OperationsBenchmark kernels. > > image > > Initial RFP[1] was floated on the panama-dev mailing list. > > Kindly review the draft PR and share your feedback. > > Best Regards, > Jatin > > [1] https://mail.openjdk.org/pipermail/panama-dev/2025-August/021100.html Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Including test changes from Bhavana Kilambi (ARM) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/44ac727d..7da5d147 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=06-07 Stats: 16 lines in 1 file changed: 10 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28002.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28002/head:pull/28002 PR: https://git.openjdk.org/jdk/pull/28002 From mbaesken at openjdk.org Thu Dec 11 08:20:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Dec 2025 08:20:44 GMT Subject: RFR: 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler In-Reply-To: References: Message-ID: <6e2Un67A2wUR1hnwKiD0FUeUfdi-f3ZJPaBkQEbOGxA=.05d24b1b-8e0d-41b6-84d9-228e2cecc4b7@github.com> On Wed, 10 Dec 2025 10:12:07 GMT, Matthias Baesken wrote: > test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp fails with VS2019 and some versions of VS2022 compilers as follows > > > ========================8<------------------------ > * For target support_test_jdk_jtreg_native_support_libSharedCloseAgent_libSharedCloseAgent.obj: > libSharedCloseAgent.cpp > z:\BuildAgent\work\23f345c5c4b56004\test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp(105): fatal error C1001: Internal compiler error. > (compiler file 'msc1.cpp', line 1603) Thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28739#issuecomment-3640755969 From mbaesken at openjdk.org Thu Dec 11 08:20:44 2025 From: mbaesken at openjdk.org (Matthias Baesken) Date: Thu, 11 Dec 2025 08:20:44 GMT Subject: Integrated: 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 10:12:07 GMT, Matthias Baesken wrote: > test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp fails with VS2019 and some versions of VS2022 compilers as follows > > > ========================8<------------------------ > * For target support_test_jdk_jtreg_native_support_libSharedCloseAgent_libSharedCloseAgent.obj: > libSharedCloseAgent.cpp > z:\BuildAgent\work\23f345c5c4b56004\test\jdk\java\foreign\sharedclosejvmti\libSharedCloseAgent.cpp(105): fatal error C1001: Internal compiler error. > (compiler file 'msc1.cpp', line 1603) This pull request has now been integrated. Changeset: b46aef88 Author: Matthias Baesken URL: https://git.openjdk.org/jdk/commit/b46aef88b333db8866c60c18cbf842b6cb89dacf Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8371871: libSharedCloseAgent.cpp crashes VS2019 and older VS2022 compiler Reviewed-by: jvernee, mdoerr ------------- PR: https://git.openjdk.org/jdk/pull/28739 From vklang at openjdk.org Thu Dec 11 10:12:34 2025 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 11 Dec 2025 10:12:34 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v2] In-Reply-To: References: <8GKD0B-nZxJ14FeYp451dWqlY5Lkxmj-qOZ1ELkqREU=.5d442970-b20b-4220-be79-77a33f9f3e46@github.com> Message-ID: On Thu, 11 Dec 2025 04:45:37 GMT, Patrick Strawderman wrote: >>> PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? >> >> In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. > >> > PS Is there anything analagous that should be added to any of the methods on EnumMap about the properties of the returned collections? >> >> In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. > > I actually already cut a [ticket](https://bugs.openjdk.org/browse/JDK-8373288) for this, and was planning to open a PR. I hadn't thought of Collections.newSetFromMap but I think the spliterator characteristics should be fixed regardless. @kilink @jddarcy @jmehrens >In addition to documentation, I would think the splitIterator() of EnumMap::keySet and or EnumMap::entrySet would need to be overridden too so characteristics of Collections.newSetFromMap match with this patch. I think it makes sense to tackle EnumMap separately from EnumSet, but targeting the same release. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28696#issuecomment-3641196428 From erfang at openjdk.org Thu Dec 11 11:11:31 2025 From: erfang at openjdk.org (Eric Fang) Date: Thu, 11 Dec 2025 11:11:31 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 03:29:03 GMT, Eric Fang wrote: > This patch adds intrinsic support for UMIN and UMAX reduction operations in the Vector API on AArch64, enabling direct hardware instruction mapping for better performance. > > Changes: > -------- > > 1. C2 mid-end: > - Added UMinReductionVNode and UMaxReductionVNode > > 2. AArch64 Backend: > - Added uminp/umaxp/sve_uminv/sve_umaxv instructions > - Updated match rules for all vector sizes and element types > - Both NEON and SVE implementation are supported > > 3. Test: > - Added UMIN_REDUCTION_V and UMAX_REDUCTION_V to IRNode.java > - Added assembly tests in aarch64-asmtest.py for new instructions > - Added a JTReg test file VectorUMinMaxReductionTest.java > > Different configurations were tested on aarch64 and x86 machines, and all tests passed. > > Test results of JMH benchmarks from the panama-vector project: > -------- > > On a Nvidia Grace machine with 128-bit SVE: > > Benchmark Unit Before Error After Error Uplift > Byte128Vector.UMAXLanes ops/ms 411.60 42.18 25226.51 33.92 61.29 > Byte128Vector.UMAXMaskedLanes ops/ms 558.56 85.12 25182.90 28.74 45.09 > Byte128Vector.UMINLanes ops/ms 645.58 780.76 28396.29 103.11 43.99 > Byte128Vector.UMINMaskedLanes ops/ms 621.09 718.27 26122.62 42.68 42.06 > Byte64Vector.UMAXLanes ops/ms 296.33 34.44 14357.74 15.95 48.45 > Byte64Vector.UMAXMaskedLanes ops/ms 376.54 44.01 14269.24 21.41 37.90 > Byte64Vector.UMINLanes ops/ms 373.45 426.51 15425.36 66.20 41.31 > Byte64Vector.UMINMaskedLanes ops/ms 353.32 346.87 14201.37 13.79 40.19 > Int128Vector.UMAXLanes ops/ms 174.79 192.51 9906.07 286.93 56.67 > Int128Vector.UMAXMaskedLanes ops/ms 157.23 206.68 10246.77 11.44 65.17 > Int64Vector.UMAXLanes ops/ms 95.30 126.49 4719.30 98.57 49.52 > Int64Vector.UMAXMaskedLanes ops/ms 88.19 87.44 4693.18 19.76 53.22 > Long128Vector.UMAXLanes ops/ms 80.62 97.82 5064.01 35.52 62.82 > Long128Vector.UMAXMaskedLanes ops/ms 78.15 102.91 5028.24 8.74 64.34 > Long64Vector.UMAXLanes ops/ms 47.56 62.01 46.76 52.28 0.98 > Long64Vector.UMAXMaskedLanes ops/ms 45.44 46.76 45.79 42.91 1.01 > Short128Vector.UMAXLanes ops/ms 316.65 410.30 14814.82 23.65 46.79 > Short128Vector.UMAXMaskedLanes ops/ms 308.90 351.78 15155.26 31.03 49.06 > Sh... > Nice work. Thanks for your support! > > I noticed that this PR contains the same commit of #28692. Could you please split the change from this PR? If this PR depends on #28692, I wonder whether we can change the target merge branch to `pr/28692` instead of `master` please? Yeah, I think I made a mistake when pushing the PR. I'll just convert this PR as draft since #28692 is under active review. Then rebase the PR after #28692 is merged. Thanks for the reminder~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3641410633 From erfang at openjdk.org Thu Dec 11 11:14:25 2025 From: erfang at openjdk.org (Eric Fang) Date: Thu, 11 Dec 2025 11:14:25 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v2] In-Reply-To: References: <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com> Message-ID: On Fri, 28 Nov 2025 09:21:18 GMT, Galder Zamarre?o wrote: >> Eric Fang 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: >> >> - Don't read and write the same memory in the JMH benchmarks >> - Merge branch 'master' into JDK-8370863-mask-cast-opt >> - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns >> >> `VectorMaskCastNode` is used to cast a vector mask from one type to >> another type. The cast may be generated by calling the vector API `cast` >> or generated by the compiler. For example, some vector mask operations >> like `trueCount` require the input mask to be integer types, so for >> floating point type masks, the compiler will cast the mask to the >> corresponding integer type mask automatically before doing the mask >> operation. This kind of cast is very common. >> >> If the vector element size is not changed, the `VectorMaskCastNode` >> don't generate code, otherwise code will be generated to extend or narrow >> the mask. This IR node is not free no matter it generates code or not >> because it may block some optimizations. For example: >> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` >> The middle `VectorMaskCast` prevented the following optimization: >> `(VectorStoremask (VectorLoadMask x)) => (x)` >> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which >> blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. >> >> In these IR patterns, the value of the input `x` is not changed, so we >> can safely do the optimization. But if the input value is changed, we >> can't eliminate the cast. >> >> The general idea of this PR is introducing an `uncast_mask` helper >> function, which can be used to uncast a chain of `VectorMaskCastNode`, >> like the existing `Node::uncast(bool)` function. The funtion returns >> the first non `VectorMaskCastNode`. >> >> The intended use case is when the IR pattern to be optimized may >> contain one or more consecutive `VectorMaskCastNode` and this does not >> affect the correctness of the optimization. Then this function can be >> called to eliminate the `VectorMaskCastNode` chain. >> >> Current optimizations related to `VectorMaskCastNode` include: >> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. >> 2. `(XorV (VectorMa... > > Nice improvement @erifan, just some small comments from me Hi @galderz would you mind taking another look of this PR, thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3641419459 From bkilambi at openjdk.org Thu Dec 11 12:09:30 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 11 Dec 2025 12:09:30 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <98jWF_NhAAB1WHHsotReB6SYIVSRIWNO0rmhxnNMJM8=.f21f3406-f3b3-4ce5-b009-6e50e2ebe1f1@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <98jWF_NhAAB1WHHsotReB6SYIVSRIWNO0rmhxnNMJM8=.f21f3406-f3b3-4ce5-b009-6e50e2ebe1f1@github.com> Message-ID: On Thu, 2 Oct 2025 13:21:32 GMT, Marc Chevalier wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > I see now the flags are not triviall: > > -XX:+UnlockDiagnosticVMOptions -XX:-TieredCompilation -XX:+StressArrayCopyMacroNode -XX:+StressLCM -XX:+StressGCM -XX:+StressIGVN -XX:+StressCCP -XX:+StressMacroExpansion -XX:+StressMethodHandleLinkerInlining -XX:+StressCompiledExceptionHandlers -XX:VerifyConstraintCasts=1 -XX:+StressLoopPeeling > > a lot of stress file. It's likely that many runs might be needed to reproduce. > > The machine is a VM.Standard.A1.Flex shape, as described in > https://docs.oracle.com/en-us/iaas/Content/Compute/References/computeshapes.htm > > Backtrace at the failure: > > Current CompileTask: > C2:1523 346 % b compiler.vectorization.TestFloat16VectorOperations::vectorAddReductionFloat16 @ 4 (39 bytes) > > Stack: [0x0000ffff84799000,0x0000ffff84997000], sp=0x0000ffff849920d0, free space=2020k > Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code) > V [libjvm.so+0x7da724] C2_MacroAssembler::neon_reduce_add_fp16(FloatRegister, FloatRegister, FloatRegister, unsigned int, FloatRegister)+0x2b4 (c2_MacroAssembler_aarch64.cpp:1930) > V [libjvm.so+0x154492c] PhaseOutput::scratch_emit_size(Node const*)+0x2ec (output.cpp:3171) > V [libjvm.so+0x153d4a4] PhaseOutput::shorten_branches(unsigned int*)+0x2e4 (output.cpp:528) > V [libjvm.so+0x154dcdc] PhaseOutput::Output()+0x95c (output.cpp:328) > V [libjvm.so+0x9be070] Compile::Code_Gen()+0x7f0 (compile.cpp:3127) > V [libjvm.so+0x9c21c0] Compile::Compile(ciEnv*, ciMethod*, int, Options, DirectiveSet*)+0x1774 (compile.cpp:894) > V [libjvm.so+0x7eec64] C2Compiler::compile_method(ciEnv*, ciMethod*, int, bool, DirectiveSet*)+0x2e0 (c2compiler.cpp:147) > V [libjvm.so+0x9d0f8c] CompileBroker::invoke_compiler_on_method(CompileTask*)+0xb08 (compileBroker.cpp:2345) > V [libjvm.so+0x9d1eb8] CompileBroker::compiler_thread_loop()+0x638 (compileBroker.cpp:1989) > V [libjvm.so+0xed25a8] JavaThread::thread_main_inner()+0x108 (javaThread.cpp:775) > V [libjvm.so+0x18466dc] Thread::call_run()+0xac (thread.cpp:243) > V [libjvm.so+0x152349c] thread_native_entry(Thread*)+0x12c (os_linux.cpp:895) > C [libc.so.6+0x80b50] start_thread+0x300 > > > I've attached the replay file in the JBS issue, if it can help. Hi @marc-chevalier Apologies for the delay in responding to your review comments. I have been looking at the JTREG test failures you have reported for my patch. It looks like it's not something that's caused by my patch itself. I can reproduce this error on the master branch for the other tests in `compiler/vectorization/TestFloat16VectorOperations.java` as well and it's reproducible on both AArch64 and x86_64 machines. With a quick look, it looks like for some of the failing tests, autovectorization does happen but IR rule still fails because it is expecting vector nodes of a specific shape. Adding `IRNode.VECTOR_SIZE_ANY` helped resolve those failures but still some other tests fail due to autovectorization not happening in them. I feel this needs to be looked at separately as these failures exist on master branch as well and not really caused by this patch. Would you suggest I create a separate ticket for this task? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641187476 From mchevalier at openjdk.org Thu Dec 11 12:09:33 2025 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 11 Dec 2025 12:09:33 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <_QEYCQm138PWv2vGjMFvEJ6kfMjGEn_vsuEZ_EPaRxQ=.b42967e5-cc22-4c98-a454-6698ce0a70cf@github.com> On Fri, 26 Sep 2025 12:00:31 GMT, Bhavana Kilambi wrote: > This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. > > Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - > > **For AddReduction :** > On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. > > On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. > > **For MulReduction :** > Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. > > Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - > > Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. > Ratio > 1 indicates the performance with this patch is better than the master branch. > > **N1 (UseSVE = 0, max vector length = 16B):** > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionAddFP16 256 thrpt 9 1.41 1.40 > ReductionAddFP16 512 thrpt 9 1.41 1.41 > ReductionAddFP16 1024 thrpt 9 1.43 1.40 > ReductionAddFP16 2048 thrpt 9 1.43 1.40 > ReductionMulFP16 256 thrpt 9 1.22 1.22 > ReductionMulFP16 512 thrpt 9 1.21 1.23 > ReductionMulFP16 1024 thrpt 9 1.21 1.22 > ReductionMulFP16 2048 thrpt 9 1.20 1.22 > > > On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ... I'm a bit confused. The failure I observed is an assert failing during code generation. This is a compiler crash, not an IR rule failure, and I don't think it can be solved by changing the content of `IRNode.java`. Am I misunderstanding something? Of course, we can have multiple problems, but it seems not to be what I reported. It was a while ago, but I think I checked that this failure didn't appear in our history back then. So, either it was new, or it is intermittent and I was just unlucky (always possible). As for the IR verification failure, I've looked a bit and couldn't find such an issue already. Since it reproduces on master, I suggest you file a ticket, indeed. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641228424 PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641614453 From bkilambi at openjdk.org Thu Dec 11 12:24:00 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 11 Dec 2025 12:24:00 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Fri, 26 Sep 2025 12:00:31 GMT, Bhavana Kilambi wrote: > This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. > > Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - > > **For AddReduction :** > On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. > > On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. > > **For MulReduction :** > Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. > > Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - > > Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. > Ratio > 1 indicates the performance with this patch is better than the master branch. > > **N1 (UseSVE = 0, max vector length = 16B):** > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionAddFP16 256 thrpt 9 1.41 1.40 > ReductionAddFP16 512 thrpt 9 1.41 1.41 > ReductionAddFP16 1024 thrpt 9 1.43 1.40 > ReductionAddFP16 2048 thrpt 9 1.43 1.40 > ReductionMulFP16 256 thrpt 9 1.22 1.22 > ReductionMulFP16 512 thrpt 9 1.21 1.23 > ReductionMulFP16 1024 thrpt 9 1.21 1.22 > ReductionMulFP16 2048 thrpt 9 1.20 1.22 > > > On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ... Apologies, I missed to address the assertion failure you pointed out in my previous comment. It seems to exist because gdb showed that the combined stress flags somehow set the vector length to 4B which is not allowed. The assertion failure itself can be fixed by adding `length < 8` to this condition in aarch64_vector.ad file - ` if (length < 8 || length_in_bytes > 16 || !is_feat_fp16_supported()) { return false; } ` which would avoid vectorization for 4B vector length. But after this change, the IR rules for reduction fail because now the vector reduction nodes are not generated but the IR rule is expecting them. I'll look into this but I actually noticed that this test fail even on master branch with the following IR failures - One or more @IR rules failed: Failed IR Rules (11) of Methods (11) ------------------------------------ 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddConstInputFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#ADD_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 2) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#ADD_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 3) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorDivFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#DIV_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(DivVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 4) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorFmaFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#FMA_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(FmaVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 5) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorFmaFloat16MixedConstants()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#FMA_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(FmaVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 6) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorFmaFloat16ScalarMixedConstants()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#FMA_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(FmaVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 7) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorMaxFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#MAX_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(MaxVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 8) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorMinFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#MIN_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(MinVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 9) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorMulFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#MUL_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(MulVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 10) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorSqrtFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#SQRT_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(SqrtVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! 11) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorSubFloat16()" - [Failed IR rules: 1]: * @IR rule 2: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={}, counts={"_#V#SUB_VHF#_", " >0 "}, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={"fphp", "true", "asimdhp", "true"}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})" > Phase "PrintIdeal": - counts: Graph contains wrong number of nodes: * Constraint 1: "(\d+(\s){2}(SubVHF.*)+(\s){2}===.*vector[A-Za-z])" - Failed comparison: [found] 0 > 0 [given] - No nodes matched! Mostly looks like the expected shape (the default is the `VECTOR_SIZE_MAX`) is not found in the IR graph (as the stress flags might have resulted in a change in vector length) and these failures seem to exist on both aarch64 and x86_64. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641660105 From duke at openjdk.org Thu Dec 11 12:26:26 2025 From: duke at openjdk.org (duke) Date: Thu, 11 Dec 2025 12:26:26 GMT Subject: Withdrawn: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 18:02:59 GMT, Raffaello Giulietti wrote: > Doc only change. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27830 From epeter at openjdk.org Thu Dec 11 12:34:33 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 11 Dec 2025 12:34:33 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Fri, 26 Sep 2025 12:00:31 GMT, Bhavana Kilambi wrote: > This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. > > Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - > > **For AddReduction :** > On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. > > On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. > > **For MulReduction :** > Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. > > Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - > > Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. > Ratio > 1 indicates the performance with this patch is better than the master branch. > > **N1 (UseSVE = 0, max vector length = 16B):** > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionAddFP16 256 thrpt 9 1.41 1.40 > ReductionAddFP16 512 thrpt 9 1.41 1.41 > ReductionAddFP16 1024 thrpt 9 1.43 1.40 > ReductionAddFP16 2048 thrpt 9 1.43 1.40 > ReductionMulFP16 256 thrpt 9 1.22 1.22 > ReductionMulFP16 512 thrpt 9 1.21 1.23 > ReductionMulFP16 1024 thrpt 9 1.21 1.22 > ReductionMulFP16 2048 thrpt 9 1.20 1.22 > > > On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ... And it may be worth to fix this test before adding more changes to Float16, just to be sure we have a correct base to build on and are not making thins worse ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641706953 From bkilambi at openjdk.org Thu Dec 11 13:11:27 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 11 Dec 2025 13:11:27 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Thu, 11 Dec 2025 12:31:54 GMT, Emanuel Peter wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > And it may be worth to fix this test before adding more changes to Float16, just to be sure we have a correct base to build on and are not making thins worse ;) @eme64 I agree. Would you suggest I open a separate ticket to fix this test with the stress flags? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3641848670 From epeter at openjdk.org Thu Dec 11 14:04:16 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 11 Dec 2025 14:04:16 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Fri, 26 Sep 2025 12:00:31 GMT, Bhavana Kilambi wrote: > This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. > > Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - > > **For AddReduction :** > On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. > > On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. > > **For MulReduction :** > Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. > > Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - > > Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. > Ratio > 1 indicates the performance with this patch is better than the master branch. > > **N1 (UseSVE = 0, max vector length = 16B):** > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionAddFP16 256 thrpt 9 1.41 1.40 > ReductionAddFP16 512 thrpt 9 1.41 1.41 > ReductionAddFP16 1024 thrpt 9 1.43 1.40 > ReductionAddFP16 2048 thrpt 9 1.43 1.40 > ReductionMulFP16 256 thrpt 9 1.22 1.22 > ReductionMulFP16 512 thrpt 9 1.21 1.23 > ReductionMulFP16 1024 thrpt 9 1.21 1.22 > ReductionMulFP16 2048 thrpt 9 1.20 1.22 > > > On N1, the scalarized sequence of `fadd/fmul` are generated for both `MaxVectorSize` of 8B and 16B for add reduction ... Yes, if it is indeed a bug that can be reproduced we should fix it separately. We just had the fork from JDK26 to JDK27, and so the bug fix probably needs to be backported. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3642076002 From jpai at openjdk.org Thu Dec 11 15:34:55 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 11 Dec 2025 15:34:55 GMT Subject: RFR: 8373517: Revert the macos Tahoe specific change done in JDK-8359830 Message-ID: Can I please get a review of this change which reverts the macos Tahoe specific change we had done in https://bugs.openjdk.org/browse/JDK-8359830? As noted in https://bugs.openjdk.org/browse/JDK-8373517, Apple addressed the underlying issue in a 26.0 Beta release and we no longer require this change in the JDK. The revert in this PR was done with a `git revert` of 8df6b2c4a355751cd8ca37cc5932be66bccaa123. That original commit had updated a jtreg test to verify the `os.version` system property reported by the JDK on macos. The commit in this PR retains that test because it's useful even without the source changes done in that older commit. tier1, tier2 and tier3 testing of this change completed without any related issues. I've verified that macos 26.x was one of the hosts that was picked up in those test runs. ------------- Commit messages: - copyright year - keep the additional testing in OsVersionTest - Revert "8359830: Incorrect os.version reported on macOS Tahoe 26 (Beta)" Changes: https://git.openjdk.org/jdk/pull/28768/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28768&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373517 Stats: 34 lines in 1 file changed: 0 ins; 18 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/28768.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28768/head:pull/28768 PR: https://git.openjdk.org/jdk/pull/28768 From psandoz at openjdk.org Thu Dec 11 16:46:52 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 11 Dec 2025 16:46:52 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 23:59:00 GMT, Xueming Shen wrote: > Test case ByteNNNVectorTests.MULReduceByteNNNVectorTestsMasked (specifically **_av.reduceLanes(VectorOperators.MUL, vmask)_**) fails "intermittently" with the newly added test data **mask[random]** on certain CPUs, likely those using AVX-512. For example, AMD_EPYC_9J14_96-Core is the one consistently fails. > > This new mask data was added to **_BOOLEAN_MASK_GENERATORS_** as part of the changes for JDK-8371446 https://github.com/openjdk/jdk/pull/28593 > > > withToString("mask[random]", (int s) -> { > return fill_boolean(s,_i -> RAND.nextBoolean()); > }) > > > Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. > > This change temporarily remove this data entry from BOOLEAN_MASK_GENERATORS to reduce the the test instability. > > This change also includes the regenerated test updates from gen-test.sh to sync the template and the generated test code, addressing the issue reported in JDK-8373390. I don't see any update to the template file(s), did you forget to include that in the commit? ------------- PR Review: https://git.openjdk.org/jdk/pull/28757#pullrequestreview-3568360174 From psandoz at openjdk.org Thu Dec 11 16:46:53 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 11 Dec 2025 16:46:53 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 06:46:11 GMT, Aleksey Shipilev wrote: > > Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. > > Does that mean we should problem-list the tests, instead of changing them? Its a trade off, we really want to problem list the problematic data and only on certain platforms, but we can't and so problem listing the test is broader than we would actually like. Further, resolving why the tests are failing for that data on the specific AVX512 platforms may take some time. So in this case i think it best to revert closer to the prior data we used, while retaining the updated test computation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28757#issuecomment-3642796124 From chen.l.liang at oracle.com Thu Dec 11 16:52:51 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 11 Dec 2025 16:52:51 +0000 Subject: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow In-Reply-To: References: Message-ID: Hello Vincent Gao, I saw your Java Bugs submission. Unfortunately your stacktrace caused some confusion to our triage because it is an internal exception and that trace is never printed anywhere. Your suggestion is a reasonable enhancement, that we should not use ad-hoc exceptions for control flow, given they need to fill stack traces, which is extremely costly. Since this is a cleanup, we might commit this to mainline JDK first. If this proves to be a performance bottleneck on 25 updates, we can backport. Since you are writing here, I assume this has a non-negligible impact on performance. If you can share a flame graph showing the regression from this exception, or a benchmark difference between 21 and 25.0.1, this would be extremely helpful. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of weigao Sent: Wednesday, December 10, 2025 9:31 PM To: core-libs-dev at openjdk.org Subject: Re: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow hi , because of ``private static FormatStyle fromString(String text)` throw exception and the try catch exception just set the deault value `FormatStyle.SUBFORMATPATTERN` , so why just make this function retuen this value like ? Is it better , right ? ``` private static FormatStyle fromString(String text) { for (FormatStyle style : values()) { // Also check trimmed case-insensitive for historical reasons if (style != FormatStyle.SUBFORMATPATTERN && text.trim().compareToIgnoreCase(style.text) == 0) { return style; } } return FormatStyle.SUBFORMATPATTERN; } ``` weigao > ?2025?12?11??? 11:21??? Hello, I would like to report a potential design issue in the JDK 25 implementation of MessageFormat. While working with java.util.Locale#getDisplayName(), I found that JDK internals throw and catch an IllegalArgumentException due to the following pattern added in the resource bundles: * sun.util.resources.cldr.LocaleNames * sun.util.resources.LocaleNames The pattern in question is: DisplayNamePattern: {0,choice,0#|1#{1}|2#{1} ({2})} This change originates from the following commit: adoptium/jdk at 00ffc42 ? which adds a pattern for MessageFormat. However, choice is not a valid type for FormatStyle. As a result, calling Locale#getDisplayName() triggers the following exception inside JDK code: java.lang.IllegalArgumentException at java.base/java.text.MessageFormat$FormatStyle.fromString(MessageFormat.java:2013) at java.base/java.text.MessageFormat.formatFromPattern(MessageFormat.java:1718) at java.base/java.text.MessageFormat.setFormatFromPattern(MessageFormat.java:1679) at java.base/java.text.MessageFormat.applyPatternImpl(MessageFormat.java:660) at java.base/java.text.MessageFormat.(MessageFormat.java:516) at java.base/java.util.Locale.getDisplayName(Locale.java:2309) The implementation currently relies on exception-based logic: try { fStyle = FormatStyle.fromString(style); } catch (IllegalArgumentException iae) { fStyle = FormatStyle.SUBFORMATPATTERN; } I understand that MessageFormat catches this exception and falls back to SUBFORMATPATTERN, but using exceptions to control expected logic paths may not be ideal?especially since FormatStyle.fromString() is only used by MessageFormat. A potentially cleaner approach could be to have FormatStyle.fromString() return FormatStyle.SUBFORMATPATTERN directly when encountering unknown style identifiers, instead of throwing an exception. JDK Version Observed: OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS) Please let me know if this behavior is intentional, or if it should be considered for improvement. Best regards, vincent gao -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Thu Dec 11 17:41:22 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 11 Dec 2025 17:41:22 GMT Subject: RFR: 8373517: Revert the macos Tahoe specific change done in JDK-8359830 In-Reply-To: References: Message-ID: <1BE8kS0MsgqdduNg10k2Sk3PZmyHp_1qMvtRMlxFxks=.698b3607-7544-4b44-837e-9005b0828715@github.com> On Thu, 11 Dec 2025 15:25:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which reverts the macos Tahoe specific change we had done in https://bugs.openjdk.org/browse/JDK-8359830? As noted in https://bugs.openjdk.org/browse/JDK-8373517, Apple addressed the underlying issue in a 26.0 Beta release and we no longer require this change in the JDK. > > The revert in this PR was done with a `git revert` of 8df6b2c4a355751cd8ca37cc5932be66bccaa123. That original commit had updated a jtreg test to verify the `os.version` system property reported by the JDK on macos. The commit in this PR retains that test because it's useful even without the source changes done in that older commit. > > tier1, tier2 and tier3 testing of this change completed without any related issues. I've verified that macos 26.x was one of the hosts that was picked up in those test runs. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28768#pullrequestreview-3568567132 From psandoz at openjdk.org Thu Dec 11 17:44:52 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 11 Dec 2025 17:44:52 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 23:59:00 GMT, Xueming Shen wrote: > Test case ByteNNNVectorTests.MULReduceByteNNNVectorTestsMasked (specifically **_av.reduceLanes(VectorOperators.MUL, vmask)_**) fails "intermittently" with the newly added test data **mask[random]** on certain CPUs, likely those using AVX-512. For example, AMD_EPYC_9J14_96-Core is the one consistently fails. > > This new mask data was added to **_BOOLEAN_MASK_GENERATORS_** as part of the changes for JDK-8371446 https://github.com/openjdk/jdk/pull/28593 > > > withToString("mask[random]", (int s) -> { > return fill_boolean(s,_i -> RAND.nextBoolean()); > }) > > > Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. > > This change temporarily remove this data entry from BOOLEAN_MASK_GENERATORS to reduce the the test instability. > > This change also includes the regenerated test updates from gen-test.sh to sync the template and the generated test code, addressing the issue reported in JDK-8373390. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28757#pullrequestreview-3568588420 From psandoz at openjdk.org Thu Dec 11 17:44:54 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 11 Dec 2025 17:44:54 GMT Subject: RFR: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 16:43:42 GMT, Paul Sandoz wrote: > I don't see any update to the template file(s), did you forget to include that in the commit? Answering myself, ah, i see now if i read the details section properly :-) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28757#issuecomment-3643060682 From bpb at openjdk.org Thu Dec 11 17:56:24 2025 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 11 Dec 2025 17:56:24 GMT Subject: RFR: 8373517: Revert the macos Tahoe specific change done in JDK-8359830 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:25:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which reverts the macos Tahoe specific change we had done in https://bugs.openjdk.org/browse/JDK-8359830? As noted in https://bugs.openjdk.org/browse/JDK-8373517, Apple addressed the underlying issue in a 26.0 Beta release and we no longer require this change in the JDK. > > The revert in this PR was done with a `git revert` of 8df6b2c4a355751cd8ca37cc5932be66bccaa123. That original commit had updated a jtreg test to verify the `os.version` system property reported by the JDK on macos. The commit in this PR retains that test because it's useful even without the source changes done in that older commit. > > tier1, tier2 and tier3 testing of this change completed without any related issues. I've verified that macos 26.x was one of the hosts that was picked up in those test runs. Looks fine. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28768#pullrequestreview-3568639147 From naoto at openjdk.org Thu Dec 11 19:18:27 2025 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 11 Dec 2025 19:18:27 GMT Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced [v2] In-Reply-To: References: Message-ID: On Wed, 15 Oct 2025 18:20:36 GMT, Raffaello Giulietti wrote: >> Doc only change. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Add the 'c' conversion as well. Could the sentence be more assertive than "might"? Probably "IllegalFormatConversionException is thrown if the TemporalAccesor do not have time zone" or something along the lines? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27830#issuecomment-3643409843 From sherman at openjdk.org Thu Dec 11 20:51:00 2025 From: sherman at openjdk.org (Xueming Shen) Date: Thu, 11 Dec 2025 20:51:00 GMT Subject: Integrated: 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 23:59:00 GMT, Xueming Shen wrote: > Test case ByteNNNVectorTests.MULReduceByteNNNVectorTestsMasked (specifically **_av.reduceLanes(VectorOperators.MUL, vmask)_**) fails "intermittently" with the newly added test data **mask[random]** on certain CPUs, likely those using AVX-512. For example, AMD_EPYC_9J14_96-Core is the one consistently fails. > > This new mask data was added to **_BOOLEAN_MASK_GENERATORS_** as part of the changes for JDK-8371446 https://github.com/openjdk/jdk/pull/28593 > > > withToString("mask[random]", (int s) -> { > return fill_boolean(s,_i -> RAND.nextBoolean()); > }) > > > Although this addition does reveals a potential bug in C2's av.reduceLanes(VectorOperators.MUL, vmask) implementation, it unfortunately introduces nosy, non-deterministic tier3 test failures in the vector API test suite. > > This change temporarily remove this data entry from BOOLEAN_MASK_GENERATORS to reduce the the test instability. > > This change also includes the regenerated test updates from gen-test.sh to sync the template and the generated test code, addressing the issue reported in JDK-8373390. This pull request has now been integrated. Changeset: ae85d899 Author: Xueming Shen URL: https://git.openjdk.org/jdk/commit/ae85d899d074c531371dece30319ace701517528 Stats: 224 lines in 31 files changed: 180 ins; 3 del; 41 mod 8373389: Two jdk/incubator/vector/ tests fails after JDK-8371446 Reviewed-by: psandoz ------------- PR: https://git.openjdk.org/jdk/pull/28757 From abimpoudis at openjdk.org Thu Dec 11 21:57:24 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Thu, 11 Dec 2025 21:57:24 GMT Subject: RFR: 8373552: ExactConversionsSupport: bad JLS links in javadoc Message-ID: Add relative links to the spec URL of primitive-types-in-patterns-instanceof-switch-jls.html ------------- Commit messages: - 8373552: ExactConversionsSupport: bad JLS links in javadoc Changes: https://git.openjdk.org/jdk/pull/28775/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28775&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373552 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28775.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28775/head:pull/28775 PR: https://git.openjdk.org/jdk/pull/28775 From china.weigao at gmail.com Fri Dec 12 02:12:21 2025 From: china.weigao at gmail.com (weigao) Date: Fri, 12 Dec 2025 10:12:21 +0800 Subject: [External] Feedback JDK-8318761 : Potential Issue in JDK 25 MessageFormat: Use of Internal Exception for Control Flow In-Reply-To: References: Message-ID: Hi , Chen Liang Thanks for the clarification. I agree this IllegalArgumentException is an internal exception used for control flow; it?s not printed externally by default. However, if it is thrown/caught frequently on a hot path, it can still incur a noticeable overhead (e.g., fillInStackTrace). We were able to notice this because our team monitors common JDK internal exceptions in our production workloads to validate whether changes in each release match our expectations. So even though this exception is not normally surfaced, we still observed the behavior. Below I?m adding a more concrete reproduction and benchmark data, for your evaluation of whether this is worth addressing/backporting in 25u. ## Reproducible benchmark (JMH) and results (JDK 21 vs JDK 25) I wrote a minimal JMH benchmark to simulate the cost of this pattern: ``` private static final String CHOICE_PATTERN = "{0,choice,0#|1#{1}|2#{1} ({2})}"; @Param({"0", "1", "2"}) public int choiceValue; private Object[] args; @Setup(Level.Iteration) public void setup() { args = new Object[]{choiceValue, "us_en", "UTF-8"}; } @Benchmark public void messageFormat_choice_static(Blackhole bh) { String result = MessageFormat.format(CHOICE_PATTERN, args); bh.consume(result); } ``` Pattern: {0,choice,0#|1#{1}|2#{1} ({2})} Method: call MessageFormat.format(pattern, args) (creates a new MessageFormat instance and parses the pattern each time) to amplify parsing/branch costs; 1 thread; warmup 3x10s; measurement 5x10s; fork 1. Key results (Throughput, ops/ms): JDK 21.0.5: ~2379 to ~3204 ops/ms (depending on choiceValue = 0/1/2) JDK 25: ~866 to ~1029 ops/ms ``` # JMH version: 1.37 # VM version: JDK 21.0.5, OpenJDK 64-Bit Server VM, 21.0.5+11-LTS # Warmup: 3 iterations, 10 s each # Measurement: 5 iterations, 10 s each # Timeout: 10 min per iteration # Threads: 1 thread, will synchronize iterations # Benchmark mode: Throughput, ops/time Benchmark (choiceValue) Mode Cnt Score Error Units MessageFormatBench.messageFormat_choice_static 0 thrpt 5 3204.770 ? 343.887 ops/ms MessageFormatBench.messageFormat_choice_static 1 thrpt 5 2513.444 ? 380.943 ops/ms MessageFormatBench.messageFormat_choice_static 2 thrpt 5 2379.665 ? 152.148 ops/ms ``` ``` # JMH version: 1.37 # VM version: JDK 25, OpenJDK 64-Bit Server VM, 25+36-3489 # Warmup: 3 iterations, 10 s each # Measurement: 5 iterations, 10 s each # Timeout: 10 min per iteration # Threads: 1 thread, will synchronize iterations # Benchmark mode: Throughput, ops/time Benchmark (choiceValue) Mode Cnt Score Error Units MessageFormatBench.messageFormat_choice_static 0 thrpt 5 1029.018 ? 16.425 ops/ms MessageFormatBench.messageFormat_choice_static 1 thrpt 5 932.762 ? 12.648 ops/ms MessageFormatBench.messageFormat_choice_static 2 thrpt 5 866.487 ? 49.584 ops/ms ``` This is roughly a 2.5x?3.1x throughput regression on JDK 25 compared to JDK 21. Note: the benchmark configuration is consistent between the two runs. Best regards, Vincent Gao Chen Liang ?2025?12?12??? 00:52??? > Hello Vincent Gao, > I saw your Java Bugs submission. Unfortunately your stacktrace caused some > confusion to our triage because it is an internal exception and that trace > is never printed anywhere. > Your suggestion is a reasonable enhancement, that we should not use ad-hoc > exceptions for control flow, given they need to fill stack traces, which is > extremely costly. > Since this is a cleanup, we might commit this to mainline JDK first. If > this proves to be a performance bottleneck on 25 updates, we can backport. > Since you are writing here, I assume this has a non-negligible impact on > performance. > If you can share a flame graph showing the regression from this exception, > or a benchmark difference between 21 and 25.0.1, this would be extremely > helpful. > > Regards, > Chen Liang > ------------------------------ > *From:* core-libs-dev on behalf of > weigao > *Sent:* Wednesday, December 10, 2025 9:31 PM > *To:* core-libs-dev at openjdk.org > *Subject:* Re: [External] Feedback JDK-8318761 : Potential Issue in JDK > 25 MessageFormat: Use of Internal Exception for Control Flow > > hi , because of ``private static FormatStyle fromString(String text)` > throw exception and the try catch exception just set the deault value ` > FormatStyle.SUBFORMATPATTERN` , so why just make this function retuen > this value like ? Is it better , right ? > ``` > > private static FormatStyle fromString(String text) { > for (FormatStyle style : values()) { > // Also check trimmed case-insensitive for historical reasons > if (style != FormatStyle.SUBFORMATPATTERN && > text.trim().compareToIgnoreCase(style.text) == 0) { > return style; > } > } > return FormatStyle.SUBFORMATPATTERN; > } > > ``` > > weigao ?2025?12?11??? 11:21??? > > Hello, > > I would like to report a potential design issue in the JDK 25 > implementation of MessageFormat. > > While working with java.util.Locale#getDisplayName(), I found that JDK > internals throw and catch an IllegalArgumentException due to the > following pattern added in the resource bundles: > > - > > sun.util.resources.cldr.LocaleNames > - > > sun.util.resources.LocaleNames > > The pattern in question is: > > DisplayNamePattern: {0,choice,0#|1#{1}|2#{1} ({2})} > > This change originates from the following commit: > adoptium/jdk at 00ffc42 ? which adds a pattern for MessageFormat. > However, choice is *not* a valid type for FormatStyle. > > As a result, calling Locale#getDisplayName() triggers the following > exception inside JDK code: > > java.lang.IllegalArgumentException > at java.base/java.text.MessageFormat$FormatStyle.fromString(MessageFormat.java:2013) > at java.base/java.text.MessageFormat.formatFromPattern(MessageFormat.java:1718) > at java.base/java.text.MessageFormat.setFormatFromPattern(MessageFormat.java:1679) > at java.base/java.text.MessageFormat.applyPatternImpl(MessageFormat.java:660) > at java.base/java.text.MessageFormat.(MessageFormat.java:516) > at java.base/java.util.Locale.getDisplayName(Locale.java:2309) > > The implementation currently relies on exception-based logic: > > try { > fStyle = FormatStyle.fromString(style); > } catch (IllegalArgumentException iae) { > fStyle = FormatStyle.SUBFORMATPATTERN; > } > > I understand that MessageFormat catches this exception and falls back to > SUBFORMATPATTERN, but using exceptions to control expected logic paths > may not be ideal?especially since FormatStyle.fromString() is only used > by MessageFormat. > > A potentially cleaner approach could be to have FormatStyle.fromString() > return FormatStyle.SUBFORMATPATTERN directly when encountering unknown > style identifiers, instead of throwing an exception. > > *JDK Version Observed:* > > OpenJDK Runtime Environment Temurin-25.0.1+8 (build 25.0.1+8-LTS) > > Please let me know if this behavior is intentional, or if it should be > considered for improvement. > > Best regards, > vincent gao > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Fri Dec 12 05:50:05 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Dec 2025 05:50:05 GMT Subject: RFR: 8373517: Revert the macos Tahoe specific change done in JDK-8359830 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:25:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which reverts the macos Tahoe specific change we had done in https://bugs.openjdk.org/browse/JDK-8359830? As noted in https://bugs.openjdk.org/browse/JDK-8373517, Apple addressed the underlying issue in a 26.0 Beta release and we no longer require this change in the JDK. > > The revert in this PR was done with a `git revert` of 8df6b2c4a355751cd8ca37cc5932be66bccaa123. That original commit had updated a jtreg test to verify the `os.version` system property reported by the JDK on macos. The commit in this PR retains that test because it's useful even without the source changes done in that older commit. > > tier1, tier2 and tier3 testing of this change completed without any related issues. I've verified that macos 26.x was one of the hosts that was picked up in those test runs. Thank you Roger and Brian for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28768#issuecomment-3645007123 From jpai at openjdk.org Fri Dec 12 05:50:06 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 12 Dec 2025 05:50:06 GMT Subject: Integrated: 8373517: Revert the macos Tahoe specific change done in JDK-8359830 In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 15:25:30 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which reverts the macos Tahoe specific change we had done in https://bugs.openjdk.org/browse/JDK-8359830? As noted in https://bugs.openjdk.org/browse/JDK-8373517, Apple addressed the underlying issue in a 26.0 Beta release and we no longer require this change in the JDK. > > The revert in this PR was done with a `git revert` of 8df6b2c4a355751cd8ca37cc5932be66bccaa123. That original commit had updated a jtreg test to verify the `os.version` system property reported by the JDK on macos. The commit in this PR retains that test because it's useful even without the source changes done in that older commit. > > tier1, tier2 and tier3 testing of this change completed without any related issues. I've verified that macos 26.x was one of the hosts that was picked up in those test runs. This pull request has now been integrated. Changeset: 325cdb7f Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/325cdb7fc5cd2ce1d2c2bf08ca064fb0f7e5a0b8 Stats: 34 lines in 1 file changed: 0 ins; 18 del; 16 mod 8373517: Revert the macos Tahoe specific change done in JDK-8359830 Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.org/jdk/pull/28768 From erfang at openjdk.org Fri Dec 12 07:47:12 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 12 Dec 2025 07:47:12 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: > `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. > 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. > > This PR does the following optimizations: > 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. > 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as th... Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Merge branch 'master' into JDK-8370863-mask-cast-opt - Merge branch 'master' into JDK-8370863-mask-cast-opt - Add MaxVectorSize IR test condition for VectorStoreMaskIdentityTest.java - Refine the test code and comments - Merge branch 'master' into JDK-8370863-mask-cast-opt - Don't read and write the same memory in the JMH benchmarks - Merge branch 'master' into JDK-8370863-mask-cast-opt - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. Current optimizations related to `VectorMaskCastNode` include: 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. This PR does the following optimizations: 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vector, it remains unchanged as long as the vector length remains the same, and this is guranteed in the api level. I conducted some simple research on different mask generation methods and mask operations, and obtained the following table, which includes some potential optimization opportunities that may use this `uncast_mask` function. ``` mask_gen\op toLong anyTrue allTrue trueCount firstTrue lastTrue compare N/A N/A N/A N/A N/A N/A maskAll TBI TBI TBI TBI TBI TBI fromLong TBI TBI N/A TBI TBI TBI mask_gen\op and or xor andNot not laneIsSet compare N/A N/A N/A N/A TBI N/A maskAll TBI TBI TBI TBI TBI TBI fromLong N/A N/A N/A N/A TBI TBI ``` `TBI` indicated that there may be potential optimizations here that require further investigation. Benchmarks: On a Nvidia Grace machine with 128-bit SVE2: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 59.23 0.21 148.12 0.07 2.50 microMaskLoadCastStoreDouble128 ops/us 2.43 0.00 38.31 0.01 15.73 microMaskLoadCastStoreFloat128 ops/us 6.19 0.00 75.67 0.11 12.22 microMaskLoadCastStoreInt128 ops/us 6.19 0.00 75.67 0.03 12.22 microMaskLoadCastStoreLong128 ops/us 2.43 0.00 38.32 0.01 15.74 microMaskLoadCastStoreShort64 ops/us 28.89 0.02 75.60 0.09 2.62 ``` On a Nvidia Grace machine with 128-bit NEON: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 75.75 0.19 149.74 0.08 1.98 microMaskLoadCastStoreDouble128 ops/us 8.71 0.03 38.71 0.05 4.44 microMaskLoadCastStoreFloat128 ops/us 24.05 0.03 76.49 0.05 3.18 microMaskLoadCastStoreInt128 ops/us 24.06 0.02 76.51 0.05 3.18 microMaskLoadCastStoreLong128 ops/us 8.72 0.01 38.71 0.02 4.44 microMaskLoadCastStoreShort64 ops/us 24.64 0.01 76.43 0.06 3.10 ``` On an AMD EPYC 9124 16-Core Processor with AVX3: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 82.13 0.31 115.14 0.08 1.40 microMaskLoadCastStoreDouble128 ops/us 0.32 0.00 0.32 0.00 1.01 microMaskLoadCastStoreFloat128 ops/us 42.18 0.05 57.56 0.07 1.36 microMaskLoadCastStoreInt128 ops/us 42.19 0.01 57.53 0.08 1.36 microMaskLoadCastStoreLong128 ops/us 0.30 0.01 0.32 0.00 1.05 microMaskLoadCastStoreShort64 ops/us 42.18 0.05 57.59 0.01 1.37 ``` On an AMD EPYC 9124 16-Core Processor with AVX2: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 73.53 0.20 114.98 0.03 1.56 microMaskLoadCastStoreDouble128 ops/us 0.29 0.01 0.30 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 30.78 0.14 57.50 0.01 1.87 microMaskLoadCastStoreInt128 ops/us 30.65 0.26 57.50 0.01 1.88 microMaskLoadCastStoreLong128 ops/us 0.30 0.00 0.30 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 24.92 0.00 57.49 0.01 2.31 ``` On an AMD EPYC 9124 16-Core Processor with AVX1: ``` Benchmark Unit Before Error After Error Uplift microMaskLoadCastStoreByte64 ops/us 79.68 0.01 248.49 0.91 3.12 microMaskLoadCastStoreDouble128 ops/us 0.28 0.00 0.28 0.00 1.00 microMaskLoadCastStoreFloat128 ops/us 31.11 0.04 95.48 2.27 3.07 microMaskLoadCastStoreInt128 ops/us 31.10 0.03 99.94 1.87 3.21 microMaskLoadCastStoreLong128 ops/us 0.28 0.00 0.28 0.00 0.99 microMaskLoadCastStoreShort64 ops/us 31.11 0.02 94.97 2.30 3.05 ``` This PR was tested on 128-bit, 256-bit, and 512-bit (QEMU) aarch64 environments, and two 512-bit x64 machines with various configurations, including sve2, sve1, neon, avx3, avx2, avx1, sse4 and sse3, all tests passed. ------------- Changes: https://git.openjdk.org/jdk/pull/28313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=04 Stats: 631 lines in 7 files changed: 520 ins; 16 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/28313.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28313/head:pull/28313 PR: https://git.openjdk.org/jdk/pull/28313 From erfang at openjdk.org Fri Dec 12 08:42:22 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 12 Dec 2025 08:42:22 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v2] In-Reply-To: References: Message-ID: > The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. > > Problem: > -------- > UMIN was using MAX_OR_INF (signed maximum value) as the identity: > - Byte.MAX_VALUE (127) instead of max unsigned byte (255) > - Short.MAX_VALUE (32767) instead of max unsigned short (65535) > - Integer.MAX_VALUE instead of max unsigned int (-1) > - Long.MAX_VALUE instead of max unsigned long (-1) > > UMAX was using MIN_OR_INF (signed minimum value) as the identity: > - Byte.MIN_VALUE (-128) instead of 0 > - Short.MIN_VALUE (-32768) instead of 0 > - Integer.MIN_VALUE instead of 0 > - Long.MIN_VALUE instead of 0 > > This caused incorrect result. For example: > UMAX([42,42,...,42]) returned 128 instead of 42 > > Solution: > --------- > Use correct unsigned identity values: > - UMIN: ($type$)-1 (maximum unsigned value) > - UMAX: ($type$)0 (minimum unsigned value) > > Changes: > -------- > - X-Vector.java.template: Fixed identity values in reductionOperations > - gen-template.sh: Fixed identity values for test code generation > - templates/Unit-header.template: Updated copyright year to 2025 > - Regenerated all Vector classes and test files > > Testing: > -------- > All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. Eric Fang 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: - Declare two constants for UMIN/UMAX reduction identity values - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity - 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. Problem: -------- UMIN was using MAX_OR_INF (signed maximum value) as the identity: - Byte.MAX_VALUE (127) instead of max unsigned byte (255) - Short.MAX_VALUE (32767) instead of max unsigned short (65535) - Integer.MAX_VALUE instead of max unsigned int (-1) - Long.MAX_VALUE instead of max unsigned long (-1) UMAX was using MIN_OR_INF (signed minimum value) as the identity: - Byte.MIN_VALUE (-128) instead of 0 - Short.MIN_VALUE (-32768) instead of 0 - Integer.MIN_VALUE instead of 0 - Long.MIN_VALUE instead of 0 This caused incorrect result. For example: UMAX([42,42,...,42]) returned 128 instead of 42 Solution: --------- Use correct unsigned identity values: - UMIN: ($type$)-1 (maximum unsigned value) - UMAX: ($type$)0 (minimum unsigned value) Changes: -------- - X-Vector.java.template: Fixed identity values in reductionOperations - gen-template.sh: Fixed identity values for test code generation - templates/Unit-header.template: Updated copyright year to 2025 - Regenerated all Vector classes and test files Testing: -------- All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28692/files - new: https://git.openjdk.org/jdk/pull/28692/files/4fb63a36..7f737457 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=00-01 Stats: 47492 lines in 706 files changed: 27364 ins; 15029 del; 5099 mod Patch: https://git.openjdk.org/jdk/pull/28692.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28692/head:pull/28692 PR: https://git.openjdk.org/jdk/pull/28692 From erfang at openjdk.org Fri Dec 12 08:52:00 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 12 Dec 2025 08:52:00 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v2] In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Tue, 9 Dec 2025 17:34:19 GMT, Paul Sandoz wrote: >> Okay, I understand, thank you for your insight! I'll wait for @PaulSandoz 's comment and see if we should add two **public** constants to this PR. Then I'll modify it accordingly. > > I would prefer to declare identity constants, but **only** in tests [1] , such as `MUL_IDENTITY`, `UMAX_IDENTITY` etc, that we consistently refer to and then add basic tests to verify that identity with respect to the scalar operation. The identity values are also embedded in the JDK and HotSpot compiler and i want to ensure they are clearly compared against the expected identity when an all-false mask is used. > > [1] later we could place these in some internal JDK class so we can use the same values in the JDK code, then adjust the tests to grant access to the internal JDK class to use those values. A more general place to surface up scalar identity values is in `VectorOperators` for the associative operators, something to consider later on perhaps, and that would require a CSR. @PaulSandoz Thanks for your suggestion! I declared some identity constants in both the tests and the implementations. And added some tests to verify the correctness of these constants. @merykitty Now we're using a correct constant to represent the identity value, eliminating the dependency on incorrect literals. So I've chosen to keep the current coding style. I tried the style you suggested, but I feel the original style is more readable and maintainable. Do you think this is okay? Please help take another look, thank you! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2613421273 From erfang at openjdk.org Fri Dec 12 08:55:52 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 12 Dec 2025 08:55:52 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 08:42:22 GMT, Eric Fang wrote: >> The original implementation of UMIN/UMAX reductions in JDK-8346174 used incorrect identity values in the Java implementation and test code. >> >> Problem: >> -------- >> UMIN was using MAX_OR_INF (signed maximum value) as the identity: >> - Byte.MAX_VALUE (127) instead of max unsigned byte (255) >> - Short.MAX_VALUE (32767) instead of max unsigned short (65535) >> - Integer.MAX_VALUE instead of max unsigned int (-1) >> - Long.MAX_VALUE instead of max unsigned long (-1) >> >> UMAX was using MIN_OR_INF (signed minimum value) as the identity: >> - Byte.MIN_VALUE (-128) instead of 0 >> - Short.MIN_VALUE (-32768) instead of 0 >> - Integer.MIN_VALUE instead of 0 >> - Long.MIN_VALUE instead of 0 >> >> This caused incorrect result. For example: >> UMAX([42,42,...,42]) returned 128 instead of 42 >> >> Solution: >> --------- >> Use correct unsigned identity values: >> - UMIN: ($type$)-1 (maximum unsigned value) >> - UMAX: ($type$)0 (minimum unsigned value) >> >> Changes: >> -------- >> - X-Vector.java.template: Fixed identity values in reductionOperations >> - gen-template.sh: Fixed identity values for test code generation >> - templates/Unit-header.template: Updated copyright year to 2025 >> - Regenerated all Vector classes and test files >> >> Testing: >> -------- >> All types (byte/short/int/long) now return correct results in both interpreter mode (-Xint) and compiled mode. > > Eric Fang 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: > > - Declare two constants for UMIN/UMAX reduction identity values > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions > > The original implementation of UMIN/UMAX reductions in JDK-8346174 > used incorrect identity values in the Java implementation and test code. > > Problem: > -------- > UMIN was using MAX_OR_INF (signed maximum value) as the identity: > - Byte.MAX_VALUE (127) instead of max unsigned byte (255) > - Short.MAX_VALUE (32767) instead of max unsigned short (65535) > - Integer.MAX_VALUE instead of max unsigned int (-1) > - Long.MAX_VALUE instead of max unsigned long (-1) > > UMAX was using MIN_OR_INF (signed minimum value) as the identity: > - Byte.MIN_VALUE (-128) instead of 0 > - Short.MIN_VALUE (-32768) instead of 0 > - Integer.MIN_VALUE instead of 0 > - Long.MIN_VALUE instead of 0 > > This caused incorrect result. For example: > UMAX([42,42,...,42]) returned 128 instead of 42 > > Solution: > --------- > Use correct unsigned identity values: > - UMIN: ($type$)-1 (maximum unsigned value) > - UMAX: ($type$)0 (minimum unsigned value) > > Changes: > -------- > - X-Vector.java.template: Fixed identity values in reductionOperations > - gen-template.sh: Fixed identity values for test code generation > - templates/Unit-header.template: Updated copyright year to 2025 > - Regenerated all Vector classes and test files > > Testing: > -------- > All types (byte/short/int/long) now return correct results in both > interpreter mode (-Xint) and compiled mode. Since this issue https://bugs.openjdk.org/browse/JDK-8373390, I didn't merge the latest master branch into this PR. After that issue is fixed, I'll resolve the merge conflicts. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3645539137 From rgiulietti at openjdk.org Fri Dec 12 10:20:26 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Dec 2025 10:20:26 GMT Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced [v3] In-Reply-To: References: Message-ID: > Doc only change. Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Use a more assertive wording. - Merge branch 'master' into 8341914 - Add the 'c' conversion as well. - 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27830/files - new: https://git.openjdk.org/jdk/pull/27830/files/c51f19f6..f48bf4d9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27830&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27830&range=01-02 Stats: 385531 lines in 3924 files changed: 249386 ins; 86793 del; 49352 mod Patch: https://git.openjdk.org/jdk/pull/27830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27830/head:pull/27830 PR: https://git.openjdk.org/jdk/pull/27830 From rgiulietti at openjdk.org Fri Dec 12 10:46:43 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Dec 2025 10:46:43 GMT Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced [v4] In-Reply-To: References: Message-ID: > Doc only change. Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: Remove unused import. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27830/files - new: https://git.openjdk.org/jdk/pull/27830/files/f48bf4d9..b2864964 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27830&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27830&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27830.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27830/head:pull/27830 PR: https://git.openjdk.org/jdk/pull/27830 From bkilambi at openjdk.org Fri Dec 12 14:31:20 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 12 Dec 2025 14:31:20 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: <_QEYCQm138PWv2vGjMFvEJ6kfMjGEn_vsuEZ_EPaRxQ=.b42967e5-cc22-4c98-a454-6698ce0a70cf@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <_QEYCQm138PWv2vGjMFvEJ6kfMjGEn_vsuEZ_EPaRxQ=.b42967e5-cc22-4c98-a454-6698ce0a70cf@github.com> Message-ID: On Thu, 11 Dec 2025 12:06:49 GMT, Marc Chevalier wrote: >> This patch adds mid-end support for vectorized add/mul reduction operations for half floats. It also includes backend aarch64 support for these operations. Only vectorization support through autovectorization is added as VectorAPI currently does not support Float16 vector species. >> >> Both add and mul reduction vectorized through autovectorization mandate the implementation to be strictly ordered. The following is how each of these reductions is implemented for different aarch64 targets - >> >> **For AddReduction :** >> On Neon only targets (UseSVE = 0): Generates scalarized additions using the scalar `fadd` instruction for both 8B and 16B vector lengths. This is because Neon does not provide a direct instruction for computing strictly ordered floating point add reduction. >> >> On SVE targets (UseSVE > 0): Generates the `fadda` instruction which computes add reduction for floating point in strict order. >> >> **For MulReduction :** >> Both Neon and SVE do not provide a direct instruction for computing strictly ordered floating point multiply reduction. For vector lengths of 8B and 16B, a scalarized sequence of scalar `fmul` instructions is generated and multiply reduction for vector lengths > 16B is not supported. >> >> Below is the performance of the two newly added microbenchmarks in `Float16OperationsBenchmark.java` tested on three different aarch64 machines and with varying `MaxVectorSize` - >> >> Note: On all machines, the score (ops/ms) is compared with the master branch without this patch which generates a sequence of loads (`ldrsh`) to load the FP16 value into an FPR and a scalar `fadd/fmul` to add/multiply the loaded value to the running sum/product. The ratios given below are the ratios between the throughput with this patch and the throughput without this patch. >> Ratio > 1 indicates the performance with this patch is better than the master branch. >> >> **N1 (UseSVE = 0, max vector length = 16B):** >> >> Benchmark vectorDim Mode Cnt 8B 16B >> ReductionAddFP16 256 thrpt 9 1.41 1.40 >> ReductionAddFP16 512 thrpt 9 1.41 1.41 >> ReductionAddFP16 1024 thrpt 9 1.43 1.40 >> ReductionAddFP16 2048 thrpt 9 1.43 1.40 >> ReductionMulFP16 256 thrpt 9 1.22 1.22 >> ReductionMulFP16 512 thrpt 9 1.21 1.23 >> ReductionMulFP16 1024 thrpt 9 1.21 1.22 >> ReductionMulFP16 2048 thrpt 9 1.20 1.22 >> >> >> On N1, the scalarized sequence of `fadd/fmul` are gener... > > As for the IR verification failure, I've looked a bit and couldn't find such an issue already. Since it reproduces on master, I suggest you file a ticket, indeed. Thanks! @marc-chevalier @eme64 I have created a ticket for this issue (I could reproduce the IR rules failures on both aarch64 and x86_64 locally) - https://bugs.openjdk.org/browse/JDK-8373605 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3646698569 From galder at openjdk.org Fri Dec 12 14:53:15 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Fri, 12 Dec 2025 14:53:15 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 07:47:12 GMT, Eric Fang wrote: >> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. >> >> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: >> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` >> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. >> >> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. >> >> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. >> >> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. >> >> Current optimizations related to `VectorMaskCastNode` include: >> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. >> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. >> >> This PR does the following optimizations: >> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. >> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect... > > Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Add MaxVectorSize IR test condition for VectorStoreMaskIdentityTest.java > - Refine the test code and comments > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Don't read and write the same memory in the JMH benchmarks > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns > > `VectorMaskCastNode` is used to cast a vector mask from one type to > another type. The cast may be generated by calling the vector API `cast` > or generated by the compiler. For example, some vector mask operations > like `trueCount` require the input mask to be integer types, so for > floating point type masks, the compiler will cast the mask to the > corresponding integer type mask automatically before doing the mask > operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` > don't generate code, otherwise code will be generated to extend or narrow > the mask. This IR node is not free no matter it generates code or not > because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` > The middle `VectorMaskCast` prevented the following optimization: > `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which > blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we > can safely do the optimization. But if the input value is changed, we > can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper > function, which can be used to uncast a chain of `VectorMaskCastNode`, > like the existing `Node::uncast(bool)` function. The funtion returns > the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may > contain one or more consecutive `VectorMaskCastNode` and this does not > affect the correctness of the optimization. Then this function can be > called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(V... LGTM thanks @erifan! ------------- Marked as reviewed by galder (Author). PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3572127237 From epeter at openjdk.org Fri Dec 12 15:17:16 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 12 Dec 2025 15:17:16 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 07:47:12 GMT, Eric Fang wrote: >> `VectorMaskCastNode` is used to cast a vector mask from one type to another type. The cast may be generated by calling the vector API `cast` or generated by the compiler. For example, some vector mask operations like `trueCount` require the input mask to be integer types, so for floating point type masks, the compiler will cast the mask to the corresponding integer type mask automatically before doing the mask operation. This kind of cast is very common. >> >> If the vector element size is not changed, the `VectorMaskCastNode` don't generate code, otherwise code will be generated to extend or narrow the mask. This IR node is not free no matter it generates code or not because it may block some optimizations. For example: >> 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` The middle `VectorMaskCast` prevented the following optimization: `(VectorStoremask (VectorLoadMask x)) => (x)` >> 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. >> >> In these IR patterns, the value of the input `x` is not changed, so we can safely do the optimization. But if the input value is changed, we can't eliminate the cast. >> >> The general idea of this PR is introducing an `uncast_mask` helper function, which can be used to uncast a chain of `VectorMaskCastNode`, like the existing `Node::uncast(bool)` function. The funtion returns the first non `VectorMaskCastNode`. >> >> The intended use case is when the IR pattern to be optimized may contain one or more consecutive `VectorMaskCastNode` and this does not affect the correctness of the optimization. Then this function can be called to eliminate the `VectorMaskCastNode` chain. >> >> Current optimizations related to `VectorMaskCastNode` include: >> 1. `(VectorMaskCast (VectorMaskCast x)) => (x)`, see JDK-8356760. >> 2. `(XorV (VectorMaskCast (VectorMaskCmp src1 src2 cond)) (Replicate -1)) => (VectorMaskCast (VectorMaskCmp src1 src2 ncond))`, see JDK-8354242. >> >> This PR does the following optimizations: >> 1. Extends the optimization pattern `(VectorMaskCast (VectorMaskCast x)) => (x)` as `(VectorMaskCast (VectorMaskCast? ... (VectorMaskCast x))) => (x)`. Because as long as types of the head and tail `VectorMaskCastNode` are consistent, the optimization is correct. >> 2. Supports a new optimization pattern `(VectorStoreMask (VectorMaskCast ... (VectorLoadMask x))) => (x)`. Since the value before and after the pattern is a boolean vect... > > Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: > > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Add MaxVectorSize IR test condition for VectorStoreMaskIdentityTest.java > - Refine the test code and comments > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Don't read and write the same memory in the JMH benchmarks > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns > > `VectorMaskCastNode` is used to cast a vector mask from one type to > another type. The cast may be generated by calling the vector API `cast` > or generated by the compiler. For example, some vector mask operations > like `trueCount` require the input mask to be integer types, so for > floating point type masks, the compiler will cast the mask to the > corresponding integer type mask automatically before doing the mask > operation. This kind of cast is very common. > > If the vector element size is not changed, the `VectorMaskCastNode` > don't generate code, otherwise code will be generated to extend or narrow > the mask. This IR node is not free no matter it generates code or not > because it may block some optimizations. For example: > 1. `(VectorStoremask (VectorMaskCast (VectorLoadMask x)))` > The middle `VectorMaskCast` prevented the following optimization: > `(VectorStoremask (VectorLoadMask x)) => (x)` > 2. `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))`, which > blocks the optimization `(VectorMaskToLong (VectorLongToMask x)) => (x)`. > > In these IR patterns, the value of the input `x` is not changed, so we > can safely do the optimization. But if the input value is changed, we > can't eliminate the cast. > > The general idea of this PR is introducing an `uncast_mask` helper > function, which can be used to uncast a chain of `VectorMaskCastNode`, > like the existing `Node::uncast(bool)` function. The funtion returns > the first non `VectorMaskCastNode`. > > The intended use case is when the IR pattern to be optimized may > contain one or more consecutive `VectorMaskCastNode` and this does not > affect the correctness of the optimization. Then this function can be > called to eliminate the `VectorMaskCastNode` chain. > > Current optimizations related to `VectorMaskCastNode` include: > 1. `(V... Nice work! Thanks for working on this! Just had a quick glance. Maybe I can do a full review next week. src/hotspot/share/opto/vectornode.cpp line 1489: > 1487: Node* VectorStoreMaskNode::Identity(PhaseGVN* phase) { > 1488: // Identity transformation on boolean vectors. > 1489: // VectorStoreMask (VectorMaskCast ... VectorLoadMask bv) elem_size ==> bv Suggestion: // VectorStoreMask (VectorMaskCast* VectorLoadMask bv) elem_size ==> bv Would a regex star be more explicit about 0 or more repetitions? src/hotspot/share/opto/vectornode.cpp line 1492: > 1490: // vector[n]{bool} => vector[n]{t} => vector[n]{bool} > 1491: Node* in1 = VectorNode::uncast_mask(in(1)); > 1492: if (in1->Opcode() == Op_VectorLoadMask && length() == in1->as_Vector()->length()) { Can there be a mismatch with the length? Can you give me an example? ------------- PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3572250876 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2614574171 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2614577536 From epeter at openjdk.org Fri Dec 12 15:17:19 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 12 Dec 2025 15:17:19 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v2] In-Reply-To: References: <4vSKAtr0tUG0V193gIvnEFdHm18ZhqflVAwk-09IVQ0=.081806f5-6303-4b4f-975d-7c85427ccae5@github.com> Message-ID: On Thu, 4 Dec 2025 02:23:40 GMT, Eric Fang wrote: >> src/hotspot/share/opto/vectornode.cpp line 1056: >> >>> 1054: // x remains to be a bool vector with no changes. >>> 1055: // This function can be used to eliminate the VectorMaskCast in such patterns. >>> 1056: Node* VectorNode::uncast_mask(Node* n) { >> >> Could this be a static method instead? > > Yeah it's already a static method. See https://github.com/openjdk/jdk/pull/28313/files#diff-ba9e2d10a50a01316946660ec9f68321eb864fd9c815616c10abbec39360efe5R141 > > Or you mean a static method limited to this file ? If so, I prefer not, it may be used at other places. Thanks~ Could you return a `VectorNode*`? And should the input not already be a `VectorNode*`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2614565511 From bkilambi at openjdk.org Fri Dec 12 15:45:29 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 12 Dec 2025 15:45:29 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <4VXHOCR1YSoMVbDbB8j-j18Z-_VbO0y5fJfyp3IjQ9c=.19485011-9cb3-4016-a642-61cee81adcd1@github.com> Message-ID: On Tue, 7 Oct 2025 02:47:50 GMT, Xiaohong Gong wrote: >> Are you referring to the N1 numbers? The add reduction operation has gains around ~40% while the mul reduction is around ~20% on N1. On V1 and V2 they look comparable (not considering the cases where we generate `fadda` instructions for add reduction). >> >>> Seems instructions between different ins instructions will have a data-dependence, which is not expected >> >> Why do you think it's not expected? We have the exact same sequence for Neon add reduction as well. There's back to back dependency there as well and yet it shows better performance. The N1 optimization guide shows 2 cyc latency for `fadd` and 3 cyc latency for `fmul`. Could this be the reason? WDYT? > > I mean we do not expect there is data-dependence between two `ins` operations, but it has now. We do not recommend use the instructions that just write part of a register. This might involve un-expected dependence between. I suggest to use `ext` instead, and I can observe about 20% performance improvement compared with current version on V2. I did not check the correctness, but it looks right to me. Could you please help check on other machines? Thanks! > > The change might look like: > Suggestion: > > fmulh(dst, fsrc, vsrc); > ext(vtmp, T8B, vsrc, vsrc, 2); > fmulh(dst, dst, vtmp); > ext(vtmp, T8B, vsrc, vsrc, 4); > fmulh(dst, dst, vtmp); > ext(vtmp, T8B, vsrc, vsrc, 6); > fmulh(dst, dst, vtmp); > if (isQ) { > ext(vtmp, T16B, vsrc, vsrc, 8); > fmulh(dst, dst, vtmp); > ext(vtmp, T16B, vsrc, vsrc, 10); > fmulh(dst, dst, vtmp); > ext(vtmp, T16B, vsrc, vsrc, 12); > fmulh(dst, dst, vtmp); > ext(vtmp, T16B, vsrc, vsrc, 14); > fmulh(dst, dst, vtmp); Hi @XiaohongGong Thanks for this suggestion. I understand that `ins` has a read-modify-write dependency while `ext` does not have that as we are not reading the `vtmp` register in this case. I made changes to both the add and mul reduction implementation and I could see some perf gains on V1 and V2 for mul reduction - Benchmark | vectorDim | 8B | 16B -- | -- | -- | -- Float16OperationsBenchmark.ReductionAddFP16 | 256 | 1.0022509 | 0.99938584 Float16OperationsBenchmark.ReductionAddFP16 | 512 | 1.05157946 | 1.00262025 Float16OperationsBenchmark.ReductionAddFP16 | 1024 | 1.02392196 | 1.00187924 Float16OperationsBenchmark.ReductionAddFP16 | 2048 | 1.01219315 | 0.99964493 Float16OperationsBenchmark.ReductionMulFP16 | 256 | 0.99729809 | 1.19006546 Float16OperationsBenchmark.ReductionMulFP16 | 512 | 1.03897347 | 1.0689105 Float16OperationsBenchmark.ReductionMulFP16 | 1024 | 1.01822982 | 1.01509971 Float16OperationsBenchmark.ReductionMulFP16 | 2048 | 1.0086255 | 1.0032434 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2614674991 From dl at openjdk.org Fri Dec 12 16:52:07 2025 From: dl at openjdk.org (Doug Lea) Date: Fri, 12 Dec 2025 16:52:07 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out Message-ID: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Changes signal filtering to avoid possible starvation ------------- Commit messages: - signalWork diagnostic - filter by index - For testing Changes: https://git.openjdk.org/jdk/pull/28797/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373118 Stats: 70 lines in 1 file changed: 44 ins; 5 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28797.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28797/head:pull/28797 PR: https://git.openjdk.org/jdk/pull/28797 From rriggs at openjdk.org Fri Dec 12 17:37:54 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 12 Dec 2025 17:37:54 GMT Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced [v4] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 10:46:43 GMT, Raffaello Giulietti wrote: >> Doc only change. > > Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: > > Remove unused import. src/java.base/share/classes/java/util/Formatter.java line 442: > 440: * Not all subtypes of {@link TemporalAccessor} carry a time zone, though, > 441: * so in such cases this conversion throws an {@link IllegalFormatConversionException}. > 442: * A more complete description would helpful before the table at line 388 and also just after the mention of TemporalAccessor at line 1627, I'd suggest a sentence or paragraph with something like: The `java.time` types such as `LocalDateTime `or `MonthDay` are TemporalAccessors. Each of the formatting character uses fields from the TemporalAccessor but not all accessors have all of the field. For example, the timezone is not available from LocalDateTime. If a field is not available an IllegalFormatConversionException is thrown. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27830#discussion_r2615056459 From rgiulietti at openjdk.org Fri Dec 12 18:57:54 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Fri, 12 Dec 2025 18:57:54 GMT Subject: RFR: 8341914: The j.u.Formatter doc for TemporalAccessor should be enhanced [v4] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 17:35:40 GMT, Roger Riggs wrote: >> Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unused import. > > src/java.base/share/classes/java/util/Formatter.java line 442: > >> 440: * Not all subtypes of {@link TemporalAccessor} carry a time zone, though, >> 441: * so in such cases this conversion throws an {@link IllegalFormatConversionException}. >> 442: * > > A more complete description would helpful before the table at line 388 and also > just after the mention of TemporalAccessor at line 1627, I'd suggest a sentence or paragraph with something like: > > The `java.time` types such as `LocalDateTime `or `MonthDay` are TemporalAccessors. > Each of the formatting character uses fields from the TemporalAccessor but not all accessors have all of the field. For example, the timezone is not available from LocalDateTime. If a field is not available an IllegalFormatConversionException is thrown. After a deeper look, it seems to me that what happens with `long` and `Long` used in date/time conversions is not detailed at all ?. So expect more thorough patch for date/time related conversions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27830#discussion_r2615255683 From duke at openjdk.org Fri Dec 12 19:14:50 2025 From: duke at openjdk.org (Trevor Bond) Date: Fri, 12 Dec 2025 19:14:50 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 23:58:31 GMT, Chen Liang wrote: >> Add a new factory method to `IncrementInstruction` that allows the explicit creation of a wide iinc instruction, even with a `slot` and `constant` that could fit into a normal iinc instruction. Previously, only one factory for iinc instructions existed, which inferred the type of instruction needed given the size of `slot` and `constant`. Add additional test cases for the new factory as well. All tier 1 tests and classfile tests have passed with these changes. > > Since this is an API addition, this will require a CSR. Once we have settled with the javadocs, I can create a CSR (which requires a JBS account) Hi @liach, would you be able to create a CSR request, or is there anything you need from me here? Thank you ------------- PR Comment: https://git.openjdk.org/jdk/pull/28729#issuecomment-3647799215