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 From dnguyen at openjdk.org Fri Dec 12 21:40:21 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 21:40:21 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update Message-ID: Open l10n drop. Files have been updated with translated versions. ------------- Commit messages: - Fix single quote - Initial commit Changes: https://git.openjdk.org/jdk/pull/28802/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373119 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Fri Dec 12 21:40:23 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 21:40:23 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:43:36 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. src/java.base/share/classes/sun/security/util/resources/security_de.properties line 46: > 44: invalid.null.action.provided=Ung?ltige Nullaktion angegeben > 45: invalid.null.Class.provided=Ung?ltige Nullklasse angegeben > 46: Subject.=Subject:\n This change reverts what was previously changed in the last l10n drop. There was a request to change word "Subject" to "Subjekt" at the time, and this was manually adjusted. This issue was brought up to the translation team but was ultimately rejected. So, to align with upstream, I will leave this as is. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: > 207: javac.opt.prefer=??????, ??????????????????? > 208: # L10N: do not localize: ''preview'' > 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_de.properties line 230: > 228: doclet.search_in_documentation=In Dokumentation suchen > 229: doclet.search_reset=Zur?cksetzen > 230: doclet.Member=Member Similar to above with security.properties, this change was brought up to the localization team and rejected. I intend to keep this as is for the same reason. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615537125 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615533659 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615538518 From rriggs at openjdk.org Fri Dec 12 21:44:03 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 12 Dec 2025 21:44:03 GMT Subject: RFR: 8373623: Refactor Serialization tests for Records to JUnit Message-ID: Refactor TestNG tests to JUnit under the umbrella initiative of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843). Fairly straight-forward mapping of annotations between the frameworks with some accommodations for differences in the Assert support. ------------- Commit messages: - 8373623: Refactor Serialization tests for Records to JUnit Changes: https://git.openjdk.org/jdk/pull/28804/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28804&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373623 Stats: 431 lines in 20 files changed: 131 ins; 64 del; 236 mod Patch: https://git.openjdk.org/jdk/pull/28804.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28804/head:pull/28804 PR: https://git.openjdk.org/jdk/pull/28804 From jlu at openjdk.org Fri Dec 12 22:07:06 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 22:07:06 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns Message-ID: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. M1 Mac - Perf (before): MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms M1 Mac - Perf (after): Benchmark Mode Cnt Score Error Units MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms ------------- Commit messages: - perf - impl Changes: https://git.openjdk.org/jdk/pull/28806/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373566 Stats: 58 lines in 2 files changed: 21 ins; 11 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/28806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28806/head:pull/28806 PR: https://git.openjdk.org/jdk/pull/28806 From naoto at openjdk.org Fri Dec 12 22:07:51 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 Dec 2025 22:07:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:45:34 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: > >> 207: javac.opt.prefer=??????, ??????????????????? >> 208: # L10N: do not localize: ''preview'' >> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? > > I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. Since this is an apparent l10n mistake, I'd just replace "??" with ''preview'' ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615696431 From jlu at openjdk.org Fri Dec 12 22:24:07 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 22:24:07 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v2] In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com> > This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. > > M1 Mac - Perf (before): > > > MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms > > > M1 Mac - Perf (after): > > > Benchmark Mode Cnt Score Error Units > MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms Justin Lu has updated the pull request incrementally with one additional commit since the last revision: pull values() into a var ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28806/files - new: https://git.openjdk.org/jdk/pull/28806/files/702b35f9..8eea336f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=00-01 Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28806/head:pull/28806 PR: https://git.openjdk.org/jdk/pull/28806 From naoto at openjdk.org Fri Dec 12 22:33:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 Dec 2025 22:33:52 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v2] In-Reply-To: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com> Message-ID: On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > pull values() into a var Looks good. Glad we fixed the performance regression, and kudos to the bug submitter src/java.base/share/classes/java/text/MessageFormat.java line 1993: > 1991: > 1992: // Returns a FormatStyle corresponding to the input text > 1993: // DEFAULT is the empty String, the pre-defined styles are 1-1 with their The comment could mention that pre-defined ones are lower case ones of the enum names, but compared with the input styles ignoring cases for historical reasons ------------- PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3573794462 PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615745186 From dnguyen at openjdk.org Fri Dec 12 22:34:10 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 22:34:10 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert Chinese preview change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/6a280e17..83100f94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Fri Dec 12 22:34:12 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 22:34:12 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <4jc-NxobKK8qRpYSujoOwgvRw7kj4mZVbkNnaf6X--I=.77f68671-384e-4168-9bd6-71566817ad55@github.com> On Fri, 12 Dec 2025 22:04:36 GMT, Naoto Sato wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_zh_CN.properties line 209: >> >>> 207: javac.opt.prefer=??????, ??????????????????? >>> 208: # L10N: do not localize: ''preview'' >>> 209: javac.opt.preview=?????????\n???????lint ???\n?? -source ? --release ????? >> >> I have spotted that this Chinese localization is missing the ''preview'' mentioned in the above comment. I will submit this issue to the localization team. If the fix comes in time, I will add it to this drop. Otherwise, I will add it to the next possible drop. Alternatively, if anyone has a suggestion for how to correct this, I'm open to incorporate it. > > Since this is an apparent l10n mistake, I'd just replace "??" with ''preview'' Thanks. Updated! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615744326 From liach at openjdk.org Fri Dec 12 22:41:51 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 12 Dec 2025 22:41:51 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v2] In-Reply-To: <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> <99TsVSiuxpGVpmk5TdSHpSU4cKNz9aqTRpqdzQynF_Y=.803921d5-76a4-46bc-8b2f-98470eda94fb@github.com> Message-ID: On Fri, 12 Dec 2025 22:24:07 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > pull values() into a var src/java.base/share/classes/java/text/MessageFormat.java line 2005: > 2003: var fStyle = styles[i]; > 2004: // case-insensitive comp for compatibility > 2005: if (style.compareToIgnoreCase(fStyle.toString()) == 0) { Suggestion: if (style.compareToIgnoreCase(fStyle.name()) == 0) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615761963 From jlu at openjdk.org Fri Dec 12 22:51:52 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 22:51:52 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change Identified some errors/inconsistencies you might bring to the translation team. src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 63: > 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n {0} > 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten > 63: javac.opt.arg.Werror=(,)* This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency. src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173: > 171: plugin.opt.disable-plugin=\ --disable-plugin Deaktiviert das angegebene Plug-in > 172: > 173: plugin.opt.compress=\ --compress Komprimiert alle Ressourcen im Ausgabeimage:\n Zul?ssige Werte:\n zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n und "zip-9" f?r die beste Komprimierung steht.\n Standardwert ist "zip-6."\n Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n 0: Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n 1: Gemeinsame Verwendung konstanter Zeichenfolgen\n 2: ZIP. Verwenden Sie stattdessen "zip-6". `` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."` ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3573817418 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615760993 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615770109 From jlu at openjdk.org Fri Dec 12 22:57:14 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 22:57:14 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v3] In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: > This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. > > M1 Mac - Perf (before): > > > MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms > > > M1 Mac - Perf (after): > > > Benchmark Mode Cnt Score Error Units > MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Reflect suggestions from Naoto & Chen ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28806/files - new: https://git.openjdk.org/jdk/pull/28806/files/8eea336f..e56ffa12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=01-02 Stats: 8 lines in 1 file changed: 2 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28806/head:pull/28806 PR: https://git.openjdk.org/jdk/pull/28806 From vklang at openjdk.org Fri Dec 12 22:59:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 12 Dec 2025 22:59:58 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 12 Dec 2025 16:44:21 GMT, Doug Lea

wrote: > Changes signal filtering to avoid possible starvation src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1434: > 1432: final int topLevelExec(ForkJoinTask task, WorkQueue q, > 1433: int fifo, int qbase) { > 1434: int stolen = 1; @DougLea It does seem a bit weird that stolen starts as 1 even if "task == null" (i.e. this method would return 1 for an invocation where task or q is null, which doesn't sounds right?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615790553 From dnguyen at openjdk.org Fri Dec 12 23:00:55 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Fri, 12 Dec 2025 23:00:55 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:38:34 GMT, Justin Lu wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/javac_de.properties line 63: > >> 61: javac.opt.source=Liefert Quellkompatibilit?t mit dem angegebenen Release von Java SE.\nUnterst?tzte Releases: \n {0} >> 62: javac.opt.Werror=Kompilierung beenden, wenn Warnungen auftreten >> 63: javac.opt.arg.Werror=(,)* > > This value is translated for `de`, but not for `ja` or `zh_CN`. It would be ideal for to have consistency. Thanks for finding this. I agree. I'll report this to the translation team so the Japanese and Chinese versions can be picked up as well. If it's not fixed in time for this drop, I'll include it in the next drop. > src/jdk.jlink/share/classes/jdk/tools/jlink/resources/plugins_de.properties line 173: > >> 171: plugin.opt.disable-plugin=\ --disable-plugin Deaktiviert das angegebene Plug-in >> 172: >> 173: plugin.opt.compress=\ --compress Komprimiert alle Ressourcen im Ausgabeimage:\n Zul?ssige Werte:\n zip-'{0-9}', wobei "zip-0" f?r keine Komprimierung\n und "zip-9" f?r die beste Komprimierung steht.\n Standardwert ist "zip-6."\n Veraltete Werte, die in einem zuk?nftigen Release entfernt werden:\n 0: Keine Komprimierung. Verwenden Sie stattdessen "zip-0".\n 1: Gemeinsame Verwendung konstanter Zeichenfolgen\n 2: ZIP. Verwenden Sie stattdessen "zip-6". > > `` is translated here, but untouched in `ja` and `zh_CN`. Also it is odd the period was inserted within the `"zip-6"` string. -> `"zip-6."` The extra period is definitely strange. Like with above, I'll report this as well under the same issue since it seems to only be for Japanese and Chinese again. Thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615791381 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615792622 From vklang at openjdk.org Fri Dec 12 23:04:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 12 Dec 2025 23:04:58 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 12 Dec 2025 22:56:51 GMT, Viktor Klang wrote: >> Changes signal filtering to avoid possible starvation > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1434: > >> 1432: final int topLevelExec(ForkJoinTask task, WorkQueue q, >> 1433: int fifo, int qbase) { >> 1434: int stolen = 1; > > @DougLea It does seem a bit weird that stolen starts as 1 even if "task == null" (i.e. this method would return 1 for an invocation where task or q is null, which doesn't sounds right?) On the other hand, `t` is never null, and `q` is never null, so I'll just suggest a small comment below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615796027 From vklang at openjdk.org Fri Dec 12 23:05:04 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 12 Dec 2025 23:05:04 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <-wMAAOIyEnJYGfGX7XtwMsjaps08ZLHDo4ZqZwWmt8Q=.7a163d43-c0c7-4ae2-88e1-30dee1b6e229@github.com> On Fri, 12 Dec 2025 16:44:21 GMT, Doug Lea
wrote: > Changes signal filtering to avoid possible starvation src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1435: > 1433: int fifo, int qbase) { > 1434: int stolen = 1; > 1435: if (task != null && q != null) { Suggestion: if (task != null && q != null) { // Never null, hoist checks src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1900: > 1898: * giving up q is nonull and signalled slot already taken. > 1899: */ > 1900: final void signalWork(WorkQueue q, int qbase) { This is a nice improvement which also removes the risk of the underlying array for some reason (growth) getting swapped out midway. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1922: > 1920: else > 1921: nc = (v.stackPred & LMASK) | (c & TC_MASK) | ac; > 1922: if (q != null && q.base - qbase > 0) Cheaper and more robust check, I like it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615796425 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615797362 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615797950 From vklang at openjdk.org Fri Dec 12 23:09:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 12 Dec 2025 23:09:52 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 12 Dec 2025 16:44:21 GMT, Doug Lea
wrote: > Changes signal filtering to avoid possible starvation src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1468: > 1466: ForkJoinTask t; int qcap; long qk; > 1467: ForkJoinTask[] qa = q.array; > 1468: if (q.base != qbase || qa == null || (qcap = qa.length) <= 0 || Seems like a negative array length would be problematic in general, so simplifying to a 0-check here? Suggestion: if (q.base != qbase || qa == null || (qcap = qa.length) == 0 || src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1471: > 1469: (t = (ForkJoinTask)U.getReferenceAcquire( > 1470: qa, qk = slotOffset((qcap - 1) & qbase))) == null || > 1471: q.base != qbase || Is this (repeated) check intended? (i.e. are we worried about q.base drift between polling the array?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615804439 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2615806612 From naoto at openjdk.org Fri Dec 12 23:18:52 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 12 Dec 2025 23:18:52 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v3] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Fri, 12 Dec 2025 22:57:14 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Reflect suggestions from Naoto & Chen src/java.base/share/classes/java/text/MessageFormat.java line 2004: > 2002: var styles = values(); > 2003: // Match starting at the pre-defined styles -> [SHORT:] > 2004: for (int i = 2; i < styles.length; i ++) { nit: SHORT.ordinal() can be used ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2615821178 From jlu at openjdk.org Fri Dec 12 23:28:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 12 Dec 2025 23:28:08 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v4] In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: > This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. > > M1 Mac - Perf (before): > > > MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms > > > M1 Mac - Perf (after): > > > Benchmark Mode Cnt Score Error Units > MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms Justin Lu has updated the pull request incrementally with one additional commit since the last revision: use SHORT.ordinal() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28806/files - new: https://git.openjdk.org/jdk/pull/28806/files/e56ffa12..8c80ce3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28806/head:pull/28806 PR: https://git.openjdk.org/jdk/pull/28806 From asemenyuk at openjdk.org Fri Dec 12 23:46:03 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Dec 2025 23:46:03 GMT Subject: RFR: 8373628: jpackage doesn't print to console until completetion Message-ID: Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. ------------- Commit messages: - cli Main: auto flash stderr and stdout in all variants of ToolProvider Changes: https://git.openjdk.org/jdk/pull/28807/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28807&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373628 Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28807.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28807/head:pull/28807 PR: https://git.openjdk.org/jdk/pull/28807 From asemenyuk at openjdk.org Fri Dec 12 23:46:04 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Dec 2025 23:46:04 GMT Subject: RFR: 8373628: jpackage doesn't print to console until completetion In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:09:22 GMT, Alexey Semenyuk wrote: > Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28807#issuecomment-3648524595 From weijun at openjdk.org Fri Dec 12 23:53:59 2025 From: weijun at openjdk.org (Weijun Wang) Date: Fri, 12 Dec 2025 23:53:59 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} > 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} > 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() Shall we translate "non-private" into Chinese? src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: > 1635: # 0: symbol, 1: file object > 1636: # lint: classfile > 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: > 249: doclet.filter_table_of_contents=???? > 250: doclet.filter_reset=?? > 251: doclet.sort_table_of_contents=???????????????? Seems incorrectly copied from line 244. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615834067 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615850080 PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2615854313 From asemenyuk at openjdk.org Fri Dec 12 23:56:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Dec 2025 23:56:08 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package Message-ID: - Add exception type as an additional generic parameter to all `Throwing...` interfaces - Add unit tests for "jdk.jpackage.internal.util.function" package - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach ------------- Commit messages: - Replace `ExceptionBox.rethrowUnchecked()` with `throw ExceptionBox.toUnchecked()`; remove ExceptionBox.rethrowUnchecked(). - ExceptionBox: add toUnchecked() and use it in all Throwing classes instead of ExceptionBox.rethrowUnchecked(). This change results in 100% coverage for these classes in the unit tests. Add unit tests. Add ExceptionBox.reachedUnreachable(). - Throwing: make these classes generic; don't catch Throwable-s, catch Exception-s instead and let Error-s out. Changes: https://git.openjdk.org/jdk/pull/28731/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373631 Stats: 713 lines in 52 files changed: 476 ins; 27 del; 210 mod Patch: https://git.openjdk.org/jdk/pull/28731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28731/head:pull/28731 PR: https://git.openjdk.org/jdk/pull/28731 From asemenyuk at openjdk.org Fri Dec 12 23:56:09 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 12 Dec 2025 23:56:09 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package In-Reply-To: References: Message-ID: <2YHoE1fGcQJOdoJYdjbpjR4DKKB9VI443yd-AFToY_4=.a4825518-b1be-4ba0-a81c-3c0bcbc0d840@github.com> On Wed, 10 Dec 2025 01:33:36 GMT, Alexey Semenyuk wrote: > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28731#issuecomment-3648540321 From almatvee at openjdk.org Sat Dec 13 01:07:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 13 Dec 2025 01:07:53 GMT Subject: RFR: 8373628: jpackage doesn't print to console until completetion In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:09:22 GMT, Alexey Semenyuk wrote: > Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java line 74: > 72: PrintWriter outWriter = new PrintWriter(out, true); > 73: PrintWriter errWriter = new PrintWriter(err, true); > 74: try { Looks good, but why we need two `try` blocks? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28807#discussion_r2615933489 From vlivanov at openjdk.org Sat Dec 13 01:23:56 2025 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Sat, 13 Dec 2025 01:23:56 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... Good work, Xiaohong! Can you, please, include samples of machine code generated before/after the patch (for AVX2 and AVX512)? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3648697712 From asemenyuk at openjdk.org Sat Dec 13 01:51:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 13 Dec 2025 01:51:50 GMT Subject: RFR: 8373628: jpackage doesn't print to console until completetion In-Reply-To: References: Message-ID: On Sat, 13 Dec 2025 01:04:52 GMT, Alexander Matveev wrote: >> Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/Main.java line 74: > >> 72: PrintWriter outWriter = new PrintWriter(out, true); >> 73: PrintWriter errWriter = new PrintWriter(err, true); >> 74: try { > > Looks good, but why we need two `try` blocks? To guarantee that both `PrintWriter`-s will be flushed. If we do try { return run(...); } finally { outWriter.flush(); errWriter.flush(); } `errWriter.flush()` will not be called if `outWriter.flush()` throws. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28807#discussion_r2615976964 From almatvee at openjdk.org Sat Dec 13 02:41:50 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 13 Dec 2025 02:41:50 GMT Subject: RFR: 8373628: jpackage doesn't print to console until completetion In-Reply-To: References: Message-ID: <8QrB4TyBXqoqpeGnmfAuL_zwXBohldp_vc2gTf8AM8I=.e4aa77df-af1f-48f5-b8f5-fc6cc3bc5cf6@github.com> On Fri, 12 Dec 2025 22:09:22 GMT, Alexey Semenyuk wrote: > Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28807#pullrequestreview-3574105985 From asemenyuk at openjdk.org Sat Dec 13 02:57:00 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 13 Dec 2025 02:57:00 GMT Subject: Integrated: 8373628: jpackage doesn't print to console until completetion In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:09:22 GMT, Alexey Semenyuk wrote: > Make jpackage ToolProvider implementation implement `ToolProvider#run(PrintStream, PrintStream, String)` method such that it passes `PrintWriter` objects with auto-flush enabled into `ToolProvider#run(PrintWriter, PrintWriter, String)` call. This pull request has now been integrated. Changeset: 17744fbf Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/17744fbfc004dfed5a3e959cd9ac7e7081b5be7a Stats: 20 lines in 1 file changed: 20 ins; 0 del; 0 mod 8373628: jpackage doesn't print to console until completetion Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28807 From asemenyuk at openjdk.org Sat Dec 13 04:01:51 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 13 Dec 2025 04:01:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change Marked as reviewed by asemenyuk (Reviewer). jpackage changes look good: all keys are in place and translated. Can't comment on translations, though. I don't speak any of these languages. ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3574161659 PR Comment: https://git.openjdk.org/jdk/pull/28802#issuecomment-3648886796 From dl at openjdk.org Sat Dec 13 14:55:52 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 13 Dec 2025 14:55:52 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 12 Dec 2025 23:00:29 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1434: >> >>> 1432: final int topLevelExec(ForkJoinTask task, WorkQueue q, >>> 1433: int fifo, int qbase) { >>> 1434: int stolen = 1; >> >> @DougLea It does seem a bit weird that stolen starts as 1 even if "task == null" (i.e. this method would return 1 for an invocation where task or q is null, which doesn't sounds right?) > > On the other hand, `t` is never null, and `q` is never null, so I'll just suggest a small comment below. Or less oddly, now prefaced with if (task == null || q == null) return 0; // currently impossible I also added some javadoc and comments and cosmetics ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2616349996 From dl at openjdk.org Sat Dec 13 15:29:27 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 13 Dec 2025 15:29:27 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v2] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 five additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Address review comments - signalWork diagnostic - filter by index - For testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/094d7d75..357a3cb7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=00-01 Stats: 16878 lines in 265 files changed: 10735 ins; 4003 del; 2140 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 dl at openjdk.org Sat Dec 13 15:29:29 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 13 Dec 2025 15:29:29 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v2] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 12 Dec 2025 23:05:48 GMT, Viktor Klang wrote: >> 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 five additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Address review comments >> - signalWork diagnostic >> - filter by index >> - For testing > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1468: > >> 1466: ForkJoinTask t; int qcap; long qk; >> 1467: ForkJoinTask[] qa = q.array; >> 1468: if (q.base != qbase || qa == null || (qcap = qa.length) <= 0 || > > Seems like a negative array length would be problematic in general, so simplifying to a 0-check here? > > Suggestion: > > if (q.base != qbase || qa == null || (qcap = qa.length) == 0 || C1 used to not know that lengths are nonnegative, so I always do it this way. Probably needlessly but doesn't hurt. > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1471: > >> 1469: (t = (ForkJoinTask)U.getReferenceAcquire( >> 1470: qa, qk = slotOffset((qcap - 1) & qbase))) == null || >> 1471: q.base != qbase || > > Is this (repeated) check intended? (i.e. are we worried about q.base drift between polling the array?) Yes, needed (everywhere) to avoid bad CASes in rare cases (like array wraparound). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2616363243 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2616364228 From dl at openjdk.org Sat Dec 13 18:57:29 2025 From: dl at openjdk.org (Doug Lea) Date: Sat, 13 Dec 2025 18:57:29 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v3] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <8-aDwblVBTZqotX5Fvjd40eUaZCmeO__k0WBq9_u1Ws=.ad5fc694-962e-46c6-bf91-d6807600c946@github.com> > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Revert topLevelExec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/357a3cb7..685a3ebb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=01-02 Stats: 55 lines in 1 file changed: 1 ins; 49 del; 5 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 asemenyuk at openjdk.org Sun Dec 14 05:08:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sun, 14 Dec 2025 05:08:52 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v2] In-Reply-To: References: Message-ID: > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: TKit: fix missing test execution summary if some tests fail ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28731/files - new: https://git.openjdk.org/jdk/pull/28731/files/715c5ac5..c56b5350 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28731/head:pull/28731 PR: https://git.openjdk.org/jdk/pull/28731 From smqy2314 at gmail.com Sun Dec 14 08:45:02 2025 From: smqy2314 at gmail.com (Memory) Date: Sun, 14 Dec 2025 16:45:02 +0800 Subject: Question about potential optimization for Year.isLeap() Message-ID: Hello core-libs-dev team, My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: **Current logic:** ```java return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); ``` **Proposed optimization:** ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` **Key improvements:** - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 - Reduces modulo operations from 3 to 1 in the common case **Verification benchmark:** ```java public static void main(String[] args) { int[] years = new int[1_000_000_000]; Random random = new Random(); for (int i = 0; i < years.length; i++) { years[i] = 1970 + random.nextInt(5000 - 1970 + 1); } long start1 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOriginal(year); } System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); long start2 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOptimized(year); } System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); } public static boolean isLeapOriginal(long year) { return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; } public static boolean isLeapOptimized(long year) { return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); } ``` **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? Thank you for your time and consideration. Best regards, Memory2314 -------------- next part -------------- An HTML attachment was scrubbed... URL: From raffaello.giulietti at oracle.com Sun Dec 14 11:45:18 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Sun, 14 Dec 2025 11:45:18 +0000 Subject: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: Hi, the current logic in mainline is ``` return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` (see https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321) ________________________________________ From: core-libs-dev on behalf of Memory Sent: Sunday, December 14, 2025 09:45 To: core-libs-dev at openjdk.org Subject: Question about potential optimization for Year.isLeap() Hello core-libs-dev team, My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: **Current logic:** ```java return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); ``` **Proposed optimization:** ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` **Key improvements:** - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 - Reduces modulo operations from 3 to 1 in the common case **Verification benchmark:** ```java public static void main(String[] args) { int[] years = new int[1_000_000_000]; Random random = new Random(); for (int i = 0; i < years.length; i++) { years[i] = 1970 + random.nextInt(5000 - 1970 + 1); } long start1 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOriginal(year); } System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); long start2 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOptimized(year); } System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); } public static boolean isLeapOriginal(long year) { return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; } public static boolean isLeapOptimized(long year) { return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); } ``` **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? Thank you for your time and consideration. Best regards, Memory2314 From dl at openjdk.org Sun Dec 14 12:28:28 2025 From: dl at openjdk.org (Doug Lea) Date: Sun, 14 Dec 2025 12:28:28 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v4] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Reorder signalWork filter ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/685a3ebb..e3f012fc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=02-03 Stats: 5 lines in 1 file changed: 2 ins; 2 del; 1 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 dl at openjdk.org Sun Dec 14 13:06:46 2025 From: dl at openjdk.org (Doug Lea) Date: Sun, 14 Dec 2025 13:06:46 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Adjust runworker for previous update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/e3f012fc..76dd5ddd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 smqy2314 at gmail.com Sun Dec 14 17:23:59 2025 From: smqy2314 at gmail.com (Memory) Date: Mon, 15 Dec 2025 01:23:59 +0800 Subject: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: Hi, Thanks for the correction. I confused the implementations. I'm proposing to change: ```java return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` to: ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` At the low level, this should be slightly faster because: 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation 2. Better for branch prediction - Simpler control flow pattern 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. Raffaello Giulietti ? 2025?12?14??? 19:45??? > Hi, > > the current logic in mainline is > ``` > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && > year % 100 != 0; > ``` > (see > https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321 > ) > > > ________________________________________ > From: core-libs-dev on behalf of Memory < > smqy2314 at gmail.com> > Sent: Sunday, December 14, 2025 09:45 > To: core-libs-dev at openjdk.org > Subject: Question about potential optimization for Year.isLeap() > > Hello core-libs-dev team, > > My name is Memory2314, and I am a new contributor currently waiting for my > Oracle Contributor Agreement (OCA) to be processed. > > I have been studying the `java.time.Year.isLeap()` method and would like > to propose a micro-optimization: > > **Current logic:** > ```java > return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); > ``` > > **Proposed optimization:** > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > **Key improvements:** > - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` > - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 > - Reduces modulo operations from 3 to 1 in the common case > > **Verification benchmark:** > ```java > public static void main(String[] args) { > int[] years = new int[1_000_000_000]; > Random random = new Random(); > for (int i = 0; i < years.length; i++) { > years[i] = 1970 + random.nextInt(5000 - 1970 + 1); > } > > long start1 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOriginal(year); > } > System.out.println("Original: " + (System.currentTimeMillis()-start1) > + "ms"); > > long start2 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOptimized(year); > } > System.out.println("Optimized: " + (System.currentTimeMillis()-start2) > + "ms"); > } > > public static boolean isLeapOriginal(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % > 100 != 0; > } > > public static boolean isLeapOptimized(long year) { > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > } > ``` > > **Correctness verification:** I've tested this logic extensively, > including edge cases like year 0, negative years (proleptic Gregorian), and > all century boundaries from -10,000 to 10,000. > > I am aware that I cannot submit a formal patch until my OCA is complete. > However, I would be very grateful for your initial technical feedback on > this approach before I proceed to create a fully tested patch with > benchmarks. > > Once my OCA is in place, would there be a maintainer or an experienced > contributor interested in sponsoring this change if it proves worthwhile? > > Thank you for your time and consideration. > > Best regards, > Memory2314 > -------------- next part -------------- An HTML attachment was scrubbed... URL: From syan at openjdk.org Mon Dec 15 02:35:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 02:35:51 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. Looking for 2rd reviewer, since this PR touch files in hotspot directory? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3652648703 From erfang at openjdk.org Mon Dec 15 02:39:52 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 02:39:52 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... Thanks for your review ! @eme64 ------------- PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3576179654 From erfang at openjdk.org Mon Dec 15 02:39:54 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 02:39:54 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, 12 Dec 2025 15:10:29 GMT, Emanuel Peter wrote: >> 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*`? Hi @eme64 thanks for your review. Here the design is as follows: 1. Any node can be used as the input to this function. 2. If the input node `n` is not a `VectorMaskCastNode`, then return `n` itself. The advantage of this is that we don't need to check whether the parameter `n` is a `VectorNode` when calling `uncast_mask`. This check is necessary, for example, `n` might be a `PhiNode`, which is not a `VectorNode`. Actually, this function could also be placed in the `Node` class, just like the `Node::uncast` function. However, I feel that this function is primarily used for vector nodes, and to avoid unnecessarily expanding its scope, I placed it in `VectorNode`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2617757865 From erfang at openjdk.org Mon Dec 15 02:39:58 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 02:39:58 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 15:12:37 GMT, Emanuel Peter wrote: >> 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` ch... > > 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? Yeah, done, thanks! > 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? There are currently no such counterexamples. Because now we require the length of `VectorMaskCastNode` to be consistent with the length of its input node. But I'm not sure whether this restriction will be lifted in the future, and this optimization requires the length to be the same. Because of this requirement, I added this check. Similarly, in `uncast_mask` I also did the following assert: `assert(n->as_Vector()->length() == in1->as_Vector()->length(), "vector length must match");` Do you think it would be better to change this condition to an assert? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2617758364 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2617770569 From erfang at openjdk.org Mon Dec 15 03:01:39 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 03:01:39 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] 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: Refine code comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28313/files - new: https://git.openjdk.org/jdk/pull/28313/files/a14cec2c..2ce36c8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=04-05 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 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 xgong at openjdk.org Mon Dec 15 03:13:54 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 15 Dec 2025 03:13:54 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 02:36:06 GMT, Eric Fang wrote: >> 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? > > There are currently no such counterexamples. Because now we require the length of `VectorMaskCastNode` to be consistent with the length of its input node. But I'm not sure whether this restriction will be lifted in the future, and this optimization requires the length to be the same. Because of this requirement, I added this check. Similarly, in `uncast_mask` I also did the following assert: > `assert(n->as_Vector()->length() == in1->as_Vector()->length(), "vector length must match");` > > Do you think it would be better to change this condition to an assert? Yeah, currently we might not have such a real case that the length is not matched, regardless whether there is mask casts inside the chain. At least I cannot find such a case in API level. Not sure whether such pattern will be generated by compiler itself in future due to some optimizations. As an optimization of `VectorStoreMask (VectorLoadMask vect) => vec`, we must make sure that the vector type before and after are exactly matched with each other. Consider both the basic element type of `VectorStoreMask` and the input of `VectorLoadMask` (i.e. the `vect`) are `boolean`, just checking the vector length is enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2617810466 From dholmes at openjdk.org Mon Dec 15 05:38:52 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 05:38:52 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. I'm unclear what you mean by some of the tests not working - are you saying those tests did not check the value of RETAIN_IMAGE_AFTER_TEST? Or that they never had it passed in - in which case why not? Where does it come from. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: > 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { > 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); > 255: } Pre-existing but indent is too big ------------- PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576429184 PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617997460 From dholmes at openjdk.org Mon Dec 15 05:38:53 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 05:38:53 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Mon, 15 Dec 2025 05:28:03 GMT, David Holmes wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: > >> 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { >> 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); >> 255: } > > Pre-existing but indent is too big You also need to document the fact the property is used to make this a no-op. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2617999664 From syan at openjdk.org Mon Dec 15 06:15:58 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:15:58 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Mon, 15 Dec 2025 05:35:45 GMT, David Holmes wrote: > RETAIN_IMAGE_AFTER_TEST Some tests did not check the value of the RETAIN_IMAGE_AFTER_TEST variable, causing the docker image to be deleted at the end of the test run even if the -DRETAIN_IMAGE_AFTER_TEST=true option was used when running those tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3653534316 From syan at openjdk.org Mon Dec 15 06:18:35 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:18:35 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Remove extra ident ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28208/files - new: https://git.openjdk.org/jdk/pull/28208/files/75356d0e..5e39c8f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208 PR: https://git.openjdk.org/jdk/pull/28208 From syan at openjdk.org Mon Dec 15 06:25:43 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:25:43 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - Merge branch 'openjdk:master' into jbs8371503 - Remove extra ident - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28208/files - new: https://git.openjdk.org/jdk/pull/28208/files/5e39c8f3..0bfbe8ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28208&range=01-02 Stats: 301873 lines in 2852 files changed: 201864 ins; 58740 del; 41269 mod Patch: https://git.openjdk.org/jdk/pull/28208.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28208/head:pull/28208 PR: https://git.openjdk.org/jdk/pull/28208 From syan at openjdk.org Mon Dec 15 06:31:52 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 06:31:52 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <_TW1mSrJRHz9EYzpiDbjXIPk4IexJ1bX53I8U0s_Ec8=.63403b1b-e590-428f-abb7-8e20861f307d@github.com> On Mon, 15 Dec 2025 05:29:16 GMT, David Holmes wrote: >> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 255: >> >>> 253: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { >>> 254: execute(Container.ENGINE_COMMAND, "rmi", "--force", imageNameAndTag); >>> 255: } >> >> Pre-existing but indent is too big > > You also need to document the fact the property is used to make this a no-op. > Pre-existing but indent is too big Fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28208#discussion_r2618130670 From jbhateja at openjdk.org Mon Dec 15 06:32:56 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 15 Dec 2025 06:32:56 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 03:01:39 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 incrementally with one additional commit since the last revision: > > Refine code comments src/hotspot/share/opto/vectornode.cpp line 1062: > 1060: if (!in1->isa_Vector()) { > 1061: break; > 1062: } Can you write a comment here, why you want to avoid handling masks of type TypeVectMask ? src/hotspot/share/opto/vectornode.cpp line 1063: > 1061: break; > 1062: } > 1063: assert(n->as_Vector()->length() == in1->as_Vector()->length(), "vector length must match"); While assertions are good to add, but mask cast is a lanewise operation, i.e. length compatibility is implied, and adding an assertion for IR invariants is redundant. test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 186: > 184: testThreeCastsKernel(IntVector.SPECIES_128, ShortVector.SPECIES_64, FloatVector.SPECIES_128, LongVector.SPECIES_256); > 185: verifyResult(IntVector.SPECIES_128.length()); > 186: } A nit, you can define final static species like S128, S64 pointing to fully qualified species, it will reduce the verbosity. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618083147 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618086953 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618109644 From dholmes at openjdk.org Mon Dec 15 06:47:59 2025 From: dholmes at openjdk.org (David Holmes) Date: Mon, 15 Dec 2025 06:47:59 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <6vq4NQJDnsQ_06T_1Tqfx8MmiNv2dAWYIet1OgDT1X8=.5789459a-ec8b-4bb0-8ab1-76120b28becd@github.com> On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8371503 > - Remove extra ident > - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Thanks - now it makes sense to me. ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576654982 From erfang at openjdk.org Mon Dec 15 06:57:56 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 06:57:56 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 03:01:39 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 incrementally with one additional commit since the last revision: > > Refine code comments Thanks for your review! @jatin-bhateja ------------- PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3576654397 From erfang at openjdk.org Mon Dec 15 06:58:01 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 06:58:01 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 06:09:26 GMT, Jatin Bhateja wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine code comments > > src/hotspot/share/opto/vectornode.cpp line 1062: > >> 1060: if (!in1->isa_Vector()) { >> 1061: break; >> 1062: } > > Can you write a comment here, why you want to avoid handling masks of type TypeVectMask ? Hi, @jatin-bhateja, I didn't quite understand what you meant. I'm not sure if you mistook `isa_Vector` for `isa_vectormask`. Checking `isa_Vector` here is to ensure that `in1` is a `VectorNode`, so that it calls the `as_Vector` function. > src/hotspot/share/opto/vectornode.cpp line 1063: > >> 1061: break; >> 1062: } >> 1063: assert(n->as_Vector()->length() == in1->as_Vector()->length(), "vector length must match"); > > While assertions are good to add, but mask cast is a lanewise operation, i.e. length compatibility is implied, and adding an assertion for IR invariants is redundant. My main concern here is that the requirement for `VectorMaskCastNode` to have the same length for both input and output might have been removed in the future. I'm not sure, but we do require the lengths to be the same here, so I added this assertion. @eme64 has a similar comment; see https://github.com/openjdk/jdk/pull/28313/changes#r2614577536. So, if you all think that the requirement for lane length in `VectorMaskCastNode` won't be removed, then we can delete this assertion and the condition below. > test/hotspot/jtreg/compiler/vectorapi/VectorStoreMaskIdentityTest.java line 186: > >> 184: testThreeCastsKernel(IntVector.SPECIES_128, ShortVector.SPECIES_64, FloatVector.SPECIES_128, LongVector.SPECIES_256); >> 185: verifyResult(IntVector.SPECIES_128.length()); >> 186: } > > A nit, you can define final static species like S128, S64 pointing to fully qualified species, it will reduce the verbosity. Make sense, I'll do the change in the next commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618171442 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618189379 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618195582 From jbhateja at openjdk.org Mon Dec 15 07:32:53 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 15 Dec 2025 07:32:53 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 06:45:18 GMT, Eric Fang wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine code comments > > src/hotspot/share/opto/vectornode.cpp line 1062: > >> 1060: if (!in1->isa_Vector()) { >> 1061: break; >> 1062: } > > Hi, @jatin-bhateja, I didn't quite understand what you meant. I'm not sure if you mistook `isa_Vector` for `isa_vectormask`. Checking `isa_Vector` here is to ensure that `in1` is a `VectorNode`, so that it calls the `as_Vector` function. I am seeing a different behaviour b/w UseAVX=2 and UseAVX=3 following kernel. public static final VectorSpecies FSP = FloatVector.SPECIES_PREFERRED; public static long micro(long ctr) { VectorMask mask = VectorMask.fromLong(FSP, 15); return mask.toLong(); } TURIN>java --add-modules=jdk.incubator.vector -XX:UseAVX=3 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=PrintIdealPhase,testmcast::micro,BEFORE_MATCHIN G -cp . testmcast CompileCommand: PrintIdealPhase testmcast.micro const char* PrintIdealPhase = 'BEFORE_MATCHING' AFTER: BEFORE_MATCHING 0 Root === 0 368 [[ 0 1 3 25 ]] inner 3 Start === 3 0 [[ 3 5 6 7 8 9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:long, 6:half} 5 Parm === 3 [[ 368 ]] Control !jvms: testmcast::micro @ bci:-1 (line 9) 6 Parm === 3 [[ 368 ]] I_O !jvms: testmcast::micro @ bci:-1 (line 9) 7 Parm === 3 [[ 368 ]] Memory Memory: @ptr:BotPTR+bot, idx=Bot; !jvms: testmcast::micro @ bci:-1 (line 9) 8 Parm === 3 [[ 368 ]] FramePtr !jvms: testmcast::micro @ bci:-1 (line 9) 9 Parm === 3 [[ 368 ]] ReturnAdr !jvms: testmcast::micro @ bci:-1 (line 9) 25 ConL === 0 [[ 376 ]] #long:15 368 Return === 5 6 7 8 9 returns 398 [[ 0 ]] 376 VectorLongToMask === _ 25 [[ 397 ]] #vectormask !jvms: VectorMask::fromLong @ bci:39 (line 243) testmcast::micro @ bci:6 (line 9) 397 VectorMaskCast === _ 376 [[ 398 ]] #vectormask !jvms: Float512Vector$Float512Mask::toLong @ bci:35 (line 765) testmcast::micro @ bci:11 (line 10) 398 VectorMaskToLong === _ 397 [[ 368 ]] #long !jvms: Float512Vector$Float512Mask::toLong @ bci:35 (line 765) testmcast::micro @ bci:11 (line 10) [time] 17ms [res] 300000000 TURIN>java --add-modules=jdk.incubator.vector -XX:UseAVX=2 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=PrintIdealPhase,testmcast::micro,BEFORE_MATCHIN G -cp . testmcast CompileCommand: PrintIdealPhase testmcast.micro const char* PrintIdealPhase = 'BEFORE_MATCHING' AFTER: BEFORE_MATCHING 0 Root === 0 368 [[ 0 1 3 25 ]] inner 3 Start === 3 0 [[ 3 5 6 7 8 9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:long, 6:half} 5 Parm === 3 [[ 368 ]] Control !jvms: testmcast::micro @ bci:-1 (line 9) 6 Parm === 3 [[ 368 ]] I_O !jvms: testmcast::micro @ bci:-1 (line 9) 7 Parm === 3 [[ 368 ]] Memory Memory: @ptr:BotPTR+bot, idx=Bot; !jvms: testmcast::micro @ bci:-1 (line 9) 8 Parm === 3 [[ 368 ]] FramePtr !jvms: testmcast::micro @ bci:-1 (line 9) 9 Parm === 3 [[ 368 ]] ReturnAdr !jvms: testmcast::micro @ bci:-1 (line 9) 25 ConL === 0 [[ 368 ]] #long:15 368 Return === 5 6 7 8 9 returns 25 [[ 0 ]] [time] 9ms [res] 300000000 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618289402 From jbhateja at openjdk.org Mon Dec 15 07:40:53 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 15 Dec 2025 07:40:53 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 06:52:22 GMT, Eric Fang wrote: >> src/hotspot/share/opto/vectornode.cpp line 1063: >> >>> 1061: break; >>> 1062: } >>> 1063: assert(n->as_Vector()->length() == in1->as_Vector()->length(), "vector length must match"); >> >> While assertions are good to add, but mask cast is a lanewise operation, i.e. length compatibility is implied, and adding an assertion for IR invariants is redundant. > > My main concern here is that the requirement for `VectorMaskCastNode` to have the same length for both input and output might have been removed in the future. I'm not sure, but we do require the lengths to be the same here, so I added this assertion. @eme64 has a similar comment; see https://github.com/openjdk/jdk/pull/28313/changes#r2614577536. So, if you all think that the requirement for lane length in `VectorMaskCastNode` won't be removed, then we can delete this assertion and the condition below. I think assertion here is redundant. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618311660 From erfang at openjdk.org Mon Dec 15 07:59:54 2025 From: erfang at openjdk.org (Eric Fang) Date: Mon, 15 Dec 2025 07:59:54 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 07:30:10 GMT, Jatin Bhateja wrote: >> src/hotspot/share/opto/vectornode.cpp line 1062: >> >>> 1060: if (!in1->isa_Vector()) { >>> 1061: break; >>> 1062: } >> >> Hi, @jatin-bhateja, I didn't quite understand what you meant. I'm not sure if you mistook `isa_Vector` for `isa_vectormask`. Checking `isa_Vector` here is to ensure that `in1` is a `VectorNode`, so that it calls the `as_Vector` function. > > Correct, I am seeing a different behaviour b/w UseAVX=2 and UseAVX=3 for following kernel. Not related to your new code but due to other sideeffect. kindly have a look. > > > public static final VectorSpecies FSP = FloatVector.SPECIES_PREFERRED; > > public static long micro(long ctr) { > VectorMask mask = VectorMask.fromLong(FSP, 15); > return mask.toLong(); > } > > > TURIN>java --add-modules=jdk.incubator.vector -XX:UseAVX=3 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=PrintIdealPhase,testmcast::micro,BEFORE_MATCHIN > G -cp . testmcast > CompileCommand: PrintIdealPhase testmcast.micro const char* PrintIdealPhase = 'BEFORE_MATCHING' > AFTER: BEFORE_MATCHING > 0 Root === 0 368 [[ 0 1 3 25 ]] inner > 3 Start === 3 0 [[ 3 5 6 7 8 9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:long, 6:half} > 5 Parm === 3 [[ 368 ]] Control !jvms: testmcast::micro @ bci:-1 (line 9) > 6 Parm === 3 [[ 368 ]] I_O !jvms: testmcast::micro @ bci:-1 (line 9) > 7 Parm === 3 [[ 368 ]] Memory Memory: @ptr:BotPTR+bot, idx=Bot; !jvms: testmcast::micro @ bci:-1 (line 9) > 8 Parm === 3 [[ 368 ]] FramePtr !jvms: testmcast::micro @ bci:-1 (line 9) > 9 Parm === 3 [[ 368 ]] ReturnAdr !jvms: testmcast::micro @ bci:-1 (line 9) > 25 ConL === 0 [[ 376 ]] #long:15 > 368 Return === 5 6 7 8 9 returns 398 [[ 0 ]] > 376 VectorLongToMask === _ 25 [[ 397 ]] #vectormask !jvms: VectorMask::fromLong @ bci:39 (line 243) testmcast::micro @ bci:6 (line 9) > 397 VectorMaskCast === _ 376 [[ 398 ]] #vectormask !jvms: Float512Vector$Float512Mask::toLong @ bci:35 (line 765) testmcast::micro @ bci:11 (line 10) > 398 VectorMaskToLong === _ 397 [[ 368 ]] #long !jvms: Float512Vector$Float512Mask::toLong @ bci:35 (line 765) testmcast::micro @ bci:11 (line 10) > [time] 17ms [res] 300000000 > TURIN>java --add-modules=jdk.incubator.vector -XX:UseAVX=2 -Xbatch -XX:-TieredCompilation -XX:CompileCommand=PrintIdealPhase,testmcast::micro,BEFORE_MATCHIN > G -cp . testmcast > CompileCommand: PrintIdealPhase testmcast.micro const char* PrintIdealPhase = 'BEFORE_MATCHING' > AFTER: BEFORE_MATCHING > 0 Root === 0 368 [[ 0 1 3 25 ]] inner > 3 Start === 3 0 [[ 3 5 6 7 8 9 ]] #{0:control, 1:abIO, 2:memory, 3:rawptr:BotPTR, 4:return_address, 5:long, 6:half} > 5 Parm === 3 [[ 368 ]] Control !jvms: testmcast::micro @ bci:-1 (line 9) > 6 Parm === 3 [[ 368 ]] I_O !jvms: testmcast::micro @ bci:-1 (line 9) > 7 Parm === 3 [[ 368 ]] Memory ... This is caused by the different IRs when using AVX2 and AVX3. - With AVX3 the generated IRs are: `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x)))` - With AVX2 the generated IRs are: `(VectorMaskToLong (VectorStoreMask (VectorMaskCast (VectorLoadMask VectorLongToMask x)))))` We have supported the following optimizations: - `(VectorStoreMask (VectorMaskCast (VectorLoadMask x))) => (x)` and - `(VectorMaskToLong (VectorLongToMask x)) => (x)`. So with AVX2, `(VectorMaskToLong (VectorStoreMask (VectorMaskCast (VectorLoadMask VectorLongToMask x))))) => (x)` `(VectorMaskToLong (VectorMaskCast (VectorLongToMask x))) => (x)` is a potential optimization, I have mentioned this in the commit message. But now we have not supported it yet. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2618369569 From lmesnik at openjdk.org Mon Dec 15 08:00:58 2025 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Mon, 15 Dec 2025 08:00:58 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> On Mon, 15 Dec 2025 06:25:43 GMT, SendaoYan wrote: >> Hi all, >> >> The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. >> >> This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. >> >> Change has been verified locally on linux-x64 by run the all touched tests. > > SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: > > - Merge branch 'openjdk:master' into jbs8371503 > - Remove extra ident > - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Marked as reviewed by lmesnik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28208#pullrequestreview-3576911752 From xgong at openjdk.org Mon Dec 15 08:36:51 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 15 Dec 2025 08:36:51 GMT Subject: RFR: 8372136: VectorAPI: Refactor subword gather load API java implementation In-Reply-To: References: Message-ID: On Sat, 13 Dec 2025 01:21:14 GMT, Vladimir Ivanov wrote: > Good work, Xiaohong! > Thanks so much for your review! > Can you, please, include samples of machine code generated before/after the patch (for AVX2 and AVX512)? Sure. The generated code has no difference for cases that just need **1 gather load**. For cases that need **2/4 times** of gather loads, the main differences come from the **duplicate initializing instructions** before iterations of 8B gather loads (which could be optimized in future), and the additional code generated for **vector slice and merging**. Following is an example of loading a `Short256Vector` under `-XX:UseAVX=2`, which needs 2 times of gather loads. The corresponding Java code is: private static final VectorSpecies S_SPECIES = ShortVector.SPECIES_PREFERRED; static void gather_short() { for (int i = 0; i < LENGTH; i += S_SPECIES.length()) { ShortVector.fromArray(S_SPECIES, sa, i, index, i) .intoArray(sr, i); } } static void gather_short_masked() { VectorMask mask = VectorMask.fromArray(S_SPECIES, m, 0); for (int i = 0; i < LENGTH; i += S_SPECIES.length()) { ShortVector.fromArray(S_SPECIES, sa, i, index, i, mask) .intoArray(sr, i); } } Here is the kernel code generated **without** this patch: 0x00007a0e8c06ecb0: vmovd %r9d,%xmm1 0x00007a0e8c06ecb5: lea 0x10(%rbx,%rsi,2),%r14 0x00007a0e8c06ecba: mov %r13,%r8 0x00007a0e8c06ecbd: mov $0x10,%r9d 0x00007a0e8c06ecc3: vpxor %ymm5,%ymm5,%ymm5 0x00007a0e8c06ecc7: vpxor %ymm4,%ymm4,%ymm4 0x00007a0e8c06eccb: vpcmpeqd %ymm6,%ymm6,%ymm6 0x00007a0e8c06eccf: vpsubd %ymm6,%ymm5,%ymm6 0x00007a0e8c06ecd3: vpslld $0x1,%ymm6,%ymm6 0x00007a0e8c06ecd8: vmovdqu 0x41020(%rip),%ymm5 # Stub::Stub Generator vector_iota_indices_stub+128 0x00007a0e8c0afd00 ; {external_word} 0x00007a0e8c06ece0: vpxor %ymm3,%ymm3,%ymm3 0x00007a0e8c06ece4: mov (%r8),%r11d 0x00007a0e8c06ece7: vpinsrw $0x0,(%r14,%r11,2),%xmm3,%xmm3 0x00007a0e8c06ecee: mov 0x4(%r8),%r11d 0x00007a0e8c06ecf2: vpinsrw $0x1,(%r14,%r11,2),%xmm3,%xmm3 0x00007a0e8c06ecf9: mov 0x8(%r8),%r11d 0x00007a0e8c06ecfd: vpinsrw $0x2,(%r14,%r11,2),%xmm3,%xmm3 0x00007a0e8c06ed04: mov 0xc(%r8),%r11d 0x00007a0e8c06ed08: vpinsrw $0x3,(%r14,%r11,2),%xmm3,%xmm3 0x00007a0e8c06ed0f: vpermd %ymm3,%ymm5,%ymm3 0x00007a0e8c06ed14: vpsubd %ymm6,%ymm5,%ymm5 0x00007a0e8c06ed18: vpor %ymm3,%ymm4,%ymm4 0x00007a0e8c06ed1c: add $0x10,%r8 0x00007a0e8c06ed20: sub $0x4,%r9d 0x00007a0e8c06ed24: jne 0x00007a0e8c06ece0 0x00007a0e8c06ed26: vmovdqu %ymm4,0x10(%rbp,%rsi,2) And here is the kernel code generated **with** this patch: 0x000070118c06a033: vmovd %edi,%xmm5 0x000070118c06a037: vmovq %rbp,%xmm3 0x000070118c06a03c: vmovd %ecx,%xmm2 0x000070118c06a040: mov %r9d,(%rsp) 0x000070118c06a044: lea 0x10(%rsi,%r10,2),%r14 # start of the second gather_load operation 0x000070118c06a049: mov %r11,%rbp 0x000070118c06a04c: mov $0x8,%ecx 0x000070118c06a051: vpxor %xmm4,%xmm4,%xmm4 0x000070118c06a055: vpxor %xmm10,%xmm10,%xmm10 0x000070118c06a05a: vpcmpeqd %xmm11,%xmm11,%xmm11 0x000070118c06a05f: vpsubd %xmm11,%xmm4,%xmm11 0x000070118c06a064: vpslld $0x1,%xmm11,%xmm11 0x000070118c06a06a: vmovdqu 0x45cgt8e(%rip),%xmm4 # Stub::Stub Generator vector_iota_indices_stub+128 0x000070118c0afd00 ; {external_word} 0x000070118c06a072: vpxor %xmm6,%xmm6,%xmm6 0x000070118c06a076: mov 0x0(%rbp),%edi 0x000070118c06a079: vpinsrw $0x0,(%r14,%rdi,2),%xmm6,%xmm6 0x000070118c06a080: mov 0x4(%rbp),%edi 0x000070118c06a083: vpinsrw $0x1,(%r14,%rdi,2),%xmm6,%xmm6 0x000070118c06a08a: mov 0x8(%rbp),%edi 0x000070118c06a08d: vpinsrw $0x2,(%r14,%rdi,2),%xmm6,%xmm6 0x000070118c06a094: mov 0xc(%rbp),%edi 0x000070118c06a097: vpinsrw $0x3,(%r14,%rdi,2),%xmm6,%xmm6 0x000070118c06a09e: vpermd %ymm6,%ymm4,%ymm6 0x000070118c06a0a3: vpsubd %xmm11,%xmm4,%xmm4 0x000070118c06a0a8: vpor %xmm6,%xmm10,%xmm10 0x000070118c06a0ac: add $0x10,%rbp 0x000070118c06a0b0: sub $0x4,%ecx 0x000070118c06a0b3: jne 0x000070118c06a072 0x000070118c06a0b5: vmovdqu %xmm10,%xmm4 # vector reinterpret, the end of second gather_load 0x000070118c06a0ba: vperm2i128 $0x21,%ymm4,%ymm9,%ymm6 # vector slice 0x000070118c06a0c0: lea 0x10(%rsi,%r10,2),%r11 # start of the first gather_load operation 0x000070118c06a0c5: mov %rax,%rcx 0x000070118c06a0c8: mov $0x8,%r8d 0x000070118c06a0ce: vpxor %xmm10,%xmm10,%xmm10 0x000070118c06a0d3: vpxor %xmm4,%xmm4,%xmm4 0x000070118c06a0d7: vpcmpeqd %xmm13,%xmm13,%xmm13 0x000070118c06a0dc: vpsubd %xmm13,%xmm10,%xmm13 0x000070118c06a0e1: vpslld $0x1,%xmm13,%xmm13 0x000070118c06a0e7: vmovdqu 0x45c11(%rip),%xmm10 # Stub::Stub Generator vector_iota_indices_stub+128 0x000070118c0afd00 ; {external_word} 0x000070118c06a0ef: vpxor %xmm12,%xmm12,%xmm12 0x000070118c06a0f4: mov (%rcx),%r9d 0x000070118c06a0f7: vpinsrw $0x0,(%r11,%r9,2),%xmm12,%xmm12 0x000070118c06a0fe: mov 0x4(%rcx),%r9d 0x000070118c06a102: vpinsrw $0x1,(%r11,%r9,2),%xmm12,%xmm12 0x000070118c06a109: mov 0x8(%rcx),%r9d 0x000070118c06a10d: vpinsrw $0x2,(%r11,%r9,2),%xmm12,%xmm12 0x000070118c06a114: mov 0xc(%rcx),%r9d 0x000070118c06a118: vpinsrw $0x3,(%r11,%r9,2),%xmm12,%xmm12 0x000070118c06a11f: vpermd %ymm12,%ymm10,%ymm12 0x000070118c06a124: vpsubd %xmm13,%xmm10,%xmm10 0x000070118c06a129: vpor %xmm12,%xmm4,%xmm4 0x000070118c06a12e: add $0x10,%rcx 0x000070118c06a132: sub $0x4,%r8d 0x000070118c06a136: jne 0x000070118c06a0ef 0x000070118c06a138: vmovdqu %xmm4,%xmm4 ; vector reinterpret, the end of the first gather_load 0x000070118c06a13c: vpor %ymm6,%ymm4,%ymm4 ; final merge 0x000070118c06a140: vmovq %xmm3,%r11 0x000070118c06a145: vmovdqu %ymm4,0x10(%r11,%r10,2) ;*invokestatic store {reexecute=0 rethrow=0 return_oop=0} ; - jdk.incubator.vector.ShortVector::intoArray at 44 (line 3514) ; - VectorAPITest::gather_short at 38 (line 116) For the masked cases, besides additional added instructions, there are more code generated for the **mask slice** operations. I also attached the full code for kinds of cases. Please kindly share your feedback. Thanks a lot! [avx2_short_max_after.txt](https://github.com/user-attachments/files/24160578/avx2_short_max_after.txt) [avx2_short_max_before.txt](https://github.com/user-attachments/files/24160581/avx2_short_max_before.txt) [avx3_short_max_before.txt](https://github.com/user-attachments/files/24160582/avx3_short_max_before.txt) [avx3_short_max_after.txt](https://github.com/user-attachments/files/24160584/avx3_short_max_after.txt) [avx3_short_max_masked_after.txt](https://github.com/user-attachments/files/24160638/avx3_short_max_masked_after.txt) [avx3_short_max_masked_before.txt](https://github.com/user-attachments/files/24160644/avx3_short_max_masked_before.txt) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28520#issuecomment-3654421400 From vklang at openjdk.org Mon Dec 15 10:01:12 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 15 Dec 2025 10:01:12 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 14 Dec 2025 13:06:46 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Adjust runworker for previous update src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1881: > 1879: else > 1880: nc = (v.stackPred & LMASK) | (c & TC_MASK) | ac; > 1881: if (c == (c = compareAndExchangeCtl(c, nc))) { I think the risk here is that this introduces more cache-coordination contention, esp. on multisocket aarch64. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2618743184 From vklang at openjdk.org Mon Dec 15 10:21:33 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 15 Dec 2025 10:21:33 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 14 Dec 2025 13:06:46 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Adjust runworker for previous update src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1892: > 1890: } > 1891: if (q != null && q.base - qbase > 0) > 1892: break; Crazy idea: Only create new workers on successful CAS if no queue-drift has occurred, but always prioritize to wake up sleeping workers regardless? Suggestion: if (v != null) { v.phase = sp; if (v.parking != 0) U.unpark(v.owner); } else if (q == null || q.base - qbase == 0) createWorker(); break; } if (q != null && q.base - qbase > 0) break; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2618808997 From aefimov at openjdk.org Mon Dec 15 10:27:45 2025 From: aefimov at openjdk.org (Aleksei Efimov) Date: Mon, 15 Dec 2025 10:27:45 GMT Subject: RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message [v2] In-Reply-To: References: Message-ID: <5ZPGGEjV9nh7xIzuGgPPYsntuSuqdGlDdN8oTdmbd-k=.e7e6c174-2a83-45c2-ae0f-674aa7187e9d@github.com> On Tue, 9 Dec 2025 16:03:15 GMT, Jaikiran Pai wrote: >> 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.n... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fail if InitialDirContext() construction completes normally Nice clean up of the exception handling code. Looks good to me! ------------- Marked as reviewed by aefimov (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28725#pullrequestreview-3577449822 From vklang at openjdk.org Mon Dec 15 10:54:36 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 15 Dec 2025 10:54:36 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Mon, 15 Dec 2025 10:19:09 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust runworker for previous update > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1892: > >> 1890: } >> 1891: if (q != null && q.base - qbase > 0) >> 1892: break; > > Crazy idea: Only create new workers on successful CAS if no queue-drift has occurred, but always prioritize to wake up sleeping workers regardless? > > Suggestion: > > if (v != null) { > v.phase = sp; > if (v.parking != 0) > U.unpark(v.owner); > } else if (q == null || q.base - qbase == 0) > createWorker(); > > break; > } > if (q != null && q.base - qbase > 0) > break; Narrator: Turns out it was crazy, as it requires a back-out of nc. Disregard the comment above :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2618919162 From raffaello.giulietti at oracle.com Mon Dec 15 11:32:13 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 15 Dec 2025 11:32:13 +0000 Subject: [External] : Re: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: In OpenJDK we use the JMH framework to measure performance. See the documentation in https://github.com/openjdk/jmh https://github.com/openjdk/jdk/blob/master/doc/testing.md and search for "microbenchmark" You can find some samples in https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples In OpenJDK itself, you can find real world usage of JMH in https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench Once you are ready to use JMH, on the mailing list you can then provide the JMH results comparing the "before change" and "after change" figures. Hope this helps ________________________________________ From: Memory Sent: Sunday, December 14, 2025 18:23 To: Raffaello Giulietti Cc: core-libs-dev at openjdk.org Subject: [External] : Re: Question about potential optimization for Year.isLeap() Hi, Thanks for the correction. I confused the implementations. I'm proposing to change: ```java return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` to: ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` At the low level, this should be slightly faster because: 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation 2. Better for branch prediction - Simpler control flow pattern 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. Raffaello Giulietti > ? 2025?12?14??? 19:45??? Hi, the current logic in mainline is ``` return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` (see https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321) ________________________________________ From: core-libs-dev > on behalf of Memory > Sent: Sunday, December 14, 2025 09:45 To: core-libs-dev at openjdk.org Subject: Question about potential optimization for Year.isLeap() Hello core-libs-dev team, My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: **Current logic:** ```java return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); ``` **Proposed optimization:** ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` **Key improvements:** - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 - Reduces modulo operations from 3 to 1 in the common case **Verification benchmark:** ```java public static void main(String[] args) { int[] years = new int[1_000_000_000]; Random random = new Random(); for (int i = 0; i < years.length; i++) { years[i] = 1970 + random.nextInt(5000 - 1970 + 1); } long start1 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOriginal(year); } System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); long start2 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOptimized(year); } System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); } public static boolean isLeapOriginal(long year) { return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; } public static boolean isLeapOptimized(long year) { return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); } ``` **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? Thank you for your time and consideration. Best regards, Memory2314 From vklang at openjdk.org Mon Dec 15 11:34:41 2025 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 15 Dec 2025 11:34:41 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 14 Dec 2025 13:06:46 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Adjust runworker for previous update src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1865: > 1863: long ac = (c + RC_UNIT) & RC_MASK, nc; > 1864: int sp = (int)c, i = sp & SMASK; > 1865: if ((short)(c >>> RC_SHIFT) >= pc) I'm wondering if it might make sense to re-read `parallelism` on each new loop, since if we have a parallelism resize *during this loop* we want to exit early? Suggestion: for (long c = ctl;;) { WorkQueue[] qs = queues; long ac = (c + RC_UNIT) & RC_MASK, nc; int sp = (int)c, i = sp & SMASK, pc; if ((short)(c >>> RC_SHIFT) >= (pc = parallelism)) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2619038375 From cushon at openjdk.org Mon Dec 15 11:35:41 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 15 Dec 2025 11:35:41 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v15] In-Reply-To: References: Message-ID: > This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content. > > This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest > > > byte[] bytes = new byte[length]; > MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length); > return new String(bytes, charset); > > > However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy. > > See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html) > > Benchmark results: > > > Benchmark (size) Mode Cnt Score Error Units > ToJavaStringTest.jni_readString 5 avgt 30 55.339 ? 0.401 ns/op > ToJavaStringTest.jni_readString 20 avgt 30 59.887 ? 0.295 ns/op > ToJavaStringTest.jni_readString 100 avgt 30 84.288 ? 0.419 ns/op > ToJavaStringTest.jni_readString 200 avgt 30 119.275 ? 0.496 ns/op > ToJavaStringTest.jni_readString 451 avgt 30 193.106 ? 1.528 ns/op > ToJavaStringTest.panama_copyLength 5 avgt 30 7.348 ? 0.048 ns/op > ToJavaStringTest.panama_copyLength 20 avgt 30 7.440 ? 0.125 ns/op > ToJavaStringTest.panama_copyLength 100 avgt 30 11.766 ? 0.058 ns/op > ToJavaStringTest.panama_copyLength 200 avgt 30 16.096 ? 0.089 ns/op > ToJavaStringTest.panama_copyLength 451 avgt 30 25.844 ? 0.054 ns/op > ToJavaStringTest.panama_readString 5 avgt 30 5.857 ? 0.046 ns/op > ToJavaStringTest.panama_readString 20 avgt 30 7.750 ? 0.046 ns/op > ToJavaStringTest.panama_readString 100 avgt 30 14.109 ? 0.187 ns/op > ToJavaStringTest.panama_readString 200 avgt 30 18.035 ? 0.130 ns/op > ToJavaStringTest.panama_readString 451 avgt 30 35.896 ? 0.227 ns/op > ToJavaStringTest.panama_readStringLength 5 avgt 30 4.565 ? 0.038 ns/op > ToJavaStringTest.panama_readStringLength 20 avgt 30 4.654 ? 0.040 ns/op > ToJavaStringTest.panama_readString... Liam Miller-Cushon 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 20 additional commits since the last revision: - Rename the parameter of getString from length to byteLength - Merge branch 'master' into JDK-8369564 - Review feedback - Update discussion of truncated reads of strings containing \0 - Return the number of copied bytes - More javadoc updates - Use Utils.checkNonNegativeArgument - Review feedback * handle numChars + srcIndex overflow, and add tests * replace yen with a character that round trips - Improve test coverage, and more fixes - Review feedback * document assertion to link to bytesCompatible * throw IAE for length > Integer.MAX_VALUE * javadoc fixes - ... and 10 more: https://git.openjdk.org/jdk/compare/f328b875...229ffa01 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28043/files - new: https://git.openjdk.org/jdk/pull/28043/files/6065acd8..229ffa01 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=13-14 Stats: 129196 lines in 1978 files changed: 84829 ins; 32115 del; 12252 mod Patch: https://git.openjdk.org/jdk/pull/28043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28043/head:pull/28043 PR: https://git.openjdk.org/jdk/pull/28043 From cushon at openjdk.org Mon Dec 15 11:35:43 2025 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 15 Dec 2025 11:35:43 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v14] In-Reply-To: References: Message-ID: <9jxz0W_HByW5_v6DJfatEohDuJ8xFsWlsOFvV5WUlOw=.58917e57-a1b4-400f-862a-b105b2467792@github.com> On Tue, 25 Nov 2025 19:10:25 GMT, Liam Miller-Cushon wrote: >> This PR proposes adding a new overload to `MemorySegment::getString` that takes a known byte length of the content. >> >> This was previously proposed in https://github.com/openjdk/jdk/pull/20725, but the outcome of [JDK-8333843](https://bugs.openjdk.org/browse/JDK-8333843) was to update `MemorySegment#getString` to suggest >> >> >> byte[] bytes = new byte[length]; >> MemorySegment.copy(segment, JAVA_BYTE, offset, bytes, 0, length); >> return new String(bytes, charset); >> >> >> However this is less efficient than what the implementation of getString does after [JDK-8362893](https://bugs.openjdk.org/browse/JDK-8362893), it now uses `JavaLangAccess::uncheckedNewStringNoRepl` to avoid the copy. >> >> See also discussion in [this panama-dev@ thread](https://mail.openjdk.org/pipermail/panama-dev/2025-November/021193.html), and mcimadamore's document [Pulling the (foreign) string](https://cr.openjdk.org/~mcimadamore/panama/strings_ffm.html) >> >> Benchmark results: >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ToJavaStringTest.jni_readString 5 avgt 30 55.339 ? 0.401 ns/op >> ToJavaStringTest.jni_readString 20 avgt 30 59.887 ? 0.295 ns/op >> ToJavaStringTest.jni_readString 100 avgt 30 84.288 ? 0.419 ns/op >> ToJavaStringTest.jni_readString 200 avgt 30 119.275 ? 0.496 ns/op >> ToJavaStringTest.jni_readString 451 avgt 30 193.106 ? 1.528 ns/op >> ToJavaStringTest.panama_copyLength 5 avgt 30 7.348 ? 0.048 ns/op >> ToJavaStringTest.panama_copyLength 20 avgt 30 7.440 ? 0.125 ns/op >> ToJavaStringTest.panama_copyLength 100 avgt 30 11.766 ? 0.058 ns/op >> ToJavaStringTest.panama_copyLength 200 avgt 30 16.096 ? 0.089 ns/op >> ToJavaStringTest.panama_copyLength 451 avgt 30 25.844 ? 0.054 ns/op >> ToJavaStringTest.panama_readString 5 avgt 30 5.857 ? 0.046 ns/op >> ToJavaStringTest.panama_readString 20 avgt 30 7.750 ? 0.046 ns/op >> ToJavaStringTest.panama_readString 100 avgt 30 14.109 ? 0.187 ns/op >> ToJavaStringTest.panama_readString 200 avgt 30 18.035 ? 0.130 ns/op >> ToJavaStringTest.panama_readString 451 avgt 30 35.896 ? 0.227 ns/op >> ToJavaStringTest.panama_readStringLength 5 avgt 30 4.565 ? 0.038 ns/op >> ToJavaStringTest.panama_readStringLength 20... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback I have tentatively renamed the parameter of `getString` from `length` to `byteLength`, in response to discussion in [the CSR](https://bugs.openjdk.org/browse/JDK-8372338) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3655136484 From mcimadamore at openjdk.org Mon Dec 15 11:50:22 2025 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 15 Dec 2025 11:50:22 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v14] In-Reply-To: <9jxz0W_HByW5_v6DJfatEohDuJ8xFsWlsOFvV5WUlOw=.58917e57-a1b4-400f-862a-b105b2467792@github.com> References: <9jxz0W_HByW5_v6DJfatEohDuJ8xFsWlsOFvV5WUlOw=.58917e57-a1b4-400f-862a-b105b2467792@github.com> Message-ID: On Mon, 15 Dec 2025 11:29:45 GMT, Liam Miller-Cushon wrote: > I have tentatively renamed the parameter of `getString` from `length` to `byteLength`, in response to discussion in [the CSR](https://bugs.openjdk.org/browse/JDK-8372338) sensible move ------------- PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3655200342 From alanb at openjdk.org Mon Dec 15 11:52:24 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Dec 2025 11:52:24 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v5] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Mon, 15 Dec 2025 11:32:00 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Adjust runworker for previous update > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1865: > >> 1863: long ac = (c + RC_UNIT) & RC_MASK, nc; >> 1864: int sp = (int)c, i = sp & SMASK; >> 1865: if ((short)(c >>> RC_SHIFT) >= pc) > > I'm wondering if it might make sense to re-read `parallelism` on each new loop, since if we have a parallelism resize *during this loop* we want to exit early? > > > Suggestion: > > for (long c = ctl;;) { > WorkQueue[] qs = queues; > long ac = (c + RC_UNIT) & RC_MASK, nc; > int sp = (int)c, i = sp & SMASK, pc; > if ((short)(c >>> RC_SHIFT) >= (pc = parallelism)) Maybe but it should also be rare to adjust parallelism, and setParallelism changed recently to signal. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2619087486 From jnorlinder at openjdk.org Mon Dec 15 12:19:26 2025 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 15 Dec 2025 12:19:26 GMT Subject: RFR: 8373647: Avoid unnecessary fstat when opening file for write Message-ID: # Background When Java applications uses APIs like java.io.FileOutputStream it will hook into native implementations in e.g. io_util_md.c for Unix/Linux. Java does not allow reading a directory and the implementation reflect this fact. For Unix there are three access modes O_RDONLY, O_WRONLY, O_RDWR. Moreover, on Unix it is possible to read a directory and an extra check has been added in the code to ensure that the user is trying to read a file (with O_RDONLY) and not a directory. This extra check results in an additional syscall. This check is actually redundant in case user are using access mode O_WRONLY or O_RDWR. If one is trying to call open on a directory with these modes the specification in Unix and Linux specifies that EISDIR shall be returned. For the case of Unix standard it has been part of the standard at least since 1997 (https://pubs.opengroup.org/onlinepubs/007908799/xsh/open.html) and Linux since at least 2004 (see v 2.0 https://www.kernel.org/pub/linux/docs/man-pages/Archive/ ) to return error if user is trying to write to an directory. In OpenJDK we also include AIX and they are certified to follow the Unix standard (https://www.opengroup.org/openbrand/register/ibm.htm). I believe that it is therefore safe to assume that this is a well implemented aspect of the Unix standard by now and that this technical debt can be eliminated (assuming that this check was indeed needed at some point). # Performance Improvements A stress-test that opens a huge amount of files to trigger a syscall storm reveals that a removal of this redundant syscall may also improve performance during high load: JDK 27 baseline Benchmark Mode Cnt Score Error Units FileWriteStress.test sample 8438452 3722.451 ? 2.402 ns/op JDK 27 patched Benchmark Mode Cnt Score Error Units FileWriteStress.test sample 4952304 3191.912 ? 4.011 ns/op ~17% performance boost. ------------- Commit messages: - Fix copyright year - Add microbenchmark - Proper access mode reading - Add O_RDONLY check Changes: https://git.openjdk.org/jdk/pull/28823/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373647 Stats: 75 lines in 2 files changed: 63 ins; 0 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28823.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28823/head:pull/28823 PR: https://git.openjdk.org/jdk/pull/28823 From jpai at openjdk.org Mon Dec 15 13:39:31 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Dec 2025 13:39:31 GMT Subject: RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message [v2] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 16:03:15 GMT, Jaikiran Pai wrote: >> 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.n... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > fail if InitialDirContext() construction completes normally Thank you Aleksei for the review. I ran another round of CI testing with this change against latest master branch and it continues to pass. I also considered if we should change this test from testng to junit in this PR, but since this test uses the `LdapTimeoutTest.assertCompletion` (which resides in a separate test), then such a change would require a much bigger refactoring to the other `LdapTimeoutTest` test too. So I'll leave out that effort to a subsequent PR in future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28725#issuecomment-3655684334 From jpai at openjdk.org Mon Dec 15 13:39:34 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 15 Dec 2025 13:39:34 GMT Subject: Integrated: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 15:49:36 GMT, Jaikiran Pai wrote: > 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... This pull request has now been integrated. Changeset: 1f47294c Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/1f47294cd336db34030ea16132490ab51310ace5 Stats: 64 lines in 1 file changed: 28 ins; 13 del; 23 mod 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message Reviewed-by: aefimov ------------- PR: https://git.openjdk.org/jdk/pull/28725 From syan at openjdk.org Mon Dec 15 14:21:44 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:21:44 GMT Subject: RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v3] In-Reply-To: <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> <0RKPJughffV_BK27e8yiXUZ_yPhtq136QfeAdTp47Pk=.d1e09b89-06d9-47de-98b1-5bad8225aaa1@github.com> Message-ID: On Mon, 15 Dec 2025 07:58:35 GMT, Leonid Mesnik wrote: >> SendaoYan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into jbs8371503 >> - Remove extra ident >> - 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests > > Marked as reviewed by lmesnik (Reviewer). Thanks for the reviews @lmesnik @dholmes-ora ------------- PR Comment: https://git.openjdk.org/jdk/pull/28208#issuecomment-3655876260 From syan at openjdk.org Mon Dec 15 14:21:46 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:21:46 GMT Subject: Integrated: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> References: <7kEYqfoRzlpl7vu5PbOXazM0R9E4NTu57jBH7jVSty4=.ca25f1a2-fb52-4e1b-b7b8-bd81493bc594@github.com> Message-ID: On Sat, 8 Nov 2025 08:10:45 GMT, SendaoYan wrote: > Hi all, > > The DockerTestUtils.RETAIN_IMAGE_AFTER_TEST variable which read the property from "jdk.test.docker.retain.image" do not work for some of the docker tests, such as jdk/internal/platform/docker/TestDockerCpuMetrics.java, only works for some of the docker tests, such as jdk/internal/platform/docker/TestPidsLimit.java. > > This PR read the DockerTestUtils.RETAIN_IMAGE_AFTER_TEST inside function removeDockerImage instead of before all the fucntion removeDockerImage. This will make all the docker tests receive the property jdk.test.docker.retain.image. > > Change has been verified locally on linux-x64 by run the all touched tests. This pull request has now been integrated. Changeset: 34f24131 Author: SendaoYan URL: https://git.openjdk.org/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c Stats: 32 lines in 11 files changed: 2 ins; 20 del; 10 mod 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Reviewed-by: lmesnik, dholmes ------------- PR: https://git.openjdk.org/jdk/pull/28208 From syan at openjdk.org Mon Dec 15 14:39:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 15 Dec 2025 14:39:51 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests Message-ID: Hi all, This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. Thanks! ------------- Commit messages: - Backport 34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c Changes: https://git.openjdk.org/jdk/pull/28826/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371503 Stats: 32 lines in 11 files changed: 2 ins; 20 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28826/head:pull/28826 PR: https://git.openjdk.org/jdk/pull/28826 From duke at openjdk.org Mon Dec 15 15:59:26 2025 From: duke at openjdk.org (Yi Wu) Date: Mon, 15 Dec 2025 15:59:26 GMT Subject: RFR: 8373344: Add support for FP16 min/max reduction operations Message-ID: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> This patch adds mid-end support for vectorized min/max reduction operations for half floats. It also includes backend AArch64 support for these operations. Both floating point min/max reductions don?t require strict order, because they are associative. It will generate NEON fminv/fmaxv reduction instructions when max vector length is 8B or 16B. On SVE supporting machines with vector lengths > 16B, it will generate the SVE fminv/fmaxv instructions. The patch also adds support for partial min/max reductions on SVE machines using fminv/fmaxv. Ratio of throughput(ops/ms) > 1 indicates the performance with this patch is better than the mainline. Neoverse N1 (UseSVE = 0, max vector length = 16B): Benchmark vectorDim Mode Cnt 8B 16B ReductionMaxFP16 256 thrpt 9 3.69 6.44 ReductionMaxFP16 512 thrpt 9 3.71 7.62 ReductionMaxFP16 1024 thrpt 9 4.16 8.64 ReductionMaxFP16 2048 thrpt 9 4.44 9.12 ReductionMinFP16 256 thrpt 9 3.69 6.43 ReductionMinFP16 512 thrpt 9 3.70 7.62 ReductionMinFP16 1024 thrpt 9 4.16 8.64 ReductionMinFP16 2048 thrpt 9 4.44 9.10 Neoverse V1 (UseSVE = 1, max vector length = 32B): Benchmark vectorDim Mode Cnt 8B 16B 32B ReductionMaxFP16 256 thrpt 9 3.96 8.62 8.02 ReductionMaxFP16 512 thrpt 9 3.54 9.25 11.71 ReductionMaxFP16 1024 thrpt 9 3.77 8.71 14.07 ReductionMaxFP16 2048 thrpt 9 3.88 8.44 14.69 ReductionMinFP16 256 thrpt 9 3.96 8.61 8.03 ReductionMinFP16 512 thrpt 9 3.54 9.28 11.69 ReductionMinFP16 1024 thrpt 9 3.76 8.70 14.12 ReductionMinFP16 2048 thrpt 9 3.87 8.45 14.70 Neoverse V2 (UseSVE = 2, max vector length = 16B): Benchmark vectorDim Mode Cnt 8B 16B ReductionMaxFP16 256 thrpt 9 4.78 10.00 ReductionMaxFP16 512 thrpt 9 3.74 11.33 ReductionMaxFP16 1024 thrpt 9 3.86 9.59 ReductionMaxFP16 2048 thrpt 9 3.94 8.71 ReductionMinFP16 256 thrpt 9 4.78 10.00 ReductionMinFP16 512 thrpt 9 3.74 11.29 ReductionMinFP16 1024 thrpt 9 3.86 9.58 ReductionMinFP16 2048 thrpt 9 3.94 8.71 Testing: hotspot_all, jdk (tier1-3) and langtools (tier1) all pass on Neoverse N1/V1/V2. ------------- Commit messages: - 8373344: Add support for FP16 min/max reduction operations Changes: https://git.openjdk.org/jdk/pull/28828/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28828&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373344 Stats: 968 lines in 13 files changed: 296 ins; 22 del; 650 mod Patch: https://git.openjdk.org/jdk/pull/28828.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28828/head:pull/28828 PR: https://git.openjdk.org/jdk/pull/28828 From liach at openjdk.org Mon Dec 15 16:04:10 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 16:04:10 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance [v5] 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: Stage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28684/files - new: https://git.openjdk.org/jdk/pull/28684/files/8dc4e31e..215055b0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28684&range=03-04 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 dl at openjdk.org Mon Dec 15 16:24:46 2025 From: dl at openjdk.org (Doug Lea) Date: Mon, 15 Dec 2025 16:24:46 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v6] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Reduce fencing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/76dd5ddd..61adb1dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=04-05 Stats: 45 lines in 1 file changed: 29 ins; 1 del; 15 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 liach at openjdk.org Mon Dec 15 17:10:24 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 17:10:24 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v10] 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 20 additional commits since the last revision: - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Stage - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - 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 - ... and 10 more: https://git.openjdk.org/jdk/compare/f5945cc1...f9d808c1 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/d734e8a6..f9d808c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=08-09 Stats: 19890 lines in 378 files changed: 12699 ins; 4700 del; 2491 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 Mon Dec 15 17:31:20 2025 From: duke at openjdk.org (Benjamin Peterson) Date: Mon, 15 Dec 2025 17:31:20 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v10] In-Reply-To: References: Message-ID: > Deep in the bowels of `System.loadLibrary`, `File.getCanonicalPath()` is called on the target library file before it is passed to the system library loading APIs. In JDK-8003887, `File.getCanonicalPath` was altered to resolve symlinks on Windows. This had unintended consequences for passing a symlink to `System.loadLibrary` on Windows. The underlying Windows `LoadLibrary` API inspects the file name passed to it and adds a `.dll` extension if the it is not already present. Thus, if `System.loadLibrary` was given a symlink to a file and that file didn't have a `.dll` extension, `LoadLibrary` try to load nonexistent file and fail. > > Fix this problem by appending a `.` to library paths in Windows' `os::dll_load`. This trailing dot inhibits `LoadLibrary`'s own appending behavior. Benjamin Peterson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits: - Merge branch 'master' into nativelibraries-fix - add test showing loading symlinked libraries with various combinations - revert dll_load fix - Merge branch 'master' into nativelibraries-fix - add cast - use os::malloc - Merge branch 'master' into nativelibraries-fix - fix compilation - fix grammar - add dot in os::dll_load rather than NativeLibraries.java - ... and 6 more: https://git.openjdk.org/jdk/compare/ad29642d...d03535ce ------------- Changes: https://git.openjdk.org/jdk/pull/24694/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24694&range=09 Stats: 92 lines in 2 files changed: 92 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24694.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24694/head:pull/24694 PR: https://git.openjdk.org/jdk/pull/24694 From liach at openjdk.org Mon Dec 15 17:44:49 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 17:44:49 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v11] In-Reply-To: References: Message-ID: <4UBpAWbg2PlNeJ9-Wr4AvehrdVb8C8BYdoXfptvPI1o=.b92c5a06-6da9-4fe0-ab02-47c5a2126020@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: Missed IR test review, rearrange benches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/f9d808c1..1d5461db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=09-10 Stats: 109 lines in 4 files changed: 89 ins; 11 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 liach at openjdk.org Mon Dec 15 17:44:52 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 17:44:52 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v10] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 17:10: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 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 20 additional commits since the last revision: > > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Stage > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - 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 > - ... and 10 more: https://git.openjdk.org/jdk/compare/faea2335...f9d808c1 Since I just noticed the actual cause of the failure of caching is that AD is created per name+type combination, I have created a benchmark case for that instead of reusing the existing exact ones: Benchmark Mode Cnt Score Error Units VarHandleTypeMismatch.exactInvocation avgt 30 0.396 ? 0.009 ns/op VarHandleTypeMismatch.genericInvocation avgt 30 0.375 ? 0.009 ns/op VarHandleTypeMismatch.pollutedInvocation avgt 30 8.281 ? 0.222 ns/op ------------- PR Comment: https://git.openjdk.org/jdk/pull/28585#issuecomment-3656852491 From liach at openjdk.org Mon Dec 15 17:44:54 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 17:44:54 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:13:23 GMT, Vladimir Ivanov wrote: >> 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. I have diagnosed the reason, updated the comments, and added a benchmark to showcase this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2620294345 From naoto at openjdk.org Mon Dec 15 18:15:44 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 15 Dec 2025 18:15:44 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v4] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: <0HGVn99AGEgpbFtSDpr-hinuAjKRuLKd1MBTpwirBpE=.5fd6a2f5-24a8-4f02-867b-2871e8c4aad1@github.com> On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > use SHORT.ordinal() Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3579535320 From liach at openjdk.org Mon Dec 15 18:29:08 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 18:29:08 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v4] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: <2fT9Wn3Bf-0oq_2U989AifJ3125-JTmriX5JeHYKNa4=.51351e46-6edf-49c9-abed-0e0c14b9e4ea@github.com> On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > use SHORT.ordinal() Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3579582217 From naoto.sato at oracle.com Mon Dec 15 18:31:24 2025 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 15 Dec 2025 10:31:24 -0800 Subject: [External] : Re: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: <37015c1b-83d7-4ea8-9d1d-7b4b7638b186@oracle.com> +1 for JMH experiment. I would like to see how it would improve in real use cases. Naoto On 12/15/25 3:32 AM, Raffaello Giulietti wrote: > In OpenJDK we use the JMH framework to measure performance. > > See the documentation in > https://github.com/openjdk/jmh > https://github.com/openjdk/jdk/blob/master/doc/testing.md and search for "microbenchmark" > > You can find some samples in > https://github.com/openjdk/jmh/tree/master/jmh-samples/src/main/java/org/openjdk/jmh/samples > > In OpenJDK itself, you can find real world usage of JMH in > https://github.com/openjdk/jdk/tree/master/test/micro/org/openjdk/bench > > Once you are ready to use JMH, on the mailing list you can then provide the JMH results comparing the "before change" and "after change" figures. > > Hope this helps > > > ________________________________________ > From: Memory > Sent: Sunday, December 14, 2025 18:23 > To: Raffaello Giulietti > Cc: core-libs-dev at openjdk.org > Subject: [External] : Re: Question about potential optimization for Year.isLeap() > > Hi, > > Thanks for the correction. I confused the implementations. > > I'm proposing to change: > > ```java > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > ``` > > to: > > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > At the low level, this should be slightly faster because: > > 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation > 2. Better for branch prediction - Simpler control flow pattern > 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case > > However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. > > Raffaello Giulietti > ? 2025?12?14??? 19:45??? > Hi, > > the current logic in mainline is > ``` > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > ``` > (see https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321) > > > ________________________________________ > From: core-libs-dev > on behalf of Memory > > Sent: Sunday, December 14, 2025 09:45 > To: core-libs-dev at openjdk.org > Subject: Question about potential optimization for Year.isLeap() > > Hello core-libs-dev team, > > My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. > > I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: > > **Current logic:** > ```java > return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); > ``` > > **Proposed optimization:** > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > **Key improvements:** > - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` > - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 > - Reduces modulo operations from 3 to 1 in the common case > > **Verification benchmark:** > ```java > public static void main(String[] args) { > int[] years = new int[1_000_000_000]; > Random random = new Random(); > for (int i = 0; i < years.length; i++) { > years[i] = 1970 + random.nextInt(5000 - 1970 + 1); > } > > long start1 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOriginal(year); > } > System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); > > long start2 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOptimized(year); > } > System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); > } > > public static boolean isLeapOriginal(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > public static boolean isLeapOptimized(long year) { > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > } > ``` > > **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. > > I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. > > Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? > > Thank you for your time and consideration. > > Best regards, > Memory2314 From jlu at openjdk.org Mon Dec 15 18:45:27 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 18:45:27 GMT Subject: RFR: 8373623: Refactor Serialization tests for Records to JUnit In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:38:16 GMT, Roger Riggs wrote: > Refactor TestNG tests to JUnit under the umbrella initiative of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843). > Fairly straight-forward mapping of annotations between the frameworks with some accommodations for differences in the Assert support. Did not spot any issues with the refactoring. ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28804#pullrequestreview-3579630820 From dnguyen at openjdk.org Mon Dec 15 18:57:21 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 18:57:21 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:39:10 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: > >> 249: doclet.filter_table_of_contents=???? >> 250: doclet.filter_reset=?? >> 251: doclet.sort_table_of_contents=???????????????? > > Seems incorrectly copied from line 244. This was what I got back from the translation team. When looking at the English file's changes, the two values are "Sort member details lexicographically" and "Sort member details in lexicographical order". Even though the wording is slightly different, these phrases mean the same thing, so the Chinese translation being the same makes sense to me. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620487307 From dnguyen at openjdk.org Mon Dec 15 19:04:38 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:04:38 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 23:35:29 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: > >> 1635: # 0: symbol, 1: file object >> 1636: # lint: classfile >> 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? > > I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620503781 From dnguyen at openjdk.org Mon Dec 15 19:08:26 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:08:26 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> On Fri, 12 Dec 2025 23:25:19 GMT, Weijun Wang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > >> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >> 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() > > Shall we translate "non-private" into Chinese? I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620512600 From henryjen at openjdk.org Mon Dec 15 19:23:47 2025 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 15 Dec 2025 19:23:47 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change jlink changes for zh_CN looks good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3579751484 From jlu at openjdk.org Mon Dec 15 19:23:51 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 19:23:51 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:05:31 GMT, Damon Nguyen wrote: >> src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: >> >>> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >>> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >>> 53: java.launcher.cls.error6=????? {0} ???? non-private ??????\n?????????? private???????\n public {0}() >> >> Shall we translate "non-private" into Chinese? > > I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620551384 From liach at openjdk.org Mon Dec 15 19:23:54 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:23:54 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> On Fri, 12 Dec 2025 22:34:10 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert Chinese preview change src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 295: > 293: > 294: # 0: symbol or name > 295: compiler.err.cant.ref.before.ctor.called=? {0} ???????????????? The original term "appear" is translated to "show" incorrectly. Google translate for single term "appear" recommends "??" which is more accurate. Same below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620524204 From liach at openjdk.org Mon Dec 15 19:23:58 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:23:58 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> On Mon, 15 Dec 2025 19:01:43 GMT, Damon Nguyen wrote: >> src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 1637: >> >>> 1635: # 0: symbol, 1: file object >>> 1636: # lint: classfile >>> 1637: compiler.warn.inconsistent.inner.classes={1} ? {0} ? InnerClasses ?????????\n??????? {0} ???? {1}? >> >> I am a little unsure of this. The English value has "({1} may need to be recompiled with {0})", which can be interpreted as "compiling 1 along with 0" but the Chinese translation sounds like "compiling 1 using 0". I tried to find where this is used but cannot. > > @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620532834 From weijun at openjdk.org Mon Dec 15 19:40:39 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:40:39 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> Message-ID: <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> On Mon, 15 Dec 2025 19:14:15 GMT, Chen Liang wrote: >> @liach Do you happen to know what the intent is here? I see you have reviewed this area before and I would appreciate the review. > > The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". > > Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. So the Chinese translation is still not precise and it should be something like "??"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620604434 From weijun at openjdk.org Mon Dec 15 19:40:42 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:40:42 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: Message-ID: <8YltPZBYyGhar7kqYOwbYElAKLTjMRXQNo9GUvUy0aM=.d6d3aba4-1f0b-4bad-a2d3-6881cfdceba6@github.com> On Mon, 15 Dec 2025 18:55:00 GMT, Damon Nguyen wrote: >> src/jdk.javadoc/share/classes/jdk/javadoc/internal/doclets/toolkit/resources/doclets_zh_CN.properties line 251: >> >>> 249: doclet.filter_table_of_contents=???? >>> 250: doclet.filter_reset=?? >>> 251: doclet.sort_table_of_contents=???????????????? >> >> Seems incorrectly copied from line 244. > > This was what I got back from the translation team. When looking at the English file's changes, the two values are "Sort member details lexicographically" and "Sort member details in lexicographical order". Even though the wording is slightly different, these phrases mean the same thing, so the Chinese translation being the same makes sense to me. Yes, you're right. I only noticed the key names are very different and thought the values should not be the same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620594909 From dnguyen at openjdk.org Mon Dec 15 19:46:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:46:17 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:20:44 GMT, Justin Lu wrote: >> I believe we should. I will submit this issue to the translation team and have it fixed in the next drop. > > I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). > > "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620616201 From weijun at openjdk.org Mon Dec 15 19:46:18 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 19:46:18 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:42:35 GMT, Damon Nguyen wrote: >> I don't see a reason why this change should occur since there was no corresponding change in the original file for this time frame. Is the change just reverting "non-private" and "private"? We might just spot revert this change here (and still notify the translation team). >> >> "`?????????????\n?????????? private`" might be better than the original translation, since `private` remains untranslated. Otherwise reverting back to the original is fine with me as well. > > Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! I guess someone has complained that the 2nd "private" should not be translated. The problem in this PR is that both "non-private" and "private" are back to English. I think the 2nd should not be translated but the 1st should, or, at least it can be written as "?private?. Keeping a "non-" in Chinese looks strange. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620619056 From dnguyen at openjdk.org Mon Dec 15 19:52:35 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 19:52:35 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: References: Message-ID: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Spot revert Chinese translation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/83100f94..1a5ebb91 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From liach at openjdk.org Mon Dec 15 19:52:37 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 19:52:37 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> Message-ID: <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> On Mon, 15 Dec 2025 19:37:45 GMT, Weijun Wang wrote: >> The intent is "{1} may need to be recompiled against the up-to-date {0} class-file dependency". >> >> Also the original English term is not exactly accurate - It should have been "InnerClasses attribute **entry** for {0} in {1} inconsistent with source code". An unfortunate miss there. > > So the Chinese translation is still not precise and it should be something like "??"? Uhh not quite... I don't know what's the translation term for recompile {1} with the latest {0} in classpath. So compiling {1} using {0} kind of makes sense. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620629526 From raffaello.giulietti at oracle.com Mon Dec 15 19:55:47 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Mon, 15 Dec 2025 19:55:47 +0000 Subject: [External] : Re: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: BTW, the variant below excluded 75% of the non-leap years with just one comparison: ``` return (year & 0x3) == 0 && ((year & 0xF) == 0 || year % 100 != 0) ``` ________________________________________ From: Memory Sent: Sunday, December 14, 2025 18:23 To: Raffaello Giulietti Cc: core-libs-dev at openjdk.org Subject: [External] : Re: Question about potential optimization for Year.isLeap() Hi, Thanks for the correction. I confused the implementations. I'm proposing to change: ```java return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` to: ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` At the low level, this should be slightly faster because: 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation 2. Better for branch prediction - Simpler control flow pattern 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. Raffaello Giulietti > ? 2025?12?14??? 19:45??? Hi, the current logic in mainline is ``` return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; ``` (see https://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321) ________________________________________ From: core-libs-dev > on behalf of Memory > Sent: Sunday, December 14, 2025 09:45 To: core-libs-dev at openjdk.org Subject: Question about potential optimization for Year.isLeap() Hello core-libs-dev team, My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: **Current logic:** ```java return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); ``` **Proposed optimization:** ```java return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); ``` **Key improvements:** - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 - Reduces modulo operations from 3 to 1 in the common case **Verification benchmark:** ```java public static void main(String[] args) { int[] years = new int[1_000_000_000]; Random random = new Random(); for (int i = 0; i < years.length; i++) { years[i] = 1970 + random.nextInt(5000 - 1970 + 1); } long start1 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOriginal(year); } System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); long start2 = System.currentTimeMillis(); for (int year : years) { boolean result = isLeapOptimized(year); } System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); } public static boolean isLeapOriginal(long year) { return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; } public static boolean isLeapOptimized(long year) { return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); } ``` **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? Thank you for your time and consideration. Best regards, Memory2314 From liach at openjdk.org Mon Dec 15 20:02:40 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 20:02:40 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments [v2] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 01:37:05 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. > > Trevor Bond has updated the pull request incrementally with one additional commit since the last revision: > > Clean up javadocs and address other review comments Looks fine. Please wait patiently for the CSR review. I have created the CSR. @asotona might help review it; but the CSR review lead will be on winter break, so you might need to wait till January. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28729#pullrequestreview-3579910365 PR Comment: https://git.openjdk.org/jdk/pull/28729#issuecomment-3657353934 From asemenyuk at openjdk.org Mon Dec 15 20:04:23 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 15 Dec 2025 20:04:23 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v3] In-Reply-To: References: Message-ID: > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: - Result: add unit tests, remove unused mapErrors(UnaryOperator>) function; better and more consistent error reporting based on testing - Result: replace create(Supplier) with of(ThrowingSupplier) - CustomInfoPListTest: fix local test failure: [22:38:21.786] TRACE: assertStringListEquals(): Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same [22:38:21.786] TRACE: assertStringListEquals( 1, /CFBundleDevelopmentRegion: en-US) [22:38:21.786] TRACE: assertStringListEquals( 2, /CFBundleExecutable: libjli.dylib) [22:38:21.786] TRACE: assertStringListEquals( 3, /CFBundleIdentifier: Hello) [22:38:21.787] TRACE: assertStringListEquals( 4, /CFBundleInfoDictionaryVersion: 7.0) [22:38:21.787] TRACE: assertStringListEquals( 5, /CFBundleName: PackageCustomInfoPListTest) [22:38:21.787] TRACE: assertStringListEquals( 6, /CFBundlePackageType: BNDL) [22:38:21.787] TRACE: assertStringListEquals( 7, /CFBundleShortVersionString: 1.0) [22:38:21.787] TRACE: assertStringListEquals( 8, /CFBundleSignature: ????) [22:38:21.787] TRACE: assertStringListEquals( 9, /CFBundleVersion: 1.0) [22:38:21.787] ERROR: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same [22:38:21.787] [ FAILED ] CustomInfoPListTest.testPackage(APP); checks=54 Exception in thread "main" java.lang.AssertionError: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same at jdk.jpackage.test.TKit.error(TKit.java:360) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:1068) at CustomInfoPListTest$TestConfig.lambda$createPListFilesVerifier$1(CustomInfoPListTest.java:274) at CustomInfoPListTest.lambda$testApp$9(CustomInfoPListTest.java:182) Caused by not getting the default plist file from the vanilla app image runtime directory when the external runtime with the "bin" subdirectory is used with the tests. Test log without the predefined runtime: ======================================== [22:35:26.310] Creating app package: PackageCustomInfoPListTest.app in jpackage-tests/CustomInfoPListTest/testPackage.571a7829/vanilla [22:35:26.318] Running jlink ... [22:35:29.430] Using default package resource ApplicationRuntime-Info.plist.template [Embedded Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize). Test log with the predefined runtime: ===================================== [22:38:17.465] Creating app package: PackageCustomInfoPListTest.app in jpackage-tests/CustomInfoPListTest/testPackage.571a7829/vanilla [22:38:17.605] Using default package resource Runtime-Info.plist.template [Embedded Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize). ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28731/files - new: https://git.openjdk.org/jdk/pull/28731/files/c56b5350..0a47251e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=01-02 Stats: 663 lines in 6 files changed: 640 ins; 11 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/28731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28731/head:pull/28731 PR: https://git.openjdk.org/jdk/pull/28731 From kfarrell at openjdk.org Mon Dec 15 20:13:44 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 15 Dec 2025 20:13:44 GMT Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID [v3] In-Reply-To: References: Message-ID: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> > Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: spec update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28435/files - new: https://git.openjdk.org/jdk/pull/28435/files/90f93860..20573f20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28435&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28435&range=01-02 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28435.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28435/head:pull/28435 PR: https://git.openjdk.org/jdk/pull/28435 From kfarrell at openjdk.org Mon Dec 15 20:13:45 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 15 Dec 2025 20:13:45 GMT Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID [v2] In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 11:03:43 GMT, Kieran Farrell wrote: >> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > spec update Apologies for the hold up I was OOO. I've pushed the update now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3657394563 From chen.l.liang at oracle.com Mon Dec 15 20:23:32 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 15 Dec 2025 20:23:32 +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: Hi Vincent, Thanks for the details. Our engineers have created a patch at https://github.com/openjdk/jdk/pull/28806. We seek to backport this to the 25 updates once this is merged. Ideally this would be part of update 25.0.3. Thank you again for this performance regression report! -Chen ________________________________ From: weigao Sent: Thursday, December 11, 2025 8:12 PM To: Chen Liang Cc: 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 , 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?C3.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 alanb at openjdk.org Mon Dec 15 20:32:49 2025 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 15 Dec 2025 20:32:49 GMT Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID [v3] In-Reply-To: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> References: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> Message-ID: <5ZL8f6NWG9WGwmhVCVPz2UV3kp3U063bwLHlNntCXzg=.2abbd2e2-a589-44aa-be54-bb3998d3da79@github.com> On Mon, 15 Dec 2025 20:13:44 GMT, Kieran Farrell wrote: >> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > spec update Good ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28435#pullrequestreview-3580017075 From liach at openjdk.org Mon Dec 15 20:35:39 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 20:35:39 GMT Subject: RFR: 8373552: ExactConversionsSupport: bad JLS links in javadoc In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 20:50:31 GMT, Aggelos Biboudis wrote: > Add relative links to the spec URL of primitive-types-in-patterns-instanceof-switch-jls.html Sure, this works. The original javadoc render is "See *Java Language Specification*:" but "See: JLS xxx" would work too. Ideally we would use something like a preview note, but this is now turned into [a JEP](https://openjdk.org/jeps/8363700) so a stopgap measure is better. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28775#pullrequestreview-3580028381 PR Comment: https://git.openjdk.org/jdk/pull/28775#issuecomment-3657482675 From weijun at openjdk.org Mon Dec 15 20:37:43 2025 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 15 Dec 2025 20:37:43 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> References: <0YsBpAfeZNmhzrtYthdcn9t-eScYEh1vd3fFMfPpgCQ=.4639ac8d-6736-4084-81cd-bd6933d4fd78@github.com> <6KlIqi_J9HjtMk-iU_A_6xZFpVVpAm12IOaKE_AE1a8=.3c22e23a-b9d3-41d5-af4a-f1a6098d3f3a@github.com> <_KVY1o8jncsmNAqFViGyvlxo08R-Y2Uw1y6U25E-Gb8=.0c9f2ffe-faf2-4dd7-81a5-546e3ddbeefe@github.com> Message-ID: On Mon, 15 Dec 2025 19:48:07 GMT, Chen Liang wrote: >> So the Chinese translation is still not precise and it should be something like "??"? > > Uhh not quite... I don't know what's the translation term for recompile {1} with the latest {0} in classpath. So compiling {1} using {0} kind of makes sense. OK, so the current translation is good enough. I have no more objection then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620758924 From duke at openjdk.org Mon Dec 15 20:39:27 2025 From: duke at openjdk.org (duke) Date: Mon, 15 Dec 2025 20:39:27 GMT Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID [v3] In-Reply-To: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> References: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> Message-ID: On Mon, 15 Dec 2025 20:13:44 GMT, Kieran Farrell wrote: >> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > spec update @kieran-farrell Your change (at version 20573f208102dc635974ac7ff79b006d1d644d2a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28435#issuecomment-3657499750 From aturbanov at openjdk.org Mon Dec 15 20:44:39 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 15 Dec 2025 20:44:39 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v4] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Fri, 12 Dec 2025 23:28:08 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > use SHORT.ordinal() src/java.base/share/classes/java/text/MessageFormat.java line 2004: > 2002: var styles = values(); > 2003: // Match starting at the pre-defined styles -> [SHORT:] > 2004: for (int i = SHORT.ordinal(); i < styles.length; i ++) { Suggestion: for (int i = SHORT.ordinal(); i < styles.length; i++) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28806#discussion_r2620785423 From rriggs at openjdk.org Mon Dec 15 20:45:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Dec 2025 20:45:53 GMT Subject: RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID [v3] In-Reply-To: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> References: <9HfgtW35Ui4myrStnAqXWlNwgacOsMzsXFBF_hMpyB4=.479d704b-fe50-466e-8abd-f42b1bb4fb21@github.com> Message-ID: On Mon, 15 Dec 2025 20:13:44 GMT, Kieran Farrell wrote: >> Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > spec update Looks good, thanks for the followup. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28435#pullrequestreview-3580080437 From kfarrell at openjdk.org Mon Dec 15 20:54:30 2025 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 15 Dec 2025 20:54:30 GMT Subject: Integrated: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID In-Reply-To: References: Message-ID: On Thu, 20 Nov 2025 16:07:36 GMT, Kieran Farrell wrote: > Replacing 'global identifier' with 'UUID' for consistancy in the spec as suggested during the review of JDK-8334015. This pull request has now been integrated. Changeset: 6aeabd4b Author: Kieran Farrell Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/6aeabd4bfaca168e9c88716b185979cf1e1b85ed Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID Reviewed-by: alanb, rriggs, jpai ------------- PR: https://git.openjdk.org/jdk/pull/28435 From almatvee at openjdk.org Mon Dec 15 21:10:16 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 15 Dec 2025 21:10:16 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 19:52:35 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Spot revert Chinese translation Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3580154697 From roger.riggs at oracle.com Mon Dec 15 21:11:25 2025 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 15 Dec 2025 16:11:25 -0500 Subject: [External] : Re: Question about potential optimization for Year.isLeap() In-Reply-To: References: Message-ID: Hi, Leap year computation is well trodden ground. You might find Ben Joffe's article interesting among others. There is also an amazing amount of optimization that occurs after the code is written and the compilation to different instruction sets is taken into account. Some hardware techniques that come into play are: ?- Branch prediction, in which the cpu pre-fetches both instruction paths and in some cases speculatively executes down both paths, making a late choice to pick the proper result. ?- Conditional assignments in which there is no branch, just a register load that is conditional on some previous condition. ?- etc... I'd expect to see different performance results on different architectures. (x64, aarch64, etc). Sometimes, its hard to pick which variant to leave in the source code. Frequently, a good compromise is to make sure the algorithm is correct and easy to understand and let the optimizer do its best. Regards, Roger On 12/15/25 2:55 PM, Raffaello Giulietti wrote: > BTW, the variant below excluded 75% of the non-leap years with just one comparison: > ``` > return (year & 0x3) == 0 && ((year & 0xF) == 0 || year % 100 != 0) > ``` > > > ________________________________________ > From: Memory > Sent: Sunday, December 14, 2025 18:23 > To: Raffaello Giulietti > Cc:core-libs-dev at openjdk.org > Subject: [External] : Re: Question about potential optimization for Year.isLeap() > > Hi, > > Thanks for the correction. I confused the implementations. > > I'm proposing to change: > > ```java > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > ``` > > to: > > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > At the low level, this should be slightly faster because: > > 1. Fewer CPU branches - Ternary creates a true branch, while logical operators use short-circuit evaluation > 2. Better for branch prediction - Simpler control flow pattern > 3. Less operation duplication - The current code conceptually checks (year & 3) == 0 twice in the false case > > However, I understand any performance difference would likely be minimal. If the team prefers the current ternary operator for better readability, I fully respect that decision. > > Raffaello Giulietti > ? 2025?12?14??? 19:45??? > Hi, > > the current logic in mainline is > ``` > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > ``` > (seehttps://github.com/openjdk/jdk/blob/fb531cdaf3b30034e0efa86b9b20558478ce94d0/src/java.base/share/classes/java/time/Year.java#L321) > > > ________________________________________ > From: core-libs-dev > on behalf of Memory > > Sent: Sunday, December 14, 2025 09:45 > To:core-libs-dev at openjdk.org > Subject: Question about potential optimization for Year.isLeap() > > Hello core-libs-dev team, > > My name is Memory2314, and I am a new contributor currently waiting for my Oracle Contributor Agreement (OCA) to be processed. > > I have been studying the `java.time.Year.isLeap()` method and would like to propose a micro-optimization: > > **Current logic:** > ```java > return (year % 4 == 0 && year % 100 != 0) || (year % 400 == 0); > ``` > > **Proposed optimization:** > ```java > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > ``` > > **Key improvements:** > - Replaces `year % 4 == 0` with bitwise `(year & 3) == 0` > - Uses `(year & 15) == 0` to efficiently detect years divisible by 400 > - Reduces modulo operations from 3 to 1 in the common case > > **Verification benchmark:** > ```java > public static void main(String[] args) { > int[] years = new int[1_000_000_000]; > Random random = new Random(); > for (int i = 0; i < years.length; i++) { > years[i] = 1970 + random.nextInt(5000 - 1970 + 1); > } > > long start1 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOriginal(year); > } > System.out.println("Original: " + (System.currentTimeMillis()-start1) + "ms"); > > long start2 = System.currentTimeMillis(); > for (int year : years) { > boolean result = isLeapOptimized(year); > } > System.out.println("Optimized: " + (System.currentTimeMillis()-start2) + "ms"); > } > > public static boolean isLeapOriginal(long year) { > return (year & 15) == 0 ? (year & 3) == 0 : (year & 3) == 0 && year % 100 != 0; > } > > public static boolean isLeapOptimized(long year) { > return (year & 15) == 0 || ((year & 3) == 0 && year % 100 != 0); > } > ``` > > **Correctness verification:** I've tested this logic extensively, including edge cases like year 0, negative years (proleptic Gregorian), and all century boundaries from -10,000 to 10,000. > > I am aware that I cannot submit a formal patch until my OCA is complete. However, I would be very grateful for your initial technical feedback on this approach before I proceed to create a fully tested patch with benchmarks. > > Once my OCA is in place, would there be a maintainer or an experienced contributor interested in sponsoring this change if it proves worthwhile? > > Thank you for your time and consideration. > > Best regards, > Memory2314 -------------- next part -------------- An HTML attachment was scrubbed... URL: From jlu at openjdk.org Mon Dec 15 21:16:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 21:16:08 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 19:52:35 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Spot revert Chinese translation src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} > 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} > 53: java.launcher.cls.error6=????? {0} ?????????????\n???????????????????\n public {0}() Translating "non-private" looks good, but we might leave the second "private" untranslated, since the original intent for that one is being used as a Java keyword. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620866475 From jlu at openjdk.org Mon Dec 15 21:20:29 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 21:20:29 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v5] In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: > This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. > > M1 Mac - Perf (before): > > > MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms > > > M1 Mac - Perf (after): > > > Benchmark Mode Cnt Score Error Units > MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms Justin Lu has updated the pull request incrementally with one additional commit since the last revision: spacing of increment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28806/files - new: https://git.openjdk.org/jdk/pull/28806/files/8c80ce3e..2fe77590 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28806&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28806.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28806/head:pull/28806 PR: https://git.openjdk.org/jdk/pull/28806 From asemenyuk at openjdk.org Mon Dec 15 21:28:11 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 15 Dec 2025 21:28:11 GMT Subject: RFR: 8373710: Improve jpackage error reporting Message-ID: - Append "Error: " prefix to error messages - Always print stack traces of internal exceptions, not only when running in verbose mode ------------- Commit messages: - Improve error reporting: fix the value of "message.error-header" l10n key that was supposed to be updated in JDK-8372359. Always print stack trace of an exception if was not explicitly thrown from jpackage code. Better test coverage for the cli/Main. Changes: https://git.openjdk.org/jdk/pull/28833/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373710 Stats: 229 lines in 3 files changed: 220 ins; 1 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28833/head:pull/28833 PR: https://git.openjdk.org/jdk/pull/28833 From dnguyen at openjdk.org Mon Dec 15 21:32:24 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:32:24 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: > Open l10n drop. Files have been updated with translated versions. Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: Revert private keyword ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28802/files - new: https://git.openjdk.org/jdk/pull/28802/files/1a5ebb91..4f80e7e4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28802&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28802.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28802/head:pull/28802 PR: https://git.openjdk.org/jdk/pull/28802 From dnguyen at openjdk.org Mon Dec 15 21:32:26 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:32:26 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: References: <1ufR9UxA6vUcmh-4Fw6virbi19_MTZDT8egy1g6kCYc=.f3fba997-7339-4348-8378-7f0fb58b1df4@github.com> Message-ID: On Mon, 15 Dec 2025 19:43:46 GMT, Weijun Wang wrote: >> Good catch. I'm going with this option since it doesn't make sense. to update this line anyway when the original file didn't change this line. I'll submit the issue about these words not being translated nonetheless. Thanks! > > I guess someone has complained that the 2nd "private" should not be translated. The problem in this PR is that both "non-private" and "private" are back to English. I think the 2nd should not be translated but the 1st should, or, at least it can be written as "?private?. Keeping a "non-" in Chinese looks strange. Agreed. I have reverted the second private back to the not-translated version. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620910384 From asemenyuk at openjdk.org Mon Dec 15 21:32:34 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 15 Dec 2025 21:32:34 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v4] In-Reply-To: References: Message-ID: > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach > > Supplementary changes: > - Take advantage of the updated `Throwing...` interfaces in the `Result` class. > - Add unit tests for the `Result` class and fix uncovered minor issues. Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Result: add unit tests, remove unused mapErrors(UnaryOperator>) function; better and more consistent error reporting based on testing - Result: replace create(Supplier) with of(ThrowingSupplier) - CustomInfoPListTest: fix local test failure: [22:38:21.786] TRACE: assertStringListEquals(): Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same [22:38:21.786] TRACE: assertStringListEquals( 1, /CFBundleDevelopmentRegion: en-US) [22:38:21.786] TRACE: assertStringListEquals( 2, /CFBundleExecutable: libjli.dylib) [22:38:21.786] TRACE: assertStringListEquals( 3, /CFBundleIdentifier: Hello) [22:38:21.787] TRACE: assertStringListEquals( 4, /CFBundleInfoDictionaryVersion: 7.0) [22:38:21.787] TRACE: assertStringListEquals( 5, /CFBundleName: PackageCustomInfoPListTest) [22:38:21.787] TRACE: assertStringListEquals( 6, /CFBundlePackageType: BNDL) [22:38:21.787] TRACE: assertStringListEquals( 7, /CFBundleShortVersionString: 1.0) [22:38:21.787] TRACE: assertStringListEquals( 8, /CFBundleSignature: ????) [22:38:21.787] TRACE: assertStringListEquals( 9, /CFBundleVersion: 1.0) [22:38:21.787] ERROR: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same [22:38:21.787] [ FAILED ] CustomInfoPListTest.testPackage(APP); checks=54 Exception in thread "main" java.lang.AssertionError: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same at jdk.jpackage.test.TKit.error(TKit.java:360) at jdk.jpackage.test.TKit.assertStringListEquals(TKit.java:1068) at CustomInfoPListTest$TestConfig.lambda$createPListFilesVerifier$1(CustomInfoPListTest.java:274) at CustomInfoPListTest.lambda$testApp$9(CustomInfoPListTest.java:182) Caused by not getting the default plist file from the vanilla app image runtime directory when the external runtime with the "bin" subdirectory is used with the tests. Test log without the predefined runtime: ======================================== [22:35:26.310] Creating app package: PackageCustomInfoPListTest.app in jpackage-tests/CustomInfoPListTest/testPackage.571a7829/vanilla [22:35:26.318] Running jlink ... [22:35:29.430] Using default package resource ApplicationRuntime-Info.plist.template [Embedded Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize). Test log with the predefined runtime: ===================================== [22:38:17.465] Creating app package: PackageCustomInfoPListTest.app in jpackage-tests/CustomInfoPListTest/testPackage.571a7829/vanilla [22:38:17.605] Using default package resource Runtime-Info.plist.template [Embedded Java Runtime Info.plist] (add Runtime-Info.plist to the resource-dir to customize). - TKit: fix missing test execution summary if some tests fail - Replace `ExceptionBox.rethrowUnchecked()` with `throw ExceptionBox.toUnchecked()`; remove ExceptionBox.rethrowUnchecked(). - ExceptionBox: add toUnchecked() and use it in all Throwing classes instead of ExceptionBox.rethrowUnchecked(). This change results in 100% coverage for these classes in the unit tests. Add unit tests. Add ExceptionBox.reachedUnreachable(). - Throwing: make these classes generic; don't catch Throwable-s, catch Exception-s instead and let Error-s out. ------------- Changes: https://git.openjdk.org/jdk/pull/28731/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=03 Stats: 1374 lines in 55 files changed: 1116 ins; 38 del; 220 mod Patch: https://git.openjdk.org/jdk/pull/28731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28731/head:pull/28731 PR: https://git.openjdk.org/jdk/pull/28731 From dnguyen at openjdk.org Mon Dec 15 21:39:42 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:39:42 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v3] In-Reply-To: References: <_t7T8S2_DaWKwPJncyWMNexDfL6xdRRr12AMG7nU5ww=.0d8369ac-a6a8-433f-827e-15360e3263d0@github.com> Message-ID: On Mon, 15 Dec 2025 21:13:07 GMT, Justin Lu wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Spot revert Chinese translation > > src/java.base/share/classes/sun/launcher/resources/launcher_zh_CN.properties line 53: > >> 51: java.launcher.cls.error4=??: ???? {0} ??? LinkageError\n\t{1} >> 52: java.launcher.cls.error5=??: ??????? {0}\n??: {1}: {2} >> 53: java.launcher.cls.error6=????? {0} ?????????????\n???????????????????\n public {0}() > > Translating "non-private" looks good, but we might leave the second "private" untranslated, since the original intent for that one is being used as a Java keyword. Weijun brought up the same thing above. This has been updated. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620933892 From dnguyen at openjdk.org Mon Dec 15 21:39:46 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Mon, 15 Dec 2025 21:39:46 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v2] In-Reply-To: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> References: <5DQ6UsA2li8t_hE1dZ1jkXCRUuHXCituWpRS5o3OSa0=.583404a8-ec75-4527-be3d-577a1d0fed0e@github.com> Message-ID: On Mon, 15 Dec 2025 19:10:35 GMT, Chen Liang wrote: >> Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: >> >> Revert Chinese preview change > > src/jdk.compiler/share/classes/com/sun/tools/javac/resources/compiler_zh_CN.properties line 295: > >> 293: >> 294: # 0: symbol or name >> 295: compiler.err.cant.ref.before.ctor.called=? {0} ???????????????? > > The original term "appear" is translated to "show" incorrectly. Google translate for single term "appear" recommends "??" which is more accurate. Same below. I will note and file this to the translation team as well. In the past, similar issues occurred where more accurate words exist, but sometimes they do not update the translations anyway due to there being no functional issue from their perspective. However, I will update this in the next drop if they do fix it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28802#discussion_r2620931705 From liach at openjdk.org Mon Dec 15 21:50:32 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 15 Dec 2025 21:50:32 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v5] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > spacing of increment Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3580310763 From rriggs at openjdk.org Mon Dec 15 22:12:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 15 Dec 2025 22:12:59 GMT Subject: [jdk26] RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID Message-ID: Backport of doc-only information about scope of UUID class. ------------- Commit messages: - Backport 6aeabd4bfaca168e9c88716b185979cf1e1b85ed Changes: https://git.openjdk.org/jdk/pull/28835/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28835&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370910 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28835.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28835/head:pull/28835 PR: https://git.openjdk.org/jdk/pull/28835 From jlu at openjdk.org Mon Dec 15 22:31:59 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 22:31:59 GMT Subject: RFR: 8373119: JDK 26 RDP1 L10n resource files update [v4] In-Reply-To: References: Message-ID: <6Ucr0pTs8y0eZTZsnO5sK0wHVPDlKk5nw7V0idjibCo=.2abee019-c538-4647-b01b-5875a9c65804@github.com> On Mon, 15 Dec 2025 21:32:24 GMT, Damon Nguyen wrote: >> Open l10n drop. Files have been updated with translated versions. > > Damon Nguyen has updated the pull request incrementally with one additional commit since the last revision: > > Revert private keyword Looks like you addressed the concerns that were possible to resolve, and will file the rest with the translation team. LGTM. ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28802#pullrequestreview-3580442012 From jlu at openjdk.org Mon Dec 15 22:57:08 2025 From: jlu at openjdk.org (Justin Lu) Date: Mon, 15 Dec 2025 22:57:08 GMT Subject: RFR: 8373716: Refactor further java/util tests from TestNG to JUnit Message-ID: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically, - _java/util/Calendar_ - _java/util/TimeZone_ - _java/util/Properties_ - _java/util/ResourceBundle_ This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same, **Calendar** `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit` **TimeZone** `84 = 39 TestNG + 45 JUnit -> 0 TestNG + 84 JUnit` **Properties** `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit` **ResourceBundle** `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit` ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/28836/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28836&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373716 Stats: 184 lines in 14 files changed: 44 ins; 23 del; 117 mod Patch: https://git.openjdk.org/jdk/pull/28836.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28836/head:pull/28836 PR: https://git.openjdk.org/jdk/pull/28836 From asemenyuk at openjdk.org Tue Dec 16 00:54:31 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 00:54:31 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v2] In-Reply-To: References: Message-ID: > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: cli/Main fix ErrorTest failure ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28833/files - new: https://git.openjdk.org/jdk/pull/28833/files/f5ebedd8..6b6e8cad Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=00-01 Stats: 37 lines in 2 files changed: 23 ins; 4 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28833/head:pull/28833 PR: https://git.openjdk.org/jdk/pull/28833 From asemenyuk at openjdk.org Tue Dec 16 00:54:31 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 00:54:31 GMT Subject: RFR: 8373710: Improve jpackage error reporting In-Reply-To: References: Message-ID: <-w9_PDMfpI4a0FoVFqi9yMdizVyUZc1230OPJshlW1U=.200f1f4e-31f8-4bad-929f-fae4ec24a5e9@github.com> On Mon, 15 Dec 2025 21:20:49 GMT, Alexey Semenyuk wrote: > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28833#issuecomment-3658224655 From jpai at openjdk.org Tue Dec 16 01:25:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 16 Dec 2025 01:25:57 GMT Subject: [jdk26] RFR: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 22:06:23 GMT, Roger Riggs wrote: > Backport of doc-only information about scope of UUID class. Looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28835#pullrequestreview-3580790882 From liach at openjdk.org Tue Dec 16 01:59:55 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 01:59:55 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 This looks reasonable in principle. However, we need to verify we indeed won't run into putting non-chronofield into an enum map by accident, and this is a bit hard... ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3580903973 From erfang at openjdk.org Tue Dec 16 02:24:51 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 16 Dec 2025 02:24:51 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: <_Nidz7v88pMoPXhyrFT7ZzLrxBJWj5o_i75enBlU8Us=.0dc8fd05-a366-4e6e-8af7-0ccd0d5ddf50@github.com> On Mon, 15 Dec 2025 07:37:42 GMT, Jatin Bhateja wrote: >> My main concern here is that the requirement for `VectorMaskCastNode` to have the same length for both input and output might have been removed in the future. I'm not sure, but we do require the lengths to be the same here, so I added this assertion. @eme64 has a similar comment; see https://github.com/openjdk/jdk/pull/28313/changes#r2614577536. So, if you all think that the requirement for lane length in `VectorMaskCastNode` won't be removed, then we can delete this assertion and the condition below. > > I think assertion here is redundant. Yeah, I think deleting this assertion is also reasonable. After all, if the input and output lengths of `VectorMaskCastNode` are inconsistent, it will cause more problems. I will consider how to handle these two places in conjunction with @eme64's comment. Thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2621517632 From china.weigao at gmail.com Tue Dec 16 02:24:42 2025 From: china.weigao at gmail.com (weigao) Date: Tue, 16 Dec 2025 10:24:42 +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 Thank you and OpenJDK community for accepting this suggestion. Best regards, vincent gao Chen Liang ?2025?12?16??? 04:23??? > Hi Vincent, > Thanks for the details. Our engineers have created a patch at > https://github.com/openjdk/jdk/pull/28806. > We seek to backport this to the 25 updates once this is merged. Ideally > this would be part of update 25.0.3. > Thank you again for this performance regression report! > > -Chen > ------------------------------ > *From:* weigao > *Sent:* Thursday, December 11, 2025 8:12 PM > *To:* Chen Liang > *Cc:* 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 , 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 almatvee at openjdk.org Tue Dec 16 02:38:56 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 16 Dec 2025 02:38:56 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v2] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 00:54:31 GMT, Alexey Semenyuk wrote: >> - Append "Error: " prefix to error messages >> - Always print stack traces of internal exceptions, not only when running in verbose mode > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > cli/Main fix ErrorTest failure Looks good with minor comment. test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/cli/MainTest.java line 371: > 369: return ex -> { > 370: var msg = formatter.apply(ex); > 371: return I18N.format("message.error-header", msg) + System.lineSeparator(); Extra space in `msg) +`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28833#pullrequestreview-3580953438 PR Review Comment: https://git.openjdk.org/jdk/pull/28833#discussion_r2621525783 From erfang at openjdk.org Tue Dec 16 03:31:07 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 16 Dec 2025 03:31:07 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] 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 pull request now contains four commits: - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity - 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: https://git.openjdk.org/jdk/pull/28692/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=02 Stats: 9118 lines in 44 files changed: 3251 ins; 3822 del; 2045 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 Tue Dec 16 03:34:56 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 16 Dec 2025 03:34:56 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 03:31:07 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 pull request now contains four commits: > > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - 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. Hi, could you please take another look at this PR? I've already processed all your comments. @merykitty @PaulSandoz And @XiaohongGong @shqking ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3658575085 From almatvee at openjdk.org Tue Dec 16 03:50:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 16 Dec 2025 03:50:53 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v4] In-Reply-To: References: Message-ID: <8EbqbyaBBI3AkKgHSRnjJIJslzLsTlk4u5uhCiHBuJg=.315ce446-7a79-4dde-8bce-dbd9ffc130ae@github.com> On Mon, 15 Dec 2025 21:32:34 GMT, Alexey Semenyuk wrote: >> - Add exception type as an additional generic parameter to all `Throwing...` interfaces >> - Add unit tests for "jdk.jpackage.internal.util.function" package >> - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw >> - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% >> - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): >> - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it >> - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` >> - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors >> - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate >> - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach >> >> Supplementary changes: >> - Take advantage of the updated `Throwing...` interfaces in the `Result` class. >> - Add unit tests for the `Result` class and fix uncovered minor issues. > > Alexey Semenyuk 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: > > - Result: add unit tests, remove unused mapErrors(UnaryOperator>) function; better and more consistent error reporting based on testing > - Result: replace create(Supplier) with of(ThrowingSupplier) > - CustomInfoPListTest: fix local test failure: > > [22:38:21.786] TRACE: assertStringListEquals(): Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same > [22:38:21.786] TRACE: assertStringListEquals( 1, /CFBundleDevelopmentRegion: en-US) > [22:38:21.786] TRACE: assertStringListEquals( 2, /CFBundleExecutable: libjli.dylib) > [22:38:21.786] TRACE: assertStringListEquals( 3, /CFBundleIdentifier: Hello) > [22:38:21.787] TRACE: assertStringListEquals( 4, /CFBundleInfoDictionaryVersion: 7.0) > [22:38:21.787] TRACE: assertStringListEquals( 5, /CFBundleName: PackageCustomInfoPListTest) > [22:38:21.787] TRACE: assertStringListEquals( 6, /CFBundlePackageType: BNDL) > [22:38:21.787] TRACE: assertStringListEquals( 7, /CFBundleShortVersionString: 1.0) > [22:38:21.787] TRACE: assertStringListEquals( 8, /CFBundleSignature: ????) > [22:38:21.787] TRACE: assertStringListEquals( 9, /CFBundleVersion: 1.0) > [22:38:21.787] ERROR: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same > [22:38:21.787] [ FAILED ] CustomInfoPListTest.testPackage(APP); checks=54 > Exception in thread "main" java.lang.AssertionError: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Cont... Looks good. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 237: > 235: throw ExceptionBox.unbox(ex); > 236: } > 237: } catch (Exception|AssertionError t) { Should we use space around `|` or not? I see some old cases when we do `catch (ExceptionBox | InvocationTargetException ex)` and in new cases we do `catch (Exception|AssertionError t)`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28731#pullrequestreview-3581053974 PR Review Comment: https://git.openjdk.org/jdk/pull/28731#discussion_r2621610599 From rriggs at openjdk.org Tue Dec 16 04:17:13 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Dec 2025 04:17:13 GMT Subject: [jdk26] Integrated: 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 22:06:23 GMT, Roger Riggs wrote: > Backport of doc-only information about scope of UUID class. This pull request has now been integrated. Changeset: c46e6350 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/c46e6350aa1e339e845a1fd7a11419f327ae651d Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod 8370910: Cleanup terminology of UUID vs Global Identifiers in UUID Reviewed-by: jpai Backport-of: 6aeabd4bfaca168e9c88716b185979cf1e1b85ed ------------- PR: https://git.openjdk.org/jdk/pull/28835 From rriggs at openjdk.org Tue Dec 16 04:29:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Dec 2025 04:29:59 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v5] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > spacing of increment Looks good Marked as reviewed by rriggs (Reviewer). ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3581214624 PR Review: https://git.openjdk.org/jdk/pull/28806#pullrequestreview-3581218040 From duke at openjdk.org Tue Dec 16 04:50:25 2025 From: duke at openjdk.org (Patrick Strawderman) Date: Tue, 16 Dec 2025 04:50:25 GMT Subject: RFR: 8373288: EnumMap spliterators should include more specific characteristics Message-ID: The spliterators returned by keySet, entrySet, and values were not reporting additional characteristics, such as ORDERED, SORTED, and NONNULL; the EnumMap iterators all guarantee iteration is in the natural order of the enum key, and nulls are disallowed as keys. Null values are allowed, so the values collection can only additionally report ORDERED. ------------- Commit messages: - Update copyright year - 8373288: EnumMap spliterators should include more specific characteristics Changes: https://git.openjdk.org/jdk/pull/28840/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28840&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373288 Stats: 140 lines in 2 files changed: 138 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28840.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28840/head:pull/28840 PR: https://git.openjdk.org/jdk/pull/28840 From darcy at openjdk.org Tue Dec 16 05:09:51 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Dec 2025 05:09:51 GMT Subject: RFR: 8373288: EnumMap spliterators should include more specific characteristics In-Reply-To: References: Message-ID: <3VXeasovMPqHxds_-ZHjZ-0Wzqm4wgEwxuizMeC_Luc=.30200907-2fbc-4aaf-84c3-bc96b8e9ac7b@github.com> On Tue, 16 Dec 2025 04:42:53 GMT, Patrick Strawderman wrote: > The spliterators returned by keySet, entrySet, and values were not reporting additional characteristics, such as ORDERED, SORTED, and NONNULL; the EnumMap iterators all guarantee iteration is in the natural order of the enum key, and nulls are disallowed as keys. > > Null values are allowed, so the values collection can only additionally report ORDERED. While changing the specification to add these requirements would require CSR review, I think that would be a better version of this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28840#issuecomment-3658865460 From asemenyuk at openjdk.org Tue Dec 16 05:19:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 05:19:52 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v4] In-Reply-To: <8EbqbyaBBI3AkKgHSRnjJIJslzLsTlk4u5uhCiHBuJg=.315ce446-7a79-4dde-8bce-dbd9ffc130ae@github.com> References: <8EbqbyaBBI3AkKgHSRnjJIJslzLsTlk4u5uhCiHBuJg=.315ce446-7a79-4dde-8bce-dbd9ffc130ae@github.com> Message-ID: On Tue, 16 Dec 2025 03:23:12 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: >> >> - Result: add unit tests, remove unused mapErrors(UnaryOperator>) function; better and more consistent error reporting based on testing >> - Result: replace create(Supplier) with of(ThrowingSupplier) >> - CustomInfoPListTest: fix local test failure: >> >> [22:38:21.786] TRACE: assertStringListEquals(): Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same >> [22:38:21.786] TRACE: assertStringListEquals( 1, /CFBundleDevelopmentRegion: en-US) >> [22:38:21.786] TRACE: assertStringListEquals( 2, /CFBundleExecutable: libjli.dylib) >> [22:38:21.786] TRACE: assertStringListEquals( 3, /CFBundleIdentifier: Hello) >> [22:38:21.787] TRACE: assertStringListEquals( 4, /CFBundleInfoDictionaryVersion: 7.0) >> [22:38:21.787] TRACE: assertStringListEquals( 5, /CFBundleName: PackageCustomInfoPListTest) >> [22:38:21.787] TRACE: assertStringListEquals( 6, /CFBundlePackageType: BNDL) >> [22:38:21.787] TRACE: assertStringListEquals( 7, /CFBundleShortVersionString: 1.0) >> [22:38:21.787] TRACE: assertStringListEquals( 8, /CFBundleSignature: ????) >> [22:38:21.787] TRACE: assertStringListEquals( 9, /CFBundleVersion: 1.0) >> [22:38:21.787] ERROR: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same >> [22:38:21.787] [ FAILED ] CustomInfoPListTest.testPackage(APP); checks=54 >> Exception in thread "main" java.lang.AssertionError: Actual list is shorter than expected by 5 elements: Check contents of [CustomInfoPListTest/testPackage.571a7829/vanilla/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] and [CustomInfoPListTest/testPackage.571a7829/unpacked-pkg/unpacked/Applications/PackageCustomInfoPListTest.app/Contents/runtime/Contents/Info.plist] plist files are the same >> at jdk.... > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java line 237: > >> 235: throw ExceptionBox.unbox(ex); >> 236: } >> 237: } catch (Exception|AssertionError t) { > > Should we use space around `|` or not? I see some old cases when we do `catch (ExceptionBox | InvocationTargetException ex)` and in new cases we do `catch (Exception|AssertionError t)`. Yes, we should. Will fix it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28731#discussion_r2621824785 From asotona at openjdk.org Tue Dec 16 08:34:53 2025 From: asotona at openjdk.org (Adam Sotona) Date: Tue, 16 Dec 2025 08:34:53 GMT Subject: RFR: 8341272: Factory to create wide iinc instruction with small arguments [v2] In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 01:37:05 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. > > Trevor Bond has updated the pull request incrementally with one additional commit since the last revision: > > Clean up javadocs and address other review comments Marked as reviewed by asotona (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28729#pullrequestreview-3581913669 From bkilambi at openjdk.org Tue Dec 16 10:23:32 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 16 Dec 2025 10:23:32 GMT Subject: RFR: 8371711: AArch64: SVE intrinsics for Arrays.sort methods (int, float) In-Reply-To: References: <8i4snpt_829luK8hB9U6qgJ833kiNK1hPe7IckfaoJ8=.5cd666c6-b4c9-4ff5-bb39-d1243afd61f0@github.com> Message-ID: On Tue, 9 Dec 2025 00:01:26 GMT, Vladimir Ivanov wrote: > 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? @iwanowww This sounds good. I can wait until you post your PR and then I can start working on updating this patch based on that. Thanks a lot! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3659808712 From bkilambi at openjdk.org Tue Dec 16 13:49:03 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 16 Dec 2025 13:49:03 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 Thu, 11 Dec 2025 06:08:58 GMT, Jatin Bhateja wrote: > 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. Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3660602956 From rgiulietti at openjdk.org Tue Dec 16 14:43:33 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 16 Dec 2025 14:43:33 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit Message-ID: Replace testng framework with junit ------------- Commit messages: - 8373798: Refactor java/math tests to use JUnit Changes: https://git.openjdk.org/jdk/pull/28848/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28848&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373798 Stats: 124 lines in 2 files changed: 43 ins; 11 del; 70 mod Patch: https://git.openjdk.org/jdk/pull/28848.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28848/head:pull/28848 PR: https://git.openjdk.org/jdk/pull/28848 From alanb at openjdk.org Tue Dec 16 15:02:06 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 16 Dec 2025 15:02:06 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 14:38:07 GMT, Raffaello Giulietti wrote: > Replace testng framework with junit test/jdk/java/math/BigDecimal/Constructor.java line 71: > 69: } else { > 70: throw nfe; > 71: } If you want, you could use `NumberFormatException nfe = assertThrows(..)` here, then assert the cause. That would avoid mixing JUnit asserts with explicit throw of RuntimeException. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28848#discussion_r2623633366 From rgiulietti at openjdk.org Tue Dec 16 15:07:45 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Tue, 16 Dec 2025 15:07:45 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 14:59:35 GMT, Alan Bateman wrote: >> Replace testng framework with junit > > test/jdk/java/math/BigDecimal/Constructor.java line 71: > >> 69: } else { >> 70: throw nfe; >> 71: } > > If you want, you could use `NumberFormatException nfe = assertThrows(..)` here, then assert the cause. That would avoid mixing JUnit asserts with explicit throw of RuntimeException. That's just the result of a mechanical conversion of the original testng-based code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28848#discussion_r2623658294 From jbhateja at openjdk.org Tue Dec 16 15:48:06 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 16 Dec 2025 15:48:06 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 Tue, 16 Dec 2025 13:45:58 GMT, Bhavana Kilambi wrote: > > 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. > > Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR? Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR. Best Regards ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3661203155 From asemenyuk at openjdk.org Tue Dec 16 16:31:18 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 16:31:18 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v5] In-Reply-To: References: Message-ID: <-WMSRJXL1nt49ZVJrTwyleNqyCQnGxq4ozZ34t5xujc=.c4379fa8-5037-409c-8226-7c2b8c2d11ac@github.com> > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach > > Supplementary changes: > - Take advantage of the updated `Throwing...` interfaces in the `Result` class. > - Add unit tests for the `Result` class and fix uncovered minor issues. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Fix whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28731/files - new: https://git.openjdk.org/jdk/pull/28731/files/d791b771..2c807850 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28731&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28731.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28731/head:pull/28731 PR: https://git.openjdk.org/jdk/pull/28731 From asemenyuk at openjdk.org Tue Dec 16 16:59:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 16:59:08 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v3] In-Reply-To: References: Message-ID: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Fix test failure; Fix whitespaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28833/files - new: https://git.openjdk.org/jdk/pull/28833/files/6b6e8cad..a592354e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=01-02 Stats: 4 lines in 2 files changed: 1 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28833/head:pull/28833 PR: https://git.openjdk.org/jdk/pull/28833 From psandoz at openjdk.org Tue Dec 16 17:43:33 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 16 Dec 2025 17:43:33 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 03:31:07 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 pull request now contains four commits: > > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - 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. test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template line 12: > 10: $abstractvectortype$ av = $abstractvectortype$.fromArray(SPECIES, a, i); > 11: r[i] = av.reduceLanes(VectorOperators.[[TEST]], vmask); > 12: ra = [[TEST_OP]](ra, r[i]); It's probably ok to merge the two cases, but to be conservative assign to a local variable rather than reading from the array e.g., $type$ v = av.reduceLanes(VectorOperators.[[TEST]], vmask); r[i] = v; ra = [[TEST_OP]](ra, v); test/jdk/jdk/incubator/vector/templates/Unit-Identity-test.template line 3: > 1: > 2: @Test(dataProvider = "$type$UnaryOpProvider") > 3: static void testIdentityValues(IntFunction<$type$[]> fa) { Since we already have the scalar operation we can generalize and reuse e.g., to test the following: (id, x) == x, (x, id) == x, (id, id) == id. I believe we could add the additional test to `Unit-Reduction-op.template` and `Unit-Reduction-op-func.template`. WDYT? test/jdk/jdk/incubator/vector/templates/Unit-Identity-test.template line 60: > 58: > 59: @Test(dataProvider = "$type$UnaryOpProvider") > 60: static void testMaskedReductionIdentityAllFalse(IntFunction<$type$[]> fa) { Do we need this test since we already have boolean data sets with all false values that is used for the mask tests ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2624139874 PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2624178071 PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2624149971 From qamai at openjdk.org Tue Dec 16 17:50:25 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 16 Dec 2025 17:50:25 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: On Fri, 12 Dec 2025 08:49:04 GMT, Eric Fang wrote: >> 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! Then, please add tests to verify the correctness of these identity value (i.e. `x + i == x`). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2624199711 From iris at openjdk.org Tue Dec 16 17:56:53 2025 From: iris at openjdk.org (Iris Clark) Date: Tue, 16 Dec 2025 17:56:53 GMT Subject: RFR: 8373552: ExactConversionsSupport: bad JLS links in javadoc In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 20:50:31 GMT, Aggelos Biboudis wrote: > Add relative links to the spec URL of primitive-types-in-patterns-instanceof-switch-jls.html Looks good for now. Note that once the feature is standardized and the new sections are integrated into the JLS, you'll need to update the references to use `@jls`. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28775#pullrequestreview-3584307009 From darcy at openjdk.org Tue Dec 16 18:07:21 2025 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 16 Dec 2025 18:07:21 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit In-Reply-To: References: Message-ID: <6VaYXQay9-7SMRm9qChOB-NPB5OfbR5NaRR43HtW9Vg=.b84dc18a-795e-4426-9ef8-e6cc8b31995e@github.com> On Tue, 16 Dec 2025 14:38:07 GMT, Raffaello Giulietti wrote: > Replace testng framework with junit Looks fine. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28848#pullrequestreview-3584347416 From jlu at openjdk.org Tue Dec 16 18:14:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Dec 2025 18:14:34 GMT Subject: RFR: 8373566: Performance regression with java.text.MessageFormat subformat patterns [v5] In-Reply-To: References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Mon, 15 Dec 2025 21:20:29 GMT, Justin Lu wrote: >> This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. >> >> M1 Mac - Perf (before): >> >> >> MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms >> >> >> M1 Mac - Perf (after): >> >> >> Benchmark Mode Cnt Score Error Units >> MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms >> MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > spacing of increment Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28806#issuecomment-3661794583 From jlu at openjdk.org Tue Dec 16 18:14:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Dec 2025 18:14:36 GMT Subject: Integrated: 8373566: Performance regression with java.text.MessageFormat subformat patterns In-Reply-To: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> References: <46vDwiFm-RfhCbyGzOB7UHoWYKhqUfAMP2s-Ts3bFeQ=.a4972514-b27c-473a-9dd8-885da115347a@github.com> Message-ID: On Fri, 12 Dec 2025 21:59:52 GMT, Justin Lu wrote: > This PR addresses a performance degradation when constructing a new MessageFormat that contains a subformat with a pattern that is not a predefined style. This is due to internal logic which catches an IAE specifically for subformat patterns. Perf tests for choice and number are not grouped, since performance is directly tied to subformat creation. > > M1 Mac - Perf (before): > > > MessageFormatterBench.testSubformatChoice thrpt 15 865.430 ? 6.766 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 1021.808 ? 11.413 ops/ms > > > M1 Mac - Perf (after): > > > Benchmark Mode Cnt Score Error Units > MessageFormatterBench.testSubformatChoice thrpt 15 1671.033 ? 55.012 ops/ms > MessageFormatterBench.testSubformatNumber thrpt 15 3275.727 ? 47.370 ops/ms This pull request has now been integrated. Changeset: 81e37576 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/81e375768837e1ae6c34c1d0a8eff06b4e1d2889 Stats: 58 lines in 2 files changed: 21 ins; 9 del; 28 mod 8373566: Performance regression with java.text.MessageFormat subformat patterns Reviewed-by: liach, rriggs, naoto ------------- PR: https://git.openjdk.org/jdk/pull/28806 From liach at openjdk.org Tue Dec 16 18:54:34 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 18:54:34 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] 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 14 additional commits since the last revision: - Recommended test tweaks - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting - 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 - ... and 4 more: https://git.openjdk.org/jdk/compare/57f00286...567e8925 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/b20b7f5b..567e8925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=04-05 Stats: 21935 lines in 436 files changed: 14170 ins; 4911 del; 2854 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 dl at openjdk.org Tue Dec 16 19:12:24 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 16 Dec 2025 19:12:24 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Relax orderings in push ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/61adb1dc..7cc2dd1a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=05-06 Stats: 33 lines in 1 file changed: 7 ins; 10 del; 16 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 naoto at openjdk.org Tue Dec 16 19:17:09 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Dec 2025 19:17:09 GMT Subject: RFR: 8373716: Refactor further java/util tests from TestNG to JUnit In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> Message-ID: On Mon, 15 Dec 2025 22:50:22 GMT, Justin Lu wrote: > This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically, > - _java/util/Calendar_ > - _java/util/TimeZone_ > - _java/util/Properties_ > - _java/util/ResourceBundle_ > > > This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same, > > **Calendar** > `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit` > > **TimeZone** > `84 = 39 TestNG + 45 JUnit -> 0 TestNG + 84 JUnit` > > **Properties** > `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit` > > **ResourceBundle** > `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit` LGTM. One suggestion not related to testng->junit effort. test/jdk/java/util/Calendar/JapaneseLenientEraTest.java line 45: > 43: public class JapaneseLenientEraTest { > 44: > 45: Object[][] names() { Probably blame is on me, but it would make more sense to rename this method to `lenientEra`. ------------- PR Review: https://git.openjdk.org/jdk/pull/28836#pullrequestreview-3584588629 PR Review Comment: https://git.openjdk.org/jdk/pull/28836#discussion_r2624439179 From jlu at openjdk.org Tue Dec 16 19:25:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Dec 2025 19:25:34 GMT Subject: RFR: 8373716: Refactor further java/util tests from TestNG to JUnit [v2] In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> Message-ID: > This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically, > - _java/util/Calendar_ > - _java/util/TimeZone_ > - _java/util/Properties_ > - _java/util/ResourceBundle_ > > > This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same, > > **Calendar** > `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit` > > **TimeZone** > `84 = 39 TestNG + 45 JUnit -> 0 TestNG + 84 JUnit` > > **Properties** > `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit` > > **ResourceBundle** > `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit` Justin Lu has updated the pull request incrementally with one additional commit since the last revision: names -> lenientEra ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28836/files - new: https://git.openjdk.org/jdk/pull/28836/files/a65a4930..8a8b31b4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28836&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28836&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28836.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28836/head:pull/28836 PR: https://git.openjdk.org/jdk/pull/28836 From mdoerr at openjdk.org Tue Dec 16 19:38:27 2025 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 16 Dec 2025 19:38:27 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) @psandoz: Can you take a look, please? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3662075741 From naoto at openjdk.org Tue Dec 16 19:48:24 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 16 Dec 2025 19:48:24 GMT Subject: RFR: 8373716: Refactor further java/util tests from TestNG to JUnit [v2] In-Reply-To: References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> Message-ID: <0P2ruBkQeL5uDxeNyaesYtrrnsBQnVuNFYakIOTr-SA=.4a04a60a-9456-4275-b131-74e30a6227b3@github.com> On Tue, 16 Dec 2025 19:25:34 GMT, Justin Lu wrote: >> This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically, >> - _java/util/Calendar_ >> - _java/util/TimeZone_ >> - _java/util/Properties_ >> - _java/util/ResourceBundle_ >> >> >> This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same, >> >> **Calendar** >> `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit` >> >> **TimeZone** >> `84 = 39 TestNG + 45 JUnit -> 0 TestNG + 84 JUnit` >> >> **Properties** >> `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit` >> >> **ResourceBundle** >> `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit` > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > names -> lenientEra LGTM ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28836#pullrequestreview-3584694256 From rriggs at openjdk.org Tue Dec 16 20:27:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Dec 2025 20:27:01 GMT Subject: Integrated: 8373623: Refactor Serialization tests for Records to JUnit In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 21:38:16 GMT, Roger Riggs wrote: > Refactor TestNG tests to JUnit under the umbrella initiative of [JDK-8307843](https://bugs.openjdk.org/browse/JDK-8307843). > Fairly straight-forward mapping of annotations between the frameworks with some accommodations for differences in the Assert support. This pull request has now been integrated. Changeset: 1e357e9e Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/1e357e9e976bfb0abc9d4e14bfb1572693622af8 Stats: 431 lines in 20 files changed: 131 ins; 64 del; 236 mod 8373623: Refactor Serialization tests for Records to JUnit Reviewed-by: jlu ------------- PR: https://git.openjdk.org/jdk/pull/28804 From jrose at openjdk.org Tue Dec 16 20:35:17 2025 From: jrose at openjdk.org (John R Rose) Date: Tue, 16 Dec 2025 20:35:17 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:54: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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - 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 > - ... and 4 more: https://git.openjdk.org/jdk/compare/384c62c9...567e8925 Excellent. It does not pay down every bit of technical debt in this area, but it is a significant installment payment. I think `constantFold` is OK as a directory name, although maybe a bit vague (folloing Jorn?s observations). Perhaps `constantFields` or `fieldFolding`. Or (most specifically) `trustedFinalFields`, but I think that is unnecessarily narrow. I suggest `fieldFolding` or `foldFields` or the like. The trusting logic is one way to fold fields, and also the forthcoming `ACC_STRICT_INIT`. There are also proposals to infer strictness in the absence of `ACC_STRICT_INIT`. All of those might have test cases associated with the tests for this feature. We could expect several tests in here eventually, validating the folding properties of various flavors of constant fields. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3584835561 From almatvee at openjdk.org Tue Dec 16 21:20:11 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 16 Dec 2025 21:20:11 GMT Subject: RFR: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package [v5] In-Reply-To: <-WMSRJXL1nt49ZVJrTwyleNqyCQnGxq4ozZ34t5xujc=.c4379fa8-5037-409c-8226-7c2b8c2d11ac@github.com> References: <-WMSRJXL1nt49ZVJrTwyleNqyCQnGxq4ozZ34t5xujc=.c4379fa8-5037-409c-8226-7c2b8c2d11ac@github.com> Message-ID: On Tue, 16 Dec 2025 16:31:18 GMT, Alexey Semenyuk wrote: >> - Add exception type as an additional generic parameter to all `Throwing...` interfaces >> - Add unit tests for "jdk.jpackage.internal.util.function" package >> - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw >> - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% >> - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): >> - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it >> - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` >> - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors >> - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate >> - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach >> >> Supplementary changes: >> - Take advantage of the updated `Throwing...` interfaces in the `Result` class. >> - Add unit tests for the `Result` class and fix uncovered minor issues. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Fix whitespaces Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28731#pullrequestreview-3584975155 From dnguyen at openjdk.org Tue Dec 16 21:22:17 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Dec 2025 21:22:17 GMT Subject: Integrated: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Fri, 12 Dec 2025 20:43:36 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. This pull request has now been integrated. Changeset: fb99ba6c Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod 8373119: JDK 26 RDP1 L10n resource files update Reviewed-by: jlu, asemenyuk, almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28802 From asemenyuk at openjdk.org Tue Dec 16 21:29:03 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 21:29:03 GMT Subject: Integrated: 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 01:33:36 GMT, Alexey Semenyuk wrote: > - Add exception type as an additional generic parameter to all `Throwing...` interfaces > - Add unit tests for "jdk.jpackage.internal.util.function" package > - Add `ExceptionBox.toUnchecked()`. It is equivalent to `ExceptionBox.rethrowUnchecked()`, but doesn't throw > - Replace `ExceptionBox.rethrowUnchecked(...)` with `ExceptionBox.toUnchecked(...)`; this increased test coverage of "jdk.jpackage.internal.util.function" package from 86% to 97% > - Change exception handling in `ExceptionBox.toUnchecked()` (former `ExceptionBox.rethrowUnchecked()`): > - `InterruptedException`: instead of rethrowing an exception of this type, it calls `Thread.currentThread().interrupt()` and then rethrows it > - Add `ExceptionBox.unbox()` (former `TKit.unbox()`). It is complementary to `ExceptionBox.toUnchecked()` > - Catch `Exception` instead of `Throwable` where appropriate to avoid catching `Error`-s. The idea is not to handle fatal errors > - Replace vague `throws Throwable` exception specifications with more specific ones where appropriate > - Add `ExceptionBox.reachedUnreachable()` for use in locations that control flow is not expected to reach > > Supplementary changes: > - Take advantage of the updated `Throwing...` interfaces in the `Result` class. > - Add unit tests for the `Result` class and fix uncovered minor issues. This pull request has now been integrated. Changeset: 2241218e Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/2241218ef64ed6cb51f962f3ab6db1a766f1744f Stats: 1374 lines in 55 files changed: 1116 ins; 38 del; 220 mod 8373631: Improve classes in the "jdk.jpackage.internal.util.function" package Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28731 From duke at openjdk.org Tue Dec 16 21:38:36 2025 From: duke at openjdk.org (eunbin son) Date: Tue, 16 Dec 2025 21:38:36 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods Message-ID: ## Summary Adds comprehensive edge case tests for `Objects.requireNonNull`, `requireNonNullElse`, and `requireNonNullElseGet` methods to improve test coverage. ## Problem The current test suite for `Objects.requireNonNull` methods covers basic cases but lacks edge case coverage. ## Solution This PR adds tests for the following edge cases: - requireNonNull with null Supplier parameter - requireNonNull with Supplier that throws exception - requireNonNullElse with both arguments null - requireNonNullElseGet with null supplier - requireNonNullElseGet with supplier returning null ## Issue Fixes JDK-8373661 **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 ## Type of Change - [x] Test addition/modification - [ ] Bug fix - [ ] New feature - [ ] Documentation improvement - [ ] Refactoring ## Testing make test TEST="jtreg:test/jdk/java/util/Objects" ------------- Commit messages: - 8373661: Add edge case tests for Objects.requireNonNull methods Changes: https://git.openjdk.org/jdk/pull/28845/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373661 Stats: 126 lines in 1 file changed: 126 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From duke at openjdk.org Tue Dec 16 21:38:37 2025 From: duke at openjdk.org (eunbin son) Date: Tue, 16 Dec 2025 21:38:37 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 13:22:40 GMT, eunbin son wrote: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" I have signed the OCA. My GitHub username is thswlsqls. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3660572352 From dnguyen at openjdk.org Tue Dec 16 22:05:04 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 16 Dec 2025 22:05:04 GMT Subject: [jdk26] RFR: 8373119: JDK 26 RDP1 L10n resource files update Message-ID: Hi all, This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. Thanks! ------------- Commit messages: - Backport fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 Changes: https://git.openjdk.org/jdk/pull/28854/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28854&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373119 Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod Patch: https://git.openjdk.org/jdk/pull/28854.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28854/head:pull/28854 PR: https://git.openjdk.org/jdk/pull/28854 From rriggs at openjdk.org Tue Dec 16 22:16:46 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 16 Dec 2025 22:16:46 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods In-Reply-To: References: Message-ID: <8vp57HJD1AEXF1nycG0RcypV4PiSsg3rqtDhhN_UVsc=.7329c0c3-5b3a-435e-b69c-d5056bbf9f4a@github.com> On Tue, 16 Dec 2025 13:22:40 GMT, eunbin son wrote: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" The new tests scope is good. The current standard for tests is JUnit and it would be better to convert the test to JUnit before adding new tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3662639789 From jlu at openjdk.org Tue Dec 16 22:23:32 2025 From: jlu at openjdk.org (Justin Lu) Date: Tue, 16 Dec 2025 22:23:32 GMT Subject: [jdk26] RFR: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 21:52:52 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. > > Thanks! Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28854#pullrequestreview-3585197804 From almatvee at openjdk.org Tue Dec 16 22:46:03 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 16 Dec 2025 22:46:03 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v3] In-Reply-To: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> References: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> Message-ID: On Tue, 16 Dec 2025 16:59:08 GMT, Alexey Semenyuk wrote: >> - Append "Error: " prefix to error messages >> - Always print stack traces of internal exceptions, not only when running in verbose mode > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failure; Fix whitespaces src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java line 152: > 150: var errMsg = I18N.format("error.cert.not.found", certificateSelector.signingIdentities().getFirst(), > 151: keychain.map(Keychain::name).orElse("")); > 152: Log.error(I18N.format("message.error-header", errMsg)); Looks like it is only place which uses `message.error-header` directly. Do you know why? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28833#discussion_r2624992301 From duke at openjdk.org Tue Dec 16 22:52:13 2025 From: duke at openjdk.org (Ruben) Date: Tue, 16 Dec 2025 22:52:13 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs Message-ID: Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. Renaissance 0.15.0 benchmark results (MOVK-based scheme) Neoverse V1. The runs were limited to 16 cores. Number of runs: 6 for baseline, 6 for the changes - interleaved pairs. Command line: java -jar renaissance-jmh-0.15.0.jar \ -bm avgt -gc true -v extra \ -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ -XX:+UseG1GC' The change is geometric mean of ratios across 6 the pairs of runs. | Benchmark | Change | 90% CI for the change | | ----------------------------------------------------- | -------- | --------------------- | | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | | org.renaissance.scala.stm.JmhScalaStmBench7.run | -0.096% | -0.773% to 0.586% | | org.renaissance.twitter.finagle.JmhFinagleChirper.run | -0.200% | -1.143% to 0.698% | | org.renaissance.twitter.finagle.JmhFinagleHttp.run | -0.865% | -1.328% to -0.251% | |------------------------------------------------------------------------------------------| | Overall geometric mean: -0.459% change (90% CI: [-0.839%, -0.097%]) | |------------------------------------------------------------------------------------------| ------------- Commit messages: - 8373696: AArch64: Refine post-call NOPs - 8373696: AArch64: C1: Embed FP constants into the main code Changes: https://git.openjdk.org/jdk/pull/28855/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28855&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373696 Stats: 573 lines in 12 files changed: 473 ins; 42 del; 58 mod Patch: https://git.openjdk.org/jdk/pull/28855.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28855/head:pull/28855 PR: https://git.openjdk.org/jdk/pull/28855 From duke at openjdk.org Tue Dec 16 23:09:18 2025 From: duke at openjdk.org (eunbin son) Date: Tue, 16 Dec 2025 23:09:18 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v2] In-Reply-To: References: Message-ID: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son has updated the pull request incrementally with one additional commit since the last revision: 8373661: Address review feedback - Fixed code style issues - Added additional test case Thanks to @RogerRiggs for the feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/9e9cf422..0f1cab66 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=00-01 Stats: 287 lines in 1 file changed: 24 ins; 106 del; 157 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From duke at openjdk.org Tue Dec 16 23:09:19 2025 From: duke at openjdk.org (eunbin son) Date: Tue, 16 Dec 2025 23:09:19 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 13:22:40 GMT, eunbin son wrote: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" Thanks for reviews. I've completed the JUnit conversion as requested: - [?] Converted `BasicObjectsTest.java` to JUnit format - [?] Added all edge case tests using JUnit annotations - [?] All tests pass successfully The changes have been pushed. Please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3662806511 From duke at openjdk.org Tue Dec 16 23:16:42 2025 From: duke at openjdk.org (eunbin son) Date: Tue, 16 Dec 2025 23:16:42 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v3] In-Reply-To: References: Message-ID: <2SCiLVyYsKlpBQC40dsSD2BjETT4LpY6zXupX6bP7w0=.56344d0f-6222-41a7-a34c-ae277e5a047a@github.com> > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son 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: 8373661: Convert BasicObjectsTest to JUnit format - Converted all 17 test methods from jtreg main-method format to JUnit - Removed main() method - Added @run junit annotation - All tests follow OpenJDK JUnit testing patterns Thanks to @RogerRiggs for the feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/0f1cab66..03017eff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From liach at openjdk.org Tue Dec 16 23:30:14 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 23:30:14 GMT Subject: RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing Message-ID: This test incorrectly uses getFields to discover package-private fields, resulting in no VarHandle being tested. Without fixing that site, the newly added assertFalse fails. @JornVernee please review since you initially created this. This bug is discovered during junit migration attempt. I intentionally separated this for ease of backport all the way to 17, when this test was added. ------------- Commit messages: - 8373832 Changes: https://git.openjdk.org/jdk/pull/28858/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28858&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373832 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28858.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28858/head:pull/28858 PR: https://git.openjdk.org/jdk/pull/28858 From asemenyuk at openjdk.org Tue Dec 16 23:36:16 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 16 Dec 2025 23:36:16 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v3] In-Reply-To: References: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> Message-ID: On Tue, 16 Dec 2025 22:43:13 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix test failure; Fix whitespaces > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/SigningIdentityBuilder.java line 152: > >> 150: var errMsg = I18N.format("error.cert.not.found", certificateSelector.signingIdentities().getFirst(), >> 151: keychain.map(Keychain::name).orElse("")); >> 152: Log.error(I18N.format("message.error-header", errMsg)); > > Looks like it is only place which uses `message.error-header` directly. Do you know why? This is because ErrorTest expects two error messages when a certificate cannot be found [1]. One is `error.cert.not.found`, and another one is `error.explicit-sign-no-cert`. It has been like this all the time. Test cases for these keys were added in [JDK-8355328](https://bugs.openjdk.org/browse/JDK-8355328). Back in the day, these errors were reported from different locations. When `SigningIdentityBuilder.java` was added, the same function started reporting both errors. We can report only a single exception to the top-level error handler. So one error is reported in place, and another is reported with an exception. I can see now that `error.cert.not.found`, and `error.explicit-sign-no-cert` are duplicating each other. We need only one of them. I filed [JDK-83738330](https://bugs.openjdk.org/browse/JDK-83738330) to do this follow-up clean-up. [1] https://github.com/openjdk/jdk/blob/87d881fee01c42f5847031a63d50873b3d438f7a/test/jdk/tools/jpackage/share/ErrorTest.java#L703 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28833#discussion_r2625089412 From liach at openjdk.org Tue Dec 16 23:41:18 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 16 Dec 2025 23:41:18 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v3] In-Reply-To: <2SCiLVyYsKlpBQC40dsSD2BjETT4LpY6zXupX6bP7w0=.56344d0f-6222-41a7-a34c-ae277e5a047a@github.com> References: <2SCiLVyYsKlpBQC40dsSD2BjETT4LpY6zXupX6bP7w0=.56344d0f-6222-41a7-a34c-ae277e5a047a@github.com> Message-ID: On Tue, 16 Dec 2025 23:16:42 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son 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: > > 8373661: Convert BasicObjectsTest to JUnit format > > - Converted all 17 test methods from jtreg main-method format to JUnit > - Removed main() method > - Added @run junit annotation > - All tests follow OpenJDK JUnit testing patterns > > Thanks to @RogerRiggs for the feedback. test/jdk/java/util/Objects/BasicObjectsTest.java line 305: > 303: RuntimeException.class, > 304: () -> Objects.requireNonNull(null, () -> { > 305: throw new RuntimeException("Supplier exception"); Instead of detecting by message, you can allocate an exception outside of the lambda, throw it here, and assertSame your exception with the assertThrows returned exception. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2625097382 From vklang at openjdk.org Tue Dec 16 23:54:51 2025 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 16 Dec 2025 23:54:51 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 16 Dec 2025 19:12:24 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Relax orderings in push src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1268: > 1266: pool != null) > 1267: pool.signalWork(this, s); // may have appeared empty > 1268: } else throw new RejectedExecutionException("Queue capacity exceeded"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2625121121 From almatvee at openjdk.org Tue Dec 16 23:59:55 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 16 Dec 2025 23:59:55 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v3] In-Reply-To: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> References: <9mUIQtLU2-M__j0aMXOjmVEG5aaSpPErqG_v_z8x0NM=.8b6eacfb-a96c-4db1-9696-09e4e7387bf6@github.com> Message-ID: On Tue, 16 Dec 2025 16:59:08 GMT, Alexey Semenyuk wrote: >> - Append "Error: " prefix to error messages >> - Always print stack traces of internal exceptions, not only when running in verbose mode > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Fix test failure; Fix whitespaces Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28833#pullrequestreview-3585429297 From vklang at openjdk.org Wed Dec 17 00:06:52 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 17 Dec 2025 00:06:52 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 16 Dec 2025 19:12:24 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Relax orderings in push src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1260: > 1258: ForkJoinTask[] a = array; > 1259: int size = s - base + 1, m; > 1260: if (((a != null && a.length > size) || (a = growArray(a, s)) != null) && Instruction ordering reason to assign the size ahead of the `if`? ? int m; if (((a != null && a.length > (s - base + 1)) || (a = growArray(a, s)) != null) && ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2625146420 From vklang at openjdk.org Wed Dec 17 00:09:53 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 17 Dec 2025 00:09:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 16 Dec 2025 19:12:24 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Relax orderings in push src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1300: > 1298: } > 1299: top = s; // back out > 1300: if ((phase & 1) == 0) // unlock if external I presume the read of `phase` is very much intentional here (otherwise passing in boolean internal as a param would make sense), so it might be worth adding the reason for reading phase on this line? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2625152528 From jvernee at openjdk.org Wed Dec 17 00:35:49 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Dec 2025 00:35:49 GMT Subject: RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 23:23:02 GMT, Chen Liang wrote: > This test incorrectly uses getFields to discover package-private fields, resulting in no VarHandle being tested. Without fixing that site, the newly added assertFalse fails. > > @JornVernee please review since you initially created this. > > This bug is discovered during junit migration attempt. I intentionally separated this for ease of backport all the way to 17, when this test was added. Good catch ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28858#pullrequestreview-3585505598 From shade at openjdk.org Wed Dec 17 08:48:21 2025 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 17 Dec 2025 08:48:21 GMT Subject: RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 23:23:02 GMT, Chen Liang wrote: > This test incorrectly uses getFields to discover package-private fields, resulting in no VarHandle being tested. Without fixing that site, the newly added assertFalse fails. > > @JornVernee please review since you initially created this. > > This bug is discovered during junit migration attempt. I intentionally separated this for ease of backport all the way to 17, when this test was added. Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28858#pullrequestreview-3586618371 From hannesw at openjdk.org Wed Dec 17 08:52:41 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 17 Dec 2025 08:52:41 GMT Subject: RFR: 8309748: Improve host selection in `External Specifications` page Message-ID: Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html) - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired. ------------- Commit messages: - 8309748: Improve host selection in `External Specifications` page Changes: https://git.openjdk.org/jdk/pull/28863/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309748 Stats: 97 lines in 5 files changed: 71 ins; 3 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/28863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28863/head:pull/28863 PR: https://git.openjdk.org/jdk/pull/28863 From duke at openjdk.org Wed Dec 17 09:04:06 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 17 Dec 2025 09:04:06 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 src/java.base/share/classes/java/time/format/Parsed.java line 175: > 173: */ > 174: @SuppressWarnings("unchecked") > 175: Parsed(boolean onlyChronoField) { If you know that only ChronoFields are used then imho the loop over the entries of `fieldValues` in method `resolveFields` can be skipped (line 290ff). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2626170333 From alanb at openjdk.org Wed Dec 17 09:09:27 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Dec 2025 09:09:27 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 16 Dec 2025 19:12:24 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with one additional commit since the last revision: > > Relax orderings in push The change to relax orderings in push means that java/lang/Thread/virtual/Starvation.java now failing very frequently, on both x64 and aarch64. So this may tell us something. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28797#issuecomment-3664358162 From alanb at openjdk.org Wed Dec 17 09:27:58 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Dec 2025 09:27:58 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit In-Reply-To: References: Message-ID: <5wahWkupAXES5aEY6cEB1vxQ4i5NshpgMX76ZfJCivE=.2591e568-8c47-437d-962b-008d09dd2948@github.com> On Tue, 16 Dec 2025 15:05:03 GMT, Raffaello Giulietti wrote: >> test/jdk/java/math/BigDecimal/Constructor.java line 71: >> >>> 69: } else { >>> 70: throw nfe; >>> 71: } >> >> If you want, you could use `NumberFormatException nfe = assertThrows(..)` here, then assert the cause. That would avoid mixing JUnit asserts with explicit throw of RuntimeException. > > That's just the result of a mechanical conversion of the original testng-based code. Okay, but you could go the extra mile and replace the throw of RuntimeException as it looks very strange to have the test be a JUnit test and still have this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28848#discussion_r2626254818 From rgiulietti at openjdk.org Wed Dec 17 09:27:59 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Dec 2025 09:27:59 GMT Subject: Integrated: 8373798: Refactor java/math tests to use JUnit In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 14:38:07 GMT, Raffaello Giulietti wrote: > Replace testng framework with junit This pull request has now been integrated. Changeset: fc76403b Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/fc76403b01c4e801f2a58810deeec2a6ebfa8458 Stats: 124 lines in 2 files changed: 43 ins; 11 del; 70 mod 8373798: Refactor java/math tests to use JUnit Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/28848 From rgiulietti at openjdk.org Wed Dec 17 09:32:58 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Dec 2025 09:32:58 GMT Subject: RFR: 8373798: Refactor java/math tests to use JUnit In-Reply-To: <5wahWkupAXES5aEY6cEB1vxQ4i5NshpgMX76ZfJCivE=.2591e568-8c47-437d-962b-008d09dd2948@github.com> References: <5wahWkupAXES5aEY6cEB1vxQ4i5NshpgMX76ZfJCivE=.2591e568-8c47-437d-962b-008d09dd2948@github.com> Message-ID: On Wed, 17 Dec 2025 09:25:11 GMT, Alan Bateman wrote: >> That's just the result of a mechanical conversion of the original testng-based code. > > Okay, but you could go the extra mile and replace the throw of RuntimeException as it looks very strange to have the test be a JUnit test and still have this. It is my plan to review all numerics related tests, rewriting some of those that do not use any framework to use junit in the end. For now, the priority is to remove the dependencies on testng. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28848#discussion_r2626271021 From aph at openjdk.org Wed Dec 17 09:35:48 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 17 Dec 2025 09:35:48 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 22:45:08 GMT, Ruben wrote: > Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. > > Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. > > Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. > > > Renaissance 0.15.0 benchmark results (MOVK-based scheme) > Neoverse V1. > The runs were limited to 16 cores. > > Number of runs: > 6 for baseline, 6 for the changes - interleaved pairs. > > Command line: > java -jar renaissance-jmh-0.15.0.jar \ > -bm avgt -gc true -v extra \ > -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ > -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ > -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ > -XX:+UseG1GC' > > The change is geometric mean of ratios across 6 the pairs of runs. > > | Benchmark | Change | 90% CI for the change | > | ----------------------------------------------------- | -------- | --------------------- | > | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | > | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | > | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | > | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | > | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | > | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | > | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | > | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | > | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | > | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | > | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | > | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | > | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | > | org.renaissance.scala.stm.JmhScalaStmBench7.run | -0.096% | -0.773% to 0.586% | > | org.renaissance.twitter.finagle.J... While the basic idea is a good one, I think there are better ways to do it. Consider fixing the number of instructions to two rather than three. Then a post-call NOP can be either 'nop; movk/movz` or `b.nv; movk/adrp`. Or something similar.. `b.nv` is more expensive, but should be rare. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3664486119 From erfang at openjdk.org Wed Dec 17 10:17:42 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 17 Dec 2025 10:17:42 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: <_83w1j5POhabfLjcO-tiFEmS4LB31hGJIxTW-2fkBKE=.a5f12f59-4225-4f7c-8966-4e2708b7bb5a@github.com> Message-ID: <_mYdgiXX_AOJLvk-X0yS_Wx1byEukpDdNVyUFAHPDrM=.d86ad224-626b-4381-9f64-6af9842131a6@github.com> On Tue, 16 Dec 2025 17:47:42 GMT, Quan Anh Mai wrote: >> @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! > > Then, please add tests to verify the correctness of these identity value (i.e. `x + i == x`). Yeah, I have added two tests for these constants, see https://github.com/openjdk/jdk/pull/28692/changes#diff-18d929c1615a4dbad7c65daa66edc98fa1537968fa14a2b8105145d18e9eb12fR6471. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2626433209 From erfang at openjdk.org Wed Dec 17 10:22:17 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 17 Dec 2025 10:22:17 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 03:31:07 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 pull request now contains four commits: > > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - 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. @merykitty @PaulSandoz thanks for your feedbacks, I will make the necessary revisions based on your suggestions shortly. Please continue to review the PR if you have any further suggestions. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3664661062 From abimpoudis at openjdk.org Wed Dec 17 10:34:09 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 17 Dec 2025 10:34:09 GMT Subject: Integrated: 8373552: ExactConversionsSupport: bad JLS links in javadoc In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 20:50:31 GMT, Aggelos Biboudis wrote: > Add relative links to the spec URL of primitive-types-in-patterns-instanceof-switch-jls.html This pull request has now been integrated. Changeset: 9a23f8aa Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/9a23f8aa337e1292179625ce9bb8abe22c9e22e2 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8373552: ExactConversionsSupport: bad JLS links in javadoc Reviewed-by: liach, iris ------------- PR: https://git.openjdk.org/jdk/pull/28775 From aturbanov at openjdk.org Wed Dec 17 10:43:54 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Wed, 17 Dec 2025 10:43:54 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests In-Reply-To: References: Message-ID: <9vaoIacqeQtaDtLMMicjQ5L2TqbqgPFasZBuIT7-t2M=.4ad31447-cf97-4081-bcdc-65c57baf88af@github.com> On Mon, 15 Dec 2025 14:27:14 GMT, SendaoYan wrote: > Hi all, > > This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. > > Thanks! test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 293: > 291: */ > 292: public static void removeDockerImage(String imageNameAndTag) throws Exception { > 293: if(!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { Suggestion: if (!DockerTestUtils.RETAIN_IMAGE_AFTER_TEST) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28826#discussion_r2626526625 From bkilambi at openjdk.org Wed Dec 17 10:45:46 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 17 Dec 2025 10:45:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: > 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 ... Bhavana Kilambi 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: - Address review comments - Merge 'master' - 8366444: Add support for add/mul reduction operations for Float16 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 mul reduction respectively. V1 (UseSVE = 1, max vector length = 32B): Benchmark vectorDim Mode Cnt 8B 16B 32B ReductionAddFP16 256 thrpt 9 1.11 1.75 2.02 ReductionAddFP16 512 thrpt 9 1.02 1.64 1.93 ReductionAddFP16 1024 thrpt 9 1.02 1.59 1.85 ReductionAddFP16 2048 thrpt 9 1.02 1.56 1.80 ReductionMulFP16 256 thrpt 9 1.12 0.99 1.09 ReductionMulFP16 512 thrpt 9 1.04 1.01 1.04 ReductionMulFP16 1024 thrpt 9 1.02 1.02 1.00 ReductionMulFP16 2048 thrpt 9 1.01 1.01 1.00 On V1, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be generated for AddReductionVHF/MulReductionVHF as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: scalarized "fmul" sequence is generated for MulReductionVHF and "fadda" is generated for AddReductionVHF which fetches signficant gains. For MaxVectorSize = 32: Autovectorization of MulReductionVHF is disabled for MaxVectorSize > 16B so the autovectorizer checks for maximal implemented size[1] which is 16B and generates scalarized "fmul" sequence for 16B in this case. For AddReductionVHF, it generates the "fadda" instruction. V2 (UseSVE = 2, max vector length = 16B) Benchmark vectorDim Mode Cnt 8B 16B ReductionAddFP16 256 thrpt 9 1.16 1.70 ReductionAddFP16 512 thrpt 9 1.02 1.61 ReductionAddFP16 1024 thrpt 9 1.01 1.53 ReductionAddFP16 2048 thrpt 9 1.00 1.49 ReductionMulFP16 256 thrpt 9 1.18 0.99 ReductionMulFP16 512 thrpt 9 1.04 1.01 ReductionMulFP16 1024 thrpt 9 1.02 1.02 ReductionMulFP16 2048 thrpt 9 1.01 1.01 On V2, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be generated as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: "fadda" instruction is generated for AddReductionVHF which results in significant gains in performance. For MulReductionVHF, the scalarized "fmul" sequence will be generated. Testing: hotspot_all, jdk(tiers1-3) and langtools(tier1) all pass on N1/V1/V2. [1] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/share/opto/superword.cpp#L1677 [2] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L479 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27526/files - new: https://git.openjdk.org/jdk/pull/27526/files/b8eb35ba..e8e3989d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=00-01 Stats: 432095 lines in 4952 files changed: 278406 ins; 97133 del; 56556 mod Patch: https://git.openjdk.org/jdk/pull/27526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526 PR: https://git.openjdk.org/jdk/pull/27526 From bkilambi at openjdk.org Wed Dec 17 10:45:48 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Wed, 17 Dec 2025 10:45:48 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! Hi @marc-chevalier @XiaohongGong I have addressed your review comments. Apologies for the delay in responding. Please take a look at the new patchset. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3664751991 From aph at openjdk.org Wed Dec 17 11:22:57 2025 From: aph at openjdk.org (Andrew Haley) Date: Wed, 17 Dec 2025 11:22:57 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: Message-ID: <3vwwr8CwTPqUSBQTOeUca6QtEMuVqxkuhebFvR2BLL8=.e6ba9a3b-31a9-4d9c-990b-37ab628a4bd4@github.com> On Tue, 16 Dec 2025 22:45:08 GMT, Ruben wrote: > Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. > > Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. > > Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. > > > Renaissance 0.15.0 benchmark results (MOVK-based scheme) > Neoverse V1. > The runs were limited to 16 cores. > > Number of runs: > 6 for baseline, 6 for the changes - interleaved pairs. > > Command line: > java -jar renaissance-jmh-0.15.0.jar \ > -bm avgt -gc true -v extra \ > -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ > -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ > -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ > -XX:+UseG1GC' > > The change is geometric mean of ratios across 6 the pairs of runs. > > | Benchmark | Change | 90% CI for the change | > | ----------------------------------------------------- | -------- | --------------------- | > | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | > | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | > | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | > | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | > | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | > | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | > | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | > | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | > | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | > | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | > | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | > | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | > | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | > | org.renaissance.scala.stm.JmhScalaStmBench7.run | -0.096% | -0.773% to 0.586% | > | org.renaissance.twitter.finagle.J... src/hotspot/cpu/aarch64/c1_LIRAssembler_aarch64.cpp line 140: > 138: } > 139: } > 140: This shouldn't be here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28855#discussion_r2626663660 From duke at openjdk.org Wed Dec 17 11:50:53 2025 From: duke at openjdk.org (eunbin son) Date: Wed, 17 Dec 2025 11:50:53 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v4] In-Reply-To: References: Message-ID: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son has updated the pull request incrementally with one additional commit since the last revision: 8373661: Use assertSame for exception instance verification Updated testRequireNonNullWithSupplierThrowingException to allocate the exception outside of the lambda and use assertSame to verify the same exception instance is thrown, as suggested by @liach. This provides a more precise verification that the exception from the supplier is thrown directly, not wrapped. Thanks to @liach for the feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/03017eff..3986ed4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=02-03 Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From duke at openjdk.org Wed Dec 17 11:50:56 2025 From: duke at openjdk.org (eunbin son) Date: Wed, 17 Dec 2025 11:50:56 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v3] In-Reply-To: References: <2SCiLVyYsKlpBQC40dsSD2BjETT4LpY6zXupX6bP7w0=.56344d0f-6222-41a7-a34c-ae277e5a047a@github.com> Message-ID: On Tue, 16 Dec 2025 23:37:59 GMT, Chen Liang wrote: >> eunbin son 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: >> >> 8373661: Convert BasicObjectsTest to JUnit format >> >> - Converted all 17 test methods from jtreg main-method format to JUnit >> - Removed main() method >> - Added @run junit annotation >> - All tests follow OpenJDK JUnit testing patterns >> >> Thanks to @RogerRiggs for the feedback. > > test/jdk/java/util/Objects/BasicObjectsTest.java line 305: > >> 303: RuntimeException.class, >> 304: () -> Objects.requireNonNull(null, () -> { >> 305: throw new RuntimeException("Supplier exception"); > > Instead of detecting by message, you can allocate an exception outside of the lambda, throw it here, and assertSame your exception with the assertThrows returned exception. @liach Thank you for the feedback! I've updated the test to allocate the exception outside of the lambda and use `assertSame` to verify the same exception instance is thrown, as you suggested. This provides a more precise verification that the exception from the supplier is thrown directly, not wrapped. The changes have been pushed. Please review again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2626741691 From syan at openjdk.org Wed Dec 17 11:52:45 2025 From: syan at openjdk.org (SendaoYan) Date: Wed, 17 Dec 2025 11:52:45 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: > Hi all, > > This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. > > Thanks! SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Add an whitespace after if Co-authored-by: Andrey Turbanov ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28826/files - new: https://git.openjdk.org/jdk/pull/28826/files/d66b7695..ae10ac54 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28826&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28826.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28826/head:pull/28826 PR: https://git.openjdk.org/jdk/pull/28826 From duke at openjdk.org Wed Dec 17 12:13:34 2025 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 17 Dec 2025 12:13:34 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 src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 551: > 549: * This is used to optimize the storage of parsed field values in the Parsed class. > 550: */ > 551: final boolean onlyChronoField; If you add to DateTimePrinterParser the method: public default boolean onlyChronoFields() { return true; } and override in CompositePrinterParser, NumberPrinterParser, TextPrinterParser, DefaultValueParser with obvious implementations you should be able to get rid of this field, same in DateTimeFormatterBuilder. (Or keep the field, but initialize in the constructor from printerParser). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2626818693 From hannesw at openjdk.org Wed Dec 17 12:24:22 2025 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Wed, 17 Dec 2025 12:24:22 GMT Subject: RFR: 8309748: Improve host selection in `External Specifications` page [v2] In-Reply-To: References: Message-ID: > Please review a change to improve selection by host name in the External Specifications page. After trying a list of checkboxes as used in the API summary pages and finding it not a suitable solution, I found that a select/dropdown menu works best for this page. > > - [New external specs page](https://cr.openjdk.org/~hannesw/8309748/api.00/external-specs.html) > - [Old external specs page](https://docs.oracle.com/en/java/javase/25/docs/api/external-specs.html) for comparsion > > I also updated `@spec` tags in `java.lang.Character` to point to `www.unicode.org` rather than `unicode.org` to avoid a `unicode.org` entry in the host list (other `@spec` tags use the `www.unicode.org` host name). The short `unicode.org` URL is still used elsewhere in the `java.lang.Character` class, I can update those links to the canonical host name as well if desired. Hannes Walln?fer has updated the pull request incrementally with one additional commit since the last revision: Remove pointless parentheses ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28863/files - new: https://git.openjdk.org/jdk/pull/28863/files/4587271c..fe88df58 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28863&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28863.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28863/head:pull/28863 PR: https://git.openjdk.org/jdk/pull/28863 From alanb at openjdk.org Wed Dec 17 12:43:11 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Dec 2025 12:43:11 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 18:54: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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - 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 > - ... and 4 more: https://git.openjdk.org/jdk/compare/c6348e62...567e8925 Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3587543908 From mchevalier at openjdk.org Wed Dec 17 12:43:16 2025 From: mchevalier at openjdk.org (Marc Chevalier) Date: Wed, 17 Dec 2025 12:43:16 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Wed, 17 Dec 2025 10:45:46 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 gener... > > Bhavana Kilambi 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: > > - Address review comments > - Merge 'master' > - 8366444: Add support for add/mul reduction operations for Float16 > > 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 > Redu... Changes requested by mchevalier (Committer). src/hotspot/share/opto/vectornode.hpp line 328: > 326: ReductionNode(ctrl, in1, in2), _requires_strict_order(requires_strict_order) {} > 327: > 328: virtual int Opcode() const; Build is failing on Mac because of `-Winconsistent-missing-override`: since you specified `override` on `bottom_type` and `ideal_reg`, you need to put `override` everywhere it applies. That means `Opcode` `requires_strict_order`, `hash`, `cmp` and `size_of`. And same in `MulReductionVHFNode`. ------------- PR Review: https://git.openjdk.org/jdk/pull/27526#pullrequestreview-3587543752 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2626909207 From dl at openjdk.org Wed Dec 17 12:55:06 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 17 Dec 2025 12:55:06 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v8] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Another diagnostic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/7cc2dd1a..debaf274 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=06-07 Stats: 14 lines in 1 file changed: 1 ins; 1 del; 12 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 jbhateja at openjdk.org Wed Dec 17 12:56:01 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 17 Dec 2025 12:56:01 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] 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 23 commits: - Fix from Bhavana Kilambi for failing JTREG regressions on AARCH64 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Including test changes from Bhavana Kilambi (ARM) - 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 - ... and 13 more: https://git.openjdk.org/jdk/compare/5e7ae281...703f313d ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 515408 lines in 232 files changed: 284464 ins; 229217 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 dl at openjdk.org Wed Dec 17 13:02:23 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 17 Dec 2025 13:02:23 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v9] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 12 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Another diagnostic - Relax orderings in push - Reduce fencing - Adjust runworker for previous update - Reorder signalWork filter - Revert topLevelExec - Merge branch 'openjdk:master' into JDK-8373118 - Address review comments - signalWork diagnostic - ... and 2 more: https://git.openjdk.org/jdk/compare/a99e3875...9b2f082d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/debaf274..9b2f082d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=07-08 Stats: 8648 lines in 356 files changed: 5837 ins; 1035 del; 1776 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 duke at openjdk.org Wed Dec 17 13:05:04 2025 From: duke at openjdk.org (eunbin son) Date: Wed, 17 Dec 2025 13:05:04 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes Message-ID: ## Summary Add explicit null check using `Objects.requireNonNull` in `DataOutputStream.writeBytes(String s)` to provide a clearer error message and make the API contract explicit. ## Problem The `writeBytes` method currently throws a `NullPointerException` when `null` is passed, but the error message may not be clear in all contexts. While JDK 14+ provides helpful NullPointerException messages through JEP 358 (Helpful NullPointerExceptions), adding an explicit null check using `Objects.requireNonNull` makes the API contract more explicit and provides consistent error messaging across different JDK versions. ## Solution Added `Objects.requireNonNull(s, "s")` at the beginning of the `writeBytes(String s)` method. This ensures: - A clear error message ("s") is provided when null is passed - The API contract explicitly states that null is not allowed - The method fails fast with a descriptive exception ## Issue Fixes JDK-8373660 **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 ## Type of Change - [x] Test addition/modification - [x] Bug fix - [ ] New feature - [ ] Documentation improvement - [ ] Refactoring ## Testing A new JUnit test has been added to verify the null check behavior: # Run the specific JUnit test file make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" # Or run all tests in the DataOutputStream directory make test TEST="jtreg:test/jdk/java/io/DataOutputStream" ------------- Commit messages: - 8373660: Add explicit null check in DataOutputStream.writeBytes Changes: https://git.openjdk.org/jdk/pull/28869/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28869&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373660 Stats: 30 lines in 2 files changed: 30 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28869.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28869/head:pull/28869 PR: https://git.openjdk.org/jdk/pull/28869 From dl at openjdk.org Wed Dec 17 13:06:33 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 17 Dec 2025 13:06:33 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 17 Dec 2025 00:07:28 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Relax orderings in push > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1300: > >> 1298: } >> 1299: top = s; // back out >> 1300: if ((phase & 1) == 0) // unlock if external > > I presume the read of `phase` is very much intentional here (otherwise passing in boolean internal as a param would make sense), so it might be worth adding the reason for reading phase on this line? ? Yes. The main reason is that I had needed growArray in bulk-steal exploration (but not committed) and needed version without argument). But then noticed that there's no reason to have arg for a case that almost never happens. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2626993923 From vklang at openjdk.org Wed Dec 17 13:10:16 2025 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 17 Dec 2025 13:10:16 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 17 Dec 2025 13:03:44 GMT, Doug Lea
wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1300: >> >>> 1298: } >>> 1299: top = s; // back out >>> 1300: if ((phase & 1) == 0) // unlock if external >> >> I presume the read of `phase` is very much intentional here (otherwise passing in boolean internal as a param would make sense), so it might be worth adding the reason for reading phase on this line? ? > > Yes. The main reason is that I had needed growArray in bulk-steal exploration (but not committed) and needed version without argument). But then noticed that there's no reason to have arg for a case that almost never happens. Makes sense, thanks for confirming ? :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2627005262 From dl at openjdk.org Wed Dec 17 13:16:13 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 17 Dec 2025 13:16:13 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v7] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <08NA268jiMZFwN43Jmlcrx560Ye-nLrLcUgfkqNWDhQ=.423e3510-93f8-4bdc-a4f2-145a0bdbf70b@github.com> On Wed, 17 Dec 2025 00:04:29 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Relax orderings in push > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1260: > >> 1258: ForkJoinTask[] a = array; >> 1259: int size = s - base + 1, m; >> 1260: if (((a != null && a.length > size) || (a = growArray(a, s)) != null) && > > Instruction ordering reason to assign the size ahead of the `if`? ? > > > int m; > if (((a != null && a.length > (s - base + 1)) || (a = growArray(a, s)) != null) && (Now reworked a little...) Well, mainly trying to simply the conditional while avoiding possibly-uninitialized errors ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2627024361 From alanb at openjdk.org Wed Dec 17 13:39:46 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 17 Dec 2025 13:39:46 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 12:56:14 GMT, eunbin son wrote: > Add explicit null check using Objects.requireNonNull in DataOutputStream.writeBytes(String s) to provide a clearer error message and make the API contract explicit. Can you paste in the existing NPE message vs. the new NPE message? With Helpful NPEs (JEP 358), there is a less need to make changes like this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3665396706 From jvernee at openjdk.org Wed Dec 17 13:55:06 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Dec 2025 13:55:06 GMT Subject: RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free Message-ID: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> ASAN correctly detected a use-after-free in this test. The issue is that an async `ScopedAccessError` is thrown while executing java code as part of a JVMTI callback. This exception is meant to unwind out of a scoped memory access, to prevent access to memory that has already been freed. But, currently the native agent code is printing and clearing the exception, which doesn't prevent the memory access from occurring, leading to a use-after-free. Ideally, the agent should propagate the exception to the place in the Java code where the JVMTI event happens, but it is not possible to exit the callback with a pending exception, and AFAICT there is no JVMTI API for propagating async exceptions that are thrown during a JVMTI callback. So, the only sane thing the test can do is exit the process, which is what I've implemented here. This fixes the test, but it leaves the larger question of how JVMTI agents should deal with async exceptions unresolved. ------------- Commit messages: - Cleanup memory management code - Terminate after receiving ScopedAccessError Changes: https://git.openjdk.org/jdk/pull/28853/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28853&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372493 Stats: 41 lines in 2 files changed: 27 ins; 5 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28853.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28853/head:pull/28853 PR: https://git.openjdk.org/jdk/pull/28853 From liach at openjdk.org Wed Dec 17 13:55:08 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 13:55:08 GMT Subject: RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> References: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> Message-ID: <99NuH0trLDfPeoEyDvvNMnE4_oMblU95Ul71rXJxvFg=.b8b6232e-60ab-4cbf-8bf3-587ad4aca86d@github.com> On Tue, 16 Dec 2025 18:47:34 GMT, Jorn Vernee wrote: > ASAN correctly detected a use-after-free in this test. > > The issue is that an async `ScopedAccessError` is thrown while executing java code as part of a JVMTI callback. This exception is meant to unwind out of a scoped memory access, to prevent access to memory that has already been freed. But, currently the native agent code is printing and clearing the exception, which doesn't prevent the memory access from occurring, leading to a use-after-free. > > Ideally, the agent should propagate the exception to the place in the Java code where the JVMTI event happens, but it is not possible to exit the callback with a pending exception, and AFAICT there is no JVMTI API for propagating async exceptions that are thrown during a JVMTI callback. So, the only sane thing the test can do is exit the process, which is what I've implemented here. > > This fixes the test, but it leaves the larger question of how JVMTI agents should deal with async exceptions unresolved. The updated logic in the test looks clear. And it properly prevents the asan-identified access from happening. test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp line 109: > 107: jni_env->ExceptionDescribe(); > 108: if (jni_env->IsInstanceOf(ex, EXCEPTION_CLS)) { > 109: exit(0); // success Just curious, does this just terminate the agent? If this terminates the JVM, how is the checked string printed: output.stderrShouldContain("Exception in thread "Trigger" jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError: Invalid memory access"); test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp line 115: > 113: } > 114: > 115: jvmti_env->Deallocate((unsigned char*) method_name); We can move the 2 Deallocate to right above CallStaticVoidMethod. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28853#pullrequestreview-3585028117 PR Review Comment: https://git.openjdk.org/jdk/pull/28853#discussion_r2624622160 PR Review Comment: https://git.openjdk.org/jdk/pull/28853#discussion_r2624619545 From jvernee at openjdk.org Wed Dec 17 13:55:10 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Dec 2025 13:55:10 GMT Subject: RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> References: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> Message-ID: On Tue, 16 Dec 2025 18:47:34 GMT, Jorn Vernee wrote: > ASAN correctly detected a use-after-free in this test. > > The issue is that an async `ScopedAccessError` is thrown while executing java code as part of a JVMTI callback. This exception is meant to unwind out of a scoped memory access, to prevent access to memory that has already been freed. But, currently the native agent code is printing and clearing the exception, which doesn't prevent the memory access from occurring, leading to a use-after-free. > > Ideally, the agent should propagate the exception to the place in the Java code where the JVMTI event happens, but it is not possible to exit the callback with a pending exception, and AFAICT there is no JVMTI API for propagating async exceptions that are thrown during a JVMTI callback. So, the only sane thing the test can do is exit the process, which is what I've implemented here. > > This fixes the test, but it leaves the larger question of how JVMTI agents should deal with async exceptions unresolved. test/jdk/java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java line 86: > 84: SINK = segment.get(ValueLayout.JAVA_INT, 0); // should throw > 85: System.err.println("No exception thrown during outer memory access"); > 86: System.exit(1); This code is never executed because we terminate the process during the memory access before this, but this check was missing from the initial implementation of the test. This memory access should not complete normally. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28853#discussion_r2624388615 From jvernee at openjdk.org Wed Dec 17 13:55:10 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 17 Dec 2025 13:55:10 GMT Subject: RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: <99NuH0trLDfPeoEyDvvNMnE4_oMblU95Ul71rXJxvFg=.b8b6232e-60ab-4cbf-8bf3-587ad4aca86d@github.com> References: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> <99NuH0trLDfPeoEyDvvNMnE4_oMblU95Ul71rXJxvFg=.b8b6232e-60ab-4cbf-8bf3-587ad4aca86d@github.com> Message-ID: On Tue, 16 Dec 2025 20:21:59 GMT, Chen Liang wrote: >> ASAN correctly detected a use-after-free in this test. >> >> The issue is that an async `ScopedAccessError` is thrown while executing java code as part of a JVMTI callback. This exception is meant to unwind out of a scoped memory access, to prevent access to memory that has already been freed. But, currently the native agent code is printing and clearing the exception, which doesn't prevent the memory access from occurring, leading to a use-after-free. >> >> Ideally, the agent should propagate the exception to the place in the Java code where the JVMTI event happens, but it is not possible to exit the callback with a pending exception, and AFAICT there is no JVMTI API for propagating async exceptions that are thrown during a JVMTI callback. So, the only sane thing the test can do is exit the process, which is what I've implemented here. >> >> This fixes the test, but it leaves the larger question of how JVMTI agents should deal with async exceptions unresolved. > > test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp line 109: > >> 107: jni_env->ExceptionDescribe(); >> 108: if (jni_env->IsInstanceOf(ex, EXCEPTION_CLS)) { >> 109: exit(0); // success > > Just curious, does this just terminate the agent? If this terminates the JVM, how is the checked string printed: > > output.stderrShouldContain("Exception in thread "Trigger" jdk.internal.misc.ScopedMemoryAccess$ScopedAccessError: Invalid memory access"); It terminates the VM. That string is printed by `ExceptionDescribe()` > test/jdk/java/foreign/sharedclosejvmti/libSharedCloseAgent.cpp line 115: > >> 113: } >> 114: >> 115: jvmti_env->Deallocate((unsigned char*) method_name); > > We can move the 2 Deallocate to right above CallStaticVoidMethod. Cleaned this code up a bit. We just need one call to `Deallocate` for each string. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28853#discussion_r2624641725 PR Review Comment: https://git.openjdk.org/jdk/pull/28853#discussion_r2624662418 From abimpoudis at openjdk.org Wed Dec 17 13:58:05 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Wed, 17 Dec 2025 13:58:05 GMT Subject: [jdk26] RFR: 8373552: ExactConversionsSupport: bad JLS links in javadoc Message-ID: Hi all, This pull request contains a backport of commit [9a23f8aa](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/9a23f8aa337e1292179625ce9bb8abe22c9e22e2__;!!ACWV5N9M2RV99hQ!ODxLmrmWdnBMblnjNoeOr6ngrizirMDIh6Jg5qb80Req5yuCrVFSD6xAMZA9Z0Dz0hixsZx2wYBErPApp89s8baaWJ04oOE$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Aggelos Biboudis on 17 Dec 2025 and was reviewed by Chen Liang and Iris Clark. Thanks! ------------- Commit messages: - Backport 9a23f8aa337e1292179625ce9bb8abe22c9e22e2 Changes: https://git.openjdk.org/jdk/pull/28870/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28870&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/28870.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28870/head:pull/28870 PR: https://git.openjdk.org/jdk/pull/28870 From heidinga at openjdk.org Wed Dec 17 14:29:10 2025 From: heidinga at openjdk.org (Dan Heidinga) Date: Wed, 17 Dec 2025 14:29:10 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`. Marked as reviewed by heidinga (no project role). ------------- PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3588008090 From dl at openjdk.org Wed Dec 17 14:42:36 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 17 Dec 2025 14:42:36 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v10] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <4xPa_yGMj3w-VUfzEmKGwmKvYB2yekkSWbIpmLiWgDw=.b6371d34-af97-404d-8693-ccc9b32d11e0@github.com> > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Avoid double-filtering ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/9b2f082d..45f8a9a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=08-09 Stats: 15 lines in 1 file changed: 8 ins; 2 del; 5 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 liach at openjdk.org Wed Dec 17 14:49:18 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 14:49:18 GMT Subject: [jdk26] RFR: 8373552: ExactConversionsSupport: bad JLS links in javadoc In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 13:44:56 GMT, Aggelos Biboudis wrote: > Hi all, > > This pull request contains a backport of commit [9a23f8aa](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/9a23f8aa337e1292179625ce9bb8abe22c9e22e2__;!!ACWV5N9M2RV99hQ!ODxLmrmWdnBMblnjNoeOr6ngrizirMDIh6Jg5qb80Req5yuCrVFSD6xAMZA9Z0Dz0hixsZx2wYBErPApp89s8baaWJ04oOE$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Aggelos Biboudis on 17 Dec 2025 and was reviewed by Chen Liang and Iris Clark. > > Thanks! Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28870#pullrequestreview-3588097207 From asemenyuk at openjdk.org Wed Dec 17 14:54:57 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Dec 2025 14:54:57 GMT Subject: RFR: 8373887: jpackage tests may potentially deadlock Message-ID: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> Fix potential deadlock in `jdk.jpackage.test.Executor.runExecutable()`: read subprocess's output streams concurrently in separate threads instead of reading them sequentially from the same thread. This change required updating some test cases in the corresponding unit test. ------------- Commit messages: - Fix WinResourceTest deadlock Changes: https://git.openjdk.org/jdk/pull/28872/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28872&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373887 Stats: 42 lines in 2 files changed: 38 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28872.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28872/head:pull/28872 PR: https://git.openjdk.org/jdk/pull/28872 From asemenyuk at openjdk.org Wed Dec 17 15:21:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Dec 2025 15:21:54 GMT Subject: RFR: 8373887: jpackage tests may potentially deadlock [v2] In-Reply-To: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> References: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> Message-ID: > Fix potential deadlock in `jdk.jpackage.test.Executor.runExecutable()`: read subprocess's output streams concurrently in separate threads instead of reading them sequentially from the same thread. > > This change required updating some test cases in the corresponding unit test. Alexey Semenyuk 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: Fix WinResourceTest deadlock ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28872/files - new: https://git.openjdk.org/jdk/pull/28872/files/04f3423e..4c1a8535 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28872&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28872&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28872.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28872/head:pull/28872 PR: https://git.openjdk.org/jdk/pull/28872 From asemenyuk at openjdk.org Wed Dec 17 15:30:36 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Dec 2025 15:30:36 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v4] In-Reply-To: References: Message-ID: > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into JDK-8373710 - Fix test failure; Fix whitespaces - cli/Main fix ErrorTest failure - Improve error reporting: fix the value of "message.error-header" l10n key that was supposed to be updated in JDK-8372359. Always print stack trace of an exception if was not explicitly thrown from jpackage code. Better test coverage for the cli/Main. ------------- Changes: https://git.openjdk.org/jdk/pull/28833/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=03 Stats: 260 lines in 5 files changed: 240 ins; 1 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/28833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28833/head:pull/28833 PR: https://git.openjdk.org/jdk/pull/28833 From rgiulietti at openjdk.org Wed Dec 17 17:31:13 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 17 Dec 2025 17:31:13 GMT Subject: RFR: 8373068: Revisit details of Float16 to decimal conversion algorithm Message-ID: <9ZbSyd8J5JIStU0kfeduyOq6AHyvoiv1TQnmRBS8p-o=.3bddc5f2-e60e-4965-95ec-865a430336c5@github.com> Change the range for plain notation, reducing it to the interval [1e-3, 1e3). ------------- Commit messages: - 8373068: Revisit details of Float16 to decimal conversion algorithm Changes: https://git.openjdk.org/jdk/pull/28875/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28875&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373068 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28875.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28875/head:pull/28875 PR: https://git.openjdk.org/jdk/pull/28875 From darcy at openjdk.org Wed Dec 17 17:39:02 2025 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 17 Dec 2025 17:39:02 GMT Subject: RFR: 8373068: Revisit details of Float16 to decimal conversion algorithm In-Reply-To: <9ZbSyd8J5JIStU0kfeduyOq6AHyvoiv1TQnmRBS8p-o=.3bddc5f2-e60e-4965-95ec-865a430336c5@github.com> References: <9ZbSyd8J5JIStU0kfeduyOq6AHyvoiv1TQnmRBS8p-o=.3bddc5f2-e60e-4965-95ec-865a430336c5@github.com> Message-ID: On Wed, 17 Dec 2025 17:22:47 GMT, Raffaello Giulietti wrote: > Change the range for plain notation, reducing it to the interval [1e-3, 1e3). Marked as reviewed by darcy (Reviewer). Given the limited range of Float16, I think this is a reasonable adjustment of the policy of when to switch between the two output formats. ------------- PR Review: https://git.openjdk.org/jdk/pull/28875#pullrequestreview-3588828152 PR Comment: https://git.openjdk.org/jdk/pull/28875#issuecomment-3666438739 From asemenyuk at openjdk.org Wed Dec 17 17:39:04 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Dec 2025 17:39:04 GMT Subject: RFR: 8373887: jpackage tests may potentially deadlock [v2] In-Reply-To: References: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> Message-ID: On Wed, 17 Dec 2025 15:21:54 GMT, Alexey Semenyuk wrote: >> Fix potential deadlock in `jdk.jpackage.test.Executor.runExecutable()`: read subprocess's output streams concurrently in separate threads instead of reading them sequentially from the same thread. >> >> This change required updating some test cases in the corresponding unit test. > > Alexey Semenyuk 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: > > Fix WinResourceTest deadlock @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28872#issuecomment-3666437157 From iklam at openjdk.org Wed Dec 17 18:16:23 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 17 Dec 2025 18:16:23 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer [v2] In-Reply-To: References: 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`. Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision: - @liach comment: Fixed identation - Merge branch 'master' into 8373392-replace-cds-object-subgraphs-with-aot-safe-class-initializer - 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28736/files - new: https://git.openjdk.org/jdk/pull/28736/files/562d15a9..5497502f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=00-01 Stats: 15093 lines in 587 files changed: 9847 ins; 1687 del; 3559 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 jlu at openjdk.org Wed Dec 17 18:20:12 2025 From: jlu at openjdk.org (Justin Lu) Date: Wed, 17 Dec 2025 18:20:12 GMT Subject: Integrated: 8373716: Refactor further java/util tests from TestNG to JUnit In-Reply-To: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> References: <8h4hrNU2Fz-fMb85S4V0PVaNTeZUCVu8RKmM_J1km2M=.3f88d46d-fdff-43b1-a6af-1891901c3d7f@github.com> Message-ID: On Mon, 15 Dec 2025 22:50:22 GMT, Justin Lu wrote: > This PR updates a batch of _java/util_ tests from TestNG to JUnit. Specifically, > - _java/util/Calendar_ > - _java/util/TimeZone_ > - _java/util/Properties_ > - _java/util/ResourceBundle_ > > > This change is fully automated, I did not identify any further manual changes required. The total number of framework based tests reported by Jtreg remain the same, > > **Calendar** > `791 = 17 TestNG + 774 JUnit -> 0 TestNG + 791 JUnit` > > **TimeZone** > `84 = 39 TestNG + 45 JUnit -> 0 TestNG + 84 JUnit` > > **Properties** > `28 = 28 TestNG + 0 JUnit -> 0 TestNG + 28 JUnit` > > **ResourceBundle** > `45 = 45 TestNG + 0 JUnit -> 0 TestNG + 45 JUnit` This pull request has now been integrated. Changeset: 4e05748f Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/4e05748f0899cabb235c71ecdf4256d4ad137a0d Stats: 185 lines in 14 files changed: 44 ins; 23 del; 118 mod 8373716: Refactor further java/util tests from TestNG to JUnit Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/28836 From rriggs at openjdk.org Wed Dec 17 19:59:27 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Dec 2025 19:59:27 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit Message-ID: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Refactor serialization tests to use JUnit. Automated conversion for most annotations. Conditional tests are refactored to use JUnit Enable/DisableIf. ------------- Commit messages: - JDK-8373913: Refactor serialization tests tests to use JUnit Changes: https://git.openjdk.org/jdk/pull/28877/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373913 Stats: 406 lines in 12 files changed: 96 ins; 62 del; 248 mod Patch: https://git.openjdk.org/jdk/pull/28877.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28877/head:pull/28877 PR: https://git.openjdk.org/jdk/pull/28877 From iklam at openjdk.org Wed Dec 17 20:04:48 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 17 Dec 2025 20:04:48 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer [v3] In-Reply-To: References: 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`. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28736/files - new: https://git.openjdk.org/jdk/pull/28736/files/5497502f..306d9167 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28736&range=01-02 Stats: 41 lines in 1 file changed: 38 ins; 0 del; 3 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 iklam at openjdk.org Wed Dec 17 20:08:28 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 17 Dec 2025 20:08:28 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer [v3] In-Reply-To: References: Message-ID: <6Ime-D9wgZGM9Qz-u4IhkQ00fnRPUQOwmX-O70Lz41s=.5c6627aa-9239-4805-987b-aa8c79241f72@github.com> On Wed, 17 Dec 2025 20:04:48 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`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry I have to fix the SharedSymbolTableBucketSize.java test. With this PR and testing with `-vmoptions:-XX:+AOTClassLinking -vmoptions:-XX:+UseZGC`, the first block of "table stats" has a single entry. I fixed the test case to look for "Shared symbol table stats", which is the info that the test case intends to check. [...] [0.591s][info][cds] type array classes = 9 [0.591s][info][cds] symbols = 46244 [0.681s][info][aot,hashtables] Shared subgraphs table stats -------- base: 0x0000000800000000 [0.681s][info][aot,hashtables] Number of entries : 1 [0.681s][info][aot,hashtables] Total bytes used : 24 [0.681s][info][aot,hashtables] Average bytes per entry : 24.000 [0.681s][info][aot,hashtables] Average bucket size : 1.000 [0.681s][info][aot,hashtables] Variance of bucket size : 0.000 [0.681s][info][aot,hashtables] Std. dev. of bucket size: 0.000 [0.681s][info][aot,hashtables] Maximum bucket size : 1 [0.681s][info][aot,hashtables] Empty buckets : 0 [0.681s][info][aot,hashtables] Value_Only buckets : 1 [0.681s][info][aot,hashtables] Other buckets : 0 [0.688s][info][aot,hashtables] Shared symbol table stats -------- base: 0x0000000800000000 [0.688s][info][aot,hashtables] Number of entries : 46244 [0.688s][info][aot,hashtables] Total bytes used : 393792 [0.688s][info][aot,hashtables] Average bytes per entry : 8.516 [0.688s][info][aot,hashtables] Average bucket size : 7.734 [0.688s][info][aot,hashtables] Variance of bucket size : 7.513 [0.688s][info][aot,hashtables] Std. dev. of bucket size: 2.741 [0.688s][info][aot,hashtables] Maximum bucket size : 20 [0.688s][info][aot,hashtables] Empty buckets : 2 [0.688s][info][aot,hashtables] Value_Only buckets : 24 [0.688s][info][aot,hashtables] Other buckets : 5953 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3666964418 From liach at openjdk.org Wed Dec 17 20:54:40 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 20:54:40 GMT Subject: RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 23:23:02 GMT, Chen Liang wrote: > This test incorrectly uses getFields to discover package-private fields, resulting in no VarHandle being tested. Without fixing that site, the newly added assertFalse fails. > > @JornVernee please review since you initially created this. > > This bug is discovered during junit migration attempt. I intentionally separated this for ease of backport all the way to 17, when this test was added. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28858#issuecomment-3667104831 From liach at openjdk.org Wed Dec 17 20:54:41 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 20:54:41 GMT Subject: Integrated: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 23:23:02 GMT, Chen Liang wrote: > This test incorrectly uses getFields to discover package-private fields, resulting in no VarHandle being tested. Without fixing that site, the newly added assertFalse fails. > > @JornVernee please review since you initially created this. > > This bug is discovered during junit migration attempt. I intentionally separated this for ease of backport all the way to 17, when this test was added. This pull request has now been integrated. Changeset: e75726ee Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing Reviewed-by: jvernee, shade ------------- PR: https://git.openjdk.org/jdk/pull/28858 From rriggs at openjdk.org Wed Dec 17 21:08:58 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 17 Dec 2025 21:08:58 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v4] In-Reply-To: References: Message-ID: <0d43bzqFVibE1lAvHgxPxvEPTqxQWCuYNhHxV57Bg8M=.fd379436-8440-4853-bfc3-2599e7b5604f@github.com> On Wed, 17 Dec 2025 11:50:53 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Use assertSame for exception instance verification > > Updated testRequireNonNullWithSupplierThrowingException to allocate > the exception outside of the lambda and use assertSame to verify > the same exception instance is thrown, as suggested by @liach. > > This provides a more precise verification that the exception from > the supplier is thrown directly, not wrapped. > > Thanks to @liach for the feedback. Thanks for the conversion. It may be useful to force some of the asserts to fail and check that the error messages are readable. test/jdk/java/util/Objects/BasicObjectsTest.java line 31: > 29: */ > 30: > 31: import static org.junit.jupiter.api.Assertions.*; OpenJdk style is to avoid wildcard imports, especially for small numbers. test/jdk/java/util/Objects/BasicObjectsTest.java line 34: > 32: import org.junit.jupiter.api.Test; > 33: import java.util.*; > 34: import java.util.function.*; Please expand these too, though they are pre-existing. test/jdk/java/util/Objects/BasicObjectsTest.java line 49: > 47: assertEquals(expected, result, > 48: String.format("When equating %s to %s, got %b instead of %b", > 49: a, b, result, expected)); Since the JUnit assertEquals already prints the expected and actual, please simplify, retaining a message that identifies the test. test/jdk/java/util/Objects/BasicObjectsTest.java line 134: > 132: @Override > 133: public String toString() { > 134: throw new RuntimeException(); In Junit, this should probably call Assertions.fail(...) test/jdk/java/util/Objects/BasicObjectsTest.java line 208: > 206: NullPointerException.class, > 207: () -> testFunc.apply(null), > 208: testFuncName + " should throw NPE"); AssertThrows will already include the message that it should throw; the message argument can be simplified to just the testFuncName. test/jdk/java/util/Objects/BasicObjectsTest.java line 218: > 216: "isNull(null) should return true"); > 217: assertFalse(Objects.isNull(Objects.class), > 218: "isNull(Objects.class) should return false"); Could be simplifed with Assertions.assertNull or assertNonNull. Here and elsewhere in this test. ------------- PR Review: https://git.openjdk.org/jdk/pull/28845#pullrequestreview-3589611390 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628605220 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628606965 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628616800 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628625305 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628633438 PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628642090 From liach at openjdk.org Wed Dec 17 21:23:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 21:23:52 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit In-Reply-To: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Wed, 17 Dec 2025 19:53:00 GMT, Roger Riggs wrote: > Refactor serialization tests to use JUnit. > Automated conversion for most annotations. > Conditional tests are refactored to use JUnit Enable/DisableIf. test/jdk/java/io/Serializable/class/NonSerializableTest.java line 104: > 102: @ParameterizedTest > 103: @MethodSource("provider") > 104: public void test(String[][] argArray) throws Exception { I recommend changing `provider` to return `List` or `Object[]`, instead of hacking the test. test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java line 389: > 387: Assertions.assertEquals( ObjectInputFilter.Status.REJECTED, filter.checkInput(new FilterValues(arrayClass, value, value, value, value)), > 388: "last limit value not used: " + filter); > 389: Assertions.assertEquals( ObjectInputFilter.Status.UNDECIDED, filter.checkInput(new FilterValues(arrayClass, value-1, value-1, value-1, value-1)), Extra indentation from the auto conversion script ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2628680694 PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2628691334 From liach at openjdk.org Wed Dec 17 21:30:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 21:30:52 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG Message-ID: Refactor java/lang/invoke tests to use JUnit instead of TestNG. This is done by: 1. First a round of automatic conversion 2. Simplify exception handling tests 3. Replacing `assert` keyword and switching to better assertion APIs for equality etc. 4. Some other random cleanups, such as module status Testing: java/lang/invoke on Linux-x64. I un-problemlisted the updated `java/lang/invoke/lambda/LambdaFileEncodingSerialization.java` too. ------------- Commit messages: - Whitespace - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit - invoke move away from testng Changes: https://git.openjdk.org/jdk/pull/28879/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28879&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373935 Stats: 6251 lines in 127 files changed: 634 ins; 865 del; 4752 mod Patch: https://git.openjdk.org/jdk/pull/28879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28879/head:pull/28879 PR: https://git.openjdk.org/jdk/pull/28879 From liach at openjdk.org Wed Dec 17 21:41:50 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 21:41:50 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: References: Message-ID: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> > Refactor java/lang/invoke tests to use JUnit instead of TestNG. > This is done by: > 1. First a round of automatic conversion > 2. Simplify exception handling tests > 3. Replacing `assert` keyword and switching to better assertion APIs for equality etc. > 4. Some other random cleanups, such as module status > > Testing: java/lang/invoke on Linux-x64. I un-problemlisted the updated `java/lang/invoke/lambda/LambdaFileEncodingSerialization.java` too. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Some omissions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28879/files - new: https://git.openjdk.org/jdk/pull/28879/files/ac47d48a..dfdb2de1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28879&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28879&range=00-01 Stats: 59 lines in 2 files changed: 2 ins; 11 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/28879.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28879/head:pull/28879 PR: https://git.openjdk.org/jdk/pull/28879 From liach at openjdk.org Wed Dec 17 22:07:29 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:07:29 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer [v3] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 20:04:48 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`. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry The new tests look fine to me. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28736#pullrequestreview-3589877162 From liach at openjdk.org Wed Dec 17 22:11:15 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:11:15 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v4] In-Reply-To: <0d43bzqFVibE1lAvHgxPxvEPTqxQWCuYNhHxV57Bg8M=.fd379436-8440-4853-bfc3-2599e7b5604f@github.com> References: <0d43bzqFVibE1lAvHgxPxvEPTqxQWCuYNhHxV57Bg8M=.fd379436-8440-4853-bfc3-2599e7b5604f@github.com> Message-ID: On Wed, 17 Dec 2025 21:03:48 GMT, Roger Riggs wrote: >> eunbin son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373661: Use assertSame for exception instance verification >> >> Updated testRequireNonNullWithSupplierThrowingException to allocate >> the exception outside of the lambda and use assertSame to verify >> the same exception instance is thrown, as suggested by @liach. >> >> This provides a more precise verification that the exception from >> the supplier is thrown directly, not wrapped. >> >> Thanks to @liach for the feedback. > > test/jdk/java/util/Objects/BasicObjectsTest.java line 218: > >> 216: "isNull(null) should return true"); >> 217: assertFalse(Objects.isNull(Objects.class), >> 218: "isNull(Objects.class) should return false"); > > Could be simplifed with Assertions.assertNull or assertNonNull. Here and elsewhere in this test. I think this is testing `isNull` API and shouldn't be simplified. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2628817056 From iklam at openjdk.org Wed Dec 17 22:19:58 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 17 Dec 2025 22:19:58 GMT Subject: RFR: 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer [v3] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 22:04:42 GMT, Chen Liang wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed test case -- the regexp pattern could match the stats for the subgraphs table, which now has a single entry > > The new tests look fine to me. Thank you @liach @DanHeidinga for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28736#issuecomment-3667419351 From iklam at openjdk.org Wed Dec 17 22:20:00 2025 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 17 Dec 2025 22:20:00 GMT Subject: Integrated: 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`. This pull request has now been integrated. Changeset: 232b41b2 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/232b41b2227bc9d03d88d316aa28d0cbe87086f7 Stats: 642 lines in 30 files changed: 406 ins; 186 del; 50 mod 8373392: Replace CDS object subgraphs with @AOTSafeClassInitializer Reviewed-by: liach, heidinga ------------- PR: https://git.openjdk.org/jdk/pull/28736 From dlsmith at openjdk.org Wed Dec 17 22:36:13 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 22:36:13 GMT Subject: RFR: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java Message-ID: [JDK-8371495](https://bugs.openjdk.org/browse/JDK-8371495) fixed the HTML content of JLS & JVMS, and [JDK-8372532](https://bugs.openjdk.org/browse/JDK-8372532) brought these changes into the mainline repo. This changeset removes the tests from the problem list. I'll integrate into 27 and then backport to 26. ------------- Commit messages: - Remove commented lines - 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java Changes: https://git.openjdk.org/jdk/pull/28880/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28880&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370970 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28880.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28880/head:pull/28880 PR: https://git.openjdk.org/jdk/pull/28880 From dnguyen at openjdk.org Wed Dec 17 22:41:09 2025 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 17 Dec 2025 22:41:09 GMT Subject: [jdk26] Integrated: 8373119: JDK 26 RDP1 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 21:52:52 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [fb99ba6c](https://github.com/openjdk/jdk/commit/fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 16 Dec 2025 and was reviewed by Justin Lu, Alexey Semenyuk and Alexander Matveev. > > Thanks! This pull request has now been integrated. Changeset: d94b2a11 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/d94b2a11818e0c3321188ab831b4bce6d7ca7ddf Stats: 1141 lines in 52 files changed: 706 ins; 159 del; 276 mod 8373119: JDK 26 RDP1 L10n resource files update Reviewed-by: jlu Backport-of: fb99ba6ccd6e6d7a0e717a1b9f2a80402af5c661 ------------- PR: https://git.openjdk.org/jdk/pull/28854 From liach at openjdk.org Wed Dec 17 22:42:01 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:42:01 GMT Subject: RFR: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java In-Reply-To: References: Message-ID: <6ILF1LRUT1NifJq5BQtAbY7PCzJ4Qkx20C4-bx0PiUA=.c82d217b-4960-41ae-8b08-ce3ef49281de@github.com> On Wed, 17 Dec 2025 22:18:00 GMT, Dan Smith wrote: > [JDK-8371495](https://bugs.openjdk.org/browse/JDK-8371495) fixed the HTML content of JLS & JVMS, and [JDK-8372532](https://bugs.openjdk.org/browse/JDK-8372532) brought these changes into the mainline repo. This changeset removes the tests from the problem list. > > I'll integrate into 27 and then backport to 26. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28880#pullrequestreview-3589952693 From dlsmith at openjdk.org Wed Dec 17 22:42:01 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 22:42:01 GMT Subject: Integrated: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 22:18:00 GMT, Dan Smith wrote: > [JDK-8371495](https://bugs.openjdk.org/browse/JDK-8371495) fixed the HTML content of JLS & JVMS, and [JDK-8372532](https://bugs.openjdk.org/browse/JDK-8372532) brought these changes into the mainline repo. This changeset removes the tests from the problem list. > > I'll integrate into 27 and then backport to 26. This pull request has now been integrated. Changeset: c16ce929 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/c16ce929c7bc127fe18d3faa037d81c2760a44a2 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28880 From liach at openjdk.org Wed Dec 17 22:47:52 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:47:52 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v4] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:50:53 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Use assertSame for exception instance verification > > Updated testRequireNonNullWithSupplierThrowingException to allocate > the exception outside of the lambda and use assertSame to verify > the same exception instance is thrown, as suggested by @liach. > > This provides a more precise verification that the exception from > the supplier is thrown directly, not wrapped. > > Thanks to @liach for the feedback. I agree with Roger's points about simplifying some test messages. Sometimes we don't even write test messages if the subject is clear from the test code context, because the exceptions usually include the line numbers already. However, these are not critical. However, I think Roger might be too strict on imports and Assertions.fail vs exceptions - these are acceptable because they don't affect the test quality, so I am not concerned. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3667486305 From dlsmith at openjdk.org Wed Dec 17 22:48:11 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 22:48:11 GMT Subject: [jdk26] RFR: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java Message-ID: This pull request contains a backport of commit [c16ce929](https://github.com/openjdk/jdk/commit/c16ce929c7bc127fe18d3faa037d81c2760a44a2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Dan Smith on 17 Dec 2025 and was reviewed by Chen Liang. ------------- Commit messages: - Backport c16ce929c7bc127fe18d3faa037d81c2760a44a2 Changes: https://git.openjdk.org/jdk/pull/28881/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28881&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370970 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28881.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28881/head:pull/28881 PR: https://git.openjdk.org/jdk/pull/28881 From liach at openjdk.org Wed Dec 17 22:54:05 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 17 Dec 2025 22:54:05 GMT Subject: [jdk26] RFR: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 22:40:29 GMT, Dan Smith wrote: > This pull request contains a backport of commit [c16ce929](https://github.com/openjdk/jdk/commit/c16ce929c7bc127fe18d3faa037d81c2760a44a2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 17 Dec 2025 and was reviewed by Chen Liang. Thanks for this doc quality improvement. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28881#pullrequestreview-3589974561 From dlsmith at openjdk.org Wed Dec 17 22:54:05 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Wed, 17 Dec 2025 22:54:05 GMT Subject: [jdk26] Integrated: 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 22:40:29 GMT, Dan Smith wrote: > This pull request contains a backport of commit [c16ce929](https://github.com/openjdk/jdk/commit/c16ce929c7bc127fe18d3faa037d81c2760a44a2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 17 Dec 2025 and was reviewed by Chen Liang. This pull request has now been integrated. Changeset: fb8365e7 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/fb8365e75e148d9810c9c7a2f708b1a782515206 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8370970: DocCheck failure in jdkDoctypeBadcharsCheck.java and jdkCheckHtml.java Reviewed-by: liach Backport-of: c16ce929c7bc127fe18d3faa037d81c2760a44a2 ------------- PR: https://git.openjdk.org/jdk/pull/28881 From almatvee at openjdk.org Wed Dec 17 22:59:04 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 17 Dec 2025 22:59:04 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v4] In-Reply-To: References: Message-ID: <0djVOLu2xSZgreGZWQTcg4kGRZzpTUIAIiKayq1WCQc=.52b374e7-6548-4819-ba68-aeae10992b13@github.com> On Wed, 17 Dec 2025 15:30:36 GMT, Alexey Semenyuk wrote: >> - Append "Error: " prefix to error messages >> - Always print stack traces of internal exceptions, not only when running in verbose mode > > Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: > > - Merge branch 'master' into JDK-8373710 > - Fix test failure; Fix whitespaces > - cli/Main fix ErrorTest failure > - Improve error reporting: fix the value of "message.error-header" l10n key that was supposed to be updated in JDK-8372359. Always print stack trace of an exception if was not explicitly thrown from jpackage code. Better test coverage for the cli/Main. Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28833#pullrequestreview-3589990564 From asemenyuk at openjdk.org Wed Dec 17 23:41:20 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 17 Dec 2025 23:41:20 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v5] In-Reply-To: References: Message-ID: <-JaM9-d4pnwCxq3pLXPLzCTq1O8PL-hTWBPRdQ5cHFo=.3c0c04bc-5985-4249-8d8e-f9b37b8cf8c9@github.com> > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Fix merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28833/files - new: https://git.openjdk.org/jdk/pull/28833/files/c6766243..8eddff4b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28833&range=03-04 Stats: 8 lines in 1 file changed: 0 ins; 3 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/28833.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28833/head:pull/28833 PR: https://git.openjdk.org/jdk/pull/28833 From liach at openjdk.org Thu Dec 18 00:03:10 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 00:03:10 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: Message-ID: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> > 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: Move the test to a core library purposed directory ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28540/files - new: https://git.openjdk.org/jdk/pull/28540/files/567e8925..16db9901 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28540&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 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 liach at openjdk.org Thu Dec 18 00:03:13 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 00:03:13 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v6] In-Reply-To: References: Message-ID: <7WM2llDmHIma5F6pRh7EIdeubuz7qI-uTqvSsqmfug4=.6ce794e4-c270-4d83-a481-5ac75a71afc9@github.com> On Tue, 16 Dec 2025 18:54: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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 14 additional commits since the last revision: > > - Recommended test tweaks > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/class-final-trusting > - 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 > - ... and 4 more: https://git.openjdk.org/jdk/compare/0095e40a...567e8925 After offline discussion, we have decided to move this test to `compiler/corelibs`, which will become the future home for various compiler framework-based tests verifying the behavior of core library APIs once they are compiled. For example, this package may add more constant folding verifications (such as for Lazy Constants) or loop hoisting verification for FFM API. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3667634659 From almatvee at openjdk.org Thu Dec 18 00:25:15 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 18 Dec 2025 00:25:15 GMT Subject: RFR: 8373710: Improve jpackage error reporting [v5] In-Reply-To: <-JaM9-d4pnwCxq3pLXPLzCTq1O8PL-hTWBPRdQ5cHFo=.3c0c04bc-5985-4249-8d8e-f9b37b8cf8c9@github.com> References: <-JaM9-d4pnwCxq3pLXPLzCTq1O8PL-hTWBPRdQ5cHFo=.3c0c04bc-5985-4249-8d8e-f9b37b8cf8c9@github.com> Message-ID: On Wed, 17 Dec 2025 23:41:20 GMT, Alexey Semenyuk wrote: >> - Append "Error: " prefix to error messages >> - Always print stack traces of internal exceptions, not only when running in verbose mode > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Fix merge Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28833#pullrequestreview-3590137159 From almatvee at openjdk.org Thu Dec 18 01:08:53 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 18 Dec 2025 01:08:53 GMT Subject: RFR: 8373887: jpackage tests may potentially deadlock [v2] In-Reply-To: References: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> Message-ID: On Wed, 17 Dec 2025 15:21:54 GMT, Alexey Semenyuk wrote: >> Fix potential deadlock in `jdk.jpackage.test.Executor.runExecutable()`: read subprocess's output streams concurrently in separate threads instead of reading them sequentially from the same thread. >> >> This change required updating some test cases in the corresponding unit test. > > Alexey Semenyuk 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: > > Fix WinResourceTest deadlock Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28872#pullrequestreview-3590267233 From asemenyuk at openjdk.org Thu Dec 18 01:50:15 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 18 Dec 2025 01:50:15 GMT Subject: Integrated: 8373887: jpackage tests may potentially deadlock In-Reply-To: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> References: <8yO0GI_eXQH4UMrwc4cYTjdCh0_pwTujWXArJtvPp_I=.844fc1f4-0316-423f-88e7-3aad8ac5339b@github.com> Message-ID: On Wed, 17 Dec 2025 14:47:05 GMT, Alexey Semenyuk wrote: > Fix potential deadlock in `jdk.jpackage.test.Executor.runExecutable()`: read subprocess's output streams concurrently in separate threads instead of reading them sequentially from the same thread. > > This change required updating some test cases in the corresponding unit test. This pull request has now been integrated. Changeset: ea583441 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/ea5834415db6410c73271c496811ff6b5dcc87ef Stats: 42 lines in 2 files changed: 38 ins; 0 del; 4 mod 8373887: jpackage tests may potentially deadlock Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28872 From qamai at openjdk.org Thu Dec 18 03:41:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 03:41:54 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory Is this annotation just for constant folding of final fields? That seems pretty limited. Can we have it to notify that the final fields of a class can be treated as strict fields? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668189051 From liach at openjdk.org Thu Dec 18 03:54:53 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 03:54:53 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory Yes, this is the purpose of this annotation for now. Unfortunately the JDK can only use strict after it leaves preview, so I think this is necessary to bridge the gap during this period. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668227064 From qamai at openjdk.org Thu Dec 18 04:07:54 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 04:07:54 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory If the JDK wants to use strict then it can, it is the user code which does not have access to strict fields, isn't it? What I mean is why isn't this annotation stronger so we can improve the accesses into currently-trusted fields, too (`MemorySegment` fields for example). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668255154 From liach at openjdk.org Thu Dec 18 04:54:05 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 04:54:05 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory What do you mean by this annotation being "stronger"? This annotation uses class granularity because javac generates synthetic fields like local variable captures, which cannot be annotated by field annotations. The JDK will have to resort to an annotation, because JDK class files cannot use preview features because they need to be able to run with preview features off. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668363917 From qamai at openjdk.org Thu Dec 18 05:00:56 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 05:00:56 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3668379612 From syan at openjdk.org Thu Dec 18 06:30:00 2025 From: syan at openjdk.org (SendaoYan) Date: Thu, 18 Dec 2025 06:30:00 GMT Subject: [jdk26] RFR: 8371503: RETAIN_IMAGE_AFTER_TEST do not work for some tests [v2] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 11:52:45 GMT, SendaoYan wrote: >> Hi all, >> >> This pull request contains a backport of commit [34f24131](https://github.com/openjdk/jdk/commit/34f241317ecd7473cfb6dcc2e6e5cf3a40299e2c) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by SendaoYan on 15 Dec 2025 and was reviewed by Leonid Mesnik and David Holmes. >> >> This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. >> >> Thanks! > > SendaoYan has updated the pull request incrementally with one additional commit since the last revision: > > Add an whitespace after if > > Co-authored-by: Andrey Turbanov Change has been verified locally on linux-x64. This clean backport PR will make all the docker tests receive -Djdk.test.docker.retain.image property correctly. Verify command: j -Djdk.test.docker.image.name=jdk-build -Djdk.test.docker.image.version=11 -conc:20 $(git status -s | awk '{print $NF}' | sed "/ockerTestUtils.java/d" | xargs) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3668601523 From alanb at openjdk.org Thu Dec 18 07:32:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Dec 2025 07:32:54 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> References: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> Message-ID: On Wed, 17 Dec 2025 21:41:50 GMT, Chen Liang wrote: >> Refactor java/lang/invoke tests to use JUnit instead of TestNG. >> This is done by: >> 1. First a round of automatic conversion >> 2. Simplify exception handling tests >> 3. Replacing `assert` keyword and switching to better assertion APIs for equality etc. >> 4. Some other random cleanups, such as module status >> >> Testing: java/lang/invoke on Linux-x64. I un-problemlisted the updated `java/lang/invoke/lambda/LambdaFileEncodingSerialization.java` too. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Some omissions test/jdk/java/lang/invoke/DropLookupModeTest.java line 158: > 156: Integer.MIN_VALUE, > 157: }) > 158: public void testBadInput(Integer modeToDrop) { The ValueSource produces ints but the parameter to testBadInput is Integer. The original data provider test used Integer too so I assume this was just the conversion. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2629914346 From bkilambi at openjdk.org Thu Dec 18 10:17:47 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 18 Dec 2025 10:17:47 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v3] In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: > 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 ... Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: Fix build failures on Mac ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27526/files - new: https://git.openjdk.org/jdk/pull/27526/files/e8e3989d..620b422a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=01-02 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/27526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526 PR: https://git.openjdk.org/jdk/pull/27526 From bkilambi at openjdk.org Thu Dec 18 10:17:52 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 18 Dec 2025 10:17:52 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Wed, 17 Dec 2025 12:40:38 GMT, Marc Chevalier wrote: >> Bhavana Kilambi 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: >> >> - Address review comments >> - Merge 'master' >> - 8366444: Add support for add/mul reduction operations for Float16 >> >> 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 vecto... > > src/hotspot/share/opto/vectornode.hpp line 328: > >> 326: ReductionNode(ctrl, in1, in2), _requires_strict_order(requires_strict_order) {} >> 327: >> 328: virtual int Opcode() const; > > Build is failing on Mac because of `-Winconsistent-missing-override`: since you specified `override` on `bottom_type` and `ideal_reg`, you need to put `override` everywhere it applies. That means `Opcode` `requires_strict_order`, `hash`, `cmp` and `size_of`. And same in `MulReductionVHFNode`. Done thanks. Could you please take another look? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2630407402 From mchevalier at openjdk.org Thu Dec 18 10:21:33 2025 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 18 Dec 2025 10:21:33 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <9aaKc1g9G-g7a6oZ5s-hZASP_j3_qlAPKN070WQXUew=.6307668d-1d96-467b-90c4-2b5b33041366@github.com> On Thu, 18 Dec 2025 10:12:20 GMT, Bhavana Kilambi wrote: >> src/hotspot/share/opto/vectornode.hpp line 328: >> >>> 326: ReductionNode(ctrl, in1, in2), _requires_strict_order(requires_strict_order) {} >>> 327: >>> 328: virtual int Opcode() const; >> >> Build is failing on Mac because of `-Winconsistent-missing-override`: since you specified `override` on `bottom_type` and `ideal_reg`, you need to put `override` everywhere it applies. That means `Opcode` `requires_strict_order`, `hash`, `cmp` and `size_of`. And same in `MulReductionVHFNode`. > > Done thanks. Could you please take another look? Running some tests. I'll take a look. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2630429246 From duke at openjdk.org Thu Dec 18 11:54:41 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 18 Dec 2025 11:54:41 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son has updated the pull request incrementally with one additional commit since the last revision: 8373661: Address code style feedback - Expanded wildcard imports to individual imports - Simplified test messages to identify tests only - Used Assertions.fail() where appropriate - Kept assertTrue/assertFalse for isNull API tests Thanks to @RogerRiggs and @liach for the feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/3986ed4b..11d7aae7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=03-04 Stats: 26 lines in 1 file changed: 11 ins; 6 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From duke at openjdk.org Thu Dec 18 11:54:41 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 18 Dec 2025 11:54:41 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods In-Reply-To: <8vp57HJD1AEXF1nycG0RcypV4PiSsg3rqtDhhN_UVsc=.7329c0c3-5b3a-435e-b69c-d5056bbf9f4a@github.com> References: <8vp57HJD1AEXF1nycG0RcypV4PiSsg3rqtDhhN_UVsc=.7329c0c3-5b3a-435e-b69c-d5056bbf9f4a@github.com> Message-ID: On Tue, 16 Dec 2025 22:14:27 GMT, Roger Riggs wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > The new tests scope is good. > The current standard for tests is JUnit and it would be better to convert the test to JUnit before adding new tests. Thank you for the detailed feedback, @RogerRiggs and @liach! I've addressed the following: - [x] Expanded wildcard imports to individual imports (as requested by @RogerRiggs) - [x] Simplified test messages to just identify the test (as both reviewers suggested) - [x] Used Assertions.fail() where appropriate (as suggested by @RogerRiggs) - [x] Kept assertTrue/assertFalse for isNull API tests (as @liach correctly noted) - [x] Simplified assertThrows message argument to just testFuncName (as suggested by @RogerRiggs) Regarding wildcard imports and Assertions.fail vs exceptions: I've made the changes as requested, but I understand from @liach's comment that these are acceptable either way. I've followed @RogerRiggs's preferences for consistency. The changes have been pushed. Please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3669913387 From duke at openjdk.org Thu Dec 18 12:03:14 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 18 Dec 2025 12:03:14 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 13:37:17 GMT, Alan Bateman wrote: >> ## Summary >> >> Add explicit null check using `Objects.requireNonNull` in >> `DataOutputStream.writeBytes(String s)` to provide a clearer error message >> and make the API contract explicit. >> >> ## Problem >> >> The `writeBytes` method currently throws a `NullPointerException` when >> `null` is passed, but the error message may not be clear in all contexts. >> While JDK 14+ provides helpful NullPointerException messages through >> JEP 358 (Helpful NullPointerExceptions), adding an explicit null check >> using `Objects.requireNonNull` makes the API contract more explicit and >> provides consistent error messaging across different JDK versions. >> >> ## Solution >> >> Added `Objects.requireNonNull(s, "s")` at the beginning of the >> `writeBytes(String s)` method. This ensures: >> - A clear error message ("s") is provided when null is passed >> - The API contract explicitly states that null is not allowed >> - The method fails fast with a descriptive exception >> >> ## Issue >> Fixes JDK-8373660 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 >> >> >> ## Type of Change >> - [x] Test addition/modification >> - [x] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> A new JUnit test has been added to verify the null check behavior: >> >> >> # Run the specific JUnit test file >> make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" >> >> # Or run all tests in the DataOutputStream directory >> make test TEST="jtreg:test/jdk/java/io/DataOutputStream" > >> Add explicit null check using Objects.requireNonNull in DataOutputStream.writeBytes(String s) to provide a clearer error message and make the API contract explicit. > > Can you paste in the existing NPE message vs. the new NPE message? With Helpful NPEs (JEP 358), there is a less need to make changes like this. @AlanBateman Thank you for the feedback! ## Analysis: **JEP 358 message advantages:** - More detailed: Shows which method call failed ("String.length()") - More informative: Explains the context of the failure **Objects.requireNonNull advantages:** - Explicit API contract: Makes it clear at method entry that null is not allowed - Fail-fast: Exception occurs at method entry, not deep in the method body - Consistent across JDK versions: Works the same way in JDK 8, 11, 14, 17, etc. - Simpler message: Just the parameter name I understand that with JEP 358, there's less need for explicit null checks in many cases. However, I believe `Objects.requireNonNull` still provides value by: 1. Making the API contract explicit at the method signature level 2. Failing fast before any method body execution 3. Providing consistent behavior across all JDK versions I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3669945336 From alanb at openjdk.org Thu Dec 18 12:43:42 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Dec 2025 12:43:42 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 12:00:01 GMT, eunbin son wrote: > I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? Would you mind pasting in the existing NPE message and the new NPE message? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3670098310 From bkilambi at openjdk.org Thu Dec 18 12:44:53 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Thu, 18 Dec 2025 12:44:53 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: <5NNS6uN_GhivBLv-OhE1Tn0HJhrL6-TKlsN9wWKOytU=.d36bafc2-a5c4-4878-920c-6707cf3547bb@github.com> On Tue, 16 Dec 2025 15:45:15 GMT, Jatin Bhateja wrote: >>> 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. >> >> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR? > >> > 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. >> >> Hi @jbhateja, thanks for the suggestion. Based on the comments here - https://bugs.openjdk.org/browse/JDK-8373574, is it ok if my fix (along with a regression test as suggested) be part of this PR? > > Hi @Bhavana-Kilambi , As @TobiHartmann suggested we can included your patch with the PR. > Best Regards Thanks @jatin-bhateja for including AArch64 changes to the patch. Also @TobiHartmann suggested (here - https://bugs.openjdk.org/browse/JDK-8373574) that it'd be good to have a regression test for the AArch64 failures. I have put together a small JTREG test taking one of the VectorAPI tests from `TestFloat16VectorOperations.java` introduced in this PR (which was the one failing on AArch64). Could you please include the testcase as well? The patch is attached here [test.patch](https://github.com/user-attachments/files/24235556/test.patch) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3670100491 From rgiulietti at openjdk.org Thu Dec 18 13:12:41 2025 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 18 Dec 2025 13:12:41 GMT Subject: Integrated: 8373068: Revisit details of Float16 to decimal conversion algorithm In-Reply-To: <9ZbSyd8J5JIStU0kfeduyOq6AHyvoiv1TQnmRBS8p-o=.3bddc5f2-e60e-4965-95ec-865a430336c5@github.com> References: <9ZbSyd8J5JIStU0kfeduyOq6AHyvoiv1TQnmRBS8p-o=.3bddc5f2-e60e-4965-95ec-865a430336c5@github.com> Message-ID: On Wed, 17 Dec 2025 17:22:47 GMT, Raffaello Giulietti wrote: > Change the range for plain notation, reducing it to the interval [1e-3, 1e3). This pull request has now been integrated. Changeset: 3258e4da Author: Raffaello Giulietti URL: https://git.openjdk.org/jdk/commit/3258e4dafa85b2347c7640b0fd87197959cabea2 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod 8373068: Revisit details of Float16 to decimal conversion algorithm Reviewed-by: darcy ------------- PR: https://git.openjdk.org/jdk/pull/28875 From duke at openjdk.org Thu Dec 18 13:31:02 2025 From: duke at openjdk.org (Ruben) Date: Thu, 18 Dec 2025 13:31:02 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 09:32:43 GMT, Andrew Haley wrote: >> Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. >> >> Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. >> >> Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. >> >> >> Renaissance 0.15.0 benchmark results (MOVK-based scheme) >> Neoverse V1. >> The runs were limited to 16 cores. >> >> Number of runs: >> 6 for baseline, 6 for the changes - interleaved pairs. >> >> Command line: >> java -jar renaissance-jmh-0.15.0.jar \ >> -bm avgt -gc true -v extra \ >> -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ >> -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ >> -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ >> -XX:+UseG1GC' >> >> The change is geometric mean of ratios across 6 the pairs of runs. >> >> | Benchmark | Change | 90% CI for the change | >> | ----------------------------------------------------- | -------- | --------------------- | >> | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | >> | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | >> | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | >> | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | >> | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | >> | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | >> | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | >> | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | >> | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | >> | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | >> | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | >> | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | >> | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | >> | org.renaissance.scala.stm.JmhScalaStmBench7.run ... > > While the basic idea is a good one, I think there are better ways to do it. > > Consider fixing the number of instructions to two rather than three. Then a post-call NOP can be either 'nop; movk/movz` or `b.nv; movk/adrp`. Or something similar.. `b.nv` is more expensive, but should be rare. Thank you for the feedback, @theRealAph, I will be out of office until early January - I'm planning to respond in more detail and work on updating the PR when I am back. I agree a fixed-length post-call NOP sequence would be preferable and would make the implementation simpler. The `B.nv` might not be suitable in this case - I believe the branch will be "always taken". However, I had considered using `CBNZ XZR, <#imm>`. So far, I avoided implementing it because it is unclear what performance effects this might have. While I agree that the case will be rare in terms of static occurrences - it might still impact performance if a particular instance is on a frequent execution path. I believe the change in C1 floating-point constants handling is a dependency for the current implementation - it allows keeping the constants section empty and ensures the compiler can determine the offset to the code blob header before the code buffer is finalized. However, if the approach is changed to a fixed post-call NOP sequence length, there will be no dependency between these two optimizations. I will revisit both the post-call NOP sequence structure and the dependency on floating-point constants handling when I return in January. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3670298853 From alanb at openjdk.org Thu Dec 18 13:36:59 2025 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 18 Dec 2025 13:36:59 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Wed, 17 Dec 2025 21:16:49 GMT, Chen Liang wrote: >> Refactor serialization tests to use JUnit. >> Automated conversion for most annotations. >> Conditional tests are refactored to use JUnit Enable/DisableIf. > > test/jdk/java/io/Serializable/class/NonSerializableTest.java line 104: > >> 102: @ParameterizedTest >> 103: @MethodSource("provider") >> 104: public void test(String[][] argArray) throws Exception { > > I recommend changing `provider` to return `List` or `Object[]`, instead of hacking the test. `Stream` is another option, at least I've found it useful for the method sources like this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2631129391 From dl at openjdk.org Thu Dec 18 13:44:43 2025 From: dl at openjdk.org (Doug Lea) Date: Thu, 18 Dec 2025 13:44:43 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v11] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation Doug Lea has updated the pull request incrementally with one additional commit since the last revision: Check diagnosis ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/45f8a9a6..3370c0bf Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=09-10 Stats: 57 lines in 1 file changed: 6 ins; 14 del; 37 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 aturbanov at openjdk.org Thu Dec 18 13:49:05 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 18 Dec 2025 13:49:05 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> References: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> Message-ID: On Wed, 17 Dec 2025 21:41:50 GMT, Chen Liang wrote: >> Refactor java/lang/invoke tests to use JUnit instead of TestNG. >> This is done by: >> 1. First a round of automatic conversion >> 2. Simplify exception handling tests >> 3. Replacing `assert` keyword and switching to better assertion APIs for equality etc. >> 4. Some other random cleanups, such as module status >> >> Testing: java/lang/invoke on Linux-x64. I un-problemlisted the updated `java/lang/invoke/lambda/LambdaFileEncodingSerialization.java` too. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Some omissions test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java line 298: > 296: { > 297: boolean x = (boolean) vh.get(recv); > 298: assertEquals(true, x,"get boolean value"); Suggestion: assertEquals(true, x, "get boolean value"); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2631166589 From dl at openjdk.org Thu Dec 18 13:51:02 2025 From: dl at openjdk.org (Doug Lea) Date: Thu, 18 Dec 2025 13:51:02 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v12] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 15 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Check diagnosis - Avoid double-filtering - Merge branch 'openjdk:master' into JDK-8373118 - Another diagnostic - Relax orderings in push - Reduce fencing - Adjust runworker for previous update - Reorder signalWork filter - Revert topLevelExec - ... and 5 more: https://git.openjdk.org/jdk/compare/b952f805...2d8cff2b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/3370c0bf..2d8cff2b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=10-11 Stats: 3894 lines in 125 files changed: 2523 ins; 810 del; 561 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 aph at openjdk.org Thu Dec 18 13:55:41 2025 From: aph at openjdk.org (Andrew Haley) Date: Thu, 18 Dec 2025 13:55:41 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: Message-ID: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> On Tue, 16 Dec 2025 22:45:08 GMT, Ruben wrote: > Extend MOVK-based scheme to MOVK/MOVZ allowing to store 19 bits of metadata. > > Choose number of metadata slots in post-call NOP sequence between 1 and 2 depending on the offset from the CodeBlob header. > > Additionally, implement ADR/ADRP-based metadata storage - that provides 22 bits instead of 16 bits to store metadata. This can be enabled via UsePostCallSequenceWithADRP option. > > > Renaissance 0.15.0 benchmark results (MOVK-based scheme) > Neoverse V1. > The runs were limited to 16 cores. > > Number of runs: > 6 for baseline, 6 for the changes - interleaved pairs. > > Command line: > java -jar renaissance-jmh-0.15.0.jar \ > -bm avgt -gc true -v extra \ > -jvmArgsAppend '-Xbatch -XX:-UseDynamicNumberOfCompilerThreads \ > -XX:-CICompilerCountPerCPU -XX:ActiveProcessorCount=16 \ > -XX:CICompilerCount=2 -Xms8g -Xmx8g -XX:+AlwaysPreTouch \ > -XX:+UseG1GC' > > The change is geometric mean of ratios across 6 the pairs of runs. > > | Benchmark | Change | 90% CI for the change | > | ----------------------------------------------------- | -------- | --------------------- | > | org.renaissance.actors.JmhAkkaUct.run | -0.215% | -2.652% to 1.357% | > | org.renaissance.actors.JmhReactors.run | -0.166% | -1.974% to 1.775% | > | org.renaissance.jdk.concurrent.JmhFjKmeans.run | 0.222% | -0.492% to 0.933% | > | org.renaissance.jdk.concurrent.JmhFutureGenetic.run | -1.880% | -2.438% to -1.343% | > | org.renaissance.jdk.streams.JmhMnemonics.run | -0.500% | -1.032% to 0.089% | > | org.renaissance.jdk.streams.JmhParMnemonics.run | -0.740% | -2.092% to 0.639% | > | org.renaissance.jdk.streams.JmhScrabble.run | -0.031% | -0.353% to 0.310% | > | org.renaissance.neo4j.JmhNeo4jAnalytics.run | -0.873% | -2.323% to 0.427% | > | org.renaissance.rx.JmhRxScrabble.run | -0.512% | -1.121% to 0.049% | > | org.renaissance.scala.dotty.JmhDotty.run | -0.219% | -1.108% to 0.708% | > | org.renaissance.scala.sat.JmhScalaDoku.run | -2.750% | -6.426% to -0.827% | > | org.renaissance.scala.stdlib.JmhScalaKmeans.run | 0.046% | -0.383% to 0.408% | > | org.renaissance.scala.stm.JmhPhilosophers.run | 1.497% | -0.955% to 3.923% | > | org.renaissance.scala.stm.JmhScalaStmBench7.run | -0.096% | -0.773% to 0.586% | > | org.renaissance.twitter.finagle.J... On 18/12/2025 13:28, Ruben wrote: > The |B.nv| might not be suitable in this case - I believe the branch > will be "always taken". Ah, so it is. That's a shame. > However, I had considered using |CBNZ XZR, <#imm>|. So far, I avoided > implementing it because it is unclear what performance effects this > might have. I've tried it, and it's definitely a lot slower than a NOP or a MOVZ. It would be nice if we could persuade the architecture people to give as a NOP with payload, perhaps because "Intel has it." But if we choose the split between CB offset and oopmap index wisely, we can avoid using a second instruction most of the time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3670392141 From liach at openjdk.org Thu Dec 18 16:28:36 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 16:28:36 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 04:58:38 GMT, Quan Anh Mai wrote: > So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. No. We currently cannot enforce such final fields to be all written before the `Object::` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::` either. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671092060 From rriggs at openjdk.org Thu Dec 18 16:46:26 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Dec 2025 16:46:26 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v2] In-Reply-To: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: > Refactor serialization tests to use JUnit. > Automated conversion for most annotations. > Conditional tests are refactored to use JUnit Enable/DisableIf. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Cleanup arglist and fix code style ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28877/files - new: https://git.openjdk.org/jdk/pull/28877/files/990e1358..e3fdaef1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=00-01 Stats: 25 lines in 2 files changed: 3 ins; 0 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/28877.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28877/head:pull/28877 PR: https://git.openjdk.org/jdk/pull/28877 From qamai at openjdk.org Thu Dec 18 16:49:25 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 18 Dec 2025 16:49:25 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 16:25:29 GMT, Chen Liang wrote: >> What I mean by stronger is that trusted final fields only ensure that their values are unchanged after initialization. Strict fields are unchanged unconditionally, there is only 1 observable state for a strict field of an object. As a result, in addition to constant folding, we can do load hoisting, too. So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. > >> So my question is why this annotation does not try to enforce a stronger invariant so that we can benefit from those invariants without having to wait for strict fields. > > No. We currently cannot enforce such final fields to be all written before the `Object::` entry, and I also don't think mainline has this safe publication fence at the beginning of `Object::` either. @liach I don't think we need such a condition, we only need to ensure that the fields are not read from and the object does not escape to memory before the termination of ``. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671176336 From liach at openjdk.org Thu Dec 18 18:12:59 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 18:12:59 GMT Subject: RFR: 8372696: Allow boot classes to explicitly opt-in for final field trusting [v7] In-Reply-To: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> References: <56pJKejOYp59xiAZ_0iAKzBpGnU341_0o5Dhy53jx_0=.d331165a-ae13-4ae2-923d-302d3bddccfd@github.com> Message-ID: On Thu, 18 Dec 2025 00:03:10 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: > > Move the test to a core library purposed directory We can port JDK-8354068 to mainline, but I think this is better done as a separate effort from the introduction of this annotation. This patch is more focused on the jdk implications. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3671501119 From liach at openjdk.org Thu Dec 18 18:18:29 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 18:18:29 GMT Subject: RFR: 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp:115 (ID: 51676) Message-ID: The bitwise manipulation code in ImageDecompressor::getU8 and getU4 utilizes implicit conversion to signed int for bitwise or, making this code confusing, especially when the most significant bytes are explicitly converted to unsigned long long, and unsigned long long takes part in a bitwise or with int. We should convert all u1 to u8/u4 before shifts to make the code easier to maintain and understand. ------------- Commit messages: - Yeat - Explicitly convert values for shifts and bitwise or Changes: https://git.openjdk.org/jdk/pull/28903/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28903&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373447 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28903.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28903/head:pull/28903 PR: https://git.openjdk.org/jdk/pull/28903 From dlsmith at openjdk.org Thu Dec 18 18:34:49 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 18:34:49 GMT Subject: RFR: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Message-ID: All 5 blocking issues have been addressed, and the jdkCheckLinks test can now be turned back on. ------------- Commit messages: - 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Changes: https://git.openjdk.org/jdk/pull/28904/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28904&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370249 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28904.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28904/head:pull/28904 PR: https://git.openjdk.org/jdk/pull/28904 From liach at openjdk.org Thu Dec 18 18:52:59 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 18:52:59 GMT Subject: RFR: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:24:39 GMT, Dan Smith wrote: > All 5 blocking issues have been addressed, and the jdkCheckLinks test can now be turned back on. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28904#pullrequestreview-3594555041 From dlsmith at openjdk.org Thu Dec 18 19:34:41 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 19:34:41 GMT Subject: Integrated: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:24:39 GMT, Dan Smith wrote: > All 5 blocking issues have been addressed, and the jdkCheckLinks test can now be turned back on. This pull request has now been integrated. Changeset: 6cbfc769 Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/6cbfc7691f8d3171cf223977b0b94e5f25fed93d Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28904 From liach at openjdk.org Thu Dec 18 20:47:48 2025 From: liach at openjdk.org (Chen Liang) Date: Thu, 18 Dec 2025 20:47:48 GMT Subject: [jdk26] Integrated: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 In-Reply-To: References: Message-ID: <5kRmsv8Dqeb4RLWJYruRapwRde3kbnO_tDrPrHtn-FM=.8741878c-b1fe-41d1-969b-d70348a43759@github.com> On Thu, 18 Dec 2025 19:33:32 GMT, Dan Smith wrote: > This pull request contains a backport of commit [6cbfc769](https://github.com/openjdk/jdk/commit/6cbfc7691f8d3171cf223977b0b94e5f25fed93d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28906#pullrequestreview-3594859940 From dlsmith at openjdk.org Thu Dec 18 20:47:48 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 20:47:48 GMT Subject: [jdk26] Integrated: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Message-ID: This pull request contains a backport of commit [6cbfc769](https://github.com/openjdk/jdk/commit/6cbfc7691f8d3171cf223977b0b94e5f25fed93d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang. ------------- Commit messages: - Backport 6cbfc7691f8d3171cf223977b0b94e5f25fed93d Changes: https://git.openjdk.org/jdk/pull/28906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370249 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28906/head:pull/28906 PR: https://git.openjdk.org/jdk/pull/28906 From dlsmith at openjdk.org Thu Dec 18 20:47:48 2025 From: dlsmith at openjdk.org (Dan Smith) Date: Thu, 18 Dec 2025 20:47:48 GMT Subject: [jdk26] Integrated: 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 19:33:32 GMT, Dan Smith wrote: > This pull request contains a backport of commit [6cbfc769](https://github.com/openjdk/jdk/commit/6cbfc7691f8d3171cf223977b0b94e5f25fed93d) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Dan Smith on 18 Dec 2025 and was reviewed by Chen Liang. This pull request has now been integrated. Changeset: a611399a Author: Dan Smith URL: https://git.openjdk.org/jdk/commit/a611399a3f0be1510ba2be461217eece201a0491 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod 8370249: Test jdk/javadoc/doccheck/checks/jdkCheckLinks.java fails due to JVMS/JLS links after JDK-8349681 Reviewed-by: liach Backport-of: 6cbfc7691f8d3171cf223977b0b94e5f25fed93d ------------- PR: https://git.openjdk.org/jdk/pull/28906 From duke at openjdk.org Thu Dec 18 22:42:31 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 18 Dec 2025 22:42:31 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 12:41:16 GMT, Alan Bateman wrote: >> @AlanBateman Thank you for the feedback! >> >> ## Analysis: >> >> **JEP 358 message advantages:** >> - More detailed: Shows which method call failed ("String.length()") >> - More informative: Explains the context of the failure >> >> **Objects.requireNonNull advantages:** >> - Explicit API contract: Makes it clear at method entry that null is not allowed >> - Fail-fast: Exception occurs at method entry, not deep in the method body >> - Consistent across JDK versions: Works the same way in JDK 8, 11, 14, 17, etc. >> - Simpler message: Just the parameter name >> >> I understand that with JEP 358, there's less need for explicit null checks in many cases. However, I believe `Objects.requireNonNull` still provides value by: >> 1. Making the API contract explicit at the method signature level >> 2. Failing fast before any method body execution >> 3. Providing consistent behavior across all JDK versions >> >> I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? > >> I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? > > Would you mind pasting in the existing NPE message and the new NPE message? Of course. Thank you for the review, @AlanBateman! Here are the NPE messages: **Existing NPE message (JEP 358 automatic, without Objects.requireNonNull):** java.lang.NullPointerException: Cannot invoke "String.length()" because "s" is null **New NPE message (with Objects.requireNonNull):** java.lang.NullPointerException: s The JEP 358 message provides more context (shows which method call failed), while Objects.requireNonNull provides a simpler message and fails fast at method entry. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3672535570 From rriggs at openjdk.org Thu Dec 18 22:48:44 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 18 Dec 2025 22:48:44 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 12:56:14 GMT, eunbin son wrote: > ## Summary > > Add explicit null check using `Objects.requireNonNull` in > `DataOutputStream.writeBytes(String s)` to provide a clearer error message > and make the API contract explicit. > > ## Problem > > The `writeBytes` method currently throws a `NullPointerException` when > `null` is passed, but the error message may not be clear in all contexts. > While JDK 14+ provides helpful NullPointerException messages through > JEP 358 (Helpful NullPointerExceptions), adding an explicit null check > using `Objects.requireNonNull` makes the API contract more explicit and > provides consistent error messaging across different JDK versions. > > ## Solution > > Added `Objects.requireNonNull(s, "s")` at the beginning of the > `writeBytes(String s)` method. This ensures: > - A clear error message ("s") is provided when null is passed > - The API contract explicitly states that null is not allowed > - The method fails fast with a descriptive exception > > ## Issue > Fixes JDK-8373660 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 > > > ## Type of Change > - [x] Test addition/modification > - [x] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > A new JUnit test has been added to verify the null check behavior: > > > # Run the specific JUnit test file > make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" > > # Or run all tests in the DataOutputStream directory > make test TEST="jtreg:test/jdk/java/io/DataOutputStream" $0.02, The original exception message is complete and accurate without adding extra bytecodes or an extra line of source. I don't think the addition is worthwhile. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3672567334 From duke at openjdk.org Thu Dec 18 23:07:13 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 18 Dec 2025 23:07:13 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 22:46:00 GMT, Roger Riggs wrote: >> ## Summary >> >> Add explicit null check using `Objects.requireNonNull` in >> `DataOutputStream.writeBytes(String s)` to provide a clearer error message >> and make the API contract explicit. >> >> ## Problem >> >> The `writeBytes` method currently throws a `NullPointerException` when >> `null` is passed, but the error message may not be clear in all contexts. >> While JDK 14+ provides helpful NullPointerException messages through >> JEP 358 (Helpful NullPointerExceptions), adding an explicit null check >> using `Objects.requireNonNull` makes the API contract more explicit and >> provides consistent error messaging across different JDK versions. >> >> ## Solution >> >> Added `Objects.requireNonNull(s, "s")` at the beginning of the >> `writeBytes(String s)` method. This ensures: >> - A clear error message ("s") is provided when null is passed >> - The API contract explicitly states that null is not allowed >> - The method fails fast with a descriptive exception >> >> ## Issue >> Fixes JDK-8373660 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 >> >> >> ## Type of Change >> - [x] Test addition/modification >> - [x] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> A new JUnit test has been added to verify the null check behavior: >> >> >> # Run the specific JUnit test file >> make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" >> >> # Or run all tests in the DataOutputStream directory >> make test TEST="jtreg:test/jdk/java/io/DataOutputStream" > > $0.02, The original exception message is complete and accurate without adding extra bytecodes or an extra line of source. > I don't think the addition is worthwhile. @RogerRiggs Thank you for the review! I've reviewed the OpenJDK codebase and found that most code uses just the parameter name (e.g., `Objects.requireNonNull(out, "out")`), which is what I've used here. However, the Objects.java Javadoc examples use more descriptive messages like `"bar must not be null"`. Using `Objects.requireNonNull` at the method entry point allows us to immediately identify the problematic parameter and makes the API contract explicit. By using a more descriptive message like `"s must not be null"`, we can provide a complete and accurate error message that clearly indicates which parameter is null and why it cannot be null, while still maintaining the benefits of fail-fast validation at method entry. I'm open to changing it to a more descriptive message if that's the preferred approach. Would you like to share your opinion on this approach? - `Objects.requireNonNull(s, "s must not be null")` I'm happy to follow the project's conventions and your guidance on this. Thank you for take time to review this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3672625364 From almatvee at openjdk.org Thu Dec 18 23:12:19 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 18 Dec 2025 23:12:19 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil Message-ID: - I was not able to reproduce this issue. - Based on log we calling same detach command simultaneously: [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. - Fixed by mounting DMG into random location. - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. ------------- Commit messages: - 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil Changes: https://git.openjdk.org/jdk/pull/28912/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28912&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373105 Stats: 14 lines in 1 file changed: 12 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28912/head:pull/28912 PR: https://git.openjdk.org/jdk/pull/28912 From almatvee at openjdk.org Thu Dec 18 23:32:17 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 18 Dec 2025 23:32:17 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: <7Yof-eGWYnGPdA_7TKRpV-bW9miNwtOpI5BFzPnVcTs=.1374a1db-36d7-4396-8c67-b358f5ce2d42@github.com> On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. @alexeysemenyukoracle Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28912#issuecomment-3672728781 From dl at openjdk.org Thu Dec 18 23:38:19 2025 From: dl at openjdk.org (Doug Lea) Date: Thu, 18 Dec 2025 23:38:19 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v13] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 16 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check diagnosis - Avoid double-filtering - Merge branch 'openjdk:master' into JDK-8373118 - Another diagnostic - Relax orderings in push - Reduce fencing - Adjust runworker for previous update - Reorder signalWork filter - ... and 6 more: https://git.openjdk.org/jdk/compare/b80c07f3...b0b37d38 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/2d8cff2b..b0b37d38 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=11-12 Stats: 112 lines in 6 files changed: 43 ins; 50 del; 19 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 asemenyuk at openjdk.org Thu Dec 18 23:58:17 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 18 Dec 2025 23:58:17 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. I once suspected jpackage's DMG attach/detach code was not very reliable, as the fixed volume name is used and filed [JDK-8371494](https://bugs.openjdk.org/browse/JDK-8371494) to investigate. Back then, as I never observed AsyncTest failures, I closed the CR as not an issue. It merely took some time to reveal the problem. We need both jpackage and the test code fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28912#issuecomment-3672780072 From jlu at openjdk.org Fri Dec 19 00:21:40 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 19 Dec 2025 00:21:40 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:01:07 GMT, Justin Lu wrote: > Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit. > > First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974. > https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run. > https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool. > The rest of the commits are aesthetic related. > > Before conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit > > > After conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java line 202: > 200: @Test > 201: public void test_get_TemporalField_invalidField() { > 202: Assertions.assertThrows(DateTimeException.class, () -> { It appears that not all the `TemporalAccessor`s from `samples()` are being tested. I want to keep the total count of tests before and after the migration the same, so handling this separate from this issue. Filed [JDK-8374051](https://bugs.openjdk.org/browse/JDK-8374051). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2632918995 From jlu at openjdk.org Fri Dec 19 00:21:40 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 19 Dec 2025 00:21:40 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG Message-ID: Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit. First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974. https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run. https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool. The rest of the commits are aesthetic related. Before conversion stats Test results: passed: 187 Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit After conversion stats Test results: passed: 187 Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit ------------- Commit messages: - Fixing @timeout as well as unrelated stray spacing - Apply copyright years - Cleaning up some leftover whitespace from tool - Automated conversion created statement lambdas for exception tests. Modify to expression lambdas - Cleaning up unused JUnit imports - Fix converted lambdas - Mark TEST.properties as JUnit dirs - Apply JUnitConvert Changes: https://git.openjdk.org/jdk/pull/28911/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373830 Stats: 13726 lines in 178 files changed: 2264 ins; 690 del; 10772 mod Patch: https://git.openjdk.org/jdk/pull/28911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28911/head:pull/28911 PR: https://git.openjdk.org/jdk/pull/28911 From almatvee at openjdk.org Fri Dec 19 01:03:54 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 19 Dec 2025 01:03:54 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: <86R2lvuHMqmCvfaxAU9X2-m2bE6Ozkw4D3y0RfgOw2Y=.99d6ac99-5f1c-4899-ab98-628fda412eac@github.com> On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. We do not need to fix jpackage. It is already uses random mount root. Example from trace: /usr/bin/hdiutil attach /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage8052723072987214442/dmg-workdir/proto.dmg -verbose -mountroot /var/folders/dr/65dj5x3j0296mqtsn9z27xc80000gn/T/jdk.jpackage8052723072987214442/dmg-workdir ------------- PR Comment: https://git.openjdk.org/jdk/pull/28912#issuecomment-3672976643 From swen at openjdk.org Fri Dec 19 02:43:01 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Dec 2025 02:43:01 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 09:01:09 GMT, Johannes D?bler wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove redundant checkField > > src/java.base/share/classes/java/time/format/Parsed.java line 175: > >> 173: */ >> 174: @SuppressWarnings("unchecked") >> 175: Parsed(boolean onlyChronoField) { > > If you know that only ChronoFields are used then imho the loop over the entries of `fieldValues` in method `resolveFields` can be skipped (line 290ff). Good suggestion, but that should be a separate PR ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2633378092 From swen at openjdk.org Fri Dec 19 02:46:55 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Dec 2025 02:46:55 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 12:11:14 GMT, Johannes D?bler wrote: >> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision: >> >> remove redundant checkField > > src/java.base/share/classes/java/time/format/DateTimeFormatter.java line 551: > >> 549: * This is used to optimize the storage of parsed field values in the Parsed class. >> 550: */ >> 551: final boolean onlyChronoField; > > If you add to DateTimePrinterParser the method: > > public default boolean onlyChronoFields() { > return true; > } > > and override in CompositePrinterParser, NumberPrinterParser, TextPrinterParser, DefaultValueParser with obvious implementations you should be able to get rid of this field, same in DateTimeFormatterBuilder. (Or keep the field, but initialize in the constructor from printerParser). https://github.com/openjdk/jdk/pull/28471/changes/d8742d7514abfe0e36f105fa7310fdb1755ae546 The initial version was similar to what you suggested. In the discussion above, I accepted liach's suggestion and modified it into the current implementation. I prefer the current implementation, and it will be easier to calculate chronoFieldsBitSet in the next step. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28471#discussion_r2633384391 From asemenyuk at openjdk.org Fri Dec 19 03:03:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 19 Dec 2025 03:03:50 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. Oh, right. The issue is with the `hdiutil attach` command, not with `hdiutil create`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28912#issuecomment-3673283394 From asemenyuk at openjdk.org Fri Dec 19 03:09:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 19 Dec 2025 03:09:52 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: <8jWeSSU3JYdStNB6MGPI3TO2rqHrGOPAXzZ3rVFkXx4=.a566a954-73da-4384-beb1-d5c0bdfff314@github.com> On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. Changes requested by asemenyuk (Reviewer). test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 89: > 87: final Path mountRoot; > 88: try { > 89: mountRoot = Files.createTempDirectory("mountRoot"); Temporary test files should be created in the test working directory. Use `TKit.createTempDirectory("mount-root")` instead. It also makes the newly added `TKit.deleteDirectoryRecursive(mountRoot, "");` call redundant, as the test working directory will be deleted automatically when the test exits. `TKit.createTempDirectory()` throws unchecked exceptions; the `try/catch` is redundant. ------------- PR Review: https://git.openjdk.org/jdk/pull/28912#pullrequestreview-3596572759 PR Review Comment: https://git.openjdk.org/jdk/pull/28912#discussion_r2633421368 From swen at openjdk.org Fri Dec 19 06:14:49 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Dec 2025 06:14:49 GMT Subject: RFR: 8315585: Optimization for decimal to string [v6] In-Reply-To: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> Message-ID: <4EdAcA5QAPHJxBlMj5IP88E4Ymkvjf24z5vcWrjJOFE=.616d890e-a5cc-40ed-9010-9e44f3bcde43@github.com> > Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 - simplify layoutChars - comments, from @liach - getValueString -> getCompactValueString, from @liach - Refactor BigDecimal string creation to use JLA.uncheckedNewStringWithLatin1Bytes Co-authored-by: Qwen-Coder - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 # Conflicts: # src/java.base/share/classes/java/math/BigDecimal.java - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 # Conflicts: # src/java.base/share/classes/java/math/BigDecimal.java # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java # test/micro/org/openjdk/bench/java/math/BigDecimals.java - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 # Conflicts: # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java - remove getChars(long, int, char[]) - ... and 27 more: https://git.openjdk.org/jdk/compare/3f33eaa4...32d95b36 ------------- Changes: https://git.openjdk.org/jdk/pull/23310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23310&range=05 Stats: 449 lines in 3 files changed: 243 ins; 108 del; 98 mod Patch: https://git.openjdk.org/jdk/pull/23310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23310/head:pull/23310 PR: https://git.openjdk.org/jdk/pull/23310 From liach at openjdk.org Fri Dec 19 06:14:55 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 06:14:55 GMT Subject: RFR: 8315585: Optimization for decimal to string [v6] In-Reply-To: <4EdAcA5QAPHJxBlMj5IP88E4Ymkvjf24z5vcWrjJOFE=.616d890e-a5cc-40ed-9010-9e44f3bcde43@github.com> References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> <4EdAcA5QAPHJxBlMj5IP88E4Ymkvjf24z5vcWrjJOFE=.616d890e-a5cc-40ed-9010-9e44f3bcde43@github.com> Message-ID: On Fri, 19 Dec 2025 06:10:56 GMT, Shaojin Wen wrote: >> Continue to complete PR #16006 and PR #21593 to improve BigDecimal::toString and BigDecimal::toPlainString performance and reduce duplicate code > > Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: > > - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 > - simplify layoutChars > - comments, from @liach > - getValueString -> getCompactValueString, from @liach > - Refactor BigDecimal string creation to use JLA.uncheckedNewStringWithLatin1Bytes > > Co-authored-by: Qwen-Coder > - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 > > # Conflicts: > # src/java.base/share/classes/java/math/BigDecimal.java > - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 > > # Conflicts: > # src/java.base/share/classes/java/math/BigDecimal.java > # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > # test/micro/org/openjdk/bench/java/math/BigDecimals.java > - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 > - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 > > # Conflicts: > # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java > - remove getChars(long, int, char[]) > - ... and 27 more: https://git.openjdk.org/jdk/compare/3f33eaa4...32d95b36 src/java.base/share/classes/java/math/BigDecimal.java line 3456: > 3454: > 3455: long intCompact = this.intCompact; > 3456: // currency fast path This comment should be moved to the `scale2` method. src/java.base/share/classes/java/math/BigDecimal.java line 3468: > 3466: } > 3467: > 3468: private static String getValueString(int signum, long intCompactAbs, int intCompactAbsSize, int scale) { I recommend naming this `getCompactValueString` to indicate this differs from `getValueString` by accepting only compact values. Something like: "Returns a digit.digit string for a compact value" src/java.base/share/classes/java/math/BigDecimal.java line 4223: > 4221: if ((scale >= 0) && (adjusted >= -6)) { // plain number > 4222: return getValueString(signum, coeff, scale); > 4223: } Let's move this `if ((scale >= 0) && (adjusted >= -6)) {` into the `else` for `if (intCompact != INFLATED) {` above for parity. src/java.base/share/classes/java/math/BigDecimal.java line 4237: > 4235: if (coeffLen > 1) { // more to come > 4236: buf.append('.') > 4237: .append(coeff, 1, coeffLen); Is this right that the old end is `coeffLen - 1` but the new end is `coeffLen`? I don't see why there should be no more `-1`. src/java.base/share/classes/java/math/BigDecimal.java line 4289: > 4287: return JLA.uncheckedNewStringWithLatin1Bytes(buf); > 4288: } > 4289: private String unscaledString() { Suggestion: } private String unscaledString() { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2621031566 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2621027174 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2621172443 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2621180081 PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2621181708 From swen at openjdk.org Fri Dec 19 06:14:57 2025 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 19 Dec 2025 06:14:57 GMT Subject: RFR: 8315585: Optimization for decimal to string [v6] In-Reply-To: References: <82Xwac0lVIdkdXb4oxPb5ub3EOxA01mlzz1F2552i0c=.5e466c37-7673-4a17-b46d-47d7f9e64100@github.com> <4EdAcA5QAPHJxBlMj5IP88E4Ymkvjf24z5vcWrjJOFE=.616d890e-a5cc-40ed-9010-9e44f3bcde43@github.com> Message-ID: On Mon, 15 Dec 2025 23:30:06 GMT, Chen Liang wrote: >> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits: >> >> - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 >> - simplify layoutChars >> - comments, from @liach >> - getValueString -> getCompactValueString, from @liach >> - Refactor BigDecimal string creation to use JLA.uncheckedNewStringWithLatin1Bytes >> >> Co-authored-by: Qwen-Coder >> - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 >> >> # Conflicts: >> # src/java.base/share/classes/java/math/BigDecimal.java >> - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 >> >> # Conflicts: >> # src/java.base/share/classes/java/math/BigDecimal.java >> # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java >> # test/micro/org/openjdk/bench/java/math/BigDecimals.java >> - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 >> - Merge remote-tracking branch 'upstream/master' into dec_to_str_202501 >> >> # Conflicts: >> # src/java.base/share/classes/jdk/internal/util/DecimalDigits.java >> - remove getChars(long, int, char[]) >> - ... and 27 more: https://git.openjdk.org/jdk/compare/3f33eaa4...32d95b36 > > src/java.base/share/classes/java/math/BigDecimal.java line 4237: > >> 4235: if (coeffLen > 1) { // more to come >> 4236: buf.append('.') >> 4237: .append(coeff, 1, coeffLen); > > Is this right that the old end is `coeffLen - 1` but the new end is `coeffLen`? I don't see why there should be no more `-1`. If we use `new BigDecimal("4.933579065397471E-11").toString()` as an example: In the original code, `coeff` is generated as follows, with three unused null values ??before the `char[]`: coeff = new char[19]; offset = DecimalDigits.getChars(Math.abs(intCompact), coeff.length, coeff); The code that was called: // coeff := [, , , 4, 9, 3, 3, 5, 7, 9, 0, 6, 5, 3, 9, 7, 4, 7, 1] // offset := 3 // coeffLen := 16 // append(char[] str, int offset, int len) buf.append(coeff, offset + 1, coeffLen - 1); In the new code, coeff is generated as follows: byte[] buf = new byte[coeffLen]; DecimalDigits.uncheckedGetCharsLatin1(intCompactAbs, buf.length, buf); coeff = newStringNoRepl(buf); The method call has also been changed from `append(char[] str, int offset, int len)` to `append(CharSequence s, int start, int end)`. // coeff := "4933579065397471" // coeffLen := 16 // append(CharSequence s, int start, int end) buf.append(coeff, 1, coeffLen); | | origin | current | |---------------|----------------------------------------------------------------------------|--------------------| | coeoff | [ 0x00, 0x00, 0x00, 4, 9, 3, 3, 5, 7, 9, 0, 6, 5, 3, 9, 7, 4, 7, 1] | "4933579065397471" | | offset | 3 | | | coeffLen | 16 | 16 | | call method | append(char[] str, int offset, int len) | append(CharSequence s, int start, int end) | ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/23310#discussion_r2633331853 From jbhateja at openjdk.org Fri Dec 19 06:29:57 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 19 Dec 2025 06:29:57 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> Message-ID: On Thu, 13 Nov 2025 19:47:52 GMT, Paul Sandoz wrote: >>> The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class. >> >> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable > >> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class. >> >> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable > > I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g., T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind. Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. Hi @eme64 , Kindly share your comments. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673727967 From alanb at openjdk.org Fri Dec 19 06:33:54 2025 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 19 Dec 2025 06:33:54 GMT Subject: RFR: 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:01:03 GMT, Chen Liang wrote: > The bitwise manipulation code in ImageDecompressor::getU8 and getU4 utilizes implicit conversion to signed int for bitwise or, making this code confusing, especially when the most significant bytes are explicitly converted to unsigned long long, and unsigned long long takes part in a bitwise or with int. We should convert all u1 to u8/u4 before shifts to make the code easier to maintain and understand. Looks okay. I assume you will run at least tier1-tier5 so check the various builds and configurations. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28903#pullrequestreview-3597088988 From epeter at openjdk.org Fri Dec 19 07:03:58 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 19 Dec 2025 07:03:58 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> Message-ID: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja wrote: >>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class. >>> >>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable >> >> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g., T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind. > > Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. > Hi @eme64 , Kindly share your comments. @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3673842243 From abimpoudis at openjdk.org Fri Dec 19 07:08:06 2025 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 19 Dec 2025 07:08:06 GMT Subject: [jdk26] Integrated: 8373552: ExactConversionsSupport: bad JLS links in javadoc In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 13:44:56 GMT, Aggelos Biboudis wrote: > Hi all, > > This pull request contains a backport of commit [9a23f8aa](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/9a23f8aa337e1292179625ce9bb8abe22c9e22e2__;!!ACWV5N9M2RV99hQ!ODxLmrmWdnBMblnjNoeOr6ngrizirMDIh6Jg5qb80Req5yuCrVFSD6xAMZA9Z0Dz0hixsZx2wYBErPApp89s8baaWJ04oOE$) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Aggelos Biboudis on 17 Dec 2025 and was reviewed by Chen Liang and Iris Clark. > > Thanks! This pull request has now been integrated. Changeset: 2dc6c491 Author: Aggelos Biboudis URL: https://git.openjdk.org/jdk/commit/2dc6c491bffd12d62e19c788ff4e516ed94d7198 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod 8373552: ExactConversionsSupport: bad JLS links in javadoc Reviewed-by: liach Backport-of: 9a23f8aa337e1292179625ce9bb8abe22c9e22e2 ------------- PR: https://git.openjdk.org/jdk/pull/28870 From jpai at openjdk.org Fri Dec 19 07:48:28 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 19 Dec 2025 07:48:28 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds Message-ID: Can I please get a review of this test-only change which addresses intermittent failures in `java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java`? The `@summary` in that test's test definition about what this test does: > @summary When the "java.rmi.dgc.leaseValue" system property is set to a > value much lower than its default (10 minutes), then the server-side > user-visible detection of DGC lease expiration-- in the form of > Unreferenced.unreferenced() invocations and possibly even local garbage > collection (including weak reference notification, finalization, etc.)-- > may be delayed longer than expected. While this is not a spec violation > (because there are no timeliness guarantees for any of these garbage > collection-related events), the user might expect that an unreferenced() > invocation for an object whose last client has terminated abnormally > should occur on relatively the same time order as the lease value > granted. In its current form, the test uses a lease expiry of 10 seconds, launches a trivial `java` application which looks up the bound object from the registry and then terminates itself. After launching that trivial java application, the test then waits for 20 seconds, expecting that the `Unreferenced.unreferenced()` callback (upon lease expiry of 10 seconds) will be called within those 20 seconds. This wait intermittently fails because the `Unreferenced.unreferenced()` doesn't get called within those 20 seconds. Experiments show that the reason for these intermittent failures is due to the `SelfTerminator` application which does the registry lookup (and which involves connection establishment and communication over a socket) can sometimes take several seconds (5 or more for example). That effectively means that by the time this `SelfTerminator` starts its termination after the lookup, it's already several seconds into the "wait()" in the test. The commit in this PR cleans up the test to more accurately track the duration of how long it took between the lease expiry and the `Unreferenced.unreferenced()` callback to be invoked. Additionally, just to make the test more robust, the maximum expected duration has been increased to 60 seconds instead of 20 seconds. Given the text in the test's summary, I think this increase is still within the expectations of how long it takes for the callback to be invoked after the client has exited abnormally. The test continues to pass with this change and a test repeat of 50 too did not reproduce any failures. ------------- Commit messages: - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds Changes: https://git.openjdk.org/jdk/pull/28919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8170896 Stats: 79 lines in 2 files changed: 42 ins; 16 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/28919.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28919/head:pull/28919 PR: https://git.openjdk.org/jdk/pull/28919 From xgong at openjdk.org Fri Dec 19 08:46:07 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 19 Dec 2025 08:46:07 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v3] 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 Fri, 12 Dec 2025 15:42:24 GMT, Bhavana Kilambi wrote: >> 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 Neoverse V1 and Neoverse V2 for mul reduction but none for Neoverse N1. The following is ratio between throughput with `ext` and throughput with `ins` (`>1` would mean `ext` is better) on Neoverse V2 - > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > href="file:////Users/bhakil01/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip.htm"> > href="file:////Users/bhakil01/Library/Group%20Containers/UBF8T346G9.Office/TemporaryItems/msohtmlclip/clip_filelist.xml"> > > > > > > > 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 > > > > > > > > The 20% gain you mentioned is reproducible but only for the smallest array size. The gains taper for larger array sizes (my wild guess is that for smaller array sizes the loop is lantency-bound so reducing the dependency due to the `ins` chains helps bring down the total latency but for larger array sizes the loop becomes more memory bound with more number of loads/stores and probably here removing the `ins` dependency chains doesn't help much?). > > > Similar number for Neoverse V1 - > > xmlns:o="urn:schemas-microsoft-com:office:office" > xmlns:x="urn:schemas-microsoft-com:office:excel" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Thu, 18 Dec 2025 10:17:47 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 gener... > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Fix build failures on Mac src/hotspot/cpu/aarch64/aarch64_vector.ad line 3457: > 3455: format %{ "reduce_addD_sve $dst_src1, $dst_src1, $src2" %} > 3456: ins_encode %{ > 3457: assert(UseSVE > 0, "must be sve"); Why do you remove this assertion? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2634230858 From xgong at openjdk.org Fri Dec 19 08:54:58 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 19 Dec 2025 08:54:58 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Wed, 17 Dec 2025 10:45:46 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 gener... > > Bhavana Kilambi 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: > > - Address review comments > - Merge 'master' > - 8366444: Add support for add/mul reduction operations for Float16 > > 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 > Redu... src/hotspot/cpu/aarch64/aarch64_vector.ad line 3490: > 3488: %} > 3489: ins_pipe(pipe_slow); > 3490: %} Could you please float this rule above `reduce_addF_sve` and below `reduce_addHF`? Better to rename `reduce_addHF` to `reduce_addHF_neon` ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2634240241 From xgong at openjdk.org Fri Dec 19 09:11:56 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Fri, 19 Dec 2025 09:11:56 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v3] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <58NIPjOC6PTzn0H5BwY5FUkNfpe_qHuHLyIPCLiZ1QI=.0bf7f024-e772-459c-bd96-01981446beda@github.com> On Thu, 18 Dec 2025 10:17:47 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 gener... > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Fix build failures on Mac src/hotspot/cpu/aarch64/aarch64_vector.ad line 259: > 257: // implements strictly ordered floating point add reduction which does not require > 258: // the FEAT_FP16 and ASIMDHP checks as SVE supports half-precision floats by default. > 259: case Op_AddReductionVHF: Does it need to check `length_in_bytes < 8` for add reduction? src/hotspot/cpu/aarch64/aarch64_vector.ad line 392: > 390: case Op_StoreVectorScatter: > 391: case Op_AddReductionVF: > 392: case Op_AddReductionVHF: Suggestion: case Op_AddReductionVHF: case Op_AddReductionVF: src/hotspot/share/opto/vectornode.hpp line 323: > 321: // is generated through VectorAPI as VectorAPI does not impose any such rules on ordering. > 322: const bool _requires_strict_order; > 323: public: Suggestion: const bool _requires_strict_order; public: ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2634252247 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2634258731 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2634278136 From erfang at openjdk.org Fri Dec 19 09:55:25 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 19 Dec 2025 09:55:25 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v4] 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 incrementally with one additional commit since the last revision: Refine the tests for identity values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28692/files - new: https://git.openjdk.org/jdk/pull/28692/files/d685d3df..b5237a28 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=02-03 Stats: 8949 lines in 42 files changed: 5473 ins; 2384 del; 1092 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 19 09:55:28 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 19 Dec 2025 09:55:28 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 03:31:07 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 pull request now contains four commits: > > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - 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. Hi @PaulSandoz @merykitty , I have resolved your comments, would you mind taking another look, thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3674350285 From erfang at openjdk.org Fri Dec 19 09:55:31 2025 From: erfang at openjdk.org (Eric Fang) Date: Fri, 19 Dec 2025 09:55:31 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: Message-ID: <7AWYFpxh5IuDz-ILQnB1thgi5mFmfS0waEmJFfPcmM0=.ec8acf99-5311-405d-957f-526bd8d4af62@github.com> On Tue, 16 Dec 2025 17:26:57 GMT, Paul Sandoz wrote: >> Eric Fang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: >> >> - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity >> - 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. > > test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template line 12: > >> 10: $abstractvectortype$ av = $abstractvectortype$.fromArray(SPECIES, a, i); >> 11: r[i] = av.reduceLanes(VectorOperators.[[TEST]], vmask); >> 12: ra = [[TEST_OP]](ra, r[i]); > > It's probably ok to merge the two cases, but to be conservative assign to a local variable rather than reading from the array e.g., > > $type$ v = av.reduceLanes(VectorOperators.[[TEST]], vmask); > r[i] = v; > ra = [[TEST_OP]](ra, v); Hi @PaulSandoz . I've changed to using a temporary variable. By the way, are you worried that the `read-after-write` optimization isn't implemented in some architectures? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2634426258 From asemenyuk at openjdk.org Fri Dec 19 13:06:39 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 19 Dec 2025 13:06:39 GMT Subject: Integrated: 8373710: Improve jpackage error reporting In-Reply-To: References: Message-ID: <98ddMrkgDhQP6dXfQDUxMhLyimIZjdbPGP6ahkTiWH8=.7fd85ae2-5d77-4a81-b28d-35bdb82ee567@github.com> On Mon, 15 Dec 2025 21:20:49 GMT, Alexey Semenyuk wrote: > - Append "Error: " prefix to error messages > - Always print stack traces of internal exceptions, not only when running in verbose mode This pull request has now been integrated. Changeset: 45642acf Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/45642acf1b290306509375e58bde8f6c9cd1b308 Stats: 257 lines in 5 files changed: 237 ins; 1 del; 19 mod 8373710: Improve jpackage error reporting Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28833 From ysuenaga at openjdk.org Fri Dec 19 14:14:59 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 19 Dec 2025 14:14:59 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory In-Reply-To: <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com> References: <5tNWv176ukslb0DlkjmhiYH3QU6yoOuq68IMtWrtKy4=.79f473a2-c106-4928-ba8e-8f8a55de6383@github.com> Message-ID: On Thu, 18 Dec 2025 13:37:50 GMT, Sebastian L?vdahl wrote: >> @slovdahl I found out the cause of error in TestJcmdWithSideCar.java. It is not a bug, environment issue. >> I sent email to serviceability-dev because it is different from this PR. >> https://mail.openjdk.org/pipermail/serviceability-dev/2025-December/068668.html >> >> Anyway, I'm waiting for Reviewers for this PR! > > @YaSuenag Interesting, thanks for figuring that part out. > > In any case, I also ran the tests locally now (using Docker 29.1.3 on Ubuntu 24.04), both on the latest JDK master branch and on your branch. Both passed. > > > make test TEST=test/hotspot/jtreg/containers/docker/TestJcmdWithSideCar.java JTREG=RUN_PROBLEM_LISTS=true > > > But on another note, I'm wondering if this change breaks the fix from https://bugs.openjdk.org/browse/JDK-8226919 and https://github.com/openjdk/jdk/pull/17628. > > Unfortunately there is no jtreg test for it, but by following the steps I did in https://github.com/openjdk/jdk/pull/17628#issuecomment-1916589081 and trying to attach to a JVM run as a systemd unit with extra privileges using a JDK built from this branch, I got this error: > > > [15:35:41] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/java -version > openjdk version "27-internal" 2026-09-15 > OpenJDK Runtime Environment (build 27-internal-adhoc.slovdahl.jdk) > OpenJDK 64-Bit Server VM (build 27-internal-adhoc.slovdahl.jdk, mixed mode, sharing) > > [15:30:58] ~/dev/external/jdk-8226919-reproducer ? /home/slovdahl/dev/external/jdk/build/linux-x86_64-server-release/images/jdk/bin/jcmd $(pgrep -f Reproducer.java) VM.version > 2799281: > com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineImpl.java:281) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findSocketFile(VirtualMachineImpl.java:231) > at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:82) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > Caused by: java.nio.file.AccessDeniedException: /proc/2799281/root/tmp > at java.base/sun.nio.fs.UnixException.translateToIOException(UnixException.java:90) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:108) > at java.base/sun.nio.fs.UnixException.rethrowAsIOException(UnixException.java:113) > at java.base/sun.nio.fs.UnixFileSystemProvider.isSameFile(UnixFileSystemProvider.java:391) > at java.base... @slovdahl I fix the problem, and I added new testcase as TestWithoutDumpableProcess.java which covers your use case. I reproduce the problem which is same situation with your case with `prctl()` with `PR_SET_DUMPABLE`. if `PR_SET_DUMPABLE` is disabled, most of file owner in procfs is root and we cannot access /proc//root even though `jcmd` lists the process. New testcase call `prctl` via FFM. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28867#issuecomment-3675225882 From ysuenaga at openjdk.org Fri Dec 19 14:47:40 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Fri, 19 Dec 2025 14:47:40 GMT Subject: RFR: 8373867: Improve robustness of Attach API for finding tmp directory [v4] In-Reply-To: References: Message-ID: > We can see several thread dump on the console of Distroless nonroot JDK when we attach debug (root) Distroless container image to the nonroot container as following. It is not expected. > > > $ podman run -it --rm --name debuggee -v `pwd`/LongSleep:/opt/LongSleep:Z --entrypoint java gcr.io/distroless/java25-debian13:nonroot -cp /opt/LongSleep -Xlog:attach=debug LongSleep > [38.252s][debug][attach] Failed to find attach file: /tmp/.attach_pid1 > 2025-12-17 06:34:37 > Full thread dump OpenJDK 64-Bit Server VM (25.0.1+8-LTS mixed mode, sharing): > > Threads class SMR info: > _java_thread_list=0x000078a8bc13f200, length=10, elements={ > 0x000078a8bc02bb60, 0x000078a8bc128200, 0x000078a8bc1293f0, 0x000078a8bc12ae40, > 0x000078a8bc12c760, 0x000078a8bc12dfe0, 0x000078a8bc12fde0, 0x000078a8bc1317d0, > : > > > Attach API put `.attach_pid` file at first to clarify subsequent SIGQUIT means create AttachListener thread. That file attempt to create on current work directory of the target process, but it would fallback to /tmp if failed (e.g. attacher cannot write onto work directory). > > In case of attaching nonroot container from root container, and also it would fail due to lack of write permission on current work directory, and cannot access /proc//root/tmp. It causes following error on jcmd: > > > $ podman run -it --rm --pid container:debuggee --entrypoint sh gcr.io/distroless/java25-debian13:debug > / # /usr/lib/jvm/jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file /tmp/.java_pid1: target process 1 doesn't respond within 10500ms or HotSpot VM not loaded > at jdk.attach/sun.tools.attach.VirtualMachineImpl.(VirtualMachineImpl.java:115) > at jdk.attach/sun.tools.attach.AttachProviderImpl.attachVirtualMachine(AttachProviderImpl.java:56) > at jdk.attach/com.sun.tools.attach.VirtualMachine.attach(VirtualMachine.java:201) > at jdk.jcmd/sun.tools.jcmd.JCmd.executeCommandForPid(JCmd.java:113) > at jdk.jcmd/sun.tools.jcmd.JCmd.main(JCmd.java:97) > > / # ls -l /proc/1/cwd > ls: /proc/1/cwd: cannot read link: Permission denied > lrwxrwxrwx 1 nonroot nonroot 0 Dec 17 06:34 /proc/1/cwd > > > > After this change, we can see following exception on the console of jcmd when we encounter this situation: > > # jcmd 1 VM.version > 1: > com.sun.tools.attach.AttachNotSupportedException: Unable to access the filesystem of the target process > at jdk.attach/sun.tools.attach.VirtualMachineImpl.findTargetProcessTmpDirectory(VirtualMachineIm... Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision: Improve exception ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28867/files - new: https://git.openjdk.org/jdk/pull/28867/files/dfd9a18b..3341dd60 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28867&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28867.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28867/head:pull/28867 PR: https://git.openjdk.org/jdk/pull/28867 From rriggs at openjdk.org Fri Dec 19 17:00:52 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Dec 2025 17:00:52 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: <5l25k-v0rc0U-lYSzjK7bCi8falsChSQRkWHPUBVFao=.a4bcc9fb-1a93-44c8-b175-9a6735810cbe@github.com> On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. Comment on the description contents and formatting: Skara (the automation for OpenJDK PRs) adds its own content (using Markdown) at the end to document the progress and steps. The final bit of `preformatted` text in the description does not seem to be closed properly so the Skara comment shows up as raw Markdown. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3675814936 From rriggs at openjdk.org Fri Dec 19 17:05:01 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Dec 2025 17:05:01 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: <-uFHJHbrctIL1QmP1oW-7nQ0eV011zL1zAzEa_tV-fg=.becf4dcd-cd51-448b-8dc4-72a962f3b5b0@github.com> On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. The copyright date needs to be updated to 2025. Tests should be as readable and maintainable as the other source code. The coding styles vary a bit, having accumulated by many authors over the years. Changes should follow the existing coding style in the file, package, module, etc. The changes look good; thanks for taking on the JUnit conversion and the addition of tests. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28845#pullrequestreview-3599377100 From liach at openjdk.org Fri Dec 19 17:09:49 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 17:09:49 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: References: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> Message-ID: <5a3pBvqRX30-B4tsX7_MF5bjajuPcK2yrXB7IQi-rG0=.4251b0bd-f68a-4c48-8dab-f683864a0540@github.com> On Thu, 18 Dec 2025 07:30:36 GMT, Alan Bateman wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/DropLookupModeTest.java line 158: > >> 156: Integer.MIN_VALUE, >> 157: }) >> 158: public void testBadInput(Integer modeToDrop) { > > The ValueSource produces ints but the parameter to testBadInput is Integer. The original data provider test used Integer too so I assume this was just the conversion. Looks like this luckily works because junit boxes all ValueSource values, which don't have to be unboxed when passed here. But yes, this method should take an int instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2635736836 From liach at openjdk.org Fri Dec 19 17:09:52 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 17:09:52 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: References: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> Message-ID: On Thu, 18 Dec 2025 13:45:41 GMT, Andrey Turbanov wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/VarHandles/VarHandleTestAccessBoolean.java line 298: > >> 296: { >> 297: boolean x = (boolean) vh.get(recv); >> 298: assertEquals(true, x,"get boolean value"); > > Suggestion: > > assertEquals(true, x, "get boolean value"); This is a template bug, will fix the template and regenerate the test series. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2635746810 From liach at openjdk.org Fri Dec 19 17:17:16 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 17:17:16 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. test/jdk/java/util/Objects/BasicObjectsTest.java line 1: > 1: /* You can update the copyright year by running sh bin/update_copyright_year.sh -b 53ebcdbd029a1c78f8429574b78cecce70c11af2 (this refers to the last mainline commit on your PR branch) in the project root directory. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28845#discussion_r2635767910 From jvernee at openjdk.org Fri Dec 19 17:40:15 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 19 Dec 2025 17:40:15 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 have started looking at this patch, but it's taking a while, and I've run out of time before the holidays. I will pick this back up next year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3675949673 From jvernee at openjdk.org Fri Dec 19 17:41:27 2025 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 19 Dec 2025 17:41:27 GMT Subject: Integrated: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> References: <_k3jQN-8PG2Qs-U5YIpn0rIBCnv4tkVW-YEHXxccOkY=.faf146d2-f387-43c6-ae8d-be27ada1f49d@github.com> Message-ID: On Tue, 16 Dec 2025 18:47:34 GMT, Jorn Vernee wrote: > ASAN correctly detected a use-after-free in this test. > > The issue is that an async `ScopedAccessError` is thrown while executing java code as part of a JVMTI callback. This exception is meant to unwind out of a scoped memory access, to prevent access to memory that has already been freed. But, currently the native agent code is printing and clearing the exception, which doesn't prevent the memory access from occurring, leading to a use-after-free. > > Ideally, the agent should propagate the exception to the place in the Java code where the JVMTI event happens, but it is not possible to exit the callback with a pending exception, and AFAICT there is no JVMTI API for propagating async exceptions that are thrown during a JVMTI callback. So, the only sane thing the test can do is exit the process, which is what I've implemented here. > > This fixes the test, but it leaves the larger question of how JVMTI agents should deal with async exceptions unresolved. This pull request has now been integrated. Changeset: 821e9ff9 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/821e9ff965cad52cdd26c08785312db49bcce539 Stats: 41 lines in 2 files changed: 27 ins; 5 del; 9 mod 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28853 From naoto at openjdk.org Fri Dec 19 18:40:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 19 Dec 2025 18:40:14 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:01:07 GMT, Justin Lu wrote: > Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit. > > First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974. > https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run. > https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool. > The rest of the commits are aesthetic related. > > Before conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit > > > After conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit LGTM over all. There may be a bug in the tool, as I see duplicated comments for no apparent reason (did not check all the files) Also, please rename the directory `java/time/nontestng` to `java/time/nonjunit`. test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java line 89: > 87: static final int HIJRAH_DATE_TYPE = 6; // java.time.chrono.Ser.HIJRAH_DATE_TYPE > 88: static final int MINGUO_DATE_TYPE = 7; // java.time.chrono.Ser.MINGUO_DATE_TYPE > 89: static final int THAIBUDDHIST_DATE_TYPE = 8; // java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE// java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE The comment seems duplicated for no apparent reason. (Tool's bug?) test/jdk/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java line 76: > 74: public class TCKChronologySerialization extends AbstractTCKTest { > 75: > 76: static final int CHRONO_TYPE = 1; // java.time.chrono.Ser.CHRONO_TYPE// java.time.chrono.Ser.CHRONO_TYPE Same here test/jdk/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java line 95: > 93: public class TCKEraSerialization extends AbstractTCKTest { > 94: > 95: static final int JAPANESE_ERA_TYPE = 5; // java.time.chrono.Ser.JAPANESE_ERA// java.time.chrono.Ser.JAPANESE_ERA And here too ------------- PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3599617701 PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635940661 PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635942887 PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2635944980 From almatvee at openjdk.org Fri Dec 19 19:50:36 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 19 Dec 2025 19:50:36 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil [v2] In-Reply-To: References: Message-ID: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28912/files - new: https://git.openjdk.org/jdk/pull/28912/files/c4583ecd..cdba5272 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28912&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28912&range=00-01 Stats: 7 lines in 1 file changed: 0 ins; 6 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28912.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28912/head:pull/28912 PR: https://git.openjdk.org/jdk/pull/28912 From almatvee at openjdk.org Fri Dec 19 19:50:37 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 19 Dec 2025 19:50:37 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil [v2] - `TKit.createTempDirectory("mount-root")` will be used instead of `Files.createTempDirectory("mount-root")` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28912#issuecomment-3676314644 From jlu at openjdk.org Fri Dec 19 19:52:34 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 19 Dec 2025 19:52:34 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v2] In-Reply-To: References: Message-ID: > Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit. > > First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974. > https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run. > https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool. > The rest of the commits are aesthetic related. > > Before conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit > > > After conversion stats > > > Test results: passed: 187 > Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - nontestng -> nonjunit - Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28911/files - new: https://git.openjdk.org/jdk/pull/28911/files/d07c912c..d90d23ed Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=00-01 Stats: 3 lines in 11 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28911.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28911/head:pull/28911 PR: https://git.openjdk.org/jdk/pull/28911 From jlu at openjdk.org Fri Dec 19 19:52:36 2025 From: jlu at openjdk.org (Justin Lu) Date: Fri, 19 Dec 2025 19:52:36 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 18:33:13 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with two additional commits since the last revision: >> >> - nontestng -> nonjunit >> - Fix comments > > test/jdk/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java line 89: > >> 87: static final int HIJRAH_DATE_TYPE = 6; // java.time.chrono.Ser.HIJRAH_DATE_TYPE >> 88: static final int MINGUO_DATE_TYPE = 7; // java.time.chrono.Ser.MINGUO_DATE_TYPE >> 89: static final int THAIBUDDHIST_DATE_TYPE = 8; // java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE// java.time.chrono.Ser.THAIBUDDHIST_DATE_TYPE > > The comment seems duplicated for no apparent reason. (Tool's bug?) Thanks for spotting, it does appear to be left by the tool. I searched for other occurrences and did not find any besides the ones you mentioned. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28911#discussion_r2636118993 From rpressler at openjdk.org Fri Dec 19 19:55:10 2025 From: rpressler at openjdk.org (Ron Pressler) Date: Fri, 19 Dec 2025 19:55:10 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. If an LLM was used in this PR, please provide the model's name and version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3676330769 From rriggs at openjdk.org Fri Dec 19 19:55:10 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Dec 2025 19:55:10 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: <7pRFX_Recerq0YrUvraF1KznLuIX6yxxJqgFBMrycQ0=.78aab831-13ce-4922-8c23-1366eaec327f@github.com> On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. Was this generated by an LLM? ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28845#pullrequestreview-3599867923 From rriggs at openjdk.org Fri Dec 19 20:31:53 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Dec 2025 20:31:53 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 12:56:14 GMT, eunbin son wrote: > ## Summary > > Add explicit null check using `Objects.requireNonNull` in > `DataOutputStream.writeBytes(String s)` to provide a clearer error message > and make the API contract explicit. > > ## Problem > > The `writeBytes` method currently throws a `NullPointerException` when > `null` is passed, but the error message may not be clear in all contexts. > While JDK 14+ provides helpful NullPointerException messages through > JEP 358 (Helpful NullPointerExceptions), adding an explicit null check > using `Objects.requireNonNull` makes the API contract more explicit and > provides consistent error messaging across different JDK versions. > > ## Solution > > Added `Objects.requireNonNull(s, "s")` at the beginning of the > `writeBytes(String s)` method. This ensures: > - A clear error message ("s") is provided when null is passed > - The API contract explicitly states that null is not allowed > - The method fails fast with a descriptive exception > > ## Issue > Fixes JDK-8373660 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 > > > ## Type of Change > - [x] Test addition/modification > - [x] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > A new JUnit test has been added to verify the null check behavior: > > > # Run the specific JUnit test file > make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" > > # Or run all tests in the DataOutputStream directory > make test TEST="jtreg:test/jdk/java/io/DataOutputStream" Please close this PR. It does not add enough value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3676490828 From liach at openjdk.org Fri Dec 19 20:38:02 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 20:38:02 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 11:54:41 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address code style feedback > > - Expanded wildcard imports to individual imports > - Simplified test messages to identify tests only > - Used Assertions.fail() where appropriate > - Kept assertTrue/assertFalse for isNull API tests > > Thanks to @RogerRiggs and @liach for the feedback. I don't think we can accept this patch as-is - Even though tests would "increase coverage", this patch adds a lot of messages that are probably never printed that we cannot really validate them. In particular, this patch is verbose - a lot of the message strings and comments are simply repeating what is immediately clear from the code. Such spam of information reminds people of large language models, which tend to generate code that seems rich on the first glance but ultimately becomes problematic in the long run. For example, we wish for freedom to update exception messages in the future, while the added tests are restricting the messages our APIs can return. ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28845#pullrequestreview-3600024617 From liach at openjdk.org Fri Dec 19 20:43:53 2025 From: liach at openjdk.org (Chen Liang) Date: Fri, 19 Dec 2025 20:43:53 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: <2aB5lBUWlz1ZQBpAJgsMGulVTNcEBq6YIBET9wmNaI0=.673c8b4c-e301-4b00-b8a5-13f62a5ecb29@github.com> On Wed, 17 Dec 2025 12:56:14 GMT, eunbin son wrote: > ## Summary > > Add explicit null check using `Objects.requireNonNull` in > `DataOutputStream.writeBytes(String s)` to provide a clearer error message > and make the API contract explicit. > > ## Problem > > The `writeBytes` method currently throws a `NullPointerException` when > `null` is passed, but the error message may not be clear in all contexts. > While JDK 14+ provides helpful NullPointerException messages through > JEP 358 (Helpful NullPointerExceptions), adding an explicit null check > using `Objects.requireNonNull` makes the API contract more explicit and > provides consistent error messaging across different JDK versions. > > ## Solution > > Added `Objects.requireNonNull(s, "s")` at the beginning of the > `writeBytes(String s)` method. This ensures: > - A clear error message ("s") is provided when null is passed > - The API contract explicitly states that null is not allowed > - The method fails fast with a descriptive exception > > ## Issue > Fixes JDK-8373660 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373660 > > > ## Type of Change > - [x] Test addition/modification > - [x] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > A new JUnit test has been added to verify the null check behavior: > > > # Run the specific JUnit test file > make test TEST="jtreg:test/jdk/java/io/DataOutputStream/DataOutputStreamTest.java" > > # Or run all tests in the DataOutputStream directory > make test TEST="jtreg:test/jdk/java/io/DataOutputStream" As far as I see, this patch provides little to no value - null checks is already given by the package specification. The extra `requireNonNull` call inflates bytecode size and harms JIT compilers. The unit test added is way too narrow and restricts the NPE message freedom. Note that when the bug triage moves a submitted ticket to JDK, it does not mean the ticket is always a good idea - in particular, the "problem" section of this PR and the "motivation" section in the JBS issue are complete nonsense. ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28869#pullrequestreview-3600044234 From asemenyuk at openjdk.org Fri Dec 19 21:34:02 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 19 Dec 2025 21:34:02 GMT Subject: RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 19:50:36 GMT, Alexander Matveev wrote: >> - I was not able to reproduce this issue. >> - Based on log we calling same detach command simultaneously: >> >> [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... >> [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... >> >> - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. >> - Fixed by mounting DMG into random location. >> - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil [v2] Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28912#pullrequestreview-3600196354 From rriggs at openjdk.org Fri Dec 19 21:44:59 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 19 Dec 2025 21:44:59 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 This version isn't well encapsulated and has changes across multiple files. What was suggested at the beginning of December is prototyped in PR #28936. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3676723222 From bchristi at openjdk.org Fri Dec 19 21:52:27 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 19 Dec 2025 21:52:27 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode Message-ID: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> `RuntimeArguments.java` runs with `@requires vm.flagless`, though setting the `test.thread.factory=Virtual` system property with `-D` will still run the test. The test spawns java processes, checking for particular, exact sets of runtime options (hence, `vm.flagless`). It is not expecting to find `-Dtest.thread.factory=Virtual`. It doesn't seem important that this test be run with the virtual thread factory. The suggestion of adding this test to `ProblemList-Virtual.txt` seems reasonable. (It would be a long term resident of the problem list, which is perhaps a bit strange.) Alternative courses of action: * Teach the test itself to artificially pass in the presence of `-D` options. * Enhance the test so it knows how to expect `-D` options; offhand that doesn't seem worth it. ------------- Commit messages: - add VM/RuntimeArguments.java to ProblemList-Virtual.txt Changes: https://git.openjdk.org/jdk/pull/28935/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28935&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373718 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28935/head:pull/28935 PR: https://git.openjdk.org/jdk/pull/28935 From psandoz at openjdk.org Fri Dec 19 22:05:24 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 19 Dec 2025 22:05:24 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: <7AWYFpxh5IuDz-ILQnB1thgi5mFmfS0waEmJFfPcmM0=.ec8acf99-5311-405d-957f-526bd8d4af62@github.com> References: <7AWYFpxh5IuDz-ILQnB1thgi5mFmfS0waEmJFfPcmM0=.ec8acf99-5311-405d-957f-526bd8d4af62@github.com> Message-ID: On Fri, 19 Dec 2025 09:50:26 GMT, Eric Fang wrote: >> test/jdk/jdk/incubator/vector/templates/Kernel-Reduction-Masked-op-func.template line 12: >> >>> 10: $abstractvectortype$ av = $abstractvectortype$.fromArray(SPECIES, a, i); >>> 11: r[i] = av.reduceLanes(VectorOperators.[[TEST]], vmask); >>> 12: ra = [[TEST_OP]](ra, r[i]); >> >> It's probably ok to merge the two cases, but to be conservative assign to a local variable rather than reading from the array e.g., >> >> $type$ v = av.reduceLanes(VectorOperators.[[TEST]], vmask); >> r[i] = v; >> ra = [[TEST_OP]](ra, v); > > Hi @PaulSandoz . I've changed to using a temporary variable. > > By the way, are you worried that the `read-after-write` optimization isn't implemented in some architectures? Or for some reason does not happen. I find it best if for the hot loops we can keep the code as focused as possible. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2636420892 From bchristi at openjdk.org Fri Dec 19 22:07:37 2025 From: bchristi at openjdk.org (Brent Christian) Date: Fri, 19 Dec 2025 22:07:37 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode [v2] In-Reply-To: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> References: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> Message-ID: > `RuntimeArguments.java` runs with `@requires vm.flagless`, though setting the `test.thread.factory=Virtual` system property with `-D` will still run the test. > > The test spawns java processes, checking for particular, exact sets of runtime options (hence, `vm.flagless`). It is not expecting to find `-Dtest.thread.factory=Virtual`. > > It doesn't seem important that this test be run with the virtual thread factory. The suggestion of adding this test to `ProblemList-Virtual.txt` seems reasonable. (It would be a long term resident of the problem list, which is perhaps a bit strange.) > > Alternative courses of action: > * Teach the test itself to artificially pass in the presence of `-D` options. > * Enhance the test so it knows how to expect `-D` options; offhand that doesn't seem worth it. Brent Christian has updated the pull request incrementally with one additional commit since the last revision: Change ProblemList bugid to 8309303 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28935/files - new: https://git.openjdk.org/jdk/pull/28935/files/e14a1cec..2483e66e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28935&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28935&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28935.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28935/head:pull/28935 PR: https://git.openjdk.org/jdk/pull/28935 From psandoz at openjdk.org Fri Dec 19 22:13:59 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 19 Dec 2025 22:13:59 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v4] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 09:55:25 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 incrementally with one additional commit since the last revision: > > Refine the tests for identity values Very good, a good stepping stone to for further improvements to declare and test these constants. Just one last comment which i hope will be easy to address then I think its good for integration. test/jdk/jdk/incubator/vector/templates/Unit-Reduction-op-func.template line 25: > 23: "[[TEST]](" + x + ", [[TEST_INIT]]) != " + x); > 24: } > 25: } Just one last thing wrap the loop in a `try/catch(AssertionError e)` where the `assertEquals` in the loop do not pass in a string argument. The production of such strings within the loop slow the tests down. In the catch duplicate the `assertEquals with the string argument. ------------- PR Review: https://git.openjdk.org/jdk/pull/28692#pullrequestreview-3600300548 PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2636437477 From psandoz at openjdk.org Fri Dec 19 22:52:56 2025 From: psandoz at openjdk.org (Paul Sandoz) Date: Fri, 19 Dec 2025 22:52:56 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> Message-ID: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> On Fri, 19 Dec 2025 06:26:47 GMT, Jatin Bhateja wrote: >>> > The basic type codes are declared and shared across Java and HotSpot - it's used in `LaneType`. Can we pass a single argument that is the basic type instead of two arguments. HotSpot should know from the basic type what the carrier class and also what the operation type without it being explicitly told, since presumably it knew the inverse - the basic type from the element class. >>> >>> Hi @PaulSandoz, T_HALFFLOAT used in LaneType is mainly used for differentiation of various cache keys used by conversion operation lookups. In principle, we can extend VM to acknowledge this new custom basic type on the lines of T_METADATA / T_ADDRESS; its scope for now will be restricted to VectorSupport. We can gradually expose this to C2 type, such that TypeVect for all Float16 VectorIR uses T_HALFFLOAT as its basic type; currently, we use T_SHORT as the lane type. Let me know if this looks reasonable >> >> I am proposing something simpler, really as a temporary step until `Float16` becomes part of the `java.base` module. IIUC from the basic type we can reliably determine what the two arguments we currently passing are e.g., T_HALFFLOAT = { short.class, VECTOR_TYPE_FP16 }. So we don't need to pass two arguments, we can just pass one, the intrinsic can lookup the class and operation type kind. > > Hi @PaulSandoz , your comments have been addressed. Please let us know if there are other comments. > Hi @eme64 , Kindly share your comments. > @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) Same here! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3676923873 From msheppar at openjdk.org Fri Dec 19 23:12:51 2025 From: msheppar at openjdk.org (Mark Sheppard) Date: Fri, 19 Dec 2025 23:12:51 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 07:41:09 GMT, Jaikiran Pai wrote: > Can I please get a review of this test-only change which addresses intermittent failures in `java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java`? > > The `@summary` in that test's test definition about what this test does: > >> @summary When the "java.rmi.dgc.leaseValue" system property is set to a >> value much lower than its default (10 minutes), then the server-side >> user-visible detection of DGC lease expiration-- in the form of >> Unreferenced.unreferenced() invocations and possibly even local garbage >> collection (including weak reference notification, finalization, etc.)-- >> may be delayed longer than expected. While this is not a spec violation >> (because there are no timeliness guarantees for any of these garbage >> collection-related events), the user might expect that an unreferenced() >> invocation for an object whose last client has terminated abnormally >> should occur on relatively the same time order as the lease value >> granted. > > In its current form, the test uses a lease expiry of 10 seconds, launches a trivial `java` application which looks up the bound object from the registry and then terminates itself. After launching that trivial java application, the test then waits for 20 seconds, expecting that the `Unreferenced.unreferenced()` callback (upon lease expiry of 10 seconds) will be called within those 20 seconds. This wait intermittently fails because the `Unreferenced.unreferenced()` doesn't get called within those 20 seconds. > > Experiments show that the reason for these intermittent failures is due to the `SelfTerminator` application which does the registry lookup (and which involves connection establishment and communication over a socket) can sometimes take several seconds (5 or more for example). That effectively means that by the time this `SelfTerminator` starts its termination after the lookup, it's already several seconds into the "wait()" in the test. > > The commit in this PR cleans up the test to more accurately track the duration of how long it took between the lease expiry and the `Unreferenced.unreferenced()` callback to be invoked. Additionally, just to make the test more robust, the maximum expected duration has been increased to 60 seconds instead of 20 seconds. Given the text in the test's summary, I think this increase is still within the expectations of how long it takes for the callback to be invoked after the client has exited abnormally. > > The test continues to pass with this change and a te... replacing the obj.lock.wait(TIMEOUT); with the do while loop is a good change as the Object.wait is susceptible to intermittent early return. jtreg takes care of a test timeout. BUT I think it possible to simply the main test logic a bit. The Object wait/notify could be replaced by a CountDownLatch. The remote unreferenced method counts down the latch and the main test thread awaits the count down of the latch (in place of the do while). Thus removing the synchronize logic. This eliminates the necessity for the assert assert and for a state variable unreferenced. lines 121 - 136 are a refactor extract method isWithinTimeLimits one could debate if the temporal checks are necessary, as they cannot be guaranteed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3676932915 From almatvee at openjdk.org Fri Dec 19 23:22:08 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 19 Dec 2025 23:22:08 GMT Subject: Integrated: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 23:05:35 GMT, Alexander Matveev wrote: > - I was not able to reproduce this issue. > - Based on log we calling same detach command simultaneously: > > [08:49:10.288] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > [08:49:10.274] TRACE: exec: Execute [/usr/bin/hdiutil detach -force -verbose /Volumes/Foo](5); discard out+err... > > - I think `hdiutil` does not handle attaching/detaching DMG with same name asynchronously multiple times well enough. > - Fixed by mounting DMG into random location. > - Added `-nobrowse`, so DMG will not be added to Finder. We do not need DMG to be shown in Finder when attached during test. This pull request has now been integrated. Changeset: 2d092840 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/2d0928406027a848cf2d2d0574024970b8fb535c Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/28912 From naoto at openjdk.org Sat Dec 20 00:27:58 2025 From: naoto at openjdk.org (Naoto Sato) Date: Sat, 20 Dec 2025 00:27:58 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v2] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 19:52:34 GMT, Justin Lu wrote: >> Please review this PR which migrates the java.time tests from TestNG to JUnit. The java.time tests use TestNG based on the directory level settings configured by TEST.properties, so they are best migrated altogether. This is a large PR, so I have tried to make the changes clear by commit. >> >> First, the auto conversion tool is run in https://github.com/openjdk/jdk/commit/b1fd7dbdec85aac5a44cc875e57a36be8f1b6974. >> https://github.com/openjdk/jdk/commit/3805cfd8765c0c76b61893dcf1670951402f98c3 and https://github.com/openjdk/jdk/commit/b697ca5d9a8067bcecea2dfb32f92f7699085dee are required so that the tests can actually compile and run. >> https://github.com/openjdk/jdk/commit/d07c912c4c16d2b3307e489563f148f71cfdf4a4 addresses the timeout annotation which was not covered by the auto conversion tool. >> The rest of the commits are aesthetic related. >> >> Before conversion stats >> >> >> Test results: passed: 187 >> Framework-based tests: 32,339 = 32,339 TestNG + 0 JUnit >> >> >> After conversion stats >> >> >> Test results: passed: 187 >> Framework-based tests: 32,339 = 0 TestNG + 32,339 JUnit > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - nontestng -> nonjunit > - Fix comments Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3600504359 From duke at openjdk.org Sat Dec 20 04:50:51 2025 From: duke at openjdk.org (eunbin son) Date: Sat, 20 Dec 2025 04:50:51 GMT Subject: RFR: 8373660: Add explicit null check in DataOutputStream.writeBytes In-Reply-To: References: Message-ID: <4PLDpFCVh1EXn8EZKgtQ00MoquaJl4yolU3m6ZApzME=.92637736-b5ba-4a81-bb56-acfcae047b05@github.com> On Thu, 18 Dec 2025 12:41:16 GMT, Alan Bateman wrote: >> @AlanBateman Thank you for the feedback! >> >> ## Analysis: >> >> **JEP 358 message advantages:** >> - More detailed: Shows which method call failed ("String.length()") >> - More informative: Explains the context of the failure >> >> **Objects.requireNonNull advantages:** >> - Explicit API contract: Makes it clear at method entry that null is not allowed >> - Fail-fast: Exception occurs at method entry, not deep in the method body >> - Consistent across JDK versions: Works the same way in JDK 8, 11, 14, 17, etc. >> - Simpler message: Just the parameter name >> >> I understand that with JEP 358, there's less need for explicit null checks in many cases. However, I believe `Objects.requireNonNull` still provides value by: >> 1. Making the API contract explicit at the method signature level >> 2. Failing fast before any method body execution >> 3. Providing consistent behavior across all JDK versions >> >> I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? > >> I'm open to feedback on whether this change is appropriate, or if we should rely on JEP 358's automatic messages instead. What would you recommend? > > Would you mind pasting in the existing NPE message and the new NPE message? Thank you very much for the review. Every line of your feedback is very valuable to me, @AlanBateman @liach @RogerRiggs and I've learned a lot from this experience. Please close the PR. I'm happy to follow your guidance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3677378492 From swen at openjdk.org Sat Dec 20 05:26:50 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 20 Dec 2025 05:26:50 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 21:42:14 GMT, Roger Riggs wrote: > This version isn't well encapsulated and has changes across multiple files. What was suggested at the beginning of December is prototyped in PR #28936. 1. Using exceptions for logic control seems like a bad practice. 2. A DateTimeFormatter is reused multiple times. Our approach of calculating `onlyChronoField` only runs once during construction. However, using a runtime approach with `try-catch ClassCastException` executes the corresponding code every time `parse` is called. This is a choice between executing once and executing multiple times. 3. In the `DateTimeFormatter::checkField` method, we could later add an `int chronoFieldBitSet` field to record which ChronoFields are used. This could further optimize other methods of `Parsed`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3677403633 From duke at openjdk.org Sat Dec 20 06:01:49 2025 From: duke at openjdk.org (eunbin son) Date: Sat, 20 Dec 2025 06:01:49 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v6] In-Reply-To: References: Message-ID: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son has updated the pull request incrementally with two additional commits since the last revision: - 8373661: Address liach's feedback on test verbosity - Removed exception message tests to allow API flexibility - Removed verbose Javadoc and inline comments - Simplified test messages to use method names only - Updated copyright year Thanks to @liach for the feedback. - Update full name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/11d7aae7..a81933ef Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=04-05 Stats: 55 lines in 1 file changed: 0 ins; 39 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From duke at openjdk.org Sat Dec 20 06:13:06 2025 From: duke at openjdk.org (eunbin son) Date: Sat, 20 Dec 2025 06:13:06 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 19:50:22 GMT, Ron Pressler wrote: >> eunbin son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373661: Address code style feedback >> >> - Expanded wildcard imports to individual imports >> - Simplified test messages to identify tests only >> - Used Assertions.fail() where appropriate >> - Kept assertTrue/assertFalse for isNull API tests >> >> Thanks to @RogerRiggs and @liach for the feedback. > > If an LLM was used in this PR, please provide the model's name and version. Thanks to @pron for your interest. To answer your question about LLM usage: This PR was created with assistance from an AI coding assistant (Auto agent router by Cursor: Composer1, Opus4.5, Sonnet 4.5, GPT 5.1, Gemini 3, Grok Code ) for initial code generation, but all changes have been reviewed and refined based on maintainer feedback. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3677448047 From duke at openjdk.org Sat Dec 20 06:13:04 2025 From: duke at openjdk.org (eunbin son) Date: Sat, 20 Dec 2025 06:13:04 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v4] In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 22:43:44 GMT, Chen Liang wrote: >> eunbin son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373661: Use assertSame for exception instance verification >> >> Updated testRequireNonNullWithSupplierThrowingException to allocate >> the exception outside of the lambda and use assertSame to verify >> the same exception instance is thrown, as suggested by @liach. >> >> This provides a more precise verification that the exception from >> the supplier is thrown directly, not wrapped. >> >> Thanks to @liach for the feedback. > > I agree with Roger's points about simplifying some test messages. Sometimes we don't even write test messages if the subject is clear from the test code context, because the exceptions usually include the line numbers already. However, these are not critical. > > However, I think Roger might be too strict on imports and Assertions.fail vs exceptions - these are acceptable because they don't affect the test quality, so I am not concerned. Thank you for the feedback, @liach and @RogerRiggs! I've addressed your concerns: - [x] Updated description contents and formatting , copyright year (as requested by @RogerRiggs) - [x] Removed exception message tests to allow API flexibility (as suggested by @liach) - [x] Removed verbose Javadoc and inline comments (as suggested by @liach) - [x] Simplified test messages to use method names only The tests now follow OpenJDK patterns where only exception types are tested, not messages. The code is more concise and maintainable. The changes have been pushed. Please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3677444777 From liach at openjdk.org Sat Dec 20 06:38:52 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Dec 2025 06:38:52 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: References: Message-ID: On Sat, 20 Dec 2025 06:08:11 GMT, eunbin son wrote: > but all changes have been reviewed and refined based on maintainer feedback OpenJDK reviewers are not obligated to babysit a contribution back and forth for multiple iterations to get the patch right, regardless if it is from a bot or a human. For example, I asked to run a command to fix the copyright year and to remove redundant message, both of which are done incorrectly. We simply cannot afford extra review cycles in this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3677473559 From alanb at openjdk.org Sat Dec 20 07:22:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 20 Dec 2025 07:22:51 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode [v2] In-Reply-To: References: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> Message-ID: On Fri, 19 Dec 2025 22:07:37 GMT, Brent Christian wrote: >> `RuntimeArguments.java` runs with `@requires vm.flagless`, though setting the `test.thread.factory=Virtual` system property with `-D` will still run the test. >> >> The test spawns java processes, checking for particular, exact sets of runtime options (hence, `vm.flagless`). It is not expecting to find `-Dtest.thread.factory=Virtual`. >> >> It doesn't seem important that this test be run with the virtual thread factory. The suggestion of adding this test to `ProblemList-Virtual.txt` seems reasonable. (It would be a long term resident of the problem list, which is perhaps a bit strange.) >> >> Alternative courses of action: >> * Teach the test itself to artificially pass in the presence of `-D` options. >> * Enhance the test so it knows how to expect `-D` options; offhand that doesn't seem worth it. >> >> Update: >> The bots don't like having the "current" bugid present in the problem list. I have updated the bugid in the PL to 8309303 (when the `VM_OPTIONS` constant was added to the test) - a bit disingenuous. If we're not happy with this, I guess a new issue could be filed ("RuntimeArguments.java doesn't account for -D system properties") to use in the problem list. > > Brent Christian has updated the pull request incrementally with one additional commit since the last revision: > > Change ProblemList bugid to 8309303 > It doesn't seem important that this test be run with the virtual thread factory. In that case, can you add `@requires test.thread.factory == null` to the test description. That would avoid having it permanently excluded via ProblemList-Virtual.txt when doing JTREG_TEST_THREAD_FACTORY=Virtual test runs. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28935#issuecomment-3677514928 From duke at openjdk.org Sat Dec 20 07:33:01 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 20 Dec 2025 07:33:01 GMT Subject: RFR: 8373288: EnumMap spliterators should include more specific characteristics In-Reply-To: References: Message-ID: On Tue, 16 Dec 2025 04:42:53 GMT, Patrick Strawderman wrote: > The spliterators returned by keySet, entrySet, and values were not reporting additional characteristics, such as ORDERED, SORTED, and NONNULL; the EnumMap iterators all guarantee iteration is in the natural order of the enum key, and nulls are disallowed as keys. > > Null values are allowed, so the values collection can only additionally report ORDERED. Note?that unlike?`EnumSet`, `EnumMap` can?be?subclassed by?arbitrary user?code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28840#issuecomment-3677520831 From duke at openjdk.org Sat Dec 20 07:57:03 2025 From: duke at openjdk.org (khanbilal732) Date: Sat, 20 Dec 2025 07:57:03 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: <1AAarrfD-phPgtlAouQqYJmVWtZ8RiilagnF3OH0P_w=.712748cd-4fb4-45b6-99b6-0efedd637756@github.com> 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 Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3600847064 PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3600847321 From duke at openjdk.org Sat Dec 20 08:23:25 2025 From: duke at openjdk.org (eunbin son) Date: Sat, 20 Dec 2025 08:23:25 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v7] In-Reply-To: References: Message-ID: > ## Summary > Adds comprehensive edge case tests for `Objects.requireNonNull`, > `requireNonNullElse`, and `requireNonNullElseGet` methods to improve > test coverage. > > ## Problem > The current test suite for `Objects.requireNonNull` methods covers > basic cases but lacks edge case coverage. > > ## Solution > This PR adds tests for the following edge cases: > - requireNonNull with null Supplier parameter > - requireNonNull with Supplier that throws exception > - requireNonNullElse with both arguments null > - requireNonNullElseGet with null supplier > - requireNonNullElseGet with supplier returning null > > ## Issue > Fixes JDK-8373661 > > **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 > > ## Type of Change > - [x] Test addition/modification > - [ ] Bug fix > - [ ] New feature > - [ ] Documentation improvement > - [ ] Refactoring > > ## Testing > > make test TEST="jtreg:test/jdk/java/util/Objects" eunbin son has updated the pull request incrementally with one additional commit since the last revision: 8373661: Address liach's feedback on copyright year and redundant messages I apologize for the earlier incorrect implementation. As @liach noted, "I asked to run a command to fix the copyright year and to remove redundant message, both of which are done incorrectly." I have now properly addressed both concerns: - Copyright year: Updated to 2025 (the copyright year was already set in the previous commit, but I should have used the update_copyright_year.sh script as requested) - Redundant messages: Removed all exception message tests, verbose inline comments, and simplified all test messages to use only test method names Thanks to @liach for the detailed feedback. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28845/files - new: https://git.openjdk.org/jdk/pull/28845/files/a81933ef..379d08d4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28845&range=05-06 Stats: 47 lines in 1 file changed: 0 ins; 20 del; 27 mod Patch: https://git.openjdk.org/jdk/pull/28845.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28845/head:pull/28845 PR: https://git.openjdk.org/jdk/pull/28845 From swen at openjdk.org Sat Dec 20 12:44:22 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 20 Dec 2025 12:44:22 GMT Subject: RFR: 8371431: Warning message when turning off CompactStrings [v2] In-Reply-To: References: Message-ID: > A warning message should be given before removing the CompactStrings off option. Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits: - Merge branch 'master' into compact_str_warn_2510 - Merge branch 'master' into compact_str_warn_2510 - from @liach - add warnings ------------- Changes: https://git.openjdk.org/jdk/pull/27995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27995&range=01 Stats: 12 lines in 2 files changed: 0 ins; 9 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/27995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27995/head:pull/27995 PR: https://git.openjdk.org/jdk/pull/27995 From liach at openjdk.org Sat Dec 20 15:46:56 2025 From: liach at openjdk.org (Chen Liang) Date: Sat, 20 Dec 2025 15:46:56 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: <8SYcvuKQETAkpwcYiH8rhjuqx1QxN5BIfmHdiNeURw4=.7664b61d-c6a7-4d4b-9cf0-83a2ad7ecf88@github.com> 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 I just noted that custom TemporalField implementations must be able to put any TemporalField they like into this map: https://github.com/openjdk/jdk/blob/2d0928406027a848cf2d2d0574024970b8fb535c/src/java.base/share/classes/java/time/temporal/TemporalField.java#L364-L379 Roger's model will fail if a non-TemporalField puts into this map. This PR's model is safe because all `TemporalField` here will be `ChronoField` which won't try to do dangerous stuff to the map. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3677909248 From duke at openjdk.org Sat Dec 20 17:34:56 2025 From: duke at openjdk.org (ExE Boss) Date: Sat, 20 Dec 2025 17:34:56 GMT Subject: RFR: 8371795: Improve documentation of Class.isInstance [v5] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 16:04:10 GMT, Chen Liang wrote: >> 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: > > Stage src/java.base/share/classes/java/lang/Class.java line 758: > 756: * @param obj the reference to check, an object or {@code null} > 757: * @return true the reference type represented by this {@code Class} is > 758: * a supertype of the class of {@code obj}; false otherwise Missing??if?: Suggestion: * @return true if the reference type represented by this {@code Class} * is a supertype of the class of {@code obj}; false otherwise ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28684#discussion_r2637236468 From rriggs at openjdk.org Sat Dec 20 21:33:02 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Sat, 20 Dec 2025 21:33:02 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 This PR has been through too many incremental changes. I suspect a better solution is to implement a fit-for-purpose Map, optimized for ChronoFields but taking into account the possibility of unknown TemporalFields. All within the implementation of a Map. I'd like to see this PR closed and take a fresh look with all that is learned by the attempt. ------------- Changes requested by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3601320108 From swen at openjdk.org Sun Dec 21 03:11:58 2025 From: swen at openjdk.org (Shaojin Wen) Date: Sun, 21 Dec 2025 03:11:58 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: <02zE8rOqmMB8MdI-lumotct6Jac2d4x5c_JFQrJWvLQ=.cbedc414-08b4-41db-a22f-653954aa164e@github.com> On Sat, 20 Dec 2025 21:30:32 GMT, Roger Riggs wrote: > This PR has been through too many incremental changes. I suspect a better solution is to implement a fit-for-purpose Map, optimized for ChronoFields but taking into account the possibility of unknown TemporalFields. All within the implementation of a Map. I'd like to see this PR closed and take a fresh look with all that is learned by the attempt. I believe that tasks that can be performed during the build process should not be done during the parse process. The process of building a DateTimeBuilder is executed once, while the parsing process is executed N times. For example, a pattern like `yyyy-MM-dd HH:mm:ss.SSS` requires calling the `put` method of the Map 7 times during the parsing process. Therefore, I think we should check whether chronoFieldOnly is used in DateTimeFormatterBuilder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3678397639 From john_platts at hotmail.com Sun Dec 21 05:12:28 2025 From: john_platts at hotmail.com (John Platts) Date: Sun, 21 Dec 2025 05:12:28 +0000 Subject: Improving performance of the default implementation of java.lang.Math.fma Message-ID: There is a much better way to implement java.lang.Math.fma(double, double, double) than the current default implementation in src/java.base/share/classes/java/lang/Math.java. Here is a much better implementation of java.lang.Math.fma (and this has been shown to be much faster than (new BigDecimal(a)).multiply(new BigDecimal(b)).add(new BigDecimal(c)).doubleValue() if a, b, and c are all finite floating-point values through benchmarking): private static double scalbFiniteF64Sum(double hi, double lo, int exp) { // Both hi and lo should be finite, and |hi| >= |lo| should be true if // hi != 0.0 final double sum0 = hi + lo; final double scaleResult0 = Math.scalb(sum0, exp); if (!(Math.abs(scaleResult0) <= Double.MIN_NORMAL) || lo == 0.0) { // If |scaleResult0| > Double.MIN_NORMAL or lo == 0.0, then // scaleResult0 will be correctly rounded. // Return scaleResult0 in this case. return scaleResult0; } // scaleResult1 is equal to scaleResult0 with its ULP bit cleared. // This ensures that the final result will be correctly rounded if // the ULP bit of scaleResult0 is set. final double scaleResult1 = Double.longBitsToDouble( Double.doubleToRawLongBits(scaleResult0) & (-2L)); // scaleErr is equal to the error of scaling sum0 by 2**exp, scaled back // up by 2**-exp. scaleResult1 is used to compute scaleErr to ensure // that the value of the ULP bit of scaleResult0, scaled up by 2**-exp, // is included in scaleErr to ensure that the final result is correctly // rounded. final double scaleErr = sum0 - Math.scalb(scaleResult1, -exp); // err0 is equal to the error of hi + lo final double err0 = (hi - sum0) + lo; // Compute scaleErr + err0 using the Fast2Sum algorithm as // |scaleErr| >= |err0| should be true if |scaleErr| > 0 final double sum1 = scaleErr + err0; final double err1 = (scaleErr - sum1) + err0; final long sum1Bits = Double.doubleToRawLongBits(sum1); final long err1Bits = Double.doubleToRawLongBits(err1); final long sum1IsInexactInSignBit = err1Bits ^ (err1Bits + 0x7FFF_FFFF_FFFF_FFFFL); // roundedToOddSum1 is equal to the rounded to odd sum of scaleErr and // err0 final double roundedToOddSum1 = Double.longBitsToDouble((sum1Bits + (((sum1Bits ^ err1Bits) & sum1IsInexactInSignBit) >> 63)) | (sum1IsInexactInSignBit >>> 63)); // scaleResult2 is equal to the correctly rounded value of // (hi + lo) * 2**exp final double scaleResult2 = scaleResult1 + Math.scalb(roundedToOddSum1, exp); return scaleResult2; } public static double fma(double a, double b, double c) { final long aBits = Double.doubleToRawLongBits(a); final long bBits = Double.doubleToRawLongBits(b); final long cBits = Double.doubleToRawLongBits(c); final int aBiasedExp = (int) (aBits >>> 52) & 0x7FF; final int bBiasedExp = (int) (bBits >>> 52) & 0x7FF; final int cBiasedExp = (int) (cBits >>> 52) & 0x7FF; if (((aBits ^ (aBits - 1)) | (bBits ^ (bBits - 1)) | (cBits ^ (cBits - 1)) | (0x7FE - aBiasedExp) | (0x7FE - bBiasedExp)) < 0) { // If at least one of a, b, or c are zero or at least one of a or b // is non-finite, the result will be equal to a * b + c. return a * b + c; } else if (cBiasedExp == 0x7FF) { // If a and b are both nonzero finite numbers and c is a non-finite // value, simply return c since the exact result of a * b + c will // be equal to c in this case. return c; } // a, b, and c are all nonzero finite values at this point // Normalize a and b to normal floating-point numbers final int aIsDenormalMask = (aBiasedExp - 1) >> 31; final int bIsDenormalMask = (bBiasedExp - 1) >> 31; final long aNormalizeAdjBits = (aBits & 0x8000_0000_0000_0000L) | (aIsDenormalMask & 0x0350_0000_0000_0000L); final long bNormalizeAdjBits = (bBits & 0x8000_0000_0000_0000L) | (bIsDenormalMask & 0x0350_0000_0000_0000L); final double normalizedA = Double.longBitsToDouble(aBits | aNormalizeAdjBits) - Double.longBitsToDouble(aNormalizeAdjBits); final double normalizedB = Double.longBitsToDouble(bBits | bNormalizeAdjBits) - Double.longBitsToDouble(bNormalizeAdjBits); // If a is a denormal number, normalizedA is equal to a * 2**52. // Otherwise, if a is already a normal number, normalizedA is equal to // a. // If b is a denormal number, normalizedB is equal to b * 2**52. // Otherwise, if b is already a normal number, normalizedB is equal to // b. final long normalizedABits = Double.doubleToRawLongBits(normalizedA); final long normalizedBBits = Double.doubleToRawLongBits(normalizedB); final int normalizedABiasedExp = (int) (normalizedABits >>> 52) & 0x7FF; final int normalizedBBiasedExp = (int) (normalizedBBits >>> 52) & 0x7FF; // minPBiasedExp is the smallest possible biased exponent (with an // exponent bias of 1023) of the exact value of a * b. final int minPBiasedExp = normalizedABiasedExp + normalizedBBiasedExp + (aIsDenormalMask & -52) + (bIsDenormalMask & -52) + -1023; if (minPBiasedExp >= 2048) { // If minPBiasedExp >= 2048, then a * b + c is known to overflow to // infinity. Return a * b + c in this case. return a * b + c; } // Normalize c to a normal floating-point number final int cIsDenormalMask = (cBiasedExp - 1) >> 31; final long cNormalizeAdjBits = (cBits & 0x8000_0000_0000_0000L) | (cIsDenormalMask & 0x0350_0000_0000_0000L); final double normalizedC = Double.longBitsToDouble(cBits | cNormalizeAdjBits) - Double.longBitsToDouble(cNormalizeAdjBits); // If c is a denormal number, normalizedC is equal to c * 2**52. // Otherwise, if c is already a normal number, normalizedC is equal to // c. final long normalizedCBits = Double.doubleToRawLongBits(normalizedC); final int normalizedCBiasedExp = (int) (normalizedCBits >>> 52) & 0x7FF; final int adjCBiasedExp = normalizedCBiasedExp + (cIsDenormalMask & -52); // adjCBiasedExp is equal to floor(log2(|c|)) + 1023, even if c is a // denormal number final int expDiff = adjCBiasedExp - minPBiasedExp; if (expDiff >= 55) { // If expDiff is greater than or equal to 55, the exact value of // |a * b| is less than 0.5 * ulp(c). The correctly rounded result // of a * b + c is known to be equal to c in this case. Return c in // this case as the exact value of |a * b| is too small to affect // the correctly rounded result of a * b + c. return c; } // aMant is equal to the mantissa of a, with 1 <= |a| < 2 // bMant is equal to the mantissa of b, with 1 <= |b| < 2 final double aMant = Double.longBitsToDouble(((normalizedABits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL)); final double bMant = Double.longBitsToDouble(((normalizedBBits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL)); // Split aMant and bMant using Veltkamp-Dekker splitting final double aMantGamma = aMant * 134217729.0; final double bMantGamma = bMant * 134217729.0; final double aMantHi = aMantGamma + (aMant - aMantGamma); final double bMantHi = bMantGamma + (bMant - bMantGamma); final double aMantLo = aMant - aMantHi; final double bMantLo = bMant - bMantHi; final double pHi = aMant * bMant; final double pLo = ((aMantHi * bMantHi - pHi) + (aMantHi * bMantLo + aMantLo * bMantHi)) + aMantLo * bMantLo; if (minPBiasedExp >= 1 && pLo == 0.0) { // If minPBiasedExp >= 1 and pLo == 0.0 are both true, then a * b is // known to be exact and normal. Return a * b + c in this case. return a * b + c; } final int resultScaleUpExp = minPBiasedExp - 1023; if (expDiff <= -106) { // If expDiff <= -106 is true, then |a * b| >= 2**-968 must be true // since 2**-1074 <= |c| < 2**-105 * |a * b|. if (pLo == 0.0) { // If expDiff <= -106 and pLo == 0.0 are both true, then |c| // is too small to affect the correctly rounded result. // Return a * b in this case since a * b is known to be either // an exact normal finite number or infinity and as |c| is too // small to affect the result of a * b + c. return a * b; } else { // If expDiff <= -106 and pLo != 0.0 are both true, then // 0 < |c * 2**-resultScaleUpExp| < 0.5 * ulp(pLo) is known // to be true. // In this case, the rounded to odd sum of pLo and // c * 2**-resultScaleUpExp can be computed by decrementing // pLoBits by 1 if pLoBits and cBits have different signs // rounded to odd sum of pLo and c * 2**-resultScaleUpExp // can be computed by simply decrementing pLoBits by 1 if pLo // and c have different signs followed by setting the LSB bit as // in this case. final long pLoBits = Double.doubleToRawLongBits(pLo); // roundedToOddLoSum is equal to the rounded to odd sum of // pLo and c * 2**-resultScaleUpExp final double roundedToOddLoSum = Double.longBitsToDouble( (pLoBits + ((pLoBits ^ cBits) >> 63)) | 1L); // Return the correctly rounded value of // (s1 + roundedToOddLoSum) * 2**resultScaleUpExp return scalbFiniteF64Sum(pHi, roundedToOddLoSum, resultScaleUpExp); } } // -105 <= expDiff <= 54 is now true at this point final double scaledC = Double.longBitsToDouble(((normalizedCBits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL) + ((long) expDiff << 52)); // Compute pLo + scaledC using the 2Sum algorithm final double s0 = pLo + scaledC; final double v0 = s0 - pLo; final double e0 = (pLo - (s0 - v0)) + (scaledC - v0); // s0 + e0 == pLo + scaledC // Compute pHi + s0 using the 2Sum algorithm final double s1 = pHi + s0; final double v1 = s1 - pHi; final double e1 = (pHi - (s1 - v1)) + (s0 - v1); // s1 + e1 + e0 == pHi + pLo + scaledC // Compute the rounded to odd sum of e1 and e0 to ensure that the final // result is correctly rounded. // Fast2Sum is sufficient for computing e1 + e0 as either |e1| == 0.0 or // |e1| >= |e0| should be true final double s2 = e1 + e0; final double e2 = (e1 - s2) + e0; // s1 + s2 + e2 == pHi + pLo + scaledC final long s2Bits = Double.doubleToRawLongBits(s2); final long e2Bits = Double.doubleToRawLongBits(e2); final long s2IsInexactInSignBit = e2Bits ^ (e2Bits + 0x7FFF_FFFF_FFFF_FFFFL); // roundedToOddS2 is equal to the rounded to odd sum of e1 and e0 and // is used to ensure that the final result is correctly rounded final double roundedToOddS2 = Double.longBitsToDouble( (s2Bits + (((s2Bits ^ e2Bits) & s2IsInexactInSignBit) >> 63)) | (s2IsInexactInSignBit >>> 63)); // Return the correctly rounded value of // (s1 + roundedToOddS2) * 2**resultScaleUpExp return scalbFiniteF64Sum(s1, roundedToOddS2, resultScaleUpExp); } There are a few tricks up the sleeve with the above implementation. If xBits is the result of Double.doubleToRawLongBits(x): xBits ^ (xBits - 1) is equal to -1 if and only if x == 0 or x == -0 and is non-negative otherwise xBits ^ (xBits + 0x7FFF_FFFF_FFFF_FFFFL) is negative if and only if x != 0 and equal to Long.MAX_VALUE if x == 0 The rounded to odd result of a + b is used in a few places in the above implementation of fma to ensure that the final sum is correctly rounded. From nbenalla at openjdk.org Sun Dec 21 14:53:48 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Sun, 21 Dec 2025 14:53:48 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 Message-ID: The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. ------------- Depends on: https://git.openjdk.org/jdk/pull/28944 Commit messages: - remove JavaBaseCheckSince from ProblemList Changes: https://git.openjdk.org/jdk/pull/28945/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372801 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28945/head:pull/28945 PR: https://git.openjdk.org/jdk/pull/28945 From aturbanov at openjdk.org Sun Dec 21 20:35:05 2025 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Sun, 21 Dec 2025 20:35:05 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v2] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Thu, 18 Dec 2025 16:46:26 GMT, Roger Riggs wrote: >> Refactor serialization tests to use JUnit. >> Automated conversion for most annotations. >> Conditional tests are refactored to use JUnit Enable/DisableIf. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Cleanup arglist and fix code style test/jdk/java/io/Serializable/serialFilter/GlobalFilterTest.java line 161: > 159: @EnabledIf("hasGlobalFilter") > 160: @MethodSource("globalPatternElements") > 161: void globalFilterElements(String pattern, boolean allowed,Object obj) { Suggestion: void globalFilterElements(String pattern, boolean allowed, Object obj) { test/jdk/java/io/Serializable/serialFilter/SerialFactoryFaults.java line 80: > 78: > 79: if (factoryName.equals("ForcedError_NoSuchClass")) { > 80: Assertions.assertEquals( "invalid jdk.serialFilterFactory: ForcedError_NoSuchClass: java.lang.ClassNotFoundException: ForcedError_NoSuchClass", msg, "wrong exception"); too many spaces test/jdk/java/io/Serializable/serialFilter/SerialFilterFunctionTest.java line 108: > 106: Assertions.assertThrows(NullPointerException.class, () -> ObjectInputFilter.allowFilter(predicate, expected)); > 107: } else { > 108: Assertions.assertEquals( expected, ObjectInputFilter.allowFilter(predicate, otherStatus).checkInput(info), "Predicate result"); too man spaces ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2638091288 PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2638091168 PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2638091414 From duke at openjdk.org Sun Dec 21 22:35:54 2025 From: duke at openjdk.org (eunbin son) Date: Sun, 21 Dec 2025 22:35:54 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v5] In-Reply-To: <5l25k-v0rc0U-lYSzjK7bCi8falsChSQRkWHPUBVFao=.a4bcc9fb-1a93-44c8-b175-9a6735810cbe@github.com> References: <5l25k-v0rc0U-lYSzjK7bCi8falsChSQRkWHPUBVFao=.a4bcc9fb-1a93-44c8-b175-9a6735810cbe@github.com> Message-ID: <-SXJ2B-BB_YGg1KDfEjicq2s7IpdMFygP4A3sNWDtng=.6b633f32-1519-4705-810b-911052686c1a@github.com> On Fri, 19 Dec 2025 16:58:33 GMT, Roger Riggs wrote: >> eunbin son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373661: Address code style feedback >> >> - Expanded wildcard imports to individual imports >> - Simplified test messages to identify tests only >> - Used Assertions.fail() where appropriate >> - Kept assertTrue/assertFalse for isNull API tests >> >> Thanks to @RogerRiggs and @liach for the feedback. > > Comment on the description contents and formatting: > Skara (the automation for OpenJDK PRs) adds its own content (using Markdown) at the end to document the progress and steps. > The final bit of `preformatted` text in the description does not seem to be closed properly so the Skara comment shows up as raw Markdown. Thank you for your feedback, @RogerRiggs and @liach. I?ve reviewed all comments again and addressed each item as listed below: ? ? JUnit conversion (@RogerRiggs): Converted to JUnit format with @Test annotations and the @run junit directive; removed the main() method. ? ? Wildcard imports (@RogerRiggs): Replaced wildcard imports with explicit individual imports. ? ? Test message simplification (@RogerRiggs): All test messages now use method names only. ? ? Exception message tests removal (@liach): Removed all exception message assertions; tests now verify only the exception types using assertThrows. ? ? Copyright year update (@RogerRiggs): Updated the copyright header to include 2025. ? ? Verbose comments removal (@liach): Removed unnecessary Javadoc and inline comments from the newly added test methods. ? ? Exception instance verification (@liach): Updated testRequireNonNullWithSupplierThrowingException to allocate the exception outside the lambda and use assertSame to verify that the same instance is thrown. All changes are included in the latest commit(s). If I missed anything, please let me know and I?ll be happy to address it. Please review when you have a chance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3679628190 From john_platts at hotmail.com Sun Dec 21 22:42:16 2025 From: john_platts at hotmail.com (John Platts) Date: Sun, 21 Dec 2025 22:42:16 +0000 Subject: Improving performance of the default implementation of Math.fma for float Message-ID: Here is a much better default implementation for java.lang.Math.fma(float, float, float): public static float fma(float a, float b, float c) { // product is equal to the exact value of a * b final double product = (double)a * (double)b; final double cAsDouble = (double)c; double sum = product + cAsDouble; if (Double.isFinite(sum)) { // If sum is finite, round sum to odd to ensure that the conversion of // sum to single-precision floating point is correctly rounded. final double v = sum - product; final double err = (product - (sum - v)) + (cAsDouble - v); final long sumBits = Double.doubleToRawLongBits(sum); final long errBits = Double.doubleToRawLongBits(err); final long sumIsInexactInSignBit = errBits ^ (errBits + 0x7FFF_FFFF_FFFF_FFFFL); sum = Double.longBitsToDouble( (sumBits + (((sumBits ^ errBits) & sumIsInexactInSignBit) >> 63)) | (sumIsInexactInSignBit >>> 63)); // sum is now equal to the rounded to odd double-precision floating // point result of a * b + c } // Return the result of converting sum (which will be rounded to odd if // finite) to single-precision floating point return (float)sum; } The above implementation of Math.fma(float, float, float) is much more efficient than the current implementation of java.lang.Math.fma(float, float, float) in src/java.base/share/classes/java/lang/Math.java as it avoids the overhead of using BigDecimal addition to compute the exact sum of a * b + c if a, b, and c are all finite floating-point values. From duke at openjdk.org Sun Dec 21 23:44:53 2025 From: duke at openjdk.org (Florent Guillaume) Date: Sun, 21 Dec 2025 23:44:53 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v7] In-Reply-To: References: Message-ID: On Sat, 20 Dec 2025 08:23:25 GMT, eunbin son wrote: >> ## Summary >> Adds comprehensive edge case tests for `Objects.requireNonNull`, >> `requireNonNullElse`, and `requireNonNullElseGet` methods to improve >> test coverage. >> >> ## Problem >> The current test suite for `Objects.requireNonNull` methods covers >> basic cases but lacks edge case coverage. >> >> ## Solution >> This PR adds tests for the following edge cases: >> - requireNonNull with null Supplier parameter >> - requireNonNull with Supplier that throws exception >> - requireNonNullElse with both arguments null >> - requireNonNullElseGet with null supplier >> - requireNonNullElseGet with supplier returning null >> >> ## Issue >> Fixes JDK-8373661 >> >> **JBS Issue Link**: https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8373661 >> >> ## Type of Change >> - [x] Test addition/modification >> - [ ] Bug fix >> - [ ] New feature >> - [ ] Documentation improvement >> - [ ] Refactoring >> >> ## Testing >> >> make test TEST="jtreg:test/jdk/java/util/Objects" > > eunbin son has updated the pull request incrementally with one additional commit since the last revision: > > 8373661: Address liach's feedback on copyright year and redundant messages > > I apologize for the earlier incorrect implementation. As @liach noted, > "I asked to run a command to fix the copyright year and to remove > redundant message, both of which are done incorrectly." I have now > properly addressed both concerns: > > - Copyright year: Updated to 2025 (the copyright year was already set > in the previous commit, but I should have used the > update_copyright_year.sh script as requested) > > - Redundant messages: Removed all exception message tests, verbose > inline comments, and simplified all test messages to use only test > method names > > Thanks to @liach for the detailed feedback. So much time and power extended on reviewing a PR for one test file whose update changes essentially nothing to the JDK... Using AI tools on the JDK for no other purpose than using AI... There are other priorities imho. This PR should be closed for lack of relevance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3679738015 From john_platts at hotmail.com Mon Dec 22 00:02:13 2025 From: john_platts at hotmail.com (John Platts) Date: Mon, 22 Dec 2025 00:02:13 +0000 Subject: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor Message-ID: The following loop in the java.math.BigDecimal(double val, MathContext mc) constructor is inefficient: while ((significand & 1) == 0) { // i.e., significand is even significand >>= 1; exponent++; } Here is a more efficient alternative using Long.numberOfTrailingZeros: final int numOfTrailingZerosInSignificand = Long.numberOfTrailingZeros(significand); significand >>= numOfTrailingZerosInSignificand; exponent += numOfTrailingZerosInSignificand; From duke at openjdk.org Mon Dec 22 03:24:01 2025 From: duke at openjdk.org (eunbin son) Date: Mon, 22 Dec 2025 03:24:01 GMT Subject: RFR: 8373661: Add edge case tests for Objects.requireNonNull methods [v7] In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 23:41:42 GMT, Florent Guillaume wrote: >> eunbin son has updated the pull request incrementally with one additional commit since the last revision: >> >> 8373661: Address liach's feedback on copyright year and redundant messages >> >> I apologize for the earlier incorrect implementation. As @liach noted, >> "I asked to run a command to fix the copyright year and to remove >> redundant message, both of which are done incorrectly." I have now >> properly addressed both concerns: >> >> - Copyright year: Updated to 2025 (the copyright year was already set >> in the previous commit, but I should have used the >> update_copyright_year.sh script as requested) >> >> - Redundant messages: Removed all exception message tests, verbose >> inline comments, and simplified all test messages to use only test >> method names >> >> Thanks to @liach for the detailed feedback. > > So much time and power extended on reviewing a PR for one test file whose update changes essentially nothing to the JDK... Using AI tools on the JDK for no other purpose than using AI... > There are other priorities imho. > This PR should be closed for lack of relevance. Thank you for the review and for pointing out the priority concerns. @efge My intention was simply to make a small, good-faith contribution to the JDK test code, not to add review burden or to promote the use of AI tools. I understand if this change is not considered relevant. I appreciate the time you?ve already spent on this. @liach @RogerRiggs ------------- PR Comment: https://git.openjdk.org/jdk/pull/28845#issuecomment-3680215142 From galder at openjdk.org Mon Dec 22 09:43:02 2025 From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=) Date: Mon, 22 Dec 2025 09:43:02 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 In-Reply-To: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> Message-ID: On Mon, 15 Dec 2025 15:51:32 GMT, Yi Wu wrote: > This patch adds mid-end support for vectorized min/max reduction operations for half floats. It also includes backend AArch64 support for these operations. > Both floating point min/max reductions don?t require strict order, because they are associative. > > It will generate NEON fminv/fmaxv reduction instructions when max vector length is 8B or 16B. On SVE supporting machines with vector lengths > 16B, it will generate the SVE fminv/fmaxv instructions. > The patch also adds support for partial min/max reductions on SVE machines using fminv/fmaxv. > > Ratio of throughput(ops/ms) > 1 indicates the performance with this patch is better than the mainline. > > Neoverse N1 (UseSVE = 0, max vector length = 16B): > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionMaxFP16 256 thrpt 9 3.69 6.44 > ReductionMaxFP16 512 thrpt 9 3.71 7.62 > ReductionMaxFP16 1024 thrpt 9 4.16 8.64 > ReductionMaxFP16 2048 thrpt 9 4.44 9.12 > ReductionMinFP16 256 thrpt 9 3.69 6.43 > ReductionMinFP16 512 thrpt 9 3.70 7.62 > ReductionMinFP16 1024 thrpt 9 4.16 8.64 > ReductionMinFP16 2048 thrpt 9 4.44 9.10 > > > Neoverse V1 (UseSVE = 1, max vector length = 32B): > > Benchmark vectorDim Mode Cnt 8B 16B 32B > ReductionMaxFP16 256 thrpt 9 3.96 8.62 8.02 > ReductionMaxFP16 512 thrpt 9 3.54 9.25 11.71 > ReductionMaxFP16 1024 thrpt 9 3.77 8.71 14.07 > ReductionMaxFP16 2048 thrpt 9 3.88 8.44 14.69 > ReductionMinFP16 256 thrpt 9 3.96 8.61 8.03 > ReductionMinFP16 512 thrpt 9 3.54 9.28 11.69 > ReductionMinFP16 1024 thrpt 9 3.76 8.70 14.12 > ReductionMinFP16 2048 thrpt 9 3.87 8.45 14.70 > > > Neoverse V2 (UseSVE = 2, max vector length = 16B): > > Benchmark vectorDim Mode Cnt 8B 16B > ReductionMaxFP16 256 thrpt 9 4.78 10.00 > ReductionMaxFP16 512 thrpt 9 3.74 11.33 > ReductionMaxFP16 1024 thrpt 9 3.86 9.59 > ReductionMaxFP16 2048 thrpt 9 3.94 8.71 > ReductionMinFP16 256 thrpt 9 4.78 10.00 > ReductionMinFP16 512 thrpt 9 3.74 11.29 > ReductionMinFP16 1024 thrpt 9 3.86 9.58 > ReductionMinFP16 2048 thrpt 9 3.94 8.71 > > > Testing: > hotspot_all, jdk (tier1-3) and langtools (tier1) all pass on Neoverse N1/V1/V2. Thanks @yiwu0b11, some superficial comments test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 486: > 484: @Test > 485: @Warmup(500) > 486: @IR(counts = {"reduce_minHF_masked", " >0 "}, Could you add IRNode constants for `reduce_minHF_masked`? Also for the max version below test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 319: > 317: > 318: @Benchmark > 319: public short ReductionMinFP16() { Suggestion: public short reductionMinFP16() { test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 328: > 326: > 327: @Benchmark > 328: public short ReductionMaxFP16() { Suggestion: public short reductionMaxFP16() { ------------- Changes requested by galder (Author). PR Review: https://git.openjdk.org/jdk/pull/28828#pullrequestreview-3603354237 PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2639273162 PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2639270984 PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2639271426 From rriggs at openjdk.org Mon Dec 22 14:34:04 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 22 Dec 2025 14:34:04 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 Given early comments about parsing, I'd expect further work to allow queries of the Map testing for the fields needed by common patterns. A specialized Map could use a bitmap/array for the ChronoFields and test for multiple fields at a time. A specialized Map could have a `putChronoField` method that would bypass extra testing on the type, it would be used by the implementation in Parsed maintaining encapsulation. There is an edge case that could be used for an custom implementation of TemporalField in which the `TemporField.resolve` implementation for the new custom field could `put` a new non-ChronoField field into the map. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3682326591 From liach at openjdk.org Mon Dec 22 16:02:01 2025 From: liach at openjdk.org (Chen Liang) Date: Mon, 22 Dec 2025 16:02:01 GMT Subject: RFR: 8372460: Use EnumMap instead of HashMap for DateTimeFormatter parsing to improve performance [v7] In-Reply-To: References: Message-ID: <1fPWBjSZO5rye867HjTu4PDI_JMKhDniT59FaeZ1IXk=.0701f069-733d-4552-9ef7-ee7327ac82cc@github.com> 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 I think this work may be accepted for now for its immediate performance gain. Properly implementing a Map is a more complex task that is no less error prone compared to this onlyChronoField boolean tracker field. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3682685346 From chen.l.liang at oracle.com Mon Dec 22 16:09:21 2025 From: chen.l.liang at oracle.com (Chen Liang) Date: Mon, 22 Dec 2025 16:09:21 +0000 Subject: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor In-Reply-To: References: Message-ID: Hello, this appears to be a harmless cleanup that has no behavioral impact. Created https://bugs.openjdk.org/browse/JDK-8374202 for this. Feel free to follow our guide at https://openjdk.org/guide/ to submit a PR on GitHub for this issue. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of John Platts Sent: Sunday, December 21, 2025 6:02 PM To: core-libs-dev at openjdk.org Subject: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor The following loop in the java.math.BigDecimal(double val, MathContext mc) constructor is inefficient: while ((significand & 1) == 0) { // i.e., significand is even significand >>= 1; exponent++; } Here is a more efficient alternative using Long.numberOfTrailingZeros: final int numOfTrailingZerosInSignificand = Long.numberOfTrailingZeros(significand); significand >>= numOfTrailingZerosInSignificand; exponent += numOfTrailingZerosInSignificand; -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Mon Dec 22 16:13:58 2025 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 22 Dec 2025 16:13:58 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 I primarily object to the spread of state across multiple classes where it is not needed. Accepting short term gains, just puts off final solutions and tends to muddy the implementation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3682747998 From bkilambi at openjdk.org Mon Dec 22 16:28:45 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 22 Dec 2025 16:28:45 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: > 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 ... Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: Address review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27526/files - new: https://git.openjdk.org/jdk/pull/27526/files/620b422a..21ad1c93 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=02-03 Stats: 43 lines in 3 files changed: 16 ins; 5 del; 22 mod Patch: https://git.openjdk.org/jdk/pull/27526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526 PR: https://git.openjdk.org/jdk/pull/27526 From bkilambi at openjdk.org Mon Dec 22 16:28:48 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 22 Dec 2025 16:28:48 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Fri, 19 Dec 2025 08:47:47 GMT, Xiaohong Gong wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 3457: > >> 3455: format %{ "reduce_addD_sve $dst_src1, $dst_src1, $src2" %} >> 3456: ins_encode %{ >> 3457: assert(UseSVE > 0, "must be sve"); > > Why do you remove this assertion? It was by mistake and it went past my notice. Thanks. I reverted this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2640448217 From bkilambi at openjdk.org Mon Dec 22 16:28:55 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 22 Dec 2025 16:28:55 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v2] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Fri, 19 Dec 2025 08:50:59 GMT, Xiaohong Gong wrote: >> Bhavana Kilambi 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: >> >> - Address review comments >> - Merge 'master' >> - 8366444: Add support for add/mul reduction operations for Float16 >> >> 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 vecto... > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 3490: > >> 3488: %} >> 3489: ins_pipe(pipe_slow); >> 3490: %} > > Could you please float this rule above `reduce_addF_sve` and below `reduce_addHF`? Better to rename `reduce_addHF` to `reduce_addHF_neon` ? Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2640448612 From bkilambi at openjdk.org Mon Dec 22 16:37:56 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 22 Dec 2025 16:37:56 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v3] In-Reply-To: <58NIPjOC6PTzn0H5BwY5FUkNfpe_qHuHLyIPCLiZ1QI=.0bf7f024-e772-459c-bd96-01981446beda@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <58NIPjOC6PTzn0H5BwY5FUkNfpe_qHuHLyIPCLiZ1QI=.0bf7f024-e772-459c-bd96-01981446beda@github.com> Message-ID: On Fri, 19 Dec 2025 08:55:18 GMT, Xiaohong Gong wrote: >> Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix build failures on Mac > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 259: > >> 257: // implements strictly ordered floating point add reduction which does not require >> 258: // the FEAT_FP16 and ASIMDHP checks as SVE supports half-precision floats by default. >> 259: case Op_AddReductionVHF: > > Does it need to check `length_in_bytes < 8` for add reduction? Yes, it would be better to add it. Although when I tested with `MaxVectorSize=4`, it defaults to 8B instead but with the stress flags above, it could possibly fail although it wasn't easy to reproduce. I have still added this check for `AddReductionVHF` instead. > src/hotspot/cpu/aarch64/aarch64_vector.ad line 392: > >> 390: case Op_StoreVectorScatter: >> 391: case Op_AddReductionVF: >> 392: case Op_AddReductionVHF: > > Suggestion: > > case Op_AddReductionVHF: > case Op_AddReductionVF: Done > src/hotspot/share/opto/vectornode.hpp line 323: > >> 321: // is generated through VectorAPI as VectorAPI does not impose any such rules on ordering. >> 322: const bool _requires_strict_order; >> 323: public: > > Suggestion: > > const bool _requires_strict_order; > > public: Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2640473140 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2640474548 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2640473528 From iklam at openjdk.org Mon Dec 22 18:05:44 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 18:05:44 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Message-ID: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. ------------- Commit messages: - 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Changes: https://git.openjdk.org/jdk/pull/28938/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28938&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373983 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28938.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28938/head:pull/28938 PR: https://git.openjdk.org/jdk/pull/28938 From duke at openjdk.org Mon Dec 22 18:05:44 2025 From: duke at openjdk.org (khanbilal732) Date: Mon, 22 Dec 2025 18:05:44 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). Marked as reviewed by khanbilal732 at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600847786 PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3600867977 From naoto at openjdk.org Mon Dec 22 18:09:11 2025 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 22 Dec 2025 18:09:11 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. Looks fine ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28938#pullrequestreview-3605159944 From iklam at openjdk.org Mon Dec 22 19:47:07 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 19:47:07 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> Message-ID: On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato wrote: >> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. >> >> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. > > Looks fine Thanks @naotoj for the review ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3683897935 From iklam at openjdk.org Mon Dec 22 19:47:09 2025 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 22 Dec 2025 19:47:09 GMT Subject: Integrated: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. This pull request has now been integrated. Changeset: 4b8eda30 Author: Ioi Lam URL: https://git.openjdk.org/jdk/commit/4b8eda30474b99a9f1065e5cea9d8c2fb859bab2 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/28938 From asemenyuk at openjdk.org Mon Dec 22 22:07:16 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 22 Dec 2025 22:07:16 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact Message-ID: Miscellaneous refactorings without functional changes: - Replace StringBuffer with StringBuilder where appropriate - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle - Remove redundat parameter from `SetBuilder.build()` - Make `JUnitUtils.assertArrayEquals()` permit null-s - Add `JPackageCommand.withToolProvider()` - Make some handy package-private methods in StandardBundlingOperation class public - BundleSpec: add "sealed" modifier - IdentityWrapper: add `wrapIdentity()` - Simplify `DefaultBundlingEnvironment.createNativePackage()` - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used ------------- Commit messages: - Use Files.createDirectories() instead of TKit.createDirectories() where automatic clean-up functionality is not used - DefaultBundlingEnvironment: change the signature of createNativePackage() - DefaultBundlingEnvironment: better error message in getBundlerSupplier() - TKit: remove "throws IOException" from createDirectories() - IdentityWrapper: add wrapIdentity() - BundleSpec: add "sealed" - PackageType: follow-up for BundlingOperationDescriptor changes; ignore errors when the service loader can't find BundlingEnvironment instance. - StandardBundlingOperation: make handy package-private methods public, add Verb enum - BundlingOperationDescriptor: add VERB_CREATE_BUNDLE, add another ctor - JPackageCommand: add withToolProvider() - ... and 5 more: https://git.openjdk.org/jdk/compare/b5ac8f83...e9583db1 Changes: https://git.openjdk.org/jdk/pull/28957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374216 Stats: 232 lines in 25 files changed: 120 ins; 39 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From asemenyuk at openjdk.org Mon Dec 22 22:15:13 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 22 Dec 2025 22:15:13 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: References: Message-ID: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used Alexey Semenyuk 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 two new commits since the last revision: - Use Files.createDirectories() instead of TKit.createDirectories() where automatic clean-up functionality is not used - DefaultBundlingEnvironment: change the signature of createNativePackage() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28957/files - new: https://git.openjdk.org/jdk/pull/28957/files/e9583db1..65d9c176 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From asemenyuk at openjdk.org Mon Dec 22 23:47:54 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 22 Dec 2025 23:47:54 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 22:15:13 GMT, Alexey Semenyuk wrote: >> Miscellaneous refactorings without functional changes: >> >> - Replace StringBuffer with StringBuilder where appropriate >> - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions >> - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle >> - Remove redundat parameter from `SetBuilder.build()` >> - Make `JUnitUtils.assertArrayEquals()` permit null-s >> - Add `JPackageCommand.withToolProvider()` >> - Make some handy package-private methods in StandardBundlingOperation class public >> - BundleSpec: add "sealed" modifier >> - IdentityWrapper: add `wrapIdentity()` >> - Simplify `DefaultBundlingEnvironment.createNativePackage()` >> - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used > > Alexey Semenyuk 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 two new commits since the last revision: > > - Use Files.createDirectories() instead of TKit.createDirectories() where automatic clean-up functionality is not used > - DefaultBundlingEnvironment: change the signature of createNativePackage() @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28957#issuecomment-3684561846 From asemenyuk at openjdk.org Tue Dec 23 00:01:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 00:01:48 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v3] In-Reply-To: References: Message-ID: <1_c7SUDrh_tNCyjh5AT-DuEwPb2NFYfm5KJ_nQacPmc=.602c57c0-813c-4806-bea7-31a924359d0d@github.com> > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits: - Use Files.createDirectories() instead of TKit.createDirectories() where automatic clean-up functionality is not used - DefaultBundlingEnvironment: change the signature of createNativePackage() - DefaultBundlingEnvironment: better error message in getBundlerSupplier() - TKit: remove "throws IOException" from createDirectories() - IdentityWrapper: add wrapIdentity() - BundleSpec: add "sealed" - PackageType: follow-up for BundlingOperationDescriptor changes; ignore errors when the service loader can't find BundlingEnvironment instance. - StandardBundlingOperation: make handy package-private methods public, add Verb enum - BundlingOperationDescriptor: add VERB_CREATE_BUNDLE, add another ctor - JPackageCommand: add withToolProvider() - ... and 5 more: https://git.openjdk.org/jdk/compare/4b8eda30...5d43b18f ------------- Changes: https://git.openjdk.org/jdk/pull/28957/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=02 Stats: 234 lines in 25 files changed: 120 ins; 41 del; 73 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From almatvee at openjdk.org Tue Dec 23 00:01:58 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 00:01:58 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 22:15:13 GMT, Alexey Semenyuk wrote: >> Miscellaneous refactorings without functional changes: >> >> - Replace StringBuffer with StringBuilder where appropriate >> - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions >> - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle >> - Remove redundat parameter from `SetBuilder.build()` >> - Make `JUnitUtils.assertArrayEquals()` permit null-s >> - Add `JPackageCommand.withToolProvider()` >> - Make some handy package-private methods in StandardBundlingOperation class public >> - BundleSpec: add "sealed" modifier >> - IdentityWrapper: add `wrapIdentity()` >> - Simplify `DefaultBundlingEnvironment.createNativePackage()` >> - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used > > Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. Looks good with minor comments. src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java line 71: > 69: } > 70: > 71: public boolean createBundle() { `createBundle` -> `isCreateBundleVerb`. `createBundle` is confusing. It reads like it should create bundle when this function is called. src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java line 49: > 47: > 48: createNativePackage(options, > 49: WinFromOpions.createWinMsiPackage(options), `WinFromOpions` -> `WinFromOptions`. Missing `t`. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 463: > 461: return useKeychain(keychain.spec().keychain()); > 462: } > 463: `unpackadeRuntimeBundleDir` -> `unpackedRuntimeBundleDir` ------------- PR Review: https://git.openjdk.org/jdk/pull/28957#pullrequestreview-3606075853 PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641516837 PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641524848 PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641532148 From almatvee at openjdk.org Tue Dec 23 00:01:59 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 00:01:59 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 23:30:48 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java line 71: > >> 69: } >> 70: >> 71: public boolean createBundle() { > > `createBundle` -> `isCreateBundleVerb`. `createBundle` is confusing. It reads like it should create bundle when this function is called. I am confused about use case of this enum. It has `SIGN` which is mac specific and has `CREATE` for create bundle which sounds generic for all platforms. Can you explain usage of this enum, improve it is naming or document it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641519758 From liach at openjdk.org Tue Dec 23 00:16:03 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Dec 2025 00:16:03 GMT Subject: RFR: 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:01:03 GMT, Chen Liang wrote: > The bitwise manipulation code in ImageDecompressor::getU8 and getU4 utilizes implicit conversion to signed int for bitwise or, making this code confusing, especially when the most significant bytes are explicitly converted to unsigned long long, and unsigned long long takes part in a bitwise or with int. We should convert all u1 to u8/u4 before shifts to make the code easier to maintain and understand. I ran tier 1-5, only unrelated failures. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28903#issuecomment-3684607749 From liach at openjdk.org Tue Dec 23 00:16:03 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Dec 2025 00:16:03 GMT Subject: Integrated: 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp In-Reply-To: References: Message-ID: On Thu, 18 Dec 2025 18:01:03 GMT, Chen Liang wrote: > The bitwise manipulation code in ImageDecompressor::getU8 and getU4 utilizes implicit conversion to signed int for bitwise or, making this code confusing, especially when the most significant bytes are explicitly converted to unsigned long long, and unsigned long long takes part in a bitwise or with int. We should convert all u1 to u8/u4 before shifts to make the code easier to maintain and understand. This pull request has now been integrated. Changeset: ecb42341 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/ecb42341a94326b1ee85ddd7b9ebadce8c952b99 Stats: 7 lines in 1 file changed: 0 ins; 0 del; 7 mod 8373447: Suspicious sign extension after integer promotion in imageDecompressor.cpp Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/28903 From asemenyuk at openjdk.org Tue Dec 23 01:00:28 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 01:00:28 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v4] In-Reply-To: References: Message-ID: > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: unpackadeRuntimeBundleDir -> unpackedRuntimeBundleDir ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28957/files - new: https://git.openjdk.org/jdk/pull/28957/files/5d43b18f..9ab1bb00 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=02-03 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From asemenyuk at openjdk.org Tue Dec 23 01:00:30 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 01:00:30 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 23:44:47 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 463: > >> 461: return useKeychain(keychain.spec().keychain()); >> 462: } >> 463: > > `unpackadeRuntimeBundleDir` -> `unpackedRuntimeBundleDir` Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641623452 From asemenyuk at openjdk.org Tue Dec 23 01:16:48 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 01:16:48 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v5] In-Reply-To: References: Message-ID: > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: - WinFromOpions -> WinFromOptions - StandardBundlingOperation: make the Verb enum private and document - StandardBundlingOperation: rename createBundle() into isCreateBundle() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28957/files - new: https://git.openjdk.org/jdk/pull/28957/files/9ab1bb00..d36624d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=03-04 Stats: 15 lines in 3 files changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From asemenyuk at openjdk.org Tue Dec 23 01:16:50 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 01:16:50 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 23:32:59 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardBundlingOperation.java line 71: >> >>> 69: } >>> 70: >>> 71: public boolean createBundle() { >> >> `createBundle` -> `isCreateBundleVerb`. `createBundle` is confusing. It reads like it should create bundle when this function is called. > > I am confused about use case of this enum. It has `SIGN` which is mac specific and has `CREATE` for create bundle which sounds generic for all platforms. Can you explain usage of this enum, improve it is naming or document it? This enum is for internal use. Made it public by accident. Fixed & documented. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641640230 From asemenyuk at openjdk.org Tue Dec 23 01:16:53 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 01:16:53 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v2] In-Reply-To: References: <-9nHNbWQ_WAxh3K6IFU8jUlYt1JN-i3JwzGyyRl_8Io=.96e50905-7f45-4939-9e95-574db94fd0d0@github.com> Message-ID: On Mon, 22 Dec 2025 23:37:50 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. > > src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinBundlingEnvironment.java line 49: > >> 47: >> 48: createNativePackage(options, >> 49: WinFromOpions.createWinMsiPackage(options), > > `WinFromOpions` -> `WinFromOptions`. Missing `t`. Fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28957#discussion_r2641646228 From asemenyuk at openjdk.org Tue Dec 23 02:27:35 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 02:27:35 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v6] In-Reply-To: References: Message-ID: > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: BasicTest: use Files.createDirectories() instead of TKit.createDirectories() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28957/files - new: https://git.openjdk.org/jdk/pull/28957/files/d36624d3..5b41d27d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28957&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28957.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28957/head:pull/28957 PR: https://git.openjdk.org/jdk/pull/28957 From almatvee at openjdk.org Tue Dec 23 03:04:52 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:04:52 GMT Subject: RFR: 8374216: Assorted changes to jpackage without functional impact [v6] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 02:27:35 GMT, Alexey Semenyuk wrote: >> Miscellaneous refactorings without functional changes: >> >> - Replace StringBuffer with StringBuilder where appropriate >> - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions >> - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle >> - Remove redundat parameter from `SetBuilder.build()` >> - Make `JUnitUtils.assertArrayEquals()` permit null-s >> - Add `JPackageCommand.withToolProvider()` >> - Make some handy package-private methods in StandardBundlingOperation class public >> - BundleSpec: add "sealed" modifier >> - IdentityWrapper: add `wrapIdentity()` >> - Simplify `DefaultBundlingEnvironment.createNativePackage()` >> - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > BasicTest: use Files.createDirectories() instead of TKit.createDirectories() Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28957#pullrequestreview-3606368301 From almatvee at openjdk.org Tue Dec 23 03:10:25 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:10:25 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" Message-ID: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> - Removed `plst`. It is not clear why we need it. - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. ------------- Commit messages: - 8374215: [macos] Clean "lic_template.plist" Changes: https://git.openjdk.org/jdk/pull/28959/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374215 Stats: 13 lines in 1 file changed: 0 ins; 13 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28959.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28959/head:pull/28959 PR: https://git.openjdk.org/jdk/pull/28959 From asemenyuk at openjdk.org Tue Dec 23 03:10:27 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 03:10:27 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 02:49:22 GMT, Alexander Matveev wrote: > - Removed `plst`. It is not clear why we need it. > - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist line 184: > 182: 0x0000 > 183: Data > 184: AAYFTm9yc2sERW5pZwlJa2tlIGVuaWcIU2tyaXYgdXQKQXJraXZlci4uLqNIdmlzIERlIGVyIGVuaWcgaSBiZXN0ZW1tZWxzZW5lIGkgZGVubmUgbGlzZW5zYXZ0YWxlbiwga2xpa2tlciBEZSBwjCAiRW5pZyIta25hcHBlbiBmb3IgjCBpbnN0YWxsZXJlIHByb2dyYW12YXJlbi4gSHZpcyBEZSBpa2tlIGVyIGVuaWcsIGtsaWtrZXIgRGUgcIwgIklra2UgZW5pZyIu I suppose this is a base64-encoded Norwegian translation of something. We don't support Norwegian l10n. Supported l10n-s should be in .properties files and encoded as base64 at runtime. ------------- PR Review: https://git.openjdk.org/jdk/pull/28959#pullrequestreview-3606363972 PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2641780135 From almatvee at openjdk.org Tue Dec 23 03:10:27 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:10:27 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 02:49:22 GMT, Alexander Matveev wrote: > - Removed `plst`. It is not clear why we need it. > - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. @alexeysemenyukoracle Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3684859375 From almatvee at openjdk.org Tue Dec 23 03:10:29 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:10:29 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 03:00:32 GMT, Alexey Semenyuk wrote: >> - Removed `plst`. It is not clear why we need it. >> - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist line 184: > >> 182: 0x0000 >> 183: Data >> 184: AAYFTm9yc2sERW5pZwlJa2tlIGVuaWcIU2tyaXYgdXQKQXJraXZlci4uLqNIdmlzIERlIGVyIGVuaWcgaSBiZXN0ZW1tZWxzZW5lIGkgZGVubmUgbGlzZW5zYXZ0YWxlbiwga2xpa2tlciBEZSBwjCAiRW5pZyIta25hcHBlbiBmb3IgjCBpbnN0YWxsZXJlIHByb2dyYW12YXJlbi4gSHZpcyBEZSBpa2tlIGVyIGVuaWcsIGtsaWtrZXIgRGUgcIwgIklra2UgZW5pZyIu > > I suppose this is a base64-encoded Norwegian translation of something. We don't support Norwegian l10n. > > Supported l10n-s should be in .properties files and encoded as base64 at runtime. I will drop all translations except `de`, `ja`, `zh_CN` and move them to .properties files. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2641786661 From asemenyuk at openjdk.org Tue Dec 23 03:16:49 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 03:16:49 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 02:49:22 GMT, Alexander Matveev wrote: > NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. Right, but `hdiutil udifrez` command is still working: [02:08:24.166] Running /usr/bin/hdiutil [02:08:24.194] Command [PID: 93201]: /usr/bin/hdiutil udifrez testCommon/output/CommonLicenseTest-1.0.dmg -xml /var/folders/xt/bm4_x23d1_s0kbvvls86_7z80000gr/T/jdk.jpackage6799898339358549904/config/CommonLicenseTest-license.plist [02:08:24.194] Output: hdiutil: WARNING: udifrez is deprecated copying resource 'STR#' (5000)... copying resource 'STR#' (5001)... copying resource 'STR#' (5002)... copying resource 'STR#' (5003)... copying resource 'STR#' (5004)... copying resource 'STR#' (5005)... copying resource 'STR#' (5006)... copying resource 'STR#' (5007)... copying resource 'STR#' (5008)... copying resource 'STR#' (5009)... copying resource 'STR#' (5010)... copying resource 'STR#' (5011)... copying resource 'STR#' (5012)... copying resource 'STR#' (5013)... copying resource 'STR#' (5014)... copying resource 'STR#' (5015)... copying resource 'STR#' (5016)... copying resource 'TMPL' (128)... copying resource 'TEXT' (5000)... copying resource 'LPic' (5000)... copying resource 'styl' (5000)... copying resource 'plst' (0)... [02:08:24.195] Returned: 0 [02:08:24.195] Result DMG installer for CommonLicenseTest: testCommon/output/CommonLicenseTest-1.0.dmg. [02:08:24.196] Succeeded in building Mac DMG Package package [02:08:24.319] TRACE: exec: Done. Exit code: 0 Should we spend time cleaning the "lic_template.plist" file and adding complexity by moving resources to l10n files, or merely remove support for a license file in DMG packaging? I'm on the fence. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3684915337 From almatvee at openjdk.org Tue Dec 23 03:20:51 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:20:51 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 03:13:05 GMT, Alexey Semenyuk wrote: > Should we spend time cleaning the "lic_template.plist" file and adding complexity by moving resources to l10n files, or merely remove support for a license file in DMG packaging? I'm on the fence. I think we should not remove it as long as it is supported by `hdiutil` in case if it is being used. For cleanup we should drop unsupported translations, but moving them to l10n files is not really necessary, since we will never change them. I will prefer drop translations, but do not move them to l10n files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3684929135 From asemenyuk at openjdk.org Tue Dec 23 03:32:52 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 03:32:52 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 03:18:47 GMT, Alexander Matveev wrote: > but moving them to l10n files is not really necessary, since we will never change them. Right, but this way they will be out of the scope for the localization team. This is not right. Let's get it fixed properly and never touch it again until the `hdiutil udifrez` command is entirely broken. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3684952429 From almatvee at openjdk.org Tue Dec 23 03:36:54 2025 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 23 Dec 2025 03:36:54 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 02:49:22 GMT, Alexander Matveev wrote: > - Removed `plst`. It is not clear why we need it. > - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. Do you have suggestion if we should issue warning for `DMG` and `--license-file` that it was deprecated and we will drop it as soon as `hdiutil` drops it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3684958332 From asemenyuk at openjdk.org Tue Dec 23 04:00:49 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 04:00:49 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" In-Reply-To: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 02:49:22 GMT, Alexander Matveev wrote: > - Removed `plst`. It is not clear why we need it. > - I did not found official specification for this file, but based on some research `plst` is not part of it. Other entries seems to be required. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. I don't support complicating jpackage with the warning. When `hdiutil udifrez` stops working, jpackage will start failing: https://github.com/openjdk/jdk/blob/ecb42341a94326b1ee85ddd7b9ebadce8c952b99/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java#L417 We don't need anything extra. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3685000102 From asemenyuk at openjdk.org Tue Dec 23 04:42:08 2025 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 23 Dec 2025 04:42:08 GMT Subject: Integrated: 8374216: Assorted changes to jpackage without functional impact In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 20:09:13 GMT, Alexey Semenyuk wrote: > Miscellaneous refactorings without functional changes: > > - Replace StringBuffer with StringBuilder where appropriate > - LauncherBuilder: set reasonable defaults to "defaultIconResourceName" property; move `defaultIconResourceName()` from LauncherFromOptions > - Make `MacHelper.createRuntimeBundle()` use PackageTest to create a runtime bundle. Will use DMG by default and optionally PKG packaging to create a runtime bundle > - Remove redundat parameter from `SetBuilder.build()` > - Make `JUnitUtils.assertArrayEquals()` permit null-s > - Add `JPackageCommand.withToolProvider()` > - Make some handy package-private methods in StandardBundlingOperation class public > - BundleSpec: add "sealed" modifier > - IdentityWrapper: add `wrapIdentity()` > - Simplify `DefaultBundlingEnvironment.createNativePackage()` > - TKit: remove "throws IOException" from `createDirectories()`; Replace `TKit.createDirectories()` with `Files.createDirectories()` where directory clean-up is not used This pull request has now been integrated. Changeset: a0094f52 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/a0094f529a6cf7e1e28a20d5033a9a1405f49d9f Stats: 248 lines in 27 files changed: 127 ins; 41 del; 80 mod 8374216: Assorted changes to jpackage without functional impact Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28957 From xgong at openjdk.org Tue Dec 23 04:53:57 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 23 Dec 2025 04:53:57 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 22 Dec 2025 16:28:45 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 gener... > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Thanks for your updating! I will trigger a test with kinds of SVE machines. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3685096477 From erfang at openjdk.org Tue Dec 23 07:27:36 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 23 Dec 2025 07:27:36 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v5] 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 incrementally with one additional commit since the last revision: wrap the test loop within a try/catch to speed up the tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28692/files - new: https://git.openjdk.org/jdk/pull/28692/files/b5237a28..e0e3d865 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28692&range=03-04 Stats: 2457 lines in 33 files changed: 1638 ins; 273 del; 546 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 Tue Dec 23 07:27:36 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 23 Dec 2025 07:27:36 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v3] In-Reply-To: References: <7AWYFpxh5IuDz-ILQnB1thgi5mFmfS0waEmJFfPcmM0=.ec8acf99-5311-405d-957f-526bd8d4af62@github.com> Message-ID: On Fri, 19 Dec 2025 22:02:03 GMT, Paul Sandoz wrote: >> Hi @PaulSandoz . I've changed to using a temporary variable. >> >> By the way, are you worried that the `read-after-write` optimization isn't implemented in some architectures? > > Or for some reason does not happen. I find it best if for the hot loops we can keep the code as focused as possible. Got it, thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28692#discussion_r2642240929 From qamai at openjdk.org Tue Dec 23 07:33:57 2025 From: qamai at openjdk.org (Quan Anh Mai) Date: Tue, 23 Dec 2025 07:33:57 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v5] In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 07:27:36 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 incrementally with one additional commit since the last revision: > > wrap the test loop within a try/catch to speed up the tests Marked as reviewed by qamai (Committer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28692#pullrequestreview-3606938781 From erfang at openjdk.org Tue Dec 23 07:34:00 2025 From: erfang at openjdk.org (Eric Fang) Date: Tue, 23 Dec 2025 07:34:00 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v4] In-Reply-To: References: Message-ID: On Fri, 19 Dec 2025 22:11:29 GMT, Paul Sandoz wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Refine the tests for identity values > > Very good, a good stepping stone to for further improvements to declare and test these constants. Just one last comment which i hope will be easy to address then I think its good for integration. Hi @PaulSandoz , I?ve already put the test loop into a try-catch block. Could you please take another look at this PR when you have time? Thanks a lot for your patience! ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3685511551 From alanb at openjdk.org Tue Dec 23 08:33:10 2025 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 23 Dec 2025 08:33:10 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> <4LyfgSLqfn9_LQw_btiGnIT3ENH7ljTUHf_Mu-UrtYU=.a5d35f14-ed31-4414-be0c-26136b1228a2@github.com> Message-ID: On Mon, 22 Dec 2025 18:06:30 GMT, Naoto Sato wrote: >> This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. >> >> Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. > > Looks fine @naotoj java.locale.useOldISOCodes was added as a compatibility switch in JDK 17. Do you have any sense as to whether it is used? I'm just wondering if if the "no longer supported" warning when the property is specified on the command line is worth it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3685715503 From bkilambi at openjdk.org Tue Dec 23 10:05:55 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Tue, 23 Dec 2025 10:05:55 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! Hello @marc-chevalier Could I request you to test the new patchset again please? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3686020585 From raffaello.giulietti at oracle.com Tue Dec 23 10:40:37 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Tue, 23 Dec 2025 10:40:37 +0000 Subject: Improving performance of the default implementation of java.lang.Math.fma In-Reply-To: References: Message-ID: Hi, both Math.fma() variants are annotated with @IntrinsicCandidate. This means that, in compiled machine code, the methods get replaced by a platform specific optimised instruction sequence, possibly just a single hardware instruction. While your proposal seems to be more efficient than the current Java code, it suffers from some drawbacks: * The methods are far less readable (and maintainable) than the current simple Java implementations. * Being more convoluted, they require extensive review time to make sure they are 100% correct. * They only benefit interpreted code, that is, code that is rarely executed. In normal circumstances, hot code does not execute the Java version. All in all, given the combination of the above, I'm not sure that a review effort would benefit the general public. Also, your claim about improved efficiency should be substantiated by JMH results (https://github.com/openjdk/jmh) to convince this audience. Greetings Raffaello ________________________________________ From: core-libs-dev on behalf of John Platts Sent: Sunday, December 21, 2025 06:12 To: core-libs-dev at openjdk.org Subject: Improving performance of the default implementation of java.lang.Math.fma There is a much better way to implement java.lang.Math.fma(double, double, double) than the current default implementation in src/java.base/share/classes/java/lang/Math.java. Here is a much better implementation of java.lang.Math.fma (and this has been shown to be much faster than (new BigDecimal(a)).multiply(new BigDecimal(b)).add(new BigDecimal(c)).doubleValue() if a, b, and c are all finite floating-point values through benchmarking): private static double scalbFiniteF64Sum(double hi, double lo, int exp) { // Both hi and lo should be finite, and |hi| >= |lo| should be true if // hi != 0.0 final double sum0 = hi + lo; final double scaleResult0 = Math.scalb(sum0, exp); if (!(Math.abs(scaleResult0) <= Double.MIN_NORMAL) || lo == 0.0) { // If |scaleResult0| > Double.MIN_NORMAL or lo == 0.0, then // scaleResult0 will be correctly rounded. // Return scaleResult0 in this case. return scaleResult0; } // scaleResult1 is equal to scaleResult0 with its ULP bit cleared. // This ensures that the final result will be correctly rounded if // the ULP bit of scaleResult0 is set. final double scaleResult1 = Double.longBitsToDouble( Double.doubleToRawLongBits(scaleResult0) & (-2L)); // scaleErr is equal to the error of scaling sum0 by 2**exp, scaled back // up by 2**-exp. scaleResult1 is used to compute scaleErr to ensure // that the value of the ULP bit of scaleResult0, scaled up by 2**-exp, // is included in scaleErr to ensure that the final result is correctly // rounded. final double scaleErr = sum0 - Math.scalb(scaleResult1, -exp); // err0 is equal to the error of hi + lo final double err0 = (hi - sum0) + lo; // Compute scaleErr + err0 using the Fast2Sum algorithm as // |scaleErr| >= |err0| should be true if |scaleErr| > 0 final double sum1 = scaleErr + err0; final double err1 = (scaleErr - sum1) + err0; final long sum1Bits = Double.doubleToRawLongBits(sum1); final long err1Bits = Double.doubleToRawLongBits(err1); final long sum1IsInexactInSignBit = err1Bits ^ (err1Bits + 0x7FFF_FFFF_FFFF_FFFFL); // roundedToOddSum1 is equal to the rounded to odd sum of scaleErr and // err0 final double roundedToOddSum1 = Double.longBitsToDouble((sum1Bits + (((sum1Bits ^ err1Bits) & sum1IsInexactInSignBit) >> 63)) | (sum1IsInexactInSignBit >>> 63)); // scaleResult2 is equal to the correctly rounded value of // (hi + lo) * 2**exp final double scaleResult2 = scaleResult1 + Math.scalb(roundedToOddSum1, exp); return scaleResult2; } public static double fma(double a, double b, double c) { final long aBits = Double.doubleToRawLongBits(a); final long bBits = Double.doubleToRawLongBits(b); final long cBits = Double.doubleToRawLongBits(c); final int aBiasedExp = (int) (aBits >>> 52) & 0x7FF; final int bBiasedExp = (int) (bBits >>> 52) & 0x7FF; final int cBiasedExp = (int) (cBits >>> 52) & 0x7FF; if (((aBits ^ (aBits - 1)) | (bBits ^ (bBits - 1)) | (cBits ^ (cBits - 1)) | (0x7FE - aBiasedExp) | (0x7FE - bBiasedExp)) < 0) { // If at least one of a, b, or c are zero or at least one of a or b // is non-finite, the result will be equal to a * b + c. return a * b + c; } else if (cBiasedExp == 0x7FF) { // If a and b are both nonzero finite numbers and c is a non-finite // value, simply return c since the exact result of a * b + c will // be equal to c in this case. return c; } // a, b, and c are all nonzero finite values at this point // Normalize a and b to normal floating-point numbers final int aIsDenormalMask = (aBiasedExp - 1) >> 31; final int bIsDenormalMask = (bBiasedExp - 1) >> 31; final long aNormalizeAdjBits = (aBits & 0x8000_0000_0000_0000L) | (aIsDenormalMask & 0x0350_0000_0000_0000L); final long bNormalizeAdjBits = (bBits & 0x8000_0000_0000_0000L) | (bIsDenormalMask & 0x0350_0000_0000_0000L); final double normalizedA = Double.longBitsToDouble(aBits | aNormalizeAdjBits) - Double.longBitsToDouble(aNormalizeAdjBits); final double normalizedB = Double.longBitsToDouble(bBits | bNormalizeAdjBits) - Double.longBitsToDouble(bNormalizeAdjBits); // If a is a denormal number, normalizedA is equal to a * 2**52. // Otherwise, if a is already a normal number, normalizedA is equal to // a. // If b is a denormal number, normalizedB is equal to b * 2**52. // Otherwise, if b is already a normal number, normalizedB is equal to // b. final long normalizedABits = Double.doubleToRawLongBits(normalizedA); final long normalizedBBits = Double.doubleToRawLongBits(normalizedB); final int normalizedABiasedExp = (int) (normalizedABits >>> 52) & 0x7FF; final int normalizedBBiasedExp = (int) (normalizedBBits >>> 52) & 0x7FF; // minPBiasedExp is the smallest possible biased exponent (with an // exponent bias of 1023) of the exact value of a * b. final int minPBiasedExp = normalizedABiasedExp + normalizedBBiasedExp + (aIsDenormalMask & -52) + (bIsDenormalMask & -52) + -1023; if (minPBiasedExp >= 2048) { // If minPBiasedExp >= 2048, then a * b + c is known to overflow to // infinity. Return a * b + c in this case. return a * b + c; } // Normalize c to a normal floating-point number final int cIsDenormalMask = (cBiasedExp - 1) >> 31; final long cNormalizeAdjBits = (cBits & 0x8000_0000_0000_0000L) | (cIsDenormalMask & 0x0350_0000_0000_0000L); final double normalizedC = Double.longBitsToDouble(cBits | cNormalizeAdjBits) - Double.longBitsToDouble(cNormalizeAdjBits); // If c is a denormal number, normalizedC is equal to c * 2**52. // Otherwise, if c is already a normal number, normalizedC is equal to // c. final long normalizedCBits = Double.doubleToRawLongBits(normalizedC); final int normalizedCBiasedExp = (int) (normalizedCBits >>> 52) & 0x7FF; final int adjCBiasedExp = normalizedCBiasedExp + (cIsDenormalMask & -52); // adjCBiasedExp is equal to floor(log2(|c|)) + 1023, even if c is a // denormal number final int expDiff = adjCBiasedExp - minPBiasedExp; if (expDiff >= 55) { // If expDiff is greater than or equal to 55, the exact value of // |a * b| is less than 0.5 * ulp(c). The correctly rounded result // of a * b + c is known to be equal to c in this case. Return c in // this case as the exact value of |a * b| is too small to affect // the correctly rounded result of a * b + c. return c; } // aMant is equal to the mantissa of a, with 1 <= |a| < 2 // bMant is equal to the mantissa of b, with 1 <= |b| < 2 final double aMant = Double.longBitsToDouble(((normalizedABits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL)); final double bMant = Double.longBitsToDouble(((normalizedBBits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL)); // Split aMant and bMant using Veltkamp-Dekker splitting final double aMantGamma = aMant * 134217729.0; final double bMantGamma = bMant * 134217729.0; final double aMantHi = aMantGamma + (aMant - aMantGamma); final double bMantHi = bMantGamma + (bMant - bMantGamma); final double aMantLo = aMant - aMantHi; final double bMantLo = bMant - bMantHi; final double pHi = aMant * bMant; final double pLo = ((aMantHi * bMantHi - pHi) + (aMantHi * bMantLo + aMantLo * bMantHi)) + aMantLo * bMantLo; if (minPBiasedExp >= 1 && pLo == 0.0) { // If minPBiasedExp >= 1 and pLo == 0.0 are both true, then a * b is // known to be exact and normal. Return a * b + c in this case. return a * b + c; } final int resultScaleUpExp = minPBiasedExp - 1023; if (expDiff <= -106) { // If expDiff <= -106 is true, then |a * b| >= 2**-968 must be true // since 2**-1074 <= |c| < 2**-105 * |a * b|. if (pLo == 0.0) { // If expDiff <= -106 and pLo == 0.0 are both true, then |c| // is too small to affect the correctly rounded result. // Return a * b in this case since a * b is known to be either // an exact normal finite number or infinity and as |c| is too // small to affect the result of a * b + c. return a * b; } else { // If expDiff <= -106 and pLo != 0.0 are both true, then // 0 < |c * 2**-resultScaleUpExp| < 0.5 * ulp(pLo) is known // to be true. // In this case, the rounded to odd sum of pLo and // c * 2**-resultScaleUpExp can be computed by decrementing // pLoBits by 1 if pLoBits and cBits have different signs // rounded to odd sum of pLo and c * 2**-resultScaleUpExp // can be computed by simply decrementing pLoBits by 1 if pLo // and c have different signs followed by setting the LSB bit as // in this case. final long pLoBits = Double.doubleToRawLongBits(pLo); // roundedToOddLoSum is equal to the rounded to odd sum of // pLo and c * 2**-resultScaleUpExp final double roundedToOddLoSum = Double.longBitsToDouble( (pLoBits + ((pLoBits ^ cBits) >> 63)) | 1L); // Return the correctly rounded value of // (s1 + roundedToOddLoSum) * 2**resultScaleUpExp return scalbFiniteF64Sum(pHi, roundedToOddLoSum, resultScaleUpExp); } } // -105 <= expDiff <= 54 is now true at this point final double scaledC = Double.longBitsToDouble(((normalizedCBits | 0x3FF0_0000_0000_0000L) & 0xBFFF_FFFF_FFFF_FFFFL) + ((long) expDiff << 52)); // Compute pLo + scaledC using the 2Sum algorithm final double s0 = pLo + scaledC; final double v0 = s0 - pLo; final double e0 = (pLo - (s0 - v0)) + (scaledC - v0); // s0 + e0 == pLo + scaledC // Compute pHi + s0 using the 2Sum algorithm final double s1 = pHi + s0; final double v1 = s1 - pHi; final double e1 = (pHi - (s1 - v1)) + (s0 - v1); // s1 + e1 + e0 == pHi + pLo + scaledC // Compute the rounded to odd sum of e1 and e0 to ensure that the final // result is correctly rounded. // Fast2Sum is sufficient for computing e1 + e0 as either |e1| == 0.0 or // |e1| >= |e0| should be true final double s2 = e1 + e0; final double e2 = (e1 - s2) + e0; // s1 + s2 + e2 == pHi + pLo + scaledC final long s2Bits = Double.doubleToRawLongBits(s2); final long e2Bits = Double.doubleToRawLongBits(e2); final long s2IsInexactInSignBit = e2Bits ^ (e2Bits + 0x7FFF_FFFF_FFFF_FFFFL); // roundedToOddS2 is equal to the rounded to odd sum of e1 and e0 and // is used to ensure that the final result is correctly rounded final double roundedToOddS2 = Double.longBitsToDouble( (s2Bits + (((s2Bits ^ e2Bits) & s2IsInexactInSignBit) >> 63)) | (s2IsInexactInSignBit >>> 63)); // Return the correctly rounded value of // (s1 + roundedToOddS2) * 2**resultScaleUpExp return scalbFiniteF64Sum(s1, roundedToOddS2, resultScaleUpExp); } There are a few tricks up the sleeve with the above implementation. If xBits is the result of Double.doubleToRawLongBits(x): xBits ^ (xBits - 1) is equal to -1 if and only if x == 0 or x == -0 and is non-negative otherwise xBits ^ (xBits + 0x7FFF_FFFF_FFFF_FFFFL) is negative if and only if x != 0 and equal to Long.MAX_VALUE if x == 0 The rounded to odd result of a + b is used in a few places in the above implementation of fma to ensure that the final sum is correctly rounded. From raffaello.giulietti at oracle.com Tue Dec 23 10:55:10 2025 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Tue, 23 Dec 2025 10:55:10 +0000 Subject: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor In-Reply-To: References: Message-ID: Straightforward enhancement, straightforward review. Thanks John Platts for the upcoming PR. ________________________________________ From: core-libs-dev on behalf of Chen Liang Sent: Monday, December 22, 2025 17:09 To: John Platts; core-libs-dev at openjdk.org Subject: Re: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor Hello, this appears to be a harmless cleanup that has no behavioral impact. Created https://bugs.openjdk.org/browse/JDK-8374202 for this. Feel free to follow our guide at https://openjdk.org/guide/ to submit a PR on GitHub for this issue. Regards, Chen Liang ________________________________ From: core-libs-dev on behalf of John Platts Sent: Sunday, December 21, 2025 6:02 PM To: core-libs-dev at openjdk.org Subject: Replace loop with Long.numberOfTrailingZeros in BigDecimal(double val, MathContext mc) constructor The following loop in the java.math.BigDecimal(double val, MathContext mc) constructor is inefficient: while ((significand & 1) == 0) { // i.e., significand is even significand >>= 1; exponent++; } Here is a more efficient alternative using Long.numberOfTrailingZeros: final int numOfTrailingZerosInSignificand = Long.numberOfTrailingZeros(significand); significand >>= numOfTrailingZerosInSignificand; exponent += numOfTrailingZerosInSignificand; From naoto at openjdk.org Tue Dec 23 17:39:14 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Dec 2025 17:39:14 GMT Subject: RFR: 8373983: java/util/Locale/UseOldISOCodesTest.java fails with JTREG_AOT_JDK=onestep In-Reply-To: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> References: <3rEXHY3jSwuIY-97UODDKjui4OvLbMatadVoqGuT7B4=.b34de0e1-9b13-4c39-ab8c-cf43fbb13a3a@github.com> Message-ID: On Sat, 20 Dec 2025 03:15:39 GMT, Ioi Lam wrote: > This test checks for a warning message that's printed by `sun.util.locale.BaseLocale.` during the AOT cache training run. Because `BaseLocale` is AOT-initialized, `BaseLocale.` is not executed when the test is running with an AOT cache, so the message is not printed. > > Since this message was already printed in the AOT training run, it's not necessary to print it again in the AOT production run. We should exclude the test case in the `JTREG_AOT_JDK=onestep` test mode. AFAIK, Google has been using the system property (cf. comments in https://bugs.openjdk.org/browse/JDK-8267069). So I would rather be on the safer side to emit the warning. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28938#issuecomment-3687445514 From liach at openjdk.org Tue Dec 23 19:40:02 2025 From: liach at openjdk.org (Chen Liang) Date: Tue, 23 Dec 2025 19:40:02 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 14:06:00 GMT, Nizar Benalla wrote: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28945#pullrequestreview-3609131169 From dl at openjdk.org Tue Dec 23 19:59:24 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 23 Dec 2025 19:59:24 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v14] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 18 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Check reworked ordering control - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check diagnosis - Avoid double-filtering - Merge branch 'openjdk:master' into JDK-8373118 - Another diagnostic - Relax orderings in push - Reduce fencing - ... and 8 more: https://git.openjdk.org/jdk/compare/e90d7ee4...63ed23c5 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/b0b37d38..63ed23c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=12-13 Stats: 2653 lines in 145 files changed: 1264 ins; 499 del; 890 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 naoto at openjdk.org Tue Dec 23 20:07:20 2025 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 23 Dec 2025 20:07:20 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList Message-ID: Removing the test from AOT Problem List. The test `java/lang/IO/IO.java` had a dependency on `jdk.internal.le` module, but it was removed in JDK26(https://bugs.openjdk.org/browse/JDK-8361613). Apart from that, the test case itself has been modified to not emit AOT/CDS logging messages in order for the output comparing test to succeed. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/28967/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28967&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374217 Stats: 6 lines in 2 files changed: 0 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28967.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28967/head:pull/28967 PR: https://git.openjdk.org/jdk/pull/28967 From iklam at openjdk.org Tue Dec 23 20:14:51 2025 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 23 Dec 2025 20:14:51 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 20:00:24 GMT, Naoto Sato wrote: > Removing the test from AOT Problem List. The test `java/lang/IO/IO.java` had a dependency on `jdk.internal.le` module, but it was removed in JDK26(https://bugs.openjdk.org/browse/JDK-8361613). Apart from that, the test case itself has been modified to not emit AOT/CDS logging messages in order for the output comparing test to succeed. looks good ------------- Marked as reviewed by iklam (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28967#pullrequestreview-3609220658 From dl at openjdk.org Tue Dec 23 23:38:10 2025 From: dl at openjdk.org (Doug Lea) Date: Tue, 23 Dec 2025 23:38:10 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v15] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 19 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check reworked ordering control - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check diagnosis - Avoid double-filtering - Merge branch 'openjdk:master' into JDK-8373118 - Another diagnostic - Relax orderings in push - ... and 9 more: https://git.openjdk.org/jdk/compare/6802d1a7...e73e127e ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/63ed23c5..e73e127e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=13-14 Stats: 14 lines in 3 files changed: 9 ins; 3 del; 2 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 serb at openjdk.org Wed Dec 24 01:49:49 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 01:49:49 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed Message-ID: The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374316: Update copyright year to 2025 for hotspot in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28970/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374316 Stats: 519 lines in 519 files changed: 0 ins; 0 del; 519 mod Patch: https://git.openjdk.org/jdk/pull/28970.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970 PR: https://git.openjdk.org/jdk/pull/28970 From xgong at openjdk.org Wed Dec 24 01:49:57 2025 From: xgong at openjdk.org (Xiaohong Gong) Date: Wed, 24 Dec 2025 01:49:57 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 22 Dec 2025 16:28:45 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 gener... > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Tests passed. LGTM! ------------- Marked as reviewed by xgong (Committer). PR Review: https://git.openjdk.org/jdk/pull/27526#pullrequestreview-3609692140 From jpai at openjdk.org Wed Dec 24 02:13:02 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 24 Dec 2025 02:13:02 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: On Tue, 23 Dec 2025 20:00:24 GMT, Naoto Sato wrote: > Removing the test from AOT Problem List. The test `java/lang/IO/IO.java` had a dependency on `jdk.internal.le` module, but it was removed in JDK26(https://bugs.openjdk.org/browse/JDK-8361613). Apart from that, the test case itself has been modified to not emit AOT/CDS logging messages in order for the output comparing test to succeed. test/jdk/java/lang/IO/IO.java line 53: > 51: /* > 52: * @test > 53: * @bug 8305457 8342936 8351435 8344706 8361613 8374217 Hello Naoto, the changes look OK to me. However, the guidelines of using `@bug` for tests https://openjdk.org/guide/#jtreg say: > 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. So I think we shouldn't add this bug id here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28967#discussion_r2644619880 From serb at openjdk.org Wed Dec 24 02:57:38 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 02:57:38 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed Message-ID: The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: ` git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374320: Update copyright year to 2025 for java.net.http in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28973/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28973&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374320 Stats: 191 lines in 191 files changed: 0 ins; 0 del; 191 mod Patch: https://git.openjdk.org/jdk/pull/28973.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28973/head:pull/28973 PR: https://git.openjdk.org/jdk/pull/28973 From kbarrett at openjdk.org Wed Dec 24 04:34:53 2025 From: kbarrett at openjdk.org (Kim Barrett) Date: Wed, 24 Dec 2025 04:34:53 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov wrote: > The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) There are a lot of non-hotspot files in this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688645543 From serb at openjdk.org Wed Dec 24 04:52:58 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 04:52:58 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 04:32:25 GMT, Kim Barrett wrote: > There are a lot of non-hotspot files in this PR. Most of them are related and were touched by the same commits pushed to `src/hotspot`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688672537 From serb at openjdk.org Wed Dec 24 05:27:56 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 05:27:56 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed In-Reply-To: References: Message-ID: <9cmIm_ANkhZ9knsjEEdCJjy4qJH6TGMFcLoPMS1OVBQ=.53c83270-52bb-4c26-a415-e54a9ed37f56@github.com> On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov wrote: > The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` I can split out some of these changes into a separate PR to make this one smaller, but I already have a bunch of them =( ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3688721427 From alanb at openjdk.org Wed Dec 24 06:58:51 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 24 Dec 2025 06:58:51 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 02:05:28 GMT, Sergey Bylokhov wrote: > The copyright year in "java.net.http" files updated in 2025 has been bumped to 2025. All files are updated which touched the src/java.net.http and related files. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > ` > git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3688873806 From serb at openjdk.org Wed Dec 24 07:03:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 07:03:31 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 06:55:36 GMT, Alan Bateman wrote: >I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. correct, they appeared in jdk/master in 2025 as new files as part of the JEP integration. Not sure whether they should be excluded or not, since they were touched this year in some way. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3688881325 From swen at openjdk.org Wed Dec 24 07:05:04 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 24 Dec 2025 07:05:04 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v4] In-Reply-To: References: Message-ID: <-mrZCW-zC8g6b229IgERMJpS5dM_xRego-4kRahpuKs=.16a3fce6-983a-41b0-bb81-08ec415b6480@github.com> > 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 22 commits: - Merge branch 'master' into optim_to_hex_202501 - 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 - ... and 12 more: https://git.openjdk.org/jdk/compare/a59dbc51...bcb7d4be ------------- Changes: https://git.openjdk.org/jdk/pull/22942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=03 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 serb at openjdk.org Wed Dec 24 07:12:21 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 07:12:21 GMT Subject: RFR: 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed Message-ID: The copyright year in "jdk.jpackage" files updated in 2025 has been bumped to 2025. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28979/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28979&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374326 Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28979.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28979/head:pull/28979 PR: https://git.openjdk.org/jdk/pull/28979 From erfang at openjdk.org Wed Dec 24 07:15:58 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 24 Dec 2025 07:15:58 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: Message-ID: <113AdKQ15cNGhCreLhNcnBjkOMh8riqUR8TnUCDKBPM=.7ec93b7a-6433-461c-8b61-93d360f7d712@github.com> On Fri, 12 Dec 2025 15:13:35 GMT, Emanuel Peter wrote: >> 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` ch... > > 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? Hi @eme64 , I?d really appreciate hearing your thoughts on this when you have a moment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2644986216 From serb at openjdk.org Wed Dec 24 07:51:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 24 Dec 2025 07:51:02 GMT Subject: RFR: 8374327: Update copyright year to 2025 for java.base in files where it was missed Message-ID: This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` ------------- Commit messages: - 8374327: Update copyright year to 2025 for java.base in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28980/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28980&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374327 Stats: 80 lines in 80 files changed: 0 ins; 0 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/28980.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28980/head:pull/28980 PR: https://git.openjdk.org/jdk/pull/28980 From swen at openjdk.org Wed Dec 24 09:01:46 2025 From: swen at openjdk.org (Shaojin Wen) Date: Wed, 24 Dec 2025 09:01:46 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v5] 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 incrementally with one additional commit since the last revision: fix merge error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22942/files - new: https://git.openjdk.org/jdk/pull/22942/files/bcb7d4be..9d2e6269 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=03-04 Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 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 jbhateja at openjdk.org Wed Dec 24 09:17:57 2025 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 24 Dec 2025 09:17:57 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <4o-mRvCoV4nHqDouamLFsjYVVHhSuAOurJipQmy3xo8=.08cbadfa-ebdf-4c6b-a7f3-efe808f82b92@github.com> On Mon, 22 Dec 2025 16:28:45 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 gener... > > Bhavana Kilambi has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Common IR changes looks good to me, adding some minor comments. test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 81: > 79: if(!expected_fp16.equals(actual_fp16)) { > 80: throw new AssertionError("Result Mismatch!, reduction type = " + reductionFunc + " actual = " + actual_fp16 + " expected = " + expected_fp16); > 81: } Please use Verify.checkEQ, Float16 support has been added to [Verifier](https://github.com/openjdk/jdk/pull/28095) recently test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 323: > 321: short result = (short) 0; > 322: for (int i = 0; i < vectorDim; i++) { > 323: result = float16ToRawShortBits(Float16.add(Float16.shortBitsToFloat16(result), Float16.shortBitsToFloat16(vector1[i]))); Float16 class is statically imported, we don't need fully qualified names here. Suggestion: result = float16ToRawShortBits(Float16.add(shortBitsToFloat16(result), shortBitsToFloat16(vector1[i]))); test/micro/org/openjdk/bench/jdk/incubator/vector/Float16OperationsBenchmark.java line 332: > 330: short result = floatToFloat16(1.0f); > 331: for (int i = 0; i < vectorDim; i++) { > 332: result = float16ToRawShortBits(Float16.multiply(Float16.shortBitsToFloat16(result), Float16.shortBitsToFloat16(vector1[i]))); Suggestion: result = float16ToRawShortBits(Float16.multiply(shortBitsToFloat16(result), shortBitsToFloat16(vector1[i]))); ------------- PR Review: https://git.openjdk.org/jdk/pull/27526#pullrequestreview-3610393442 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2645201339 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2645214816 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2645216202 From nbenalla at openjdk.org Wed Dec 24 14:50:56 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 24 Dec 2025 14:50:56 GMT Subject: RFR: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 [v2] In-Reply-To: References: Message-ID: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28945/files - new: https://git.openjdk.org/jdk/pull/28945/files/cdf8e3e9..cdf8e3e9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28945&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28945.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28945/head:pull/28945 PR: https://git.openjdk.org/jdk/pull/28945 From nbenalla at openjdk.org Wed Dec 24 14:50:57 2025 From: nbenalla at openjdk.org (Nizar Benalla) Date: Wed, 24 Dec 2025 14:50:57 GMT Subject: Integrated: 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 In-Reply-To: References: Message-ID: On Sun, 21 Dec 2025 14:06:00 GMT, Nizar Benalla wrote: > The test no longer needs to be problem listed now that the symbol information has caught up and is up to date. > This PR has a dependency on https://github.com/openjdk/jdk/pull/28944, I want them integrate them in order. This pull request has now been integrated. Changeset: 98b7792a Author: Nizar Benalla URL: https://git.openjdk.org/jdk/commit/98b7792a072380978b09fda4ec194f333d2ce7e3 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod 8372801: tools/sincechecker/modules/java.base/JavaBaseCheckSince.java fails with JDK 27 Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/28945 From dl at openjdk.org Wed Dec 24 19:21:39 2025 From: dl at openjdk.org (Doug Lea) Date: Wed, 24 Dec 2025 19:21:39 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v16] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: > Changes signal filtering to avoid possible starvation 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 21 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - recheck avoiding cross-class offsets - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check reworked ordering control - Merge branch 'openjdk:master' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Check diagnosis - Avoid double-filtering - Merge branch 'openjdk:master' into JDK-8373118 - ... and 11 more: https://git.openjdk.org/jdk/compare/67220f08...228ec84d ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/e73e127e..228ec84d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=14-15 Stats: 171 lines in 8 files changed: 66 ins; 46 del; 59 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 duke at openjdk.org Thu Dec 25 01:13:18 2025 From: duke at openjdk.org (eunbin son) Date: Thu, 25 Dec 2025 01:13:18 GMT Subject: RFR: 8374342: Remove incorrect @throws NoSuchFileException from FileUtils.java Message-ID: ### Summary Remove incorrect @throws documentation from FileUtils.deleteFileIfExistsWithRetry. ### Description The method documentation states that no exception is thrown if the file does not exist. The implementation checks file existence before deletion and does not throw NoSuchFileException in this case. This change removes the contradictory @throws clause. No behavior is changed. ### Bug ID : JDK-8374342 https://bugs.java.com/bugdatabase/view_bug?bug_id=8374342 ------------- Commit messages: - 8374342: Remove incorrect @throws NoSuchFileException from FileUtils.java Changes: https://git.openjdk.org/jdk/pull/28985/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28985&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374342 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28985.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28985/head:pull/28985 PR: https://git.openjdk.org/jdk/pull/28985 From swen at openjdk.org Thu Dec 25 02:01:31 2025 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 25 Dec 2025 02:01:31 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v6] 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 24 commits: - Merge remote-tracking branch 'upstream/master' into optim_to_hex_202501 - fix merge error - Merge branch 'master' into optim_to_hex_202501 - 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 - ... and 14 more: https://git.openjdk.org/jdk/compare/73a8629c...d896e365 ------------- Changes: https://git.openjdk.org/jdk/pull/22942/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=05 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 shaojin.wensj at alibaba-inc.com Thu Dec 25 07:01:55 2025 From: shaojin.wensj at alibaba-inc.com (wenshao) Date: Thu, 25 Dec 2025 15:01:55 +0800 Subject: =?UTF-8?B?QU9UU2FmZUNsYXNzSW5pdGlhbGl6ZXIgdG8gRGVjaW1hbERpZ2l0cyAmIEhleERpZ2l0cw==?= Message-ID: Both DecimalDigits and HexDigits have an array that needs to be pre-computed; this can be addressed by adding @AOTSafeClassInitializer. - Shaojin Wen -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Thu Dec 25 08:43:10 2025 From: duke at openjdk.org (duke) Date: Thu, 25 Dec 2025 08:43:10 GMT Subject: Withdrawn: 8357272: Add overrides for all default methods to wrapper collections In-Reply-To: References: Message-ID: On Wed, 28 May 2025 03:03:45 GMT, Stuart Marks wrote: > This mostly just adds overrides to the wrapper implementations in java.util.Collections. However, in order to satisfy the test, some overrides are also added to ReverseOrderSortedMapView, which is used by the SortedMap wrapper keySet, values, and entrySet views. These overrides don't do anything except to call super, so they're arguably dead code. However, they enable all combinations of sequenced map views to be tested, which is valuable. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25478 From serb at openjdk.org Fri Dec 26 00:52:31 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Dec 2025 00:52:31 GMT Subject: RFR: 8374363: Update copyright year to 2025 for test/micro in files where it was missed Message-ID: The copyright year in "test/micro" files updated in 2025 has been bumped to 2025. **Note:** I have skipped all files updated by the https://github.com/openjdk/jdk/commit/beb43e2633900bb9ab3c975376fe5860b6d054e0 The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374363: Update copyright year to 2025 for test/micro in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28995/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28995&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374363 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/28995.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28995/head:pull/28995 PR: https://git.openjdk.org/jdk/pull/28995 From syan at openjdk.org Fri Dec 26 02:24:39 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 02:24:39 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable Message-ID: Hi all, Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. Change has been verified locally. Test-fix only, no risk. ------------- Commit messages: - 8374364: TestCgroupMetrics.java fails when docker service unavailable Changes: https://git.openjdk.org/jdk/pull/28996/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374364 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From jiefu at openjdk.org Fri Dec 26 03:05:58 2025 From: jiefu at openjdk.org (Jie Fu) Date: Fri, 26 Dec 2025 03:05:58 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 02:17:10 GMT, SendaoYan wrote: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. > > Change has been verified locally. Test-fix only, no risk. So `MetricsTester.main(args)` requires the docker service, right? Maybe it would be better to add this check in a place like`MetricsTester`, where it requires docker service directly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3691978718 From serb at openjdk.org Fri Dec 26 03:18:25 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Fri, 26 Dec 2025 03:18:25 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Message-ID: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Changes: https://git.openjdk.org/jdk/pull/28997/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28997&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374365 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/28997.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28997/head:pull/28997 PR: https://git.openjdk.org/jdk/pull/28997 From syan at openjdk.org Fri Dec 26 06:05:49 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 06:05:49 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable In-Reply-To: References: Message-ID: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com> On Fri, 26 Dec 2025 03:02:56 GMT, Jie Fu wrote: > So `MetricsTester.main(args)` requires the docker service, right? > > Maybe it would be better to add this check in a place like`MetricsTester`, where it requires docker service directly. Only jdk/internal/platform/cgroup/TestCgroupMetrics.java observed fails when docker service unavailable. There are total two tests invoke MetricsTester. The other test jdk/internal/platform/docker/TestSystemMetrics.java already call `DockerTestUtils.checkCanTestDocker()` [before start test](https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/internal/platform/docker/TestSystemMetrics.java#L45). So i think it's better to leave this check inside test, same like to jdk/internal/platform/docker/TestSystemMetrics.java. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692198076 From jiefu at openjdk.org Fri Dec 26 06:17:50 2025 From: jiefu at openjdk.org (Jie Fu) Date: Fri, 26 Dec 2025 06:17:50 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable In-Reply-To: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com> References: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com> Message-ID: On Fri, 26 Dec 2025 06:02:09 GMT, SendaoYan wrote: > So i think it's better to leave this check inside test, same like to jdk/internal/platform/docker/TestSystemMetrics.java. I don't think so. Just imagine someone may call `MetricsTester.main(args)` again in the future, how can you prevent him/her not forgetting adding the check before the call? That's why I would suggest adding it in the place where it requires docker directly, not the place indirectly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692221565 From syan at openjdk.org Fri Dec 26 06:44:38 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 06:44:38 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable [v2] In-Reply-To: References: Message-ID: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with two additional commits since the last revision: - Fix year - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/9411a6e7..fe094b55 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=00-01 Stats: 6 lines in 2 files changed: 2 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From syan at openjdk.org Fri Dec 26 06:44:38 2025 From: syan at openjdk.org (SendaoYan) Date: Fri, 26 Dec 2025 06:44:38 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable In-Reply-To: References: <8lTS6szgRbmyZAgHYTTAuE7NqTFOQGIacSPgd7pI2wU=.43a3ca3c-73b4-47e6-9a05-9b3dc1d8d8f2@github.com> Message-ID: On Fri, 26 Dec 2025 06:15:21 GMT, Jie Fu wrote: > That's why I would suggest adding it in the place where it requires docker directly, not the place indirectly. Fixed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3692264918 From jiefu at openjdk.org Fri Dec 26 07:13:50 2025 From: jiefu at openjdk.org (Jie Fu) Date: Fri, 26 Dec 2025 07:13:50 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when docker service unavailable [v2] In-Reply-To: References: Message-ID: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> On Fri, 26 Dec 2025 06:44:38 GMT, SendaoYan wrote: >> Hi all, >> >> Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. >> >> Change has been verified locally. Test-fix only, no risk. > > SendaoYan has updated the pull request incrementally with two additional commits since the last revision: > > - Fix year > - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86: > 84: > 85: public static void main(String[] args) throws Exception { > 86: DockerTestUtils.checkCanTestDocker(); Thanks for the update. Can you explain why here requires docker service directly? >From the logs in JBS, I guess the places should be where the following docker files are required? Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2647686625 From epeter at openjdk.org Fri Dec 26 11:13:11 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 26 Dec 2025 11:13:11 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 03:01:39 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 incrementally with one additional commit since the last revision: > > Refine code comments I'll review this again in early January, once I'm back from Christnas/New Year break ;) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3692708993 From epeter at openjdk.org Fri Dec 26 11:13:13 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 26 Dec 2025 11:13:13 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: <113AdKQ15cNGhCreLhNcnBjkOMh8riqUR8TnUCDKBPM=.7ec93b7a-6433-461c-8b61-93d360f7d712@github.com> References: <113AdKQ15cNGhCreLhNcnBjkOMh8riqUR8TnUCDKBPM=.7ec93b7a-6433-461c-8b61-93d360f7d712@github.com> Message-ID: On Wed, 24 Dec 2025 07:12:59 GMT, Eric Fang wrote: >> 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? > > Hi @eme64 , I?d really appreciate hearing your thoughts on this when you have a moment. Honestly, I'd just make it an assert, if your code currently does not expect it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2648043826 From epeter at openjdk.org Fri Dec 26 11:18:58 2025 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 26 Dec 2025 11:18:58 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v5] In-Reply-To: References: <113AdKQ15cNGhCreLhNcnBjkOMh8riqUR8TnUCDKBPM=.7ec93b7a-6433-461c-8b61-93d360f7d712@github.com> Message-ID: On Fri, 26 Dec 2025 11:09:30 GMT, Emanuel Peter wrote: >> Hi @eme64 , I?d really appreciate hearing your thoughts on this when you have a moment. > > Honestly, I'd just make it an assert, if your code currently does not expect it. That will force us to look at the example that would eventually violate the assert, and evaluate the situation. Maybe it would reveal a bug (and we could catch and fix it). Maybe it is a new pattern that means we have to rethink things more widely. Or maybe we'd just convert it back to a condition, but at least at that point we'd have an example that takes the other branch. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2648050276 From phh at openjdk.org Fri Dec 26 21:23:56 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Dec 2025 21:23:56 GMT Subject: RFR: 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 06:39:57 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.jpackage" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done > ` Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28979#pullrequestreview-3613894327 From phh at openjdk.org Fri Dec 26 22:21:00 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Dec 2025 22:21:00 GMT Subject: RFR: 8374363: Update copyright year to 2025 for test/micro in files where it was missed In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 00:23:37 GMT, Sergey Bylokhov wrote: > The copyright year in "test/micro" files updated in 2025 has been bumped to 2025. > > **Note:** I have skipped all files updated by the https://github.com/openjdk/jdk/commit/beb43e2633900bb9ab3c975376fe5860b6d054e0 > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28995#pullrequestreview-3613921214 From phh at openjdk.org Fri Dec 26 22:58:54 2025 From: phh at openjdk.org (Paul Hohensee) Date: Fri, 26 Dec 2025 22:58:54 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by phh (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28997#pullrequestreview-3613936569 From serb at openjdk.org Sat Dec 27 04:49:10 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 04:49:10 GMT Subject: Integrated: 8374363: Update copyright year to 2025 for test/micro in files where it was missed In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 00:23:37 GMT, Sergey Bylokhov wrote: > The copyright year in "test/micro" files updated in 2025 has been bumped to 2025. > > **Note:** I have skipped all files updated by the https://github.com/openjdk/jdk/commit/beb43e2633900bb9ab3c975376fe5860b6d054e0 > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 5c694eab Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/5c694eab0f48045d2f71d0cd5ab53c1daddaa963 Stats: 15 lines in 15 files changed: 0 ins; 0 del; 15 mod 8374363: Update copyright year to 2025 for test/micro in files where it was missed Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk/pull/28995 From serb at openjdk.org Sat Dec 27 07:07:04 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:07:04 GMT Subject: Integrated: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 9512a43e Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/9512a43e82652be7294338c11cc9ffb0f0324b92 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod 8374365: Update copyright year to 2025 for test/jdk in files where it was missed Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk/pull/28997 From serb at openjdk.org Sat Dec 27 07:30:59 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:30:59 GMT Subject: RFR: 8374365: Update copyright year to 2025 for test/jdk in files where it was missed In-Reply-To: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> References: <3XiMyW7Xq6WvyuinujI9LA1o6pFarAX_W7wPqotSL00=.4dde8383-d1f8-4141-bc21-1923e1a4850f@github.com> Message-ID: On Fri, 26 Dec 2025 02:35:31 GMT, Sergey Bylokhov wrote: > The copyright year in "test/jdk" files updated in 2025 has been bumped to 2025. This covers all tests in test/jdk to avoid submitting additional PRs. > > **Note:** I have skipped some files updated by the: https://github.com/openjdk/jdk/commit/24a734938e5 and https://github.com/openjdk/jdk/commit/5e1cc082593 where files were renamed. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28997#issuecomment-3693789137 From serb at openjdk.org Sat Dec 27 07:40:58 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 07:40:58 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 00:16:59 GMT, Sergey Bylokhov wrote: > The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` I will update this PR to include all changes in src/hotspot and test/hotspot only. The rest will be done separately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28970#issuecomment-3693798808 From serb at openjdk.org Sat Dec 27 08:27:48 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Sat, 27 Dec 2025 08:27:48 GMT Subject: RFR: 8374316: Update copyright year to 2025 for hotspot in files where it was missed [v2] In-Reply-To: References: Message-ID: <1PnVxFvQfC9jvy7jFAVnY-0nOLDWnqVC71iAAizAzWI=.389a28a8-1a6b-4a7e-a67f-cdcb62b4af23@github.com> > The copyright year in hotspot files updated in 2025 has been bumped to 2025. (to minimize... the patch...for now, all files modified by the commits in src/hotspot have been updated only.) > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Sergey Bylokhov 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: 8374316: Update copyright year to 2025 for hotspot in files where it was missed ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28970/files - new: https://git.openjdk.org/jdk/pull/28970/files/e4855247..12ba39f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28970&range=00-01 Stats: 222 lines in 222 files changed: 0 ins; 0 del; 222 mod Patch: https://git.openjdk.org/jdk/pull/28970.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28970/head:pull/28970 PR: https://git.openjdk.org/jdk/pull/28970 From vklang at openjdk.org Sun Dec 28 17:38:58 2025 From: vklang at openjdk.org (Viktor Klang) Date: Sun, 28 Dec 2025 17:38:58 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v16] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <3V5dzXxT3Z1kpxj4c96ait9widW_xRaE1FaN_94qM2I=.dfc60e7d-a8e6-4002-955d-002a9942e4ea@github.com> On Wed, 24 Dec 2025 19:21:39 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > 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 21 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - recheck avoiding cross-class offsets > - Merge branch 'openjdk:master' into JDK-8373118 > - Merge branch 'openjdk:master' into JDK-8373118 > - Check reworked ordering control > - Merge branch 'openjdk:master' into JDK-8373118 > - Merge branch 'openjdk:master' into JDK-8373118 > - Check diagnosis > - Avoid double-filtering > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 11 more: https://git.openjdk.org/jdk/compare/67e1f04f...228ec84d src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1981: > 1979: if (src != qid) > 1980: w.source = src = qid; > 1981: w.topLevelExec(t, fifo); Given that topLevelExec is tiny, and only called from this line, it might be better to just inline it here, since we know that `t` is originally not-null here, we can defer the initial null-check to only apply to subsequent tasks: do { t.doExec(); } while ((t = w.nextLocalTask(fifo)) != null); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2649830703 From syan at openjdk.org Mon Dec 29 08:38:51 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:38:51 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v3] In-Reply-To: References: Message-ID: <_nWN7E-jJuR_2ZhDZdsSgfLWtlBpUI5R1qAxjOLx3yo=.eb153abc-a164-434e-96ac-4a892b79ac2f@github.com> > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the docker service is unavailable. The details shows in jbs issue. I think it's better to call `DockerTestUtils.checkCanTestDocker()` before run this test. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Check cpu period and cpuset avaialable before test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/fe094b55..1be8d17a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=01-02 Stats: 12 lines in 2 files changed: 7 ins; 2 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From syan at openjdk.org Mon Dec 29 08:40:56 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:40:56 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v2] In-Reply-To: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> References: <_2D9Y1xJlTBC5zsmbO4t00pm1Jdt7UmfYlbM8BwXhLM=.68ffa627-e415-49d1-8563-e9a04c2f126b@github.com> Message-ID: On Fri, 26 Dec 2025 07:10:03 GMT, Jie Fu wrote: >> SendaoYan has updated the pull request incrementally with two additional commits since the last revision: >> >> - Fix year >> - Move DockerTestUtils.checkCanTestDocker() inside MetricsTester > > test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 86: > >> 84: >> 85: public static void main(String[] args) throws Exception { >> 86: DockerTestUtils.checkCanTestDocker(); > > Thanks for the update. > > Can you explain why here requires docker service directly? > > From the logs in JBS, I guess the places should be where the following docker files are required? > > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_quota_us > Unable to open : /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.stat I think this test fails because the cpuset in unmounted. So I updated the JBS titile and comments. And I added check 'cpu period' and 'cpu set' available or not before subtest, rather than check the docker service. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2650463886 From syan at openjdk.org Mon Dec 29 08:48:15 2025 From: syan at openjdk.org (SendaoYan) Date: Mon, 29 Dec 2025 08:48:15 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: > Hi all, > > Test jdk/internal/platform/cgroup/TestCgroupMetrics.java report fails when the cpuset unmounted. The details shows in jbs issue. I think it's better to check the 'cpu period' or 'cpuset' available or not before run the releated tests. > > Change has been verified locally. Test-fix only, no risk. SendaoYan has updated the pull request incrementally with one additional commit since the last revision: Update copyright year for test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/1be8d17a..068b1591 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28996.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28996/head:pull/28996 PR: https://git.openjdk.org/jdk/pull/28996 From bkilambi at openjdk.org Mon Dec 29 17:39:42 2025 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 29 Dec 2025 17:39:42 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: > 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 ... Bhavana Kilambi 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: - Address review comments for the JTREG test and microbenchmark - Merge branch 'master' - Address review comments - Fix build failures on Mac - Address review comments - Merge 'master' - 8366444: Add support for add/mul reduction operations for Float16 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 mul reduction respectively. V1 (UseSVE = 1, max vector length = 32B): Benchmark vectorDim Mode Cnt 8B 16B 32B ReductionAddFP16 256 thrpt 9 1.11 1.75 2.02 ReductionAddFP16 512 thrpt 9 1.02 1.64 1.93 ReductionAddFP16 1024 thrpt 9 1.02 1.59 1.85 ReductionAddFP16 2048 thrpt 9 1.02 1.56 1.80 ReductionMulFP16 256 thrpt 9 1.12 0.99 1.09 ReductionMulFP16 512 thrpt 9 1.04 1.01 1.04 ReductionMulFP16 1024 thrpt 9 1.02 1.02 1.00 ReductionMulFP16 2048 thrpt 9 1.01 1.01 1.00 On V1, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be generated for AddReductionVHF/MulReductionVHF as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: scalarized "fmul" sequence is generated for MulReductionVHF and "fadda" is generated for AddReductionVHF which fetches signficant gains. For MaxVectorSize = 32: Autovectorization of MulReductionVHF is disabled for MaxVectorSize > 16B so the autovectorizer checks for maximal implemented size[1] which is 16B and generates scalarized "fmul" sequence for 16B in this case. For AddReductionVHF, it generates the "fadda" instruction. V2 (UseSVE = 2, max vector length = 16B) Benchmark vectorDim Mode Cnt 8B 16B ReductionAddFP16 256 thrpt 9 1.16 1.70 ReductionAddFP16 512 thrpt 9 1.02 1.61 ReductionAddFP16 1024 thrpt 9 1.01 1.53 ReductionAddFP16 2048 thrpt 9 1.00 1.49 ReductionMulFP16 256 thrpt 9 1.18 0.99 ReductionMulFP16 512 thrpt 9 1.04 1.01 ReductionMulFP16 1024 thrpt 9 1.02 1.02 ReductionMulFP16 2048 thrpt 9 1.01 1.01 On V2, for MaxVectorSize = 8: scalarized fadd/fmul sequence will be generated as UseSVE defaults to 0 [2]. For MaxVectorSize = 16: "fadda" instruction is generated for AddReductionVHF which results in significant gains in performance. For MulReductionVHF, the scalarized "fmul" sequence will be generated. Testing: hotspot_all, jdk(tiers1-3) and langtools(tier1) all pass on N1/V1/V2. [1] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/share/opto/superword.cpp#L1677 [2] https://github.com/openjdk/jdk/blob/a272696813f2e5e896ac9de9985246aaeb9d476c/src/hotspot/cpu/aarch64/vm_version_aarch64.cpp#L479 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27526/files - new: https://git.openjdk.org/jdk/pull/27526/files/21ad1c93..f2685b21 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27526&range=03-04 Stats: 7865 lines in 1198 files changed: 4087 ins; 1420 del; 2358 mod Patch: https://git.openjdk.org/jdk/pull/27526.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27526/head:pull/27526 PR: https://git.openjdk.org/jdk/pull/27526 From duke at openjdk.org Mon Dec 29 22:30:04 2025 From: duke at openjdk.org (duke) Date: Mon, 29 Dec 2025 22:30:04 GMT Subject: Withdrawn: 8370983: Add methods for primitive operators to support method handles In-Reply-To: References: Message-ID: <_2ZrP3CAbC65FSixdjIeItZgZqeufMHgq3jgPJw5ouQ=.b1d1a4f4-a1ed-4628-a766-f10e6e74a902@github.com> On Fri, 31 Oct 2025 04:55:31 GMT, Joe Darcy wrote: > Initial draft of a partial set of methods wrapping primitive operators to get feedback on the class providing this functionality. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28081 From serb at openjdk.org Tue Dec 30 07:05:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 07:05:02 GMT Subject: Integrated: 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 06:39:57 GMT, Sergey Bylokhov wrote: > The copyright year in "jdk.jpackage" files updated in 2025 has been bumped to 2025. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done > ` This pull request has now been integrated. Changeset: 08450f2c Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/08450f2c4d447c42a2ca8222d162ae3d2d25268a Stats: 13 lines in 13 files changed: 0 ins; 0 del; 13 mod 8374326: Update copyright year to 2025 for jdk.jpackage in files where it was missed Reviewed-by: phh ------------- PR: https://git.openjdk.org/jdk/pull/28979 From serb at openjdk.org Tue Dec 30 12:34:15 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 12:34:15 GMT Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed Message-ID: The copyright year in test/* files updated in 2025 has been bumped to 2025. Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - revert langtools/jdk/javadoc/doclet/testSourceTab/SingleTab - 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed. Changes: https://git.openjdk.org/jdk/pull/29006/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29006&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374383 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod Patch: https://git.openjdk.org/jdk/pull/29006.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29006/head:pull/29006 PR: https://git.openjdk.org/jdk/pull/29006 From aloraini.omar at gmail.com Tue Dec 30 19:20:02 2025 From: aloraini.omar at gmail.com (Omar Aloraini) Date: Tue, 30 Dec 2025 22:20:02 +0300 Subject: ScopeValue for Locale, Clock, ZoneId ... and others Message-ID: Many objects fit into the contextual data that needs to be passed between caller/callee whether they are part of the application code or between application and library. The current state is that frameworks such Spring define many "holder" classes which give access to the underlying object stored in a ThreadLocal (e.g. LocaleContextHolder). But could this be part of the JDK itself? I wish to write the following code: ``` Locale locale = Locale.VALUE.get() ... I also wish to avoid propagating the value every time: ``` getTranslation("key", locale) ``` If every framework has a different scopedvalue we are no better than where we started. Should every class define an instance of its ScopedValue as a field? or should we have a generic holder keyed by the Class object itself? Or should it be part of the ScopedValue API itself? ``` ScopedValue.get(Locale.class) ScopedValue.where(Locale.class, Locale.ENGLISH) ``` needless to say, for the highest payoff, this needs to be part of java.base. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serb at openjdk.org Tue Dec 30 20:18:34 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 20:18:34 GMT Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed Message-ID: The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year. The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` ------------- Commit messages: - 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed Changes: https://git.openjdk.org/jdk/pull/29008/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29008&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374391 Stats: 89 lines in 89 files changed: 0 ins; 0 del; 89 mod Patch: https://git.openjdk.org/jdk/pull/29008.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29008/head:pull/29008 PR: https://git.openjdk.org/jdk/pull/29008 From duke at openjdk.org Tue Dec 30 20:40:42 2025 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Tue, 30 Dec 2025 20:40:42 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v5] In-Reply-To: References: Message-ID: > The goal of the PR is to improve both, sequential and parallel, sorting of primitives. > > **The main achievements** > > - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n) > - improved mixed insertion sort (makes whole sorting faster) > - improved merging sort for almost sorted data > - optimized parallel sorting > - improved step for pivot candidates and pivot partitioning > - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError > - minor javadoc and comment changes > > - extended existing tests > - added tests for radix sort, heap sort, insertion sort > - added benchmarking JMH tests > - improved test coverage > > **The summary of benchmarking:** > > **Sequential sorting (Arrays.sort)** > > byte: up to 50% faster > char: 4-7 times faster > short: 2-6 times faster > int: 1.2-5 times faster > long: 1.2-5 times faster > float: 1.2-5 times faster > double: 1.2-4 times faster > > **Parallel sorting (Arrays.parallelSort)** > > int: 1.2-9 times faster > long: 1.2-9 times faster > float: 1.2-4 times faster > double: 1.2-4 times faster > > **AVX512 support** > > Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results. > > **High-level chart showing how the actual sorting algorithm is selected > based on parallel/sequential and input size** > > **int/long/float/double** > > if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort > if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort > if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort > if random data => two pivots quicksort, else => one pivot quicksort > > **byte** > > if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort > else => counting sort > > **char/short** > > if size > MIN_COUNTING_SORT_SIZE(640) => counting sort > if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort > if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort > if random data => two pivots quicksort, else => one pivot quicksort > > **parallel sorting (int/long/float/double)** > > if size < MIN_PARALLEL_SORT_SIZE(3K) => sequential sort > invoke parallel merge sort, depth depends on paral... Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision: JDK-8266431: Dual-Pivot Quicksort improvements * Improved merging sort * Created Sorting.template for testing ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27411/files - new: https://git.openjdk.org/jdk/pull/27411/files/013394a5..cec80653 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=03-04 Stats: 5018 lines in 6 files changed: 3251 ins; 652 del; 1115 mod Patch: https://git.openjdk.org/jdk/pull/27411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27411/head:pull/27411 PR: https://git.openjdk.org/jdk/pull/27411 From duke at openjdk.org Tue Dec 30 20:44:01 2025 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Tue, 30 Dec 2025 20:44:01 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v4] In-Reply-To: References: Message-ID: On Sun, 30 Nov 2025 21:55:35 GMT, Vladimir Yaroslavskiy wrote: >> The goal of the PR is to improve both, sequential and parallel, sorting of primitives. >> >> **The main achievements** >> >> - introduced Radix in parallel sorting which shows several times boost of performance and has linear complexity instead of n*ln(n) >> - improved mixed insertion sort (makes whole sorting faster) >> - improved merging sort for almost sorted data >> - optimized parallel sorting >> - improved step for pivot candidates and pivot partitioning >> - suggested better buffer allocation: if no memory, it is switched to in-place sorting with no OutOfMemoryError >> - minor javadoc and comment changes >> >> - extended existing tests >> - added tests for radix sort, heap sort, insertion sort >> - added benchmarking JMH tests >> - improved test coverage >> >> **The summary of benchmarking:** >> >> **Sequential sorting (Arrays.sort)** >> >> byte: up to 50% faster >> char: 4-7 times faster >> short: 2-6 times faster >> int: 1.2-5 times faster >> long: 1.2-5 times faster >> float: 1.2-5 times faster >> double: 1.2-4 times faster >> >> **Parallel sorting (Arrays.parallelSort)** >> >> int: 1.2-9 times faster >> long: 1.2-9 times faster >> float: 1.2-4 times faster >> double: 1.2-4 times faster >> >> **AVX512 support** >> >> Vamsi Parasa suggested faster sort routines by taking advantage of AVX512 instructions, see https://github.com/openjdk/jdk/pull/14227, sources of sorting were modified. Therefore, I performed benchmarking of the final version (which includes optimizations by Vamsi Parasa and optimizations from my side) on a server with CPUs supported AVX512 instructions, no regression of performance was found, see detailed benchmarking results. >> >> **High-level chart showing how the actual sorting algorithm is selected >> based on parallel/sequential and input size** >> >> **int/long/float/double** >> >> if size < MAX_INSERTION_SORT_SIZE(=51) => [ mixed ] insertion sort >> if array is almost sorted and size > MIN_MERGING_SORT_SIZE(=512) => merging sort >> if recursion depth > MAX_RECURSION_DEPTH(=64) => heap sort >> if random data => two pivots quicksort, else => one pivot quicksort >> >> **byte** >> >> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort >> else => counting sort >> >> **char/short** >> >> if size > MIN_COUNTING_SORT_SIZE(640) => counting sort >> if size < MAX_INSERTION_SORT_SIZE(=51) => insertion sort >> if recursion depth > MAX_RECURSION_DEPTH(=64) => counting sort >> if random data => two pivots quicksort, else => one pivot quicksort >> >> **parallel sorting (int/lo... > > Vladimir Yaroslavskiy has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8266431: Dual-Pivot Quicksort improvements > > * Improved mixed insertion sort > * Created DualPivotQuicksort template > * Added descitpion of sorting logic Hi team, I created a code template for Sorting.java to test the correctness of DualPivotQuicksort. Also merging sort was a little bit improved. I checked the idea of multiple counter arrays, but haven't found speedup of sorting. @DougLea Doug Lea @jatin-bhateja, @jbhateja Jatin Bhateja @tarsa Piotr Tarsa Please look at the latest changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3700524951 From serb at openjdk.org Tue Dec 30 23:09:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Tue, 30 Dec 2025 23:09:05 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Looking for volunteers to review this patch. It cannot be integrated in 2026. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700774950 From joe.darcy at oracle.com Tue Dec 30 23:34:12 2025 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Tue, 30 Dec 2025 15:34:12 -0800 Subject: Improving performance of the default implementation of java.lang.Math.fma In-Reply-To: References: Message-ID: <3fbff499-9c82-45dc-81f5-7483ced08465@oracle.com> On 12/23/2025 2:40 AM, Raffaello Giulietti wrote: > Hi, > > both Math.fma() variants are annotated with @IntrinsicCandidate. This means that, in compiled machine code, the methods get replaced by a platform specific optimised instruction sequence, possibly just a single hardware instruction. At least for some mathematical methods, the instrinsic version is used by the HotSpot interpreter too. Therefore, since most-to-all commercially relevant architectures include fma instructions now, the software implementation of fma may never be used on those platforms, even when running in the interpreter. I think a quote by Tony Hoare from "The emperor's old clothes" is relevant here: "I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." The float and double fma implementation using BigDecimal are intentionally going for the "obviously no?deficiencies" approach. I think developing a more direct software implementation of float and/or double fma would be useful if and only if there was an architecture of interest that didn't provide that hardware primitive. Any such effort would need to include a much more thorough set of regression tests than those currently used for {Math, StrictMath}.fma. -Joe > > While your proposal seems to be more efficient than the current Java code, it suffers from some drawbacks: > * The methods are far less readable (and maintainable) than the current simple Java implementations. > * Being more convoluted, they require extensive review time to make sure they are 100% correct. > * They only benefit interpreted code, that is, code that is rarely executed. In normal circumstances, hot code does not execute the Java version. > All in all, given the combination of the above, I'm not sure that a review effort would benefit the general public. > > Also, your claim about improved efficiency should be substantiated by JMH results (https://github.com/openjdk/jmh) to convince this audience. > > Greetings > Raffaello > > > ________________________________________ > From: core-libs-dev on behalf of John Platts > Sent: Sunday, December 21, 2025 06:12 > To: core-libs-dev at openjdk.org > Subject: Improving performance of the default implementation of java.lang.Math.fma > > There is a much better way to implement java.lang.Math.fma(double, double, double) than the current default implementation in src/java.base/share/classes/java/lang/Math.java. > > Here is a much better implementation of java.lang.Math.fma (and this has been shown to be much faster than (new BigDecimal(a)).multiply(new BigDecimal(b)).add(new BigDecimal(c)).doubleValue() if a, b, and c are all finite floating-point values through benchmarking): > private static double scalbFiniteF64Sum(double hi, double lo, int exp) { > // Both hi and lo should be finite, and |hi| >= |lo| should be true if > // hi != 0.0 > > final double sum0 = hi + lo; > final double scaleResult0 = Math.scalb(sum0, exp); > if (!(Math.abs(scaleResult0) <= Double.MIN_NORMAL) || lo == 0.0) { > // If |scaleResult0| > Double.MIN_NORMAL or lo == 0.0, then > // scaleResult0 will be correctly rounded. > > // Return scaleResult0 in this case. > > return scaleResult0; > } > > // scaleResult1 is equal to scaleResult0 with its ULP bit cleared. > // This ensures that the final result will be correctly rounded if > // the ULP bit of scaleResult0 is set. > final double scaleResult1 = Double.longBitsToDouble( > Double.doubleToRawLongBits(scaleResult0) & (-2L)); > > // scaleErr is equal to the error of scaling sum0 by 2**exp, scaled back > // up by 2**-exp. scaleResult1 is used to compute scaleErr to ensure > // that the value of the ULP bit of scaleResult0, scaled up by 2**-exp, > // is included in scaleErr to ensure that the final result is correctly > // rounded. > final double scaleErr = sum0 - Math.scalb(scaleResult1, -exp); > > // err0 is equal to the error of hi + lo > final double err0 = (hi - sum0) + lo; > > // Compute scaleErr + err0 using the Fast2Sum algorithm as > // |scaleErr| >= |err0| should be true if |scaleErr| > 0 > final double sum1 = scaleErr + err0; > final double err1 = (scaleErr - sum1) + err0; > > final long sum1Bits = Double.doubleToRawLongBits(sum1); > final long err1Bits = Double.doubleToRawLongBits(err1); > final long sum1IsInexactInSignBit = err1Bits > ^ (err1Bits + 0x7FFF_FFFF_FFFF_FFFFL); > > // roundedToOddSum1 is equal to the rounded to odd sum of scaleErr and > // err0 > final double roundedToOddSum1 = Double.longBitsToDouble((sum1Bits > + (((sum1Bits ^ err1Bits) & sum1IsInexactInSignBit) >> 63)) > | (sum1IsInexactInSignBit >>> 63)); > > // scaleResult2 is equal to the correctly rounded value of > // (hi + lo) * 2**exp > final double scaleResult2 = scaleResult1 > + Math.scalb(roundedToOddSum1, exp); > > return scaleResult2; > } > > public static double fma(double a, double b, double c) { > final long aBits = Double.doubleToRawLongBits(a); > final long bBits = Double.doubleToRawLongBits(b); > final long cBits = Double.doubleToRawLongBits(c); > > final int aBiasedExp = (int) (aBits >>> 52) & 0x7FF; > final int bBiasedExp = (int) (bBits >>> 52) & 0x7FF; > final int cBiasedExp = (int) (cBits >>> 52) & 0x7FF; > > if (((aBits ^ (aBits - 1)) | (bBits ^ (bBits - 1)) > | (cBits ^ (cBits - 1)) | (0x7FE - aBiasedExp) > | (0x7FE - bBiasedExp)) < 0) { > // If at least one of a, b, or c are zero or at least one of a or b > // is non-finite, the result will be equal to a * b + c. > return a * b + c; > } else if (cBiasedExp == 0x7FF) { > // If a and b are both nonzero finite numbers and c is a non-finite > // value, simply return c since the exact result of a * b + c will > // be equal to c in this case. > return c; > } > > // a, b, and c are all nonzero finite values at this point > > // Normalize a and b to normal floating-point numbers > > final int aIsDenormalMask = (aBiasedExp - 1) >> 31; > final int bIsDenormalMask = (bBiasedExp - 1) >> 31; > > final long aNormalizeAdjBits = (aBits & 0x8000_0000_0000_0000L) > | (aIsDenormalMask & 0x0350_0000_0000_0000L); > final long bNormalizeAdjBits = (bBits & 0x8000_0000_0000_0000L) > | (bIsDenormalMask & 0x0350_0000_0000_0000L); > > final double normalizedA = > Double.longBitsToDouble(aBits | aNormalizeAdjBits) > - Double.longBitsToDouble(aNormalizeAdjBits); > final double normalizedB = > Double.longBitsToDouble(bBits | bNormalizeAdjBits) > - Double.longBitsToDouble(bNormalizeAdjBits); > > // If a is a denormal number, normalizedA is equal to a * 2**52. > // Otherwise, if a is already a normal number, normalizedA is equal to > // a. > > // If b is a denormal number, normalizedB is equal to b * 2**52. > // Otherwise, if b is already a normal number, normalizedB is equal to > // b. > > final long normalizedABits = Double.doubleToRawLongBits(normalizedA); > final long normalizedBBits = Double.doubleToRawLongBits(normalizedB); > > final int normalizedABiasedExp = (int) (normalizedABits >>> 52) & 0x7FF; > final int normalizedBBiasedExp = (int) (normalizedBBits >>> 52) & 0x7FF; > > // minPBiasedExp is the smallest possible biased exponent (with an > // exponent bias of 1023) of the exact value of a * b. > final int minPBiasedExp = normalizedABiasedExp + normalizedBBiasedExp > + (aIsDenormalMask & -52) + (bIsDenormalMask & -52) + -1023; > > if (minPBiasedExp >= 2048) { > // If minPBiasedExp >= 2048, then a * b + c is known to overflow to > // infinity. Return a * b + c in this case. > return a * b + c; > } > > // Normalize c to a normal floating-point number > > final int cIsDenormalMask = (cBiasedExp - 1) >> 31; > > final long cNormalizeAdjBits = (cBits & 0x8000_0000_0000_0000L) > | (cIsDenormalMask & 0x0350_0000_0000_0000L); > > final double normalizedC = > Double.longBitsToDouble(cBits | cNormalizeAdjBits) > - Double.longBitsToDouble(cNormalizeAdjBits); > > // If c is a denormal number, normalizedC is equal to c * 2**52. > // Otherwise, if c is already a normal number, normalizedC is equal to > // c. > > final long normalizedCBits = Double.doubleToRawLongBits(normalizedC); > final int normalizedCBiasedExp = (int) (normalizedCBits >>> 52) & 0x7FF; > > final int adjCBiasedExp = normalizedCBiasedExp > + (cIsDenormalMask & -52); > > // adjCBiasedExp is equal to floor(log2(|c|)) + 1023, even if c is a > // denormal number > > final int expDiff = adjCBiasedExp - minPBiasedExp; > if (expDiff >= 55) { > // If expDiff is greater than or equal to 55, the exact value of > // |a * b| is less than 0.5 * ulp(c). The correctly rounded result > // of a * b + c is known to be equal to c in this case. Return c in > // this case as the exact value of |a * b| is too small to affect > // the correctly rounded result of a * b + c. > > return c; > } > > // aMant is equal to the mantissa of a, with 1 <= |a| < 2 > // bMant is equal to the mantissa of b, with 1 <= |b| < 2 > final double aMant = > Double.longBitsToDouble(((normalizedABits | 0x3FF0_0000_0000_0000L) > & 0xBFFF_FFFF_FFFF_FFFFL)); > final double bMant = > Double.longBitsToDouble(((normalizedBBits | 0x3FF0_0000_0000_0000L) > & 0xBFFF_FFFF_FFFF_FFFFL)); > > // Split aMant and bMant using Veltkamp-Dekker splitting > final double aMantGamma = aMant * 134217729.0; > final double bMantGamma = bMant * 134217729.0; > > final double aMantHi = aMantGamma + (aMant - aMantGamma); > final double bMantHi = bMantGamma + (bMant - bMantGamma); > > final double aMantLo = aMant - aMantHi; > final double bMantLo = bMant - bMantHi; > > final double pHi = aMant * bMant; > final double pLo = ((aMantHi * bMantHi - pHi) > + (aMantHi * bMantLo + aMantLo * bMantHi)) + aMantLo * bMantLo; > > if (minPBiasedExp >= 1 && pLo == 0.0) { > // If minPBiasedExp >= 1 and pLo == 0.0 are both true, then a * b is > // known to be exact and normal. Return a * b + c in this case. > > return a * b + c; > } > > final int resultScaleUpExp = minPBiasedExp - 1023; > > if (expDiff <= -106) { > // If expDiff <= -106 is true, then |a * b| >= 2**-968 must be true > // since 2**-1074 <= |c| < 2**-105 * |a * b|. > > if (pLo == 0.0) { > // If expDiff <= -106 and pLo == 0.0 are both true, then |c| > // is too small to affect the correctly rounded result. > > // Return a * b in this case since a * b is known to be either > // an exact normal finite number or infinity and as |c| is too > // small to affect the result of a * b + c. > return a * b; > } else { > // If expDiff <= -106 and pLo != 0.0 are both true, then > // 0 < |c * 2**-resultScaleUpExp| < 0.5 * ulp(pLo) is known > // to be true. > > // In this case, the rounded to odd sum of pLo and > // c * 2**-resultScaleUpExp can be computed by decrementing > // pLoBits by 1 if pLoBits and cBits have different signs > // rounded to odd sum of pLo and c * 2**-resultScaleUpExp > // can be computed by simply decrementing pLoBits by 1 if pLo > // and c have different signs followed by setting the LSB bit as > // in this case. > > final long pLoBits = Double.doubleToRawLongBits(pLo); > > // roundedToOddLoSum is equal to the rounded to odd sum of > // pLo and c * 2**-resultScaleUpExp > final double roundedToOddLoSum = Double.longBitsToDouble( > (pLoBits + ((pLoBits ^ cBits) >> 63)) | 1L); > > // Return the correctly rounded value of > // (s1 + roundedToOddLoSum) * 2**resultScaleUpExp > return scalbFiniteF64Sum(pHi, roundedToOddLoSum, > resultScaleUpExp); > } > } > > // -105 <= expDiff <= 54 is now true at this point > > final double scaledC = > Double.longBitsToDouble(((normalizedCBits | 0x3FF0_0000_0000_0000L) > & 0xBFFF_FFFF_FFFF_FFFFL) + ((long) expDiff << 52)); > > // Compute pLo + scaledC using the 2Sum algorithm > > final double s0 = pLo + scaledC; > final double v0 = s0 - pLo; > final double e0 = (pLo - (s0 - v0)) + (scaledC - v0); > > // s0 + e0 == pLo + scaledC > > // Compute pHi + s0 using the 2Sum algorithm > > final double s1 = pHi + s0; > final double v1 = s1 - pHi; > final double e1 = (pHi - (s1 - v1)) + (s0 - v1); > > // s1 + e1 + e0 == pHi + pLo + scaledC > > // Compute the rounded to odd sum of e1 and e0 to ensure that the final > // result is correctly rounded. > > // Fast2Sum is sufficient for computing e1 + e0 as either |e1| == 0.0 or > // |e1| >= |e0| should be true > > final double s2 = e1 + e0; > final double e2 = (e1 - s2) + e0; > > // s1 + s2 + e2 == pHi + pLo + scaledC > > final long s2Bits = Double.doubleToRawLongBits(s2); > final long e2Bits = Double.doubleToRawLongBits(e2); > final long s2IsInexactInSignBit = e2Bits > ^ (e2Bits + 0x7FFF_FFFF_FFFF_FFFFL); > > // roundedToOddS2 is equal to the rounded to odd sum of e1 and e0 and > // is used to ensure that the final result is correctly rounded > final double roundedToOddS2 = Double.longBitsToDouble( > (s2Bits + (((s2Bits ^ e2Bits) & s2IsInexactInSignBit) >> 63)) > | (s2IsInexactInSignBit >>> 63)); > > // Return the correctly rounded value of > // (s1 + roundedToOddS2) * 2**resultScaleUpExp > return scalbFiniteF64Sum(s1, roundedToOddS2, resultScaleUpExp); > } > > There are a few tricks up the sleeve with the above implementation. > > If xBits is the result of Double.doubleToRawLongBits(x): > xBits ^ (xBits - 1) is equal to -1 if and only if x == 0 or x == -0 and is non-negative otherwise > xBits ^ (xBits + 0x7FFF_FFFF_FFFF_FFFFL) is negative if and only if x != 0 and equal to Long.MAX_VALUE if x == 0 > > The rounded to odd result of a + b is used in a few places in the above implementation of fma to ensure that the final sum is correctly rounded. From liach at openjdk.org Wed Dec 31 00:20:54 2025 From: liach at openjdk.org (Chen Liang) Date: Wed, 31 Dec 2025 00:20:54 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700907244 From serb at openjdk.org Wed Dec 31 00:52:02 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 00:52:02 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 00:18:14 GMT, Chen Liang wrote: > Unfortunately many of our reviewers are on their winter break. You might consider proposing such prs in early December in the future. Yeah, usually [magicus](https://github.com/openjdk/jdk/pull/22642) updates those files, but for some reason this year updates were missing, so I decided to pick them up. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3700942964 From jpai at openjdk.org Wed Dec 31 01:32:52 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 01:32:52 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Hello Sergey, > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done What is that command expected to return as output? I ran that on top of this PR and I don't see any output. It completes normally without any error. I'm on macos. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701057533 From jpai at openjdk.org Wed Dec 31 01:49:51 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 01:49:51 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: <1W3A16ibXOMrTbXRCkTywPfLx2l0Lm9Pxe2_aJft9Zc=.95756c42-e9a3-498e-b99c-7111af17b18b@github.com> On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Looking at some other similar PRs that were open, I even tried the following command that was noted in one of them: git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done Even this one doesn't generate any output for me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701127162 From serb at openjdk.org Wed Dec 31 02:16:01 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 02:16:01 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` The first command checks the files changed in the last commit of the PR and verifies whether each file has any commit history since January 1, 2025. If not, it prints "NOT IN 2025". `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` The disadvantage of the first command is that it depends on a specific commit. The second command avoids this by comparing the current PR against master and using that diff as the list of changed files. To test the second command, modify and commit a file in the PR branch that has not been modified in 2025. The script will flag it as "NOT IN 2025", because this PR is expected to change only files that already have commits on master in 2025. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701263133 From jpai at openjdk.org Wed Dec 31 04:41:57 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 04:41:57 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` Marked as reviewed by jpai (Reviewer). Thank you for that detail, I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. The changes look good to me. ------------- PR Review: https://git.openjdk.org/jdk/pull/28980#pullrequestreview-3620237303 PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701430051 From jpai at openjdk.org Wed Dec 31 04:52:50 2025 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 31 Dec 2025 04:52:50 GMT Subject: RFR: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov wrote: > The copyright year in test/* files updated in 2025 has been bumped to 2025. > > Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Looks OK to me. I did a trivial verification that the files updated in this PR were indeed updated in 2025. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29006#pullrequestreview-3620246101 From erfang at openjdk.org Wed Dec 31 05:02:51 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 31 Dec 2025 05:02:51 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v7] 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: Convert the check condition for vector length into an assertion Also refined the tests. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28313/files - new: https://git.openjdk.org/jdk/pull/28313/files/2ce36c8d..8c29c902 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=05-06 Stats: 92 lines in 2 files changed: 13 ins; 5 del; 74 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 Wed Dec 31 05:05:52 2025 From: erfang at openjdk.org (Eric Fang) Date: Wed, 31 Dec 2025 05:05:52 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: On Fri, 26 Dec 2025 11:10:07 GMT, Emanuel Peter wrote: > I'll review this again in early January, once I'm back from Christnas/New Year break ;) Cool, no hurry, thanks for your review and happy Christmas/New Year! @eme64 @jatin-bhateja @XiaohongGong ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3701452219 From serb at openjdk.org Wed Dec 31 09:17:07 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 09:17:07 GMT Subject: Integrated: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:21:19 GMT, Sergey Bylokhov wrote: > This patch updates the remaining files in java.base that were not covered by other recent PRs related to copyright updates. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff HEAD~1 --name-only | while read f; do git log HEAD~1 --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done ` This pull request has now been integrated. Changeset: 36d2c277 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/36d2c277c47767ba22208e2e49c46001642bd4f5 Stats: 80 lines in 80 files changed: 0 ins; 0 del; 80 mod 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/28980 From alanb at openjdk.org Wed Dec 31 09:25:13 2025 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 31 Dec 2025 09:25:13 GMT Subject: RFR: 8374327: Update copyright year to 2025 for files in java.base added/updated by commits in 2025 In-Reply-To: References: Message-ID: <_66pqVpeNUXYUPpnX4X56yihxoBpaIll4RdsJAUCSGo=.6b4217ed-c69a-4738-a719-3860c0ec212e@github.com> On Wed, 31 Dec 2025 04:38:43 GMT, Jaikiran Pai wrote: > I used a slightly different way to verify that the files changed in this PR were indeed updated in 2025. There's a handful of files that were last updated in Dec 2024 via PRs that were in progress at the time. The "/integrate" happened in early Jan 2025 so it looks like the files were updated in 2025. Probably happens every year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28980#issuecomment-3701814018 From duke at openjdk.org Wed Dec 31 09:38:10 2025 From: duke at openjdk.org (Eunbin Son) Date: Wed, 31 Dec 2025 09:38:10 GMT Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor error messages for better clarity [v2] In-Reply-To: References: Message-ID: > ### Summary > MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)". > > This addresses the first of three issues in JDK-8374395. > > ### Description > When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this. > > toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged. > > Added test cases to the existing jtreg test file. All tests pass. > > ### Bug-ID : JDK-8374395 > https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395 Eunbin Son has updated the pull request incrementally with one additional commit since the last revision: 8374395: Add JUnit test for MemoryUsage.toString() undefined values ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29009/files - new: https://git.openjdk.org/jdk/pull/29009/files/479857d0..413e3c12 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29009&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29009&range=00-01 Stats: 175 lines in 2 files changed: 87 ins; 88 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29009.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29009/head:pull/29009 PR: https://git.openjdk.org/jdk/pull/29009 From duke at openjdk.org Wed Dec 31 09:40:03 2025 From: duke at openjdk.org (Eunbin Son) Date: Wed, 31 Dec 2025 09:40:03 GMT Subject: RFR: JDK-8374395 : Improve MemoryUsage.toString() and constructor error messages for better clarity In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 07:57:18 GMT, Alan Bateman wrote: >> ### Summary >> MemoryUsage.toString() now displays "N/A" for undefined init and max values (-1) instead of "-1(-1K)". >> >> This addresses the first of three issues in JDK-8374395. >> >> ### Description >> When init or max is -1 (undefined), toString() outputs "-1(-1K)". The Javadoc states that -1 means undefined, but the output does not clearly indicate this. >> >> toString() checks if init or max equals -1 and outputs "init = N/A" or "max = N/A" respectively. Output format for valid values remains unchanged. >> >> Added test cases to the existing jtreg test file. All tests pass. >> >> ### Bug-ID : JDK-8374395 >> https://bugs.java.com/bugdatabase/view_bug?bug_id=JDK-8374395 > >> This addresses the first of three issues in JDK-8374395. > > Note that you can't use the same JBS issue for different PRs/commits. If there are other changes proposed then they will need their own JBS issues. > > test/jdk/java/lang/management/MemoryUsage would be a better place for unit tests for this API. @AlanBateman Thanks for the review. Addressed. This PR covers only the first issue from JDK-8374395. Should I create separate JBS issues for the remaining two? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29009#issuecomment-3701837689 From serb at openjdk.org Wed Dec 31 10:09:05 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 10:09:05 GMT Subject: Integrated: 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 22:27:22 GMT, Sergey Bylokhov wrote: > The copyright year in test/* files updated in 2025 has been bumped to 2025. > > Updates to some tests in the test/langtools/jdk/javadoc/ group are skipped because some tests depend on exact output. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: c6246d58 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/c6246d58f72942b66cb0632186366f0b99402306 Stats: 76 lines in 76 files changed: 0 ins; 0 del; 76 mod 8374383: Update the copyright year to 2025 in the remaining files under test/ where it was missed Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29006 From aivanov at openjdk.org Wed Dec 31 15:35:53 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Dec 2025 15:35:53 GMT Subject: RFR: 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed In-Reply-To: References: Message-ID: On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov wrote: > The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` Marked as reviewed by aivanov (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29008#pullrequestreview-3621060611 From aivanov at openjdk.org Wed Dec 31 15:49:00 2025 From: aivanov at openjdk.org (Alexey Ivanov) Date: Wed, 31 Dec 2025 15:49:00 GMT Subject: RFR: 8374320: Update copyright year to 2025 for java.net.http in files where it was missed In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 07:00:11 GMT, Sergey Bylokhov wrote: > > I checked the http3 branch in the sandbox and several of these files had their last change in 2024, not 2025. When JEP 517 integrated then it might appear that they were created in 2025 even though they have exited in the http3 branch for longer than that. > > correct, they appeared in jdk/master in 2025 as new files as part of the JEP integration. Not sure whether they should be excluded or not, since they were touched this year in some way. Since the development branch is gone and the commits are squashed, these are the new files from the `master` branch perspective. I think the copyright year can still be bumped up in them, preserving the original year. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28973#issuecomment-3702417860 From serb at openjdk.org Wed Dec 31 17:20:09 2025 From: serb at openjdk.org (Sergey Bylokhov) Date: Wed, 31 Dec 2025 17:20:09 GMT Subject: Integrated: 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed In-Reply-To: References: Message-ID: On Tue, 30 Dec 2025 18:30:45 GMT, Sergey Bylokhov wrote: > The copyright year in src/* files updated in 2025 has been bumped to 2025. This is the last PR for this task this year. > > The next command can be run (on top of this PR) to verify that each file had prior commits in 2025: > > `git diff origin/master --name-only | while read f; do git log origin/master --since="2025-01-01" --oneline -- "$f" | head -1 | grep -q . || echo "NOT IN 2025: $f"; done` This pull request has now been integrated. Changeset: 2d1be8a9 Author: Sergey Bylokhov URL: https://git.openjdk.org/jdk/commit/2d1be8a9e66fe82b60f7a22fd7796f0e54e60a5f Stats: 89 lines in 89 files changed: 0 ins; 0 del; 89 mod 8374391: Update the copyright year to 2025 in the remaining files under src/ where it was missed Reviewed-by: aivanov ------------- PR: https://git.openjdk.org/jdk/pull/29008