From serb at openjdk.org Thu Jan 1 04:24:24 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Thu, 1 Jan 2026 04:24:24 GMT Subject: Withdrawn: 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 ` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28973 From bkilambi at openjdk.org Fri Jan 2 10:13:03 2026 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Fri, 2 Jan 2026 10:13:03 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v4] In-Reply-To: <4o-mRvCoV4nHqDouamLFsjYVVHhSuAOurJipQmy3xo8=.08cbadfa-ebdf-4c6b-a7f3-efe808f82b92@github.com> References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> <4o-mRvCoV4nHqDouamLFsjYVVHhSuAOurJipQmy3xo8=.08cbadfa-ebdf-4c6b-a7f3-efe808f82b92@github.com> Message-ID: On Wed, 24 Dec 2025 09:15:00 GMT, Jatin Bhateja wrote: >> 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. Hi @jatin-bhateja could you please take another look at the patch? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3704967816 From naoto at openjdk.org Fri Jan 2 18:27:34 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Jan 2026 18:27:34 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: 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. 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 three additional commits since the last revision: - Reverted bugid in the test - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList - initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28967/files - new: https://git.openjdk.org/jdk/pull/28967/files/44f2fff4..b98b83a4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28967&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28967&range=00-01 Stats: 4448 lines in 1946 files changed: 965 ins; 390 del; 3093 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 naoto at openjdk.org Fri Jan 2 18:27:36 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Jan 2026 18:27:36 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: On Wed, 24 Dec 2025 02:09:57 GMT, Jaikiran Pai wrote: >> 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 three additional commits since the last revision: >> >> - Reverted bugid in the test >> - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList >> - initial commit > > 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. You're right. Reverted the bug ID in the test ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28967#discussion_r2658200576 From naoto at openjdk.org Fri Jan 2 19:03:04 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 2 Jan 2026 19:03:04 GMT Subject: RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests Message-ID: Removing `static` from the JUnit test cases so that they are executed ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29021/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29021&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374433 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29021.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29021/head:pull/29021 PR: https://git.openjdk.org/jdk/pull/29021 From iris at openjdk.org Fri Jan 2 19:07:53 2026 From: iris at openjdk.org (Iris Clark) Date: Fri, 2 Jan 2026 19:07:53 GMT Subject: RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato wrote: > Removing `static` from the JUnit test cases so that they are executed Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3623731349 From joehw at openjdk.org Fri Jan 2 19:37:02 2026 From: joehw at openjdk.org (Joe Wang) Date: Fri, 2 Jan 2026 19:37:02 GMT Subject: RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato wrote: > Removing `static` from the JUnit test cases so that they are executed Marked as reviewed by joehw (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3623770093 From alexey.ivanov at oracle.com Fri Jan 2 20:02:12 2026 From: alexey.ivanov at oracle.com (Alexey Ivanov) Date: Fri, 2 Jan 2026 20:02:12 +0000 Subject: Request to work on JDK-8374344 In-Reply-To: References: Message-ID: Hi Vignesh, This question belongs in core-libs-dev because the component of the issue is *core-libs*. On 2025-12-27 15:53, Vignesh Sadanki wrote: > Hi everyone, > > I'm new to OpenJDK and interested in contributing. I came across bug > JDK-8374344 ("Clarifying HttpURLConnection.disconnect() Behavior > Regarding Resource Management and Connection Pooling") and would like > to work on it. > > Could someone confirm if this bug is available for me to take, and if > there are any guidelines I should follow? > > Thanks, > Vignesh Sadankae -- Regards, Alexey From asemenyuk at openjdk.org Fri Jan 2 20:46:08 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 Jan 2026 20:46:08 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class Message-ID: - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. Supplementary changes: - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private ------------- Commit messages: - Copyright year update - IOUtils: remove getPID() - CommandOutputControl: processNotifier() -> processListener() - Executor-s: add missing functions - Make SystemEnvironment and related classes package-private - Rework the fix using ScopedValue - CommandOutputControlTest: test charset; add a stress test - CommandOutputControl: fix javadoc - CommandOutputControl: remove dead code based on code coverage - CommandOutputControlTest: disable test_close_streams() on macOS - ... and 41 more: https://git.openjdk.org/jdk/compare/2daf12ed...70d7de8d Changes: https://git.openjdk.org/jdk/pull/28733/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374219 Stats: 10507 lines in 87 files changed: 8461 ins; 1644 del; 402 mod Patch: https://git.openjdk.org/jdk/pull/28733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28733/head:pull/28733 PR: https://git.openjdk.org/jdk/pull/28733 From asemenyuk at openjdk.org Fri Jan 2 20:46:09 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 2 Jan 2026 20:46:09 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:03:47 GMT, Alexey Semenyuk wrote: > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/28733#issuecomment-3706191311 From dl at openjdk.org Fri Jan 2 20:46:53 2026 From: dl at openjdk.org (Doug Lea) Date: Fri, 2 Jan 2026 20:46:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v17] 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 24 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Not sure why this merge is necessary Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Fix deactivate; faster quiescence - 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 - ... and 14 more: https://git.openjdk.org/jdk/compare/74c835fa...556c5201 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/228ec84d..556c5201 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=15-16 Stats: 3603 lines in 1872 files changed: 593 ins; 294 del; 2716 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 vklang at openjdk.org Fri Jan 2 23:00:04 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 2 Jan 2026 23:00:04 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v17] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 2 Jan 2026 20:46:53 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 24 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - Not sure why this merge is necessary > Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 > - Merge branch 'openjdk:master' into JDK-8373118 > - Fix deactivate; faster quiescence > - 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 > - ... and 14 more: https://git.openjdk.org/jdk/compare/016cc33f...556c5201 src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1307: > 1305: ForkJoinTask[] a = array; > 1306: int b = base, s = top - 1, cap; > 1307: if (a != null && s - b >= 0 && (cap = a.length) > 0) { Would it help to make the assignment to `cap` be `(cap = a.length - 1) >= 0` and then eliminate the `(cap - 1)` in the slotOffset calculations on both sides of `fifo`-branches? src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1334: > 1332: final ForkJoinTask nextLocalTask() { > 1333: U.loadFence(); // ensure ordering for external callers > 1334: ForkJoinTask t= nextLocalTask(config & FIFO); nit Suggestion: ForkJoinTask t = nextLocalTask(config & FIFO); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2658510000 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2658510564 From mdoerr at openjdk.org Fri Jan 2 23:34:53 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 2 Jan 2026 23:34:53 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fail early on Windows, and more comments src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154: > 152: if (ss.getUsername() != null) { > 153: // When getpwuid_r fails, username will not be available. > 154: userPrincipal = new UnixPrincipal(ss.getUsername()); With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected). @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call): #include __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd, char *buf, size_t buflen, struct passwd **result) { return getpwuid_r(uid, pwd, buf, buflen, result); } Any idea? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658544971 From weijun at openjdk.org Sat Jan 3 02:30:55 2026 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 3 Jan 2026 02:30:55 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fail early on Windows, and more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154: > >> 152: if (ss.getUsername() != null) { >> 153: // When getpwuid_r fails, username will not be available. >> 154: userPrincipal = new UnixPrincipal(ss.getUsername()); > > With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected). > @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call): > > #include > > __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd, > char *buf, size_t buflen, struct passwd **result) > { > return getpwuid_r(uid, pwd, buf, buflen, result); > } > > Any idea? I somehow think the `size_t buflen` in-between might be the reason. Are they put on the stack or into registers? Is there an alignment issue here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658656686 From weijun at openjdk.org Sat Jan 3 02:39:56 2026 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 3 Jan 2026 02:39:56 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 2 Jan 2026 23:31:49 GMT, Martin Doerr wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fail early on Windows, and more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154: > >> 152: if (ss.getUsername() != null) { >> 153: // When getpwuid_r fails, username will not be available. >> 154: userPrincipal = new UnixPrincipal(ss.getUsername()); > > With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected). > @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call): > > #include > > __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd, > char *buf, size_t buflen, struct passwd **result) > { > return getpwuid_r(uid, pwd, buf, buflen, result); > } > > Any idea? Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2658665306 From alan.bateman at oracle.com Sat Jan 3 06:22:34 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Sat, 3 Jan 2026 06:22:34 +0000 Subject: Request to work on JDK-8374344 In-Reply-To: References: Message-ID: This might be tricky to specify, and could end up with some implNote to document the behavior of the JDK protocol handler. In any case, net-dev (rather than core-libs-dev) is the place to discuss this. -Alan On 02/01/2026 20:02, Alexey Ivanov wrote: > Hi Vignesh, > > This question belongs in core-libs-dev because the component of the > issue is *core-libs*. > > On 2025-12-27 15:53, Vignesh Sadanki wrote: >> Hi everyone, >> >> I'm new to OpenJDK and interested in contributing. I came across bug >> JDK-8374344 ("Clarifying HttpURLConnection.disconnect() Behavior >> Regarding Resource Management and Connection Pooling") and would like >> to work on it. >> >> Could someone confirm if this bug is available for me to take, and if >> there are any guidelines I should follow? >> >> Thanks, >> Vignesh Sadankae From dl at openjdk.org Sat Jan 3 15:49:53 2026 From: dl at openjdk.org (Doug Lea) Date: Sat, 3 Jan 2026 15:49:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v18] 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: Strengthen some orderings ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/556c5201..f077eb9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=16-17 Stats: 35 lines in 1 file changed: 16 ins; 3 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 dl at openjdk.org Sat Jan 3 16:16:56 2026 From: dl at openjdk.org (Doug Lea) Date: Sat, 3 Jan 2026 16:16:56 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v16] In-Reply-To: <3V5dzXxT3Z1kpxj4c96ait9widW_xRaE1FaN_94qM2I=.dfc60e7d-a8e6-4002-955d-002a9942e4ea@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> <3V5dzXxT3Z1kpxj4c96ait9widW_xRaE1FaN_94qM2I=.dfc60e7d-a8e6-4002-955d-002a9942e4ea@github.com> Message-ID: On Sun, 28 Dec 2025 17:34:50 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 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/98c9441f...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); Except that normally, topLevelExec shouldn't be inlined in runWorker because it hits megamorphic FJT.exec(). Which is actually good in some artificial benchmarks with only one task type, but rarely in actual use. But there might be ways to place some @DontInline to control better. I'll try some out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2659003373 From mdoerr at openjdk.org Sat Jan 3 18:18:57 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Sat, 3 Jan 2026 18:18:57 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Sat, 3 Jan 2026 02:37:07 GMT, Weijun Wang wrote: >> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixLoginModule.java line 154: >> >>> 152: if (ss.getUsername() != null) { >>> 153: // When getpwuid_r fails, username will not be available. >>> 154: userPrincipal = new UnixPrincipal(ss.getUsername()); >> >> With this change, the test passes on AIX (though the `getpwuid_r` call does not work as expected). >> @JoKern65, @varada1110: The `getpwuid_r` FFM call doesn't set the `result`. The strange thing is that it works when I call it through a C wrapper (same FFM call): >> >> #include >> >> __attribute__((visibility("default"))) int call_getpwuid_r(int uid, struct passwd *pwd, >> char *buf, size_t buflen, struct passwd **result) >> { >> return getpwuid_r(uid, pwd, buf, buflen, result); >> } >> >> Any idea? > > Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`? No, I don't have `jextract` for AIX, but I think @varada1110 does. The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.) I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)! Calling it through my C wrapper which uses the `size_t` also works as already stated above. I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659065739 From weijun at openjdk.org Sat Jan 3 18:47:54 2026 From: weijun at openjdk.org (Weijun Wang) Date: Sat, 3 Jan 2026 18:47:54 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> On Sat, 3 Jan 2026 18:15:47 GMT, Martin Doerr wrote: >> Have you tried `jextract` on AIX? Does the generated code have the same `FunctionDescriptor`? > > No, I don't have `jextract` for AIX, but I think @varada1110 does. > The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.) > I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)! > Calling it through my C wrapper which uses the `size_t` also works as already stated above. > I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here. Or I can call this `_posix_getpwuid_r` function in an `if (isAix())` block. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2659080243 From jpai at openjdk.org Sun Jan 4 01:41:09 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Sun, 4 Jan 2026 01:41:09 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:27:34 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. > > 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 three additional commits since the last revision: > > - Reverted bugid in the test > - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList > - initial commit Thank you for the update, Naoto. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28967#pullrequestreview-3624625183 From serb at openjdk.org Sun Jan 4 02:20:09 2026 From: serb at openjdk.org (Sergey Bylokhov) Date: Sun, 4 Jan 2026 02:20:09 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Mon, 10 Nov 2025 22:24:52 GMT, Archie Cobbs wrote: >> This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. >> >> Summary of code changes: >> >> * Add new warning and associated lint category `"suppression"` >> * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? >> * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. >> * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. >> * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. >> * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break >> >> ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category > > Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: > > - Suppress new unnecessary suppresion warnings created by recent commits. > - Merge branch 'master' into JDK-8344159 > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflict. > - Merge branch 'master' into JDK-8344159 to fix conflicts. > - Add clarifying comment. > - Merge branch 'master' into JDK-8344159 > - Change inner class name to avoid shadowing superclass name. > - Add a couple of code clarification comments. > - Refactor test to avoid requiring changes to TestRunner. > - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 Is this PR still active, or is there any ongoing work on it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3707541329 From duke at openjdk.org Sun Jan 4 06:09:09 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 4 Jan 2026 06:09:09 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())` I had Copilot (GPT-4.1) create a draft: > ## Summary > > Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string. > > ## Problem > > Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check). > > A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 or UTF8MB4. Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points. > > ## Solution > > Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization. > > ## Specification > > Add to `java.lang.CharSequence` interface: > ```java > /** > * Returns the number of Unicode code points in this character sequence. > * Equivalent to {@code codePointCount(0, length())}. > * > * @return the number of Unicode code points in this sequence > * @since N > */ > default int codePointCount() { > return codePointCount(0, length()); > } > ``` > > Add to `java.lang.String` class: > ```java > /** > * Returns the number of Unicode code points in this string. > * Equivalent to {@code codePointCount(0, length())}. > * > * @return the number of Unicode code points in this string > * @since N > */ > @Override > public int codePointCount() { > return codePointCount(0, length()); > } > ``` > > Here, `N` refers to the next Java platform version in which this change will be available. > > Informative Supplement: > > - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461) > - Example use cases: > ```java > // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points: > if (userName.codePointCount() > 20) { > IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!"); > } > // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B: > if (password.codePointCount() < 8) { > IO.println("Password is too short!"); > } > ``` > > References: > - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.0/en/char.html) > - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html) > - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)
Markdown Source ## Summary Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string. ## Problem Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check). A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 or UTF8MB4. Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points. ## Solution Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization. ## Specification Add to `java.lang.CharSequence` interface: /** * Returns the number of Unicode code points in this character sequence. * Equivalent to {@code codePointCount(0, length())}. * * @return the number of Unicode code points in this sequence * @since N */ default int codePointCount() { return codePointCount(0, length()); } Add to `java.lang.String` class: /** * Returns the number of Unicode code points in this string. * Equivalent to {@code codePointCount(0, length())}. * * @return the number of Unicode code points in this string * @since N */ @Override public int codePointCount() { return codePointCount(0, length()); } Here, `N` refers to the next Java platform version in which this change will be available. Informative Supplement: - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461) - Example use cases: ```java // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points: if (userName.codePointCount() > 20) { IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!"); } // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B: if (password.codePointCount() < 8) { IO.println("Password is too short!"); } ``` References: - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.0/en/char.html) - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html) - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)
Needs to be fixed: > for character sets like UTF-8 or UTF8MB4. ? "for character sets like UTF-8 (utf8mb4 in MySQL)." ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3707771006 From duke at openjdk.org Sun Jan 4 07:25:06 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 4 Jan 2026 07:25:06 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: <3JOprtfyEvBcaGwc36e-4qD7pXLFJ_bWYce2CHerALQ=.95148986-fa08-4ec7-93d9-0014d075abb0@github.com> References: <3JOprtfyEvBcaGwc36e-4qD7pXLFJ_bWYce2CHerALQ=.95148986-fa08-4ec7-93d9-0014d075abb0@github.com> Message-ID: On Sat, 8 Nov 2025 13:53:27 GMT, Chen Liang wrote: >> The CSR text is not modified from the boilerplate, but I have no authority to modify it. > > Hi @tats-u, if you can provide the text for the CSR, I can help upload your text to the JBS. Unfortunately you need a JBS account in order to update the CSR. @liach Fixed: > ## Summary > > Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string. > > ## Problem > > Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check). > > A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 (utf8mb4 in MySQL). Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points. > > ## Solution > > Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization. > > ## Specification > > Add to `java.lang.CharSequence` interface: > ```java > /** > * Returns the number of Unicode code points in this character sequence. > * Equivalent to {@code codePointCount(0, length())}. > * > * @return the number of Unicode code points in this sequence > * @since N > */ > default int codePointCount() { > return codePointCount(0, length()); > } > ``` > > Add to `java.lang.String` class: > ```java > /** > * Returns the number of Unicode code points in this string. > * Equivalent to {@code codePointCount(0, length())}. > * > * @return the number of Unicode code points in this string > * @since N > */ > @Override > public int codePointCount() { > return codePointCount(0, length()); > } > ``` > > Here, `N` refers to the next Java platform version in which this change will be available. > > Informative Supplement: > > - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461) > - Example use cases: > ```java > // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points: > if (userName.codePointCount() > 20) { > IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!"); > } > // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B: > if (password.codePointCount() < 8) { > IO.println("Password is too short!"); > } > ``` > > References: > - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.4/en/char.html) > - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html) > - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver)
Markdown Source ## Summary Add a no-argument `codePointCount()` method to `CharSequence` and `String` to count the number of Unicode code points in the entire sequence or string. ## Problem Currently, `String.codePointCount` and `CharSequence.codePointCount` only provide an overload that requires start and end indices. Developers often expect an overload with no arguments that returns the code point count of the entire string or sequence. Without this, developers resort to verbose or less efficient workarounds, such as using `codePoints().count()` (which yields every code point, adding unnecessary overhead) or calling `codePointCount(0, str.length())` (which is more verbose, requires a temporary variable, and performs an extra boundary check). A common use case involves enforcing maximum character limits on user input, particularly for fields stored in databases such as MySQL or PostgreSQL. Both database systems can consider the declared length of `VARCHAR(n)` columns as the number of Unicode code points, not just the number of `char` units or bytes for character sets like UTF-8 (utf8mb4 in MySQL). Correctly counting code points is essential for supporting internationalized input, emoji, and non-BMP characters. For example, the NIST SP 800-63B guideline specifies that passwords should be checked in terms of the number of Unicode code points. ## Solution Introduce default no-argument `codePointCount()` methods in both the `CharSequence` interface and the `String` class. The new method returns the number of Unicode code points in the entire character sequence, equivalent to invoking `codePointCount(0, length())`, but provides better readability and avoids unnecessary overhead. The implementation in `CharSequence` is a default method, while `String` provides an explicit override for potential performance optimization. ## Specification Add to `java.lang.CharSequence` interface: /** * Returns the number of Unicode code points in this character sequence. * Equivalent to {@code codePointCount(0, length())}. * * @return the number of Unicode code points in this sequence * @since N */ default int codePointCount() { return codePointCount(0, length()); } Add to `java.lang.String` class: /** * Returns the number of Unicode code points in this string. * Equivalent to {@code codePointCount(0, length())}. * * @return the number of Unicode code points in this string * @since N */ @Override public int codePointCount() { return codePointCount(0, length()); } Here, `N` refers to the next Java platform version in which this change will be available. Informative Supplement: - Implementation: [GitHub PR 26461](https://github.com/openjdk/jdk/pull/26461) - Example use cases: ```java // For user names stored in MySQL (or PostgreSQL) VARCHAR(20), which counts code points: if (userName.codePointCount() > 20) { IO.println("The user name is too long to store in VARCHAR(20) in utf8mb4 MySQL/PostgreSQL!"); } // Password policy: require at least 8 Unicode characters (code points) as per NIST SP 800-63B: if (password.codePointCount() < 8) { IO.println("Password is too short!"); } ``` References: - [MySQL VARCHAR documentation](https://dev.mysql.com/doc/refman/8.4/en/char.html) - [PostgreSQL Character Types](https://www.postgresql.org/docs/current/datatype-character.html) - [NIST SP 800-63B ?5.1.1.2](https://pages.nist.gov/800-63-4/sp800-63b.html#passwordver) ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3707818947 From jbhateja at openjdk.org Sun Jan 4 10:30:23 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 4 Jan 2026 10:30:23 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... Common IR changes looks good to me. Best Regards, Jatin ------------- Marked as reviewed by jbhateja (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27526#pullrequestreview-3624931740 From acobbs at openjdk.org Sun Jan 4 16:27:07 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 16:27:07 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v5] In-Reply-To: References: <26Gs2omFeLXWjo85AUbAb34PpolWLLsjB2aMS92fNKY=.04fb0491-212d-4212-9dde-08250f361053@github.com> Message-ID: On Sun, 4 Jan 2026 02:17:35 GMT, Sergey Bylokhov wrote: >> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 135 commits: >> >> - Suppress new unnecessary suppresion warnings created by recent commits. >> - Merge branch 'master' into JDK-8344159 >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflict. >> - Merge branch 'master' into JDK-8344159 to fix conflicts. >> - Add clarifying comment. >> - Merge branch 'master' into JDK-8344159 >> - Change inner class name to avoid shadowing superclass name. >> - Add a couple of code clarification comments. >> - Refactor test to avoid requiring changes to TestRunner. >> - ... and 125 more: https://git.openjdk.org/jdk/compare/43afce54...aaf029e8 > > Is this PR still active, or is there any ongoing work on it? Hi @mrserb, > Is this PR still active, or is there any ongoing work on it? Work is completed to the point that it's ready for review, but this is a new feature and as such is lower priority than other changes that are currently being worked on. In the meantime if you're interested in doing any testing or playing around with it I'd love to hear any feedback. Thanks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/25167#issuecomment-3708223841 From acobbs at openjdk.org Sun Jan 4 18:04:45 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sun, 4 Jan 2026 18:04:45 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v6] In-Reply-To: References: Message-ID: <6hvrmK7tyWXAYYeJoCF9jP68LEShyo45T3vo3o7eF2U=.a8c1af86-8025-447e-b531-d195409e3117@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 139 commits: - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - Add clarifying comment. - ... and 129 more: https://git.openjdk.org/jdk/compare/53824cf2...cad270ed ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=05 Stats: 1695 lines in 35 files changed: 1492 ins; 49 del; 154 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From xgong at openjdk.org Mon Jan 5 06:49:50 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 5 Jan 2026 06:49:50 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 LGTM. Thanks for the fixing! ------------- Marked as reviewed by xgong (Committer). PR Review: https://git.openjdk.org/jdk/pull/28692#pullrequestreview-3625662421 From erfang at openjdk.org Mon Jan 5 08:11:19 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 5 Jan 2026 08:11:19 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] 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 eight commits: - Update copyright year to 2026 - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity - wrap the test loop within a try/catch to speed up the tests - Refine the tests for identity values - 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=05 Stats: 13975 lines in 48 files changed: 7543 ins; 3660 del; 2772 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 Jan 5 08:14:10 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 5 Jan 2026 08:14:10 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] 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 12 commits: - Update copyright year to 2026 - Merge branch 'master' into JDK-8370863-mask-cast-opt - Convert the check condition for vector length into an assertion Also refined the tests. - Refine code comments - 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 - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 ------------- Changes: https://git.openjdk.org/jdk/pull/28313/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=07 Stats: 643 lines in 7 files changed: 528 ins; 16 del; 99 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 duke at openjdk.org Mon Jan 5 08:41:50 2026 From: duke at openjdk.org (Johny Jose) Date: Mon, 5 Jan 2026 08:41:50 GMT Subject: RFR: 8373476 : (tz) Update Timezone Data to 2025c Message-ID: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> tzdata changes for 2025c ------------- Commit messages: - 8373476: (tz) Update Timezone Data to 2025c Changes: https://git.openjdk.org/jdk/pull/29029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373476 Stats: 132 lines in 11 files changed: 67 ins; 8 del; 57 mod Patch: https://git.openjdk.org/jdk/pull/29029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29029/head:pull/29029 PR: https://git.openjdk.org/jdk/pull/29029 From coffeys at openjdk.org Mon Jan 5 09:18:22 2026 From: coffeys at openjdk.org (Sean Coffey) Date: Mon, 5 Jan 2026 09:18:22 GMT Subject: RFR: 8373476 : (tz) Update Timezone Data to 2025c In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> Message-ID: On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose wrote: > tzdata changes for 2025c LGTM ------------- Marked as reviewed by coffeys (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29029#pullrequestreview-3626034314 From jpai at openjdk.org Mon Jan 5 09:42:37 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Jan 2026 09:42:37 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... Thank you for the review, Mark. > BUT I think it possible to simply the main test logic a bit. The Object wait/notify could be replaced by a CountDownLatch. That's a good idea. I have updated the PR to use a CountDownLatch. The test continues to pass with this change. > one could debate if the temporal checks are necessary, as they cannot be guaranteed. Given the motivation of this original test, as stated in its `@summary`, I think we should continue testing that the callback does indeed fire within reasonable amount of time, depending on the configured `java.rmi.dgc.leaseValue` value. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3709647389 From jpai at openjdk.org Mon Jan 5 09:42:35 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 5 Jan 2026 09:42:35 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v2] In-Reply-To: References: 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 te... Jaikiran Pai 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: - Mark's review - use CountDownLatch - merge latest from master branch - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/af9e6502..d086512d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=00-01 Stats: 5957 lines in 2014 files changed: 1797 ins; 727 del; 3433 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 duke at openjdk.org Mon Jan 5 11:31:26 2026 From: duke at openjdk.org (Yi Wu) Date: Mon, 5 Jan 2026 11:31:26 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 [v2] In-Reply-To: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> Message-ID: <72RiEFo5wji1vOtIRzFwO03_0OsaCe2zzHjp9YPD8-k=.6a88f4eb-3fff-4fe5-bb43-260d81b7954a@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. Yi Wu 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: - Replace assert with verify - Add IRNode constant and code refactor - Merge remote-tracking branch 'origin/master' into yiwu-8373344 - 8373344: Add support for FP16 min/max reduction operations 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28828/files - new: https://git.openjdk.org/jdk/pull/28828/files/2f80bc4f..9971752e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28828&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28828&range=00-01 Stats: 17385 lines in 2438 files changed: 9261 ins; 2408 del; 5716 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 duke at openjdk.org Mon Jan 5 11:33:33 2026 From: duke at openjdk.org (Yi Wu) Date: Mon, 5 Jan 2026 11:33:33 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 [v2] In-Reply-To: References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> Message-ID: On Mon, 22 Dec 2025 09:40:42 GMT, Galder Zamarre?o wrote: >> Yi Wu 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: >> >> - Replace assert with verify >> - Add IRNode constant and code refactor >> - Merge remote-tracking branch 'origin/master' into yiwu-8373344 >> - 8373344: Add support for FP16 min/max reduction operations >> >> 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)... > > Thanks @yiwu0b11, some superficial comments Thanks @galderz for the code review, I've updated the code and also replaced assert with [verify](https://github.com/openjdk/jdk/pull/28095) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28828#issuecomment-3710056269 From mdoerr at openjdk.org Mon Jan 5 11:47:23 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Jan 2026 11:47:23 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> Message-ID: On Sat, 3 Jan 2026 18:45:40 GMT, Weijun Wang wrote: >> No, I don't have `jextract` for AIX, but I think @varada1110 does. >> The signature is `static int getpwuid_r(uid_t, struct passwd *, char *, size_t, struct passwd **)` which essentially matches. (A possible problem may be that `uid_t` is unsigned, but we're treating it as `int`. However, the sign bit is 0 in my experiments. All parameters are passed in 64-bit registers in which `int` gets sign extended.) >> I have found `extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **)` which takes an `int` for the buffer length and that functions works if I call it directly from Java (instead of the one above)! >> Calling it through my C wrapper which uses the `size_t` also works as already stated above. >> I think the AIX specific investigation could be done in a separate issue if the discussion is getting too long, here. > > Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough? > > private static final MethodHandle getpwuid_r = LINKER > - .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"), > + .downcallHandle(SYMBOL_LOOKUP.findOrThrow( > + OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), > FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER, > - C_SIZE_T, C_POINTER)); > + OperatingSystem.isAix() ? C_INT : C_SIZE_T, > + C_POINTER)); Thank you for taking care of it! I appreciate it. This has worked: diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java index ee2c5effcf0..3afab6f7974 100644 --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java @@ -38,6 +38,8 @@ import java.lang.invoke.MethodHandle; import java.lang.invoke.VarHandle; +import jdk.internal.util.OperatingSystem; + import static java.lang.foreign.MemoryLayout.PathElement.groupElement; /** @@ -106,9 +108,9 @@ public class UnixSystem { .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"), FunctionDescriptor.of(C_INT)); private static final MethodHandle getpwuid_r = LINKER - .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"), + .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER, - C_SIZE_T, C_POINTER)); + OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER)); private static final GroupLayout passwd_layout = MemoryLayout.structLayout( C_POINTER.withName("pw_name"), @@ -136,7 +138,7 @@ public class UnixSystem { // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux. // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different // on different platforms. - private static final long GETPW_R_SIZE_MAX = 4096L; + private static final int GETPW_R_SIZE_MAX = 4096; /** * Instantiate a {@code UnixSystem} and load Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly. I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days. We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong. Not sure of anyone uses so large UIDs and if we could restrict them. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661215966 From jvernee at openjdk.org Mon Jan 5 12:06:35 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 5 Jan 2026 12:06:35 GMT Subject: [jdk26] RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free Message-ID: Hi all, This pull request contains a backport of commit [821e9ff9](https://github.com/openjdk/jdk/commit/821e9ff965cad52cdd26c08785312db49bcce539) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jorn Vernee on 19 Dec 2025 and was reviewed by Chen Liang. Thanks! We are currently in RDP1 (https://openjdk.org/projects/jdk/26/), and this issue is a test bug (noreg-self), so it is allowed without approval. ------------- Commit messages: - Backport 821e9ff965cad52cdd26c08785312db49bcce539 Changes: https://git.openjdk.org/jdk/pull/29031/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29031&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/29031.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29031/head:pull/29031 PR: https://git.openjdk.org/jdk/pull/29031 From djgredler at gmail.com Mon Jan 5 12:15:16 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Mon, 5 Jan 2026 13:15:16 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? Message-ID: Hi, I was recently looking at subclassing `ByteArrayOutputStream` in an application so that I could add a fast VarHandle-based `writeLong(long)` method (writing 8 bytes to the byte array in one go). The internal `ByteArrayOutputStream` buffer is protected, so no issue there, but `ensureCapacity(int)` is private rather than protected, and uses the internal `ArraysSupport` class, so it's not even easy to copy/paste as duplicate code in the subclass. Similar `ensureCapacity` methods in `ArrayList` and `StringBuilder` are public. Would a PR adjusting the visibility of this method from private to protected be accepted? Take care, Daniel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mcimadamore at openjdk.org Mon Jan 5 12:28:23 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 12:28:23 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fail early on Windows, and more comments src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90: > 88: = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t"); > 89: > 90: private static Linker.Option ccs = Linker.Option.captureCallState("errno"); names of static final fields should be capitalized? src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 121: > 119: // While we don't need those fields here, the struct needs to be > 120: // big enough to avoid buffer overflow when `getpwuid_r` is called. > 121: MemoryLayout.sequenceLayout(100, C_CHAR).withName("dummy")); maybe use a padding layout here? (assuming you don't want clients to access the bytes in `dummy`) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661328588 PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661324659 From mcimadamore at openjdk.org Mon Jan 5 12:34:21 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 5 Jan 2026 12:34:21 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 2 Jan 2026 17:00:37 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > fail early on Windows, and more comments src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87: > 85: = ((AddressLayout) LINKER.canonicalLayouts().get("void*")) > 86: .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR)); > 87: private static final ValueLayout.OfLong C_SIZE_T Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2661342378 From bkilambi at openjdk.org Mon Jan 5 12:43:36 2026 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 5 Jan 2026 12:43:36 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 @eme64 Would you please be able to run some testing internally before I integrate this patch? Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3710264065 From dl at openjdk.org Mon Jan 5 13:14:22 2026 From: dl at openjdk.org (Doug Lea) Date: Mon, 5 Jan 2026 13:14:22 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v19] 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: Undo/redo ordering changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/f077eb9e..2a580747 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=17-18 Stats: 105 lines in 1 file changed: 26 ins; 40 del; 39 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 alanb at openjdk.org Mon Jan 5 13:27:27 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Jan 2026 13:27:27 GMT Subject: RFR: 8373647: Avoid unnecessary fstat when opening file for write In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 11:49:19 GMT, Jonas Norlinder wrote: > # 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. The new APIs doesn't have this restriction but we are stuck with it for FileInputStream or when opening a file for read with RandomAccessFile. At some point we will replace the implementation of all 3 as they can be implemented on top of the new APIs. src/java.base/unix/native/libjava/io_util_md.c line 82: > 80: // not a read access mode then the Unix standard > 81: // guarantees to have failed with EISDIR > 82: if (fd == -1 || ((oflag & O_ACCMODE) != O_RDONLY) != 0) { Can you drop the "Fast-path" comment as it is confusing here. It just needs to say that there is no need to check if the file is a directory when opened for write. src/java.base/unix/native/libjava/io_util_md.c line 86: > 84: } > 85: > 86: // Slow-path, while Unix allow for directories We can replace this with a clearer comment to say that FileInputStream is specified to throw if the file is a directory? test/micro/org/openjdk/bench/java/io/FileWriteStress.java line 26: > 24: > 25: import java.io.File; > 26: import java.io.FileNotFoundException; Used? test/micro/org/openjdk/bench/java/io/FileWriteStress.java line 44: > 42: > 43: @Fork(value = 10) > 44: public class FileWriteStress { You might want to think about a better name for this as it's not really a write stress tests. It could test both FOS and RAF as the changes in the PR change both. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28823#issuecomment-3710409761 PR Review Comment: https://git.openjdk.org/jdk/pull/28823#discussion_r2661474563 PR Review Comment: https://git.openjdk.org/jdk/pull/28823#discussion_r2661479745 PR Review Comment: https://git.openjdk.org/jdk/pull/28823#discussion_r2634936021 PR Review Comment: https://git.openjdk.org/jdk/pull/28823#discussion_r2634935307 From asemenyuk at openjdk.org Mon Jan 5 13:53:58 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 5 Jan 2026 13:53:58 GMT Subject: RFR: 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other Message-ID: Remove the "error.explicit-sign-no-cert" error message, which duplicates the "error.cert.not.found" error message. ------------- Commit messages: - 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other Changes: https://git.openjdk.org/jdk/pull/29025/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29025&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373833 Stats: 17 lines in 3 files changed: 1 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29025.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29025/head:pull/29025 PR: https://git.openjdk.org/jdk/pull/29025 From asemenyuk at openjdk.org Mon Jan 5 13:53:58 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 5 Jan 2026 13:53:58 GMT Subject: RFR: 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 02:02:44 GMT, Alexey Semenyuk wrote: > Remove the "error.explicit-sign-no-cert" error message, which duplicates the "error.cert.not.found" error message. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29025#issuecomment-3710494409 From roger.riggs at oracle.com Mon Jan 5 14:53:35 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 5 Jan 2026 09:53:35 -0500 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: Message-ID: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> Hi Daniel, That seems reasonable, allowing control over the timing of resizes. Making it public is sensible too. From a higher point of view, are you sure you want to be working with ByteArrayOutputStream and not ByteBuffer or Memory Segments? There are more performance possibilities with those APIs. Regards, Roger On 1/5/26 7:15 AM, Daniel Gredler wrote: > Hi, > > I was recently looking at subclassing `ByteArrayOutputStream` in an > application so that I could add a fast VarHandle-based > `writeLong(long)` method (writing 8 bytes to the byte array in one > go). The internal?`ByteArrayOutputStream` buffer is protected, so no > issue there, but `ensureCapacity(int)` is private rather than > protected, and uses the internal `ArraysSupport` class, so it's not > even easy to copy/paste as duplicate code in the subclass. Similar > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are > public. Would a PR adjusting the visibility of this method from > private to protected be accepted? > > Take care, > > Daniel > > From abimpoudis at openjdk.org Mon Jan 5 15:44:12 2026 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Mon, 5 Jan 2026 15:44:12 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 739: > 737: * Determines if the reference type represented by this {@code Class} object > 738: * is the same as or a proper supertype of the class of the object specified > 739: * by the argument. This method is the dynamic equivalent of the type What do you think about something like the following, just to minimize the diff with the original spec? "This method is the dynamic equivalent of the Java language {@code instanceof} type comparison operator (JLS {@jls15.20.2})" (adding "type comparison" before the operator) src/java.base/share/classes/java/lang/Class.java line 741: > 739: * by the argument. This method is the dynamic equivalent of the type > 740: * comparison operator of the {@code instanceof} Java keyword (JLS {@jls > 741: * 15.20.2}). This method returns {@code true} if and only if this {@code I think this ("This method returns.... without throwing a {@code ClassCastException}") didn't need a change, did it? Because now it seems that `isInstance` checks only the success of a narrowing reference conversion. Because the following which is a widening reference conversion check returns `true` but it seems to be excluded by the new javadoc: `Animal.class.isInstance(new Dog())`. src/java.base/share/classes/java/lang/Class.java line 748: > 746: * Class} object without throwing a {@code ClassCastException}. > 747: * > 748: *

This method behaves as if: Showing an example is a great idea! Shouldn't we use an example with the actual `instanceof` type comparison operator here? Why use an example of `isAssignableFrom` to the `isInstance` javadoc? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28684#discussion_r2660767325 PR Review Comment: https://git.openjdk.org/jdk/pull/28684#discussion_r2661907375 PR Review Comment: https://git.openjdk.org/jdk/pull/28684#discussion_r2661912045 From jvernee at openjdk.org Mon Jan 5 16:03:29 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 5 Jan 2026 16:03:29 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 I think it would be good to change all the calls to `Assertions.*` to use static imports instead. This PR changes quite a few calls to use the longer form, but doesn't do so uniformly test/jdk/java/lang/invoke/8147078/Test8147078.java line 37: > 35: import org.junit.jupiter.api.Test; > 36: > 37: import static org.junit.jupiter.api.Assertions.assertThrows; Copyright year on this file should be updated. test/jdk/java/lang/invoke/AccessControlTest.java line 217: > 215: boolean sameClass = (c1 == c2); > 216: Assertions.assertTrue(samePackage || !sameTopLevel); > 217: Assertions.assertTrue(sameTopLevel || !sameClass); Suggestion: assertTrue(samePackage || !sameTopLevel); assertTrue(sameTopLevel || !sameClass); test/jdk/java/lang/invoke/CompileThresholdBootstrapTest.java line 46: > 44: public static void main(String ... args) throws Throwable { > 45: CompileThresholdBootstrapTest test = new CompileThresholdBootstrapTest(); > 46: test.testBootstrap(); Does this main method even do anything? Looks like it's not being run. test/jdk/java/lang/invoke/DefineClassTest.java line 211: > 209: > 210: Class clazz = lookup.defineClass(generateClass("java.lang.Foo")); > 211: assertEquals("java.lang.Foo", clazz.getName()); Looks like the parameter order was already reversed here. test/jdk/java/lang/invoke/LoopCombinatorTest.java line 236: > 234: assertEqualsFIXME(messageOrNull, iae.getMessage()); > 235: return; > 236: } Could you split this into separate positive and negative tests, with separate sources? test/jdk/java/lang/invoke/LoopCombinatorTest.java line 339: > 337: assertEqualsFIXME(messageOrNull, iae.getMessage()); > 338: return; > 339: } Same here. test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java line 46: > 44: // inaccessible interface > 45: Method m = intf.getMethod("test"); > 46: assertFalse(m.canAccess(t)); This looks like a semantic change? Fixing an existing bug in the test? test/jdk/java/lang/invoke/MethodHandles/TestDropReturn.java line 40: > 38: import org.junit.jupiter.params.provider.MethodSource; > 39: > 40: @TestInstance(TestInstance.Lifecycle.PER_CLASS) Why is this annotation needed here? There's only one test method. test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java line 241: > 239: var e = Assertions.assertThrows(BootstrapMethodError.class, mh::invoke); > 240: Throwable t = e.getCause(); > 241: Assertions.assertTrue(WrongMethodTypeException.class.isAssignableFrom(t.getClass())); Suggestion: assertInstanceOf(WrongMethodTypeException.class, e.getCause()); test/jdk/java/lang/invoke/condy/CondyWrongType.java line 117: > 115: caught = caught.getCause(); > 116: assertNotNull(caught); > 117: assertTrue(ClassCastException.class.isAssignableFrom(caught.getClass())); Suggestion: assertInstanceOf(ClassCastException.class, caught.getCause()); ------------- PR Review: https://git.openjdk.org/jdk/pull/28879#pullrequestreview-3590083827 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2628995639 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2628998893 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2629006433 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2629008843 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661620158 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661621257 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661675942 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661650953 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661933198 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2661948489 From jvernee at openjdk.org Mon Jan 5 16:03:31 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 5 Jan 2026 16:03:31 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 Wed, 17 Dec 2025 23:51:42 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/AccessControlTest.java line 217: > >> 215: boolean sameClass = (c1 == c2); >> 216: Assertions.assertTrue(samePackage || !sameTopLevel); >> 217: Assertions.assertTrue(sameTopLevel || !sameClass); > > Suggestion: > > assertTrue(samePackage || !sameTopLevel); > assertTrue(sameTopLevel || !sameClass); Looks like you can do this cleanup in other places too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2629000475 From weijun at openjdk.org Mon Jan 5 16:13:56 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 16:13:56 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> Message-ID: On Mon, 5 Jan 2026 11:42:08 GMT, Martin Doerr wrote: >> Or I can call this `_posix_getpwuid_r` function if `isAix()` is true. Is this enough? >> >> private static final MethodHandle getpwuid_r = LINKER >> - .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"), >> + .downcallHandle(SYMBOL_LOOKUP.findOrThrow( >> + OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), >> FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER, >> - C_SIZE_T, C_POINTER)); >> + OperatingSystem.isAix() ? C_INT : C_SIZE_T, >> + C_POINTER)); > > Thank you for taking care of it! I appreciate it. This has worked: > > diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > index ee2c5effcf0..3afab6f7974 100644 > --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > @@ -38,6 +38,8 @@ > import java.lang.invoke.MethodHandle; > import java.lang.invoke.VarHandle; > > +import jdk.internal.util.OperatingSystem; > + > import static java.lang.foreign.MemoryLayout.PathElement.groupElement; > > /** > @@ -106,9 +108,9 @@ public class UnixSystem { > .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getgid"), > FunctionDescriptor.of(C_INT)); > private static final MethodHandle getpwuid_r = LINKER > - .downcallHandle(SYMBOL_LOOKUP.findOrThrow("getpwuid_r"), > + .downcallHandle(SYMBOL_LOOKUP.findOrThrow(OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), > FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER, > - C_SIZE_T, C_POINTER)); > + OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER)); > > private static final GroupLayout passwd_layout = MemoryLayout.structLayout( > C_POINTER.withName("pw_name"), > @@ -136,7 +138,7 @@ public class UnixSystem { > // sysconf(_SC_GETPW_R_SIZE_MAX) on macOS is 4096 and 1024 on Linux. > // Not calling sysconf() here because _SC_GETPW_R_SIZE_MAX is different > // on different platforms. > - private static final long GETPW_R_SIZE_MAX = 4096L; > + private static final int GETPW_R_SIZE_MAX = 4096; > > /** > * Instantiate a {@code UnixSystem} and load > > Note that `GETPW_R_SIZE_MAX` needs to be an `int` because `long` to `int` conversion would require an explicit cast (probably also for arm32). The other way round works implicitly. > > I'd like to have feedback from the AIX experts as well. They may still be on vacation for a couple of days. > > We still have a potential problem with the UID parameter. We are using an `int`, but the C code expects an `uint32_t`. Some platforms pass 32 bit values in 64 bit registers and expect a proper extension (zero for unsigned and sign for signed). If the UID becomes larger than INT_MAX, we use sign extend which is wrong. > Not sure of anyone uses so large UIDs and if we could re... Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s. Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail later with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662017228 From weijun at openjdk.org Mon Jan 5 16:13:59 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 16:13:59 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Mon, 5 Jan 2026 12:25:41 GMT, Maurizio Cimadamore wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fail early on Windows, and more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 90: > >> 88: = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("size_t"); >> 89: >> 90: private static Linker.Option ccs = Linker.Option.captureCallState("errno"); > > names of static final fields should be capitalized? I inlined it instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662029528 From weijun at openjdk.org Mon Jan 5 16:19:17 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 16:19:17 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Mon, 5 Jan 2026 12:31:10 GMT, Maurizio Cimadamore wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> fail early on Windows, and more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 87: > >> 85: = ((AddressLayout) LINKER.canonicalLayouts().get("void*")) >> 86: .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR)); >> 87: private static final ValueLayout.OfLong C_SIZE_T > > Note that portability between 32/64 is hard, even if using canonicalLayouts -- because size_t will likely be an IntLayout on arm32, while a LongLayout in 64 bits. If you never use this layout to access data (e.g. call `MemorySegment::get/set`) I'd suggest to avoid the cast, and leave it just as `ValueLayout` Ah yes, thanks for pointing out. I forgot to update it when changing "long" to "size_t". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662046816 From weijun at openjdk.org Mon Jan 5 16:30:23 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 16:30:23 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v6] In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: > Rewrite the native calls with FFM. Weijun Wang 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: - address comments from Maurizio; support AIX-specific `_posix_getpwuid_r`; recover unsigned int - Merge branch 'master' into 8277489 - fail early on Windows, and more comments - use size_t - error handling - rewrite without jextract - no tabs - the fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28931/files - new: https://git.openjdk.org/jdk/pull/28931/files/578f1d2e..b54ca67c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=04-05 Stats: 5209 lines in 1977 files changed: 1372 ins; 600 del; 3237 mod Patch: https://git.openjdk.org/jdk/pull/28931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931 PR: https://git.openjdk.org/jdk/pull/28931 From roger.riggs at oracle.com Mon Jan 5 16:37:13 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 5 Jan 2026 11:37:13 -0500 Subject: ScopeValue for Locale, Clock, ZoneId ... and others In-Reply-To: References: Message-ID: Hi Omar, Global variables have long been the domain of bugs and increase the maintenance cost of software creating undocumented or under-documented dependencies on external contexts. Scoped variables are essentially global variables and are useful in specific contexts and with the explicit specification and documentation of their effects on APIs and behavior. It could be interesting to look at some specific use cases and explore the scope and impact on usability and compatibility. Regards, Roger On 12/30/25 2:20 PM, Omar Aloraini wrote: > 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. From mdoerr at openjdk.org Mon Jan 5 16:39:43 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Jan 2026 16:39:43 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> Message-ID: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> On Mon, 5 Jan 2026 16:06:56 GMT, Weijun Wang wrote: > Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs. Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`. However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended. > I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username. Fine with me. I don't like ignoring getpwuid_r failures, either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662113718 From weijun at openjdk.org Mon Jan 5 16:49:05 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 16:49:05 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> Message-ID: On Mon, 5 Jan 2026 16:36:50 GMT, Martin Doerr wrote: >> Maybe we can call `Integer.toUnsignedLong()` on `pw_uid` and `pw_gid`? In `UnixSystem`, they are `long`s. >> >> Also, I want to discuss on the `username` issue again. Do you think it's good to login successfully without a `UnixPrincipal`? Now that there is a way on AIX to get it, I'm more inclined to revert the changes made to `UnixLoginModule`. While the old `Unix.c` seems to support username being `null` we know it would fail immediately with an NPE so this has never really worked before. My current understanding is that silent passing the login without a username might hide a bug and if the user takes it for granted that there should be a `UnixPrincipal` there will be a problem sooner or later. In fact, I would suggest we just throw an exception in `UnixSystem` if `getpwuid_r` cannot find the username. > >> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs. > > Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`. > However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? > In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended. > >> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username. > > Fine with me. I don't like ignoring getpwuid_r failures, either. I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`. The results always look good after a `Integer.toUnsignedLong()` conversion. I would think it's safe because it's only called after the C functions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662146915 From weijun at openjdk.org Mon Jan 5 17:20:29 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 17:20:29 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: > Rewrite the native calls with FFM. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: must have username; more comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28931/files - new: https://git.openjdk.org/jdk/pull/28931/files/b54ca67c..cfd794b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=05-06 Stats: 43 lines in 2 files changed: 5 ins; 25 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/28931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931 PR: https://git.openjdk.org/jdk/pull/28931 From naoto at openjdk.org Mon Jan 5 17:20:31 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Jan 2026 17:20:31 GMT Subject: RFR: 8374217: Remove IO.java test from AOT ProblemList [v2] In-Reply-To: References: Message-ID: <1wIcRHdAvCGaMY6HiHewDAdCHFUi0mJgJN0PKY4rb4s=.18fcee6b-d667-42de-9934-a4c759feefcf@github.com> On Fri, 2 Jan 2026 18:27:34 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. > > 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 three additional commits since the last revision: > > - Reverted bugid in the test > - Merge branch 'master' into JDK-8374217-Remove-IO-from-AOTProblemList > - initial commit Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28967#issuecomment-3711344510 From naoto at openjdk.org Mon Jan 5 17:20:32 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Jan 2026 17:20:32 GMT Subject: Integrated: 8374217: Remove IO.java test from AOT ProblemList In-Reply-To: References: Message-ID: <32_4HTHwNl9_7aQxovrEdXjNjObYm3WM7FShxoZrl1g=.ce491b24-57c7-4055-a0a8-d7bbcd972c4a@github.com> 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. This pull request has now been integrated. Changeset: 27dbdec2 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/27dbdec297fc8030812f7290a7601b6a99defb46 Stats: 5 lines in 2 files changed: 0 ins; 4 del; 1 mod 8374217: Remove IO.java test from AOT ProblemList Reviewed-by: jpai, iklam ------------- PR: https://git.openjdk.org/jdk/pull/28967 From jlu at openjdk.org Mon Jan 5 17:21:47 2026 From: jlu at openjdk.org (Justin Lu) Date: Mon, 5 Jan 2026 17:21:47 GMT Subject: RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato wrote: > Removing `static` from the JUnit test cases so that they are executed Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29021#pullrequestreview-3627735928 From duke at openjdk.org Mon Jan 5 17:27:09 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 5 Jan 2026 17:27:09 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended Message-ID: Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. ------------- Commit messages: - removing ImageBufferCache and unwinding dead code Changes: https://git.openjdk.org/jdk/pull/29043/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374308 Stats: 54 lines in 3 files changed: 12 ins; 39 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29043/head:pull/29043 PR: https://git.openjdk.org/jdk/pull/29043 From duke at openjdk.org Mon Jan 5 17:36:39 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 5 Jan 2026 17:36:39 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:19:50 GMT, David Beaumont wrote: > Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. > > I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). > > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 390: > 388: } > 389: > 390: private static ByteBuffer allocateBuffer(long size) { The only bit of code from ImageBufferCache that was being used in existing code. src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 411: > 409: } > 410: > 411: /** Seemed worth stressing that this is a new buffer allocation (since there's no "release" option to callers anymore, it's a usage/lifetime change). src/java.base/share/classes/jdk/internal/jimage/ImageReader.java line 193: > 191: > 192: /** > 193: * Returns the content of a resource node in a newly allocated byte buffer. While the "ByteBuffer" instance is newly allocated, it's almost always a cheap slice of the memory mapped file. I'm not sure what we want as the best wording here, since: 1. We want people to know they don't need to worry about "releasing" it, but also 2. we don't want people to think it's using a newly allocated/copied buffer. Happy to take suggestion on better wording here and for "getResourceBuffer" above. src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 470: > 468: } > 469: > 470: @Override Can be removed since ModuleReader has a default method with the null check in it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662257958 PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662260718 PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662270609 PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662272689 From darcy at openjdk.org Mon Jan 5 17:41:01 2026 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Jan 2026 17:41:01 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma Message-ID: Add comment describing why Math.fma uses BigDecimal. ------------- Commit messages: - JDK-8374540: Add comment describing implementaiton choices of Math.fma Changes: https://git.openjdk.org/jdk/pull/29044/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29044&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374540 Stats: 13 lines in 1 file changed: 12 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29044/head:pull/29044 PR: https://git.openjdk.org/jdk/pull/29044 From duke at openjdk.org Mon Jan 5 17:41:31 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 5 Jan 2026 17:41:31 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: Message-ID: > Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. > > I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). > > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: actually remove the class ... ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29043/files - new: https://git.openjdk.org/jdk/pull/29043/files/2b158fe4..5a37317e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=00-01 Stats: 158 lines in 1 file changed: 0 ins; 158 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29043/head:pull/29043 PR: https://git.openjdk.org/jdk/pull/29043 From rgiulietti at openjdk.org Mon Jan 5 17:53:09 2026 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Mon, 5 Jan 2026 17:53:09 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:33:34 GMT, Joe Darcy wrote: > Add comment describing why Math.fma uses BigDecimal. src/java.base/share/classes/java/lang/Math.java line 2380: > 2378: */ > 2379: @IntrinsicCandidate > 2380: public static double fma(double a, double b, double c) { There are some parts that do not sound right to me, but English is not my native language. Thus, the text might still sound correct to native ears. src/java.base/share/classes/java/lang/Math.java line 2384: > 2382: // a straightforward manner relying on BigDecimal for the > 2383: // heavy-lifting of the numerical computation. It would be > 2384: // possible for the computation done using all binary Suggestion: // possible for the computation to be done using all binary src/java.base/share/classes/java/lang/Math.java line 2387: > 2385: // floating-point and integer operations, at the cost of more > 2386: // complicated logic. Since most processors have hardware > 2387: // support for fma so and this method is an intrinsic Suggestion: // support for fma and this method is an intrinsic ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2662324013 PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2662325012 PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2662326202 From alanb at openjdk.org Mon Jan 5 17:56:30 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Jan 2026 17:56:30 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: Message-ID: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> On Mon, 5 Jan 2026 17:41:31 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > actually remove the class ... src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 392: > 390: private static ByteBuffer allocateBuffer(long size) { > 391: if (size < 0 || Integer.MAX_VALUE < size) { > 392: throw new IndexOutOfBoundsException("size"); I don't think it can happen but I assume IAE would be more appropriate here as size is not an index. src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 394: > 392: throw new IndexOutOfBoundsException("size"); > 393: } > 394: ByteBuffer result = ByteBuffer.allocateDirect((int) ((size + 0xFFF) & ~0xFFF)); Can you remind me why it allocates multiples of 4k? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662336397 PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662334175 From naoto at openjdk.org Mon Jan 5 17:56:30 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 5 Jan 2026 17:56:30 GMT Subject: RFR: 8373476 : (tz) Update Timezone Data to 2025c In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> Message-ID: On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose wrote: > tzdata changes for 2025c LGTM. For the JIRA issue, please fix the last paragraph in the problem text: Commentary now also uses characters from the set -''""?? as this can be useful and should work with current applications. This also affects data in iso3166.tab and zone1970.tab, which now contain strings like "C?te d'Ivoire" instead of "C?te d'Ivoire". which seems to have converted the non-ASCII quotes to ASCII equivalents, which made the paragraph not making sense. FWIW, the original was: Commentary now also uses characters from the set ??????? as this can be useful and should work with current applications. This also affects data in iso3166.tab and zone1970.tab, which now contain strings like ?C?te d?Ivoire? instead of ?C?te d'Ivoire? src/java.base/share/data/tzdata/iso3166.tab line 44: > 42: # ?Czech Republic? and ?Turkey? rather than ?Czechia? and ?T?rkiye?), > 43: # and sometimes to omit needless detail or churn (e.g., ?Netherlands? > 44: # rather than ?Netherlands (the)? or ?Netherlands (Kingdom of the)?). It's interesting that they started using non-ASCII quotes in comments, which is different from our policy, but we need to live with it as it is the upstream change ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29029#pullrequestreview-3627828729 PR Review Comment: https://git.openjdk.org/jdk/pull/29029#discussion_r2662309506 From mdoerr at openjdk.org Mon Jan 5 18:02:11 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 5 Jan 2026 18:02:11 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> Message-ID: On Mon, 5 Jan 2026 16:46:32 GMT, Weijun Wang wrote: >>> Maybe we can call Integer.toUnsignedLong() on pw_uid and pw_gid? In UnixSystem, they are longs. >> >> Yes, I had thought about this, too. But, I think we will need to distinguish between the platforms. PPC64 and s390 (and also SPARC which is no longer supported) pass smaller integer type values as 64 bit `long` and `Integer.toUnsignedLong()` would be correct when we change the signature to use `long` instead of `int`. >> However, other platforms may require to pass the values as 4 Byte `int`. Especially when they are passed on stack. (Not sure if any supported platform does that. Probably not.) It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? >> In hotspot, `CCallingConventionRequiresIntsAsLongs` is used to decide if 4 Byte integer types need to get extended. >> >>> I would suggest we just throw an exception in UnixSystem if getpwuid_r cannot find the username. >> >> Fine with me. I don't like ignoring getpwuid_r failures, either. > > I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`. The results always look good after a `Integer.toUnsignedLong()` conversion. > > I would think it's safe because it's only called after the C functions. What you have done is fine. Thanks! However, there is one potential problem left: We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX): [2.537s][trace][foreign,downcall] ;; { argument shuffle [2.537s][trace][foreign,downcall] 0x0a0001000747d744: mr r12,r3 [2.537s][trace][foreign,downcall] 0x0a0001000747d748: extsw r3,r4 [2.537s][trace][foreign,downcall] 0x0a0001000747d74c: mr r4,r5 [2.537s][trace][foreign,downcall] 0x0a0001000747d750: mr r5,r6 [2.537s][trace][foreign,downcall] 0x0a0001000747d754: extsw r6,r7 [2.537s][trace][foreign,downcall] 0x0a0001000747d758: mr r7,r8 [2.537s][trace][foreign,downcall] ;; } argument shuffle The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend. A possible workaround would be to do the conversion in Java and passing it as long: diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java index ed520529ac8..573513b7bef 100644 --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java @@ -25,6 +25,7 @@ package com.sun.security.auth.module; +import jdk.internal.util.Architecture; import jdk.internal.util.OperatingSystem; import java.lang.foreign.AddressLayout; @@ -83,6 +84,8 @@ public class UnixSystem { = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char"); private static final ValueLayout.OfInt C_INT = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int"); + private static final ValueLayout.OfLong C_LONG + = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long"); private static final AddressLayout C_POINTER = ((AddressLayout) LINKER.canonicalLayouts().get("void*")) .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR)); @@ -110,10 +113,14 @@ public class UnixSystem { // getpwuid_r does not work on AIX, instead we use another similar function // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **) + // At least the following architecture require appropriate zero or sign extension to 64 bit. + private static final boolean calling_convention_requires_int_as_long = Architecture.isPPC64() || Architecture.isPPC64LE() || Architecture.isS390(); private static final MethodHandle getpwuid_r = LINKER .downcallHandle(SYMBOL_LOOKUP.findOrThrow( OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), - FunctionDescriptor.of(C_INT, C_INT, C_POINTER, C_POINTER, + FunctionDescriptor.of(C_INT, + calling_convention_requires_int_as_long ? C_LONG : C_INT, + C_POINTER, C_POINTER, OperatingSystem.isAix() ? C_INT : C_SIZE_T, C_POINTER)); @@ -179,11 +186,15 @@ public UnixSystem() { var pwd = scope.allocate(passwd_layout); var result = scope.allocate(C_POINTER); var buffer = scope.allocate(GETPW_R_SIZE_MAX); - var tmpUid = (int)getuid.invokeExact(); + long tmpUid = Integer.toUnsignedLong((int) getuid.invokeExact()); // Do not call invokeExact because the type of buffer_size is not // always long in the underlying system. - int out = (int) getpwuid_r.invoke( - tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result); + int out = 0; + if (calling_convention_requires_int_as_long) { + out = (int) getpwuid_r.invoke(tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result); + } else { + out = (int) getpwuid_r.invoke((int) tmpUid, pwd, buffer, GETPW_R_SIZE_MAX, result); + } if (out != 0 || result.get(ValueLayout.ADDRESS, 0).equals(MemorySegment.NULL)) { if (out != 0) { // If ERANGE (Result too large) is detected in a new platform, @@ -193,7 +204,7 @@ public UnixSystem() { } else { getpwuid_r_error = "the requested entry is not found"; } - uid = Integer.toUnsignedLong(tmpUid); + uid = tmpUid; gid = Integer.toUnsignedLong((int)getgid.invokeExact()); username = null; } else { But I don't really like it. I hope we can find a better solution. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662361633 From dmlloyd at openjdk.org Mon Jan 5 18:14:55 2026 From: dmlloyd at openjdk.org (David Lloyd) Date: Mon, 5 Jan 2026 18:14:55 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> Message-ID: On Mon, 5 Jan 2026 18:00:09 GMT, Martin Doerr wrote: >> I created fake account and group on my linux-x64 with numbers bigger than `Integer.MAX_VALUE` and call `getgroups` and `getpwuid_r`. The results always look good after a `Integer.toUnsignedLong()` conversion. >> >> I would think it's safe because it's only called after the C functions. > > What you have done is fine. Thanks! However, there is one potential problem left: > We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX): > > [2.537s][trace][foreign,downcall] ;; { argument shuffle > [2.537s][trace][foreign,downcall] 0x0a0001000747d744: mr r12,r3 > [2.537s][trace][foreign,downcall] 0x0a0001000747d748: extsw r3,r4 > [2.537s][trace][foreign,downcall] 0x0a0001000747d74c: mr r4,r5 > [2.537s][trace][foreign,downcall] 0x0a0001000747d750: mr r5,r6 > [2.537s][trace][foreign,downcall] 0x0a0001000747d754: extsw r6,r7 > [2.537s][trace][foreign,downcall] 0x0a0001000747d758: mr r7,r8 > [2.537s][trace][foreign,downcall] ;; } argument shuffle > > The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend. > > A possible workaround would be to do the conversion in Java and passing it as long: > > diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > index ed520529ac8..573513b7bef 100644 > --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java > @@ -25,6 +25,7 @@ > > package com.sun.security.auth.module; > > +import jdk.internal.util.Architecture; > import jdk.internal.util.OperatingSystem; > > import java.lang.foreign.AddressLayout; > @@ -83,6 +84,8 @@ public class UnixSystem { > = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char"); > private static final ValueLayout.OfInt C_INT > = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int"); > + private static final ValueLayout.OfLong C_LONG > + = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long"); > private static final AddressLayout C_POINTER > = ((AddressLayout) LINKER.canonicalLayouts().get("void*")) > .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR)); > @@ -110,10 +113,14 @@ public class UnixSystem { > > // getpwuid_r does not work on AIX, instead we use another similar function > // extern int _posix_getpwuid_r(uid_t, struct passwd *, char *, int, struct passwd **) > + ... FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662391104 From jsjolen at openjdk.org Mon Jan 5 19:21:11 2026 From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=) Date: Mon, 5 Jan 2026 19:21:11 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Mon, 5 Jan 2026 17:52:39 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> actually remove the class ... > > src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 392: > >> 390: private static ByteBuffer allocateBuffer(long size) { >> 391: if (size < 0 || Integer.MAX_VALUE < size) { >> 392: throw new IndexOutOfBoundsException("size"); > > I don't think it can happen but I assume IAE would be more appropriate here as size is not an index. Only needs to check for the `Integer.MAX_VALUE` in any case, as `ByteBuffer::allocateDirect` throws on `size < 0`. It also uses IAE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2662538975 From rriggs at openjdk.org Mon Jan 5 19:35:34 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 Jan 2026 19:35:34 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:41:31 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > actually remove the class ... Please update the issue with the change in scope of the change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29043#issuecomment-3711812793 From alanb at openjdk.org Mon Jan 5 19:41:17 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 5 Jan 2026 19:41:17 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:41:31 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > actually remove the class ... > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. I think we should leave the API docs as is as it allows for a ModuleReader to use off-heap memory in the future. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29043#issuecomment-3711830260 From duke at openjdk.org Mon Jan 5 19:58:29 2026 From: duke at openjdk.org (=?UTF-8?B?SmVhbi1Ob8OrbA==?= Rouvignac) Date: Mon, 5 Jan 2026 19:58:29 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:33:34 GMT, Joe Darcy wrote: > Add comment describing why Math.fma uses BigDecimal. src/java.base/share/classes/java/lang/Math.java line 2389: > 2387: // support for fma so and this method is an intrinsic > 2388: // candidate, the software implementation below would only > 2389: // used on processors without native fma support. Suggestion: // be used on processors without native fma support. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2662635935 From jnorlinder at openjdk.org Mon Jan 5 20:19:43 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 5 Jan 2026 20:19:43 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v2] In-Reply-To: References: 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. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Fixes from review ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28823/files - new: https://git.openjdk.org/jdk/pull/28823/files/efca77c5..458e1c34 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=00-01 Stats: 120 lines in 3 files changed: 60 ins; 56 del; 4 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 rriggs at openjdk.org Mon Jan 5 20:21:07 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 5 Jan 2026 20:21:07 GMT Subject: RFR: 8374544: Add SleepyCat diagnostics for all platforms Message-ID: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 ------------- Commit messages: - JDK-8374544: Add SleepyCat diagnostics for all platforms Changes: https://git.openjdk.org/jdk/pull/29047/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29047&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374544 Stats: 14 lines in 2 files changed: 0 ins; 7 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29047.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29047/head:pull/29047 PR: https://git.openjdk.org/jdk/pull/29047 From jnorlinder at openjdk.org Mon Jan 5 20:22:13 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Mon, 5 Jan 2026 20:22:13 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 11:49:19 GMT, Jonas Norlinder wrote: > # 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. Thanks for the review Alan. Pushed fixes. Here is a quick benchmark run with `RandomAccessFile` included. # Baseline Benchmark Mode Cnt Score Error Units OpenFileStress.testFileOutputStream sample 2471437 3812.476 ? 3.962 ns/op OpenFileStress.testRandomAccessFile sample 2468304 3817.273 ? 4.616 ns/op # Patch Benchmark Mode Cnt Score Error Units OpenFileStress.testFileOutputStream sample 1446195 3276.342 ? 7.779 ns/op OpenFileStress.testRandomAccessFile sample 1710040 3315.482 ? 6.024 ns/op (In case anyone asks: The microbenchmark checks for Windows as per discussions with @cl4es where we concluded that if we can make the tests run on any platform that is preferable?even if it really has nothing to do with this particular improvement.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28823#issuecomment-3711954521 From bpb at openjdk.org Mon Jan 5 20:49:23 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Mon, 5 Jan 2026 20:49:23 GMT Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava [v19] In-Reply-To: References: Message-ID: > This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows. Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 19 commits: - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - Merge - ... and 9 more: https://git.openjdk.org/jdk/compare/27dbdec2...c7446357 ------------- Changes: https://git.openjdk.org/jdk/pull/20317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=18 Stats: 1539 lines in 92 files changed: 774 ins; 668 del; 97 mod Patch: https://git.openjdk.org/jdk/pull/20317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317 PR: https://git.openjdk.org/jdk/pull/20317 From weijun at openjdk.org Mon Jan 5 21:34:16 2026 From: weijun at openjdk.org (Weijun Wang) Date: Mon, 5 Jan 2026 21:34:16 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> Message-ID: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> On Mon, 5 Jan 2026 18:12:08 GMT, David Lloyd wrote: >> What you have done is fine. Thanks! However, there is one potential problem left: >> We are passing `tmpUid` to `getpwuid_r` as an `int`. That results in the following sequence (example from AIX): >> >> [2.537s][trace][foreign,downcall] ;; { argument shuffle >> [2.537s][trace][foreign,downcall] 0x0a0001000747d744: mr r12,r3 >> [2.537s][trace][foreign,downcall] 0x0a0001000747d748: extsw r3,r4 >> [2.537s][trace][foreign,downcall] 0x0a0001000747d74c: mr r4,r5 >> [2.537s][trace][foreign,downcall] 0x0a0001000747d750: mr r5,r6 >> [2.537s][trace][foreign,downcall] 0x0a0001000747d754: extsw r6,r7 >> [2.537s][trace][foreign,downcall] 0x0a0001000747d758: mr r7,r8 >> [2.537s][trace][foreign,downcall] ;; } argument shuffle >> >> The 4 Byte value for `tmpUid` is taken from Register r4, sign extended to 8 Byte long and put into the first argument register r3. The sign extend is wrong because `uid` is an `uint32_t`. That violates the calling convention. We have no way to tell the FFM that we need zero extend. >> >> A possible workaround would be to do the conversion in Java and passing it as long: >> >> diff --git a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java >> index ed520529ac8..573513b7bef 100644 >> --- a/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java >> +++ b/src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java >> @@ -25,6 +25,7 @@ >> >> package com.sun.security.auth.module; >> >> +import jdk.internal.util.Architecture; >> import jdk.internal.util.OperatingSystem; >> >> import java.lang.foreign.AddressLayout; >> @@ -83,6 +84,8 @@ public class UnixSystem { >> = (ValueLayout.OfByte) LINKER.canonicalLayouts().get("char"); >> private static final ValueLayout.OfInt C_INT >> = (ValueLayout.OfInt) LINKER.canonicalLayouts().get("int"); >> + private static final ValueLayout.OfLong C_LONG >> + = (ValueLayout.OfLong) LINKER.canonicalLayouts().get("long"); >> private static final AddressLayout C_POINTER >> = ((AddressLayout) LINKER.canonicalLayouts().get("void*")) >> .withTargetLayout(MemoryLayout.sequenceLayout(java.lang.Long.MAX_VALUE, C_CHAR)); >> @@ -110,10 +113,14 @@ public class UnixSystem { >> >> // getpwuid_r does not work on AIX, instead we use another similar function >> // exter... > > FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664 \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2662861217 From darcy at openjdk.org Mon Jan 5 21:56:18 2026 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 5 Jan 2026 21:56:18 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v2] In-Reply-To: References: Message-ID: > Add comment describing why Math.fma uses BigDecimal. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Respond to review feedback and add conclusion. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29044/files - new: https://git.openjdk.org/jdk/pull/29044/files/309afbc2..c1dac46a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29044&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29044&range=00-01 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29044/head:pull/29044 PR: https://git.openjdk.org/jdk/pull/29044 From almatvee at openjdk.org Mon Jan 5 22:54:54 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Mon, 5 Jan 2026 22:54:54 GMT Subject: RFR: 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 02:02:44 GMT, Alexey Semenyuk wrote: > Remove the "error.explicit-sign-no-cert" error message, which duplicates the "error.cert.not.found" error message. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29025#pullrequestreview-3628662895 From psandoz at openjdk.org Tue Jan 6 00:55:29 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 6 Jan 2026 00:55:29 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:11:19 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 eight commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - wrap the test loop within a try/catch to speed up the tests > - Refine the tests for identity values > - 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. This looks good. Before we integrate we will run it through our test system and report back to you. ------------- Marked as reviewed by psandoz (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28692#pullrequestreview-3628897605 From jpai at openjdk.org Tue Jan 6 01:40:20 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 01:40:20 GMT Subject: RFR: 8374544: Add SleepyCat diagnostics for all platforms In-Reply-To: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> References: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> Message-ID: On Mon, 5 Jan 2026 20:14:21 GMT, Roger Riggs wrote: > To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. > On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 Hello Roger, the changes look OK to me. The copyright year on the test file will need an update. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29047#pullrequestreview-3629012918 From bpb at openjdk.org Tue Jan 6 02:03:25 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 02:03:25 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified Message-ID: If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. ------------- Commit messages: - 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified Changes: https://git.openjdk.org/jdk/pull/29052/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29052&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372377 Stats: 13 lines in 1 file changed: 11 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29052/head:pull/29052 PR: https://git.openjdk.org/jdk/pull/29052 From dholmes at openjdk.org Tue Jan 6 02:24:41 2026 From: dholmes at openjdk.org (David Holmes) Date: Tue, 6 Jan 2026 02:24:41 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 08:48:15 GMT, SendaoYan wrote: >> 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 A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. test/lib/jdk/test/lib/containers/cgroup/MetricsTester.java line 87: > 85: public static void main(String[] args) throws Exception { > 86: Metrics m = Metrics.systemMetrics(); > 87: // If cgroups is not configured, report success Suggestion: // If cgroups is not configured, the test is skipped. test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > 371: long oldVal = metrics.getCpuPeriod(); > 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { > 373: System.out.println("Get cpu period fails, test skipped."); Note sure this indicates a "fail" as such. ------------- PR Review: https://git.openjdk.org/jdk/pull/28996#pullrequestreview-3629079111 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663353307 PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663359000 From syan at openjdk.org Tue Jan 6 02:52:18 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 02:52:18 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v5] 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 comment "If cgroups is not configured, the test is skipped." which suggestion from @dholmes-ora Co-authored-by: David Holmes <62092539+dholmes-ora at users.noreply.github.com> ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28996/files - new: https://git.openjdk.org/jdk/pull/28996/files/068b1591..8e2ee419 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28996&range=03-04 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 syan at openjdk.org Tue Jan 6 03:04:21 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:04:21 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: <5qxuuuhHvgrHEPlLUV-O8Ngykq5lufQ5n_IbmXxeu0k=.65dc5916-245b-412b-a60f-1c0058464051@github.com> On Tue, 6 Jan 2026 02:19:32 GMT, David Holmes wrote: >> 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 > > test/lib/jdk/test/lib/containers/cgroup/MetricsTesterCgroupV1.java line 373: > >> 371: long oldVal = metrics.getCpuPeriod(); >> 372: if (oldVal == CgroupSubsystem.LONG_RETVAL_UNLIMITED) { >> 373: System.out.println("Get cpu period fails, test skipped."); > > Note sure this indicates a "fail" as such. The `getCpuPeriod` call `getLongValue` to read property value from file /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us. The `getLongValue` will return CgroupSubsystem.LONG_RETVAL_UNLIMITED if it can not open the file. So I think it's better to skip this sub-test when there is no /sys/fs/cgroup/cpu,cpuacct/system.slice/sshd.service/cpu.cfs_period_us file. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28996#discussion_r2663425108 From syan at openjdk.org Tue Jan 6 03:08:51 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 6 Jan 2026 03:08:51 GMT Subject: RFR: 8374364: TestCgroupMetrics.java fails when cpuset unmounted [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 02:21:44 GMT, David Holmes wrote: > A couple of comments but I'm not sure what the right approach is here. Seems inconsistent to use SkippedException in one place, but not others. This PR use SkippedException instead of report test pass. It's unrelated to the subject, It just fix it by the way ------------- PR Comment: https://git.openjdk.org/jdk/pull/28996#issuecomment-3712926235 From jpai at openjdk.org Tue Jan 6 04:47:23 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 04:47:23 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 01:55:16 GMT, Brian Burkhalter wrote: > If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. Hello Brian, this looks OK to me. Would this same check be needed in the `testFile()` method where too the `Space` constructor gets called? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29052#pullrequestreview-3629345191 From alanb at openjdk.org Tue Jan 6 06:13:24 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 06:13:24 GMT Subject: RFR: 8370216: Fix of new File("").exists() causes undefined behavior in libraries In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:14:44 GMT, Brian Burkhalter wrote: > Add a system property, `jdk.io.File.failIfEmptyPath`, which when `true` reverts to legacy, pre-JDK 25 behavior, as to how `java.io.File` handles an empty pathname string. The store has moved on since the PR was created. I assume we will need to update the File class description to allow this. ------------- Changes requested by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28158#pullrequestreview-3629547682 From alanb at openjdk.org Tue Jan 6 06:46:54 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 06:46:54 GMT Subject: RFR: 8369227: Virtual thread stuck in PARKED state Message-ID: A regression since we changed the VirtualThread implementation to use use FJP delayed task handling (JDK-8351927) in JDK 25. If a virtual thread does a timed-park, followed immediately by an untimed-park, while racing with both an async unpark and the execution of cancelled timeout-task, then it is possible for the virtual thread to get stuck in the parked state. More specifically, it is possible for stars to align to create the scenario where parkTimeoutExpired makes available the parking permit but it doesn't continue the thread because it has moved on to an untimed-park. A small oversight that crept in when the timeout support was migrated to use the new delay scheduler. Testing: tier1-5. New stress tests added, and existing stress test TimedWaitALot updated. ------------- Commit messages: - Test pinned case too - Merge branch 'master' into JDK-8369227 - Merge branch 'master' into JDK-8369227 - Merge branch 'master' into JDK-8369227 - Initial commit Changes: https://git.openjdk.org/jdk/pull/29011/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29011&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369227 Stats: 165 lines in 3 files changed: 143 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29011.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29011/head:pull/29011 PR: https://git.openjdk.org/jdk/pull/29011 From vklang at openjdk.org Tue Jan 6 06:46:55 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 6 Jan 2026 06:46:55 GMT Subject: RFR: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 08:08:49 GMT, Alan Bateman wrote: > A regression since we changed the VirtualThread implementation to use use FJP delayed task handling (JDK-8351927) in JDK 25. > > If a virtual thread does a timed-park, followed immediately by an untimed-park, while racing with both an async unpark and the execution of cancelled timeout-task, then it is possible for the virtual thread to get stuck in the parked state. More specifically, it is possible for stars to align to create the scenario where parkTimeoutExpired makes available the parking permit but it doesn't continue the thread because it has moved on to an untimed-park. A small oversight that crept in when the timeout support was migrated to use the new delay scheduler. > > Testing: tier1-5. New stress tests added, and existing stress test TimedWaitALot updated. src/java.base/share/classes/java/lang/VirtualThread.java line 920: > 918: private void parkTimeoutExpired() { > 919: assert !VirtualThread.currentThread().isVirtual(); > 920: unpark(true); @AlanBateman There's a slight semantic difference here now, where parkTimeoutExpired can now transition from both PARKED and TIMED_PARKED where before it could only transition from TIME_PARKED. Is this change intentional, and if not, it might be better to duplicate the logic in parkTimeoutExpired and unpark (but filtering on TIMED_PARKED and PARKED respectively). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29011#discussion_r2662139857 From alanb at openjdk.org Tue Jan 6 06:46:57 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 06:46:57 GMT Subject: RFR: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 16:44:17 GMT, Viktor Klang wrote: >> A regression since we changed the VirtualThread implementation to use use FJP delayed task handling (JDK-8351927) in JDK 25. >> >> If a virtual thread does a timed-park, followed immediately by an untimed-park, while racing with both an async unpark and the execution of cancelled timeout-task, then it is possible for the virtual thread to get stuck in the parked state. More specifically, it is possible for stars to align to create the scenario where parkTimeoutExpired makes available the parking permit but it doesn't continue the thread because it has moved on to an untimed-park. A small oversight that crept in when the timeout support was migrated to use the new delay scheduler. >> >> Testing: tier1-5. New stress tests added, and existing stress test TimedWaitALot updated. > > src/java.base/share/classes/java/lang/VirtualThread.java line 920: > >> 918: private void parkTimeoutExpired() { >> 919: assert !VirtualThread.currentThread().isVirtual(); >> 920: unpark(true); > > @AlanBateman There's a slight semantic difference here now, where parkTimeoutExpired can now transition from both PARKED and TIMED_PARKED where before it could only transition from TIME_PARKED. Is this change intentional, and if not, it might be better to duplicate the logic in parkTimeoutExpired and unpark (but filtering on TIMED_PARKED and PARKED respectively). It is intentional. Whoever makes available the parking permit must unpark the virtual thread if it is parked. This includes the untimed, timed, and pinned cases. In this case, parkTimeoutExpired could be racing with unpark, or a "cancelled" parkTimeoutExpired could be racing with unpark. The change in this PR just restores the behavior to what we had before changing it to use the FJP delay scheduler. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29011#discussion_r2662198773 From alanb at openjdk.org Tue Jan 6 07:00:50 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 07:00:50 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 01:55:16 GMT, Brian Burkhalter wrote: > If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. What would you think about changing Space's constructor to throw IOException to remove the confusing RuntimeException from this test. For testFile then I assume we should allow it to continue to fail. Something would be very broken in the test environment if the volume containing the temp dir disappears or fails while in use. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29052#issuecomment-3713376081 From alanb at openjdk.org Tue Jan 6 07:32:36 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 07:32:36 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 21:56:18 GMT, Joe Darcy wrote: >> Add comment describing why Math.fma uses BigDecimal. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback and add conclusion. src/java.base/share/classes/java/lang/Math.java line 2389: > 2387: // support for fma and this method is an intrinsic candidate, > 2388: // the software implementation below would only be used on > 2389: // processors without native fma support. Therefore, the It will be used when in the interpreter too, which it think confuses people sometimes as they modify the Java code and see that the modified code executes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2663934822 From xgong at openjdk.org Tue Jan 6 07:40:58 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Tue, 6 Jan 2026 07:40:58 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 [v2] In-Reply-To: <72RiEFo5wji1vOtIRzFwO03_0OsaCe2zzHjp9YPD8-k=.6a88f4eb-3fff-4fe5-bb43-260d81b7954a@github.com> References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> <72RiEFo5wji1vOtIRzFwO03_0OsaCe2zzHjp9YPD8-k=.6a88f4eb-3fff-4fe5-bb43-260d81b7954a@github.com> Message-ID: On Mon, 5 Jan 2026 11:31:26 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 ... > > Yi Wu 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: > > - Replace assert with verify > - Add IRNode constant and code refactor > - Merge remote-tracking branch 'origin/master' into yiwu-8373344 > - 8373344: Add support for FP16 min/max reduction operations > > 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 t... src/hotspot/cpu/aarch64/aarch64_vector.ad line 381: > 379: case Op_XorReductionV: > 380: case Op_MinReductionVHF: > 381: case Op_MaxReductionVHF: We can use the NEON instructions if the vector size <= 16B as well for partial cases. Did you test the performance with NEON instead of using predicated SVE instructions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2663933727 From vyazici at openjdk.org Tue Jan 6 08:23:16 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 6 Jan 2026 08:23:16 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics Message-ID: Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210]. [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 ------------- Commit messages: - Revert "8361842: Move input validation checks to Java for java.lang.StringCoding intrinsics" Changes: https://git.openjdk.org/jdk/pull/29055/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29055&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374523 Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/29055.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29055/head:pull/29055 PR: https://git.openjdk.org/jdk/pull/29055 From vyazici at openjdk.org Tue Jan 6 08:23:16 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 6 Jan 2026 08:23:16 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Tier 1-3 are clear on c8acc80b8c6. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713645184 From alanb at openjdk.org Tue Jan 6 08:30:21 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 08:30:21 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:19:43 GMT, Jonas Norlinder wrote: >> # 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. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fixes from review Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28823#pullrequestreview-3629926450 From vyazici at openjdk.org Tue Jan 6 08:40:39 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 6 Jan 2026 08:40:39 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Matching the labels with #25998 that this PR is reverting: ------------- PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3713697821 From eirbjo at openjdk.org Tue Jan 6 08:55:47 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 6 Jan 2026 08:55:47 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 21:56:18 GMT, Joe Darcy wrote: >> Add comment describing why Math.fma uses BigDecimal. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Respond to review feedback and add conclusion. src/java.base/share/classes/java/lang/Math.java line 2381: > 2379: @IntrinsicCandidate > 2380: public static double fma(double a, double b, double c) { > 2381: // Implementation note: this method is intentionally coded in The note seems currently structured as: * Actual implementation design * Hypothetical/alternative implementation design * Performance context * Actual implementation design ("-ilities") The part suggesting how an alternative Java implementation could be made more performant seems counterproductive or at the least unnecessary. I think the structure can be simplified as: * Performance context * Actual implementation design/"-ilities" Here's a sketch intended to demonstrate the suggested stucture (needs work for correctness, grammar, etc.): // The Java implementation below will only be used where intrinsics // using hardware fma support is not available. // Therefore, simplicity, maintainability, and ease of testing // of the code is more important than direct performance. // The implementation is intentinally kept straightforward, // relying on BigDecimal for numerical computation. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2664155997 From shade at openjdk.org Tue Jan 6 09:14:15 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 6 Jan 2026 09:14:15 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 This does not look like a clean backout -- the incoming/outgoing line counts do not match against the original commit -- so extra caution is needed in reviews. Apart from the inadverent (?) addition in `JavaLangAccess.java`, there seem to be hunk differences in some `sun/nio/cs` files; I assume those are intentional? src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455: > 453: * compatible. > 454: *

> 455: * WARNING: This method does not perform any bound checks. These two lines are not in the original commit? https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740 ------------- PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630055594 PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664196789 From vyazici at openjdk.org Tue Jan 6 09:59:56 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 6 Jan 2026 09:59:56 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 09:06:27 GMT, Aleksey Shipilev wrote: >> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. >> >> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 >> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 > > src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455: > >> 453: * compatible. >> 454: *

>> 455: * WARNING: This method does not perform any bound checks. > > These two lines are not in the original commit? > > https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740 In chronological order: 1. 8fcfddb2d202 renamed `encodeASCII` to `uncheckedEncodeASCII` and added the `WARNING` clause. 2. 655dc516c22a, the commit this PR is reverting, renamed the method back to `encodeASCII` and removed the `WARNING`. This was possible, since `StringCoding::implEncodeAsciiArray` was hardened with necessary checks in the very same commit. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664348820 From duke at openjdk.org Tue Jan 6 10:09:58 2026 From: duke at openjdk.org (duke) Date: Tue, 6 Jan 2026 10:09:58 GMT Subject: RFR: 8373476 : (tz) Update Timezone Data to 2025c In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> Message-ID: On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose wrote: > tzdata changes for 2025c @johnyjose30 Your change (at version 512f7a5dcb5340647720760b847a52f15bcfd98a) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29029#issuecomment-3714052685 From duke at openjdk.org Tue Jan 6 10:09:59 2026 From: duke at openjdk.org (Johny Jose) Date: Tue, 6 Jan 2026 10:09:59 GMT Subject: RFR: 8373476 : (tz) Update Timezone Data to 2025c In-Reply-To: References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> Message-ID: On Mon, 5 Jan 2026 17:42:08 GMT, Naoto Sato wrote: >> tzdata changes for 2025c > > src/java.base/share/data/tzdata/iso3166.tab line 44: > >> 42: # ?Czech Republic? and ?Turkey? rather than ?Czechia? and ?T?rkiye?), >> 43: # and sometimes to omit needless detail or churn (e.g., ?Netherlands? >> 44: # rather than ?Netherlands (the)? or ?Netherlands (Kingdom of the)?). > > It's interesting that they started using non-ASCII quotes in comments, which is different from our policy, but we need to live with it as it is the upstream change Updated Jira ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29029#discussion_r2664372684 From vyazici at openjdk.org Tue Jan 6 10:10:59 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 6 Jan 2026 10:10:59 GMT Subject: RFR: 8374523: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 09:10:53 GMT, Aleksey Shipilev wrote: > there seem to be hunk differences in some `sun/nio/cs` files; I assume those are intentional? Yes, they are clean reverts of the associated files changed in 655dc516c22a. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3714049430 From alanb at openjdk.org Tue Jan 6 10:27:26 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 10:27:26 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set Message-ID: Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/29059/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29059&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373427 Stats: 7 lines in 1 file changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29059/head:pull/29059 PR: https://git.openjdk.org/jdk/pull/29059 From duke at openjdk.org Tue Jan 6 10:27:41 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 10:27:41 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v3] In-Reply-To: References: Message-ID: <-ZJPqUsvDA7pVNKNf4aRgUUQxoKRHLXlNrPmQQJHee4=.3fa7f148-08fa-4ef2-a2ad-23c162cace09@github.com> > Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. > > I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). > > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: copyright update ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29043/files - new: https://git.openjdk.org/jdk/pull/29043/files/5a37317e..e3bbc4c5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=01-02 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29043/head:pull/29043 PR: https://git.openjdk.org/jdk/pull/29043 From duke at openjdk.org Tue Jan 6 10:32:36 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 10:32:36 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Mon, 5 Jan 2026 19:14:12 GMT, Johan Sj?len wrote: >> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 392: >> >>> 390: private static ByteBuffer allocateBuffer(long size) { >>> 391: if (size < 0 || Integer.MAX_VALUE < size) { >>> 392: throw new IndexOutOfBoundsException("size"); >> >> I don't think it can happen but I assume IAE would be more appropriate here as size is not an index. > > Only needs to check for the `Integer.MAX_VALUE` in any case, as `ByteBuffer::allocateDirect` throws on `size < 0`. It also uses IAE Fair points. This is just moved code, but IOOBE is clearly not the right choice here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664444964 From duke at openjdk.org Tue Jan 6 10:37:16 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 10:37:16 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Tue, 6 Jan 2026 10:29:14 GMT, David Beaumont wrote: >> src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 394: >> >>> 392: throw new IndexOutOfBoundsException("size"); >>> 393: } >>> 394: ByteBuffer result = ByteBuffer.allocateDirect((int) ((size + 0xFFF) & ~0xFFF)); >> >> Can you remind me why it allocates multiples of 4k? >> >> Also, would be useful to know if using ByteByte.allocate (to allocate a heap buffer) would be okay here. > > I can't, I've never seen this code before. No comments, no tests for why 4k is a good size. Probably just a "page size" heuristic. I'm just removing dead code and moving what's not dead out of the class to be deleted. > > Changing details beyond that should probably be a different PR. Actually, thinking about this more, it would have the benefit (in the situation where caching happens) of making buckets more likely to be reususeable, so if we're willing to assume that, and since the cache is going away, we could justify dropping the rounding and just allocating the exact size. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664458010 From duke at openjdk.org Tue Jan 6 10:32:40 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 10:32:40 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Mon, 5 Jan 2026 17:51:56 GMT, Alan Bateman wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> actually remove the class ... > > src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 394: > >> 392: throw new IndexOutOfBoundsException("size"); >> 393: } >> 394: ByteBuffer result = ByteBuffer.allocateDirect((int) ((size + 0xFFF) & ~0xFFF)); > > Can you remind me why it allocates multiples of 4k? > > Also, would be useful to know if using ByteByte.allocate (to allocate a heap buffer) would be okay here. I can't, I've never seen this code before. No comments, no tests for why 4k is a good size. Probably just a "page size" heuristic. I'm just removing dead code and moving what's not dead out of the class to be deleted. Changing details beyond that should probably be a different PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664442989 From duke at openjdk.org Tue Jan 6 10:42:21 2026 From: duke at openjdk.org (Johny Jose) Date: Tue, 6 Jan 2026 10:42:21 GMT Subject: Integrated: 8373476 : (tz) Update Timezone Data to 2025c In-Reply-To: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> References: <3O30FDn_YYGrefjF0MMHyuR9_jblBwjU3ZCHyhqJ5HU=.98a2a89b-a6e8-42e5-9894-3f2ac1727f04@github.com> Message-ID: On Mon, 5 Jan 2026 08:33:32 GMT, Johny Jose wrote: > tzdata changes for 2025c This pull request has now been integrated. Changeset: 5df183be Author: Johny Jose Committer: Sean Coffey URL: https://git.openjdk.org/jdk/commit/5df183be6c484d8f9635fac149caf5e2079c5561 Stats: 132 lines in 11 files changed: 67 ins; 8 del; 57 mod 8373476: (tz) Update Timezone Data to 2025c Reviewed-by: coffeys, naoto ------------- PR: https://git.openjdk.org/jdk/pull/29029 From duke at openjdk.org Tue Jan 6 10:49:42 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 10:49:42 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Tue, 6 Jan 2026 10:30:00 GMT, David Beaumont wrote: >> Only needs to check for the `Integer.MAX_VALUE` in any case, as `ByteBuffer::allocateDirect` throws on `size < 0`. It also uses IAE > > Fair points. This is just moved code, but IOOBE is clearly not the right choice here. In fact, taking a more holistic view, the size check is already done by the caller, so there's some nice simplification possible here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664504433 From alanb at openjdk.org Tue Jan 6 10:49:43 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 10:49:43 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Tue, 6 Jan 2026 10:34:27 GMT, David Beaumont wrote: >> I can't, I've never seen this code before. No comments, no tests for why 4k is a good size. Probably just a "page size" heuristic. I'm just removing dead code and moving what's not dead out of the class to be deleted. >> >> Changing details beyond that should probably be a different PR. > > Actually, thinking about this more, it would have the benefit (in the situation where caching happens) of making buckets more likely to be reususeable, so if we're willing to assume that, and since the cache is going away, we could justify dropping the rounding and just allocating the exact size. I can't see any reason to round up now so I think we should remove it. I don't mind if its this PR or a separate PR. I'm interested to know if this can be changed to use allocate as it doesn't need a direct buffer here. FileChannel.read uses the thread-local buffer cache when called with a heap-buffer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664493810 From shade at openjdk.org Tue Jan 6 10:55:36 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 6 Jan 2026 10:55:36 GMT Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Marked as reviewed by shade (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630455590 From thartmann at openjdk.org Tue Jan 6 10:55:36 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 6 Jan 2026 10:55:36 GMT Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29055#pullrequestreview-3630459848 From shade at openjdk.org Tue Jan 6 10:55:38 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 6 Jan 2026 10:55:38 GMT Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 09:57:02 GMT, Volkan Yazici wrote: >> src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java line 455: >> >>> 453: * compatible. >>> 454: *

>>> 455: * WARNING: This method does not perform any bound checks. >> >> These two lines are not in the original commit? >> >> https://github.com/openjdk/jdk/commit/655dc516c22ac84fccee6b1fdc607c492465be6b#diff-bd92d760986b9249dd3c02cc147db4f7e9dbbef90afef4971ee497a50e48c740 > > In chronological order: > > 1. 8fcfddb2d202 renamed `encodeASCII` to `uncheckedEncodeASCII` and added the `WARNING` clause. > 2. 655dc516c22a, the commit this PR is reverting, renamed the method back to `encodeASCII` and removed the `WARNING`. This was possible, since `StringCoding::implEncodeAsciiArray` was hardened with necessary checks in the very same commit. Ah yes, I misread, apologies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29055#discussion_r2664514651 From jpai at openjdk.org Tue Jan 6 11:00:44 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 11:00:44 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:09:21 GMT, Alan Bateman wrote: > Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29059#pullrequestreview-3630471317 From duke at openjdk.org Tue Jan 6 11:03:45 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 11:03:45 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v4] In-Reply-To: References: Message-ID: > Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. > > I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). > > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. David Beaumont has updated the pull request incrementally with one additional commit since the last revision: simplifying allocation and argument checks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29043/files - new: https://git.openjdk.org/jdk/pull/29043/files/e3bbc4c5..7d54c8e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29043&range=02-03 Stats: 18 lines in 1 file changed: 2 ins; 10 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29043.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29043/head:pull/29043 PR: https://git.openjdk.org/jdk/pull/29043 From duke at openjdk.org Tue Jan 6 11:03:46 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 11:03:46 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v2] In-Reply-To: References: <9jKLysiqb1xp8RktL_3Il1okoXowwX5dcsC_U-VgJmo=.1d5a4709-b622-423d-8576-6d91088a7cdb@github.com> Message-ID: On Tue, 6 Jan 2026 10:47:04 GMT, David Beaumont wrote: >> Fair points. This is just moved code, but IOOBE is clearly not the right choice here. > > In fact, taking a more holistic view, the size check is already done by the caller, so there's some nice simplification possible here. You *do* need a negative check when using long because of underflow. If longValue is 0xFFFFFFFF00000001 (negative, invalid) then '(int) longValue' is 1 (positive, valid). https://docs.oracle.com/javase/specs/jls/se7/html/jls-5.html#jls-5.1.3 Or you could use a different style of check: int intValue = (int) longValue; if (intValue != longValue) { throw ... } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664543524 From michaelm at openjdk.org Tue Jan 6 11:13:14 2026 From: michaelm at openjdk.org (Michael McMahon) Date: Tue, 6 Jan 2026 11:13:14 GMT Subject: RFR: 8374342: Remove incorrect @throws NoSuchFileException from FileUtils.java In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 01:06:33 GMT, Eunbin Son wrote: > ### 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 This seems reasonable. You will need to update the PR title to match the change I made to the bug title. ------------- Marked as reviewed by michaelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28985#pullrequestreview-3630510921 From duke at openjdk.org Tue Jan 6 11:27:16 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 11:27:16 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v4] In-Reply-To: References: Message-ID: <8472Adw0JOVpFYa4ua8tu7XnwD6T1KuAF0ItW6YT3Bw=.29f52a46-ebdd-4bc0-8cbe-02e6d36c7ab2@github.com> On Tue, 6 Jan 2026 11:03:45 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > simplifying allocation and argument checks src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 373: > 371: throw new InternalError("Image file channel not open"); > 372: } > 373: ByteBuffer buffer = ByteBuffer.allocate(checkedSize); I changed this to just "allocate" (not "allocateDirect") after carefully reading up on direct buffers. It's just possible this might have an observable effect (positive or negative) on either performance or memory pressure, so I'm happy to change it back if people are worried. It's the only bit of this change that I think might not be a guaranteed no-op. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664605202 From duke at openjdk.org Tue Jan 6 11:31:47 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 11:31:47 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 11:03:45 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > simplifying allocation and argument checks src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 390: > 388: } > 389: > 390: if (read != size) { Since the size check already happened in the caller, this check is never triggered, and if the rounding is removed, the limit() call isn't needed, so this method collapses into a single allocate method call which can be inlined. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664615982 From msheppar at openjdk.org Tue Jan 6 11:41:52 2026 From: msheppar at openjdk.org (Mark Sheppard) Date: Tue, 6 Jan 2026 11:41:52 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 09:42:35 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 continue... > > Jaikiran Pai 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: > > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds test/jdk/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java line 111: > 109: System.err.println("waiting for unreferenced() callback..."); > 110: callbackInvocationLatch.await(); > 111: Instant waitEndedAt = Instant.now(); 111 - 126 refactor extract method isWithinExpectedTimeLimit simpllifies reading of test, and lucidly expresses the logic of the time evaluation ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28919#discussion_r2664640429 From alanb at openjdk.org Tue Jan 6 12:12:22 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 12:12:22 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v4] In-Reply-To: References: Message-ID: <5p2fCaf3URXGuC4Hei1z63I0jFf0UtW2si-NdADg0wg=.9ea137db-394d-4c96-81bc-86c4946a0b03@github.com> On Tue, 6 Jan 2026 11:03:45 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > simplifying allocation and argument checks Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29043#pullrequestreview-3630670627 From alanb at openjdk.org Tue Jan 6 12:12:25 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 12:12:25 GMT Subject: RFR: 8374308: ImageBufferCache does not work as intended [v4] In-Reply-To: <8472Adw0JOVpFYa4ua8tu7XnwD6T1KuAF0ItW6YT3Bw=.29f52a46-ebdd-4bc0-8cbe-02e6d36c7ab2@github.com> References: <8472Adw0JOVpFYa4ua8tu7XnwD6T1KuAF0ItW6YT3Bw=.29f52a46-ebdd-4bc0-8cbe-02e6d36c7ab2@github.com> Message-ID: <6igM814uxVvgL9oQju52YweNR3DNzeL5qNYU7lMXLa4=.da80bac0-a6cc-488a-a28c-aa5ef72359d9@github.com> On Tue, 6 Jan 2026 11:23:29 GMT, David Beaumont wrote: >> David Beaumont has updated the pull request incrementally with one additional commit since the last revision: >> >> simplifying allocation and argument checks > > src/java.base/share/classes/jdk/internal/jimage/BasicImageReader.java line 373: > >> 371: throw new InternalError("Image file channel not open"); >> 372: } >> 373: ByteBuffer buffer = ByteBuffer.allocate(checkedSize); > > I changed this to just "allocate" (not "allocateDirect") after carefully reading up on direct buffers. > It's just possible this might have an observable effect (positive or negative) on either performance or memory pressure, so I'm happy to change it back if people are worried. > > It's the only bit of this change that I think might not be a guaranteed no-op. It avoids allocating direct memory and leaving it to GC reference processing to free, so I think better than just removing the caching. It should have no impact on usage at runtime, at least not the main stream platforms that are 64-bit and thus memory map the jimage file. On 64-bit, the built-in class loaders and other usages at runtime use slices of the mapping rather rather than allocate. I think ARM is the only 32-bit port that is still maintained to some degree. 32-bit, and jrtfs when targeting a different run-time image, and the only cases that will use file I/O. I would expect at least some tests for javac -system should exercise this code, and we should have a few jimage tests that run with `-Djdk.image.map.all=false` to exercise this code (maybe we need more). If you want, you could increase confidence by testing with `TEST_OPTS_JAVA_OPTIONS=-Djdk.image.map.all=false`. Also since we are early in JDK 27 it means there is time for course correction in case any creepy crawlies come out of the woodwork. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29043#discussion_r2664718547 From djgredler at gmail.com Tue Jan 6 14:01:05 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Tue, 6 Jan 2026 15:01:05 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> Message-ID: Hi Roger, Thanks for the feedback, I've created an issue in JBS [1] and will create the PR in the coming days. This method currently throws an OOME if a negative capacity is requested, but that should never happen because it's only called internally after careful parameter validation. Once it's public, users will be able to request negative capacities directly. For the public API, I'm leaning towards quietly ignoring calls with non-positive capacities, a la `AbstractStringBuilder`, instead of throwing an OOME. Let me know if you agree? Also, do you know what the maximum possible requested capacity is here? It would be good to avoid the need for follow-up issues like this one [2] for `ArrayList`. Take care, Daniel [1] https://bugs.openjdk.org/browse/JDK-8374610 [2] https://bugs.openjdk.org/browse/JDK-8258565 On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs wrote: > Hi Daniel, > > That seems reasonable, allowing control over the timing of resizes. > Making it public is sensible too. > > From a higher point of view, are you sure you want to be working with > ByteArrayOutputStream and not ByteBuffer or Memory Segments? There are > more performance possibilities with those APIs. > > Regards, Roger > > > On 1/5/26 7:15 AM, Daniel Gredler wrote: > > Hi, > > > > I was recently looking at subclassing `ByteArrayOutputStream` in an > > application so that I could add a fast VarHandle-based > > `writeLong(long)` method (writing 8 bytes to the byte array in one > > go). The internal `ByteArrayOutputStream` buffer is protected, so no > > issue there, but `ensureCapacity(int)` is private rather than > > protected, and uses the internal `ArraysSupport` class, so it's not > > even easy to copy/paste as duplicate code in the subclass. Similar > > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are > > public. Would a PR adjusting the visibility of this method from > > private to protected be accepted? > > > > Take care, > > > > Daniel > > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vklang at openjdk.org Tue Jan 6 14:16:01 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 6 Jan 2026 14:16:01 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: <8gAwM6XaY-FM_Sg9st2JtcAAMCc-pKUQ_QY3CIn_k-o=.02334644-8b01-474b-ba01-0a3b6261b383@github.com> On Tue, 6 Jan 2026 10:09:21 GMT, Alan Bateman wrote: > Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1087: > 1085: * exception outcome is obtained, this method may not be invoked again. The only > 1086: * case where this method may be called again by the scope owner is after > 1087: * {@code InterruptedException} is thrown. Just offering a potential alternative formulation. `This method must only be called once, unless the previous invocation resulted in an {@code InterruptedException} being thrown.` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29059#discussion_r2665059665 From vklang at openjdk.org Tue Jan 6 14:20:07 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 6 Jan 2026 14:20:07 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:56:56 GMT, Jaikiran Pai wrote: >> Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. > > This looks good to me. I see @jaikiran is already on this, so I'll just chime in and say that it looks good from my perspective. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29059#issuecomment-3714865142 From roger.riggs at oracle.com Tue Jan 6 14:54:36 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 6 Jan 2026 09:54:36 -0500 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> Message-ID: <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> Hi Daniel, I don't think you could call it `ensureCapacity()` if it ignores the request. The limit is not specified, different VMs have different overheads. The exception and message are appropriate: "java.lang.OutOfMemoryError: Requested array size exceeds VM limit " For negative arguments, an IllegalArgumentException might be an improvement in usability for developers. [2] 8258565 is closed as "will not fix" because the memory limits are an implementation parameter, not specified. Thanks, Roger p.s. as an API change it will need a CSR. There's a "create a CSR" menu item on the issue and a template to fill out. On 1/6/26 9:01 AM, Daniel Gredler wrote: > Hi Roger, > > Thanks for the feedback, I've created an issue in JBS [1] and will > create the PR in the coming days. > > This method currently throws an OOME if a negative capacity is > requested, but that should never happen because it's only called > internally after careful parameter validation. Once it's public, users > will be able to request negative?capacities directly. For the public > API, I'm leaning towards?quietly ignoring calls with non-positive > capacities, a la `AbstractStringBuilder`, instead of throwing an OOME. > Let me know if you agree? > > Also, do you know what the maximum possible requested capacity is > here? It would be good to avoid the need for follow-up issues like > this one [2] for `ArrayList`. > > Take care, > > Daniel > > [1] https://bugs.openjdk.org/browse/JDK-8374610 > [2] https://bugs.openjdk.org/browse/JDK-8258565 > > > > On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs wrote: > > Hi Daniel, > > That seems reasonable, allowing control over the timing of resizes. > Making it public is sensible too. > > ?From a higher point of view, are you sure you want to be working > with > ByteArrayOutputStream and not ByteBuffer or Memory Segments? There > are > more performance possibilities with those APIs. > > Regards, Roger > > > On 1/5/26 7:15 AM, Daniel Gredler wrote: > > Hi, > > > > I was recently looking at subclassing `ByteArrayOutputStream` in an > > application so that I could add a fast VarHandle-based > > `writeLong(long)` method (writing 8 bytes to the byte array in one > > go). The internal?`ByteArrayOutputStream` buffer is protected, > so no > > issue there, but `ensureCapacity(int)` is private rather than > > protected, and uses the internal `ArraysSupport` class, so it's not > > even easy to copy/paste as duplicate code in the subclass. Similar > > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are > > public. Would a PR adjusting the visibility of this method from > > private to protected be accepted? > > > > Take care, > > > > Daniel > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Tue Jan 6 15:01:43 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 15:01:43 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v3] In-Reply-To: References: 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 te... Jaikiran Pai 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: - Mark's suggestion - move the duration check to separate method - merge latest from master branch - Mark's review - use CountDownLatch - merge latest from master branch - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/d086512d..8f67f18c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=01-02 Stats: 907 lines in 42 files changed: 610 ins; 246 del; 51 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 jpai at openjdk.org Tue Jan 6 15:01:47 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 15:01:47 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v2] In-Reply-To: References: Message-ID: <7exsQQUMGzACTKl_dM5FfxlE8PTFIkfb9wcGE-SzCC8=.49f00761-c2fd-4efc-8b94-b6cf7d979e8d@github.com> On Tue, 6 Jan 2026 11:37:38 GMT, Mark Sheppard wrote: >> Jaikiran Pai 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: >> >> - Mark's review - use CountDownLatch >> - merge latest from master branch >> - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds > > test/jdk/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java line 111: > >> 109: System.err.println("waiting for unreferenced() callback..."); >> 110: callbackInvocationLatch.await(); >> 111: Instant waitEndedAt = Instant.now(); > > 111 - 126 refactor extract method isWithinExpectedTimeLimit > simpllifies reading of test, and lucidly expresses the logic of the time evaluation Done, I've updated the PR to move the duration check into a separate method. I let the File reading stay in this main method instead of passing around file path to the new assert method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28919#discussion_r2665213995 From sshivang at openjdk.org Tue Jan 6 15:12:36 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Tue, 6 Jan 2026 15:12:36 GMT Subject: [jdk26] RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message Message-ID: Hi all, This pull request contains a backport of commit [1f47294c](https://github.com/openjdk/jdk/commit/1f47294cd336db34030ea16132490ab51310ace5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Jaikiran Pai on 15 Dec 2025 and was reviewed by Aleksei Efimov. ------------- Commit messages: - Backport 1f47294cd336db34030ea16132490ab51310ace5 Changes: https://git.openjdk.org/jdk/pull/29066/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29066&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8287062 Stats: 64 lines in 1 file changed: 28 ins; 13 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29066.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29066/head:pull/29066 PR: https://git.openjdk.org/jdk/pull/29066 From jpai at openjdk.org Tue Jan 6 15:20:21 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 15:20:21 GMT Subject: [jdk26] RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 15:04:29 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [1f47294c](https://github.com/openjdk/jdk/commit/1f47294cd336db34030ea16132490ab51310ace5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jaikiran Pai on 15 Dec 2025 and was reviewed by Aleksei Efimov. This test-only backport looks OK to me and should help prevent any intermittent failures of this test. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29066#pullrequestreview-3631301481 From rriggs at openjdk.org Tue Jan 6 15:37:35 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Jan 2026 15:37:35 GMT Subject: RFR: 8374544: Add SleepyCat diagnostics for all platforms [v2] In-Reply-To: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> References: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> Message-ID: > To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. > On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Correct copyright in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29047/files - new: https://git.openjdk.org/jdk/pull/29047/files/49b05974..e686af94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29047&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29047&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29047.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29047/head:pull/29047 PR: https://git.openjdk.org/jdk/pull/29047 From duke at openjdk.org Tue Jan 6 16:08:29 2026 From: duke at openjdk.org (duke) Date: Tue, 6 Jan 2026 16:08:29 GMT Subject: [jdk26] RFR: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 15:04:29 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [1f47294c](https://github.com/openjdk/jdk/commit/1f47294cd336db34030ea16132490ab51310ace5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jaikiran Pai on 15 Dec 2025 and was reviewed by Aleksei Efimov. @Shivangi-aa Your change (at version 4de52d93ea17ca1c2f6455310df702fd3b41a960) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29066#issuecomment-3715280231 From naoto at openjdk.org Tue Jan 6 16:31:38 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 Jan 2026 16:31:38 GMT Subject: RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: References: Message-ID: <6ELTvLimbKKHD_x-JQPvPLAbPRXj2H93S_-3u6DZ_8Y=.ffcbe1d2-5dce-465b-8f3e-3f3f969d3d26@github.com> On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato wrote: > Removing `static` from the JUnit test cases so that they are executed Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29021#issuecomment-3715362758 From naoto at openjdk.org Tue Jan 6 16:31:39 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 Jan 2026 16:31:39 GMT Subject: Integrated: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: References: Message-ID: On Fri, 2 Jan 2026 18:55:33 GMT, Naoto Sato wrote: > Removing `static` from the JUnit test cases so that they are executed This pull request has now been integrated. Changeset: 136ac0d1 Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8374433: java/util/Locale/PreserveTagCase.java does not run any tests Reviewed-by: iris, joehw, jlu ------------- PR: https://git.openjdk.org/jdk/pull/29021 From bpb at openjdk.org Tue Jan 6 16:45:06 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 16:45:06 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified In-Reply-To: References: Message-ID: <5xr67b1MyQLpFXTeEoO1-laQSQYAyDI2PSPH69fjqQY=.80b77592-0a11-470e-806f-73efb4e880d7@github.com> On Tue, 6 Jan 2026 04:44:29 GMT, Jaikiran Pai wrote: > Hello Brian, this looks OK to me. Thanks for the review, @jaikiran. > Would this same check be needed in the `testFile()` method where too the `Space` constructor gets called? I don't think so as `testFile()` is called with a file that has a non-transient root. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29052#issuecomment-3715426922 From bpb at openjdk.org Tue Jan 6 16:59:56 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 16:59:56 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 06:55:59 GMT, Alan Bateman wrote: > What would you think about changing Space's constructor to throw IOException to remove the confusing RuntimeException from this test. I had considered that. I will give it another look. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29052#issuecomment-3715496414 From bpb at openjdk.org Tue Jan 6 17:04:49 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 17:04:49 GMT Subject: RFR: 8370216: Fix of new File("").exists() causes undefined behavior in libraries In-Reply-To: References: Message-ID: On Wed, 5 Nov 2025 18:14:44 GMT, Brian Burkhalter wrote: > Add a system property, `jdk.io.File.failIfEmptyPath`, which when `true` reverts to legacy, pre-JDK 25 behavior, as to how `java.io.File` handles an empty pathname string. > The storey (_sic_) has moved on since the PR was created. I assume we will need to update the File class description to allow this. Sorry, but I don't understand this comment. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28158#issuecomment-3715511954 From jpai at openjdk.org Tue Jan 6 17:09:33 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 6 Jan 2026 17:09:33 GMT Subject: RFR: 8374544: Add SleepyCat diagnostics for all platforms [v2] In-Reply-To: References: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> Message-ID: On Tue, 6 Jan 2026 15:37:35 GMT, Roger Riggs wrote: >> To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. >> On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct copyright in test Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29047#pullrequestreview-3631727097 From sshivang at openjdk.org Tue Jan 6 17:12:12 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Tue, 6 Jan 2026 17:12:12 GMT Subject: [jdk26] Integrated: 8287062: com/sun/jndi/ldap/LdapPoolTimeoutTest.java failed due to different timeout message In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 15:04:29 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [1f47294c](https://github.com/openjdk/jdk/commit/1f47294cd336db34030ea16132490ab51310ace5) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jaikiran Pai on 15 Dec 2025 and was reviewed by Aleksei Efimov. This pull request has now been integrated. Changeset: a07e0771 Author: Shivangi Gupta Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a07e0771c70f135414fe9d4827f665a60b3c8e15 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: jpai Backport-of: 1f47294cd336db34030ea16132490ab51310ace5 ------------- PR: https://git.openjdk.org/jdk/pull/29066 From alanb at openjdk.org Tue Jan 6 17:12:39 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 17:12:39 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set [v2] In-Reply-To: References: Message-ID: > Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Improve wording ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29059/files - new: https://git.openjdk.org/jdk/pull/29059/files/8bb3d684..c72b16f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29059&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29059&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29059.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29059/head:pull/29059 PR: https://git.openjdk.org/jdk/pull/29059 From alanb at openjdk.org Tue Jan 6 17:12:42 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 17:12:42 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set [v2] In-Reply-To: <8gAwM6XaY-FM_Sg9st2JtcAAMCc-pKUQ_QY3CIn_k-o=.02334644-8b01-474b-ba01-0a3b6261b383@github.com> References: <8gAwM6XaY-FM_Sg9st2JtcAAMCc-pKUQ_QY3CIn_k-o=.02334644-8b01-474b-ba01-0a3b6261b383@github.com> Message-ID: On Tue, 6 Jan 2026 14:12:22 GMT, Viktor Klang wrote: > Just offering a potential alternative formulation. > > `This method must only be called once, unless the previous invocation resulted in an {@code InterruptedException} being thrown.` Thanks, I'll see if I can incorporate some of this into the existing sentence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29059#discussion_r2665625669 From darcy at openjdk.org Tue Jan 6 17:17:05 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Jan 2026 17:17:05 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v2] In-Reply-To: References: Message-ID: <9lD8GI1R8P4RBN7taDJAqL5ed_WWgEGsEywVKA7vL6M=.f9b4d2c5-928a-48fa-88a0-4feabc00b265@github.com> On Tue, 6 Jan 2026 07:29:30 GMT, Alan Bateman wrote: > It will be used when in the interpreter too, which it think confuses people sometimes as they modify the Java code and see that the modified code executes. FWIW, I've worked with the HotSpot team in years past and at least some of the java.lang.Math intrinsics are used under all VM compilation modes including the interpreter (if they are used at all on that platform, etc.). That is basically necessary for correctness of a method like Math.sin since the specification imposes consistency constraints on the return values of different calls to Math.sin. (In other words if there are two spec-compliant implementations of Math.sin, sampling between them won't necessarily yield a third spec compliant implementation.) I'm not certain if use in the interpreter holds for Math.fma too, but I can update the comment to admit that possibility. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2665651877 From pstrawderman at netflix.com Tue Jan 6 17:19:14 2026 From: pstrawderman at netflix.com (Patrick Strawderman) Date: Tue, 6 Jan 2026 11:19:14 -0600 Subject: Regression in GZIPInputStream performance since JDK 23 Message-ID: Wanted to discuss a performance regression I noticed here before opening an issue since I'm somewhat surprised it's flown under the radar and wanted a gut check. In an application that does GZIP decoding from byte[] per request, I noticed in a profile that these calls were spending a lot of time in Throwable#fill_in_stack_trace, something I hadn't seen before. I found JDK-7036144 [1], and looking into the change I see that when decoding a single GZIP message we now rely on exceptions for control flow to detect the end of input, which is likely the cause. I wrote a JMH benchmark [2] and tested performance between JDK 22 and 23+ and the performance seems much worse for this single-shot use case, which I suspect is fairly common when decompressing bytes off the wire. Running the benchmark locally I see 20-30% reduction in throughput. Wanted to check if this is a known issue or if I am just missing something. Thanks, Patrick Strawderman [1] https://github.com/openjdk/jdk/commit/d3f3011d56267360d65841da3550eca79cf1575b [2] https://gist.github.com/kilink/9a9bed0a8a272d9b8826d5c49f1708a4 -------------- next part -------------- An HTML attachment was scrubbed... URL: From pchilanomate at openjdk.org Tue Jan 6 17:19:14 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 6 Jan 2026 17:19:14 GMT Subject: RFR: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 08:08:49 GMT, Alan Bateman wrote: > A regression since we changed the VirtualThread implementation to use use FJP delayed task handling (JDK-8351927) in JDK 25. > > If a virtual thread does a timed-park, followed immediately by an untimed-park, while racing with both an async unpark and the execution of cancelled timeout-task, then it is possible for the virtual thread to get stuck in the parked state. More specifically, it is possible for stars to align to create the scenario where parkTimeoutExpired makes available the parking permit but it doesn't continue the thread because it has moved on to an untimed-park. A small oversight that crept in when the timeout support was migrated to use the new delay scheduler. > > Testing: tier1-5. New stress tests added, and existing stress test TimedWaitALot updated. Looks good to me. ------------- Marked as reviewed by pchilanomate (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29011#pullrequestreview-3631767826 From alan.bateman at oracle.com Tue Jan 6 17:29:49 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Tue, 6 Jan 2026 17:29:49 +0000 Subject: Regression in GZIPInputStream performance since JDK 23 In-Reply-To: References: Message-ID: <226c5bc3-cf65-478d-be96-4b3a5efd93f4@oracle.com> On 06/01/2026 17:19, Patrick Strawderman wrote: > Wanted to discuss a performance regression I noticed here before > opening an issue since I'm somewhat surprised it's flown under the > radar and wanted a gut check. > > In an application that does GZIP decoding from byte[] per request, I > noticed in a profile that these calls were spending a lot of time in > Throwable#fill_in_stack_trace, something I hadn't seen before. I found > JDK-7036144 [1], and looking into the change I see that when decoding > a single GZIP message we now rely on exceptions for control flow to > detect the end of input, which is likely the cause. I think you're right, the read of the next header could handle end of stream to avoid the ZipException. We should create an issue in JBS to look at this. -Alan -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Tue Jan 6 17:38:27 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Jan 2026 17:38:27 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v2] In-Reply-To: References: Message-ID: <887LkEl6kO-QAwlhKBan2x42oX6ZR_bxX5lERNpYCss=.a4188d0e-618d-4fca-bb35-09da67f3756d@github.com> On Tue, 6 Jan 2026 08:52:35 GMT, Eirik Bj?rsn?s wrote: >> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: >> >> Respond to review feedback and add conclusion. > > src/java.base/share/classes/java/lang/Math.java line 2381: > >> 2379: @IntrinsicCandidate >> 2380: public static double fma(double a, double b, double c) { >> 2381: // Implementation note: this method is intentionally coded in > > The note seems currently structured as: > > * Actual implementation design > * Hypothetical/alternative implementation design > * Performance context > * Actual implementation design ("-ilities") > > The part suggesting how an alternative Java implementation could be made more performant seems counterproductive or at the least unnecessary. > > I think the structure can be simplified as: > > * Performance context > * Actual implementation design/"-ilities" > > Here's a sketch intended to demonstrate the suggested stucture (needs work for correctness, grammar, etc.): > > > // The Java implementation below will only be used when intrinsics > // using hardware fma support is not available. > // Therefore, simplicity, maintainability, and ease of testing > // of the code is more important than direct performance. > // The implementation is intentionally kept straightforward, > // relying on BigDecimal for numerical computation. The intention of the PR is to avert future attempts to re-writing Math.fma to make it "faster"; see https://mail.openjdk.org/pipermail/core-libs-dev/2025-December/156810.html ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29044#discussion_r2665707030 From rriggs at openjdk.org Tue Jan 6 18:07:28 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Jan 2026 18:07:28 GMT Subject: RFR: 8374308: ImageBufferCache has no effect and can be removed [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 11:03:45 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > simplifying allocation and argument checks looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29043#pullrequestreview-3631910822 From rriggs at openjdk.org Tue Jan 6 18:11:38 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Jan 2026 18:11:38 GMT Subject: RFR: 8374544: Add SleepyCat diagnostics for all platforms [v2] In-Reply-To: References: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> Message-ID: On Tue, 6 Jan 2026 15:37:35 GMT, Roger Riggs wrote: >> To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. >> On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Correct copyright in test Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29047#issuecomment-3715741076 From rriggs at openjdk.org Tue Jan 6 18:11:40 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 6 Jan 2026 18:11:40 GMT Subject: Integrated: 8374544: Add SleepyCat diagnostics for all platforms In-Reply-To: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> References: <_zg1JC9VwiW5Srbcwo9W5ienpZCQiKhlE_6mNWD4Elg=.59ffdf00-2f5b-4f0e-9089-7a9db5e477ab@github.com> Message-ID: <6-V4N2uzBvnjKLQl3YWJbRyPNzk3feqwcSOL5Rh7GYU=.b03798b1-4839-41e4-9982-12d2790860f4@github.com> On Mon, 5 Jan 2026 20:14:21 GMT, Roger Riggs wrote: > To aid diagnosis of these intermittent failures, add diagnostic information to the test failures. > On timeout, show ps and lsof commands for processes under test Add TEST.properties to increase jtreg maxOutputSize=6000000 This pull request has now been integrated. Changeset: f1e0e0c2 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/f1e0e0c25ec62a543b9cbfabd630fc4ef17a8b5c Stats: 15 lines in 2 files changed: 0 ins; 7 del; 8 mod 8374544: Add SleepyCat diagnostics for all platforms Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29047 From jlu at openjdk.org Tue Jan 6 18:22:45 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 Jan 2026 18:22:45 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v3] 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: - Removing now outdated testNG comment - Merge branch 'master' into java.time-to-JUnit - Merge branch 'master' into java.time-to-JUnit - nontestng -> nonjunit - Fix comments - 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 - ... and 3 more: https://git.openjdk.org/jdk/compare/c6f3f85a...1cb313ea ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28911/files - new: https://git.openjdk.org/jdk/pull/28911/files/d90d23ed..1cb313ea Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=01-02 Stats: 8409 lines in 2284 files changed: 2778 ins; 1646 del; 3985 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 duke at openjdk.org Tue Jan 6 18:25:27 2026 From: duke at openjdk.org (duke) Date: Tue, 6 Jan 2026 18:25:27 GMT Subject: RFR: 8374308: ImageBufferCache has no effect and can be removed [v4] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 11:03:45 GMT, David Beaumont wrote: >> Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. >> >> I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). >> >> I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. > > David Beaumont has updated the pull request incrementally with one additional commit since the last revision: > > simplifying allocation and argument checks @david-beaumont Your change (at version 7d54c8e55f7bfa2b228ecd83f0c7ca5a88742b5d) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29043#issuecomment-3715798157 From duke at openjdk.org Tue Jan 6 18:26:00 2026 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Tue, 6 Jan 2026 18:26:00 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink Message-ID: This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. image ------------- Commit messages: - Fix broken layout of markdown list inside jlink's man page. Changes: https://git.openjdk.org/jdk/pull/29069/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29069&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374632 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29069/head:pull/29069 PR: https://git.openjdk.org/jdk/pull/29069 From duke at openjdk.org Tue Jan 6 18:26:01 2026 From: duke at openjdk.org (Billy Korando) Date: Tue, 6 Jan 2026 18:26:01 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:18:07 GMT, Ana Maria Mihalceanu wrote: > This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. > image Marked as reviewed by wkorando at github.com (no known OpenJDK username). ------------- PR Review: https://git.openjdk.org/jdk/pull/29069#pullrequestreview-3631995507 From djgredler at gmail.com Tue Jan 6 18:30:26 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Tue, 6 Jan 2026 19:30:26 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> Message-ID: Hi Roger, All points noted, thanks -- just wanted to double check on this: > I don't think you could call it `ensureCapacity()` if it ignores the request. If you pass a negative (i.e. invalid) argument, you need to either throw an exception or ignore the request. Both `ArrayList` and `StringBuilder` simply ignore calls with negative arguments (i.e. neither `new ArrayList().ensureCapacity(-1)` nor `new StringBuilder().ensureCapacity(-1)` throw an exception, they just ignore the request). The old `Vector` class does the same, though few developers will be using it at this stage. All of that to say that as a developer, ignoring an `ensureCapacity()` call with a negative capacity would not have surprised me in the least, and would be consistent with the other `ensureCapacity` methods in other core classes. Let me know your thoughts on this final point, and I'll move forward with both the CSR and the PR. Thanks! Daniel On Tue, Jan 6, 2026 at 3:54?PM Roger Riggs wrote: > Hi Daniel, > > I don't think you could call it `ensureCapacity()` if it ignores the > request. > > The limit is not specified, different VMs have different overheads. > > The exception and message are appropriate: "java.lang.OutOfMemoryError: > Requested array size exceeds VM limit " > > For negative arguments, an IllegalArgumentException might be an > improvement in usability for developers. > > [2] 8258565 is closed as "will not fix" because the memory limits are an > implementation parameter, not specified. > > Thanks, Roger > > p.s. as an API change it will need a CSR. There's a "create a CSR" menu > item on the issue and a template to fill out. > > > On 1/6/26 9:01 AM, Daniel Gredler wrote: > > Hi Roger, > > Thanks for the feedback, I've created an issue in JBS [1] and will create > the PR in the coming days. > > This method currently throws an OOME if a negative capacity is requested, > but that should never happen because it's only called internally after > careful parameter validation. Once it's public, users will be able to > request negative capacities directly. For the public API, I'm leaning > towards quietly ignoring calls with non-positive capacities, a la > `AbstractStringBuilder`, instead of throwing an OOME. Let me know if you > agree? > > Also, do you know what the maximum possible requested capacity is here? It > would be good to avoid the need for follow-up issues like this one [2] for > `ArrayList`. > > Take care, > > Daniel > > [1] https://bugs.openjdk.org/browse/JDK-8374610 > [2] https://bugs.openjdk.org/browse/JDK-8258565 > > > > On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs wrote: > >> Hi Daniel, >> >> That seems reasonable, allowing control over the timing of resizes. >> Making it public is sensible too. >> >> From a higher point of view, are you sure you want to be working with >> ByteArrayOutputStream and not ByteBuffer or Memory Segments? There are >> more performance possibilities with those APIs. >> >> Regards, Roger >> >> >> On 1/5/26 7:15 AM, Daniel Gredler wrote: >> > Hi, >> > >> > I was recently looking at subclassing `ByteArrayOutputStream` in an >> > application so that I could add a fast VarHandle-based >> > `writeLong(long)` method (writing 8 bytes to the byte array in one >> > go). The internal `ByteArrayOutputStream` buffer is protected, so no >> > issue there, but `ensureCapacity(int)` is private rather than >> > protected, and uses the internal `ArraysSupport` class, so it's not >> > even easy to copy/paste as duplicate code in the subclass. Similar >> > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are >> > public. Would a PR adjusting the visibility of this method from >> > private to protected be accepted? >> > >> > Take care, >> > >> > Daniel >> > >> > >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From naoto at openjdk.org Tue Jan 6 18:57:51 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 Jan 2026 18:57:51 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:22:45 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision: > > - Removing now outdated testNG comment > - Merge branch 'master' into java.time-to-JUnit > - Merge branch 'master' into java.time-to-JUnit > - nontestng -> nonjunit > - Fix comments > - 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 > - ... and 3 more: https://git.openjdk.org/jdk/compare/23530f6a...1cb313ea Still looks good. I think the new commit warrants a copy right year increment ------------- PR Comment: https://git.openjdk.org/jdk/pull/28911#issuecomment-3715907068 From jlu at openjdk.org Tue Jan 6 19:24:35 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 Jan 2026 19:24:35 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v4] 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 one additional commit since the last revision: Bumping copyright year for TCKDateTimeFormatter.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28911/files - new: https://git.openjdk.org/jdk/pull/28911/files/1cb313ea..7e1ae3c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28911&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 naoto at openjdk.org Tue Jan 6 19:24:36 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 Jan 2026 19:24:36 GMT Subject: RFR: 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG [v4] In-Reply-To: References: Message-ID: <463l2VqYZdLGc3Aw2YJd5gXNMHGbPoklAroJjs951-Y=.65f94b1b-85c2-4741-8cb5-f850f196ad65@github.com> On Tue, 6 Jan 2026 19:21:03 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 one additional commit since the last revision: > > Bumping copyright year for TCKDateTimeFormatter.java Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28911#pullrequestreview-3632176797 From jlu at openjdk.org Tue Jan 6 19:27:10 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 Jan 2026 19:27:10 GMT Subject: Integrated: 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 This pull request has now been integrated. Changeset: 53300b4a Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/53300b4ac12240ea08227386412bfb90650c0aee Stats: 13724 lines in 186 files changed: 2264 ins; 691 del; 10769 mod 8373830: Refactor test/jdk/java/time/test tests to use JUnit over TestNG 8373829: Refactor test/jdk/java/time/tck tests to use JUnit over TestNG Reviewed-by: naoto ------------- PR: https://git.openjdk.org/jdk/pull/28911 From roger.riggs at oracle.com Tue Jan 6 19:53:11 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 6 Jan 2026 14:53:11 -0500 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> Message-ID: <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> Hi Daniel, I stand corrected, any current size (>=0) satisfies the request (zero is greater than -1). I would not say it "ignores" it, just that it already is greater or equal to the request. The current phrasing of ByteArrayOutputStream.ensureCapacity uses the "holds at least" phrasing. It would risky to change the implementation of BAOS.ensureCapacity to not throw OOME on negative minCapacity. Roger On 1/6/26 1:30 PM, Daniel Gredler wrote: > Hi Roger, > > All points noted, thanks -- just wanted to double check on this: > > >?I don't think you could call it `ensureCapacity()` if it ignores the > request. > > If you pass a negative (i.e. invalid) argument, you need to either > throw an exception or ignore the request. Both `ArrayList` and > `StringBuilder` simply ignore calls with negative arguments (i.e. > neither `new ArrayList().ensureCapacity(-1)` nor `new > StringBuilder().ensureCapacity(-1)` throw an exception, they just > ignore the request). The old `Vector` class does the same, though few > developers will be using it at this stage. > > All of that to say that as a developer, ignoring an `ensureCapacity()` > call with a negative capacity would not have surprised me in the > least, and would be consistent with the other `ensureCapacity` methods > in other core classes. > > Let me know your thoughts on this final point, and I'll move forward > with both the CSR and the PR. > > Thanks! > > Daniel > > > > On Tue, Jan 6, 2026 at 3:54?PM Roger Riggs wrote: > > Hi Daniel, > > I don't think you could call it `ensureCapacity()` if it ignores > the request. > > The limit is not specified, different VMs have different overheads. > > The exception and message are appropriate: > "java.lang.OutOfMemoryError: Requested array size exceeds VM limit " > > For negative arguments, an IllegalArgumentException might be an > improvement in usability for developers. > > [2] 8258565 is closed as "will not fix" because the memory limits > are an implementation parameter, not specified. > > Thanks, Roger > > p.s. as an API change it will need a CSR. There's a "create a CSR" > menu item on the issue and a template to fill out. > > > On 1/6/26 9:01 AM, Daniel Gredler wrote: >> Hi Roger, >> >> Thanks for the feedback, I've created an issue in JBS [1] and >> will create the PR in the coming days. >> >> This method currently throws an OOME if a negative capacity is >> requested, but that should never happen because it's only called >> internally after careful parameter validation. Once it's public, >> users will be able to request negative?capacities directly. For >> the public API, I'm leaning towards?quietly ignoring calls with >> non-positive capacities, a la `AbstractStringBuilder`, instead of >> throwing an OOME. Let me know if you agree? >> >> Also, do you know what the maximum possible requested capacity is >> here? It would be good to avoid the need for follow-up issues >> like this one [2] for `ArrayList`. >> >> Take care, >> >> Daniel >> >> [1] https://bugs.openjdk.org/browse/JDK-8374610 >> [2] https://bugs.openjdk.org/browse/JDK-8258565 >> >> >> >> On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs >> wrote: >> >> Hi Daniel, >> >> That seems reasonable, allowing control over the timing of >> resizes. >> Making it public is sensible too. >> >> ?From a higher point of view, are you sure you want to be >> working with >> ByteArrayOutputStream and not ByteBuffer or Memory Segments? >> There are >> more performance possibilities with those APIs. >> >> Regards, Roger >> >> >> On 1/5/26 7:15 AM, Daniel Gredler wrote: >> > Hi, >> > >> > I was recently looking at subclassing >> `ByteArrayOutputStream` in an >> > application so that I could add a fast VarHandle-based >> > `writeLong(long)` method (writing 8 bytes to the byte array >> in one >> > go). The internal?`ByteArrayOutputStream` buffer is >> protected, so no >> > issue there, but `ensureCapacity(int)` is private rather than >> > protected, and uses the internal `ArraysSupport` class, so >> it's not >> > even easy to copy/paste as duplicate code in the subclass. >> Similar >> > `ensureCapacity` methods in `ArrayList` and `StringBuilder` >> are >> > public. Would a PR adjusting the visibility of this method >> from >> > private to protected be accepted? >> > >> > Take care, >> > >> > Daniel >> > >> > >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From duke at openjdk.org Tue Jan 6 19:58:27 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 6 Jan 2026 19:58:27 GMT Subject: Integrated: 8374308: ImageBufferCache has no effect and can be removed In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:19:50 GMT, David Beaumont wrote: > Remove ineffective/unused ImageBufferCache class, and simplify callers / remove dead code. > > I removed the release methods in the internal classes, but the public ModuleReader API method is still there (the override can go away though since the default implementation also tests for non-null, so removing the override has no risk). > > I suspect there are no implementations of ModuleReader that implement release semantics after this change, so perhaps we could relax the documentation around it? Thoughts welcome. This pull request has now been integrated. Changeset: 7c979c14 Author: David Beaumont Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/7c979c148724ab7de650593caa22df8405d740e5 Stats: 214 lines in 4 files changed: 5 ins; 198 del; 11 mod 8374308: ImageBufferCache has no effect and can be removed Reviewed-by: alanb, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/29043 From djgredler at gmail.com Tue Jan 6 20:05:24 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Tue, 6 Jan 2026 21:05:24 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> Message-ID: > It would risky to change the implementation of BAOS.ensureCapacity to not throw OOME on negative minCapacity. Completely agree -- if we wanted the public API contract to match the `ensureCapacity` method behavior elsewhere, we would leave the existing method untouched and private, and add a public version which only delegates to the existing private method if minCapacity > 0 (almost identical to `AbstractStringBuilder`). Take care, Daniel On Tue, Jan 6, 2026 at 8:53?PM Roger Riggs wrote: > Hi Daniel, > > I stand corrected, any current size (>=0) satisfies the request (zero is > greater than -1). > > I would not say it "ignores" it, just that it already is greater or equal > to the request. > The current phrasing of ByteArrayOutputStream.ensureCapacity uses the > "holds at least" phrasing. > It would risky to change the implementation of BAOS.ensureCapacity to not > throw OOME on negative minCapacity. > > Roger > > > On 1/6/26 1:30 PM, Daniel Gredler wrote: > > Hi Roger, > > All points noted, thanks -- just wanted to double check on this: > > > I don't think you could call it `ensureCapacity()` if it ignores the > request. > > If you pass a negative (i.e. invalid) argument, you need to either throw > an exception or ignore the request. Both `ArrayList` and `StringBuilder` > simply ignore calls with negative arguments (i.e. neither `new > ArrayList().ensureCapacity(-1)` nor `new > StringBuilder().ensureCapacity(-1)` throw an exception, they just ignore > the request). The old `Vector` class does the same, though few developers > will be using it at this stage. > > All of that to say that as a developer, ignoring an `ensureCapacity()` > call with a negative capacity would not have surprised me in the least, and > would be consistent with the other `ensureCapacity` methods in other core > classes. > > Let me know your thoughts on this final point, and I'll move forward with > both the CSR and the PR. > > Thanks! > > Daniel > > > > On Tue, Jan 6, 2026 at 3:54?PM Roger Riggs wrote: > >> Hi Daniel, >> >> I don't think you could call it `ensureCapacity()` if it ignores the >> request. >> >> The limit is not specified, different VMs have different overheads. >> >> The exception and message are appropriate: "java.lang.OutOfMemoryError: >> Requested array size exceeds VM limit " >> >> For negative arguments, an IllegalArgumentException might be an >> improvement in usability for developers. >> >> [2] 8258565 is closed as "will not fix" because the memory limits are an >> implementation parameter, not specified. >> >> Thanks, Roger >> >> p.s. as an API change it will need a CSR. There's a "create a CSR" menu >> item on the issue and a template to fill out. >> >> >> On 1/6/26 9:01 AM, Daniel Gredler wrote: >> >> Hi Roger, >> >> Thanks for the feedback, I've created an issue in JBS [1] and will create >> the PR in the coming days. >> >> This method currently throws an OOME if a negative capacity is requested, >> but that should never happen because it's only called internally after >> careful parameter validation. Once it's public, users will be able to >> request negative capacities directly. For the public API, I'm leaning >> towards quietly ignoring calls with non-positive capacities, a la >> `AbstractStringBuilder`, instead of throwing an OOME. Let me know if you >> agree? >> >> Also, do you know what the maximum possible requested capacity is here? >> It would be good to avoid the need for follow-up issues like this one [2] >> for `ArrayList`. >> >> Take care, >> >> Daniel >> >> [1] https://bugs.openjdk.org/browse/JDK-8374610 >> [2] https://bugs.openjdk.org/browse/JDK-8258565 >> >> >> >> On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs >> wrote: >> >>> Hi Daniel, >>> >>> That seems reasonable, allowing control over the timing of resizes. >>> Making it public is sensible too. >>> >>> From a higher point of view, are you sure you want to be working with >>> ByteArrayOutputStream and not ByteBuffer or Memory Segments? There are >>> more performance possibilities with those APIs. >>> >>> Regards, Roger >>> >>> >>> On 1/5/26 7:15 AM, Daniel Gredler wrote: >>> > Hi, >>> > >>> > I was recently looking at subclassing `ByteArrayOutputStream` in an >>> > application so that I could add a fast VarHandle-based >>> > `writeLong(long)` method (writing 8 bytes to the byte array in one >>> > go). The internal `ByteArrayOutputStream` buffer is protected, so no >>> > issue there, but `ensureCapacity(int)` is private rather than >>> > protected, and uses the internal `ArraysSupport` class, so it's not >>> > even easy to copy/paste as duplicate code in the subclass. Similar >>> > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are >>> > public. Would a PR adjusting the visibility of this method from >>> > private to protected be accepted? >>> > >>> > Take care, >>> > >>> > Daniel >>> > >>> > >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bpb at openjdk.org Tue Jan 6 20:17:45 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 20:17:45 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified [v2] In-Reply-To: References: Message-ID: <4EzwPKbaR79CQZ3c95lSQtcBCujZSO9jcepIosGQMfs=.243aec23-12a9-4f0c-b11d-6c421b129f3d@github.com> > If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8372377: Change RuntimeException to IOException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29052/files - new: https://git.openjdk.org/jdk/pull/29052/files/dcdceeaf..6fac6925 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29052&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29052&range=00-01 Stats: 32 lines in 2 files changed: 4 ins; 8 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29052/head:pull/29052 PR: https://git.openjdk.org/jdk/pull/29052 From alanb at openjdk.org Tue Jan 6 21:01:36 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 6 Jan 2026 21:01:36 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified [v2] In-Reply-To: <4EzwPKbaR79CQZ3c95lSQtcBCujZSO9jcepIosGQMfs=.243aec23-12a9-4f0c-b11d-6c421b129f3d@github.com> References: <4EzwPKbaR79CQZ3c95lSQtcBCujZSO9jcepIosGQMfs=.243aec23-12a9-4f0c-b11d-6c421b129f3d@github.com> Message-ID: On Tue, 6 Jan 2026 20:17:45 GMT, Brian Burkhalter wrote: >> If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8372377: Change RuntimeException to IOException test/jdk/java/io/File/libGetXSpace.c line 65: > 63: const jchar* strchars = (*env)->GetStringChars(env, root, NULL); > 64: if (strchars == NULL) { > 65: JNU_ThrowByNameWithLastError(env, "java/io/IOException", The update to have getSpace0 throw IOException is good. There are now 2 cases in that native method where is throws IOException for non-I/O reasons, specifically when GetStringChars or malloc fails. You might want to revert those two as IOException doesn't make sense. I assume the change to isCDDrive can be reverted too as it doesn't throw an exception corresponding to an I/O error. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29052#discussion_r2666271741 From bpb at openjdk.org Tue Jan 6 21:06:30 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 21:06:30 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified [v2] In-Reply-To: References: <4EzwPKbaR79CQZ3c95lSQtcBCujZSO9jcepIosGQMfs=.243aec23-12a9-4f0c-b11d-6c421b129f3d@github.com> Message-ID: On Tue, 6 Jan 2026 20:58:28 GMT, Alan Bateman wrote: > The update to have getSpace0 throw IOException is good. There are now 2 cases in that native method where is throws IOException for non-I/O reasons, specifically when GetStringChars or malloc fails. You might want to revert those two as IOException doesn't make sense. Indeed I realized that myself since pushing the last commit. Will update those and isCDDrive. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29052#discussion_r2666280099 From bpb at openjdk.org Tue Jan 6 21:20:14 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Tue, 6 Jan 2026 21:20:14 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified [v3] In-Reply-To: References: Message-ID: > If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: 8372377: Revert some IOException changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29052/files - new: https://git.openjdk.org/jdk/pull/29052/files/6fac6925..faf3c269 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29052&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29052&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 2 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29052.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29052/head:pull/29052 PR: https://git.openjdk.org/jdk/pull/29052 From jlu at openjdk.org Tue Jan 6 21:37:44 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 6 Jan 2026 21:37:44 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java Message-ID: Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. ------------- Commit messages: - init Changes: https://git.openjdk.org/jdk/pull/29071/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29071&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374051 Stats: 17 lines in 1 file changed: 2 ins; 4 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29071.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29071/head:pull/29071 PR: https://git.openjdk.org/jdk/pull/29071 From pstrawderman at netflix.com Tue Jan 6 22:25:36 2026 From: pstrawderman at netflix.com (Patrick Strawderman) Date: Tue, 6 Jan 2026 16:25:36 -0600 Subject: Regression in GZIPInputStream performance since JDK 23 In-Reply-To: <226c5bc3-cf65-478d-be96-4b3a5efd93f4@oracle.com> References: <226c5bc3-cf65-478d-be96-4b3a5efd93f4@oracle.com> Message-ID: I've created an issue to track this here: https://bugs.openjdk.org/browse/JDK-8374644 On Tue, Jan 6, 2026 at 11:29?AM Alan Bateman wrote: > > > On 06/01/2026 17:19, Patrick Strawderman wrote: > > Wanted to discuss a performance regression I noticed here before opening > an issue since I'm somewhat surprised it's flown under the radar and wanted > a gut check. > > In an application that does GZIP decoding from byte[] per request, I > noticed in a profile that these calls were spending a lot of time in > Throwable#fill_in_stack_trace, something I hadn't seen before. I found JDK-7036144 > [1], and looking into the change I see that when decoding a single GZIP > message we now rely on exceptions for control flow to detect the end of > input, which is likely the cause. > > > I think you're right, the read of the next header could handle end of > stream to avoid the ZipException. We should create an issue in JBS to look > at this. > > -Alan > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Tue Jan 6 22:32:33 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 Jan 2026 22:32:33 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: test/Executor: minor fix ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28733/files - new: https://git.openjdk.org/jdk/pull/28733/files/70d7de8d..0be4bdb9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28733/head:pull/28733 PR: https://git.openjdk.org/jdk/pull/28733 From darcy at openjdk.org Tue Jan 6 22:52:14 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 6 Jan 2026 22:52:14 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v3] In-Reply-To: References: Message-ID: > Add comment describing why Math.fma uses BigDecimal. Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: Add note on interpreter. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29044/files - new: https://git.openjdk.org/jdk/pull/29044/files/c1dac46a..c04963c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29044&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29044&range=01-02 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29044.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29044/head:pull/29044 PR: https://git.openjdk.org/jdk/pull/29044 From dl at openjdk.org Tue Jan 6 22:52:57 2026 From: dl at openjdk.org (Doug Lea) Date: Tue, 6 Jan 2026 22:52:57 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] 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 28 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Split external push - Undo/redo ordering changes - Strengthen some orderings - Merge branch 'openjdk:master' into JDK-8373118 - Not sure why this merge is necessary Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 - Merge branch 'openjdk:master' into JDK-8373118 - Fix deactivate; faster quiescence - recheck avoiding cross-class offsets - Merge branch 'openjdk:master' into JDK-8373118 - ... and 18 more: https://git.openjdk.org/jdk/compare/c03fedf9...54a8672a ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/2a580747..54a8672a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=18-19 Stats: 16606 lines in 472 files changed: 3328 ins; 1877 del; 11401 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 Jan 6 23:22:29 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 6 Jan 2026 23:22:29 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java In-Reply-To: References: Message-ID: <2dPOie1wVNta3ctP1RMchr0yex_Iji6d4dEdZY_Opgc=.563e79f2-e2e8-4b1e-b039-57b3a7b8a5c7@github.com> On Tue, 6 Jan 2026 21:29:31 GMT, Justin Lu wrote: > Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. By taking the opportunity, I think it is better to make valid tests that for-loop `samples()` values parameterized too. test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java line 73: > 71: import org.junit.jupiter.api.Assertions; > 72: import org.junit.jupiter.api.Test; > 73: cosmetic: the blank line may better fit after junit imports ------------- PR Review: https://git.openjdk.org/jdk/pull/29071#pullrequestreview-3632823367 PR Review Comment: https://git.openjdk.org/jdk/pull/29071#discussion_r2666574371 From asemenyuk at openjdk.org Tue Jan 6 23:59:16 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 6 Jan 2026 23:59:16 GMT Subject: Integrated: 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other In-Reply-To: References: Message-ID: On Sun, 4 Jan 2026 02:02:44 GMT, Alexey Semenyuk wrote: > Remove the "error.explicit-sign-no-cert" error message, which duplicates the "error.cert.not.found" error message. This pull request has now been integrated. Changeset: 6b3c1e0f Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/6b3c1e0f786a889d2ac25c8bd05f4d83e666425f Stats: 17 lines in 3 files changed: 1 ins; 10 del; 6 mod 8373833: "error.cert.not.found" and "error.explicit-sign-no-cert" errors duplicate each other Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29025 From vklang at openjdk.org Wed Jan 7 01:47:56 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 7 Jan 2026 01:47:56 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set [v2] In-Reply-To: References: <8gAwM6XaY-FM_Sg9st2JtcAAMCc-pKUQ_QY3CIn_k-o=.02334644-8b01-474b-ba01-0a3b6261b383@github.com> Message-ID: On Tue, 6 Jan 2026 17:05:32 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 1087: >> >>> 1085: * exception outcome is obtained, this method may not be invoked again. The only >>> 1086: * case where this method may be called again by the scope owner is after >>> 1087: * {@code InterruptedException} is thrown. >> >> Just offering a potential alternative formulation. >> >> `This method must only be called once, unless the previous invocation resulted in an {@code InterruptedException} being thrown.` > >> Just offering a potential alternative formulation. >> >> `This method must only be called once, unless the previous invocation resulted in an {@code InterruptedException} being thrown.` > > Thanks, I'll see if I can incorporate some of this into the existing sentence. Looks good, thanks Alan! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29059#discussion_r2666799374 From jpai at openjdk.org Wed Jan 7 01:53:59 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 01:53:59 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:18:07 GMT, Ana Maria Mihalceanu wrote: > This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. > image Hello Ana, this looks OK to me. Can you please also update the copyright year on the top of this file from `2017, 2025,` to `2017, 2026,`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29069#issuecomment-3717012913 From almatvee at openjdk.org Wed Jan 7 03:58:58 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 Jan 2026 03:58:58 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:32:33 GMT, Alexey Semenyuk wrote: >> - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). >> - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. >> - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. >> - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. >> >> Supplementary changes: >> - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > test/Executor: minor fix Looks good with some comments. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 274: > 272: .setMaxAttemptsCount(10) > 273: .setAttemptTimeoutMillis(3000) > 274: .setWriteOutputToFile(true) Do we always write output to file with new implementation? I see that you call `storeOutputInFiles()` for `hdiutil`. src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/CommandOutputControl.java line 7: > 5: * This code is free software; you can redistribute it and/or modify it > 6: * under the terms of the GNU General Public License version 2 only, as > 7: * published by the Free Software Foundation. Missing "Classpath" exception. test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java line 129: > 127: var desc = spec.create().description(); > 128: assertFalse(desc.isBlank()); > 129: // System.out.println(desc); Remove if not needed. test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java line 698: > 696: private static List testSomeSavedOutput() { > 697: var testIds = List.of(/* 10, 67, 456 */); > 698: if (testIds.isEmpty()) { Can you explain what this method do? `testIds` is always empty, so not sure what it tries to do. test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java line 1003: > 1001: } > 1002: case CatCommandAction _ -> { > 1003: // Not used, no pint to implement. `pint` -> `point` ------------- PR Review: https://git.openjdk.org/jdk/pull/28733#pullrequestreview-3629203357 PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2663456818 PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2666734358 PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2666938204 PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2666955055 PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2666960201 From asemenyuk at openjdk.org Wed Jan 7 04:09:53 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 7 Jan 2026 04:09:53 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: <-NeaAYcOrN1OugDwadoYZyFxxzmBHRIV3O712j3ALn4=.84e6231a-9b61-41fd-abc1-051f09e3f489@github.com> On Tue, 6 Jan 2026 03:23:12 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: >> >> test/Executor: minor fix > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 274: > >> 272: .setMaxAttemptsCount(10) >> 273: .setAttemptTimeoutMillis(3000) >> 274: .setWriteOutputToFile(true) > > Do we always write output to file with new implementation? I see that you call `storeOutputInFiles()` for `hdiutil`. `storeOutputInFiles()` is applied only to the "hdiutil" command. This is how it was before the patch, and it hasn't changed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2666997071 From asemenyuk at openjdk.org Wed Jan 7 04:23:20 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 7 Jan 2026 04:23:20 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 03:35:08 GMT, Alexander Matveev wrote: >> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: >> >> test/Executor: minor fix > > test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java line 698: > >> 696: private static List testSomeSavedOutput() { >> 697: var testIds = List.of(/* 10, 67, 456 */); >> 698: if (testIds.isEmpty()) { > > Can you explain what this method do? `testIds` is always empty, so not sure what it tries to do. This method is for debugging individual `testSavedOutput()` test cases. It is disabled by default. If you replace `/* 10, 67, 456 */` with the index(es) of a specific `testSavedOutput()` test case(s), the test will run only selected test cases instead of running all of them. The total number of `testSavedOutput()` test cases is ~1500. When some fail and need debugging, it is a waste of time to run them all. This method allows running only selected test cases. It works this way: - Run CommandOutputControlTest test. - If some `testSavedOutput` test cases fail, capture their IDs (test case ID is an index starting from 1). - Replace `/* 10, 67, 456 */` with the captured test case IDs. - Rerun CommandOutputControlTest test. This time, it will not run all `testSavedOutput` test cases; only the captured ones will be run. Right now, this functionality isn't actually used as all test cases pass, but it may come in handy when updating the CommandOutputControlTest test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2667015030 From fyang at openjdk.org Wed Jan 7 06:59:48 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 7 Jan 2026 06:59:48 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: On Wed, 17 Dec 2025 12:56:01 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 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 Hi, I have a minor question about the tests. test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: > 1891: VectorMask m = three.compare(VectorOperators.LE, higher); > 1892: assert(m.allTrue()); > 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3633583291 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667282723 From duke at openjdk.org Wed Jan 7 07:41:03 2026 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Wed, 7 Jan 2026 07:41:03 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink [v2] In-Reply-To: References: Message-ID: > This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. > image Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: Update copyright of help file. Signed-off-by: Ana-Maria Mihalceanu ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29069/files - new: https://git.openjdk.org/jdk/pull/29069/files/7b632765..af888f08 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29069&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29069&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29069/head:pull/29069 PR: https://git.openjdk.org/jdk/pull/29069 From jpai at openjdk.org Wed Jan 7 07:45:32 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 07:45:32 GMT Subject: RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 17:12:39 GMT, Alan Bateman wrote: >> Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Improve wording Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29059#pullrequestreview-3633693079 From alanb at openjdk.org Wed Jan 7 07:45:30 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 07:45:30 GMT Subject: RFR: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:20:14 GMT, Brian Burkhalter wrote: >> If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. > > Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision: > > 8372377: Revert some IOException changes Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29052#pullrequestreview-3633694359 From jpai at openjdk.org Wed Jan 7 07:52:46 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 07:52:46 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 07:41:03 GMT, Ana Maria Mihalceanu wrote: >> This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. >> image > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright of help file. > > Signed-off-by: Ana-Maria Mihalceanu Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29069#pullrequestreview-3633711919 From duke at openjdk.org Wed Jan 7 08:20:02 2026 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Wed, 7 Jan 2026 08:20:02 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink [v3] In-Reply-To: References: Message-ID: <-6g6CUw6YHymfbPekHpzFLR_WdNO-S23bifU_st7Xgw=.59399e79-714c-4a60-8cef-722b2cbe871e@github.com> > This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. > image 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/29069/files - new: https://git.openjdk.org/jdk/pull/29069/files/af888f08..ab2c2e17 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29069&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29069&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29069.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29069/head:pull/29069 PR: https://git.openjdk.org/jdk/pull/29069 From duke at openjdk.org Wed Jan 7 08:20:04 2026 From: duke at openjdk.org (duke) Date: Wed, 7 Jan 2026 08:20:04 GMT Subject: RFR: 8374632: Broken list layout in the man page of jlink [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 07:41:03 GMT, Ana Maria Mihalceanu wrote: >> This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. >> image > > Ana Maria Mihalceanu has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright of help file. > > Signed-off-by: Ana-Maria Mihalceanu @ammbra Your change (at version ab2c2e17733acb776ba76f79079870ea53194e13) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29069#issuecomment-3717772505 From duke at openjdk.org Wed Jan 7 08:27:07 2026 From: duke at openjdk.org (Ana Maria Mihalceanu) Date: Wed, 7 Jan 2026 08:27:07 GMT Subject: Integrated: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 18:18:07 GMT, Ana Maria Mihalceanu wrote: > This PR contains an empty line to fix the formatting issue introduced in jlink's man page. I tested locally by building the JDK and the layout looks like in attachment. > image This pull request has now been integrated. Changeset: a01283a5 Author: Ana-Maria Mihalceanu Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a01283a5a57723673b1fd3c93434678fdae4102c Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8374632: Broken list layout in the man page of jlink Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29069 From pminborg at openjdk.org Wed Jan 7 08:42:52 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 08:42:52 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Tue, 23 Dec 2025 07:33:14 GMT, Shawn M Emery wrote: >> Good idea. There is a `Linker.Option.captureCallState("errno")` feature and I'll see how to use it. > > It looks like there has been prior work with this, at least with macos, e.g.: src/java.base/macosx/classes/jdk/internal/ffi/generated/errno/errno_h.java Also, there is a class `jdk.internal.foreign.CaptureStateUtil` that can be used to simplify and improve performance when working with `errno` and the likes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667535314 From pminborg at openjdk.org Wed Jan 7 08:42:56 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 08:42:56 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > must have username; more comments src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88: > 86: = (ValueLayout) LINKER.canonicalLayouts().get("size_t"); > 87: > 88: private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout(); Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2667524583 From jbhateja at openjdk.org Wed Jan 7 09:05:47 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 7 Jan 2026 09:05:47 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: On Wed, 7 Jan 2026 06:55:45 GMT, Fei Yang wrote: >> 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 > > test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: > >> 1891: VectorMask m = three.compare(VectorOperators.LE, higher); >> 1892: assert(m.allTrue()); >> 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); > > I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2667602759 From vyazici at openjdk.org Wed Jan 7 09:23:28 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 Jan 2026 09:23:28 GMT Subject: RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: <3Rpck6RY8Y4e8nra-VY8XWnlOUvYnXPEuwPL6DikCHU=.5a55c9f6-d5e9-431c-9285-d11c594127bd@github.com> On Tue, 6 Jan 2026 10:53:21 GMT, Tobias Hartmann wrote: >> Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. >> >> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 >> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 > > Looks good to me. @TobiHartmann, @shipilev, thanks so much for your kind help, and reviews. As I stated earlier, Tier 1-3 are clear using c8acc80b8c6, and I see no other remarks. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29055#issuecomment-3717974843 From vyazici at openjdk.org Wed Jan 7 09:26:04 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 7 Jan 2026 09:26:04 GMT Subject: Integrated: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: <3JPEbFO_Dlf3D46IlEOn21t0KL9wouC5z-0VQa31tsc=.f8de0911-4fcf-49f2-b25a-0b9e1059dc1a@github.com> On Tue, 6 Jan 2026 08:16:16 GMT, Volkan Yazici wrote: > Back out `java.lang.StringCoding` changes delivered in [JDK-8361842] (#25998 & 655dc516c22), which causes regressions reported in [JDK-8374210]. > > [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 This pull request has now been integrated. Changeset: 7e18de13 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/7e18de137c3b5f08a479af2b64eb22923261900b Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics Reviewed-by: shade, thartmann ------------- PR: https://git.openjdk.org/jdk/pull/29055 From jpai at openjdk.org Wed Jan 7 10:09:12 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 10:09:12 GMT Subject: [jdk26] RFR: 8374632: Broken list layout in the man page of jlink Message-ID: Can I please get a review of this (clean) backport of the doc-only fix to jlink's man page? The original fix was done in JDK mainline by Ana here https://github.com/openjdk/jdk/pull/29069 and addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374632. ------------- Commit messages: - Backport a01283a5a57723673b1fd3c93434678fdae4102c Changes: https://git.openjdk.org/jdk/pull/29083/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29083&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374632 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29083.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29083/head:pull/29083 PR: https://git.openjdk.org/jdk/pull/29083 From alanb at openjdk.org Wed Jan 7 10:47:21 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 10:47:21 GMT Subject: Integrated: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Wed, 31 Dec 2025 08:08:49 GMT, Alan Bateman wrote: > A regression since we changed the VirtualThread implementation to use use FJP delayed task handling (JDK-8351927) in JDK 25. > > If a virtual thread does a timed-park, followed immediately by an untimed-park, while racing with both an async unpark and the execution of cancelled timeout-task, then it is possible for the virtual thread to get stuck in the parked state. More specifically, it is possible for stars to align to create the scenario where parkTimeoutExpired makes available the parking permit but it doesn't continue the thread because it has moved on to an untimed-park. A small oversight that crept in when the timeout support was migrated to use the new delay scheduler. > > Testing: tier1-5. New stress tests added, and existing stress test TimedWaitALot updated. This pull request has now been integrated. Changeset: f83918c6 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/f83918c692143802f2e94bed72dfe7121d1742f9 Stats: 165 lines in 3 files changed: 143 ins; 11 del; 11 mod 8369227: Virtual thread stuck in PARKED state Reviewed-by: pchilanomate ------------- PR: https://git.openjdk.org/jdk/pull/29011 From alanb at openjdk.org Wed Jan 7 10:47:19 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 10:47:19 GMT Subject: Integrated: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 10:09:21 GMT, Alan Bateman wrote: > Small docs-only clarification to make it clearer that join throws InterruptedException if called with the current thread's interrupted status set. Also make it clear that the exception clears the interrupted status. This pull request has now been integrated. Changeset: 6af27420 Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/6af27420e3b1980bc093776e3db76072123f7487 Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod 8373427: StructuredTaskScope::join not clear if called with interrupted status set Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29059 From mdoerr at openjdk.org Wed Jan 7 11:47:37 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 7 Jan 2026 11:47:37 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> Message-ID: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> On Mon, 5 Jan 2026 21:30:54 GMT, Weijun Wang wrote: >> FWIW there is an issue and ML discussion relating to extension of arguments with respect to `ValueLayout`: https://bugs.openjdk.org/browse/JDK-8336664 > > \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)? I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668116234 From alanb at openjdk.org Wed Jan 7 11:59:01 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 11:59:01 GMT Subject: [jdk26] RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set Message-ID: Clean backport of docs-only change. The CSR was approved for 26, 27. ------------- Commit messages: - Backport 6af27420e3b1980bc093776e3db76072123f7487 Changes: https://git.openjdk.org/jdk/pull/29085/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29085&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373427 Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29085.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29085/head:pull/29085 PR: https://git.openjdk.org/jdk/pull/29085 From jpai at openjdk.org Wed Jan 7 12:11:49 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 12:11:49 GMT Subject: [jdk26] RFR: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 11:22:23 GMT, Alan Bateman wrote: > Clean backport of docs-only change. The CSR was approved for 26, 27. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29085#pullrequestreview-3634574720 From lkorinth at openjdk.org Wed Jan 7 12:35:42 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:35:42 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 10:02:41 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: > > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings > > Reviewed-by: aboldtch > - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test > > Reviewed-by: serb, aivanov, dnguyen > - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 I will redo the merge, I have done something strange. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3718660595 From duke at openjdk.org Wed Jan 7 12:50:29 2026 From: duke at openjdk.org (Eunbin Son) Date: Wed, 7 Jan 2026 12:50:29 GMT Subject: RFR: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 11:09:35 GMT, Michael McMahon wrote: >> ### 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 > > This seems reasonable. You will need to update the PR title to match the change I made to the bug title. @Michael-Mc-Mahon Thank you for the review. I updated the PR title to match bug title : [JDK-8374342](https://bugs.openjdk.org/browse/JDK-8374342) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28985#issuecomment-3718705083 From lkorinth at openjdk.org Wed Jan 7 12:58:43 2026 From: lkorinth at openjdk.org (Leo Korinth) Date: Wed, 7 Jan 2026 12:58:43 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: > This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. > > It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. > > This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. > > I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: - Merge branch '8373253' into 8367993 - Merge branch 'master' into _8373253 - Merge branch 'master' into _8367993 - 8366058: Outdated comment in WinCAPISeedGenerator Reviewed-by: mullan - 8357258: x86: Improve receiver type profiling reliability Reviewed-by: kvn, vlivanov - 8373704: Improve "SocketException: Protocol family unavailable" message Reviewed-by: lucy, jpai - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently Reviewed-by: jiefu, jbhateja, erfang, qamai - 8343809: Add requires tag to mark tests that are incompatible with exploded image Reviewed-by: alanb, dholmes - 8374465: Spurious dot in documentation for JVMTI ClassLoad Reviewed-by: kbarrett - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket Reviewed-by: djelinski, mpowers, ascarpino - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 ------------- Changes: https://git.openjdk.org/jdk/pull/28723/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28723&range=02 Stats: 130308 lines in 3967 files changed: 83803 ins; 29735 del; 16770 mod Patch: https://git.openjdk.org/jdk/pull/28723.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28723/head:pull/28723 PR: https://git.openjdk.org/jdk/pull/28723 From alanb at openjdk.org Wed Jan 7 13:38:09 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 13:38:09 GMT Subject: [jdk26] RFR: 8369227: Virtual thread stuck in PARKED state Message-ID: Clean backport to fix regression in JDK 25 when VirtualThread implementation was changed to use the FJP delayed task support. ------------- Commit messages: - Backport f83918c692143802f2e94bed72dfe7121d1742f9 Changes: https://git.openjdk.org/jdk/pull/29086/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29086&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8369227 Stats: 165 lines in 3 files changed: 143 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29086.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29086/head:pull/29086 PR: https://git.openjdk.org/jdk/pull/29086 From jpai at openjdk.org Wed Jan 7 13:38:22 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 13:38:22 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 Message-ID: Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. No new regression test has been introduced and tier1, tier2 and tier3 testing is currently in progress. ------------- Commit messages: - 8374644: Regression in GZIPInputStream performance after JDK-7036144 Changes: https://git.openjdk.org/jdk/pull/29092/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29092&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374644 Stats: 41 lines in 1 file changed: 33 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29092/head:pull/29092 PR: https://git.openjdk.org/jdk/pull/29092 From vklang at openjdk.org Wed Jan 7 13:43:01 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 7 Jan 2026 13:43:01 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 6 Jan 2026 22:52:57 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 28 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - Split external push > - Undo/redo ordering changes > - Strengthen some orderings > - Merge branch 'openjdk:master' into JDK-8373118 > - Not sure why this merge is necessary > Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 > - Merge branch 'openjdk:master' into JDK-8373118 > - Fix deactivate; faster quiescence > - recheck avoiding cross-class offsets > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 18 more: https://git.openjdk.org/jdk/compare/54191738...54a8672a src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1955: > 1953: break scan; > 1954: if (U.getReference(a, np) == null && > 1955: (rescans >= 0 || `rescans` cannot be > 0 here given https://github.com/openjdk/jdk/pull/28797/changes#diff-e398beb49cd8d3e6c2f3a8ca8eee97172c57d7f88f3ccd8a3c704632cab32f5fR1952 Suggestion: (rescans == 0 || ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2668506696 From pminborg at openjdk.org Wed Jan 7 13:43:37 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 13:43:37 GMT Subject: RFR: 8374717: Unclear wording in docs for recursion for List, Map and LazyConstant Message-ID: <-cqudLsu7pgmEjbxAxz3vM9k7fayqCeEZJrcgstOf34=.9cae792d-b902-4582-9b64-7b02c2cd9792@github.com> The factory methods `(List|Map)::ofLazy` and `LazyConstant::get` specify that an `IllegalStateException` is thrown upon a recursive invocation of the computing function. However, it is not clear that this *only* applies if recursion is made through the lazy entity (and not direct recursion on the computing function itself). This PR proposes to improve the wording in the docs for lazy constructs. This is a doc-only change. For example, we could replace the word "or" with the word "via" in the `List::ofLazy` specification so that it says: * If the provided computing function recursively calls itself via the returned * lazy list for the same index, an {@linkplain IllegalStateException} * will be thrown. ------------- Commit messages: - Update copyright years - Clarify recursive invocation in the docs Changes: https://git.openjdk.org/jdk/pull/29091/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29091&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374717 Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29091.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29091/head:pull/29091 PR: https://git.openjdk.org/jdk/pull/29091 From vklang at openjdk.org Wed Jan 7 13:48:45 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 7 Jan 2026 13:48:45 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 6 Jan 2026 22:52:57 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 28 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - Split external push > - Undo/redo ordering changes > - Strengthen some orderings > - Merge branch 'openjdk:master' into JDK-8373118 > - Not sure why this merge is necessary > Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 > - Merge branch 'openjdk:master' into JDK-8373118 > - Fix deactivate; faster quiescence > - recheck avoiding cross-class offsets > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 18 more: https://git.openjdk.org/jdk/compare/35f1afff...54a8672a src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969: > 1967: } > 1968: else if (q.base == b && > 1969: U.compareAndSetReference(a, bp, t, null)) { Would we expect a[bp] to be possible to be something besides `t` or `null` here? If not, I think we could switch to a `U.getAndSetReference(a, bp, null) == t` here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2668520485 From alanb at openjdk.org Wed Jan 7 13:50:10 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 13:50:10 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:27:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? > > In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. > > Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. > > Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. > > Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. > > The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. > > The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. > > No new regression test has been in... src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 195: > 193: * If failOnEOF is false and if the given InputStream has already > 194: * reached EOF when this method was invoked, then this method returns > 195: * 0 (indicating that there's no GZIP member header). Have you tried using -1 for EOF instead of 0? I think would make it easier to understand at the use sites. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2668528822 From jpai at openjdk.org Wed Jan 7 13:58:54 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 13:58:54 GMT Subject: [jdk26] RFR: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 11:22:50 GMT, Alan Bateman wrote: > Clean backport to fix regression in JDK 25 when VirtualThread implementation was changed to use the FJP delayed task support. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29086#pullrequestreview-3635016198 From jpai at openjdk.org Wed Jan 7 14:08:02 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 14:08:02 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? > > In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. > > Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. > > Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. > > Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. > > The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. > > The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. > > No new regression test has been in... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: use -1 to represent absence of a GZIP header, from readHeader() method ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29092/files - new: https://git.openjdk.org/jdk/pull/29092/files/9c2cf68b..06e7b370 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29092&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29092&range=00-01 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29092/head:pull/29092 PR: https://git.openjdk.org/jdk/pull/29092 From jpai at openjdk.org Wed Jan 7 14:08:04 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 7 Jan 2026 14:08:04 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: <_-vMtSuUDXI5pcsX0c7Pe0L5ungrbboT3FsIx1cq400=.b40a76ba-2559-4aa8-960c-2eb331c330ea@github.com> On Wed, 7 Jan 2026 13:47:24 GMT, Alan Bateman wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use -1 to represent absence of a GZIP header, from readHeader() method > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 195: > >> 193: * If failOnEOF is false and if the given InputStream has already >> 194: * reached EOF when this method was invoked, then this method returns >> 195: * 0 (indicating that there's no GZIP member header). > > Have you tried using -1 for EOF instead of 0? I think would make it easier to understand at the use sites. I had very briefly considered it, but there was a call site (within this class) which was doing: m += readHeader(in); so I decided to use `0` to prevent accidental additions of negative value. Having said that, that is no longer a concern with the current changes in this PR and there are only 2 call sites to this (private) method in this class. So your suggestion of using `-1` as a return value sounds good to me. I've updated the PR accordingly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2668587977 From mcimadamore at openjdk.org Wed Jan 7 14:10:02 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 7 Jan 2026 14:10:02 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Wed, 7 Jan 2026 11:44:24 GMT, Martin Doerr wrote: >> \What happens if you create a user on AIX with a uid bigger than 2^31 and call `getpwuid_r` on it (by hardcoding `tmpUid` as a negative number)? > > I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected. > It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here: https://bugs.openjdk.org/browse/JDK-8336664 (apologies -- this link was already shared by @dmlloyd ) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2668596071 From jaikiran.pai at oracle.com Wed Jan 7 14:16:49 2026 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Wed, 7 Jan 2026 19:46:49 +0530 Subject: Regression in GZIPInputStream performance since JDK 23 In-Reply-To: References: <226c5bc3-cf65-478d-be96-4b3a5efd93f4@oracle.com> Message-ID: Thank you Patrick for reporting this, providing the JMH benchmark and also narrowing this down to the actual root cause of the performance regression. A PR addressing this regression has been proposed https://github.com/openjdk/jdk/pull/29092 and with those changes the JMH benchmark numbers are back to the JDK 22 levels (the one without the JDK-7036144 change). If you have built the JDK project before and are interested in trying out that proposed change, then it would be good to verify that PR against your actual application too. Furthermore, if the library/application which exposed this problem is public and easy to build, then it would be good to know where it resides - that might help us run some experiments whenever there are future changes in this area. -Jaikiran On 07/01/26 3:55 am, Patrick Strawderman wrote: > I've created an issue to track this here: > https://bugs.openjdk.org/browse/JDK-8374644 > > On Tue, Jan 6, 2026 at 11:29?AM Alan Bateman > wrote: > > > > On 06/01/2026 17:19, Patrick Strawderman wrote: >> Wanted to discuss a performance regression I noticed here before >> opening an issue since I'm somewhat surprised it's flown under >> the radar and wanted a gut check. >> >> In an application that does GZIP decoding from byte[] per >> request, I noticed in a profile that these calls were spending a >> lot of time in Throwable#fill_in_stack_trace, something I hadn't >> seen before. I found JDK-7036144 [1], and looking into the change >> I see that when decoding a single GZIP message we now rely on >> exceptions for control flow to detect the end of input, which is >> likely the cause. > > I think you're right, the read of the next header could handle end > of stream to avoid the ZipException. We should create an issue in > JBS to look at this. > > -Alan > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pminborg at openjdk.org Wed Jan 7 14:51:22 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 14:51:22 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record Message-ID: This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. On multiple platforms, tested and passed: - [x] tier1 - [x] tier2 - [x] tier3 Not tested: - [ ] tier4 - [ ] tier5 - [ ] tier6 ------------- Commit messages: - Annotate Record with AOTSafeClassInitializer Changes: https://git.openjdk.org/jdk/pull/29084/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374155 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From vklang at openjdk.org Wed Jan 7 15:10:28 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 7 Jan 2026 15:10:28 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 7 Jan 2026 13:44:53 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 28 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Split external push >> - Undo/redo ordering changes >> - Strengthen some orderings >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Not sure why this merge is necessary >> Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Fix deactivate; faster quiescence >> - recheck avoiding cross-class offsets >> - Merge branch 'openjdk:master' into JDK-8373118 >> - ... and 18 more: https://git.openjdk.org/jdk/compare/206410fe...54a8672a > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969: > >> 1967: } >> 1968: else if (q.base == b && >> 1969: U.compareAndSetReference(a, bp, t, null)) { > > Would we expect a[bp] to be possible to be something besides `t` or `null` here? If not, I think we could switch to a `U.getAndSetReference(a, bp, null) == t` here? Narrator: it won't work since there might be other values than `t` and `null` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2668836812 From pminborg at openjdk.org Wed Jan 7 15:29:23 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 15:29:23 GMT Subject: RFR: 8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc Message-ID: This PR proposes to fix errors in the documentation for the internal classes `jdk.internal.util.ByteArray` and `jdk.internal.util.ByteArrayLittleEndian`. ------------- Commit messages: - Fix issues in documentation Changes: https://git.openjdk.org/jdk/pull/29095/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29095&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374467 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29095.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29095/head:pull/29095 PR: https://git.openjdk.org/jdk/pull/29095 From rriggs at openjdk.org Wed Jan 7 15:41:03 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 Jan 2026 15:41:03 GMT Subject: RFR: 8374717: Unclear wording in docs for recursion for List, Map and LazyConstant In-Reply-To: <-cqudLsu7pgmEjbxAxz3vM9k7fayqCeEZJrcgstOf34=.9cae792d-b902-4582-9b64-7b02c2cd9792@github.com> References: <-cqudLsu7pgmEjbxAxz3vM9k7fayqCeEZJrcgstOf34=.9cae792d-b902-4582-9b64-7b02c2cd9792@github.com> Message-ID: On Wed, 7 Jan 2026 13:20:20 GMT, Per Minborg wrote: > The factory methods `(List|Map)::ofLazy` and `LazyConstant::get` specify that an `IllegalStateException` is thrown upon a recursive invocation of the computing function. However, it is not clear that this *only* applies if recursion is made through the lazy entity (and not direct recursion on the computing function itself). > > This PR proposes to improve the wording in the docs for lazy constructs. This is a doc-only change. > > For example, we could replace the word "or" with the word "via" in the `List::ofLazy` specification so that it says: > > * If the provided computing function recursively calls itself via the returned > * lazy list for the same index, an {@linkplain IllegalStateException} > * will be thrown. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29091#pullrequestreview-3635496758 From lancea at openjdk.org Wed Jan 7 15:47:53 2026 From: lancea at openjdk.org (Lance Andersen) Date: Wed, 7 Jan 2026 15:47:53 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 14:08:02 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? >> >> In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. >> >> Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. >> >> Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. >> >> Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. >> >> The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. >> >> The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. >> >> No n... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use -1 to represent absence of a GZIP header, from readHeader() method Hi Jai, Thank you for tackling. Overall I think the changes make sense. Additional comments that might make things a bit clearer for consideration src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 82: > 80: usesDefaultInflater = true; > 81: try { > 82: readHeader(in, true); Any consideration given to using an enum or constant to make it a bit clearer on what the true represents realizing there is a comment in the readHeader method. Not a big deal either way src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 219: > 217: } else { > 218: magic = readUShort(in); > 219: } Understand what you are doing but perhaps consider adding more clarity to the comments as you are now cobbling together the int which should contain the GZIP header magic number src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 260: > 258: } > 259: crc.reset(); > 260: assert n > 0 : "incorrect number of header bytes: " + n; No problem with this but wondering if we should add this later and look at other places of interest ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29092#pullrequestreview-3635387991 PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2668878961 PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2668979389 PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2668951609 From rriggs at openjdk.org Wed Jan 7 15:48:18 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 Jan 2026 15:48:18 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:29:31 GMT, Justin Lu wrote: > Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29071#pullrequestreview-3635520229 From rriggs at openjdk.org Wed Jan 7 15:51:31 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 Jan 2026 15:51:31 GMT Subject: RFR: 8374540: Add comment describing implementaiton choices of Math.fma [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:52:14 GMT, Joe Darcy wrote: >> Add comment describing why Math.fma uses BigDecimal. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add note on interpreter. fyi, corrected typo in issue summary, PR description will need the fix too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29044#issuecomment-3719524254 From rriggs at openjdk.org Wed Jan 7 15:53:09 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 7 Jan 2026 15:53:09 GMT Subject: RFR: 8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:19:07 GMT, Per Minborg wrote: > This PR proposes to fix errors in the documentation for the internal classes `jdk.internal.util.ByteArray` and `jdk.internal.util.ByteArrayLittleEndian`. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29095#pullrequestreview-3635539791 From pminborg at openjdk.org Wed Jan 7 16:02:25 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 7 Jan 2026 16:02:25 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v2] In-Reply-To: References: Message-ID: > This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. > > On multiple platforms, tested and passed: > - [x] tier1 > - [x] tier2 > - [x] tier3 > > Not tested: > - [ ] tier4 > - [ ] tier5 > - [ ] tier6 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add a test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29084/files - new: https://git.openjdk.org/jdk/pull/29084/files/bd79de32..cdb2a594 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=00-01 Stats: 47 lines in 1 file changed: 47 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From iris at openjdk.org Wed Jan 7 17:14:58 2026 From: iris at openjdk.org (Iris Clark) Date: Wed, 7 Jan 2026 17:14:58 GMT Subject: [jdk26] RFR: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:58:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this (clean) backport of the doc-only fix to jlink's man page? The original fix was done in JDK mainline by Ana here https://github.com/openjdk/jdk/pull/29069 and addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374632. Confirmed changes identical to those pushed to main line. ------------- Marked as reviewed by iris (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29083#pullrequestreview-3635892555 From duke at openjdk.org Wed Jan 7 17:38:11 2026 From: duke at openjdk.org (Yi Wu) Date: Wed, 7 Jan 2026 17:38:11 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 [v2] In-Reply-To: References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> <72RiEFo5wji1vOtIRzFwO03_0OsaCe2zzHjp9YPD8-k=.6a88f4eb-3fff-4fe5-bb43-260d81b7954a@github.com> Message-ID: On Tue, 6 Jan 2026 07:28:59 GMT, Xiaohong Gong wrote: >> Yi Wu 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: >> >> - Replace assert with verify >> - Add IRNode constant and code refactor >> - Merge remote-tracking branch 'origin/master' into yiwu-8373344 >> - 8373344: Add support for FP16 min/max reduction operations >> >> 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)... > > src/hotspot/cpu/aarch64/aarch64_vector.ad line 381: > >> 379: case Op_XorReductionV: >> 380: case Op_MinReductionVHF: >> 381: case Op_MaxReductionVHF: > > We can use the NEON instructions if the vector size <= 16B as well for partial cases. Did you test the performance with NEON instead of using predicated SVE instructions? You mean move it down, like `Op_AddReductionVI` and `Op_AddReductionVL` to use `return !VM_Version::use_neon_for_vector(length_in_bytes);`? It doesn't to make much of a difference. Neoverse V1 (UseSVE = 1, max vector length = 32B) Benchmark vectorDim Mode Cnt 8B(old) 8B(new) chg2/chg1 16B(old) 16B(new) chg2/chg1 32B(old) 32B(new) chg2/chg1 ReductionMaxFP16 256 thrpt 9 3.96 3.96 1.00 8.63 8.62 1.00 8.02 8.02 1.00 ReductionMaxFP16 512 thrpt 9 3.54 3.54 1.00 9.25 9.25 1.00 11.71 11.71 1.00 ReductionMaxFP16 1024 thrpt 9 3.77 3.77 1.00 8.70 8.71 1.00 14.12 14.07 1.00 ReductionMaxFP16 2048 thrpt 9 3.88 3.88 1.00 8.45 8.44 1.00 14.69 14.69 1.00 ReductionMinFP16 256 thrpt 9 3.96 3.96 1.00 8.62 8.61 1.00 8.02 8.03 1.00 ReductionMinFP16 512 thrpt 9 3.55 3.54 1.00 9.26 9.28 1.00 11.72 11.69 1.00 ReductionMinFP16 1024 thrpt 9 3.76 3.76 1.00 8.69 8.70 1.00 14.10 14.12 1.00 ReductionMinFP16 2048 thrpt 9 3.87 3.87 1.00 8.44 8.45 1.00 14.76 14.70 1.00 Neoverse V2 (UseSVE = 2, max vector length = 16B) Benchmark vectorDim Mode Cnt 8B(old) 8B(new) chg2/chg1 16B(old) 16B(new) chg2/chg1 ReductionMaxFP16 256 thrpt 9 4.77 4.78 1.00 10.00 10.00 1.00 ReductionMaxFP16 512 thrpt 9 3.75 3.74 1.00 11.32 11.33 1.00 ReductionMaxFP16 1024 thrpt 9 3.87 3.86 1.00 9.59 9.59 1.00 ReductionMaxFP16 2048 thrpt 9 3.94 3.94 1.00 8.72 8.71 1.00 ReductionMinFP16 256 thrpt 9 4.77 4.78 1.00 9.97 10.00 1.00 ReductionMinFP16 512 thrpt 9 3.77 3.74 0.99 11.35 11.29 0.99 ReductionMinFP16 1024 thrpt 9 3.86 3.86 1.00 9.56 9.58 1.00 ReductionMinFP16 2048 thrpt 9 3.94 3.94 1.00 8.71 8.71 1.00 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2669419647 From liach at openjdk.org Wed Jan 7 18:03:40 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 7 Jan 2026 18:03:40 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 Mon, 5 Jan 2026 14:21:29 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java line 46: > >> 44: // inaccessible interface >> 45: Method m = intf.getMethod("test"); >> 46: assertFalse(m.canAccess(t)); > > This looks like a semantic change? Fixing an existing bug in the test? Yes. I should extract this to a separate patch - this plus the `@run testng/othervm Unnamed` should be converted to `@run main/othervm Unnamed`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2669536316 From alanb at openjdk.org Wed Jan 7 18:56:12 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 7 Jan 2026 18:56:12 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 14:08:02 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? >> >> In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. >> >> Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. >> >> Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. >> >> Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. >> >> The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. >> >> The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. >> >> No n... > > Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: > > use -1 to represent absence of a GZIP header, from readHeader() method Good ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29092#pullrequestreview-3636361111 From jlu at openjdk.org Wed Jan 7 19:34:16 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 7 Jan 2026 19:34:16 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java [v2] In-Reply-To: References: Message-ID: > Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. Justin Lu has updated the pull request incrementally with one additional commit since the last revision: parameterize the rest of tests and resolve setup conflicts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29071/files - new: https://git.openjdk.org/jdk/pull/29071/files/9076b88a..b3237311 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29071&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29071&range=00-01 Stats: 147 lines in 9 files changed: 8 ins; 45 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/29071.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29071/head:pull/29071 PR: https://git.openjdk.org/jdk/pull/29071 From jlu at openjdk.org Wed Jan 7 19:37:49 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 7 Jan 2026 19:37:49 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java [v2] In-Reply-To: <2dPOie1wVNta3ctP1RMchr0yex_Iji6d4dEdZY_Opgc=.563e79f2-e2e8-4b1e-b039-57b3a7b8a5c7@github.com> References: <2dPOie1wVNta3ctP1RMchr0yex_Iji6d4dEdZY_Opgc=.563e79f2-e2e8-4b1e-b039-57b3a7b8a5c7@github.com> Message-ID: On Tue, 6 Jan 2026 23:17:22 GMT, Naoto Sato wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> parameterize the rest of tests and resolve setup conflicts > > test/jdk/java/time/tck/java/time/AbstractDateTimeTest.java line 73: > >> 71: import org.junit.jupiter.api.Assertions; >> 72: import org.junit.jupiter.api.Test; >> 73: > > cosmetic: the blank line may better fit after junit imports https://github.com/openjdk/jdk/pull/29071/commits/b3237311331c8a2c3c0863f7de6b93a89e853020 makes the rest of the eligible tests parameterized. After doing so, there was a test failure because some of the test class implementations provide values (which are instance variables) to `samples()` that are set during the `@beforeEach` methods. However, if the parametrized arguments are resolved before the value is set during the `@beforeEach` then it may be null during the test and fail. To address this, the `samples()` methods were updated to use the tested values directly, rather than the re-usable instance variable. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29071#discussion_r2669823356 From naoto at openjdk.org Wed Jan 7 20:06:35 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 7 Jan 2026 20:06:35 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:34:16 GMT, Justin Lu wrote: >> Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > parameterize the rest of tests and resolve setup conflicts LGTM. Also good to see those `fail()` going away ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29071#pullrequestreview-3636597189 From psandoz at openjdk.org Wed Jan 7 20:25:31 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 7 Jan 2026 20:25:31 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: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> On Wed, 17 Dec 2025 12:56:01 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 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 Just some quick comments for now. I think this is better heading in the right direction. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436: > 434: } else { > 435: assert(Float16.valueOf(i).intValue() == i); > 436: } It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.) src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Vector.java line 3083: > 3081: * @return a {@code Float16Vector} with the same shape and information content > 3082: */ > 3083: public abstract Float16Vector reinterpretAsFloat16s(); At some point we should consider consolidating these methods into one which accepts the lane element type as an argument. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277: > 275: if (etype == Float16.class) { > 276: etype = short.class; > 277: } My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically. ------------- PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3636482293 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669808367 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669818576 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2669827315 From brian.burkhalter at oracle.com Wed Jan 7 20:34:12 2026 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Jan 2026 20:34:12 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> Message-ID: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Resuscitating this discussion thread from last year ... To summarize my rereading of the thread, there is good agreement that Path.{ends,starts}With(String) should be deprecated and replaced with something else, perhaps Path.{ends,starts}WithString(String). There was also a parallel suggestion that Path.{ends,starts}With(Path) be deprecated in favor of Path.{ends,starts}WithPath(Path). Thus: * Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String) * Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path) Among doubtlessly many others, one alternative is 1. Leave Path.{ends,starts}With(Path) unchanged 2. Deprecate Path.{ends,starts}With(String) 3. Add Path.pathString{ends,starts}With(String) where "pathstring" in effect implies the value of Path.toString(). Comments? Brian On Nov 2, 2025, at 3:35?PM, David Alayachew wrote: As for deprecations, I still think all 4 methods should be deprecated. This path variants are kind of ok, but the String variants are just too deceptively named. I think Rob Spoor hit it on the head with this quote. > Perhaps both can be added? > > Path.{start,end}sWithString would default to calling > toString().{start,end}sWith(arg) and > Path.{start,end}sWithPath would default to calling > {start,end}sWith(arg). The latter could default to > calling {start,end}sWith(getFileSystem().getPath(arg)) > but then custom implementations that do something else > (in addition) may not work as expected. Doing it this way, we can have (start|end)sWithPath() have both String and Path overloads with no ambiguity. -------------- next part -------------- An HTML attachment was scrubbed... URL: From djgredler at gmail.com Wed Jan 7 21:07:00 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Wed, 7 Jan 2026 22:07:00 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> Message-ID: Hi Roger, I've created the CSR here: https://bugs.openjdk.org/browse/JDK-8374739 Alan also provided some feedback on the original issue here: https://bugs.openjdk.org/browse/JDK-8374610 I was going to wait to create the PR until the CSR has been approved, if that's OK? Take care, Daniel On Tue, Jan 6, 2026 at 9:05?PM Daniel Gredler wrote: > > It would risky to change the implementation of BAOS.ensureCapacity to > not throw OOME on negative minCapacity. > > Completely agree -- if we wanted the public API contract to match the > `ensureCapacity` method behavior elsewhere, we would leave the existing > method untouched and private, and add a public version which only delegates > to the existing private method if minCapacity > 0 (almost identical to > `AbstractStringBuilder`). > > Take care, > > Daniel > > > On Tue, Jan 6, 2026 at 8:53?PM Roger Riggs wrote: > >> Hi Daniel, >> >> I stand corrected, any current size (>=0) satisfies the request (zero is >> greater than -1). >> >> I would not say it "ignores" it, just that it already is greater or equal >> to the request. >> The current phrasing of ByteArrayOutputStream.ensureCapacity uses the >> "holds at least" phrasing. >> It would risky to change the implementation of BAOS.ensureCapacity to not >> throw OOME on negative minCapacity. >> >> Roger >> >> >> On 1/6/26 1:30 PM, Daniel Gredler wrote: >> >> Hi Roger, >> >> All points noted, thanks -- just wanted to double check on this: >> >> > I don't think you could call it `ensureCapacity()` if it ignores the >> request. >> >> If you pass a negative (i.e. invalid) argument, you need to either throw >> an exception or ignore the request. Both `ArrayList` and `StringBuilder` >> simply ignore calls with negative arguments (i.e. neither `new >> ArrayList().ensureCapacity(-1)` nor `new >> StringBuilder().ensureCapacity(-1)` throw an exception, they just ignore >> the request). The old `Vector` class does the same, though few developers >> will be using it at this stage. >> >> All of that to say that as a developer, ignoring an `ensureCapacity()` >> call with a negative capacity would not have surprised me in the least, and >> would be consistent with the other `ensureCapacity` methods in other core >> classes. >> >> Let me know your thoughts on this final point, and I'll move forward with >> both the CSR and the PR. >> >> Thanks! >> >> Daniel >> >> >> >> On Tue, Jan 6, 2026 at 3:54?PM Roger Riggs >> wrote: >> >>> Hi Daniel, >>> >>> I don't think you could call it `ensureCapacity()` if it ignores the >>> request. >>> >>> The limit is not specified, different VMs have different overheads. >>> >>> The exception and message are appropriate: "java.lang.OutOfMemoryError: >>> Requested array size exceeds VM limit " >>> >>> For negative arguments, an IllegalArgumentException might be an >>> improvement in usability for developers. >>> >>> [2] 8258565 is closed as "will not fix" because the memory limits are an >>> implementation parameter, not specified. >>> >>> Thanks, Roger >>> >>> p.s. as an API change it will need a CSR. There's a "create a CSR" menu >>> item on the issue and a template to fill out. >>> >>> >>> On 1/6/26 9:01 AM, Daniel Gredler wrote: >>> >>> Hi Roger, >>> >>> Thanks for the feedback, I've created an issue in JBS [1] and will >>> create the PR in the coming days. >>> >>> This method currently throws an OOME if a negative capacity is >>> requested, but that should never happen because it's only called internally >>> after careful parameter validation. Once it's public, users will be able to >>> request negative capacities directly. For the public API, I'm leaning >>> towards quietly ignoring calls with non-positive capacities, a la >>> `AbstractStringBuilder`, instead of throwing an OOME. Let me know if you >>> agree? >>> >>> Also, do you know what the maximum possible requested capacity is here? >>> It would be good to avoid the need for follow-up issues like this one [2] >>> for `ArrayList`. >>> >>> Take care, >>> >>> Daniel >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8374610 >>> [2] https://bugs.openjdk.org/browse/JDK-8258565 >>> >>> >>> >>> On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs >>> wrote: >>> >>>> Hi Daniel, >>>> >>>> That seems reasonable, allowing control over the timing of resizes. >>>> Making it public is sensible too. >>>> >>>> From a higher point of view, are you sure you want to be working with >>>> ByteArrayOutputStream and not ByteBuffer or Memory Segments? There are >>>> more performance possibilities with those APIs. >>>> >>>> Regards, Roger >>>> >>>> >>>> On 1/5/26 7:15 AM, Daniel Gredler wrote: >>>> > Hi, >>>> > >>>> > I was recently looking at subclassing `ByteArrayOutputStream` in an >>>> > application so that I could add a fast VarHandle-based >>>> > `writeLong(long)` method (writing 8 bytes to the byte array in one >>>> > go). The internal `ByteArrayOutputStream` buffer is protected, so no >>>> > issue there, but `ensureCapacity(int)` is private rather than >>>> > protected, and uses the internal `ArraysSupport` class, so it's not >>>> > even easy to copy/paste as duplicate code in the subclass. Similar >>>> > `ensureCapacity` methods in `ArrayList` and `StringBuilder` are >>>> > public. Would a PR adjusting the visibility of this method from >>>> > private to protected be accepted? >>>> > >>>> > Take care, >>>> > >>>> > Daniel >>>> > >>>> > >>>> >>>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From ascarpino at openjdk.org Wed Jan 7 21:18:30 2026 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Wed, 7 Jan 2026 21:18:30 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com> On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > must have username; more comments src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88: > 86: = (ValueLayout) LINKER.canonicalLayouts().get("size_t"); > 87: > 88: private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout(); Should the variables below be capitalized because they are `static final`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2666736772 From weijun at openjdk.org Wed Jan 7 21:18:33 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 Jan 2026 21:18:33 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Wed, 7 Jan 2026 08:35:57 GMT, Per Minborg wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> must have username; more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88: > >> 86: = (ValueLayout) LINKER.canonicalLayouts().get("size_t"); >> 87: >> 88: private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout(); > > Would it be a good idea to use capitalized names for immutable static fields in all places in the class? E.g., `CAPTURED_STATE_LAYOUT` here. Sure, I can use `CAPTURED_STATE_LAYOUT` and `ERRNO_HANDLE`. Do you also want me to capitalize those `MethodHandle`s, `pw_xyz_layout`, and `pw_xyz_offset`? I'll be happy to do so if we want to keep this tradition. I was looking into `HBShaper` and it's mixed there. The `jextract` output puts every constant behind a method and avoids this awkwardness. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670096071 From brian.burkhalter at oracle.com Wed Jan 7 21:44:51 2026 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 7 Jan 2026 21:44:51 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: In the list below I omitted adding Path.{ends,starts}WithString(String) which is different from item 3 in the list. Brian On Jan 7, 2026, at 12:34?PM, Brian Burkhalter wrote: Among doubtlessly many others, one alternative is 1. Leave Path.{ends,starts}With(Path) unchanged 2. Deprecate Path.{ends,starts}With(String) 3. Add Path.pathString{ends,starts}With(String) where "pathstring" in effect implies the value of Path.toString(). -------------- next part -------------- An HTML attachment was scrubbed... URL: From weijun at openjdk.org Wed Jan 7 21:50:50 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 7 Jan 2026 21:50:50 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com> Message-ID: On Wed, 7 Jan 2026 01:01:52 GMT, Anthony Scarpino wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> must have username; more comments > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88: > >> 86: = (ValueLayout) LINKER.canonicalLayouts().get("size_t"); >> 87: >> 88: private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout(); > > Should the variables below be capitalized because they are `static final`? Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'll willing to choose either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2670175161 From almatvee at openjdk.org Wed Jan 7 22:41:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 7 Jan 2026 22:41:59 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 04:20:00 GMT, Alexey Semenyuk wrote: >> test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControlTest.java line 698: >> >>> 696: private static List testSomeSavedOutput() { >>> 697: var testIds = List.of(/* 10, 67, 456 */); >>> 698: if (testIds.isEmpty()) { >> >> Can you explain what this method do? `testIds` is always empty, so not sure what it tries to do. > > This method is for debugging individual `testSavedOutput()` test cases. It is disabled by default. If you replace `/* 10, 67, 456 */` with the index(es) of a specific `testSavedOutput()` test case(s), the test will run only selected test cases instead of running all of them. > > The total number of `testSavedOutput()` test cases is ~1500. When some fail and need debugging, it is a waste of time to run them all. This method allows running only selected test cases. It works this way: > - Run CommandOutputControlTest test. > - If some `testSavedOutput` test cases fail, capture their IDs (test case ID is an index starting from 1). > - Replace `/* 10, 67, 456 */` with the captured test case IDs. > - Rerun CommandOutputControlTest test. This time, it will not run all `testSavedOutput` test cases; only the captured ones will be run. > > Right now, this functionality isn't actually used as all test cases pass, but it may come in handy when updating the CommandOutputControlTest test. Can you add comment to `testSomeSavedOutput` to explain this? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28733#discussion_r2670291644 From redestad at openjdk.org Wed Jan 7 23:49:26 2026 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 7 Jan 2026 23:49:26 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:19:43 GMT, Jonas Norlinder wrote: >> # 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. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fixes from review To prevent sprawl would you agree to move the microbenchmark into a sub-class of `org.openjdk.bench.java.io.FileWrite` such as `FileWrite.Open`? Might add a bit of context that would make it clearer that it's about measuring the file open overheads in a write-only scenario. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28823#issuecomment-3721296864 From rotanolexandr842 at gmail.com Thu Jan 8 00:13:16 2026 From: rotanolexandr842 at gmail.com (Olexandr Rotan) Date: Thu, 8 Jan 2026 02:13:16 +0200 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: I am not sure if thoughts similar to mine were already present in the thread, but I am not sure there is any particular value in adding any replacement methods for deprecated ones. To me it seems like path.toString.{starts,ends}With provides endlessly more clarity on what is going on, besides maybe pathString{ends,starts}With, but this name seems clumsy, in some way resembling some denormalized column name in db in a way that it traverses multiple mental indirections to explain clearly enough what it does So, as I think, unless there is a substantial optimization to offer from merging this two operations, i would prefer just suggesting to use toString().{starts,ends}With directly Best regards On Wed, Jan 7, 2026 at 11:45?PM Brian Burkhalter < brian.burkhalter at oracle.com> wrote: > In the list below I omitted adding Path.{ends,starts}WithString(String) > which is different from item 3 in the list. > > Brian > > On Jan 7, 2026, at 12:34?PM, Brian Burkhalter > wrote: > > Among doubtlessly many others, one alternative is > > 1. Leave Path.{ends,starts}With(Path) unchanged > 2. Deprecate Path.{ends,starts}With(String) > 3. Add Path.pathString{ends,starts}With(String) > > where "pathstring" in effect implies the value of Path.toString(). > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From brian.burkhalter at oracle.com Thu Jan 8 00:25:30 2026 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Jan 2026 00:25:30 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: Thanks for helping to continue to the discussion. On Jan 7, 2026, at 4:13?PM, Olexandr Rotan wrote: I am not sure if thoughts similar to mine were already present in the thread, but I am not sure there is any particular value in adding any replacement methods for deprecated ones. Nor am I. To me it seems like path.toString.{starts,ends}With provides endlessly more clarity on what is going on, besides maybe pathString{ends,starts}With, but this name seems clumsy, in some way resembling some denormalized column name in db in a way that it traverses multiple mental indirections to explain clearly enough what it does Indeed the name is clumsy. So, as I think, unless there is a substantial optimization to offer from merging this two operations, i would prefer just suggesting to use toString().{starts,ends}With directly Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else. Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From john.r.rose at oracle.com Thu Jan 8 00:30:06 2026 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 Jan 2026 16:30:06 -0800 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: <5D44395C-D731-4F19-88AC-BB82AA1D771E@oracle.com> On 7 Jan 2026, at 12:34, Brian Burkhalter wrote: > Resuscitating this discussion thread from last year ... > > To summarize my rereading of the thread, there is good agreement that Path.{ends,starts}With(String) should be deprecated and replaced with something else, perhaps Path.{ends,starts}WithString(String). There was also a parallel suggestion that Path.{ends,starts}With(Path) be deprecated in favor of Path.{ends,starts}WithPath(Path). Thus: > > * Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String) > * Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path) > > Among doubtlessly many others, one alternative is > > 1. Leave Path.{ends,starts}With(Path) unchanged > 2. Deprecate Path.{ends,starts}With(String) > 3. Add Path.pathString{ends,starts}With(String) > > where "pathstring" in effect implies the value of Path.toString(). > > Comments? $0.02 ? I like it. I think David and Pavel have pointed out a legitimately significant "sharp edge" in the API, where it is too easy to read /foo.startsWith("bar")/ and read that as a string operation. But it isn?t. (Any other string-like methods out there? Any other /foo/ that responds to /.startsWith("bar")/ but does something different from /foo.toString()/?) Olexandr?s observation about factoring the string ops via Path::toString is also spot-on. However, it?s not a cure-all, especially given the "false friend" methods already in Path. I would suggest that, if we add new "true friend" methods in Path, that they should say something like "this is the same as calling /toString().startWith(x)/ but may be more efficient". Javadoc does (at least) two useful things at the same time: It A. makes it easier to discover useful API points, and B. teaches you how to use both those API points and related ones. The very presence of Path::endsWithString (or whatever) makes the useful API point (A) discoverable, but then it can also suggest, (B) "hey, did you consider calling toString first?". ? John From john.r.rose at oracle.com Thu Jan 8 00:32:58 2026 From: john.r.rose at oracle.com (John Rose) Date: Wed, 07 Jan 2026 16:32:58 -0800 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: On 7 Jan 2026, at 16:25, Brian Burkhalter wrote: > ?So, as I think, unless there is a substantial optimization to offer from merging this two operations, i would prefer just suggesting to use toString().{starts,ends}With directly > > Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else. $0.01 more ? I?m OK with that, as long as the javadoc teaches the toString technique in some discoverable manner. And not just via the deprecated methods?? From stuart.marks at oracle.com Thu Jan 8 00:36:04 2026 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 7 Jan 2026 16:36:04 -0800 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: On 1/7/26 12:34 PM, Brian Burkhalter wrote: > Resuscitating ?this discussion thread from last year ... > > To summarize my rereading of the thread, there is good agreement that > Path.{ends,starts}With(String) should be deprecated and replaced with something > else, perhaps Path.{ends,starts}WithString(String). There was also a parallel > suggestion that Path.{ends,starts}With(Path) be deprecated in favor of > Path.{ends,starts}WithPath(Path). Thus: > > * Path.{ends,starts}With(String) -> Path.{ends,starts}WithString(String) > * Path.{ends,starts}With(Path) -> Path.{ends,starts}WithPath(Path) My experience is that deprecation for the purposes of renaming doesn't work very well. I don't think we're intending to remove the old APIs, so they'd remain, so "renaming" would merely be the addition of new APIs with similar names. This would just make things more confusing. The main problem is that Path.{ends,starts}With(String) is confusing and misleading, so let's focus on that. > Among doubtlessly many others, one alternative is > > 1. Leave Path.{ends,starts}With(Path) unchanged This makes sense. I haven't seen any evidence that this is a problem if one is already working in the Path domain. > 2. Deprecate Path.{ends,starts}With(String) This is the confusing one, so yes, deprecate this (not for removal). It's an open question regarding what the deprecation text should recommend be used instead. Perhaps some of the discussion below will resolve this. > 3. Add Path.pathString{ends,starts}With(String) > > where "pathstring" in effect implies the value of Path.toString(). Before we start adding new APIs, I think we should consider which use cases we think we want to support. The methods take a string argument, and the two cases are whether the operation is performed on Paths and Path segments or whether the operation is performed in terms of Strings. For brevity I'll just use "EW" to represent the "endsWith" operation in either domain, but the analysis applies equally to the "startsWith" operation. Suppose we start off with var path = Path.of("/one/two/three"); The cases are: a) Path domain. The code path.EW(string) is equivalent to path.endsWith(path.getFileSystem().getPath(string)) ??? // note, this is Path.endsWith(Path) and thus we have ??? path.EW("/two/three") ==> false ??? path.EW("two/three") ==> true b) String domain. The code path.EW(string) is equivalent to ??? path.toString().endsWith(string) ??? // note, this is String.endsWith(String) and thus we have ??? path.EW("/two/three") ==> true ??? path.EW("two/three") ==> true ===== I'm not convinced we need any new APIs at all. It seems likely that many people want to perform the string-based endsWith() operation, in which case maybe it's best to be explicit and convert the path to a string using toString() before doing that. Adding a deprecation for Path.endsWith(String) should warn people not to use this method for the string-domain case. If you want to perform this operation in the Path domain, maybe it's best to be explicit about it. If you're writing library code that wants to be very general, then you probably have the relevant FileSystem in a local variable already, and you might construct Path objects explicitly before invoking the endsWith(Path) operation. Using string literals directly, and having them implicitly be converted to Path objects, seems like it easily leads to subtle problems (such as the difference in behavior between my "/two/three" and "two/three" examples above.) So, maybe being explicit is better, even if it is more verbose and less convenient. If you're writing an application that uses the default FileSystem everywhere, and you really want to perform a Path-based operation, you can just slap Path.of() around your string literal and move on. I don't think we need another method to handle this case. So, maybe do (1) and (2) but omit (3). This boils down to just deprecating endsWith(String) and startsWith(String). s'marks > > Comments? > > Brian > >> On Nov 2, 2025, at 3:35?PM, David Alayachew wrote: >> >> As for deprecations, I still think all 4 methods should be deprecated. This path >> variants are kind of ok, but the String variants are just too deceptively named. >> >> I think Rob Spoor hit it on the head with this quote. >> >> > Perhaps both can be added? >> > >> > Path.{start,end}sWithString would default to calling >> > toString().{start,end}sWith(arg) and >> > Path.{start,end}sWithPath would default to calling >> > {start,end}sWith(arg). The latter could default to >> > calling {start,end}sWith(getFileSystem().getPath(arg)) >> > but then custom implementations that do something else >> > (in addition) may not work as expected. >> >> Doing it this way, we can have (start|end)sWithPath() have both String and Path >> overloads with no ambiguity. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Thu Jan 8 00:48:25 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 8 Jan 2026 00:48:25 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions In-Reply-To: References: Message-ID: On Sun, 16 Nov 2025 03:48:31 GMT, Mohamed Issa wrote: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069: > 2067: } else { > 2068: __ ucomiss(reg1, opr2->as_xmm_float_reg()); > 2069: } Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2579691412 From missa at openjdk.org Thu Jan 8 00:48:26 2026 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 8 Jan 2026 00:48:26 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions In-Reply-To: References: Message-ID: On Tue, 2 Dec 2025 05:59:53 GMT, Jatin Bhateja wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069: > >> 2067: } else { >> 2068: __ ucomiss(reg1, opr2->as_xmm_float_reg()); >> 2069: } > > Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times. FYI, this portion could be split into a separate PR. However, I created a couple of macros so that you can check and verify if they match what you are thinking of. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2612392221 From missa at openjdk.org Thu Jan 8 00:48:24 2026 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 8 Jan 2026 00:48:24 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions Message-ID: Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 ------------- Commit messages: - Fix CMove IR tests to account for APX presence - Merge branch 'master' into user/missa-prime/avx10_2 - Update the copyright year in modified files - Happy New Year! - Re-introduce two missing UseAPX flag checks in cmov section of x86.ad file - Further cmov re-ordering in x86.ad file - Re-order cmov definitions for easier review readability - Increase measurement iteration duration to 5 seconds in FPComparison.java - Correct expensive fixup formatting and use AVX10.2 instructions in new three-way comparison definitions - Merge branch 'master' into user/missa-prime/avx10_2 - Manually resolve conflicts in FPComparion.java - ... and 7 more: https://git.openjdk.org/jdk/compare/dd20e915...1e62b5a3 Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8371955 Stats: 1036 lines in 9 files changed: 852 ins; 92 del; 92 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From missa at openjdk.org Thu Jan 8 00:48:27 2026 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 8 Jan 2026 00:48:27 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions In-Reply-To: References: Message-ID: On Thu, 11 Dec 2025 23:33:41 GMT, Mohamed Issa wrote: >> src/hotspot/cpu/x86/c1_LIRAssembler_x86.cpp line 2069: >> >>> 2067: } else { >>> 2068: __ ucomiss(reg1, opr2->as_xmm_float_reg()); >>> 2069: } >> >> Please create a new macro assembly routine for this if-else idiom, its getting repeated multiple times. > > FYI, this portion could be split into a separate PR. However, I created a couple of macros so that you can check and verify if they match what you are thinking of. I moved the logic out of this PR. I'll create another one containing it that will be linked to [JDK-8373834](https://bugs.openjdk.org/browse/JDK-8373834). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2670502059 From brian.burkhalter at oracle.com Thu Jan 8 01:02:30 2026 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 8 Jan 2026 01:02:30 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> Message-ID: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> Thanks for the useful comments. On Jan 7, 2026, at 4:32?PM, John Rose wrote: Maybe that is the way to go: just deprecating Path.{ends,starts}With(String) and nothing else. $0.01 more ? I?m OK with that, as long as the javadoc teaches the toString technique in some discoverable manner. And not just via the deprecated methods?? On Jan 7, 2026, at 4:36?PM, Stuart Marks wrote: So, maybe do (1) and (2) but omit (3). This boils down to just deprecating endsWith(String) and startsWith(String). We have had a bit of a race condition in this discussion, but at least there appears to be some agreement that deprecation alone (with some javadoc enhancement) is a good way to go. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Thu Jan 8 01:03:58 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 01:03:58 GMT Subject: [jdk26] RFR: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:58:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this (clean) backport of the doc-only fix to jlink's man page? The original fix was done in JDK mainline by Ana here https://github.com/openjdk/jdk/pull/29069 and addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374632. Thank you Iris for the review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29083#issuecomment-3721469191 From jpai at openjdk.org Thu Jan 8 01:14:59 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 01:14:59 GMT Subject: [jdk26] Integrated: 8374632: Broken list layout in the man page of jlink In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 09:58:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this (clean) backport of the doc-only fix to jlink's man page? The original fix was done in JDK mainline by Ana here https://github.com/openjdk/jdk/pull/29069 and addresses the issue noted in https://bugs.openjdk.org/browse/JDK-8374632. This pull request has now been integrated. Changeset: d0a3ba9d Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/d0a3ba9db5f9c48ee6b77643770fcee1177d6a1e Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod 8374632: Broken list layout in the man page of jlink Reviewed-by: iris Backport-of: a01283a5a57723673b1fd3c93434678fdae4102c ------------- PR: https://git.openjdk.org/jdk/pull/29083 From asemenyuk at openjdk.org Thu Jan 8 01:36:52 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 01:36:52 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v3] In-Reply-To: References: Message-ID: <4tpqqdOUdvyFBelDT98eNcZFnrxULPsMteNQ2p5khVo=.5e65711f-c919-491b-9f7a-88340b168c18@github.com> > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private Alexey Semenyuk has updated the pull request incrementally with five additional commits since the last revision: - Fix review findings - internal/Executor: rework capturing of command output - CommandOutputControl: rename ExecutableSpec into ExecutableAttributes - MockUtils: expose for use from other packages; add JPackageToolProviderBuilder helper class; fix arguments passed in a command mock when it replaces a tool provider - JPackageCommand: fix withToolProvider(): 1) reset toolProvider; 2) propagate exceptions from the worker thread to the caller thread; 3) reorder the parameters for better readability. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28733/files - new: https://git.openjdk.org/jdk/pull/28733/files/0be4bdb9..b5bb8134 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=01-02 Stats: 301 lines in 14 files changed: 188 ins; 29 del; 84 mod Patch: https://git.openjdk.org/jdk/pull/28733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28733/head:pull/28733 PR: https://git.openjdk.org/jdk/pull/28733 From asemenyuk at openjdk.org Thu Jan 8 01:36:54 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 01:36:54 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v2] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:32:33 GMT, Alexey Semenyuk wrote: >> - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). >> - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. >> - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. >> - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. >> >> Supplementary changes: >> - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > test/Executor: minor fix - Address all review comments - Update the patch with changes from a separate project based on this PR ------------- PR Comment: https://git.openjdk.org/jdk/pull/28733#issuecomment-3721522513 From erfang at openjdk.org Thu Jan 8 03:40:41 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 8 Jan 2026 03:40:41 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:53:04 GMT, Paul Sandoz wrote: > This looks good. Before we integrate we will run it through our test system and report back to you. Ok, thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3721740096 From jpai at openjdk.org Thu Jan 8 05:24:06 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 05:24:06 GMT Subject: RFR: 8374754: jtreg failure handler - replace inline javascript and inline event handlers with same origin javascript files Message-ID: Can I please get a review of this change to the jtreg failure handler that we use in the JDK? As noted in https://bugs.openjdk.org/browse/JDK-8374754 this change addresses the HTML rendering issues that are noticed in certain setups. The change here moves the inline javascript to a file of its own (generated as and when necessary). ------------- Commit messages: - 8374754: jtreg failure handler - replace inline javascript and inline event handlers with same origin javascript files Changes: https://git.openjdk.org/jdk/pull/29106/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29106&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374754 Stats: 155 lines in 4 files changed: 92 ins; 39 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/29106.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29106/head:pull/29106 PR: https://git.openjdk.org/jdk/pull/29106 From xgong at openjdk.org Thu Jan 8 06:04:09 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 8 Jan 2026 06:04:09 GMT Subject: RFR: 8373344: Add support for min/max reduction operations for Float16 [v2] In-Reply-To: References: <7qXqIBuLDFEKPNje6TALxZUATujnOY5hoODC30zJNFM=.07d8d157-1ae5-4751-befd-d6291370fb9c@github.com> <72RiEFo5wji1vOtIRzFwO03_0OsaCe2zzHjp9YPD8-k=.6a88f4eb-3fff-4fe5-bb43-260d81b7954a@github.com> Message-ID: <5gzL6qDaWABljSVUvMLm1oyMgTXwrcjDv1h9ZQH6_DA=.5b284a21-fa15-4c2b-8517-665a6ae5a4c6@github.com> On Wed, 7 Jan 2026 17:33:42 GMT, Yi Wu wrote: >You mean move it down, like Op_AddReductionVI and Op_AddReductionVL to use return !VM_Version::use_neon_for_vector(length_in_bytes);? Yes, that was what I mean. > It doesn't to make much of a difference. So what does `8B/16B/32B` mean? I guess it means the real vector size of the reduction operation? But how did you test these cases, as I noticed the code of benchmarks do not have any parallelization differences. Is the vectorization factor decided by using different `MaxVectorSize` vm option ? If so, then I think the partial cases are not touched. Could you please check whether instruction of `VectorMaskGenNode` is generated from the generated code? I assume there should be difference, because for partial cases (vector_size < MaxVectorSize), it uses the SVE predicated instructions before, while it uses NEON instructions after. And the instruction latency/throughput of SVE reduction are much worse than NEON ones. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28828#discussion_r2670981173 From alanb at openjdk.org Thu Jan 8 06:38:17 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Jan 2026 06:38:17 GMT Subject: [jdk26] Integrated: 8369227: Virtual thread stuck in PARKED state In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 11:22:50 GMT, Alan Bateman wrote: > Clean backport to fix regression in JDK 25 when VirtualThread implementation was changed to use the FJP delayed task support. This pull request has now been integrated. Changeset: d5140f2a Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/d5140f2a16d2452e4bfff31651a7cf20e0d49fc0 Stats: 165 lines in 3 files changed: 143 ins; 11 del; 11 mod 8369227: Virtual thread stuck in PARKED state Reviewed-by: jpai Backport-of: f83918c692143802f2e94bed72dfe7121d1742f9 ------------- PR: https://git.openjdk.org/jdk/pull/29086 From alanb at openjdk.org Thu Jan 8 06:38:39 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 8 Jan 2026 06:38:39 GMT Subject: [jdk26] Integrated: 8373427: StructuredTaskScope::join not clear if called with interrupted status set In-Reply-To: References: Message-ID: <6eyDvwSllGCs_nGy5eKDF_qBNSsQw1UoosrkhdvN0qQ=.79b65c97-615d-4915-b70a-453eed69f3d2@github.com> On Wed, 7 Jan 2026 11:22:23 GMT, Alan Bateman wrote: > Clean backport of docs-only change. The CSR was approved for 26, 27. This pull request has now been integrated. Changeset: 09f0076e Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/09f0076ef714ae60a06dcdb1009539bb68b94b6c Stats: 9 lines in 1 file changed: 3 ins; 1 del; 5 mod 8373427: StructuredTaskScope::join not clear if called with interrupted status set Reviewed-by: jpai Backport-of: 6af27420e3b1980bc093776e3db76072123f7487 ------------- PR: https://git.openjdk.org/jdk/pull/29085 From almatvee at openjdk.org Thu Jan 8 06:47:22 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 8 Jan 2026 06:47:22 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v3] In-Reply-To: <4tpqqdOUdvyFBelDT98eNcZFnrxULPsMteNQ2p5khVo=.5e65711f-c919-491b-9f7a-88340b168c18@github.com> References: <4tpqqdOUdvyFBelDT98eNcZFnrxULPsMteNQ2p5khVo=.5e65711f-c919-491b-9f7a-88340b168c18@github.com> Message-ID: On Thu, 8 Jan 2026 01:36:52 GMT, Alexey Semenyuk wrote: >> - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). >> - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. >> - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. >> - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. >> >> Supplementary changes: >> - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private > > Alexey Semenyuk has updated the pull request incrementally with five additional commits since the last revision: > > - Fix review findings > - internal/Executor: rework capturing of command output > - CommandOutputControl: rename ExecutableSpec into ExecutableAttributes > - MockUtils: expose for use from other packages; add JPackageToolProviderBuilder helper class; fix arguments passed in a command mock when it replaces a tool provider > - JPackageCommand: fix withToolProvider(): 1) reset toolProvider; 2) propagate exceptions from the worker thread to the caller thread; 3) reorder the parameters for better readability. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28733#pullrequestreview-3637959371 From pminborg at openjdk.org Thu Jan 8 08:18:31 2026 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Jan 2026 08:18:31 GMT Subject: Integrated: 8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc In-Reply-To: References: Message-ID: <_4zGOO--hpvzhOXWrvmLwezEcPc1StHte8USfGHY2pA=.ecc196ef-a9ce-463e-b4d4-bdfbfa64af77@github.com> On Wed, 7 Jan 2026 15:19:07 GMT, Per Minborg wrote: > This PR proposes to fix errors in the documentation for the internal classes `jdk.internal.util.ByteArray` and `jdk.internal.util.ByteArrayLittleEndian`. This pull request has now been integrated. Changeset: 1a6da449 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/1a6da4499cf8805ff3e1e517fbca81c2eeb987a9 Stats: 14 lines in 2 files changed: 0 ins; 0 del; 14 mod 8374467: Incorrect ranges in jdk.internal.util.ByteArray JavaDoc Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/29095 From alan.bateman at oracle.com Thu Jan 8 09:39:31 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Thu, 8 Jan 2026 09:39:31 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> Message-ID: On 08/01/2026 01:02, Brian Burkhalter wrote: > > We have had a bit of a race condition in this discussion, but at least > there appears to be some agreement that deprecation alone (with some > javadoc enhancement) is a good way to go. It would be also be good to try again to get a handle on the use-cases around the convention that we know as the "file extension". We've had several failed attempts on this but I think you make good progress on defining it at the last iteration. That is, I assume some temptation to use endsWith(String) is just wanting to test if the string representation has an interesting suffix. -Alan From vyazici at openjdk.org Thu Jan 8 09:51:51 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 8 Jan 2026 09:51:51 GMT Subject: [jdk26] RFR: 8374700: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics Message-ID: Backport of [JDK-8374210] integrated in 7e18de13 by #29055. [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 ------------- Commit messages: - Backport 7e18de137c3b5f08a479af2b64eb22923261900b Changes: https://git.openjdk.org/jdk/pull/29112/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29112&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374700 Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/29112.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29112/head:pull/29112 PR: https://git.openjdk.org/jdk/pull/29112 From thartmann at openjdk.org Thu Jan 8 09:59:49 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 8 Jan 2026 09:59:49 GMT Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici wrote: > Backport of [JDK-8374210] integrated in 7e18de13 by #29055. > > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Thanks, looks good to me! ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29112#pullrequestreview-3638650782 From vyazici at openjdk.org Thu Jan 8 09:59:49 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 8 Jan 2026 09:59:49 GMT Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: <1D_MQZOrQacI_1-qfW6g_QXKPtxCT5S-J3MN6JxkwGg=.823bcd7b-1758-48ea-b33d-53b337dbc814@github.com> On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici wrote: > Backport of [JDK-8374210] integrated in 7e18de13 by #29055. > > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Matching the labels with #29055 that this PR is backporting: ------------- PR Comment: https://git.openjdk.org/jdk/pull/29112#issuecomment-3723094738 From redestad at openjdk.org Thu Jan 8 10:12:01 2026 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 8 Jan 2026 10:12:01 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v2] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 20:19:43 GMT, Jonas Norlinder wrote: >> # 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. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Fixes from review Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28823#pullrequestreview-3638711202 From michaelm at openjdk.org Thu Jan 8 10:46:10 2026 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 8 Jan 2026 10:46:10 GMT Subject: RFR: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java In-Reply-To: References: Message-ID: <92HA3ZuPMWdK7mwSMidodXZUakCdrF14GqjHb5fp_eY=.551980d8-7cdd-4d10-80fb-674a17d0ce06@github.com> On Thu, 25 Dec 2025 01:06:33 GMT, Eunbin Son wrote: > ### 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 Marked as reviewed by michaelm (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28985#pullrequestreview-3638821913 From anthonyv.be at outlook.com Thu Jan 8 10:49:32 2026 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Thu, 8 Jan 2026 11:49:32 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> Message-ID: On 1/8/2026 10:39 AM, Alan Bateman wrote: > On 08/01/2026 01:02, Brian Burkhalter wrote: >> We have had a bit of a race condition in this discussion, but at >> least there appears to be some agreement that deprecation alone (with >> some javadoc enhancement) is a good way to go. > It would be also be good to try again to get a handle on the use-cases > around the convention that we know as the "file extension". We've had > several failed attempts on this but I think you make good progress on > defining it at the last iteration. That is, I assume some temptation > to use endsWith(String) is just wanting to test if the string > representation has an interesting suffix. > > -Alan Alan is spot on here, and I'm wholeheartedly in favor of leaving the API untouched. What I believe is needed, is simply to: * add a method to get the file extension from a Path (people want to get the file extension from a Path, notice there's no method to do so, notice `endsWith(String)`, use that, eventually find out it doesn't work as they expected, and then blame `endsWith(String)`) * point out that the current APIs actually are intuitive (when a method is overloaded, I intuitively expect all overloads to behave in the same manner, except for a trivial conversion of their arguments to some canonical form. This is exactly the case here) * remind people to read the Javadoc (the Javadoc of these methods is crystal clear on their behavior) The existing methods are useful (fwiw, in my codebases all uses of `Path::endsWith` invoke the `String` overload) and have many uses in existing codebases (as they've existed for nearly 15 years). And again, the actual issue is people expecting methods to behave as needed in the context of their actual use case (here, in 99% of the cases: testing the file extension), without verifying their expectations by reading the Javadoc. Deprecating these methods is also a sure-fire way to have people introduce subtle bugs in their codebases, as they'd likely "fix" the deprecations by replacing `path.endsWith("other")` with `path.endsWith(Path.of("other"))`. Adding `Path.pathString{ends,starts}With(String)` would be a mistake, I believe. One of the things that makes `Path` such a fine API, is that it cleanly abstracts the OS-specific file separator. These methods would break that abstraction and you'd end up with things like `Path.of("foo\bar").pathStringStartsWith("foo/bar")` and either way you'd have people complaining that its behavior is unintuitive (i.e., some people would expect this to return `true`, others `false`). Anthony From mchevalier at openjdk.org Thu Jan 8 12:05:36 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Thu, 8 Jan 2026 12:05:36 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... Sure, I'll take care of that! ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3723564004 From jpai at openjdk.org Thu Jan 8 12:13:49 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 12:13:49 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: <0d_B4R9Zq-LJRTBxvpxrefgu84mBqj3-U_ctaTt-D_s=.0acd0ad6-140a-4503-b6bd-e51eb914dd30@github.com> On Wed, 7 Jan 2026 15:18:16 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use -1 to represent absence of a GZIP header, from readHeader() method > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 82: > >> 80: usesDefaultInflater = true; >> 81: try { >> 82: readHeader(in, true); > > Any consideration given to using an enum or constant to make it a bit clearer on what the true represents realizing there is a comment in the readHeader method. Not a big deal either way Hello Lance, I hadn't considered those options. Given that this is a private method being invoked only in 2 places, I picked the the trivial way to pass around the boolean. If it's OK I'll let it stay in this manner for this PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672108417 From jpai at openjdk.org Thu Jan 8 12:16:23 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 12:16:23 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: <7i7HqgcsWFLQe4AroC7vVMd2JdzTmSC0AaA_xrRrvoM=.c762c9d5-9493-450a-828f-e77ab89985cd@github.com> On Wed, 7 Jan 2026 15:35:54 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use -1 to represent absence of a GZIP header, from readHeader() method > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 260: > >> 258: } >> 259: crc.reset(); >> 260: assert n > 0 : "incorrect number of header bytes: " + n; > > No problem with this but wondering if we should add this later and look at other places of interest The new place where we return the -1 (representing EOF) is a bit far away from here, so I wanted to be sure that we only return positive values here. It's not too important though, and I just noticed that there aren't any other asserts in this file. So yes, I'll remove this from the PR and we can think of introducing it later if necessary. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672118133 From jpai at openjdk.org Thu Jan 8 12:23:03 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 12:23:03 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 15:43:06 GMT, Lance Andersen wrote: >> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: >> >> use -1 to represent absence of a GZIP header, from readHeader() method > > src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 219: > >> 217: } else { >> 218: magic = readUShort(in); >> 219: } > > Understand what you are doing but perhaps consider adding more clarity to the comments as you are now cobbling together the int which should contain the GZIP header magic number Do you mean additional comments for the enclosing `if` block? That piece of code is the same as what's currently present in the implementation of `readUShort(...)` except that we won't throw a `EOFException`. Would an additional comment like this be good: // read an unsigned short value representing the GZIP magic header. // this is the same as calling readUShort(in), except that here, // when reading the first byte, we don't raise an EOFException // if the stream has already reached EOF. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672133418 From lancea at openjdk.org Thu Jan 8 12:34:13 2026 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 8 Jan 2026 12:34:13 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: <0d_B4R9Zq-LJRTBxvpxrefgu84mBqj3-U_ctaTt-D_s=.0acd0ad6-140a-4503-b6bd-e51eb914dd30@github.com> References: <0d_B4R9Zq-LJRTBxvpxrefgu84mBqj3-U_ctaTt-D_s=.0acd0ad6-140a-4503-b6bd-e51eb914dd30@github.com> Message-ID: On Thu, 8 Jan 2026 12:10:36 GMT, Jaikiran Pai wrote: >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 82: >> >>> 80: usesDefaultInflater = true; >>> 81: try { >>> 82: readHeader(in, true); >> >> Any consideration given to using an enum or constant to make it a bit clearer on what the true represents realizing there is a comment in the readHeader method. Not a big deal either way > > Hello Lance, I hadn't considered those options. Given that this is a private method being invoked only in 2 places, I picked the the trivial way to pass around the boolean. If it's OK I'll let it stay in this manner for this PR. Hi jai, ?keeping as is is fine. Perhaps if you are making additional updates just add a comment to what make it clear as to why true is passed here >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 219: >> >>> 217: } else { >>> 218: magic = readUShort(in); >>> 219: } >> >> Understand what you are doing but perhaps consider adding more clarity to the comments as you are now cobbling together the int which should contain the GZIP header magic number > > Do you mean additional comments for the enclosing `if` block? That piece of code is the same as what's currently present in the implementation of `readUShort(...)` except that we won't throw a `EOFException`. Would an additional comment like this be good: > > > // read an unsigned short value representing the GZIP magic header. > // this is the same as calling readUShort(in), except that here, > // when reading the first byte, we don't raise an EOFException > // if the stream has already reached EOF. Yes that is fine, just helps to,clarify given the code is outside readUShort which will make things clearer for others later on >> src/java.base/share/classes/java/util/zip/GZIPInputStream.java line 260: >> >>> 258: } >>> 259: crc.reset(); >>> 260: assert n > 0 : "incorrect number of header bytes: " + n; >> >> No problem with this but wondering if we should add this later and look at other places of interest > > The new place where we return the -1 (representing EOF) is a bit far away from here, so I wanted to be sure that we only return positive values here. It's not too important though, and I just noticed that there aren't any other asserts in this file. So yes, I'll remove this from the PR and we can think of introducing it later if necessary. Sounds good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672162403 PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672170548 PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672163374 From vyazici at openjdk.org Thu Jan 8 12:35:26 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 8 Jan 2026 12:35:26 GMT Subject: [jdk26] RFR: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: <31ndTk5iWs478rKrz34crpL5m9IoQEXbU1EwqwIKpCU=.faef8dff-858f-4a68-990c-c7716abb625f@github.com> On Thu, 8 Jan 2026 09:53:56 GMT, Tobias Hartmann wrote: >> Backport of [JDK-8374210] integrated in 7e18de13 by #29055. >> >> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 > > Thanks, looks good to me! @TobiHartmann, thanks so much for your kind assistance. Tier 1 is clear on c2ee487015b. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29112#issuecomment-3723665752 From vyazici at openjdk.org Thu Jan 8 12:35:27 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 8 Jan 2026 12:35:27 GMT Subject: [jdk26] Integrated: 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 09:42:58 GMT, Volkan Yazici wrote: > Backport of [JDK-8374210] integrated in 7e18de13 by #29055. > > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 This pull request has now been integrated. Changeset: 867f4620 Author: Volkan Yazici URL: https://git.openjdk.org/jdk/commit/867f4620db9cbd66ae7ed9d11fb919fb3679b012 Stats: 437 lines in 23 files changed: 25 ins; 331 del; 81 mod 8374210: [BACKOUT] Move input validation checks to Java for java.lang.StringCoding intrinsics Reviewed-by: thartmann Backport-of: 7e18de137c3b5f08a479af2b64eb22923261900b ------------- PR: https://git.openjdk.org/jdk/pull/29112 From qamai at openjdk.org Thu Jan 8 12:38:10 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 8 Jan 2026 12:38:10 GMT Subject: Withdrawn: 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28597 From jpai at openjdk.org Thu Jan 8 13:24:57 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 13:24:57 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v3] In-Reply-To: References: Message-ID: > Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? > > In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. > > Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. > > Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. > > Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. > > The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. > > The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. > > No new regression test has been in... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - merge latest from master branch - add a comment explaining the "true" value being passed to readHeader - review suggestion - assert not needed for now - add a comment to clarify the short value being read for GZIP magic header - use -1 to represent absence of a GZIP header, from readHeader() method - 8374644: Regression in GZIPInputStream performance after JDK-7036144 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29092/files - new: https://git.openjdk.org/jdk/pull/29092/files/06e7b370..e0124326 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29092&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29092&range=01-02 Stats: 971 lines in 90 files changed: 429 ins; 247 del; 295 mod Patch: https://git.openjdk.org/jdk/pull/29092.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29092/head:pull/29092 PR: https://git.openjdk.org/jdk/pull/29092 From jpai at openjdk.org Thu Jan 8 13:24:59 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 8 Jan 2026 13:24:59 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v2] In-Reply-To: References: <0d_B4R9Zq-LJRTBxvpxrefgu84mBqj3-U_ctaTt-D_s=.0acd0ad6-140a-4503-b6bd-e51eb914dd30@github.com> Message-ID: On Thu, 8 Jan 2026 12:30:46 GMT, Lance Andersen wrote: >> Do you mean additional comments for the enclosing `if` block? That piece of code is the same as what's currently present in the implementation of `readUShort(...)` except that we won't throw a `EOFException`. Would an additional comment like this be good: >> >> >> // read an unsigned short value representing the GZIP magic header. >> // this is the same as calling readUShort(in), except that here, >> // when reading the first byte, we don't raise an EOFException >> // if the stream has already reached EOF. > > Yes that is fine, just helps to,clarify given the code is outside readUShort which will make things clearer for others later on Done, I've now updated the PR to add relevant comments and remove the assert. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29092#discussion_r2672337032 From lancea at openjdk.org Thu Jan 8 13:28:16 2026 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 8 Jan 2026 13:28:16 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 13:24:57 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? >> >> In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. >> >> Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. >> >> Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. >> >> Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. >> >> The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. >> >> The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. >> >> No n... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - merge latest from master branch > - add a comment explaining the "true" value being passed to readHeader > - review suggestion - assert not needed for now > - add a comment to clarify the short value being read for GZIP magic header > - use -1 to represent absence of a GZIP header, from readHeader() method > - 8374644: Regression in GZIPInputStream performance after JDK-7036144 Thank you for the additional updates Jai. ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29092#pullrequestreview-3639422345 From bolotofski at gmail.com Thu Jan 8 14:46:25 2026 From: bolotofski at gmail.com (Sholto Bolton) Date: Thu, 8 Jan 2026 14:46:25 +0000 Subject: JDK-8272194 java.sql.Date::toLocalDate() broken for dates before 1 A.D Message-ID: Hello all, I am just reaching out to ask about the status of the issue JDK-8272194 (as well as the related bug JDK-8272194 ) I have been dealing with this issue for over a year now, and finally decided to look into fixing it. I believe I have found the solution to it, however I see the issue is already assigned to Lance Andersen (who is hopefully reading this). The solution I have arrived at seems naively simple however, so I imagine there is more to the problem than I have considered. How far along have other fixes for this gotten? Also apologies if this is the wrong mailing list or way to reach out. I am new to the OpenJDK community so I may be lacking in etiquette. Any reply would be appreciated. Thank you, Sholto Bolton -------------- next part -------------- An HTML attachment was scrubbed... URL: From lance.andersen at oracle.com Thu Jan 8 15:16:28 2026 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 8 Jan 2026 15:16:28 +0000 Subject: JDK-8272194 java.sql.Date::toLocalDate() broken for dates before 1 A.D In-Reply-To: References: Message-ID: <7CFD4E7C-C2D0-4A35-A74A-52F4BB3BFA70@oracle.com> Hi Sholto, If you have a fix you would like to provide, please refer to https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix in the OpenJDK developers guide. One of the first steps is signing the OCA, the Oracle Contributor Agreement. Once that is completed and approved, feel free to propose a fix. You will also want to update open/test/jdk/java/sql/testng/test/sql/DateTests.java and open/test/jdk/java/sql/testng/test/sql/TimestampTests.java to validate your change which would be provided as part of your proposed PR Best Lance On Jan 8, 2026, at 9:46?AM, Sholto Bolton wrote: Hello all, I am just reaching out to ask about the status of the issue JDK-8272194 (as well as the related bug JDK-8272194) I have been dealing with this issue for over a year now, and finally decided to look into fixing it. I believe I have found the solution to it, however I see the issue is already assigned to Lance Andersen (who is hopefully reading this). The solution I have arrived at seems naively simple however, so I imagine there is more to the problem than I have considered. How far along have other fixes for this gotten? Also apologies if this is the wrong mailing list or way to reach out. I am new to the OpenJDK community so I may be lacking in etiquette. Any reply would be appreciated. Thank you, Sholto Bolton Lance Andersen Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl at openjdk.org Thu Jan 8 15:18:00 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 15:18:00 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] 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: Change signalWork fencing; in-progress activation changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/54a8672a..b0d99c2f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=19-20 Stats: 131 lines in 1 file changed: 36 ins; 42 del; 53 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 epeter at openjdk.org Thu Jan 8 15:24:54 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 8 Jan 2026 15:24:54 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> <_QEYCQm138PWv2vGjMFvEJ6kfMjGEn_vsuEZ_EPaRxQ=.b42967e5-cc22-4c98-a454-6698ce0a70cf@github.com> Message-ID: On Mon, 5 Jan 2026 12:40:21 GMT, Bhavana Kilambi wrote: >> 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 @eme64 Would you please be able to run some testing internally before I integrate this patch? Thanks! @Bhavana-Kilambi This looks like a great addition! I see that you have some new benchmarks and IR tests. I wonder if it would make sense to add `Float16` benchmarks to this existing test: `test/hotspot/jtreg/compiler/loopopts/superword/TestReductions.java` And also to this Benchmark: `test/micro/org/openjdk/bench/vm/compiler/VectorReduction2.java` It would be nice if we test `simple`, `dotProduct` and `Big` reductions. It can have an impact on profitability. Your `ReductionAddFP16` and `ReductionMulFP16` are already "simple" reductions, so I'd suspect that the other reductions are also profitable. For reference: https://github.com/openjdk/jdk/pull/27803 and https://github.com/openjdk/jdk/pull/25387 ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3724348378 From epeter at openjdk.org Thu Jan 8 15:24:58 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 8 Jan 2026 15:24:58 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... src/hotspot/cpu/aarch64/aarch64_vector.ad line 267: > 265: // Only the Neon instructions need this check. SVE supports half-precision floats > 266: // by default. > 267: if (length_in_bytes < 8 || (UseSVE == 0 && !is_feat_fp16_supported())) { Was the comment about `FEAT_FP16` not supposed to stay at the top of the first Float16 operation? Now it has moved down... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2672782299 From epeter at openjdk.org Thu Jan 8 15:30:01 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 8 Jan 2026 15:30:01 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 459: > 457: short result = (short) 0; > 458: for (int i = 0; i < LEN; i++) { > 459: result = float16ToRawShortBits(add(shortBitsToFloat16(result), shortBitsToFloat16(input1[i]))); Why all the conversions from and to `short` / `Float16`? Is there any benefit to use `short` for the intermediate results? Why not make `result` a `Float16`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2672804207 From cushon at openjdk.org Thu Jan 8 15:49:14 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 8 Jan 2026 15:49:14 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException Message-ID: See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. ------------- Depends on: https://git.openjdk.org/jdk/pull/29075 Commit messages: - Don't rely on the iteration order of Map.of entries - 8208752: Calling a deserialized Lambda might fail with ClassCastException Changes: https://git.openjdk.org/jdk/pull/28943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8208752 Stats: 76 lines in 2 files changed: 66 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/28943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28943/head:pull/28943 PR: https://git.openjdk.org/jdk/pull/28943 From vklang at openjdk.org Thu Jan 8 16:13:03 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 Jan 2026 16:13:03 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 15:18:00 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: > > Change signalWork fencing; in-progress activation changes src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1268: > 1266: * Resizes the queue array and pushes unless out of memory. > 1267: * @param task the task; caller must ensure nonnull > 1268: * @param pool the pool to signal upon resize @DougLea So this param now becomes "the pool to signal upon resize, if null and the queue's owner has a pool then that pool will be used for the signal instead" src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1295: > 1293: ForkJoinWorkerThread o; > 1294: if (pool != null || > 1295: ((o = owner) != null && (pool = o.pool) != null)) Ok, so now you can't intentionally skip a signal by passing `null` as a pool. Might be for the best, since we always want to signal if we deem it to be needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2672970727 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2672974508 From jnorlinder at openjdk.org Thu Jan 8 16:13:04 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 8 Jan 2026 16:13:04 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v3] In-Reply-To: References: 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. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Rename OpenFileStress->OpenFileForWritingBench ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28823/files - new: https://git.openjdk.org/jdk/pull/28823/files/458e1c34..0aef29d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 bolotofski at gmail.com Thu Jan 8 16:24:52 2026 From: bolotofski at gmail.com (Sholto Bolton) Date: Thu, 8 Jan 2026 16:24:52 +0000 Subject: JDK-8272194 java.sql.Date::toLocalDate() broken for dates before 1 A.D In-Reply-To: <7CFD4E7C-C2D0-4A35-A74A-52F4BB3BFA70@oracle.com> References: <7CFD4E7C-C2D0-4A35-A74A-52F4BB3BFA70@oracle.com> Message-ID: Hi Lance, Thank you for your quick reply. I am just in the middle of sorting out the OCA with my company now. Once that is done I will propose my fix. Would you prefer that I send my proposed fix to this thread for discussion before putting up a PR? Cheers, Sholto Bolton On Thu, Jan 8, 2026 at 3:16?PM Lance Andersen wrote: > Hi Sholto, > > If you have a fix you would like to provide, please refer to > https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix in > the OpenJDK developers guide. One of the first steps is signing the OCA, > the Oracle Contributor Agreement. Once that is completed and approved, > feel free to propose a fix. You will also want to > update open/test/jdk/java/sql/testng/test/sql/DateTests.java > and open/test/jdk/java/sql/testng/test/sql/TimestampTests.java to validate > your change which would be provided as part of your proposed PR > > Best > Lance > > On Jan 8, 2026, at 9:46?AM, Sholto Bolton wrote: > > Hello all, > > I am just reaching out to ask about the status of the issue JDK-8272194 > (as well as the related bug > JDK-8272194 ) > > I have been dealing with this issue for over a year now, and finally > decided to look into fixing it. I believe I have found the solution to it, > however I see the issue is already assigned to Lance Andersen (who is > hopefully reading this). > > The solution I have arrived at seems naively simple however, so I imagine > there is more to the problem than I have considered. How far along have > other fixes for this gotten? > > Also apologies if this is the wrong mailing list or way to reach out. I am > new to the OpenJDK community so I may be lacking in etiquette. > > Any reply would be appreciated. > > Thank you, > Sholto Bolton > > > Lance Andersen > Oracle Java Engineering > 1 Network Drive Burlington, MA 01803 > Lance.Andersen at oracle.com > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jnorlinder at openjdk.org Thu Jan 8 16:25:57 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 8 Jan 2026 16:25:57 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v4] In-Reply-To: References: 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. Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: Move to inner-class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28823/files - new: https://git.openjdk.org/jdk/pull/28823/files/0aef29d6..3c4727a8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28823&range=02-03 Stats: 87 lines in 2 files changed: 26 ins; 60 del; 1 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 redestad at openjdk.org Thu Jan 8 16:25:57 2026 From: redestad at openjdk.org (Claes Redestad) Date: Thu, 8 Jan 2026 16:25:57 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v4] In-Reply-To: References: Message-ID: <57EZh6F0V8JNyn6OFFtmz88GOF0GXbkXnhE-1TA0U-8=.d3e99f14-3253-46cf-bc14-1a7e20a4b114@github.com> On Thu, 8 Jan 2026 16:21:59 GMT, Jonas Norlinder wrote: >> # 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. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Move to inner-class Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28823#pullrequestreview-3640204005 From duke at openjdk.org Thu Jan 8 16:28:07 2026 From: duke at openjdk.org (duke) Date: Thu, 8 Jan 2026 16:28:07 GMT Subject: RFR: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:13:04 GMT, Jonas Norlinder wrote: >> # 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. > > Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision: > > Rename OpenFileStress->OpenFileForWritingBench @JonasNorlinder Your change (at version 3c4727a89ad5866af22e1d657d0e86bb682e6676) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28823#issuecomment-3724653512 From dl at openjdk.org Thu Jan 8 16:32:01 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 16:32:01 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <2KfBd7xQwYK9sMq76FrreR3UaK9gXYUn12OdxK4GXPw=.e13f64ea-10e2-4626-a182-f7fbb31343ef@github.com> On Thu, 8 Jan 2026 16:08:41 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Change signalWork fencing; in-progress activation changes > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1268: > >> 1266: * Resizes the queue array and pushes unless out of memory. >> 1267: * @param task the task; caller must ensure nonnull >> 1268: * @param pool the pool to signal upon resize > > @DougLea So this param now becomes "the pool to signal upon resize, if null and the queue's owner has a pool then that pool will be used for the signal instead" Yes. I'll fix the param spec (among other upcoming docs fixes when this settles.) > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1295: > >> 1293: ForkJoinWorkerThread o; >> 1294: if (pool != null || >> 1295: ((o = owner) != null && (pool = o.pool) != null)) > > Ok, so now you can't intentionally skip a signal by passing `null` as a pool. Might be for the best, since we always want to signal if we deem it to be needed. Right. This covers usages of lazySubmit that we don't think can occur in loom, but now there as a safeguard. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673020403 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673015766 From dl at openjdk.org Thu Jan 8 16:32:07 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 16:32:07 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v17] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Fri, 2 Jan 2026 22:56:50 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 24 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Not sure why this merge is necessary >> Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Fix deactivate; faster quiescence >> - 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 >> - ... and 14 more: https://git.openjdk.org/jdk/compare/dd183022...556c5201 > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1307: > >> 1305: ForkJoinTask[] a = array; >> 1306: int b = base, s = top - 1, cap; >> 1307: if (a != null && s - b >= 0 && (cap = a.length) > 0) { > > Would it help to make the assignment to `cap` be `(cap = a.length - 1) >= 0` and then eliminate the `(cap - 1)` in the slotOffset calculations on both sides of `fifo`-branches? There are still some remnants of code coping with annoying fact that C1 needed to have cap (not cap - 1) in a local to do the bounds check elision. I don't think it is needed anymore. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673038453 From dl at openjdk.org Thu Jan 8 16:32:12 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 16:32:12 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <__wx7sEIFs2ZXgA_ZTA3cPslDohSnr5Hqb4gBkncVak=.3ccf756b-44af-42de-ad79-b577c062cfba@github.com> On Wed, 7 Jan 2026 13:40:53 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 28 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Split external push >> - Undo/redo ordering changes >> - Strengthen some orderings >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Not sure why this merge is necessary >> Merge remote-tracking branch 'refs/remotes/origin/JDK-8373118' into JDK-8373118 >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Fix deactivate; faster quiescence >> - recheck avoiding cross-class offsets >> - Merge branch 'openjdk:master' into JDK-8373118 >> - ... and 18 more: https://git.openjdk.org/jdk/compare/c4c1e578...54a8672a > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1955: > >> 1953: break scan; >> 1954: if (U.getReference(a, np) == null && >> 1955: (rescans >= 0 || > > `rescans` cannot be > 0 here given https://github.com/openjdk/jdk/pull/28797/changes#diff-e398beb49cd8d3e6c2f3a8ca8eee97172c57d7f88f3ccd8a3c704632cab32f5fR1952 > > Suggestion: > > (rescans == 0 || Sorry for some transient noise in that commit! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673031703 From dl at openjdk.org Thu Jan 8 16:32:15 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 16:32:15 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v20] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 7 Jan 2026 15:07:41 GMT, Viktor Klang wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1969: >> >>> 1967: } >>> 1968: else if (q.base == b && >>> 1969: U.compareAndSetReference(a, bp, t, null)) { >> >> Would we expect a[bp] to be possible to be something besides `t` or `null` here? If not, I think we could switch to a `U.getAndSetReference(a, bp, null) == t` here? > > Narrator: it won't work since there might be other values than `t` and `null` Right. I once tried to use anyway and cope with unexpected but the overhead for doing it not worth it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673026294 From bpb at openjdk.org Thu Jan 8 16:33:19 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 8 Jan 2026 16:33:19 GMT Subject: Integrated: 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 01:55:16 GMT, Brian Burkhalter wrote: > If on Windows and the `Space` constructor fails with a `RuntimeException`, skip the volume if it is found not to exist. This has been found to be the case for all errors observed recently which appear to be due to the presence of transient volumes. This pull request has now been integrated. Changeset: 677572b4 Author: Brian Burkhalter URL: https://git.openjdk.org/jdk/commit/677572b42d6d0ee62063c3f19ffad1e501ac9bf3 Stats: 40 lines in 2 files changed: 14 ins; 9 del; 17 mod 8372377: Test java/io/File/GetXSpace.java failed: The system cannot find the path specified Reviewed-by: alanb, jpai ------------- PR: https://git.openjdk.org/jdk/pull/29052 From jnorlinder at openjdk.org Thu Jan 8 16:49:16 2026 From: jnorlinder at openjdk.org (Jonas Norlinder) Date: Thu, 8 Jan 2026 16:49:16 GMT Subject: Integrated: 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream In-Reply-To: References: Message-ID: On Mon, 15 Dec 2025 11:49:19 GMT, Jonas Norlinder wrote: > # 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. This pull request has now been integrated. Changeset: c834e4c6 Author: Jonas Norlinder Committer: Claes Redestad URL: https://git.openjdk.org/jdk/commit/c834e4c641bf6c73e88b93c0cdba40a83f3192c1 Stats: 46 lines in 2 files changed: 33 ins; 0 del; 13 mod 8373647: Avoid fstat when opening file for write with RandomAccessFile or FileOutputStream Reviewed-by: redestad, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28823 From lance.andersen at oracle.com Thu Jan 8 16:51:22 2026 From: lance.andersen at oracle.com (Lance Andersen) Date: Thu, 8 Jan 2026 16:51:22 +0000 Subject: JDK-8272194 java.sql.Date::toLocalDate() broken for dates before 1 A.D In-Reply-To: References: <7CFD4E7C-C2D0-4A35-A74A-52F4BB3BFA70@oracle.com> Message-ID: Hi Sholto The PR is the best path forward for the issue in question On Jan 8, 2026, at 11:24?AM, Sholto Bolton wrote: Hi Lance, Thank you for your quick reply. I am just in the middle of sorting out the OCA with my company now. Once that is done I will propose my fix. Would you prefer that I send my proposed fix to this thread for discussion before putting up a PR? Cheers, Sholto Bolton On Thu, Jan 8, 2026 at 3:16?PM Lance Andersen > wrote: Hi Sholto, If you have a fix you would like to provide, please refer to https://openjdk.org/guide/#i-found-an-issue-in-jbs-that-i-want-to-fix in the OpenJDK developers guide. One of the first steps is signing the OCA, the Oracle Contributor Agreement. Once that is completed and approved, feel free to propose a fix. You will also want to update open/test/jdk/java/sql/testng/test/sql/DateTests.java and open/test/jdk/java/sql/testng/test/sql/TimestampTests.java to validate your change which would be provided as part of your proposed PR Best Lance On Jan 8, 2026, at 9:46?AM, Sholto Bolton > wrote: Hello all, I am just reaching out to ask about the status of the issue JDK-8272194 (as well as the related bug JDK-8272194) I have been dealing with this issue for over a year now, and finally decided to look into fixing it. I believe I have found the solution to it, however I see the issue is already assigned to Lance Andersen (who is hopefully reading this). The solution I have arrived at seems naively simple however, so I imagine there is more to the problem than I have considered. How far along have other fixes for this gotten? Also apologies if this is the wrong mailing list or way to reach out. I am new to the OpenJDK community so I may be lacking in etiquette. Any reply would be appreciated. Thank you, Sholto Bolton Lance Andersen Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com [oracle_sig_logo.gif] Lance Andersen | Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: oracle_sig_logo.gif Type: image/gif Size: 658 bytes Desc: oracle_sig_logo.gif URL: From vklang at openjdk.org Thu Jan 8 16:50:28 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 Jan 2026 16:50:28 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <-QfhcQwb3jWVK0l6Er8o0N3G7tYcTUUABpyfLOhNDUQ=.140669b3-7d11-4fd2-83a3-4761f27f1fb3@github.com> On Thu, 8 Jan 2026 15:18:00 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: > > Change signalWork fencing; in-progress activation changes src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830: > 1828: */ > 1829: final void signalWork(WorkQueue q, int qbase) { > 1830: int pc = U.getIntAcquire(this, PARALLELISM); I like this, as this has the nice benefit of seeing potential changes to `parallelism` sooner. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1855: > 1853: break; > 1854: if (c == (c = ctl) && > 1855: c == (c = U.compareAndExchangeLong(this, CTL, c, nc))) { Are there any measurable differences between the above and `c == (c = ctl) && U.compareAndSetLong(this, CTL, c, nc)` or `c == U.compareAndExchangeLong(this, CTL, c, nc)`? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673104063 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673100883 From vklang at openjdk.org Thu Jan 8 16:53:38 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 Jan 2026 16:53:38 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 15:18:00 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: > > Change signalWork fencing; in-progress activation changes src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1961: > 1959: if (q.base == b) { // else inconsistent > 1960: if (t == null) { > 1961: if (q.array == a) { // else resized @DougLea Do we have any good sense of how "far behind" a completed resize a worker can end up being (i.e. looking at an array that has been replaced already)? I'm just thinking if the rescanning is spending cycles looking at the wrong thing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673120173 From michaelm at openjdk.org Thu Jan 8 16:55:34 2026 From: michaelm at openjdk.org (Michael McMahon) Date: Thu, 8 Jan 2026 16:55:34 GMT Subject: RFR: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 01:06:33 GMT, Eunbin Son wrote: > ### 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 You need to prefix the PR title with the bugid as it was before. ie. 8374342: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java ------------- PR Comment: https://git.openjdk.org/jdk/pull/28985#issuecomment-3724759452 From asemenyuk at openjdk.org Thu Jan 8 17:26:22 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 17:26:22 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument Message-ID: Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. ------------- Commit messages: - 8373448: jpackage: StackOverflowError when processing a very long argument Changes: https://git.openjdk.org/jdk/pull/29104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373448 Stats: 44 lines in 2 files changed: 39 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29104/head:pull/29104 PR: https://git.openjdk.org/jdk/pull/29104 From asemenyuk at openjdk.org Thu Jan 8 17:26:23 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 17:26:23 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: <9gNlx3cg9L8n__rPe5tqAqC4tduxI6x8ISvXds_oOQk=.2ba30837-6394-4e0f-b992-58564a98975e@github.com> On Thu, 8 Jan 2026 04:44:55 GMT, Alexey Semenyuk wrote: > Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. > > Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` > > New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` > > Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. > > The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. @sashamatveev PTAL @fguallini can you think of any inputs to stress test/break the new regexp? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29104#issuecomment-3724876512 PR Comment: https://git.openjdk.org/jdk/pull/29104#issuecomment-3724892108 From heidinga at openjdk.org Thu Jan 8 18:32:13 2026 From: heidinga at openjdk.org (Dan Heidinga) Date: Thu, 8 Jan 2026 18:32:13 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 16:02:25 GMT, Per Minborg wrote: >> This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. >> >> On multiple platforms, tested and passed: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> >> Not tested: >> - [ ] tier4 >> - [ ] tier5 >> - [ ] tier6 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a test test/jdk/java/lang/Record/SafeClassInitializerTest.java line 44: > 42: @Test > 43: void printlnNoParamsTest() { > 44: new MyRecord(-1); I don't understand what this is testing as I don't see an AOT cache being built anywhere. What I am I missing? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2673421287 From dl at openjdk.org Thu Jan 8 18:38:41 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 18:38:41 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 16:51:34 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Change signalWork fencing; in-progress activation changes > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1961: > >> 1959: if (q.base == b) { // else inconsistent >> 1960: if (t == null) { >> 1961: if (q.array == a) { // else resized > > @DougLea Do we have any good sense of how "far behind" a completed resize a worker can end up being (i.e. looking at an array that has been replaced already)? I'm just thinking if the rescanning is spending cycles looking at the wrong thing. That loop rereads q.array on each iteration, which means it is never stale. It's possible ito nstead check for staleness and rescan if so. I just tried a version with this, but it's not looking any better. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2673445481 From rgiulietti at openjdk.org Thu Jan 8 18:45:15 2026 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Thu, 8 Jan 2026 18:45:15 GMT Subject: RFR: 8374540: Add comment describing implementation choices of Math.fma [v3] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 22:52:14 GMT, Joe Darcy wrote: >> Add comment describing why Math.fma uses BigDecimal. > > Joe Darcy has updated the pull request incrementally with one additional commit since the last revision: > > Add note on interpreter. Marked as reviewed by rgiulietti (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29044#pullrequestreview-3640754286 From pminborg at openjdk.org Thu Jan 8 18:46:18 2026 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Jan 2026 18:46:18 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v2] In-Reply-To: References: Message-ID: <05JsQN7BVmhvi-aYUdMCsurjMPYUVtVTIQPfcLMelRg=.cf4aa1f9-9c4a-4fb0-8247-37e08b447acc@github.com> On Thu, 8 Jan 2026 18:28:01 GMT, Dan Heidinga wrote: >> Per Minborg has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a test > > test/jdk/java/lang/Record/SafeClassInitializerTest.java line 44: > >> 42: @Test >> 43: void printlnNoParamsTest() { >> 44: new MyRecord(-1); > > I don't understand what this is testing as I don't see an AOT cache being built anywhere. What I am I missing? It asserts that a user-defined record can be annotated with `@AOTSafeClassInitializer`. This was not possible before. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2673455344 From pminborg at openjdk.org Thu Jan 8 18:46:19 2026 From: pminborg at openjdk.org (Per Minborg) Date: Thu, 8 Jan 2026 18:46:19 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v2] In-Reply-To: <05JsQN7BVmhvi-aYUdMCsurjMPYUVtVTIQPfcLMelRg=.cf4aa1f9-9c4a-4fb0-8247-37e08b447acc@github.com> References: <05JsQN7BVmhvi-aYUdMCsurjMPYUVtVTIQPfcLMelRg=.cf4aa1f9-9c4a-4fb0-8247-37e08b447acc@github.com> Message-ID: On Thu, 8 Jan 2026 18:37:40 GMT, Per Minborg wrote: >> test/jdk/java/lang/Record/SafeClassInitializerTest.java line 44: >> >>> 42: @Test >>> 43: void printlnNoParamsTest() { >>> 44: new MyRecord(-1); >> >> I don't understand what this is testing as I don't see an AOT cache being built anywhere. What I am I missing? > > It asserts that a user-defined record can be annotated with `@AOTSafeClassInitializer`. This was not possible before. But maybe that does not work. No. I thought the AOT testing worked as a variant like debug, but that might not be the case. I will take a look at https://github.com/openjdk/jdk/blob/master/test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GeneratedInternedString.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2673464634 From dl at openjdk.org Thu Jan 8 18:52:32 2026 From: dl at openjdk.org (Doug Lea) Date: Thu, 8 Jan 2026 18:52:32 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] 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 two additional commits since the last revision: - Undo unrelated change - Re-introduce acquiring array reads; re-arrange to rely on volatile base index ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/b0d99c2f..d2b6c7c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=20-21 Stats: 26 lines in 1 file changed: 2 ins; 4 del; 20 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 Jan 8 18:52:38 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 18:52:38 GMT Subject: RFR: 8374819: Some I/O streams left unclosed Message-ID: - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. - Add missing try-with-resources for `Class.getResourceAsStream()` calls. ------------- Commit messages: - Close opened streams or replace DocumentBuilder.parse(InputStream) with DocumentBuilder.parse(File) whichever suits better. Changes: https://git.openjdk.org/jdk/pull/29007/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29007&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374819 Stats: 25 lines in 6 files changed: 7 ins; 4 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29007/head:pull/29007 PR: https://git.openjdk.org/jdk/pull/29007 From asemenyuk at openjdk.org Thu Jan 8 18:52:39 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 18:52:39 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: Message-ID: <0CjaQJcC1CaKpUZCMZ8C4OIXIlHrWT21doKPkb9u5ZY=.48849f06-7307-4122-9dba-0ce34c738eec@github.com> On Mon, 29 Dec 2025 23:29:11 GMT, Alexey Semenyuk wrote: > - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. > - Add missing try-with-resources for `Class.getResourceAsStream()` calls. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29007#issuecomment-3725191843 From darcy at openjdk.org Thu Jan 8 18:53:45 2026 From: darcy at openjdk.org (Joe Darcy) Date: Thu, 8 Jan 2026 18:53:45 GMT Subject: Integrated: 8374540: Add comment describing implementation choices of Math.fma In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 17:33:34 GMT, Joe Darcy wrote: > Add comment describing why Math.fma uses BigDecimal. This pull request has now been integrated. Changeset: 8212993a Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/8212993ac331d8761ddb7c0eef23dbfcc6ca0c7d Stats: 17 lines in 1 file changed: 16 ins; 0 del; 1 mod 8374540: Add comment describing implementation choices of Math.fma Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/29044 From jlu at openjdk.org Thu Jan 8 19:04:39 2026 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 Jan 2026 19:04:39 GMT Subject: RFR: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 19:34:16 GMT, Justin Lu wrote: >> Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > parameterize the rest of tests and resolve setup conflicts Thanks for the reviews. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29071#issuecomment-3725233389 From jlu at openjdk.org Thu Jan 8 19:04:41 2026 From: jlu at openjdk.org (Justin Lu) Date: Thu, 8 Jan 2026 19:04:41 GMT Subject: Integrated: 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 21:29:31 GMT, Justin Lu wrote: > Discovered in https://github.com/openjdk/jdk/pull/28911, two test methods in the base test class _AbstractDateTimeTest.java_ were not testing all the `TemporalAccessor`s from `samples()` correctly. This PR updates the test methods to become parametrized so that their assertions do not exit early. This pull request has now been integrated. Changeset: 1342db0b Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/1342db0bde25c111b25f4339ae2a858dc3b15687 Stats: 158 lines in 9 files changed: 7 ins; 46 del; 105 mod 8374051: Incorrect parameterized testing of exceptions in AbstractDateTimeTest.java Reviewed-by: naoto, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/29071 From missa at openjdk.org Thu Jan 8 19:16:12 2026 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 8 Jan 2026 19:16:12 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v2] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Include apx_f in list of verified CPU features for IR encoding ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/1e62b5a3..01bf4573 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From missa at openjdk.org Thu Jan 8 19:20:06 2026 From: missa at openjdk.org (Mohamed Issa) Date: Thu, 8 Jan 2026 19:20:06 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v3] In-Reply-To: References: Message-ID: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Also update copyright year in IREncodingPrinter.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/01bf4573..38735c37 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From kfarrell at openjdk.org Thu Jan 8 19:42:50 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 19:42:50 GMT Subject: RFR: 8364182: Add jcmd VM.properties command Message-ID: The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. ------------- Commit messages: - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch Changes: https://git.openjdk.org/jdk/pull/29124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8364182 Stats: 304 lines in 18 files changed: 186 ins; 77 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From duke at openjdk.org Thu Jan 8 19:43:29 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 8 Jan 2026 19:43:29 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: Message-ID: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> On Mon, 29 Dec 2025 23:29:11 GMT, Alexey Semenyuk wrote: > - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. > - Add missing try-with-resources for `Class.getResourceAsStream()` calls. src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 167: > 165: try { > 166: final Document doc = XmlUtils.initDocumentBuilder().parse( > 167: new ByteArrayInputStream(Files.readAllBytes(appImageFilePath))); would `.parse(appImageFilePath.toFile())` also work? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2673644925 From kfarrell at openjdk.org Thu Jan 8 19:50:08 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 19:50:08 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell 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: - Merge remote-tracking branch 'origin/master' into sec_props2 - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/cda609fc..232feeaa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=00-01 Stats: 211900 lines in 2740 files changed: 163444 ins; 31329 del; 17127 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From duke at openjdk.org Thu Jan 8 20:07:45 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 8 Jan 2026 20:07:45 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell 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: > > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch src/java.base/share/classes/java/security/Security.java line 802: > 800: } > 801: > 802: static Properties getAllSecurityPropertiesReadOnly() { is this method used? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673707473 From cushon at openjdk.org Thu Jan 8 20:08:02 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 8 Jan 2026 20:08:02 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v2] In-Reply-To: References: Message-ID: > See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). > > Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. > > This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. 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 four additional commits since the last revision: - Update test - Merge branch 'JDK-8374654' into JDK-8208752 - Don't rely on the iteration order of Map.of entries - 8208752: Calling a deserialized Lambda might fail with ClassCastException ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28943/files - new: https://git.openjdk.org/jdk/pull/28943/files/272df870..10ee13db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=00-01 Stats: 137 lines in 1 file changed: 137 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28943/head:pull/28943 PR: https://git.openjdk.org/jdk/pull/28943 From asemenyuk at openjdk.org Thu Jan 8 20:20:02 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 20:20:02 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> Message-ID: On Thu, 8 Jan 2026 19:39:54 GMT, Johannes D?bler wrote: >> - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. >> - Add missing try-with-resources for `Class.getResourceAsStream()` calls. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 167: > >> 165: try { >> 166: final Document doc = XmlUtils.initDocumentBuilder().parse( >> 167: new ByteArrayInputStream(Files.readAllBytes(appImageFilePath))); > > would `.parse(appImageFilePath.toFile())` also work? Yes, but `DocumentBuilder#parse(java.io.File)` will throw `SAXException` if the file doesn't exist, while `Files#readAllBytes(Path)` throws `IOException`. This change will break the corresponding unit test. I already tried it. I switched to using `DocumentBuilder#parse(java.io.File)` in the test code because it doesn't matter what exceptions it throws. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2673749253 From kfarrell at openjdk.org Thu Jan 8 20:35:33 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 20:35:33 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: rm unused code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/232feeaa..81655c07 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=01-02 Stats: 6 lines in 1 file changed: 0 ins; 6 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From kfarrell at openjdk.org Thu Jan 8 20:35:37 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 20:35:37 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v2] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 19:50:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell 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: > > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch it seems the ability to hide JCMD commands via DCmdFactory, _hidden has been removed in JDK-8373441, I will search for an alternative method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725657806 From duke at openjdk.org Thu Jan 8 20:52:35 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 8 Jan 2026 20:52:35 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > rm unused code was there a reason why this was not simply added as an option to the existing Vm.system_properties jcmd? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3725733678 From duke at openjdk.org Thu Jan 8 20:55:42 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 8 Jan 2026 20:55:42 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> Message-ID: On Thu, 8 Jan 2026 20:16:17 GMT, Alexey Semenyuk wrote: >> src/jdk.jpackage/share/classes/jdk/jpackage/internal/AppImageFile.java line 167: >> >>> 165: try { >>> 166: final Document doc = XmlUtils.initDocumentBuilder().parse( >>> 167: new ByteArrayInputStream(Files.readAllBytes(appImageFilePath))); >> >> would `.parse(appImageFilePath.toFile())` also work? > > Yes, but `DocumentBuilder#parse(java.io.File)` will throw `SAXException` if the file doesn't exist, while `Files#readAllBytes(Path)` throws `IOException`. This change will break the corresponding unit test. I already tried it. > > I switched to using `DocumentBuilder#parse(java.io.File)` in the test code because it doesn't matter what exceptions it throws. The exception thrown will depend on the DocumentBuilder implementation, but the DocumentBuilder bundled with JDK 25 seems to throw a IOException when parsing a non existent java.io.File Exception in thread "main" java.io.FileNotFoundException: .../nonexistent.xml (The system cannot find the file specified) at java.base/java.io.FileInputStream.open0(Native Method) at java.base/java.io.FileInputStream.open(FileInputStream.java:185) at java.base/java.io.FileInputStream.(FileInputStream.java:139) at java.base/java.io.FileInputStream.(FileInputStream.java:109) at java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86) at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:183) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:665) at java.xml/com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:150) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:862) at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:826) at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:137) at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:248) at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:335) at java.xml/javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:206) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2673860954 From kevinw at openjdk.org Thu Jan 8 21:04:41 2026 From: kevinw at openjdk.org (Kevin Walls) Date: Thu, 8 Jan 2026 21:04:41 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: Message-ID: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> On Thu, 8 Jan 2026 20:35:33 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > rm unused code src/hotspot/share/services/attachListener.cpp line 308: > 306: } > 307: > 308: // Implementation of "properties -security" command. We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2673891775 From roger.riggs at oracle.com Thu Jan 8 21:19:54 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Thu, 8 Jan 2026 16:19:54 -0500 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> Message-ID: <5943f17e-45e2-44ae-bea5-2b6601cdfb36@oracle.com> Hi Daniel, CSR's get few reviewers than PR's. A broader review in the PR can improve the prose and get comments on additional use cases. For myself, I do them in parallel, putting the initial CSR in proposed state to get early feedback from the CSR review. Comments on the PR accumulate and are addressed in the PR and when that settles down, update the PR and finalize. In the CSR, the Compatibility Risk description highlights a typical more serious risk, that of superseding an existing method in an implementation and possibly changing or being in conflict with its semantics. As a protected method, its potential to be in conflict with existing implementations is reduced somewhat. The diff in the CSR should focus on the specification change, not the implementation changes unless they affect visible behavior. (Generally, avoid irrelevant information in the CSR). BTW, P4 is a better priority for this useful addition, P5 is pretty much ignored or trivial and not worth it. Thanks for the followup, Roger On 1/7/26 4:07 PM, Daniel Gredler wrote: > Hi Roger, > > I've created the CSR here: https://bugs.openjdk.org/browse/JDK-8374739 > > Alan also provided some feedback on the original issue here: > https://bugs.openjdk.org/browse/JDK-8374610 > > I was going to wait to create the PR until the CSR has been approved, > if that's OK? > > Take care, > > Daniel > > > On Tue, Jan 6, 2026 at 9:05?PM Daniel Gredler wrote: > > >?It would risky to change the implementation of > BAOS.ensureCapacity to not throw OOME on negative minCapacity. > > Completely agree -- if we wanted the public API contract to match > the `ensureCapacity` method behavior elsewhere, we would leave the > existing method untouched and private, and add a public version > which only delegates to the existing private method if minCapacity > > 0 (almost identical to `AbstractStringBuilder`). > > Take care, > > Daniel > > > On Tue, Jan 6, 2026 at 8:53?PM Roger Riggs > wrote: > > Hi Daniel, > > I stand corrected, any current size (>=0) satisfies the > request (zero is greater than -1). > > I would not say it "ignores" it, just that it already is > greater or equal to the request. > The current phrasing of ByteArrayOutputStream.ensureCapacity > uses the "holds at least" phrasing. > It would risky to change the implementation of > BAOS.ensureCapacity to not throw OOME on negative minCapacity. > > Roger > > > On 1/6/26 1:30 PM, Daniel Gredler wrote: >> Hi Roger, >> >> All points noted, thanks -- just wanted to double check on this: >> >> >?I don't think you could call it `ensureCapacity()` if it >> ignores the request. >> >> If you pass a negative (i.e. invalid) argument, you need to >> either throw an exception or ignore the request. Both >> `ArrayList` and `StringBuilder` simply ignore calls with >> negative arguments (i.e. neither `new >> ArrayList().ensureCapacity(-1)` nor `new >> StringBuilder().ensureCapacity(-1)` throw an exception, they >> just ignore the request). The old `Vector` class does the >> same, though few developers will be using it at this stage. >> >> All of that to say that as a developer, ignoring an >> `ensureCapacity()` call with a negative capacity would not >> have surprised me in the least, and would be consistent with >> the other `ensureCapacity` methods in other core classes. >> >> Let me know your thoughts on this final point, and I'll move >> forward with both the CSR and the PR. >> >> Thanks! >> >> Daniel >> >> >> >> On Tue, Jan 6, 2026 at 3:54?PM Roger Riggs >> wrote: >> >> Hi Daniel, >> >> I don't think you could call it `ensureCapacity()` if it >> ignores the request. >> >> The limit is not specified, different VMs have different >> overheads. >> >> The exception and message are appropriate: >> "java.lang.OutOfMemoryError: Requested array size exceeds >> VM limit " >> >> For negative arguments, an IllegalArgumentException might >> be an improvement in usability for developers. >> >> [2] 8258565 is closed as "will not fix" because the >> memory limits are an implementation parameter, not specified. >> >> Thanks, Roger >> >> p.s. as an API change it will need a CSR. There's a >> "create a CSR" menu item on the issue and a template to >> fill out. >> >> >> On 1/6/26 9:01 AM, Daniel Gredler wrote: >>> Hi Roger, >>> >>> Thanks for the feedback, I've created an issue in JBS >>> [1] and will create the PR in the coming days. >>> >>> This method currently throws an OOME if a negative >>> capacity is requested, but that should never happen >>> because it's only called internally after careful >>> parameter validation. Once it's public, users will be >>> able to request negative?capacities directly. For the >>> public API, I'm leaning towards?quietly ignoring calls >>> with non-positive capacities, a la >>> `AbstractStringBuilder`, instead of throwing an OOME. >>> Let me know if you agree? >>> >>> Also, do you know what the maximum possible requested >>> capacity is here? It would be good to avoid the need for >>> follow-up issues like this one [2] for `ArrayList`. >>> >>> Take care, >>> >>> Daniel >>> >>> [1] https://bugs.openjdk.org/browse/JDK-8374610 >>> [2] https://bugs.openjdk.org/browse/JDK-8258565 >>> >>> >>> >>> On Mon, Jan 5, 2026 at 3:54?PM Roger Riggs >>> wrote: >>> >>> Hi Daniel, >>> >>> That seems reasonable, allowing control over the >>> timing of resizes. >>> Making it public is sensible too. >>> >>> ?From a higher point of view, are you sure you want >>> to be working with >>> ByteArrayOutputStream and not ByteBuffer or Memory >>> Segments? There are >>> more performance possibilities with those APIs. >>> >>> Regards, Roger >>> >>> >>> On 1/5/26 7:15 AM, Daniel Gredler wrote: >>> > Hi, >>> > >>> > I was recently looking at subclassing >>> `ByteArrayOutputStream` in an >>> > application so that I could add a fast >>> VarHandle-based >>> > `writeLong(long)` method (writing 8 bytes to the >>> byte array in one >>> > go). The internal?`ByteArrayOutputStream` buffer >>> is protected, so no >>> > issue there, but `ensureCapacity(int)` is private >>> rather than >>> > protected, and uses the internal `ArraysSupport` >>> class, so it's not >>> > even easy to copy/paste as duplicate code in the >>> subclass. Similar >>> > `ensureCapacity` methods in `ArrayList` and >>> `StringBuilder` are >>> > public. Would a PR adjusting the visibility of >>> this method from >>> > private to protected be accepted? >>> > >>> > Take care, >>> > >>> > Daniel >>> > >>> > >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarrell at openjdk.org Thu Jan 8 21:27:18 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Thu, 8 Jan 2026 21:27:18 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v4] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: - merge - rm unused code - Merge remote-tracking branch 'origin/master' into sec_props2 - static helper method for both jcmd calls - missing ) - working with single arg - updates - update args - two args -not yet tested - initial patch ------------- Changes: https://git.openjdk.org/jdk/pull/29124/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03 Stats: 29 lines in 6 files changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From davidalayachew at gmail.com Thu Jan 8 21:50:02 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Thu, 8 Jan 2026 16:50:02 -0500 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> Message-ID: Thanks for reviving this. I am perfectly happy with the idea of deprecating the Path.{start,ends}With(String), and then only add the file extension method. Originally, I didn't know that new method was on the table, so I suggested a rename. But the file extension api feels like the superior solution. 10 times out of 10, if I am calling endsWith, the only time I am not looking for "whole" path elements is when I am looking for a file extension. In every other instance, the api does exactly what I expect and want. And plus, something like looking for a file extension is better off being explicit. On Thu, Jan 8, 2026, 5:50?AM Anthony Vanelverdinghe wrote: > On 1/8/2026 10:39 AM, Alan Bateman wrote: > > On 08/01/2026 01:02, Brian Burkhalter wrote: > >> We have had a bit of a race condition in this discussion, but at > >> least there appears to be some agreement that deprecation alone (with > >> some javadoc enhancement) is a good way to go. > > It would be also be good to try again to get a handle on the use-cases > > around the convention that we know as the "file extension". We've had > > several failed attempts on this but I think you make good progress on > > defining it at the last iteration. That is, I assume some temptation > > to use endsWith(String) is just wanting to test if the string > > representation has an interesting suffix. > > > > -Alan > Alan is spot on here, and I'm wholeheartedly in favor of leaving the API > untouched. > > What I believe is needed, is simply to: > * add a method to get the file extension from a Path (people want to get > the file extension from a Path, notice there's no method to do so, > notice `endsWith(String)`, use that, eventually find out it doesn't work > as they expected, and then blame `endsWith(String)`) > * point out that the current APIs actually are intuitive (when a method > is overloaded, I intuitively expect all overloads to behave in the same > manner, except for a trivial conversion of their arguments to some > canonical form. This is exactly the case here) > * remind people to read the Javadoc (the Javadoc of these methods is > crystal clear on their behavior) > > The existing methods are useful (fwiw, in my codebases all uses of > `Path::endsWith` invoke the `String` overload) and have many uses in > existing codebases (as they've existed for nearly 15 years). And again, > the actual issue is people expecting methods to behave as needed in the > context of their actual use case (here, in 99% of the cases: testing the > file extension), without verifying their expectations by reading the > Javadoc. > > Deprecating these methods is also a sure-fire way to have people > introduce subtle bugs in their codebases, as they'd likely "fix" the > deprecations by replacing `path.endsWith("other")` with > `path.endsWith(Path.of("other"))`. > > Adding `Path.pathString{ends,starts}With(String)` would be a mistake, I > believe. One of the things that makes `Path` such a fine API, is that it > cleanly abstracts the OS-specific file separator. These methods would > break that abstraction and you'd end up with things like > `Path.of("foo\bar").pathStringStartsWith("foo/bar")` and either way > you'd have people complaining that its behavior is unintuitive (i.e., > some people would expect this to return `true`, others `false`). > > Anthony > -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Thu Jan 8 22:01:59 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 8 Jan 2026 22:01:59 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> Message-ID: On Thu, 8 Jan 2026 20:52:12 GMT, Johannes D?bler wrote: >> Yes, but `DocumentBuilder#parse(java.io.File)` will throw `SAXException` if the file doesn't exist, while `Files#readAllBytes(Path)` throws `IOException`. This change will break the corresponding unit test. I already tried it. >> >> I switched to using `DocumentBuilder#parse(java.io.File)` in the test code because it doesn't matter what exceptions it throws. > > The exception thrown will depend on the DocumentBuilder implementation, but the DocumentBuilder bundled with JDK 25 seems to throw a IOException when parsing a non existent java.io.File > > Exception in thread "main" java.io.FileNotFoundException: .../nonexistent.xml (The system cannot find the file specified) > at java.base/java.io.FileInputStream.open0(Native Method) > at java.base/java.io.FileInputStream.open(FileInputStream.java:185) > at java.base/java.io.FileInputStream.(FileInputStream.java:139) > at java.base/java.io.FileInputStream.(FileInputStream.java:109) > at java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86) > at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:183) > at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:665) > at java.xml/com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:150) > at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:862) > at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:826) > at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:137) > at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:248) > at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:335) > at java.xml/javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:206) Sorry, my comment was incorrect: SAXException is thrown when the directory is passed into `DocumentBuilder#parse(java.io.File)`: org.xml.sax.SAXParseException; systemId: file:/C:/AppData/Local/Temp/junit10902338938727647559/.jpackage.xml/; lineNumber: 1; columnNumber: 1; Premature end of file. Whet it is passed to `Files#readAllBytes(Path)` it throws IOException: java.nio.file.AccessDeniedException: C:\AppData\Local\Temp\junit17123875824397995430.jpackage.xml This change causes failure of the AppImageFileTest#testDirectory test case at https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L118: org.opentest4j.AssertionFailedError: expected: but was: <".jpackage.xml" file in the predefined app image "C:\AppData\Local\Temp\junit10902338938727647559" contains malformed XML data> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141) at jdk.jpackage/jdk.jpackage.internal.AppImageFileTest.testDirectory(AppImageFileTest.java:122) at java.base at 23.0.1/java.lang.reflect.Method.invoke(Method.java:580) at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) AppImageFileTest#testNoSuchFile test case at https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L111 also fails because of an unexpected exception type. In case of a non-existant file, `DocumentBuilder#parse(java.io.File)` throws `java.io.FileNotFoundException`, and `Files#readAllBytes(Path)` throws `java.nio.file.NoSuchFileException`. This change fails AppImageFileTest#testNoSuchFile test case: org.opentest4j.AssertionFailedError: expected: <".jpackage.xml" file is missing in the predefined app image "C:\AppData\Local\Temp\junit3266296985241385507"> but was: at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177) at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141) at jdk.jpackage/jdk.jpackage.internal.AppImageFileTest.testNoSuchFile(AppImageFileTest.java:113) at java.base at 23.0.1/java.lang.reflect.Method.invoke(Method.java:580) at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674044610 From bchristi at openjdk.org Thu Jan 8 22:07:33 2026 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 8 Jan 2026 22:07:33 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode [v3] 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. > > 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 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 @requires test.thread.factory instead of problem listing - Merge branch 'master' into probList - Change ProblemList bugid to 8309303 - add VM/RuntimeArguments.java to ProblemList-Virtual.txt ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28935/files - new: https://git.openjdk.org/jdk/pull/28935/files/2483e66e..56651e24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28935&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28935&range=01-02 Stats: 26731 lines in 2591 files changed: 7154 ins; 4458 del; 15119 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 bchristi at openjdk.org Thu Jan 8 22:07:34 2026 From: bchristi at openjdk.org (Brent Christian) Date: Thu, 8 Jan 2026 22:07:34 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 Sat, 20 Dec 2025 07:20:38 GMT, Alan Bateman wrote: > can you add `@requires test.thread.factory == null` to the test description. Yes, that's much better. Thanks, Alan. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28935#issuecomment-3726021778 From duke at openjdk.org Thu Jan 8 22:11:18 2026 From: duke at openjdk.org (Larry Cable) Date: Thu, 8 Jan 2026 22:11:18 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> References: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 21:02:37 GMT, Kevin Walls wrote: >> Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: >> >> rm unused code > > src/hotspot/share/services/attachListener.cpp line 308: > >> 306: } >> 307: >> 308: // Implementation of "properties -security" command. > > We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... > > This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. > (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2674071763 From joe.darcy at oracle.com Thu Jan 8 22:33:53 2026 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Thu, 8 Jan 2026 14:33:53 -0800 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: <5943f17e-45e2-44ae-bea5-2b6601cdfb36@oracle.com> References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> <5943f17e-45e2-44ae-bea5-2b6601cdfb36@oracle.com> Message-ID: From the CSR FAQ (https://wiki.openjdk.org/spaces/csr/pages/32342047/CSR+FAQs): > Q: If my change needs a CSR review and a code review, which should I > do first? > A: To take a common case of a Java API change, there is some overlap > between the factors considered in a general code review and the > factors considered by the CSR when reviewing the specification and > compatibility impact. (CSR members often participate in code reviews > in addition to their reviews in CSR roles.) An engineer may choose to > run the CSR process and code review in parallel, but feedback from > either channel may be received which requires updates to the proposal > in the other channel. If an engineer chooses to sequence code review > and CSR review, to minimize latency the process expected to provide > more feedback should be run first. HTH, -Joe On 1/8/2026 1:19 PM, Roger Riggs wrote: > Hi Daniel, > > CSR's get few reviewers than PR's. > > A broader review in the PR can improve the prose and get comments on > additional use cases. > For myself, I do them in parallel, putting the initial CSR in proposed > state to get early feedback from the CSR review. > Comments on the PR accumulate and are addressed in the PR and when > that settles down, update the PR and finalize. > > In the CSR, the Compatibility Risk description highlights a typical > more serious risk, that of superseding an existing method in an > implementation and possibly changing or being in conflict with its > semantics. As a protected method, its potential to be in conflict with > existing implementations is reduced somewhat. > > The diff in the CSR should focus on the specification change, not the > implementation changes unless they affect visible behavior. > (Generally, avoid irrelevant information in the CSR). > > BTW, P4 is a better priority for this useful addition, P5 is pretty > much ignored or trivial and not worth it. > > Thanks for the followup, Roger > > > On 1/7/26 4:07 PM, Daniel Gredler wrote: >> Hi Roger, >> >> I've created the CSR here: https://bugs.openjdk.org/browse/JDK-8374739 >> >> Alan also provided some feedback on the original issue here: >> https://bugs.openjdk.org/browse/JDK-8374610 >> >> I was going to wait to create the PR until the CSR has been approved, >> if that's OK? >> >> Take care, >> >> Daniel >> >> From vklang at openjdk.org Thu Jan 8 23:27:38 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 Jan 2026 23:27:38 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 18:35:03 GMT, Doug Lea
wrote: >> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1961: >> >>> 1959: if (q.base == b) { // else inconsistent >>> 1960: if (t == null) { >>> 1961: if (q.array == a) { // else resized >> >> @DougLea Do we have any good sense of how "far behind" a completed resize a worker can end up being (i.e. looking at an array that has been replaced already)? I'm just thinking if the rescanning is spending cycles looking at the wrong thing. > > That loop rereads q.array on each iteration, which means it is never stale. It's possible ito nstead check for staleness and rescan if so. I just tried a version with this, but it's not looking any better. Yeah, I was just thinking that the `array`-field is non-volatile so a read isn't guaranteed to yield anything new unless that read is piggybacking on some other fence. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2674233841 From vklang at openjdk.org Thu Jan 8 23:41:30 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 8 Jan 2026 23:41:30 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 18:52:32 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with two additional commits since the last revision: > > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1261: > 1259: if (U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null && > 1260: pool != null) > 1261: pool.signalWork(this, s); // may have appeared empty @DougLea I really like how push turned out here, it's arguably one of the most elegant versions of this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2674262607 From vklang at openjdk.org Fri Jan 9 00:10:58 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 Jan 2026 00:10:58 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 18:52:32 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with two additional commits since the last revision: > > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2063: > 2061: int idle = IDLE, phase; > 2062: if ((runState & STOP) == 0L && w != null && > 2063: (idle = (phase = w.spinWaitPhase()) & IDLE) != 0) { @DougLea Not that it'll happen frequently, but it _might_ be worth checking `(runState & STOP) == 0L` directly after the spinwait, and then switch from a `for(;;)` to a do-while where the while-condition is `(runState & STOP) == 0L`. That would avoid the small risk of needing to call setCurrentBlocker twice for situations where the pool transitions to STOP while the spinwait is running. It'd be interesting to see if such a change has any discernable impact on ramp-down for benches that include startup and shutdown as a part of the benching process. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2674309609 From almatvee at openjdk.org Fri Jan 9 00:16:37 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 00:16:37 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> Message-ID: On Thu, 8 Jan 2026 21:58:36 GMT, Alexey Semenyuk wrote: >> The exception thrown will depend on the DocumentBuilder implementation, but the DocumentBuilder bundled with JDK 25 seems to throw a IOException when parsing a non existent java.io.File >> >> Exception in thread "main" java.io.FileNotFoundException: .../nonexistent.xml (The system cannot find the file specified) >> at java.base/java.io.FileInputStream.open0(Native Method) >> at java.base/java.io.FileInputStream.open(FileInputStream.java:185) >> at java.base/java.io.FileInputStream.(FileInputStream.java:139) >> at java.base/java.io.FileInputStream.(FileInputStream.java:109) >> at java.base/sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:86) >> at java.base/sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:183) >> at java.xml/com.sun.org.apache.xerces.internal.impl.XMLEntityManager.setupCurrentEntity(XMLEntityManager.java:665) >> at java.xml/com.sun.org.apache.xerces.internal.impl.XMLVersionDetector.determineDocVersion(XMLVersionDetector.java:150) >> at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:862) >> at java.xml/com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:826) >> at java.xml/com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:137) >> at java.xml/com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:248) >> at java.xml/com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(DocumentBuilderImpl.java:335) >> at java.xml/javax.xml.parsers.DocumentBuilder.parse(DocumentBuilder.java:206) > > Sorry, my comment was incorrect: SAXException is thrown when the directory is passed into `DocumentBuilder#parse(java.io.File)`: > > org.xml.sax.SAXParseException; systemId: file:/C:/AppData/Local/Temp/junit10902338938727647559/.jpackage.xml/; lineNumber: 1; columnNumber: 1; Premature end of file. > > > Whet it is passed to `Files#readAllBytes(Path)` it throws IOException: > > java.nio.file.AccessDeniedException: C:\AppData\Local\Temp\junit17123875824397995430.jpackage.xml > > > This change causes failure of the AppImageFileTest#testDirectory test case at > https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L118: > > org.opentest4j.AssertionFailedError: expected: but was: <".jpackage.xml" file in the predefined app image "C:\AppData\Local\Temp\junit10902338938727647559" contains malformed XML data> > at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) > at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) > at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) > at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) > at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177) > at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141) > at jdk.jpackage/jdk.jpackage.internal.AppImageFileTest.testDirectory(AppImageFileTest.java:122) > at java.base at 23.0.1/java.lang.reflect.Method.invoke(Method.java:580) > at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) > at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) > > > AppImageFileTest#testNoSuchFile test case at > https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L111 also fails because of an unexpected exception type. > > In case of a non-existant file, `DocumentBuilder#parse(java.io.File)` throws `java.io.FileNotFoundException`, and `Files#readAllBytes(Path)` throws `java.nio.file.NoSuchFileException`. This change fails AppImageFileTest#testNoSuchFile test case: > > org.opentest4j.AssertionFailedError: expected: <".jpackage.xml" file is missing in the predefined app image "C:\AppData\Local\Temp\junit3266296985241385507"> bu... You need to document it or adjust unit test. It does not make sense to use one approach here and different approach in `AppImageFile` below. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674319081 From almatvee at openjdk.org Fri Jan 9 00:25:12 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 00:25:12 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: <-dfRh6yJlHuKTEPKtUJlQM-68aBL5pbAF2tmKYcwgAs=.1d830288-6ea2-4155-8593-6fdcc12cf6b9@github.com> On Thu, 8 Jan 2026 04:44:55 GMT, Alexey Semenyuk wrote: > Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. > > Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` > > New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` > > Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. > > The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 744: > 742: > 743: static { > 744: System.out.println("OLD: " + pattern); Why we need to print old and new pattern? Looks like debug code was not removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29104#discussion_r2674340410 From asemenyuk at openjdk.org Fri Jan 9 00:34:49 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 00:34:49 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: <-dfRh6yJlHuKTEPKtUJlQM-68aBL5pbAF2tmKYcwgAs=.1d830288-6ea2-4155-8593-6fdcc12cf6b9@github.com> References: <-dfRh6yJlHuKTEPKtUJlQM-68aBL5pbAF2tmKYcwgAs=.1d830288-6ea2-4155-8593-6fdcc12cf6b9@github.com> Message-ID: <9tzby5YG0lNhmHoHPE75pOIiehSBKxM8jB_vqasIBQw=.df5c92aa-5364-4da5-9306-9207fde166e8@github.com> On Fri, 9 Jan 2026 00:21:32 GMT, Alexander Matveev wrote: >> Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. >> >> Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` >> >> New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` >> >> Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. >> >> The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/cli/StandardOption.java line 744: > >> 742: >> 743: static { >> 744: System.out.println("OLD: " + pattern); > > Why we need to print old and new pattern? Looks like debug code was not removed. Oh, the debug output slipped in. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29104#discussion_r2674369242 From sviswanathan at openjdk.org Fri Jan 9 00:36:53 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 9 Jan 2026 00:36:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v3] In-Reply-To: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> References: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Thu, 8 Jan 2026 19:20:06 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Also update copyright year in IREncodingPrinter.java src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1056: > 1054: } > 1055: jcc(Assembler::equal, DONE_LABEL); // handle special case +0.0/-0.0, if argument is +0.0/-0.0, return argument > 1056: jcc(Assembler::parity, DONE_LABEL); // handle special case NaN, if argument NaN, return NaN It looks to me that these two could be replaced by one jcc. For with AVX 10.2: jcc if Sign flag is set to DONE_LABEL For without AVX 10.2: jcc if equal to DONE_LABEL src/hotspot/cpu/x86/x86.ad line 1706: > 1704: __ setcc(Assembler::above, dst); > 1705: __ jcc(Assembler::aboveEqual, done); > 1706: __ movl(dst, -1); This seems to be applicable for both with/without AVX 10.2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674351156 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674367618 From asemenyuk at openjdk.org Fri Jan 9 00:42:31 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 00:42:31 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument [v2] In-Reply-To: References: Message-ID: > Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. > > Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` > > New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` > > Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. > > The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Remove debug output ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29104/files - new: https://git.openjdk.org/jdk/pull/29104/files/8210135a..d8ebb1dd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29104&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29104&range=00-01 Stats: 8 lines in 1 file changed: 0 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29104/head:pull/29104 PR: https://git.openjdk.org/jdk/pull/29104 From asemenyuk at openjdk.org Fri Jan 9 00:57:36 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 00:57:36 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> Message-ID: <03T-DrMOtLDfYpiB8IenkkW-iO4T-oGN_W0OPfM3Zds=.b5133baf-6a8e-4986-a6fa-630579e4e141@github.com> On Fri, 9 Jan 2026 00:13:12 GMT, Alexander Matveev wrote: >> Sorry, my comment was incorrect: SAXException is thrown when the directory is passed into `DocumentBuilder#parse(java.io.File)`: >> >> org.xml.sax.SAXParseException; systemId: file:/C:/AppData/Local/Temp/junit10902338938727647559/.jpackage.xml/; lineNumber: 1; columnNumber: 1; Premature end of file. >> >> >> Whet it is passed to `Files#readAllBytes(Path)` it throws IOException: >> >> java.nio.file.AccessDeniedException: C:\AppData\Local\Temp\junit17123875824397995430.jpackage.xml >> >> >> This change causes failure of the AppImageFileTest#testDirectory test case at >> https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L118: >> >> org.opentest4j.AssertionFailedError: expected: but was: <".jpackage.xml" file in the predefined app image "C:\AppData\Local\Temp\junit10902338938727647559" contains malformed XML data> >> at org.junit.jupiter.api.AssertionFailureBuilder.build(AssertionFailureBuilder.java:151) >> at org.junit.jupiter.api.AssertionFailureBuilder.buildAndThrow(AssertionFailureBuilder.java:132) >> at org.junit.jupiter.api.AssertEquals.failNotEqual(AssertEquals.java:197) >> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:182) >> at org.junit.jupiter.api.AssertEquals.assertEquals(AssertEquals.java:177) >> at org.junit.jupiter.api.Assertions.assertEquals(Assertions.java:1141) >> at jdk.jpackage/jdk.jpackage.internal.AppImageFileTest.testDirectory(AppImageFileTest.java:122) >> at java.base at 23.0.1/java.lang.reflect.Method.invoke(Method.java:580) >> at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) >> at java.base at 23.0.1/java.util.ArrayList.forEach(ArrayList.java:1597) >> >> >> AppImageFileTest#testNoSuchFile test case at >> https://github.com/openjdk/jdk/blob/385c4f8180d30c0e41b848eb4b2c1c8788211422/test/jdk/tools/jpackage/junit/share/jdk.jpackage/jdk/jpackage/internal/AppImageFileTest.java#L111 also fails because of an unexpected exception type. >> >> In case of a non-existant file, `DocumentBuilder#parse(java.io.File)` throws `java.io.FileNotFoundException`, and `Files#readAllBytes(Path)` throws `java.nio.file.NoSuchFileException`. This change fails AppImageFileTest#testNoSuchFile test case: >> >> org.opentest4j.AssertionFailedError: expected: <".jpackage.xml" file is missing in the predefine... > > You need to document it or adjust unit test. It does not make sense to use one approach here and different approach in `AppImageFile` below. The test code bails out on the first unexpected exception. It doesn't transform internal exceptions into localized user-friendly messages, etc. Implementation does. Using the same API in these particular cases solves no problem. I can just use `Files#readAllBytes(Path)` in the test code to satisfy the request for the same approach. It will make no difference, but make the code bulkier than it needs to be. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674409358 From duke at openjdk.org Fri Jan 9 01:01:41 2026 From: duke at openjdk.org (ExE Boss) Date: Fri, 9 Jan 2026 01:01:41 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v3] In-Reply-To: References: Message-ID: On Tue, 9 Dec 2025 11:17:18 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: > > Documenting that the EnumSet::spliterator() is non-fail-fast, and change implNote to implSpec src/java.base/share/classes/java/util/EnumSet.java line 524: > 522: */ > 523: @Override > 524: public final Spliterator spliterator() { Maybe?keep this?method non?`final` so?that?specialised implementations may?be?provided by?`SimpleEnumSet` or?`JumboEnumSet` in?the?future without?needing to?remove the?`final`?modifier. Suggestion: public Spliterator spliterator() { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2674414425 From almatvee at openjdk.org Fri Jan 9 01:12:58 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 01:12:58 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 00:42:31 GMT, Alexey Semenyuk wrote: >> Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. >> >> Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` >> >> New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` >> >> Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. >> >> The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Remove debug output Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29104#pullrequestreview-3641932708 From missa at openjdk.org Fri Jan 9 01:14:36 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 9 Jan 2026 01:14:36 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v3] In-Reply-To: References: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Fri, 9 Jan 2026 00:26:17 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update copyright year in IREncodingPrinter.java > > src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 1056: > >> 1054: } >> 1055: jcc(Assembler::equal, DONE_LABEL); // handle special case +0.0/-0.0, if argument is +0.0/-0.0, return argument >> 1056: jcc(Assembler::parity, DONE_LABEL); // handle special case NaN, if argument NaN, return NaN > > It looks to me that these two could be replaced by one jcc. > For with AVX 10.2: > jcc if Sign flag is set to DONE_LABEL > For without AVX 10.2: > jcc if equal to DONE_LABEL Yes, that would work. The code becomes a little more cryptic, but it should be fine with enough explanation in the comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674435533 From almatvee at openjdk.org Fri Jan 9 01:27:05 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 01:27:05 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: <03T-DrMOtLDfYpiB8IenkkW-iO4T-oGN_W0OPfM3Zds=.b5133baf-6a8e-4986-a6fa-630579e4e141@github.com> References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> <03T-DrMOtLDfYpiB8IenkkW-iO4T-oGN_W0OPfM3Zds=.b5133baf-6a8e-4986-a6fa-630579e4e141@github.com> Message-ID: On Fri, 9 Jan 2026 00:54:23 GMT, Alexey Semenyuk wrote: >> You need to document it or adjust unit test. It does not make sense to use one approach here and different approach in `AppImageFile` below. > > The test code bails out on the first unexpected exception. It doesn't transform internal exceptions into localized user-friendly messages, etc. Implementation does. Using the same API in these particular cases solves no problem. I can just use `Files#readAllBytes(Path)` in the test code to satisfy the request for the same approach. It will make no difference, but make the code bulkier than it needs to be. What I mean that our code expects specific set of exception and `final Document doc = XmlUtils.initDocumentBuilder().parse(new ByteArrayInputStream(Files.readAllBytes(appImageFilePath)));` will throw different set of exception than `final Document doc = XmlUtils.initDocumentBuilder().parse(appImageFilePath.toFile());`. Such difference needs to be documented or code adjusted. Is it possible that `parse()` will change exception being thrown in case if file does not exist? If possible then our code will be broken. If we depend on `java.nio.file.NoSuchFileException` vs `java.io.FileNotFoundException`, then lets throw exception we need by checking if file exist first. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674472974 From missa at openjdk.org Fri Jan 9 01:28:16 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 9 Jan 2026 01:28:16 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v3] In-Reply-To: References: <_GAfe6pIqFre0blQwFU-JXJ79CCSk5Ft_kxJhcg0agw=.acf06ec5-399e-4c48-bd26-f15e8b647908@github.com> Message-ID: On Fri, 9 Jan 2026 00:32:09 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Also update copyright year in IREncodingPrinter.java > > src/hotspot/cpu/x86/x86.ad line 1706: > >> 1704: __ setcc(Assembler::above, dst); >> 1705: __ jcc(Assembler::aboveEqual, done); >> 1706: __ movl(dst, -1); > > This seems to be applicable for both with/without AVX 10.2. Yes, I'll merge and add comments. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2674476014 From asemenyuk at openjdk.org Fri Jan 9 02:09:44 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 02:09:44 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> <03T-DrMOtLDfYpiB8IenkkW-iO4T-oGN_W0OPfM3Zds=.b5133baf-6a8e-4986-a6fa-630579e4e141@github.com> Message-ID: On Fri, 9 Jan 2026 01:24:08 GMT, Alexander Matveev wrote: > Is it possible that `parse()` will change exception being thrown in case if file does not exist? I assume you mean [javax.xml.parsers.DocumentBuilder#parse(java.io.File)](https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/parsers/DocumentBuilder.html#parse(java.io.File)) As we have figured out the default JDK implementation (Xerces XML parser) throws `java.io.FileNotFoundException` if a file doesn't exist and throws `org.xml.sax.SAXParseException` if the file is a directory. Another DOM XML parser (a different version of Xerces?) may behave differently. The use of `javax.xml.parsers.DocumentBuilder#parse(java.io.InputStream)` eliminates differences in how XML parsers handle file system I/O errors. jpackage implementation code delegates filesystem I/O to `java.nio.file.Files`, XML parser deals with the byte stream in memory. We don't depend on how XML parser reports filesystem I/O errors because it reads data from memory, not from the filesystem. In the test code it doesn't matter how specific XML parser handles I/O errors, so we can use `javax.xml.parsers.DocumentBuilder#parse(java.io.File)`. > If we depend on `java.nio.file.NoSuchFileException` vs `java.io.FileNotFoundException`, then lets throw exception we need by checking if file exist first. We don't depend on `java.io.FileNotFoundException`. We depend on `java.nio.file.NoSuchFileException` that `Files.readAllBytes(Path)` may throw before any `DocumentBuilder#parse(...)` is called. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674555049 From almatvee at openjdk.org Fri Jan 9 02:26:25 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 02:26:25 GMT Subject: RFR: 8374819: Some I/O streams left unclosed In-Reply-To: References: <-HgpXVSqMrMWnBw2TxlVE9eq8tftxal_nBbZwjS-caE=.318c8ad8-2774-4bd5-91e7-46ce3e843605@github.com> <03T-DrMOtLDfYpiB8IenkkW-iO4T-oGN_W0OPfM3Zds=.b5133baf-6a8e-4986-a6fa-630579e4e141@github.com> Message-ID: On Fri, 9 Jan 2026 02:06:29 GMT, Alexey Semenyuk wrote: >> What I mean that our code expects specific set of exception and >> `final Document doc = XmlUtils.initDocumentBuilder().parse(new ByteArrayInputStream(Files.readAllBytes(appImageFilePath)));` will throw different set of exception than `final Document doc = XmlUtils.initDocumentBuilder().parse(appImageFilePath.toFile());`. Such difference needs to be documented or code adjusted. Is it possible that `parse()` will change exception being thrown in case if file does not exist? If possible then our code will be broken. If we depend on `java.nio.file.NoSuchFileException` vs `java.io.FileNotFoundException`, then lets throw exception we need by checking if file exist first. > >> Is it possible that `parse()` will change exception being thrown in case if file does not exist? > > I assume you mean [javax.xml.parsers.DocumentBuilder#parse(java.io.File)](https://docs.oracle.com/en/java/javase/25/docs/api/java.xml/javax/xml/parsers/DocumentBuilder.html#parse(java.io.File)) > > As we have figured out the default JDK implementation (Xerces XML parser) throws `java.io.FileNotFoundException` if a file doesn't exist and throws `org.xml.sax.SAXParseException` if the file is a directory. Another DOM XML parser (a different version of Xerces?) may behave differently. > > The use of `javax.xml.parsers.DocumentBuilder#parse(java.io.InputStream)` eliminates differences in how XML parsers handle file system I/O errors. jpackage implementation code delegates filesystem I/O to `java.nio.file.Files`, XML parser deals with the byte stream in memory. We don't depend on how XML parser reports filesystem I/O errors because it reads data from memory, not from the filesystem. > > In the test code it doesn't matter how specific XML parser handles I/O errors, so we can use `javax.xml.parsers.DocumentBuilder#parse(java.io.File)`. > >> If we depend on `java.nio.file.NoSuchFileException` vs `java.io.FileNotFoundException`, then lets throw exception we need by checking if file exist first. > > We don't depend on `java.io.FileNotFoundException`. We depend on `java.nio.file.NoSuchFileException` that `Files.readAllBytes(Path)` may throw before any `DocumentBuilder#parse(...)` is called. // Provide java.io.InputStream instead of java.io.File to eliminates differences in how XML parsers // handle file system I/O errors. jpackage implementation code depends on how java.nio.file.Files // handles I/O errors. final Document doc = XmlUtils.initDocumentBuilder().parse( new ByteArrayInputStream(Files.readAllBytes(appImageFilePath))); Thanks for explanation. We need to document it to be clear. Simple comment will be enough like above. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29007#discussion_r2674578361 From asemenyuk at openjdk.org Fri Jan 9 03:21:12 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 03:21:12 GMT Subject: RFR: 8374819: Some I/O streams left unclosed [v2] In-Reply-To: References: Message-ID: > - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. > - Add missing try-with-resources for `Class.getResourceAsStream()` calls. Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: - AppImageInfoPListFile: simplify - Remove redundant "throws javax.xml.parsers.ParserConfigurationException" from PListReader#PListReader(byte[]) signature - AppImageFile: add a comment explaining why we use javax.xml.parsers.DocumentBuilder#parse(java.io.InputStream) and not javax.xml.parsers.DocumentBuilder#parse(java.io.File), even the later is more suitable for reading XML from a file ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29007/files - new: https://git.openjdk.org/jdk/pull/29007/files/07daf20f..eb36bbfe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29007&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29007&range=00-01 Stats: 25 lines in 4 files changed: 15 ins; 6 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29007.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29007/head:pull/29007 PR: https://git.openjdk.org/jdk/pull/29007 From sshivang at openjdk.org Fri Jan 9 03:28:36 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Fri, 9 Jan 2026 03:28:36 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing Message-ID: Hi all, This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. Thanks! ------------- Commit messages: - Backport e75726ee03ca4664827ca5d680c02bcf2a96f4ea Changes: https://git.openjdk.org/jdk/pull/29131/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29131&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/29131.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29131/head:pull/29131 PR: https://git.openjdk.org/jdk/pull/29131 From sshivang at openjdk.org Fri Jan 9 03:35:13 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Fri, 9 Jan 2026 03:35:13 GMT Subject: [jdk26] RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests Message-ID: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> Hi all, This pull request contains a backport of commit [136ac0d1](https://github.com/openjdk/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Naoto Sato on 6 Jan 2026 and was reviewed by Iris Clark, Joe Wang and Justin Lu. Thanks! ------------- Commit messages: - Backport 136ac0d10b92df8875f36c717e85595740b50ed2 Changes: https://git.openjdk.org/jdk/pull/29132/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29132&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374433 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29132.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29132/head:pull/29132 PR: https://git.openjdk.org/jdk/pull/29132 From asemenyuk at openjdk.org Fri Jan 9 03:42:28 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 03:42:28 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v4] In-Reply-To: References: Message-ID: > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: Rework JPackageCommand#withToolProvider() to run workload in a new native thread instead of a virtual thread from a pool. Pooled and/or virtual threads are problematic when used with inheritable thread-local variables. TKit class depends on such a variable, which results in intermittent test failure: java.util.concurrent.CompletionException: java.lang.NullPointerException: Cannot invoke "jdk.jpackage.test.TestInstance.workDir()" because the return value of "jdk.jpackage.test.TKit.currentTest()" is null at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323) at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359) at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364) at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1828) at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1817) at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511) at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1436) at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2011) at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187) Caused by: java.lang.NullPointerException: Cannot invoke "jdk.jpackage.test.TestInstance.workDir()" because the return value of "jdk.jpackage.test.TKit.currentTest()" is null at jdk.jpackage.test.TKit.workDir(TKit.java:244) at jdk.jpackage.test.JPackageCommand.setDefaultInputOutput(JPackageCommand.java:280) at jdk.jpackage.test.JPackageCommand.helloAppImage(JPackageCommand.java:384) at jdk.jpackage.test.JPackageCommand.helloAppImage(JPackageCommand.java:361) at jdk.jpackage/jdk.jpackage.internal.cli.MainTest.lambda$testFailedCommandOutput$2(MainTest.java:123) at jdk.jpackage.test.JPackageCommand.lambda$withToolProvider$0(JPackageCommand.java:805) at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1825) ... 5 more ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28733/files - new: https://git.openjdk.org/jdk/pull/28733/files/b5bb8134..538ed989 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=02-03 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28733/head:pull/28733 PR: https://git.openjdk.org/jdk/pull/28733 From asemenyuk at openjdk.org Fri Jan 9 03:48:24 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 03:48:24 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v5] In-Reply-To: References: Message-ID: > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: JPackageCommand: add a comment to the new withToolProvider() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28733/files - new: https://git.openjdk.org/jdk/pull/28733/files/538ed989..01c870f9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28733&range=03-04 Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28733.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28733/head:pull/28733 PR: https://git.openjdk.org/jdk/pull/28733 From asemenyuk at openjdk.org Fri Jan 9 03:49:38 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 03:49:38 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:42:28 GMT, Alexey Semenyuk wrote: >> - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). >> - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. >> - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. >> - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. >> >> Supplementary changes: >> - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > Rework JPackageCommand#withToolProvider() to run workload in a new native thread instead of a virtual thread from a pool. Pooled and/or virtual threads are problematic when used with inheritable thread-local variables. TKit class depends on such a variable, which results in intermittent test failure: > > java.util.concurrent.CompletionException: java.lang.NullPointerException: Cannot invoke "jdk.jpackage.test.TestInstance.workDir()" because the return value of "jdk.jpackage.test.TKit.currentTest()" is null > at java.base/java.util.concurrent.CompletableFuture.wrapInCompletionException(CompletableFuture.java:323) > at java.base/java.util.concurrent.CompletableFuture.encodeThrowable(CompletableFuture.java:359) > at java.base/java.util.concurrent.CompletableFuture.completeThrowable(CompletableFuture.java:364) > at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1828) > at java.base/java.util.concurrent.CompletableFuture$AsyncRun.exec(CompletableFuture.java:1817) > at java.base/java.util.concurrent.ForkJoinTask.doExec(ForkJoinTask.java:511) > at java.base/java.util.concurrent.ForkJoinPool$WorkQueue.topLevelExec(ForkJoinPool.java:1436) > at java.base/java.util.concurrent.ForkJoinPool.runWorker(ForkJoinPool.java:2011) > at java.base/java.util.concurrent.ForkJoinWorkerThread.run(ForkJoinWorkerThread.java:187) > Caused by: java.lang.NullPointerException: Cannot invoke "jdk.jpackage.test.TestInstance.workDir()" because the return value of "jdk.jpackage.test.TKit.currentTest()" is null > at jdk.jpackage.test.TKit.workDir(TKit.java:244) > at jdk.jpackage.test.JPackageCommand.setDefaultInputOutput(JPackageCommand.java:280) > at jdk.jpackage.test.JPackageCommand.helloAppImage(JPackageCommand.java:384) > at jdk.jpackage.test.JPackageCommand.helloAppImage(JPackageCommand.java:361) > at jdk.jpackage/jdk.jpackage.internal.cli.MainTest.lambda$testFailedCommandOutput$2(MainTest.java:123) > at jdk.jpackage.test.JPackageCommand.lambda$withToolProvider$0(JPackageCommand.java:805) > at java.base/java.util.concurrent.CompletableFuture$AsyncRun.run(CompletableFuture.java:1825) > ... 5 more Updated the review with a fix for the new `JPackageCommand.withToolProvider()`. The fix comes from the project based on this patch that revealed the issue. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28733#issuecomment-3726967171 From liach at openjdk.org Fri Jan 9 04:12:47 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Jan 2026 04:12:47 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:20:51 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. > > Thanks! > > Straight Backport . The test is passing in JDk26 CI. Looks good, but should we update the license year? ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29131#pullrequestreview-3642254285 From duke at openjdk.org Fri Jan 9 04:17:07 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 04:17:07 GMT Subject: Withdrawn: 8371048: ImageFileReader::open fails to check return value of osSupport::map_memory In-Reply-To: References: Message-ID: On Fri, 31 Oct 2025 14:00:38 GMT, Justin King wrote: > Check whether `osSupport::map_memory` actually succeeded in all compliation modes, instead of crashing shortly after in non-debug builds. Ideally we should fall back to just reading the entire file into memory manually or use seek+read, but this is good enough for now to avoid crashing. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28087 From duke at openjdk.org Fri Jan 9 05:12:34 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 05:12:34 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:20:51 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. > > Thanks! > > Straight Backport . The test is passing in JDk26 CI. @Shivangi-aa Your change (at version c6c6a7902732f28113c72048a3ae1ac45b0d8b70) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3727216212 From sshivang at openjdk.org Fri Jan 9 05:12:34 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Fri, 9 Jan 2026 05:12:34 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: <6TbMNkVEp_APvKL4rAdra4NkpbKfbJoAdmn46NdYkvM=.1fae12c4-15da-4eab-b931-1125985facac@github.com> On Fri, 9 Jan 2026 04:09:13 GMT, Chen Liang wrote: >> Hi all, >> >> This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. >> >> Thanks! >> >> Straight Backport . The test is passing in JDk26 CI. > > Looks good, but should we update the license year? @liach , it was updated in main MR so I retained the same. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3727209972 From jpai at openjdk.org Fri Jan 9 06:26:51 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 9 Jan 2026 06:26:51 GMT Subject: RFR: 8374644: Regression in GZIPInputStream performance after JDK-7036144 [v3] In-Reply-To: References: Message-ID: <2Pwobb6wT3gsVYacce1c3gZNGbI7oaxK3VfEN_yDRjw=.3fe7c19c-f1cc-4c2c-863c-5f5331ca80a7@github.com> On Thu, 8 Jan 2026 13:24:57 GMT, Jaikiran Pai wrote: >> Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? >> >> In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. >> >> Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. >> >> Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. >> >> Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. >> >> The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. >> >> The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. >> >> No n... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - merge latest from master branch > - add a comment explaining the "true" value being passed to readHeader > - review suggestion - assert not needed for now > - add a comment to clarify the short value being read for GZIP magic header > - use -1 to represent absence of a GZIP header, from readHeader() method > - 8374644: Regression in GZIPInputStream performance after JDK-7036144 Thank you Alan and Lance for the reviews. tier1, tier2 and tier3 testing completed without issues. I'll go ahead and integrate this now. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29092#issuecomment-3727396701 From jpai at openjdk.org Fri Jan 9 06:28:27 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Fri, 9 Jan 2026 06:28:27 GMT Subject: Integrated: 8374644: Regression in GZIPInputStream performance after JDK-7036144 In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 13:27:43 GMT, Jaikiran Pai wrote: > Can I please get a review of this change which proposes to address a performance regression in `java.util.zip.GZIPInputStream`? > > In JDK 23, we updated `GZIPInputStream` to no longer rely on `InputStream.available()` method when determining if a `InputStream` consists of additional (concatenated) GZIP streams. That was done in https://bugs.openjdk.org/browse/JDK-7036144. That change replaced the use of `InputStream.available()` with explicit call(s) to `InputStream.read()` to detect and read any additional concatenated GZIP stream header. > > Given how old that existing code in `GZIPInputStream` was, efforts were made to ensure that it wouldn't break existing applications, for the common use case. A release note too was added in an effort to highlight this change. > > Unfortunately, when reviewing and experimenting with this change I didn't realize that when we try to detect additional bytes in the stream which has already reached EOF, the `EOFException` that gets raised by this code could contribute to a performance degradation. The code does handle this exception appropriately, but it does mean that in the common case of a stream formed of just one GZIP stream, we would now end up constructing an `EOFException` in this code path. > > Construction of `Throwable` instances involves filling the stacktrace into that instance and is a relatively expensive operation. As a result, we ended up regressing the performance of this code path for the common use case of parsing a non-concatenated GZIP stream. > > The commit in this PR addresses this issue by introducing an alternate code path in the (private) `readHeader()` method to prevent an `EOFException` from being generated when the stream has already reached EOF and we are trying to determine if there's any additional concatenated GZIP stream header in the stream. This addresses the performance regression as well as lets us retain the changes that we had done in JDK-7036144 to prevent the usage of `InputStream.available()`. > > The reporter of this performance regression provided a JMH benchmark. I've run it against JDK 22 (the version that doesn't contain the JDK-7036144 change) , JDK 25 (latest JDK version which contains the JDK-7036144 change) and with this change proposed in this PR. I can see that with this change, the performance numbers improve and go back to the JDK 22 levels. I haven't included that JMH benchmark in this PR and am looking for inputs on whether we should include it. > > No new regression test has been in... This pull request has now been integrated. Changeset: a4fb07ee Author: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/a4fb07ee3e26c2f0ed3111c39c3a22167d292d04 Stats: 49 lines in 1 file changed: 41 ins; 1 del; 7 mod 8374644: Regression in GZIPInputStream performance after JDK-7036144 Reviewed-by: lancea, alanb ------------- PR: https://git.openjdk.org/jdk/pull/29092 From sshivang at openjdk.org Fri Jan 9 06:35:54 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Fri, 9 Jan 2026 06:35:54 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 04:09:13 GMT, Chen Liang wrote: >> Hi all, >> >> This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. >> >> Thanks! >> >> Straight Backport . The test is passing in JDk26 CI. > > Looks good, but should we update the license year? @liach Can you please sponsor this ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3727415941 From djelinski at openjdk.org Fri Jan 9 06:58:14 2026 From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=) Date: Fri, 9 Jan 2026 06:58:14 GMT Subject: [jdk26] RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> References: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> Message-ID: On Fri, 9 Jan 2026 03:28:32 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [136ac0d1](https://github.com/openjdk/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 6 Jan 2026 and was reviewed by Iris Clark, Joe Wang and Justin Lu. > > Thanks! > > > Straight Backport . The test is passing in JDK26 CI. Marked as reviewed by djelinski (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29132#pullrequestreview-3642636489 From duke at openjdk.org Fri Jan 9 07:06:53 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 07:06:53 GMT Subject: [jdk26] RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> References: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> Message-ID: On Fri, 9 Jan 2026 03:28:32 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [136ac0d1](https://github.com/openjdk/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 6 Jan 2026 and was reviewed by Iris Clark, Joe Wang and Justin Lu. > > Thanks! > > > Straight Backport . The test is passing in JDK26 CI. @Shivangi-aa Your change (at version bac68a1580e1e1a3584b2e6108f93c05172d31f6) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29132#issuecomment-3727484964 From shade at openjdk.org Fri Jan 9 07:22:39 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Fri, 9 Jan 2026 07:22:39 GMT Subject: [jdk26] RFR: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> References: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> Message-ID: <93ngjmdyG_BAuP0O7w1M94aIuYkBQ1uuMh23FftLqzw=.33f3ca05-8abf-45fd-95aa-04347a13e45e@github.com> On Fri, 9 Jan 2026 03:28:32 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [136ac0d1](https://github.com/openjdk/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 6 Jan 2026 and was reviewed by Iris Clark, Joe Wang and Justin Lu. > > Thanks! > > > Straight Backport . The test is passing in JDK26 CI. Test-only change, passes the RDP1 bar. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29132#issuecomment-3727520792 From sshivang at openjdk.org Fri Jan 9 07:24:22 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Fri, 9 Jan 2026 07:24:22 GMT Subject: [jdk26] Integrated: 8374433: java/util/Locale/PreserveTagCase.java does not run any tests In-Reply-To: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> References: <4O1VuuFA0uZGCkWjzMMfVASBY24BDxOTs0EAAEaQnAY=.ffe671f8-8317-4ad0-8ea8-3e38688b1c63@github.com> Message-ID: On Fri, 9 Jan 2026 03:28:32 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [136ac0d1](https://github.com/openjdk/jdk/commit/136ac0d10b92df8875f36c717e85595740b50ed2) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Naoto Sato on 6 Jan 2026 and was reviewed by Iris Clark, Joe Wang and Justin Lu. > > Thanks! > > > Straight Backport . The test is passing in JDK26 CI. This pull request has now been integrated. Changeset: 9ba5d6f8 Author: Shivangi Gupta Committer: Aleksey Shipilev URL: https://git.openjdk.org/jdk/commit/9ba5d6f8e7652754cfc91c76dc08ed1f10f2bc98 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8374433: java/util/Locale/PreserveTagCase.java does not run any tests Reviewed-by: djelinski Backport-of: 136ac0d10b92df8875f36c717e85595740b50ed2 ------------- PR: https://git.openjdk.org/jdk/pull/29132 From liach at openjdk.org Fri Jan 9 07:35:31 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 9 Jan 2026 07:35:31 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:20:51 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. > > Thanks! > > Straight Backport . The test is passing in JDk26 CI. Let's have a sustaining engineer to review before integration. Let's have a sustaining engineer to review before integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3727549358 PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3727549395 From alanb at openjdk.org Fri Jan 9 08:04:24 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 08:04:24 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v3] In-Reply-To: References: <0n3cejZUsIIyKQqkBh36ykAx9bhB_GApD7l14BCBjX0=.2fd420ac-ea86-41ef-a1f9-927b8032b670@github.com> Message-ID: On Thu, 8 Jan 2026 22:08:21 GMT, Larry Cable wrote: >> src/hotspot/share/services/attachListener.cpp line 308: >> >>> 306: } >>> 307: >>> 308: // Implementation of "properties -security" command. >> >> We don't need this: the attach API provides some basic commands, but most of the time we use the "jcmd" attach api command, which runs a DiagnosticCommand. That's how we attach and run VM.properties etc... >> >> This makes your life easier, we don't need serializeSecurityPropertiesToByteArray(), just updated DCmd and register_DCMDFactory lines. >> (you'll need to merge in the later repo changes and resolve the register_DCMDFactory changes) > > I agree, this functionality should probably be added to the existing VM.system_properties jcmd as an option (if necessary) Just some more history there. The reason the attachListener knows about the system properties command is because it dates back to JDK 6 when we introduced the attach mechanism and the Attach API. The Attach API defines VirtualMachine::getSystemProperties so both the tool and VM know about this "command". This all pre-dates jcmd and the diagnostic command framework that has been added since then. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29124#discussion_r2675223455 From sjohanss at openjdk.org Fri Jan 9 08:47:01 2026 From: sjohanss at openjdk.org (Stefan Johansson) Date: Fri, 9 Jan 2026 08:47:01 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v3] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:58:43 GMT, Leo Korinth wrote: >> This change moves almost all of the ConcurrentMark initialisation from its constructor to the method `G1ConcurrentMark::fully_initialize()`. Thus, creation time of the VM can be slightly improved by postponing creation of ConcurrentMark. Most time is saved postponing creation of statistics buffers and threads. >> >> It is not obvious that this is the best solution. I have earlier experimented with lazily allocating statistics buffers _only_. One could also initialise a little bit more eagerly (for example the concurrent mark thread) and maybe get a slightly cleaner change. However IMO it seems better to not have ConcurrentMark "half initiated" with a created mark thread, but un-initialised worker threads. >> >> This change is depending on the integration of https://bugs.openjdk.org/browse/JDK-8373253. >> >> I will be out for vacation, and will be back after new year (and will not answer questions during that time), but I thought I get the pull request out now so that you can have a look. > > Leo Korinth has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 564 commits: > > - Merge branch '8373253' into 8367993 > - Merge branch 'master' into _8373253 > - Merge branch 'master' into _8367993 > - 8366058: Outdated comment in WinCAPISeedGenerator > > Reviewed-by: mullan > - 8357258: x86: Improve receiver type profiling reliability > > Reviewed-by: kvn, vlivanov > - 8373704: Improve "SocketException: Protocol family unavailable" message > > Reviewed-by: lucy, jpai > - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently > > Reviewed-by: jiefu, jbhateja, erfang, qamai > - 8343809: Add requires tag to mark tests that are incompatible with exploded image > > Reviewed-by: alanb, dholmes > - 8374465: Spurious dot in documentation for JVMTI ClassLoad > > Reviewed-by: kbarrett > - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket > > Reviewed-by: djelinski, mpowers, ascarpino > - ... and 554 more: https://git.openjdk.org/jdk/compare/2aa8aa4b...28ccbb68 Thanks for looking into this Leo. Overall I think it looks good, just some small questions and suggestions. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 1637: > 1635: > 1636: bool G1CollectedHeap::concurrent_mark_is_terminating() const { > 1637: assert(_cm != nullptr, "thread must exist in order to check if mark is terminating"); I think it would make sense to add `&& _cm->is_fully_initialized()` to really make sure the thread has been created. src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2427: > 2425: if (_cm->is_fully_initialized()) { > 2426: tc->do_thread(_cm->cm_thread()); > 2427: } Since the _cm_thread is now in `G1ConcurrentMark` this should be handled in `G1ConcurrentMark::threads_do()` src/hotspot/share/gc/g1/g1CollectedHeap.cpp line 2549: > 2547: void G1CollectedHeap::start_concurrent_cycle(bool concurrent_operation_is_full_mark) { > 2548: assert(!_cm->in_progress(), "Can not start concurrent operation while in progress"); > 2549: assert(_cm->is_fully_initialized(), "sanity"); Not sure this sanity assert is needed `_cm->in_progress()` will always return `false` if not fully initialized, so the above assert will cover this. If we still want it, I think it should be moved above the `in_progress()` assert. src/hotspot/share/gc/g1/g1PeriodicGCTask.cpp line 46: > 44: return false; > 45: } > 46: Why is this needed? The initial young collection will make sure concurrent marking gets initialized, right? src/hotspot/share/gc/g1/g1Policy.cpp line 744: > 742: if (!_g1h->concurrent_mark()->is_fully_initialized()) { > 743: return false; > 744: } Is this needed? The `in_progress()` check below makes sure to only check the cm_thread when fully initialized. src/hotspot/share/gc/g1/g1YoungCollector.cpp line 1127: > 1125: > 1126: void G1YoungCollector::collect() { > 1127: _g1h->_cm->fully_initialize(); I think it would make more sense to do this in `G1CollectedHeap::do_collection_pause_at_safepoint()`. There we check if we should start concurrent mark, so maybe the initialization could be done only if we are about to start concurrent mark. If we can do the initialization after the actual young collection, then we could maybe even move the initialization into `G1CollectedHeap::start_concurrent_cycle(...)` ------------- Changes requested by sjohanss (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28723#pullrequestreview-3639436840 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2672366755 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675276733 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675291347 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675313622 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675328503 PR Review Comment: https://git.openjdk.org/jdk/pull/28723#discussion_r2675249630 From alanb at openjdk.org Fri Jan 9 08:53:59 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 08:53:59 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v4] In-Reply-To: References: Message-ID: <2vYchq-CkYIofednbT3mCis7UFBKeajU134sdoyssRo=.015da7ff-63ba-4105-8054-1991c339d742@github.com> On Thu, 8 Jan 2026 21:27:18 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits: > > - merge > - rm unused code > - Merge remote-tracking branch 'origin/master' into sec_props2 > - static helper method for both jcmd calls > - missing ) > - working with single arg > - updates > - update args > - two args -not yet tested > - initial patch > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026. As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3727870283 From kfarrell at openjdk.org Fri Jan 9 09:54:08 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 09:54:08 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: References: Message-ID: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: hide command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/6675081d..ee7d4707 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=03-04 Stats: 65 lines in 1 file changed: 25 ins; 10 del; 30 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From kfarrell at openjdk.org Fri Jan 9 11:34:44 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 11:34:44 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> References: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 09:54:08 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > hide command > Security properties are a somewhat niche set of non-system properties for the security/crypto area. They can't be set on the command line, need to use -Djava.security.properties== to locate a properties file to augment the security properties defined in java.security. So very confusing to developers and maybe it's time to think about whether security properties make sense in 2026. > Should this PR be put on hold until such a disccusion takes place or maybe that would be something a little further down the line? > As regards the proposal then my initial reaction is to keep it separate, meaning a security_properties rather than properties command. My initial patch added a seperate command `VM.security_properties` but I merged the two following a suggestion reduce clutter in the the `jcmd help` output. Happy to revert to a seperate command if we proceed with this and there is a preference to do so. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3728531839 From stefank at openjdk.org Fri Jan 9 12:09:22 2026 From: stefank at openjdk.org (Stefan Karlsson) Date: Fri, 9 Jan 2026 12:09:22 GMT Subject: RFR: 8367993: G1: Speed up ConcurrentMark initialization [v2] In-Reply-To: References: Message-ID: On Wed, 7 Jan 2026 12:33:41 GMT, Leo Korinth wrote: >> Leo Korinth has updated the pull request incrementally with 561 additional commits since the last revision: >> >> - Merge branch 'master' into _8367993 >> - 8366058: Outdated comment in WinCAPISeedGenerator >> >> Reviewed-by: mullan >> - 8357258: x86: Improve receiver type profiling reliability >> >> Reviewed-by: kvn, vlivanov >> - 8373704: Improve "SocketException: Protocol family unavailable" message >> >> Reviewed-by: lucy, jpai >> - 8373722: [TESTBUG] compiler/vectorapi/TestVectorOperationsWithPartialSize.java fails intermittently >> >> Reviewed-by: jiefu, jbhateja, erfang, qamai >> - 8343809: Add requires tag to mark tests that are incompatible with exploded image >> >> Reviewed-by: alanb, dholmes >> - 8374465: Spurious dot in documentation for JVMTI ClassLoad >> >> Reviewed-by: kbarrett >> - 8374317: Change GCM IV size to 12 bytes when encrypting/decrypting TLS session ticket >> >> Reviewed-by: djelinski, mpowers, ascarpino >> - 8374444: Fix simple -Wzero-as-null-pointer-constant warnings >> >> Reviewed-by: aboldtch >> - 8373847: Test javax/swing/JMenuItem/MenuItemTest/bug6197830.java failed because The test case automatically fails when clicking any items in the ?Nothing? menu in all four windows (Left-to-right)-Menu Item Test and (Right-to-left)-Menu Item Test >> >> Reviewed-by: serb, aivanov, dnguyen >> - ... and 551 more: https://git.openjdk.org/jdk/compare/b907b295...0ece3767 > > I will redo the merge, I have done something strange. @lkorinth Something went wrong with your merge and now there's a bunch of unrelated labels, which results in updates being sent to misc mailing lists that has no interest in this PR. Could you remove all those labels? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28723#issuecomment-3728642315 From duke at openjdk.org Fri Jan 9 12:10:59 2026 From: duke at openjdk.org (Eunbin Son) Date: Fri, 9 Jan 2026 12:10:59 GMT Subject: RFR: 8374342: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 16:51:57 GMT, Michael McMahon wrote: >> ### 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 > > You need to prefix the PR title with the bugid as it was before. ie. > > 8374342: Remove incorrect @throws NoSuchFileException from test/lib/jdk/test/lib/util/FileUtils.javaFileUtils.java @Michael-Mc-Mahon Thank you. I restored the PR title. /integrate ------------- PR Comment: https://git.openjdk.org/jdk/pull/28985#issuecomment-3728641789 From pminborg at openjdk.org Fri Jan 9 12:35:28 2026 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 Jan 2026 12:35:28 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: > This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. > > On multiple platforms, tested and passed: > - [x] tier1 > - [x] tier2 > - [x] tier3 > > Not tested: > - [ ] tier4 > - [ ] tier5 > - [ ] tier6 Per Minborg has updated the pull request incrementally with one additional commit since the last revision: Add a real test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29084/files - new: https://git.openjdk.org/jdk/pull/29084/files/cdb2a594..898e1e41 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=01-02 Stats: 81 lines in 2 files changed: 32 ins; 47 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From pminborg at openjdk.org Fri Jan 9 13:13:13 2026 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 9 Jan 2026 13:13:13 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:35:28 GMT, Per Minborg wrote: >> This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. >> >> On multiple platforms, tested and passed: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> >> Not tested: >> - [ ] tier4 >> - [ ] tier5 >> - [ ] tier6 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a real test test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GeneratedInternedString.java line 48: > 46: .runAOTWorkflow(); > 47: > 48: SimpleCDSAppTester.of("GeneratedInternedString") Should this be a separate test, or is it ok to tag along on the existing one? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2676146498 From fguallini at openjdk.org Fri Jan 9 14:30:23 2026 From: fguallini at openjdk.org (Fernando Guallini) Date: Fri, 9 Jan 2026 14:30:23 GMT Subject: RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: <9gNlx3cg9L8n__rPe5tqAqC4tduxI6x8ISvXds_oOQk=.2ba30837-6394-4e0f-b992-58564a98975e@github.com> References: <9gNlx3cg9L8n__rPe5tqAqC4tduxI6x8ISvXds_oOQk=.2ba30837-6394-4e0f-b992-58564a98975e@github.com> Message-ID: On Thu, 8 Jan 2026 17:22:25 GMT, Alexey Semenyuk wrote: > @fguallini can you think of any inputs to stress test/break the new regexp? LGTM, I can't think of any other cases that would cause an issue ------------- PR Comment: https://git.openjdk.org/jdk/pull/29104#issuecomment-3729131845 From alanb at openjdk.org Fri Jan 9 14:33:22 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 9 Jan 2026 14:33:22 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v5] In-Reply-To: References: <3qlmxsr_9xjvyzplwqR6Q0Z5smdoGqVfQ7wsCiafad0=.daf5745a-4c15-420a-b76a-82a8543c2fdb@github.com> Message-ID: On Fri, 9 Jan 2026 11:31:17 GMT, Kieran Farrell wrote: > My initial patch added a seperate command `VM.security_properties` Maybe revert to that as it's a better starting point to discuss. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3729139127 From rriggs at openjdk.org Fri Jan 9 14:33:22 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 14:33:22 GMT Subject: RFR: 8374819: Some I/O streams left unclosed [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:21:12 GMT, Alexey Semenyuk wrote: >> - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. >> - Add missing try-with-resources for `Class.getResourceAsStream()` calls. > > Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: > > - AppImageInfoPListFile: simplify > - Remove redundant "throws javax.xml.parsers.ParserConfigurationException" from PListReader#PListReader(byte[]) signature > - AppImageFile: add a comment explaining why we use javax.xml.parsers.DocumentBuilder#parse(java.io.InputStream) and not javax.xml.parsers.DocumentBuilder#parse(java.io.File), even the later is more suitable for reading XML from a file Can the title and description mention 'jpackage', please. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29007#issuecomment-3729148127 From vklang at openjdk.org Fri Jan 9 14:36:59 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 Jan 2026 14:36:59 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 18:52:32 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with two additional commits since the last revision: > > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2281: > 2279: if (U.compareAndSetReference(a, k, t, null)) { > 2280: q.base = b + 1; > 2281: U.putIntVolatile(w, WorkQueue.SOURCE, j); @DougLea Since WorkQueue::base is volatile with this PR, it _might_ be worth performing a plain or opaque write to q.base followed by the volatile write to WorkQueue.SOURCE? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2676415903 From vklang at openjdk.org Fri Jan 9 14:47:13 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 9 Jan 2026 14:47:13 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 18:52:32 GMT, Doug Lea
wrote: >> Changes signal filtering to avoid possible starvation > > Doug Lea has updated the pull request incrementally with two additional commits since the last revision: > > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2326: > 2324: scan: for (int l = n; l > 0; --l, ++r) { > 2325: int j; WorkQueue q; > 2326: if ((q = qs[j = r & SMASK & (n - 1)]) != null) { @DougLea `j` is never used. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2329: > 2327: for (;;) { > 2328: ForkJoinTask t; ForkJoinTask[] a; > 2329: int b, cap, nb; long k; @DougLea `nb` is never used. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3083: > 3081: static ForkJoinPool asyncCommonPool() { > 3082: ForkJoinPool cp; int p; > 3083: if ((p = (cp = common).parallelism) == 0) @DougLea `p` is never used. src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3859: > 3857: * granularities.The returned count does not include scheduled > 3858: * tasks that are not yet ready to execute, which are reported > 3859: * separately by method {@link getDelayedTaskCount}. Suggestion: * separately by method {@link #getDelayedTaskCount}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2676434850 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2676435633 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2676441709 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2676448152 From asemenyuk at openjdk.org Fri Jan 9 14:52:32 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 14:52:32 GMT Subject: Integrated: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: On Thu, 8 Jan 2026 04:44:55 GMT, Alexey Semenyuk wrote: > Replace reluctant quantifier `*?` with the possessive alternative (`*+`) and get rid of back-references from the regexp tokenizing a value of the "--arguments" option into a string array to fix the catastrophic backtracking resulting in a stack overflow. > > Old regexp: `(?:(?:(["'])(?:\\\1|.)*?(?:\1|$))|(?:\["'\s]|[^\s]))++` > > New regexp `(?:(?:(?:'(?:\'|[^'])*+(?:'|$))|(?:"(?:\"|[^"])*+(?:"|$)))|(?:\["'\s]|\S))++` > > Add test cases that pass both the old and the new variants of the regexp, except for the last test case that causes a stack overflow with the old regexp. > > The initial intention was to replace the regexp with the tokenizer function. It was abandoned in favor of reworking the regexp to minimize the risk of regressions. This pull request has now been integrated. Changeset: 8737a8ca Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/8737a8ca73952d60129e7fc2f7e17eea3b800af7 Stats: 37 lines in 2 files changed: 31 ins; 0 del; 6 mod 8373448: jpackage: StackOverflowError when processing a very long argument Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29104 From djgredler at gmail.com Fri Jan 9 15:22:18 2026 From: djgredler at gmail.com (Daniel Gredler) Date: Fri, 9 Jan 2026 16:22:18 +0100 Subject: Make ByteArrayOutputStream.ensureCapacity(int) protected? In-Reply-To: References: <77bacfdd-3e7e-450d-b615-e9c3002f5028@oracle.com> <38a16a34-b335-467b-96a1-79f3674d350b@oracle.com> <96560e31-a038-4277-bcc5-cfae01053507@oracle.com> <5943f17e-45e2-44ae-bea5-2b6601cdfb36@oracle.com> Message-ID: Thanks guys for the feedback. > BTW, P4 is a better priority for this useful addition, P5 is pretty much ignored or trivial and not worth it. I've updated to P4. I've been erring on the side of caution when assigning priority to nice-to-have JBS issues which I create :-) I'll go ahead and create the PR in the next day or two, as well. Take care, Daniel On Thu, Jan 8, 2026 at 11:33?PM Joseph D. Darcy wrote: > From the CSR FAQ > (https://wiki.openjdk.org/spaces/csr/pages/32342047/CSR+FAQs): > > > Q: If my change needs a CSR review and a code review, which should I > > do first? > > A: To take a common case of a Java API change, there is some overlap > > between the factors considered in a general code review and the > > factors considered by the CSR when reviewing the specification and > > compatibility impact. (CSR members often participate in code reviews > > in addition to their reviews in CSR roles.) An engineer may choose to > > run the CSR process and code review in parallel, but feedback from > > either channel may be received which requires updates to the proposal > > in the other channel. If an engineer chooses to sequence code review > > and CSR review, to minimize latency the process expected to provide > > more feedback should be run first. > > > HTH, > > -Joe > > On 1/8/2026 1:19 PM, Roger Riggs wrote: > > Hi Daniel, > > > > CSR's get few reviewers than PR's. > > > > A broader review in the PR can improve the prose and get comments on > > additional use cases. > > For myself, I do them in parallel, putting the initial CSR in proposed > > state to get early feedback from the CSR review. > > Comments on the PR accumulate and are addressed in the PR and when > > that settles down, update the PR and finalize. > > > > In the CSR, the Compatibility Risk description highlights a typical > > more serious risk, that of superseding an existing method in an > > implementation and possibly changing or being in conflict with its > > semantics. As a protected method, its potential to be in conflict with > > existing implementations is reduced somewhat. > > > > The diff in the CSR should focus on the specification change, not the > > implementation changes unless they affect visible behavior. > > (Generally, avoid irrelevant information in the CSR). > > > > BTW, P4 is a better priority for this useful addition, P5 is pretty > > much ignored or trivial and not worth it. > > > > Thanks for the followup, Roger > > > > > > On 1/7/26 4:07 PM, Daniel Gredler wrote: > >> Hi Roger, > >> > >> I've created the CSR here: https://bugs.openjdk.org/browse/JDK-8374739 > >> > >> Alan also provided some feedback on the original issue here: > >> https://bugs.openjdk.org/browse/JDK-8374610 > >> > >> I was going to wait to create the PR until the CSR has been approved, > >> if that's OK? > >> > >> Take care, > >> > >> Daniel > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Fri Jan 9 15:43:56 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 15:43:56 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: <75wy2ekhG3uunkk0gmFg8eErEfSDFzy_nStTPwtx9kk=.ad75de54-aa77-4e7b-ac39-9af94d04c012@github.com> On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line The jimage versions number are only significant within the tool and implementation. If the version numbers were synchronized to the JDK version, (as we do with class file versions, CDS archives, etc.) it would be straight-forward for the message to be specific about what version of jimage is needed for the jimage. ------------- PR Review: https://git.openjdk.org/jdk/pull/28456#pullrequestreview-3644468724 From rriggs at openjdk.org Fri Jan 9 17:57:00 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 17:57:00 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available Message-ID: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> On Linux and Mac, when a process is started, pipes are created to communicate with the child. In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) Converted PipelineLeaksFD test to JUnit. ------------- Commit messages: - 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available Changes: https://git.openjdk.org/jdk/pull/29143/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291986 Stats: 180 lines in 3 files changed: 132 ins; 2 del; 46 mod Patch: https://git.openjdk.org/jdk/pull/29143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29143/head:pull/29143 PR: https://git.openjdk.org/jdk/pull/29143 From darcy at openjdk.org Fri Jan 9 18:19:26 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 Jan 2026 18:19:26 GMT Subject: RFR: 8373196: Core reflection overview update for access check and conversions In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 23:36:22 GMT, Chen Liang wrote: > 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. Overall, I think this PR represents a good direction for the core reflection spec to move in and the package-level discussion just needs some refinement. src/java.base/share/classes/java/lang/reflect/package-info.java line 47: > 45: * > 46: *

Access Control

> 47: * An accessor of a reflected object perform access control against the caller Typo: perform -> performs src/java.base/share/classes/java/lang/reflect/package-info.java line 56: > 54: * the use happened on the member in A, while in the Java Language and JVM, > 55: * the use can happen on an inherited member in another class or interface, and > 56: * access control proceeds differently. (JLS {@jls 6.6.1}, JVMS {@jvms 5.4.4}) I suggest making the discussion here more explicit, such as by added a concrete B subclasses to the text, and discussing briefly the distinctions between method access i the context of B vs A. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28685#issuecomment-3730049539 PR Review Comment: https://git.openjdk.org/jdk/pull/28685#discussion_r2677149838 PR Review Comment: https://git.openjdk.org/jdk/pull/28685#discussion_r2677155989 From kfarrell at openjdk.org Fri Jan 9 18:38:53 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Fri, 9 Jan 2026 18:38:53 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: References: Message-ID: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: sperate VM.sec_props command ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/ee7d4707..db9e0e97 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=04-05 Stats: 63 lines in 3 files changed: 0 ins; 26 del; 37 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From darcy at openjdk.org Fri Jan 9 19:37:22 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 9 Jan 2026 19:37:22 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 Perhaps as part of a larger doc refresh, there would be a section at the top of Class comparing and contrasting this set of related methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28684#issuecomment-3730307487 From ascarpino at openjdk.org Fri Jan 9 20:15:12 2026 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 9 Jan 2026 20:15:12 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Mon, 5 Jan 2026 17:20:29 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > must have username; more comments Marked as reviewed by ascarpino (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3645433959 From ascarpino at openjdk.org Fri Jan 9 20:15:15 2026 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Fri, 9 Jan 2026 20:15:15 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v7] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1gqGEKeFqHqnWt4UPzS5iXdMQ0oP4BYw6LtvGIaVbkg=.1a20173c-9d85-4539-a3c6-59832656a738@github.com> Message-ID: On Wed, 7 Jan 2026 21:47:41 GMT, Weijun Wang wrote: >> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 88: >> >>> 86: = (ValueLayout) LINKER.canonicalLayouts().get("size_t"); >>> 87: >>> 88: private static final StructLayout capturedStateLayout = Linker.Option.captureStateLayout(); >> >> Should the variables below be capitalized because they are `static final`? > > Per asked the same above. I'm not exactly sure if all of them should be capitalized. I'm willing to choose either. I'm thinking the `static final` convention applies for all of them, but if someone says different because they are FFM related, I'm fine with not. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2677493814 From naoto at openjdk.org Fri Jan 9 20:56:30 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 9 Jan 2026 20:56:30 GMT Subject: RFR: 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds Message-ID: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> Clarifying the javadoc for `ZonedDateTime#toString()` about the zero seconds/nanoseconds omission. A corresponding CSR has also been drafted. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29146/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29146&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374905 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29146.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29146/head:pull/29146 PR: https://git.openjdk.org/jdk/pull/29146 From duke at openjdk.org Fri Jan 9 21:24:54 2026 From: duke at openjdk.org (duke) Date: Fri, 9 Jan 2026 21:24:54 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 @trevorkbond Your change (at version 44612c5f0a0dfa9548d4bf8d33ea68e53811f4ca) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28729#issuecomment-3730609687 From rriggs at openjdk.org Fri Jan 9 21:25:56 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 9 Jan 2026 21:25:56 GMT Subject: RFR: 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds In-Reply-To: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> References: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> Message-ID: On Fri, 9 Jan 2026 20:48:39 GMT, Naoto Sato wrote: > Clarifying the javadoc for `ZonedDateTime#toString()` about the zero seconds/nanoseconds omission. A corresponding CSR has also been drafted. Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29146#pullrequestreview-3645604905 From bpb at openjdk.org Fri Jan 9 21:25:57 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Fri, 9 Jan 2026 21:25:57 GMT Subject: RFR: 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds In-Reply-To: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> References: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> Message-ID: On Fri, 9 Jan 2026 20:48:39 GMT, Naoto Sato wrote: > Clarifying the javadoc for `ZonedDateTime#toString()` about the zero seconds/nanoseconds omission. A corresponding CSR has also been drafted. Looks fine to me. ------------- Marked as reviewed by bpb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29146#pullrequestreview-3645607799 From almatvee at openjdk.org Fri Jan 9 22:13:35 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 22:13:35 GMT Subject: RFR: 8374219: Fix issues in jpackage's Executor class [v5] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:48:24 GMT, Alexey Semenyuk wrote: >> - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). >> - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. >> - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. >> - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. >> >> Supplementary changes: >> - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > JPackageCommand: add a comment to the new withToolProvider() Latest changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28733#pullrequestreview-3645717031 From asemenyuk at openjdk.org Fri Jan 9 22:23:50 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 22:23:50 GMT Subject: Integrated: 8374219: Fix issues in jpackage's Executor class In-Reply-To: References: Message-ID: On Wed, 10 Dec 2025 05:03:47 GMT, Alexey Semenyuk wrote: > - Move code shared between jpackage's Executor and jpackage's test lib Executor into `jdk.jpackage.internal.util.CommandOutputControl` class using the latter one as the baseline for the new class; [CommandOutputControl class javadoc](https://alexeysemenyukoracle.github.io/jpackage-javadoc/jdk.jpackage/jdk/jpackage/internal/util/CommandOutputControl.html). > - Place "execute with retries" logic into `jdk.jpackage.internal.util.RetryExecutor` class and use it from both jpackage and jpackage's test lib. Use `jdk.jpackage.internal.RetryExecutor` class as the baseline. > - Add `ObjectFactory`, `ExecutorFactory`, and `RetryExecutorFactory` interfaces to the "jdk.jpackage.internal" package. They enable the use of command mocks with jpackage. > - Add `jdk.jpackage.test.mock` package. It facilitates creating command mocks. Use it to test LibProvidersLookup, LinuxSystemEnvironment, LinuxPackageArch, MacDmgSystemEnvironment, and MacDmgPackager classes. > > Supplementary changes: > - Make `jdk.jpackage.internal.SystemEnvironment` and all implementing classes package private This pull request has now been integrated. Changeset: 663a0833 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/663a08331a83c852622b8b11900f12b0dc3dbe82 Stats: 10678 lines in 88 files changed: 8624 ins; 1643 del; 411 mod 8374219: Fix issues in jpackage's Executor class Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/28733 From missa at openjdk.org Fri Jan 9 22:59:16 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 9 Jan 2026 22:59:16 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/38735c37..cd7acad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=02-03 Stats: 23 lines in 2 files changed: 9 ins; 11 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From almatvee at openjdk.org Fri Jan 9 23:18:44 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 9 Jan 2026 23:18:44 GMT Subject: RFR: 8374819: jpackage and jpackage tests leave some I/O streams unclosed [v2] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:21:12 GMT, Alexey Semenyuk wrote: >> - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. >> - Add missing try-with-resources for `Class.getResourceAsStream()` calls. > > Alexey Semenyuk has updated the pull request incrementally with three additional commits since the last revision: > > - AppImageInfoPListFile: simplify > - Remove redundant "throws javax.xml.parsers.ParserConfigurationException" from PListReader#PListReader(byte[]) signature > - AppImageFile: add a comment explaining why we use javax.xml.parsers.DocumentBuilder#parse(java.io.InputStream) and not javax.xml.parsers.DocumentBuilder#parse(java.io.File), even the later is more suitable for reading XML from a file Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29007#pullrequestreview-3645889188 From asemenyuk at openjdk.org Fri Jan 9 23:39:54 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 9 Jan 2026 23:39:54 GMT Subject: Integrated: 8374819: jpackage and jpackage tests leave some I/O streams unclosed In-Reply-To: References: Message-ID: On Mon, 29 Dec 2025 23:29:11 GMT, Alexey Semenyuk wrote: > - Replace `Files.newInputStream(path)` in chain method calls with either `new ByteArrayInputStream(Files.readAllBytes(path))` or `path.toFile()` if there is an alternative method taking a `File` instance instead of an `InputStream` and if appropriate. > - Add missing try-with-resources for `Class.getResourceAsStream()` calls. This pull request has now been integrated. Changeset: 74faf033 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/74faf033127ab3a5e28be75b91e662c589f81084 Stats: 45 lines in 7 files changed: 20 ins; 8 del; 17 mod 8374819: jpackage and jpackage tests leave some I/O streams unclosed Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29007 From brian.burkhalter at oracle.com Sat Jan 10 03:05:56 2026 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Sat, 10 Jan 2026 03:05:56 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> Message-ID: <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> Thanks for the corroboration. On Jan 8, 2026, at 1:50?PM, David Alayachew wrote: Thanks for reviving this. I am perfectly happy with the idea of deprecating the Path.{start,ends}With(String), and then only add the file extension method. Originally, I didn't know that new method was on the table, so I suggested a rename. But the file extension api feels like the superior solution. 10 times out of 10, if I am calling endsWith, the only time I am not looking for "whole" path elements is when I am looking for a file extension. In every other instance, the api does exactly what I expect and want. And plus, something like looking for a file extension is better off being explicit. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Sat Jan 10 06:05:32 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 10 Jan 2026 06:05:32 GMT Subject: RFR: 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds Message-ID: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> Replace lambda with the enum to prevent runtime/cds/ServiceLoaderTest.java test failure ------------- Commit messages: - 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds Changes: https://git.openjdk.org/jdk/pull/29151/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29151&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374923 Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29151.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29151/head:pull/29151 PR: https://git.openjdk.org/jdk/pull/29151 From asemenyuk at openjdk.org Sat Jan 10 06:05:32 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 10 Jan 2026 06:05:32 GMT Subject: RFR: 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds In-Reply-To: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> References: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> Message-ID: On Sat, 10 Jan 2026 05:59:23 GMT, Alexey Semenyuk wrote: > Replace lambda with the enum to prevent runtime/cds/ServiceLoaderTest.java test failure @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29151#issuecomment-3731875266 From almatvee at openjdk.org Sat Jan 10 06:29:47 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 10 Jan 2026 06:29:47 GMT Subject: RFR: 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds In-Reply-To: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> References: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> Message-ID: On Sat, 10 Jan 2026 05:59:23 GMT, Alexey Semenyuk wrote: > Replace lambda with the enum to prevent runtime/cds/ServiceLoaderTest.java test failure Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29151#pullrequestreview-3646478625 From asemenyuk at openjdk.org Sat Jan 10 15:08:30 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Sat, 10 Jan 2026 15:08:30 GMT Subject: Integrated: 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds In-Reply-To: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> References: <4o-RrErGzxGCg8d5nJfa3c8-sHUT5aHypeHRUQnR-js=.4816a10a-9723-4087-8bf9-127d9c37410f@github.com> Message-ID: On Sat, 10 Jan 2026 05:59:23 GMT, Alexey Semenyuk wrote: > Replace lambda with the enum to prevent runtime/cds/ServiceLoaderTest.java test failure This pull request has now been integrated. Changeset: 659b53fe Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/659b53fe33eaa531bca1951a26f357b51902311e Stats: 11 lines in 1 file changed: 5 ins; 0 del; 6 mod 8374923: runtime/cds/ServiceLoaderTest.java fails with mismatch between cds and non-cds Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29151 From cushon at openjdk.org Sat Jan 10 18:51:06 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sat, 10 Jan 2026 18:51:06 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v16] 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 21 additional commits since the last revision: - Merge branch 'master' into JDK-8369564 - 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 - ... and 11 more: https://git.openjdk.org/jdk/compare/18122b0c...e2cc6f0b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28043/files - new: https://git.openjdk.org/jdk/pull/28043/files/229ffa01..e2cc6f0b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=14-15 Stats: 50139 lines in 3134 files changed: 24190 ins; 7881 del; 18068 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 davidalayachew at gmail.com Sat Jan 10 23:19:13 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Sat, 10 Jan 2026 18:19:13 -0500 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> Message-ID: Of course. I see lots of approvals and not really any dissenters. Are we waiting for more responses? Or is there anything we can do to kick start this? On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter wrote: > Thanks for the corroboration. > > On Jan 8, 2026, at 1:50?PM, David Alayachew > wrote: > > Thanks for reviving this. > > I am perfectly happy with the idea of deprecating the > Path.{start,ends}With(String), and then only add the file extension method. > Originally, I didn't know that new method was on the table, so I suggested > a rename. But the file extension api feels like the superior solution. > > 10 times out of 10, if I am calling endsWith, the only time I am not > looking for "whole" path elements is when I am looking for a file > extension. In every other instance, the api does exactly what I expect and > want. And plus, something like looking for a file extension is better off > being explicit. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hgreule at openjdk.org Sun Jan 11 07:44:35 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Sun, 11 Jan 2026 07:44:35 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v16] In-Reply-To: References: Message-ID: On Sat, 10 Jan 2026 18:51:06 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 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 JDK-8369564 > - 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 > - ... and 11 more: https://git.openjdk.org/jdk/compare/87751392...e2cc6f0b src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1351: > 1349: * largest string supported by the platform > 1350: * @throws IndexOutOfBoundsException if {@code offset < 0} > 1351: * @throws IndexOutOfBoundsException if {@code offset > byteSize() - length} Suggestion: * @throws IndexOutOfBoundsException if {@code offset > byteSize() - byteLength} I assume this was missed? src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1356: > 1354: * @throws WrongThreadException if this method is called from a thread {@code T}, > 1355: * such that {@code isAccessibleBy(T) == false} > 1356: * @throws IllegalArgumentException if {@code length < 0} Suggestion: * @throws IllegalArgumentException if {@code byteLength < 0} ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2679311350 PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2679311392 From cushon at openjdk.org Sun Jan 11 14:03:02 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sun, 11 Jan 2026 14:03:02 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] 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 incrementally with one additional commit since the last revision: Apply suggestions from code review Co-authored-by: Hannes Greule ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28043/files - new: https://git.openjdk.org/jdk/pull/28043/files/e2cc6f0b..50aaf63b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28043&range=15-16 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Sun Jan 11 14:09:18 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sun, 11 Jan 2026 14:09:18 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v16] In-Reply-To: References: Message-ID: <8m4LUW-sNqOOPD255uBh-pnd0FGDXyXJ1_ck3jC64v8=.2e421f65-dd0c-43e5-82d5-91d8043869ec@github.com> On Sun, 11 Jan 2026 07:39:16 GMT, Hannes Greule wrote: >> 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 21 additional commits since the last revision: >> >> - Merge branch 'master' into JDK-8369564 >> - 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 >> - ... and 11 more: https://git.openjdk.org/jdk/compare/d3fa70cc...e2cc6f0b > > src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 1351: > >> 1349: * largest string supported by the platform >> 1350: * @throws IndexOutOfBoundsException if {@code offset < 0} >> 1351: * @throws IndexOutOfBoundsException if {@code offset > byteSize() - length} > > Suggestion: > > * @throws IndexOutOfBoundsException if {@code offset > byteSize() - byteLength} > > I assume this was missed? Thanks, fixed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28043#discussion_r2679577283 From cushon at openjdk.org Sun Jan 11 14:29:50 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Sun, 11 Jan 2026 14:29:50 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 14:03:02 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 >> FromJavaStringTest.segment_copyStringBytes 5 avgt 30 4.877 ? 0.508 ns/op >> FromJavaStringTest.segment_copyStringBytes 20 avgt 30 5.090 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringBytes 100 avgt 30 9.343 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringBytes 200 avgt 30 12.920 ? 2.800 ns/op >> FromJavaStringTest.segment_copyStringBytes 451 avgt 30 25.476 ? 0.388 ns/op >> FromJavaStringTest.segment_copyStringRaw 5 avgt 30 3.544 ? 0.915 ns/op >> FromJavaStringTest.segment_copyStringRaw 20 avgt 30 3.417 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringRaw 100 avgt 30 5.901 ? 0.054 ns/op >> FromJavaStringTest.segment_copyStringRaw 200 avgt 30 7.257 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringRaw 451 avgt 30 11.840 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 5 avgt 30 6.192 ? 0.144 ns/op >> FromJavaStringTest.segment_setString 20 avgt 30 6.383 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 100 avgt 30 8.920 ? 0.161 ns/op >> FromJavaStringTest.segment_setString 200 avgt 30 10.973 ? 1.614 ns/op >> FromJavaStringTest.segment_setString 451 avgt 30 19.028 ? 0.247 ns/op >> >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ToJavaStringTest.jni_re... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Hannes Greule The CSR has been approved. I have merged in the latest changes from master, and also updated two javadoc references to `length` to `byteLength` noticed by @SirYwell. I think this is ready for re-review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3734637308 From attila at openjdk.org Sun Jan 11 14:51:52 2026 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 11 Jan 2026 14:51:52 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" At least [this one comment](https://github.com/openjdk/jdk/pull/28869#issuecomment-3669945336) but possibly more of them are almost certainly LLM-generated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28869#issuecomment-3734668245 From attila at openjdk.org Sun Jan 11 15:04:00 2026 From: attila at openjdk.org (Attila Szegedi) Date: Sun, 11 Jan 2026 15:04:00 GMT Subject: RFR: 8373196: Core reflection overview update for access check and conversions In-Reply-To: References: Message-ID: On Fri, 5 Dec 2025 23:36:22 GMT, Chen Liang wrote: > 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. src/java.base/share/classes/java/lang/reflect/package-info.java line 53: > 51: * member inherited by another reference type from A with equivalent reflective > 52: * objects, with A as the {@linkplain Member#getDeclaringClass() declaring class > 53: * or interface}. Therefore, access checks of such a reflected object assumes Suggestion: * or interface}. Therefore, access checks of such a reflected object assume ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28685#discussion_r2679667347 From dl at openjdk.org Sun Jan 11 17:11:38 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 11 Jan 2026 17:11:38 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v23] 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 33 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - reunify push; improve contention vs activation vs park balance - Undo unrelated change - Re-introduce acquiring array reads; re-arrange to rely on volatile base index - Change signalWork fencing; in-progress activation changes - Merge branch 'openjdk:master' into JDK-8373118 - Split external push - Undo/redo ordering changes - Strengthen some orderings - Merge branch 'openjdk:master' into JDK-8373118 - ... and 23 more: https://git.openjdk.org/jdk/compare/efb906cb...f42d2475 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/d2b6c7c0..f42d2475 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=21-22 Stats: 17279 lines in 337 files changed: 12042 ins; 3984 del; 1253 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 Sun Jan 11 17:18:33 2026 From: duke at openjdk.org (Igor Rudenko) Date: Sun, 11 Jan 2026 17:18:33 GMT Subject: RFR: 8297053: Specify new default byte alignment for native allocators Message-ID: Use the largest known value for default allocation alignment so that align value that less than 16 (typical align for modern systems) turns to 16 ------------- Commit messages: - JDK-8297053: Specify new default byte alignment for native allocators Changes: https://git.openjdk.org/jdk/pull/29156/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29156&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8297053 Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29156.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29156/head:pull/29156 PR: https://git.openjdk.org/jdk/pull/29156 From dl at openjdk.org Sun Jan 11 17:23:36 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 11 Jan 2026 17:23:36 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v22] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 8 Jan 2026 23:38:30 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with two additional commits since the last revision: >> >> - Undo unrelated change >> - Re-introduce acquiring array reads; re-arrange to rely on volatile base index > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1261: > >> 1259: if (U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null && >> 1260: pool != null) >> 1261: pool.signalWork(this, s); // may have appeared empty > > @DougLea I really like how push turned out here, it's arguably one of the most elegant versions of this method. Too bad I had to re-uglify it a little! > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2063: > >> 2061: int idle = IDLE, phase; >> 2062: if ((runState & STOP) == 0L && w != null && >> 2063: (idle = (phase = w.spinWaitPhase()) & IDLE) != 0) { > > @DougLea Not that it'll happen frequently, but it _might_ be worth checking `(runState & STOP) == 0L` directly after the spinwait, and then switch from a `for(;;)` to a do-while where the while-condition is `(runState & STOP) == 0L`. That would avoid the small risk of needing to call setCurrentBlocker twice for situations where the pool transitions to STOP while the spinwait is running. > > It'd be interesting to see if such a change has any discernable impact on ramp-down for benches that include startup and shutdown as a part of the benching process. Thanks. Reworked in a slightly different way though. > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2281: > >> 2279: if (U.compareAndSetReference(a, k, t, null)) { >> 2280: q.base = b + 1; >> 2281: U.putIntVolatile(w, WorkQueue.SOURCE, j); > > @DougLea Since WorkQueue::base is volatile with this PR, it _might_ be worth performing a plain or opaque write to q.base followed by the volatile write to WorkQueue.SOURCE? ? Making it volatile introduced too many unnecessary ordering dependencies, so I undid that. > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2329: > >> 2327: for (;;) { >> 2328: ForkJoinTask t; ForkJoinTask[] a; >> 2329: int b, cap, nb; long k; > > @DougLea `nb` is never used. fixed > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3083: > >> 3081: static ForkJoinPool asyncCommonPool() { >> 3082: ForkJoinPool cp; int p; >> 3083: if ((p = (cp = common).parallelism) == 0) > > @DougLea `p` is never used. fixed > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 3859: > >> 3857: * granularities.The returned count does not include scheduled >> 3858: * tasks that are not yet ready to execute, which are reported >> 3859: * separately by method {@link getDelayedTaskCount}. > > Suggestion: > > * separately by method {@link #getDelayedTaskCount}. Thanks; fixed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679928842 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679927714 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679924965 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679923069 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679922712 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679922306 From dl at openjdk.org Sun Jan 11 17:28:26 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 11 Jan 2026 17:28:26 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <6uTwItprLKNf-pnMjJFR_4cuDVqHNMp_wq4vs4HYbQY=.16b4f399-71ce-47d0-b8d9-90eb440564d4@github.com> On Thu, 8 Jan 2026 23:22:30 GMT, Viktor Klang wrote: >> That loop rereads q.array on each iteration, which means it is never stale. It's possible ito nstead check for staleness and rescan if so. I just tried a version with this, but it's not looking any better. > > Yeah, I was just thinking that the `array`-field is non-volatile so a read isn't guaranteed to yield anything new unless that read is piggybacking on some other fence. The t = U.getReferenceAcquire(...) is doing a lot of work here. Every read after it must be freshly accessed. Thanks for the implicit reminder though that I should do almost all those subsequent reads until CAS at once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679934255 From dl at openjdk.org Sun Jan 11 17:38:37 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 11 Jan 2026 17:38:37 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v21] In-Reply-To: <-QfhcQwb3jWVK0l6Er8o0N3G7tYcTUUABpyfLOhNDUQ=.140669b3-7d11-4fd2-83a3-4761f27f1fb3@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> <-QfhcQwb3jWVK0l6Er8o0N3G7tYcTUUABpyfLOhNDUQ=.140669b3-7d11-4fd2-83a3-4761f27f1fb3@github.com> Message-ID: On Thu, 8 Jan 2026 16:47:08 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Change signalWork fencing; in-progress activation changes > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830: > >> 1828: */ >> 1829: final void signalWork(WorkQueue q, int qbase) { >> 1830: int pc = U.getIntAcquire(this, PARALLELISM); > > I like this, as this has the nice benefit of seeing potential changes to `parallelism` sooner. It's now back to being fresh upon entry, but not upon retries, mainly because retires are now less frequent. > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1855: > >> 1853: break; >> 1854: if (c == (c = ctl) && >> 1855: c == (c = U.compareAndExchangeLong(this, CTL, c, nc))) { > > Are there any measurable differences between the above and `c == (c = ctl) && U.compareAndSetLong(this, CTL, c, nc)` or `c == U.compareAndExchangeLong(this, CTL, c, nc)`? ? It depends on whether there is much contention and/or much filtering. I redid some of it to take a middle ground on this, and results seems almost always better. (Which made me realized that I should reconsider a few other constructions elsewhere.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679952355 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2679948199 From liach at openjdk.org Sun Jan 11 18:04:16 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 11 Jan 2026 18:04:16 GMT Subject: RFR: 8297053: Specify new default byte alignment for native allocators In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 17:11:32 GMT, Igor Rudenko wrote: > Use the largest known value for default allocation alignment so that align value that less than 16 (typical align for modern systems) turns to 16 I think it might be better to inform users that their requested small alignment gets promoted to 16: this is where the incompatibility stems from. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29156#issuecomment-3735201419 From anthonyv.be at outlook.com Sun Jan 11 19:06:22 2026 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Sun, 11 Jan 2026 20:06:22 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> Message-ID: I dissent. (Apparently my previous message wasn't clear.) The right order of things is to first introduce a file extension API. Then see if there's still complaints about `Path::endsWith(String)`. And only then, if there are, consider taking action. In my previous message I've already explained how these methods add real, tangible value and actually are intuitive. (Again, ask developers to guess how `A::foo(B)` behaves, given that both `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will intuitively guess it converts its `b` argument to an instance of `A` and passes it on to `A::foo(A)`. And their intuition would be correct in the case of `Path::endsWith(String)`. That being said, I'll be the first to admit that I've also made the mistake of attempting to use `Path::endsWith(String)` to test the file extension.) In hindsight, maybe `endsWithNames(String)` would've been a better choice, but hindsight is 20/20. Deprecating these methods now is premature. And deprecating them without replacement methods would result in way more complaints than there have ever been about `endsWith(String)`. Anthony On 1/11/2026 12:19 AM, David Alayachew wrote: > Of course. > > I see lots of approvals and not really any dissenters. Are we waiting > for more responses? Or is there anything we can do to kick start this? > > On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter > wrote: > > Thanks for the corroboration. > >> On Jan 8, 2026, at 1:50?PM, David Alayachew >> wrote: >> >> Thanks for reviving this. >> >> I am perfectly happy with the idea of deprecating the >> Path.{start,ends}With(String), and then only add the file >> extension method. Originally, I didn't know that new method was >> on the table, so I suggested a rename. But the file extension api >> feels like the superior solution. >> >> 10 times out of 10, if I am calling endsWith, the only time I am >> not looking for "whole" path elements is when I am looking for a >> file extension. In every other instance, the api does exactly >> what I expect and want. And plus, something like looking for a >> file extension is better off being explicit. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From davidalayachew at gmail.com Sun Jan 11 20:45:33 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Sun, 11 Jan 2026 15:45:33 -0500 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <6EB6F8F8-D887-427A-ADB1-356F2D301745@oracle.com> <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> Message-ID: Thanks for the response Anthony. Messages have been arriving out-of-order for me, so I didn't see yours at the time of me writing that message. I think introducing the file extension API first, then gauging the need for a deprecation before doing it is fine. Sounds like then that we are universally agreed on the first step being to add the file extension API, yes? On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe < anthonyv.be at outlook.com> wrote: > I dissent. (Apparently my previous message wasn't clear.) > > The right order of things is to first introduce a file extension API. Then > see if there's still complaints about `Path::endsWith(String)`. And only > then, if there are, consider taking action. > > In my previous message I've already explained how these methods add real, > tangible value and actually are intuitive. > (Again, ask developers to guess how `A::foo(B)` behaves, given that both > `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will > intuitively guess it converts its `b` argument to an instance of `A` and > passes it on to `A::foo(A)`. And their intuition would be correct in the > case of `Path::endsWith(String)`. That being said, I'll be the first to > admit that I've also made the mistake of attempting to use > `Path::endsWith(String)` to test the file extension.) > > In hindsight, maybe `endsWithNames(String)` would've been a better choice, > but hindsight is 20/20. > > Deprecating these methods now is premature. And deprecating them without > replacement methods would result in way more complaints than there have > ever been about `endsWith(String)`. > > Anthony > On 1/11/2026 12:19 AM, David Alayachew wrote: > > Of course. > > I see lots of approvals and not really any dissenters. Are we waiting for > more responses? Or is there anything we can do to kick start this? > > On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter < > brian.burkhalter at oracle.com> wrote: > >> Thanks for the corroboration. >> >> On Jan 8, 2026, at 1:50?PM, David Alayachew >> wrote: >> >> Thanks for reviving this. >> >> I am perfectly happy with the idea of deprecating the >> Path.{start,ends}With(String), and then only add the file extension method. >> Originally, I didn't know that new method was on the table, so I suggested >> a rename. But the file extension api feels like the superior solution. >> >> 10 times out of 10, if I am calling endsWith, the only time I am not >> looking for "whole" path elements is when I am looking for a file >> extension. In every other instance, the api does exactly what I expect and >> want. And plus, something like looking for a file extension is better off >> being explicit. >> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpai at openjdk.org Mon Jan 12 06:05:43 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 12 Jan 2026 06:05:43 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v4] In-Reply-To: References: 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 te... Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - merge latest from master branch - Mark's suggestion - move the duration check to separate method - merge latest from master branch - Mark's review - use CountDownLatch - merge latest from master branch - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/8f67f18c..029f71a0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=02-03 Stats: 32662 lines in 754 files changed: 14697 ins; 5519 del; 12446 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 duke at openjdk.org Mon Jan 12 07:09:30 2026 From: duke at openjdk.org (Trevor Bond) Date: Mon, 12 Jan 2026 07:09:30 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 669977f7 Author: Trevor Bond Committer: Adam Sotona URL: https://git.openjdk.org/jdk/commit/669977f7c4b58ab4901a340906262ab907b3ffb6 Stats: 60 lines in 4 files changed: 55 ins; 2 del; 3 mod 8341272: Factory to create wide iinc instruction with small arguments Reviewed-by: liach, asotona ------------- PR: https://git.openjdk.org/jdk/pull/28729 From sshivang at openjdk.org Mon Jan 12 07:23:32 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Mon, 12 Jan 2026 07:23:32 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 07:31:47 GMT, Chen Liang wrote: >> Hi all, >> >> This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. >> >> The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. >> >> Thanks! >> >> Straight Backport . The test is passing in JDk26 CI. > > Let's have a sustaining engineer to review before integration. @liach Can you please tag someone for sustaining. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3737188230 From mchevalier at openjdk.org Mon Jan 12 07:57:32 2026 From: mchevalier at openjdk.org (Marc Chevalier) Date: Mon, 12 Jan 2026 07:57:32 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... Testing passed fine, but keeping in mind it might not have a very exhaustive range of hardware (but nothing I can do about that, I fear). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27526#issuecomment-3737278627 From bkilambi at openjdk.org Mon Jan 12 08:16:33 2026 From: bkilambi at openjdk.org (Bhavana Kilambi) Date: Mon, 12 Jan 2026 08:16:33 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Thu, 8 Jan 2026 15:27:01 GMT, Emanuel Peter 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 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 indicate... > > test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 459: > >> 457: short result = (short) 0; >> 458: for (int i = 0; i < LEN; i++) { >> 459: result = float16ToRawShortBits(add(shortBitsToFloat16(result), shortBitsToFloat16(input1[i]))); > > Why all the conversions from and to `short` / `Float16`? > Is there any benefit to use `short` for the intermediate results? Why not make `result` a `Float16`? If I remember correctly, I tried doing that initially but the loop did not get vectorized. The Ideal graph showed there were a lot of nodes related to object creation (probably for the intermediate `Float16` result) which bloated the size of the loop resulting in the loop not getting unrolled (and eventually not vectorized). I also tried a standalone loop where I do not return the intermediate result hoping that escape analysis could help in avoiding the object creation but did not help either. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2681225725 From liach at openjdk.org Mon Jan 12 08:39:52 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 12 Jan 2026 08:39:52 GMT Subject: [jdk26] RFR: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:20:51 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. > > Thanks! > > Straight Backport . The test is passing in JDk26 CI. Guess I'll just sponsor. Guess I'll just sponsor. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3737410219 PR Comment: https://git.openjdk.org/jdk/pull/29131#issuecomment-3737410275 From sshivang at openjdk.org Mon Jan 12 08:42:36 2026 From: sshivang at openjdk.org (Shivangi Gupta) Date: Mon, 12 Jan 2026 08:42:36 GMT Subject: [jdk26] Integrated: 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 03:20:51 GMT, Shivangi Gupta wrote: > Hi all, > > This pull request contains a backport of commit [e75726ee](https://github.com/openjdk/jdk/commit/e75726ee03ca4664827ca5d680c02bcf2a96f4ea) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Chen Liang on 17 Dec 2025 and was reviewed by Jorn Vernee and Aleksey Shipilev. > > Thanks! > > Straight Backport . The test is passing in JDk26 CI. This pull request has now been integrated. Changeset: 7317343d Author: Shivangi Gupta Committer: Chen Liang URL: https://git.openjdk.org/jdk/commit/7317343d4719ea434e0e3d9d2af8734004b65343 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod 8373832: Test java/lang/invoke/TestVHInvokerCaching.java tests nothing Reviewed-by: liach Backport-of: e75726ee03ca4664827ca5d680c02bcf2a96f4ea ------------- PR: https://git.openjdk.org/jdk/pull/29131 From epeter at openjdk.org Mon Jan 12 08:50:46 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 12 Jan 2026 08:50:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 12 Jan 2026 08:13:04 GMT, Bhavana Kilambi wrote: >> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java line 459: >> >>> 457: short result = (short) 0; >>> 458: for (int i = 0; i < LEN; i++) { >>> 459: result = float16ToRawShortBits(add(shortBitsToFloat16(result), shortBitsToFloat16(input1[i]))); >> >> Why all the conversions from and to `short` / `Float16`? >> Is there any benefit to use `short` for the intermediate results? Why not make `result` a `Float16`? > > If I remember correctly, I tried doing that initially but the loop did not get vectorized. The Ideal graph showed there were a lot of nodes related to object creation (probably for the intermediate `Float16` result) which bloated the size of the loop resulting in the loop not getting unrolled (and eventually not vectorized). I also tried a standalone loop where I do not return the intermediate result hoping that escape analysis could help in avoiding the object creation but did not help either. Hmm, I see. That sounds like a deficiency in the auto unboxing of Float16. Suggestion: You should create both variants of the IR tests. And then file an RFE for the one that does not yet vectorize because of the boxing issues. Because the way things are now, it's not a huge win, to be honest. Which user is supposed to write their code in such a convoluted way, having to cast back and forth? Would they not expect they could just use Float16 all the way through? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2681318247 From epeter at openjdk.org Mon Jan 12 08:50:47 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 12 Jan 2026 08:50:47 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 12 Jan 2026 08:47:07 GMT, Emanuel Peter wrote: >> If I remember correctly, I tried doing that initially but the loop did not get vectorized. The Ideal graph showed there were a lot of nodes related to object creation (probably for the intermediate `Float16` result) which bloated the size of the loop resulting in the loop not getting unrolled (and eventually not vectorized). I also tried a standalone loop where I do not return the intermediate result hoping that escape analysis could help in avoiding the object creation but did not help either. > > Hmm, I see. That sounds like a deficiency in the auto unboxing of Float16. > > Suggestion: You should create both variants of the IR tests. And then file an RFE for the one that does not yet vectorize because of the boxing issues. > > Because the way things are now, it's not a huge win, to be honest. Which user is supposed to write their code in such a convoluted way, having to cast back and forth? Would they not expect they could just use Float16 all the way through? @jatin-bhateja What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2681319220 From vklang at openjdk.org Mon Jan 12 10:18:34 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 12 Jan 2026 10:18:34 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v23] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 11 Jan 2026 17:11:38 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 33 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - reunify push; improve contention vs activation vs park balance > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index > - Change signalWork fencing; in-progress activation changes > - Merge branch 'openjdk:master' into JDK-8373118 > - Split external push > - Undo/redo ordering changes > - Strengthen some orderings > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 23 more: https://git.openjdk.org/jdk/compare/18d2870a...f42d2475 src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2046: > 2044: Thread.yield(); // reduce unproductive scanning > 2045: for (int s = SPIN_WAITS; (idle = w.phase & IDLE) != 0 && --s != 0;) > 2046: Thread.onSpinWait(); spinning _after_ yielding? ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2681620777 From mdoerr at openjdk.org Mon Jan 12 11:41:05 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Mon, 12 Jan 2026 11:41:05 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Wed, 7 Jan 2026 14:05:32 GMT, Maurizio Cimadamore wrote: >> I haven't tried (not my machine), but it's undefined behavior. There's no guarantee that `getpwuid_r` does what we expect. We should never use undefined behavior. Also note that not only AIX is affected. > >> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? > > Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here: > > https://bugs.openjdk.org/browse/JDK-8336664 > > (apologies -- this link was already shared by @dmlloyd ) Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2681912656 From vklang at openjdk.org Mon Jan 12 12:02:15 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 12 Jan 2026 12:02:15 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v23] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <3tTEfs-cQMVfdDpzwUyVlcd1lUWpl4YD7EnssB-Uvdw=.41d41cf2-234b-4b8f-82b5-5cf238b8e84d@github.com> On Sun, 11 Jan 2026 17:11:38 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 33 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - reunify push; improve contention vs activation vs park balance > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index > - Change signalWork fencing; in-progress activation changes > - Merge branch 'openjdk:master' into JDK-8373118 > - Split external push > - Undo/redo ordering changes > - Strengthen some orderings > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 23 more: https://git.openjdk.org/jdk/compare/849376f7...f42d2475 src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1260: > 1258: U.putReferenceVolatile(a, slotOffset(m & s), task); > 1259: if (unlock != 1) // release external lock > 1260: U.putInt(this, PHASE, unlock); Doesn't this need to at least be a `putIntRelease`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2681978895 From msheppar at openjdk.org Mon Jan 12 12:24:01 2026 From: msheppar at openjdk.org (Mark Sheppard) Date: Mon, 12 Jan 2026 12:24:01 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v4] In-Reply-To: References: Message-ID: <90PzCP3BrE-3zd8nRBqY8nvopsSMUaUIZvJi36zgc6A=.743fd657-814b-4f0b-b84f-c9ea5dcf3117@github.com> On Mon, 12 Jan 2026 06:05:43 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 continue... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - merge latest from master branch > - Mark's suggestion - move the duration check to separate method > - merge latest from master branch > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds thanks for taking the feedback my openjdk status has yet to be re-asserted but, FWIW ... LGTM ------------- Marked as reviewed by msheppar (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28919#pullrequestreview-3650507206 From vklang at openjdk.org Mon Jan 12 12:49:29 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 12 Jan 2026 12:49:29 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v23] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 11 Jan 2026 17:11:38 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 33 additional commits since the last revision: > > - Merge branch 'openjdk:master' into JDK-8373118 > - reunify push; improve contention vs activation vs park balance > - Undo unrelated change > - Re-introduce acquiring array reads; re-arrange to rely on volatile base index > - Change signalWork fencing; in-progress activation changes > - Merge branch 'openjdk:master' into JDK-8373118 > - Split external push > - Undo/redo ordering changes > - Strengthen some orderings > - Merge branch 'openjdk:master' into JDK-8373118 > - ... and 23 more: https://git.openjdk.org/jdk/compare/af30d06a...f42d2475 src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830: > 1828: int pc = parallelism, i, sp; // rely on caller sync for initial reads > 1829: long c = U.getLong(this, CTL); > 1830: WorkQueue[] qs = queues; If we only read this on entry, doesn't that risk not observing the number of queues growing? src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1854: > 1852: break; > 1853: } > 1854: qs = queues; Regarding https://github.com/openjdk/jdk/pull/28797/changes#r2682127585 , so we're refresh-reading it here, relying on (at least) the https://github.com/openjdk/jdk/pull/28797/changes#diff-e398beb49cd8d3e6c2f3a8ca8eee97172c57d7f88f3ccd8a3c704632cab32f5fR1844 load? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2682127585 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2682133420 From mcimadamore at openjdk.org Mon Jan 12 13:05:44 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 13:05:44 GMT Subject: RFR: 8297053: Specify new default byte alignment for native allocators In-Reply-To: References: Message-ID: <8glW-bDRMQIJmD78xUcxjuBvHhNYTY4xfmzWU-f6fKw=.d2810aba-26af-4235-89c7-2390e3658b84@github.com> On Sun, 11 Jan 2026 17:11:32 GMT, Igor Rudenko wrote: > Use the largest known value for default allocation alignment so that align value that less than 16 (typical align for modern systems) turns to 16 This PR seems in conflict with the goals of another PR: https://git.openjdk.org/jdk/pull/28235 In that PR (see lengthy discussion) it emerged that in modern C standards, malloc is only constrained to return an alignment that is compatible with the size of the object being allocated. So, when allocating 2 bytes, some malloc implementations are allowed to return a 2-byte aligned address -- that's not against the spec. So, by forcing 16-byte min alignment on everything, we'd end up adding significant additional padding when e.g. preloading the `jemalloc` allocator. It would be helpful if you could provide some examples of why the current behavior would not be correct on some platforms. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29156#issuecomment-3738451086 From duke at openjdk.org Mon Jan 12 13:14:42 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 Jan 2026 13:14:42 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: <75wy2ekhG3uunkk0gmFg8eErEfSDFzy_nStTPwtx9kk=.ad75de54-aa77-4e7b-ac39-9af94d04c012@github.com> References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> <75wy2ekhG3uunkk0gmFg8eErEfSDFzy_nStTPwtx9kk=.ad75de54-aa77-4e7b-ac39-9af94d04c012@github.com> Message-ID: On Fri, 9 Jan 2026 15:40:30 GMT, Roger Riggs wrote: > The jimage versions number are only significant within the tool and implementation. If the version numbers were synchronized to the JDK version, (as we do with class file versions, CDS archives, etc.) it would be straight-forward for the message to be specific about what version of jimage is needed for the jimage. While that's true, it also incurs additional maintenance to ensure it's not accidentally left as the wrong value, and it would mean that in the vast majority of cases where no file structure had changed, the tool would now not work (possibly breaking existing users in unnecessary ways). An alternate approach would be to store the JDK version (as a string) at which the file was made, but not use it for the check. This way you only need it when the check fails, but can provide a precise version that would work. As Alan points out, this is really an internal tool and doesn't offer comprehensive error messages today, so it might not be worth a lot of effort to make highly detailed error messages for what should be a tiny number of advanced users. I do think some explanation is needed however, since this is a new type of failure mode which couldn't previously occur and might otherwise stump the tiny number of people it could affect. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3738480540 From mcimadamore at openjdk.org Mon Jan 12 13:27:21 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 13:27:21 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] In-Reply-To: References: Message-ID: <9pz5GWEHkLEhhO1gI38uI7VgqydZ4xMscWozaEkzQTo=.b4ef7207-1192-4c56-bc0d-efdfb506327a@github.com> On Sun, 11 Jan 2026 14:03:02 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 >> FromJavaStringTest.segment_copyStringBytes 5 avgt 30 4.877 ? 0.508 ns/op >> FromJavaStringTest.segment_copyStringBytes 20 avgt 30 5.090 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringBytes 100 avgt 30 9.343 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringBytes 200 avgt 30 12.920 ? 2.800 ns/op >> FromJavaStringTest.segment_copyStringBytes 451 avgt 30 25.476 ? 0.388 ns/op >> FromJavaStringTest.segment_copyStringRaw 5 avgt 30 3.544 ? 0.915 ns/op >> FromJavaStringTest.segment_copyStringRaw 20 avgt 30 3.417 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringRaw 100 avgt 30 5.901 ? 0.054 ns/op >> FromJavaStringTest.segment_copyStringRaw 200 avgt 30 7.257 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringRaw 451 avgt 30 11.840 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 5 avgt 30 6.192 ? 0.144 ns/op >> FromJavaStringTest.segment_setString 20 avgt 30 6.383 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 100 avgt 30 8.920 ? 0.161 ns/op >> FromJavaStringTest.segment_setString 200 avgt 30 10.973 ? 1.614 ns/op >> FromJavaStringTest.segment_setString 451 avgt 30 19.028 ? 0.247 ns/op >> >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ToJavaStringTest.jni_re... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Hannes Greule Still looks good to me -- let's also wait for @JornVernee ------------- Marked as reviewed by mcimadamore (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3650746504 From mcimadamore at openjdk.org Mon Jan 12 13:27:59 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Mon, 12 Jan 2026 13:27:59 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr wrote: >>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? >> >> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here: >> >> https://bugs.openjdk.org/browse/JDK-8336664 >> >> (apologies -- this link was already shared by @dmlloyd ) > > Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions? At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2682268844 From jvernee at openjdk.org Mon Jan 12 15:00:07 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 12 Jan 2026 15:00:07 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 14:03:02 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 >> FromJavaStringTest.segment_copyStringBytes 5 avgt 30 4.877 ? 0.508 ns/op >> FromJavaStringTest.segment_copyStringBytes 20 avgt 30 5.090 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringBytes 100 avgt 30 9.343 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringBytes 200 avgt 30 12.920 ? 2.800 ns/op >> FromJavaStringTest.segment_copyStringBytes 451 avgt 30 25.476 ? 0.388 ns/op >> FromJavaStringTest.segment_copyStringRaw 5 avgt 30 3.544 ? 0.915 ns/op >> FromJavaStringTest.segment_copyStringRaw 20 avgt 30 3.417 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringRaw 100 avgt 30 5.901 ? 0.054 ns/op >> FromJavaStringTest.segment_copyStringRaw 200 avgt 30 7.257 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringRaw 451 avgt 30 11.840 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 5 avgt 30 6.192 ? 0.144 ns/op >> FromJavaStringTest.segment_setString 20 avgt 30 6.383 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 100 avgt 30 8.920 ? 0.161 ns/op >> FromJavaStringTest.segment_setString 200 avgt 30 10.973 ? 1.614 ns/op >> FromJavaStringTest.segment_setString 451 avgt 30 19.028 ? 0.247 ns/op >> >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ToJavaStringTest.jni_re... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Hannes Greule Marked as reviewed by jvernee (Reviewer). Still looks good. I read the final CSR as well. Thanks for the diligence on this! ------------- PR Review: https://git.openjdk.org/jdk/pull/28043#pullrequestreview-3651190392 PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3738966106 From cushon at openjdk.org Mon Jan 12 15:24:57 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 12 Jan 2026 15:24:57 GMT Subject: Integrated: 8369564: Provide a MemorySegment API to read strings with known lengths In-Reply-To: References: Message-ID: <7v5DsPdPuU_55dCH84HjmjOWEZvftkfVdtb0ZDMRQyI=.45369fae-406b-4ec6-82ff-76233bc554c1@github.com> On Wed, 29 Oct 2025 10:50:53 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 > FromJavaStringTest.segment_copyStringBytes 5 avgt 30 4.877 ? 0.508 ns/op > FromJavaStringTest.segment_copyStringBytes 20 avgt 30 5.090 ? 0.051 ns/op > FromJavaStringTest.segment_copyStringBytes 100 avgt 30 9.343 ? 0.073 ns/op > FromJavaStringTest.segment_copyStringBytes 200 avgt 30 12.920 ? 2.800 ns/op > FromJavaStringTest.segment_copyStringBytes 451 avgt 30 25.476 ? 0.388 ns/op > FromJavaStringTest.segment_copyStringRaw 5 avgt 30 3.544 ? 0.915 ns/op > FromJavaStringTest.segment_copyStringRaw 20 avgt 30 3.417 ? 0.073 ns/op > FromJavaStringTest.segment_copyStringRaw 100 avgt 30 5.901 ? 0.054 ns/op > FromJavaStringTest.segment_copyStringRaw 200 avgt 30 7.257 ? 0.051 ns/op > FromJavaStringTest.segment_copyStringRaw 451 avgt 30 11.840 ? 0.041 ns/op > FromJavaStringTest.segment_setString 5 avgt 30 6.192 ? 0.144 ns/op > FromJavaStringTest.segment_setString 20 avgt 30 6.383 ? 0.041 ns/op > FromJavaStringTest.segment_setString 100 avgt 30 8.920 ? 0.161 ns/op > FromJavaStringTest.segment_setString 200 avgt 30 10.973 ? 1.614 ns/op > FromJavaStringTest.segment_setString 451 avgt 30 19.028 ? 0.247 ns/op > > > > Benchmark (size) Mode Cnt Score Error Units > ToJavaStringTest.jni_readString 5 avgt 30 53.190 ? 0.638 ns/op > ToJavaStringTes... This pull request has now been integrated. Changeset: d433ce52 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/d433ce52360994be5a88a0bcbf39cbb741b435ec Stats: 549 lines in 10 files changed: 494 ins; 26 del; 29 mod 8369564: Provide a MemorySegment API to read strings with known lengths Co-authored-by: Per Minborg Reviewed-by: jvernee, mcimadamore ------------- PR: https://git.openjdk.org/jdk/pull/28043 From rriggs at openjdk.org Mon Jan 12 15:27:33 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 15:27:33 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line I don't think any per-version maintenance is required. Both the creation and open version check would use `Runtime.version()`. On creation, its written into the jimage file and on open its checked against the current version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3739123908 From alanb at openjdk.org Mon Jan 12 15:30:49 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Jan 2026 15:30:49 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: <_OBEkatnYiCZ9cvRGxXCDAx0hmqGa09CiMFb1uVMihY=.d8ff56e0-142e-424d-b141-2ac821413d74@github.com> On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line Roger's idea to use the release version seems a good idea but might be tricky to setup. That is, it might require some build foo as the source can't reference Runtime.Version or other APIs because it gets compiled `--release` for jrt-fs.jar. That said, not to say if it's worth it as the jimage tool is not documented so should be rare to have these mismatch issues. On the current proposal: I don't particularly like having BasicImageReader.readHeader throw an IOException with a path to the jimage tool as this IOException may pop up in other contexts. I wonder if it could throw a more specific mismatch exception for this case so that the jimage tool can handle, and translate into something that includes a path to itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3739133289 From asemenyuk at openjdk.org Mon Jan 12 16:42:14 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 16:42:14 GMT Subject: RFR: 8375050: Simplify process management in jpackage tests Message-ID: Replace "taskkill" and powershell script managing child processes started by jpackage tests on Windows with `java.lang.Process` API. ------------- Commit messages: - Simplify process termination on Windows. Changes: https://git.openjdk.org/jdk/pull/29172/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29172&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375050 Stats: 238 lines in 8 files changed: 67 ins; 126 del; 45 mod Patch: https://git.openjdk.org/jdk/pull/29172.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29172/head:pull/29172 PR: https://git.openjdk.org/jdk/pull/29172 From asemenyuk at openjdk.org Mon Jan 12 16:42:15 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 16:42:15 GMT Subject: RFR: 8375050: Simplify process management in jpackage tests In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 16:28:30 GMT, Alexey Semenyuk wrote: > Replace "taskkill" and powershell script managing child processes started by jpackage tests on Windows with `java.lang.Process` API. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29172#issuecomment-3739459920 From dl at openjdk.org Mon Jan 12 17:24:29 2026 From: dl at openjdk.org (Doug Lea) Date: Mon, 12 Jan 2026 17:24:29 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v24] In-Reply-To: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <7lo8Ue0pcZ9BNBn3c_HSavukijuo0kPGUcVMDG7h5W0=.45936d54-be55-4795-a1fd-e5c29ad11bfd@github.com> > 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 35 additional commits since the last revision: - Merge branch 'openjdk:master' into JDK-8373118 - Use explicit store fences or atomics - Merge branch 'openjdk:master' into JDK-8373118 - reunify push; improve contention vs activation vs park balance - Undo unrelated change - Re-introduce acquiring array reads; re-arrange to rely on volatile base index - Change signalWork fencing; in-progress activation changes - Merge branch 'openjdk:master' into JDK-8373118 - Split external push - Undo/redo ordering changes - ... and 25 more: https://git.openjdk.org/jdk/compare/aadf8c0d...c3e137a6 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/f42d2475..c3e137a6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=23 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=22-23 Stats: 975 lines in 31 files changed: 841 ins; 55 del; 79 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 Mon Jan 12 17:41:20 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 17:41:20 GMT Subject: RFR: 8375054: Removed "signed" property from jpackage app image file Message-ID: $subj Additionally: - Validate that the value of the "--app-image" option on macOS is a valid macOS bundle, and if it is not, exit with a new "error.parameter-not-mac-bundle" error. - Read stdout of "/usr/bin/codesign" and "/usr/sbin/spctl" commands outputing plist XML as binary, and not as text. ------------- Commit messages: - Fix a bug revealed by LicenseTest.java and AppImagePackageTest.java test failures - ErrorTest: add a test case for a new "error.parameter-not-mac-bundle" error - Remove the "signed" property from the app image file; MacHelper: fix readPList() to make it read binary output of commands that write plist xml in stdout; MacSignVerify: fix findEntitlements() to save binary output for using as input for MacHelper.readPList() - Check that the value of the "--app-image" option is a valid macOS bundle and not an any directory - MacBundle: move the class to shared code to use in the cli package and in the test code. Remove fromAppImageLayout() - it can't be used in the test code. Remove isSigned() - it is broken; MacPackagingPipeline: follow-up MacBundle changes, implement isSigned(MacBundle) method properly; MacFromOptions: use MacPackagingPipeline.isSigned() - OptionSpecBuilder: support configuring cooked validator, expose createValidator() - Validator: add or() method; simplify and() - MacSignVerify: minor Changes: https://git.openjdk.org/jdk/pull/29173/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29173&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375054 Stats: 627 lines in 21 files changed: 371 ins; 182 del; 74 mod Patch: https://git.openjdk.org/jdk/pull/29173.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29173/head:pull/29173 PR: https://git.openjdk.org/jdk/pull/29173 From asemenyuk at openjdk.org Mon Jan 12 17:41:20 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 17:41:20 GMT Subject: RFR: 8375054: Removed "signed" property from jpackage app image file In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:08:17 GMT, Alexey Semenyuk wrote: > $subj > > Additionally: > - Validate that the value of the "--app-image" option on macOS is a valid macOS bundle, and if it is not, exit with a new "error.parameter-not-mac-bundle" error. > - Read stdout of "/usr/bin/codesign" and "/usr/sbin/spctl" commands outputing plist XML as binary, and not as text. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29173#issuecomment-3739698196 From dl at openjdk.org Mon Jan 12 17:44:22 2026 From: dl at openjdk.org (Doug Lea) Date: Mon, 12 Jan 2026 17:44:22 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v25] 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: Fix missing undo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/c3e137a6..bb492a04 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=24 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=23-24 Stats: 3 lines in 1 file changed: 0 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 rriggs at openjdk.org Mon Jan 12 17:49:58 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 17:49:58 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 Please review changing from testng to junit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28877#issuecomment-3739741588 From alanb at openjdk.org Mon Jan 12 18:16:34 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Jan 2026 18:16:34 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/class/NonSerializableTest.java line 67: > 65: > 66: // Test cases to compile and run > 67: public Object[] provider() { Could this be changed to be a static method that returns a Stream>, and if so, would it allow the test to drop the ned for Lifecycle.PER_CLASS. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683355298 From hgreule at openjdk.org Mon Jan 12 18:45:26 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 12 Jan 2026 18:45:26 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) Message-ID: A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. ------------- Commit messages: - adjust javadoc Changes: https://git.openjdk.org/jdk/pull/29174/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29174&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374538 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29174.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29174/head:pull/29174 PR: https://git.openjdk.org/jdk/pull/29174 From naoto at openjdk.org Mon Jan 12 18:57:30 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 Jan 2026 18:57:30 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/SerialFilterFactoryTest.java line 182: > 180: @EnabledIf("isValidFilterFactory") > 181: @MethodSource("filterCases") > 182: @Order(1) This could be a relative order, such as `Order.DEFAULT - 1`, instead of 1 vs 99? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683495954 From duke at openjdk.org Mon Jan 12 19:04:02 2026 From: duke at openjdk.org (Roger Calnan) Date: Mon, 12 Jan 2026 19:04:02 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page Message-ID: adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option ------------- Commit messages: - replace arg:-something with arg__something - updated copyright year - back out changes to keytool.md - Initial links added Changes: https://git.openjdk.org/jdk/pull/28954/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373836 Stats: 247 lines in 1 file changed: 0 ins; 0 del; 247 mod Patch: https://git.openjdk.org/jdk/pull/28954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28954/head:pull/28954 PR: https://git.openjdk.org/jdk/pull/28954 From jwilhelm at openjdk.org Mon Jan 12 19:04:03 2026 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 12 Jan 2026 19:04:03 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Looks good! ------------- Marked as reviewed by jwilhelm (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3641639372 From rriggs at openjdk.org Mon Jan 12 19:09:10 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 19:09:10 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v3] 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: Update to use Stream> for parameterized method testing. Add static to simplify test setup. Small source changes to remove "C" style array declarations. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28877/files - new: https://git.openjdk.org/jdk/pull/28877/files/e3fdaef1..cc9a66bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=01-02 Stats: 14 lines in 1 file changed: 2 ins; 3 del; 9 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 jlu at openjdk.org Mon Jan 12 19:09:12 2026 From: jlu at openjdk.org (Justin Lu) Date: Mon, 12 Jan 2026 19:09:12 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: <3lr-dKg3GZzio28UwuMvd4aCzaK6x2Q4ywddswj0vXk=.6bb79b4b-71c9-44b1-b69b-e8cd40504af4@github.com> 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/SerialFilterTest.java line 403: > 401: @MethodSource("invalidLimits") > 402: void testInvalidLimits(String pattern) { > 403: Assertions.assertThrows(IllegalArgumentException.class, () -> { Perhaps simplifying these exception checking cases such as, var iae = Assertions.assertThrows(IllegalArgumentException.class, () -> ObjectInputFilter.Config.createFilter(pattern)); System.out.printf(" success exception: %s%n", iae); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683484242 From iris at openjdk.org Mon Jan 12 19:17:32 2026 From: iris at openjdk.org (Iris Clark) Date: Mon, 12 Jan 2026 19:17:32 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3652316335 From asemenyuk at openjdk.org Mon Jan 12 19:28:40 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 19:28:40 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config Message-ID: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> The patch addresses two issues: - Each jpackage tool provider instance should have its own logging config instance. - The test lib should be able to keep output from concurrently running tests isolated from each other. These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. Supplementary changes: - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. ------------- Commit messages: - Update copyright year - Log: fix the bug revealed by AsyncTest that log messages from all jpackage instances go into the log streams of the last started jpackage instead of going in log streams associated with these jpackage instances. - Use ScopedValue - JUnitAdapter: fix charset - cli/Main: fix charsets when converting from PrintStream to PrintWriter - Simplify TKit; make AsyncTest properly collect test cases logs Changes: https://git.openjdk.org/jdk/pull/29175/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29175&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375061 Stats: 439 lines in 12 files changed: 138 ins; 170 del; 131 mod Patch: https://git.openjdk.org/jdk/pull/29175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29175/head:pull/29175 PR: https://git.openjdk.org/jdk/pull/29175 From asemenyuk at openjdk.org Mon Jan 12 19:28:41 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 12 Jan 2026 19:28:41 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: On Mon, 12 Jan 2026 19:03:25 GMT, Alexey Semenyuk wrote: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29175#issuecomment-3740137014 From jvernee at openjdk.org Mon Jan 12 19:34:51 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 12 Jan 2026 19:34:51 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:36:33 GMT, Hannes Greule wrote: > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. Looks good ------------- Marked as reviewed by jvernee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29174#pullrequestreview-3652386097 From stuart.marks at oracle.com Mon Jan 12 19:36:42 2026 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 12 Jan 2026 11:36:42 -0800 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> Message-ID: <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> Let's not tie these two issues together. The discussion clearly shows that the startsWith/endsWith(String) APIs are a trap that several people have fallen into. On that basis it should be deprecated. (Ordinarily, so as to emit a warning, and not for removal, so there won't be any compatibility issue.) There is also no requirement that a new API be introduced to replace any deprecated API. As the earlier discussion in the thread shows, both the path-based and the string-based use cases can be written using existing APIs, somewhat less conveniently and more verbosely; but these constructs are much more explicit and so are preferable to the APIs to be deprecated. The deprecation text should steer people toward the preferred constructs. It would indeed be nice to have a file extension API, but this has been discussed several times and has run aground each time for a variety of reasons. Tying these together will hold up the deprecation for no good reason. Let's proceed with just the deprecation first and work on the file extension API separately. s'marks On 1/11/26 12:45 PM, David Alayachew wrote: > Thanks for the response Anthony. Messages have been arriving out-of-order for me, > so I didn't see yours at the time of me writing that message. > > I think introducing the file extension API first, then gauging the need for a > deprecation before doing it is fine. Sounds like then that we are universally > agreed on the first step being to add the file extension API, yes? > > On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe > wrote: > > I dissent. (Apparently my previous message wasn't clear.) > > The right order of things is to first introduce a file extension API. Then see > if there's still complaints about `Path::endsWith(String)`. And only then, if > there are, consider taking action. > > In my previous message I've already explained how these methods add real, > tangible value and actually are intuitive. > (Again, ask developers to guess how `A::foo(B)` behaves, given that both > `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will > intuitively guess it converts its `b` argument to an instance of `A` and > passes it on to `A::foo(A)`. And their intuition would be correct in the case > of `Path::endsWith(String)`. That being said, I'll be the first to admit that > I've also made the mistake of attempting to use `Path::endsWith(String)` to > test the file extension.) > > In hindsight, maybe `endsWithNames(String)` would've been a better choice, but > hindsight is 20/20. > > Deprecating these methods now is premature. And deprecating them without > replacement methods would result in way more complaints than there have ever > been about `endsWith(String)`. > > Anthony > > On 1/11/2026 12:19 AM, David Alayachew wrote: >> Of course. >> >> I see lots of approvals and not really any dissenters. Are we waiting for >> more responses? Or is there anything we can do to kick start this? >> >> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter >> wrote: >> >> Thanks for the corroboration. >> >>> On Jan 8, 2026, at 1:50?PM, David Alayachew >>> wrote: >>> >>> Thanks for reviving this. >>> >>> I am perfectly happy with the idea of deprecating the >>> Path.{start,ends}With(String), and then only add the file extension >>> method. Originally, I didn't know that new method was on the table, so I >>> suggested a rename. But the file extension api feels like the superior >>> solution. >>> >>> 10 times out of 10, if I am calling endsWith, the only time I am not >>> looking for "whole" path elements is when I am looking for a file >>> extension. In every other instance, the api does exactly what I expect >>> and want. And plus, something like looking for a file extension is >>> better off being explicit. >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Mon Jan 12 19:36:01 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 12 Jan 2026 19:36:01 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v3] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Mon, 12 Jan 2026 19:09:10 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: > > Update to use Stream> for parameterized method testing. > Add static to simplify test setup. > Small source changes to remove "C" style array declarations. test/jdk/java/io/Serializable/serialFilter/CheckArrayTest.java line 55: > 53: * The filterCheck must be resilent to an InputStream not being available (only the subclass knows). > 54: */ > 55: @TestInstance(TestInstance.Lifecycle.PER_CLASS) Looks like 9 other tests are using PER_CLASS, is that because of setup methods and method sources that are instance rather than static methods? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683614000 From rriggs at openjdk.org Mon Jan 12 20:00:31 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 20:00:31 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v3] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Mon, 12 Jan 2026 19:33:10 GMT, Alan Bateman wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Update to use Stream> for parameterized method testing. >> Add static to simplify test setup. >> Small source changes to remove "C" style array declarations. > > test/jdk/java/io/Serializable/serialFilter/CheckArrayTest.java line 55: > >> 53: * The filterCheck must be resilent to an InputStream not being available (only the subclass knows). >> 54: */ >> 55: @TestInstance(TestInstance.Lifecycle.PER_CLASS) > > Looks like 9 other tests are using PER_CLASS, is that because of setup methods and method sources that are instance rather than static methods? The helpful conversion tool added PER_CLASS, I assume due to the source methods were instance method. Use of PER_CLASS does not seem to be discouraged. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683706953 From heidinga at openjdk.org Mon Jan 12 20:10:50 2026 From: heidinga at openjdk.org (Dan Heidinga) Date: Mon, 12 Jan 2026 20:10:50 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 12:35:28 GMT, Per Minborg wrote: >> This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. >> >> On multiple platforms, tested and passed: >> - [x] tier1 >> - [x] tier2 >> - [x] tier3 >> >> Not tested: >> - [ ] tier4 >> - [ ] tier5 >> - [ ] tier6 > > Per Minborg has updated the pull request incrementally with one additional commit since the last revision: > > Add a real test test/hotspot/jtreg/runtime/cds/appcds/aotClassLinking/GeneratedInternedString.java line 79: > 77: } > 78: > 79: // A variant using a bespoke record Should the record class be annotated with `@AOTSafeClassInitializer` as well? My understanding of the test framework is that it's looking for a particular error string showing bad values / objects cached in the heap archive. Without the annotation here, we're not attempting to make the record class stay initialized in the archive... Possible I'm missing something here but I don't think we're actually testing the record being saved in an initialized state yet ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29084#discussion_r2683747809 From rriggs at openjdk.org Mon Jan 12 20:26:04 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 20:26:04 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 Mon, 12 Jan 2026 18:53:54 GMT, Naoto Sato wrote: >> 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/SerialFilterFactoryTest.java line 182: > >> 180: @EnabledIf("isValidFilterFactory") >> 181: @MethodSource("filterCases") >> 182: @Order(1) > > This could be a relative order, such as `Order.DEFAULT - 1`, instead of 1 vs 99? I haven't found any documentation of Order.DEFAULT indicating its recommended usage. Nor any existing usages in OpenJDK. Its value is a very large positive number. 0x3fffffff about 1/2 way to Integer.MAX_VALUE ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683790748 From rriggs at openjdk.org Mon Jan 12 20:51:51 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 12 Jan 2026 20:51:51 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v2] In-Reply-To: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: > On Linux and Mac, when a process is started, pipes are created to communicate with the child. > In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. > > Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. > Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) > Converted PipelineLeaksFD test to JUnit. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Refactored invocation of `lsof` to not use pipes for I/O, using files instead. It removes the possibility of side effects that might affect the checking of pipe usage. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29143/files - new: https://git.openjdk.org/jdk/pull/29143/files/c8b39e4a..83d03292 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=00-01 Stats: 28 lines in 1 file changed: 12 ins; 7 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29143/head:pull/29143 PR: https://git.openjdk.org/jdk/pull/29143 From naoto at openjdk.org Mon Jan 12 21:06:10 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 12 Jan 2026 21:06:10 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 Mon, 12 Jan 2026 20:22:03 GMT, Roger Riggs wrote: >> test/jdk/java/io/Serializable/serialFilter/SerialFilterFactoryTest.java line 182: >> >>> 180: @EnabledIf("isValidFilterFactory") >>> 181: @MethodSource("filterCases") >>> 182: @Order(1) >> >> This could be a relative order, such as `Order.DEFAULT - 1`, instead of 1 vs 99? > > I haven't found any documentation of Order.DEFAULT indicating its recommended usage. > Nor any existing usages in OpenJDK. > Its value is a very large positive number. 0x3fffffff about 1/2 way to Integer.MAX_VALUE I was just reading the JUnit doc that elements that are not annotated with `@Order` have the `DEFAULT` order value, thus giving the `testCase` method higher priority achieves what we want (with only one `@Order` annotation, instead of two). I am fine either way though ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2683894438 From dholmes at openjdk.org Mon Jan 12 21:33:05 2026 From: dholmes at openjdk.org (David Holmes) Date: Mon, 12 Jan 2026 21:33:05 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] In-Reply-To: References: Message-ID: On Sun, 11 Jan 2026 14:03:02 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 >> FromJavaStringTest.segment_copyStringBytes 5 avgt 30 4.877 ? 0.508 ns/op >> FromJavaStringTest.segment_copyStringBytes 20 avgt 30 5.090 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringBytes 100 avgt 30 9.343 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringBytes 200 avgt 30 12.920 ? 2.800 ns/op >> FromJavaStringTest.segment_copyStringBytes 451 avgt 30 25.476 ? 0.388 ns/op >> FromJavaStringTest.segment_copyStringRaw 5 avgt 30 3.544 ? 0.915 ns/op >> FromJavaStringTest.segment_copyStringRaw 20 avgt 30 3.417 ? 0.073 ns/op >> FromJavaStringTest.segment_copyStringRaw 100 avgt 30 5.901 ? 0.054 ns/op >> FromJavaStringTest.segment_copyStringRaw 200 avgt 30 7.257 ? 0.051 ns/op >> FromJavaStringTest.segment_copyStringRaw 451 avgt 30 11.840 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 5 avgt 30 6.192 ? 0.144 ns/op >> FromJavaStringTest.segment_setString 20 avgt 30 6.383 ? 0.041 ns/op >> FromJavaStringTest.segment_setString 100 avgt 30 8.920 ? 0.161 ns/op >> FromJavaStringTest.segment_setString 200 avgt 30 10.973 ? 1.614 ns/op >> FromJavaStringTest.segment_setString 451 avgt 30 19.028 ? 0.247 ns/op >> >> >> >> Benchmark (size) Mode Cnt Score Error Units >> ToJavaStringTest.jni_re... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Apply suggestions from code review > > Co-authored-by: Hannes Greule This change broke the SinceChecker test: [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8375066) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3740562525 From davidalayachew at gmail.com Mon Jan 12 21:36:09 2026 From: davidalayachew at gmail.com (David Alayachew) Date: Mon, 12 Jan 2026 16:36:09 -0500 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> References: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> Message-ID: Deal. I can't make JBS Submissions, but if someone gets me a bug number, I can do it. On Mon, Jan 12, 2026, 2:36?PM Stuart Marks wrote: > Let's not tie these two issues together. > > The discussion clearly shows that the startsWith/endsWith(String) APIs are > a trap that several people have fallen into. On that basis it should be > deprecated. (Ordinarily, so as to emit a warning, and not for removal, so > there won't be any compatibility issue.) > > There is also no requirement that a new API be introduced to replace any > deprecated API. As the earlier discussion in the thread shows, both the > path-based and the string-based use cases can be written using existing > APIs, somewhat less conveniently and more verbosely; but these constructs > are much more explicit and so are preferable to the APIs to be deprecated. > The deprecation text should steer people toward the preferred constructs. > > It would indeed be nice to have a file extension API, but this has been > discussed several times and has run aground each time for a variety of > reasons. Tying these together will hold up the deprecation for no good > reason. > > Let's proceed with just the deprecation first and work on the file > extension API separately. > > s'marks > On 1/11/26 12:45 PM, David Alayachew wrote: > > Thanks for the response Anthony. Messages have been arriving out-of-order > for me, so I didn't see yours at the time of me writing that message. > > I think introducing the file extension API first, then gauging the need > for a deprecation before doing it is fine. Sounds like then that we are > universally agreed on the first step being to add the file extension API, > yes? > > On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe < > anthonyv.be at outlook.com> wrote: > >> I dissent. (Apparently my previous message wasn't clear.) >> >> The right order of things is to first introduce a file extension API. >> Then see if there's still complaints about `Path::endsWith(String)`. And >> only then, if there are, consider taking action. >> >> In my previous message I've already explained how these methods add real, >> tangible value and actually are intuitive. >> (Again, ask developers to guess how `A::foo(B)` behaves, given that both >> `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will >> intuitively guess it converts its `b` argument to an instance of `A` and >> passes it on to `A::foo(A)`. And their intuition would be correct in the >> case of `Path::endsWith(String)`. That being said, I'll be the first to >> admit that I've also made the mistake of attempting to use >> `Path::endsWith(String)` to test the file extension.) >> >> In hindsight, maybe `endsWithNames(String)` would've been a better >> choice, but hindsight is 20/20. >> >> Deprecating these methods now is premature. And deprecating them without >> replacement methods would result in way more complaints than there have >> ever been about `endsWith(String)`. >> >> Anthony >> On 1/11/2026 12:19 AM, David Alayachew wrote: >> >> Of course. >> >> I see lots of approvals and not really any dissenters. Are we waiting for >> more responses? Or is there anything we can do to kick start this? >> >> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter < >> brian.burkhalter at oracle.com> wrote: >> >>> Thanks for the corroboration. >>> >>> On Jan 8, 2026, at 1:50?PM, David Alayachew >>> wrote: >>> >>> Thanks for reviving this. >>> >>> I am perfectly happy with the idea of deprecating the >>> Path.{start,ends}With(String), and then only add the file extension method. >>> Originally, I didn't know that new method was on the table, so I suggested >>> a rename. But the file extension api feels like the superior solution. >>> >>> 10 times out of 10, if I am calling endsWith, the only time I am not >>> looking for "whole" path elements is when I am looking for a file >>> extension. In every other instance, the api does exactly what I expect and >>> want. And plus, something like looking for a file extension is better off >>> being explicit. >>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From cushon at openjdk.org Mon Jan 12 21:55:55 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 12 Jan 2026 21:55:55 GMT Subject: RFR: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 Message-ID: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Please consider this fix for JDK-8375066, which adds missing `@since 27` tags to methods added in [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8369564). ------------- Commit messages: - 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 Changes: https://git.openjdk.org/jdk/pull/29179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375066 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29179/head:pull/29179 PR: https://git.openjdk.org/jdk/pull/29179 From cushon at openjdk.org Mon Jan 12 21:56:49 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 12 Jan 2026 21:56:49 GMT Subject: RFR: 8369564: Provide a MemorySegment API to read strings with known lengths [v17] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 21:29:23 GMT, David Holmes wrote: > This change broke the SinceChecker test: [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8375066) Sorry for missing that, I have mailed a fix: https://github.com/openjdk/jdk/pull/29179 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28043#issuecomment-3740665666 From dgredler at openjdk.org Mon Jan 12 22:20:45 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Mon, 12 Jan 2026 22:20:45 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected Message-ID: ByteArrayOutputStream.ensureCapacity(int) is currently private. It would be useful if it were protected, so that it can be more easily extended by subclasses. Mailing list discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/156983.html ------------- Commit messages: - Make ByteArrayOutputStream.ensureCapacity(int) protected Changes: https://git.openjdk.org/jdk/pull/29180/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29180&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374610 Stats: 129 lines in 2 files changed: 122 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29180/head:pull/29180 PR: https://git.openjdk.org/jdk/pull/29180 From jwilhelm at openjdk.org Mon Jan 12 22:50:01 2026 From: jwilhelm at openjdk.org (Jesper Wilhelmsson) Date: Mon, 12 Jan 2026 22:50:01 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Marked as reviewed by jwilhelm (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28954#pullrequestreview-3653025338 From duke at openjdk.org Mon Jan 12 23:57:29 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 12 Jan 2026 23:57:29 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line What you're suggesting is closer to my original change. See what I undid in: https://github.com/openjdk/jdk/pull/28456/changes/aa40f0c711cf5c02a243bda01d2e2d40d4b2b352 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3741049157 From almatvee at openjdk.org Tue Jan 13 00:05:18 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Jan 2026 00:05:18 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: On Mon, 12 Jan 2026 19:03:25 GMT, Alexey Semenyuk wrote: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29175#pullrequestreview-3653196424 From almatvee at openjdk.org Tue Jan 13 01:19:24 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Jan 2026 01:19:24 GMT Subject: RFR: 8375054: Removed "signed" property from jpackage app image file In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 17:08:17 GMT, Alexey Semenyuk wrote: > $subj > > Additionally: > - Validate that the value of the "--app-image" option on macOS is a valid macOS bundle, and if it is not, exit with a new "error.parameter-not-mac-bundle" error. > - Read stdout of "/usr/bin/codesign" and "/usr/sbin/spctl" commands outputing plist XML as binary, and not as text. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29173#pullrequestreview-3653374025 From jpai at openjdk.org Tue Jan 13 01:38:32 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 Jan 2026 01:38:32 GMT Subject: RFR: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 In-Reply-To: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> References: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Message-ID: On Mon, 12 Jan 2026 21:48:34 GMT, Liam Miller-Cushon wrote: > Please consider this fix for JDK-8375066, which adds missing `@since 27` tags to methods added in [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8369564). Hello Liam, this looks reasonable to me. Have you run tier2 after this change? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29179#pullrequestreview-3653414661 From rriggs at openjdk.org Tue Jan 13 01:56:50 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 01:56:50 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v4] 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into 8373913-serialfilter-to-junit - Refactored test parameter provider methods to be static. Removed the @TestInstance annotations. Added @Serial where it was missing. - Simplification of AssertThrows cases and changing success output to System.err to interleve with JUnit output. - Update to use Stream> for parameterized method testing. Add static to simplify test setup. Small source changes to remove "C" style array declarations. - Cleanup arglist and fix code style - JDK-8373913: Refactor serialization tests tests to use JUnit Automated conversion for most annotations. Conditional tests are refactored to use JUnit Enable/DisableIf. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28877/files - new: https://git.openjdk.org/jdk/pull/28877/files/cc9a66bc..894b61b8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=02-03 Stats: 32398 lines in 2774 files changed: 10840 ins; 5580 del; 15978 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 almatvee at openjdk.org Tue Jan 13 02:37:18 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Jan 2026 02:37:18 GMT Subject: RFR: 8375050: Simplify process management in jpackage tests In-Reply-To: References: Message-ID: <2Xe26N8-1t3jLwmh-9Nw30QZL_omByYKuY3--aA5v_k=.754c88f3-7190-4660-905d-274c6bf4e0fa@github.com> On Mon, 12 Jan 2026 16:28:30 GMT, Alexey Semenyuk wrote: > Replace "taskkill" and powershell script managing child processes started by jpackage tests on Windows with `java.lang.Process` API. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29172#pullrequestreview-3653523755 From jpai at openjdk.org Tue Jan 13 06:35:01 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 Jan 2026 06:35:01 GMT Subject: RFR: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 In-Reply-To: References: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Message-ID: On Tue, 13 Jan 2026 01:34:42 GMT, Jaikiran Pai wrote: > Have you run tier2 after this change? FWIW, I ran tier1 and tier2 tests with these changes and they passed without any related issues. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29179#issuecomment-3742241855 From erfang at openjdk.org Tue Jan 13 06:41:11 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 13 Jan 2026 06:41:11 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: <5qAYM9-uEG4rKvjXvTECDSVKt5i77OVQJJKjaczas-c=.b8ade33e-009d-45b4-9510-104d828de08e@github.com> On Tue, 6 Jan 2026 00:53:04 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 eight commits: >> >> - Update copyright year to 2026 >> - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity >> - wrap the test loop within a try/catch to speed up the tests >> - Refine the tests for identity values >> - 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. > > This looks good. Before we integrate we will run it through our test system and report back to you. Hi @PaulSandoz , if you?ve already had a chance to run the tests, could you let me know how they turned out? Thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3742258650 From shade at openjdk.org Tue Jan 13 07:32:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 13 Jan 2026 07:32:41 GMT Subject: RFR: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 In-Reply-To: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> References: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Message-ID: On Mon, 12 Jan 2026 21:48:34 GMT, Liam Miller-Cushon wrote: > Please consider this fix for JDK-8375066, which adds missing `@since 27` tags to methods added in [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8369564). Marked as reviewed by shade (Reviewer). I assume you ran `SinceChecker` with this change and it now passes well? ------------- PR Review: https://git.openjdk.org/jdk/pull/29179#pullrequestreview-3654264064 PR Comment: https://git.openjdk.org/jdk/pull/29179#issuecomment-3742492231 From cushon at openjdk.org Tue Jan 13 07:55:04 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 13 Jan 2026 07:55:04 GMT Subject: RFR: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 In-Reply-To: References: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Message-ID: <2lvI8ywBHVvbp16IPiiZJpFSnzKvZOwvXJQrGo0BXs0=.31e4d3ee-780f-4c58-bbf1-001b5712a804@github.com> On Tue, 13 Jan 2026 06:31:21 GMT, Jaikiran Pai wrote: > FWIW, I ran tier1 and tier2 tests with these changes and they passed without any related issues. Thanks! > I assume you ran `SinceChecker` with this change and it now passes well? I had tested with `make test TEST="tools/sincechecker/modules/java.base/JavaBaseCheckSince.java"`, that passes with this change ------------- PR Comment: https://git.openjdk.org/jdk/pull/29179#issuecomment-3742604137 From cushon at openjdk.org Tue Jan 13 08:09:40 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 13 Jan 2026 08:09:40 GMT Subject: Integrated: 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 In-Reply-To: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> References: <5s3Abau1GyNEWMMtPAFlSNCji5zzK9Ut7CEvBafBiRY=.9617e28e-f534-400e-b982-e011ec9fbd09@github.com> Message-ID: <6hArsZ531phGvqH897Ls17IXQOGjfRoR9ORJmxtPYIU=.3823f46a-c5f1-40a7-a698-5d5dab61653c@github.com> On Mon, 12 Jan 2026 21:48:34 GMT, Liam Miller-Cushon wrote: > Please consider this fix for JDK-8375066, which adds missing `@since 27` tags to methods added in [JDK-8375066](https://bugs.openjdk.org/browse/JDK-8369564). This pull request has now been integrated. Changeset: d6f43d73 Author: Liam Miller-Cushon URL: https://git.openjdk.org/jdk/commit/d6f43d7329bf0ba08464f6d0a22de7e27ca8b399 Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod 8375066: Test tools/sincechecker/modules/java.base/JavaBaseCheckSince.java broken by JDK-8369564 Reviewed-by: jpai, shade ------------- PR: https://git.openjdk.org/jdk/pull/29179 From cushon at openjdk.org Tue Jan 13 08:21:31 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 13 Jan 2026 08:21:31 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset Message-ID: This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. --- Benchmark (encoding) (stringLength) Mode Cnt Score Error Units StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s StringLoopJmhBenchmark.getBytesLength LATIN1 100000 thrpt 5 1136360.285 ? 426475.121 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 10 thrpt 5 329508584.830 ? 6277534.933 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 100 thrpt 5 86396600.366 ? 4287569.267 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 1000 thrpt 5 10037994.564 ? 779239.446 ops/s StringLoopJmhBenchmark.getBytesLength UTF16 100000 thrpt 5 99218.929 ? 2854.843 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 10 thrpt 5 409066999.717 ? 25444799.130 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 100 thrpt 5 72126088.461 ? 42992009.452 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 1000 thrpt 5 8300806.448 ? 533912.423 ops/s StringLoopJmhBenchmark.utf8LenByLoop ASCII 100000 thrpt 5 87356.021 ? 7863.743 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 10 thrpt 5 356802960.574 ? 24814016.238 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 100 thrpt 5 85043539.617 ? 30538310.706 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 1000 thrpt 5 9952675.100 ? 2922230.486 ops/s StringLoopJmhBenchmark.utf8LenByLoop LATIN1 100000 thrpt 5 79410.881 ? 50777.786 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 10 thrpt 5 304196311.102 ? 20381571.060 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 100 thrpt 5 84223829.681 ? 10787815.139 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 1000 thrpt 5 11046224.275 ? 1200731.406 ops/s StringLoopJmhBenchmark.utf8LenByLoop UTF16 100000 thrpt 5 112590.802 ? 3741.019 ops/s ------------- Commit messages: - Whitespace - Apply suggestions from code review - 8372353: API to compute the byte length of a String encoded in a given Charset Changes: https://git.openjdk.org/jdk/pull/28454/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372353 Stats: 213 lines in 4 files changed: 213 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From duke at openjdk.org Tue Jan 13 08:21:33 2026 From: duke at openjdk.org (ExE Boss) Date: Tue, 13 Jan 2026 08:21:33 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset In-Reply-To: References: Message-ID: On Fri, 21 Nov 2025 14:58:55 GMT, Liam Miller-Cushon wrote: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... src/java.base/share/classes/java/lang/String.java line 2127: > 2125: * equivalent to this string, {@code false} otherwise > 2126: * > 2127: * @see #compareTo(String) For the?**BOM**?less **UTF?16**?charsets, this?can simply?return `value.length < 72: stringData += (char) (Math.random() * 26) + 'a'; > 73: } > 74: stringData += c; Maybe avoid?creating intermediate?strings in?a?loop to?avoid excess?GC?pressure? Suggestion: var stringDataBuilder = new StringBuilder(stringLength + 1); while (stringDataBuilder.length() < stringLength) { stringDataBuilder.append((char) (Math.random() * 26) + 'a'); } stringData = stringDataBuilder.append(c).toString(); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2552768341 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2552801055 From cushon at openjdk.org Tue Jan 13 08:21:34 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 13 Jan 2026 08:21:34 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset In-Reply-To: References: Message-ID: On Sat, 22 Nov 2025 09:37:31 GMT, ExE Boss wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > src/java.base/share/classes/java/lang/String.java line 2127: > >> 2125: * equivalent to this string, {@code false} otherwise >> 2126: * >> 2127: * @see #compareTo(String) > > For the?**BOM**?less **UTF?16**?charsets, this?can simply?return `value.length < > Suggestion: > > if (cs instanceof sun.nio.cs.UTF_16LE || > cs instanceof sun.nio.cs.UTF_16BE) { > return value.length << (1 - coder()); > } > return getBytes(cs).length; > > > [^1]: Lone?surrogates get?replaced with?`U+FFFD` when?encoding to?**UTF?16** by?[`String?::getBytes?(Charset)`], and?all?of?**LATIN1** can?be?encoded in?**UTF?16**. > > [`String?::getBytes?(Charset)`]: https://docs.oracle.com/en/java/javase/25/docs/api/java.base/java/lang/String.html#getBytes(java.nio.charset.Charset) Thanks! There is more work that could be done for other charsets here, I focused on UTF-8 and the bytesCompatible case as a proof of concept, and as a way to start discussing this. It may or may not make sense to have optimized paths for all of the other standard charsets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2556171650 From alanb at openjdk.org Tue Jan 13 08:21:47 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 08:21:47 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:13:06 GMT, Daniel Gredler wrote: > ByteArrayOutputStream.ensureCapacity(int) is currently private. It would be useful if it were protected, so that it can be more easily extended by subclasses. > > Mailing list discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/156983.html Subclasses have access to the protected buf/count fields so it's not clear that there is a strong case for adding this. I think it would be useful to hear more on how this might be used. BAOS is more of an implementation class, is extending it the right thing for the examples that you have in mind? Is the issue more about trying to size a byte[] that is close to the MAX_VALUE limit? What is the reason that the existing methods are not re-specified to use it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3742748336 From alanb at openjdk.org Tue Jan 13 08:32:42 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 08:32:42 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v3] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Mon, 12 Jan 2026 19:55:21 GMT, Roger Riggs wrote: >> test/jdk/java/io/Serializable/serialFilter/CheckArrayTest.java line 55: >> >>> 53: * The filterCheck must be resilent to an InputStream not being available (only the subclass knows). >>> 54: */ >>> 55: @TestInstance(TestInstance.Lifecycle.PER_CLASS) >> >> Looks like 9 other tests are using PER_CLASS, is that because of setup methods and method sources that are instance rather than static methods? > > The helpful conversion tool added PER_CLASS, I assume due to the source methods were instance method. Use of PER_CLASS does not seem to be discouraged. If the test were written afresh as a JUnit test then I assume the method sources would be static methods that return a Stream of arguments. I didn't know it was a tool that was adding PER_CLASS, in which case I assume okay to do another cleanup pass for issues like this. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2685378716 From jbhateja at openjdk.org Tue Jan 13 09:48:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v10] 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 26 commits: - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - 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 - ... and 16 more: https://git.openjdk.org/jdk/compare/7e18de13...14861d5e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 515469 lines in 232 files changed: 284458 ins; 229216 del; 1795 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 Jan 13 09:48:50 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:48:50 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> References: <3PzPbEnPapV-B3OenjmG6paXsyLFayh33S-f0IBI-LY=.773757f6-c9e0-48ac-b89d-aa81fd6b47f8@github.com> Message-ID: <212JnoGQ5FDIEHJMmZ2zFLxmM4BCjqrnFyuZ6CqeZ-c=.cfa4503a-e6da-401b-95b4-f3c384d12e3f@github.com> On Wed, 7 Jan 2026 19:29:03 GMT, Paul Sandoz wrote: >> 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 > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 436: > >> 434: } else { >> 435: assert(Float16.valueOf(i).intValue() == i); >> 436: } > > It would be clearer if the same pattern is copied as for the other types. Assign and assert, no need to check bounds. We don't need to be performant here. (This code may become even clearer when we can leverage patterns on the primitive types and custom numeric types.) Done > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorShape.java line 277: > >> 275: if (etype == Float16.class) { >> 276: etype = short.class; >> 277: } > > My suggestion may not worth it, but i was wondering if we could get the lane type and then use the carrier type, rather then encoding this more specifically. Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649510 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685649160 From jbhateja at openjdk.org Tue Jan 13 09:58:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 13 Jan 2026 09:58:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] 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: Adding testpoint for JDK-8373574 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/14861d5e..d1043144 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=09-10 Stats: 113 lines in 1 file changed: 113 ins; 0 del; 0 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 fyang at openjdk.org Tue Jan 13 10:14:33 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:14:33 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: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> On Wed, 7 Jan 2026 09:03:03 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/Float16Vector64Tests.java line 1893: >> >>> 1891: VectorMask m = three.compare(VectorOperators.LE, higher); >>> 1892: assert(m.allTrue()); >>> 1893: m = higher.min((short)-1).test(VectorOperators.IS_NEGATIVE); >> >> I find that `higher.min((short)-1)` produces a float16 vector of 4 NaNs. So are we testing for negative NaNs with `VectorOperators.IS_NEGATIVE`? Is it more reasonable to test `VectorOperators.IS_NAN` instead? > > Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. Maybe we should fix them as well? test/jdk/jdk/incubator/vector/FloatVector256Tests.java test/jdk/jdk/incubator/vector/FloatVector128Tests.java test/jdk/jdk/incubator/vector/FloatVector64Tests.java test/jdk/jdk/incubator/vector/FloatVector512Tests.java test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java test/jdk/jdk/incubator/vector/DoubleVector128Tests.java test/jdk/jdk/incubator/vector/DoubleVector64Tests.java test/jdk/jdk/incubator/vector/DoubleVector256Tests.java test/jdk/jdk/incubator/vector/DoubleVector512Tests.java test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685722818 From fyang at openjdk.org Tue Jan 13 10:18:46 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:18:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v9] In-Reply-To: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> References: <8tmcHaaICcnQ5AjwdCe334bxoA3cIJ3IhqWexblRgkM=.6ffed558-f343-4072-a38b-ee7f5d292373@github.com> Message-ID: On Tue, 13 Jan 2026 10:10:40 GMT, Fei Yang wrote: >> Thanks for catching this, all the Float16Vector lanes and short argument passed to shorthand APIs are assumed to be encoded in IEEE 754 binary 16 format, we should be passing Float16 bit representation of -1 here. > > Thanks for confirming this. And I see similar occurrences in Float / Double varients of the tests. > Maybe we should fix them as well? > > > test/jdk/jdk/incubator/vector/FloatVector256Tests.java > test/jdk/jdk/incubator/vector/FloatVector128Tests.java > test/jdk/jdk/incubator/vector/FloatVector64Tests.java > test/jdk/jdk/incubator/vector/FloatVector512Tests.java > test/jdk/jdk/incubator/vector/FloatVectorMaxTests.java > > test/jdk/jdk/incubator/vector/DoubleVector128Tests.java > test/jdk/jdk/incubator/vector/DoubleVector64Tests.java > test/jdk/jdk/incubator/vector/DoubleVector256Tests.java > test/jdk/jdk/incubator/vector/DoubleVector512Tests.java > test/jdk/jdk/incubator/vector/DoubleVectorMaxTests.java Ah, that doesn't seem necessary after another look. Float16 is special here. So please ignore my comment. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685745615 From fyang at openjdk.org Tue Jan 13 10:27:39 2026 From: fyang at openjdk.org (Fei Yang) Date: Tue, 13 Jan 2026 10:27:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:58:29 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: > > Adding testpoint for JDK-8373574 src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > 1651: * > 1652: * @param e the input scalar > 1653: * @return the result of multiplying this vector by the given scalar The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1694: > 1692: * > 1693: * @param e the input scalar > 1694: * @return the result of multiplying this vector by the given scalar Similar question here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685766276 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2685767490 From dgredler at openjdk.org Tue Jan 13 11:02:35 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Tue, 13 Jan 2026 11:02:35 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 08:18:58 GMT, Alan Bateman wrote: > it would be useful to hear more on how this might be used As an example, imagine a subclass which wants to add a fast `writeLong` method. With `ensureCapacity` available, this is as simple as: public class LongStream extends ByteArrayOutputStream { private static final VarHandle LONG = MethodHandles.byteArrayViewVarHandle(long[].class, BIG_ENDIAN); public void writeLong(long value) { ensureCapacity(count + 8); LONG.set(buf, count, value); count += 8; } } Without access to `ensureCapacity`, having access only to the buffer and the count, the same class must copy the `ensureCapacity` logic, which means that it must also copy the `ArraysSupport.newLength` logic: public class LongStream2 extends ByteArrayOutputStream { private static final VarHandle LONG = MethodHandles.byteArrayViewVarHandle(long[].class, BIG_ENDIAN); public void writeLong(long value) { ensureCapacity(count + 8); LONG.set(buf, count, value); count += 8; } // **************** copied from ByteArrayOutputStream **************** private void ensureCapacity(int minCapacity) { // overflow-conscious code int oldCapacity = buf.length; int minGrowth = minCapacity - oldCapacity; if (minGrowth > 0) { buf = Arrays.copyOf(buf, /*ArraysSupport.*/newLength(oldCapacity, minGrowth, oldCapacity /* preferred growth */)); } } // ******************** copied from ArraysSupport ******************** private static final int SOFT_MAX_ARRAY_LENGTH = Integer.MAX_VALUE - 8; private static int newLength(int oldLength, int minGrowth, int prefGrowth) { // preconditions not checked because of inlining // assert oldLength >= 0 // assert minGrowth > 0 int prefLength = oldLength + Math.max(minGrowth, prefGrowth); // might overflow if (0 < prefLength && prefLength <= SOFT_MAX_ARRAY_LENGTH) { return prefLength; } else { // put code cold in a separate method return hugeLength(oldLength, minGrowth); } } private static int hugeLength(int oldLength, int minGrowth) { int minLength = oldLength + minGrowth; if (minLength < 0) { // overflow throw new OutOfMemoryError( "Required array length " + oldLength + " + " + minGrowth + " is too large"); } else if (minLength <= SOFT_MAX_ARRAY_LENGTH) { return SOFT_MAX_ARRAY_LENGTH; } else { return minLength; } } } ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3743690145 From duke at openjdk.org Tue Jan 13 11:39:13 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 11:39:13 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Thu, 18 Dec 2025 13:52:44 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 ... > > 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. Hi @theRealAph, > But if we choose the split between CB offset and oopmap index wisely, we can avoid using a second instruction most of the time. > Something else to bear in mind is that we don't always have to succeed placing a post-call NOP. They are not used as frequently as they were in the past, in particular because we found a way to save and restore virtual thread stacks without usually having to trace them. In practice this means that we only have to copy the stack memory, so we don't need the post-call NOPs so often. I believe we can avoid the second instruction with the following approach: - where possible, fully store cb_offset and oopmap_index and use MOVZ/MOVK - where not possible, use MOVN and store partial cb_offset and oopmap_index. The partial cb_offset and oopmap_index values will make search for the respective metadata faster, compared to searching just based on the PC value. >From an initial experiment, is appears oopmap_index increments about every 8 instructions on average - though this observation might be specific to a certain workload. However, if that's the case, current implementation allows us to encode post-call NOPs metadata for offsets up to 8K. The above approach would be an improvement in this case: the MOVK/MOVZ-based chunks would allow us to encode the metadata for offsets up to 16K, while MOVN-based chunks would improve search for the rest of the cases. What do you think about this option? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3743848408 From asemenyuk at openjdk.org Tue Jan 13 13:36:02 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 13:36:02 GMT Subject: Integrated: 8375054: Removed "signed" property from jpackage app image file In-Reply-To: References: Message-ID: <__XcrgasmioUex6usnUK7lEH6n7ujQOO00hHPmnBCxM=.cba81512-563c-4252-b293-c698f65377f6@github.com> On Mon, 12 Jan 2026 17:08:17 GMT, Alexey Semenyuk wrote: > $subj > > Additionally: > - Validate that the value of the "--app-image" option on macOS is a valid macOS bundle, and if it is not, exit with a new "error.parameter-not-mac-bundle" error. > - Read stdout of "/usr/bin/codesign" and "/usr/sbin/spctl" commands outputing plist XML as binary, and not as text. This pull request has now been integrated. Changeset: f7be1dcf Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/f7be1dcf296d28f8e004d180038ab715153a6c15 Stats: 627 lines in 21 files changed: 371 ins; 182 del; 74 mod 8375054: Removed "signed" property from jpackage app image file Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29173 From alanb at openjdk.org Tue Jan 13 13:37:01 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 13:37:01 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: <91d59UGVSRq_W48DHEwoCkSOU8dRtwXCLph7WpL0mQg=.6cd4772d-c132-4319-a853-5e32233eafda@github.com> On Mon, 12 Jan 2026 23:53:03 GMT, David Beaumont wrote: > What you're suggesting is closer to my original change. I didn't see the original change but from a quick scan now, then it does look better in that it avoids BasicImageReader needing any reference to the jimage tool. It doesn't help with Roger's suggestion on using the runtime or class file version but I think would be harder to do because of how this gets built. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3744369033 From asemenyuk at openjdk.org Tue Jan 13 13:39:58 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 13:39:58 GMT Subject: Integrated: 8375050: Simplify process management in jpackage tests In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 16:28:30 GMT, Alexey Semenyuk wrote: > Replace "taskkill" and powershell script managing child processes started by jpackage tests on Windows with `java.lang.Process` API. This pull request has now been integrated. Changeset: 47029ccf Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/47029ccfec988e0a9298e35dcc729d9eeffc45e1 Stats: 238 lines in 8 files changed: 67 ins; 126 del; 45 mod 8375050: Simplify process management in jpackage tests Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29172 From alanb at openjdk.org Tue Jan 13 15:11:15 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 15:11:15 GMT Subject: [jdk26] RFR: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks Message-ID: This PR is for the jdk26 branch, not main line. The changes in [JDK-8360046](https://bugs.openjdk.org/browse/JDK-8360046) improve the scalability of virtual threads but introduce a subtle issue with signal filtering and a regression in some SPECjbb2015 runs. [pull/28797](https://git.openjdk.org/jdk/pull/28797) is in progress for main line to address these issues. For the jdk26 branch, the proposal is to backout the changes to ForkJoinPool from JDK-8360046 but leave the small change to VirtualThread to submit(ForkJoinTask) consistently. As part of the change, the acquire fence change to address [JDK-8372835](https://bugs.openjdk.org/browse/JDK-8372835) are proposed to be included, to avoid bringing back an issue that was fixed by JDK-8360046. So a somewhat complicated story due to jdk26 being in RDP1. Testing: test1-5, repeat testing of java/util/concurrent and java/lang/Thread/virtual tests. ------------- Commit messages: - Backout JDK-8360046, incorporate JDK-8372835 Changes: https://git.openjdk.org/jdk/pull/29187/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29187&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375130 Stats: 470 lines in 2 files changed: 143 ins; 143 del; 184 mod Patch: https://git.openjdk.org/jdk/pull/29187.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29187/head:pull/29187 PR: https://git.openjdk.org/jdk/pull/29187 From alanb at openjdk.org Tue Jan 13 15:16:06 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 15:16:06 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 11:00:26 GMT, Daniel Gredler wrote: > > it would be useful to hear more on how this might be used > > As an example, imagine a subclass which wants to add a fast `writeLong` method. With `ensureCapacity` available, this is as simple as: Is your real concern with buf.length getting close to Integer.MAX_VALUE? Aside from writeLong, could you list out the methods that you've since in BAOS subclasses. I'm wondering if BAOS should implement some of the methods defined by DataOutput to avoid needing to subclass (as BAOS is more of an implementation class). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3744887083 From duke at openjdk.org Tue Jan 13 15:52:48 2026 From: duke at openjdk.org (Benjamin Peterson) Date: Tue, 13 Jan 2026 15:52:48 GMT Subject: RFR: 8348828: Windows dll loading now resolves symlinks [v10] In-Reply-To: References: Message-ID: <7n2dAGnAuj_JvE7hpe9o9-0qqsrJabpynqXIbiG5C8M=.765d9e72-9a35-4922-993d-6d601fc34582@github.com> On Mon, 15 Dec 2025 17:31:20 GMT, Benjamin Peterson wrote: >> 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 Any security progress in the new year? ------------- PR Comment: https://git.openjdk.org/jdk/pull/24694#issuecomment-3745080385 From duke at openjdk.org Tue Jan 13 15:54:23 2026 From: duke at openjdk.org (Ruben) Date: Tue, 13 Jan 2026 15:54:23 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: >> 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 ... > > 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? Hi @iwanowww, Bhavana will be unavailable for some time, so I am coordinating the next steps and someone from our team will be taking over this PR. Thanks again for offering to finalize the libsimdsort FFM PR and post it for review. Do you have an estimate for when you expect to open it? We would like to plan the next update of the SVE Arrays.sort PR on top of it, so knowing an approximate timeline (and whether there is anything you would suggest we prepare in the meantime) would help. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3745085496 From vklang at openjdk.org Tue Jan 13 15:54:26 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 Jan 2026 15:54:26 GMT Subject: [jdk26] RFR: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:22:14 GMT, Alan Bateman wrote: > This PR is for the jdk26 branch, not main line. > > The changes in [JDK-8360046](https://bugs.openjdk.org/browse/JDK-8360046) improve the scalability of virtual threads but introduce a subtle issue with signal filtering and a regression in some SPECjbb2015 runs. [pull/28797](https://git.openjdk.org/jdk/pull/28797) is in progress for main line to address these issues. > > For the jdk26 branch, the proposal is to backout the changes to ForkJoinPool from JDK-8360046 but leave the small change to VirtualThread to submit(ForkJoinTask) consistently. As part of the change, the acquire fence change to address [JDK-8372835](https://bugs.openjdk.org/browse/JDK-8372835) are proposed to be included, to avoid bringing back an issue that was fixed by JDK-8360046. So a somewhat complicated story due to jdk26 being in RDP1. > > > Testing: test1-5, repeat testing of java/util/concurrent and java/lang/Thread/virtual tests. Thanks Alan! ------------- Marked as reviewed by vklang (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29187#pullrequestreview-3656531482 From vklang at openjdk.org Tue Jan 13 16:03:39 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 Jan 2026 16:03:39 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v25] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Mon, 12 Jan 2026 17:44:22 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: > > Fix missing undo src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2591: > 2589: unlockRunState(); > 2590: } > 2591: ForkJoinTask[] a; `a` is not used src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2593: > 2591: ForkJoinTask[] a; > 2592: if (q != null && (lock = q.tryLockPhase()) != 1) { > 2593: int unlock = lock + NEXTIDLE; Suggestion: int unlock = lock + NEXTIDLE; ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2687038807 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2687040332 From rriggs at openjdk.org Tue Jan 13 16:10:06 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 16:10:06 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line Lets go back to a simple update to the message. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3745145839 From duke at openjdk.org Tue Jan 13 16:19:36 2026 From: duke at openjdk.org (David Beaumont) Date: Tue, 13 Jan 2026 16:19:36 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: <30K5z_ofUX8WnbUjDD-ArEIy_6Cx2JfQ6vT7nwMXt24=.bea66dbc-7b0d-4b95-8471-7337f7db31f6@github.com> On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line When you say "back to", do you mean what's in the current commit? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3745215553 From vklang at openjdk.org Tue Jan 13 16:19:38 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 13 Jan 2026 16:19:38 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v25] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Mon, 12 Jan 2026 17:44:22 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: > > Fix missing undo src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2604: > 2602: throw new RejectedExecutionException(); > 2603: } > 2604: private void poolSubmit(ForkJoinTask task, boolean signalIfEmpty) { Suggestion: private void poolSubmit(ForkJoinTask task, boolean signalIfEmpty) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2687114914 From asemenyuk at openjdk.org Tue Jan 13 16:31:44 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 16:31:44 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config [v2] In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits: - Fix JPackageCommand.isWithToolProvider(); support using a custom jpackage tool provider with JPackageCommand instance in addition to existing support to alter the default jpackage tool provider; Add corresponding unit test. - Merge branch 'master' into AsyncTest-better-output - Update copyright year - Log: fix the bug revealed by AsyncTest that log messages from all jpackage instances go into the log streams of the last started jpackage instead of going in log streams associated with these jpackage instances. - Use ScopedValue - JUnitAdapter: fix charset - cli/Main: fix charsets when converting from PrintStream to PrintWriter - Simplify TKit; make AsyncTest properly collect test cases logs ------------- Changes: https://git.openjdk.org/jdk/pull/29175/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29175&range=01 Stats: 690 lines in 14 files changed: 386 ins; 162 del; 142 mod Patch: https://git.openjdk.org/jdk/pull/29175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29175/head:pull/29175 PR: https://git.openjdk.org/jdk/pull/29175 From asemenyuk at openjdk.org Tue Jan 13 16:31:45 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 16:31:45 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: On Mon, 12 Jan 2026 19:03:25 GMT, Alexey Semenyuk wrote: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. Resolved merge conflict. Fixed a regression in `JPackageCommand.isWithToolProvider()` and added a corresponding unit test. @sashamatveev, please review again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29175#issuecomment-3745266129 From asemenyuk at openjdk.org Tue Jan 13 16:37:44 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 16:37:44 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config [v3] In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: BasicTest: rollback accidental change. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29175/files - new: https://git.openjdk.org/jdk/pull/29175/files/2d32616c..5c56b928 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29175&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29175&range=01-02 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29175.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29175/head:pull/29175 PR: https://git.openjdk.org/jdk/pull/29175 From jpai at openjdk.org Tue Jan 13 17:10:01 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 13 Jan 2026 17:10:01 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v2] In-Reply-To: References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: <33aEcRuNDsP8vuSWkU-Ih-UOu5U0occIVIfEPW_W9RE=.0947ee49-c0f4-40ae-8fa7-1e44729c797f@github.com> On Mon, 12 Jan 2026 20:51:51 GMT, Roger Riggs wrote: >> On Linux and Mac, when a process is started, pipes are created to communicate with the child. >> In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. >> >> Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. >> Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) >> Converted PipelineLeaksFD test to JUnit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactored invocation of `lsof` to not use pipes for I/O, using files instead. > It removes the possibility of side effects that might affect the checking of pipe usage. Hello Roger, given what's explained in the JBS issue, this change looks reasonable to me. I just have one test related comment which I've added inline. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 54: > 52: * @requires os.family == "mac" | (os.family == "linux" & !vm.musl) > 53: * @summary File descriptor leak detection with ProcessBuilder.startPipeline > 54: * @run junit/othervm -Xint PipelineLeaksFD Is there something in this test (or even `java.lang.Process`) that makes running this test in interpreted mode a necessity? ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29143#pullrequestreview-3656896789 PR Review Comment: https://git.openjdk.org/jdk/pull/29143#discussion_r2687310909 From jlu at openjdk.org Tue Jan 13 17:36:43 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jan 2026 17:36:43 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v4] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Tue, 13 Jan 2026 01:56:50 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - Merge branch 'master' into 8373913-serialfilter-to-junit > - Refactored test parameter provider methods to be static. > Removed the @TestInstance annotations. > Added @Serial where it was missing. > - Simplification of AssertThrows cases and changing success output to System.err to interleve with JUnit output. > - Update to use Stream> for parameterized method testing. > Add static to simplify test setup. > Small source changes to remove "C" style array declarations. > - Cleanup arglist and fix code style > - JDK-8373913: Refactor serialization tests tests to use JUnit > Automated conversion for most annotations. > Conditional tests are refactored to use JUnit Enable/DisableIf. test/jdk/java/io/Serializable/records/RecordClassTest.java line 53: > 51: * Serializes and deserializes record classes. Ensures that the SUID is 0. > 52: */ > 53: @TestInstance(TestInstance.Lifecycle.PER_CLASS) If we want to remove the class instance lifecycle here as well, should we make `notSerRecordClasses()` static? test/jdk/java/io/Serializable/serialFilter/SerialFactoryFaults.java line 78: > 76: > 77: if (factoryName.equals("ForcedError_NoSuchClass")) { > 78: Assertions.assertEquals( "invalid jdk.serialFilterFactory: ForcedError_NoSuchClass: java.lang.ClassNotFoundException: ForcedError_NoSuchClass", msg, "wrong exception"); I think some of the white space issues which were left from the tool, pointed out by @turbanoff earlier, still exist. test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java line 399: > 397: @ParameterizedTest > 398: @MethodSource("invalidLimits") > 399: @MethodSource("invalidLimits") Duplicate method source added by accident? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2687379883 PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2687383790 PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2687387168 From psandoz at openjdk.org Tue Jan 13 17:39:42 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 13 Jan 2026 17:39:42 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:11:19 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 eight commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - wrap the test loop within a try/catch to speed up the tests > - Refine the tests for identity values > - 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. Marked as reviewed by psandoz (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28692#pullrequestreview-3657045842 From psandoz at openjdk.org Tue Jan 13 17:39:44 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 13 Jan 2026 17:39:44 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Tue, 6 Jan 2026 00:53:04 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 eight commits: >> >> - Update copyright year to 2026 >> - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity >> - wrap the test loop within a try/catch to speed up the tests >> - Refine the tests for identity values >> - 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. > > This looks good. Before we integrate we will run it through our test system and report back to you. > Hi @PaulSandoz , if you?ve already had a chance to run the tests, could you let me know how they turned out? Thanks~ Yes, all good! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3745582478 From rriggs at openjdk.org Tue Jan 13 17:48:50 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 17:48:50 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v2] In-Reply-To: <33aEcRuNDsP8vuSWkU-Ih-UOu5U0occIVIfEPW_W9RE=.0947ee49-c0f4-40ae-8fa7-1e44729c797f@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> <33aEcRuNDsP8vuSWkU-Ih-UOu5U0occIVIfEPW_W9RE=.0947ee49-c0f4-40ae-8fa7-1e44729c797f@github.com> Message-ID: <00TiNvCqxljp_MCokbgVvs_H6pLMJRegAysin__jc3c=.f21b913b-0114-4606-9e26-793f668b2adf@github.com> On Tue, 13 Jan 2026 17:06:56 GMT, Jaikiran Pai wrote: >> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: >> >> Refactored invocation of `lsof` to not use pipes for I/O, using files instead. >> It removes the possibility of side effects that might affect the checking of pipe usage. > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 54: > >> 52: * @requires os.family == "mac" | (os.family == "linux" & !vm.musl) >> 53: * @summary File descriptor leak detection with ProcessBuilder.startPipeline >> 54: * @run junit/othervm -Xint PipelineLeaksFD > > Is there something in this test (or even `java.lang.Process`) that makes running this test in interpreted mode a necessity? There was some question when the test was first introduced about failures due to races. I'll remove that extra run and re-test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29143#discussion_r2687448066 From rriggs at openjdk.org Tue Jan 13 18:00:23 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 18:00:23 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v5] 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: Review suggestions to remove extra spaces, duplicate annotation, and the last remaining use of PER_CLASS. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28877/files - new: https://git.openjdk.org/jdk/pull/28877/files/894b61b8..0d36b13a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28877&range=03-04 Stats: 7 lines in 3 files changed: 0 ins; 2 del; 5 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 jlahoda at openjdk.org Tue Jan 13 18:13:32 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Tue, 13 Jan 2026 18:13:32 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases Message-ID: The `SwitchBootstraps.enumSwitch` is documented to throw a `NullPointerException` when `lookup` is `null`, but it does not throw the exception in all cases. Given the `lookup` is in some cases required, the proposal herein is to properly check `lookup` is not `null`. And while doing that, I added similar checks for `invocationType` and `labels` - those were checked implicitly, but doing the check explicitly is better. Note `invocationName` is unused and is permitted to be `null`, and hence there's no check for it. Please also review the CSR: https://bugs.openjdk.org/browse/JDK-8375120 ------------- Commit messages: - Cleanup. - 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases Changes: https://git.openjdk.org/jdk/pull/29202/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29202&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375119 Stats: 41 lines in 2 files changed: 35 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29202.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29202/head:pull/29202 PR: https://git.openjdk.org/jdk/pull/29202 From iklam at openjdk.org Tue Jan 13 18:33:29 2026 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 Jan 2026 18:33:29 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows Message-ID: The bug is here on line 121: https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. ------------- Commit messages: - 8366736: Closed System.out causes child process to hang on Windows Changes: https://git.openjdk.org/jdk/pull/29198/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8366736 Stats: 105 lines in 2 files changed: 100 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From iklam at openjdk.org Tue Jan 13 18:33:30 2026 From: iklam at openjdk.org (Ioi Lam) Date: Tue, 13 Jan 2026 18:33:30 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 16:52:36 GMT, Ioi Lam wrote: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout after the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > ### Progress > * [ ] Change must be properly reviewed (1 review required, with at least 1 [Reviewer](https://openjdk.org/bylaws#reviewer)) > * [x] Change must not contain extraneous whitespace > * [x] Commit message must refer to an issue > > ### Issue > * [JDK-8366736](https://bugs.openjdk.org/browse/JDK-8366736): Closed System.out causes child process to hang on Windows (**Bug** - P4) > > ### Reviewing > Using `git` > Checkout this PR locally: `$ git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198` `$ git checkout pull/29198` > > Update a local copy of the PR: `$ git checkout pull/29198` `$ git pull https://git.openjdk.org/jdk.git pull/29198/head` > > Using Skara CLI tools > Checkout this PR locally: `$ git pr checkout 29198` > > View PR using the GUI difftool: `$ git pr show -t 29198` > > Using diff file ------------- PR Comment: https://git.openjdk.org/jdk/pull/29198#issuecomment-3745764159 From bchristi at openjdk.org Tue Jan 13 18:46:21 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 13 Jan 2026 18:46:21 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode [v3] In-Reply-To: References: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> Message-ID: On Thu, 8 Jan 2026 22:07:33 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 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 @requires test.thread.factory instead of problem listing > - Merge branch 'master' into probList > - Change ProblemList bugid to 8309303 > - add VM/RuntimeArguments.java to ProblemList-Virtual.txt Are we good? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28935#issuecomment-3745831771 From jlu at openjdk.org Tue Jan 13 18:58:17 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jan 2026 18:58:17 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v5] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Tue, 13 Jan 2026 18:00:23 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: > > Review suggestions to remove extra spaces, duplicate annotation, and > the last remaining use of PER_CLASS. LGTM ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28877#pullrequestreview-3657340540 From alanb at openjdk.org Tue Jan 13 19:03:46 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 13 Jan 2026 19:03:46 GMT Subject: RFR: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode [v3] In-Reply-To: References: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> Message-ID: On Thu, 8 Jan 2026 22:07:33 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 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 @requires test.thread.factory instead of problem listing > - Merge branch 'master' into probList > - Change ProblemList bugid to 8309303 > - add VM/RuntimeArguments.java to ProblemList-Virtual.txt Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28935#pullrequestreview-3657367056 From bchristi at openjdk.org Tue Jan 13 19:51:20 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 13 Jan 2026 19:51:20 GMT Subject: Integrated: 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode In-Reply-To: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> References: <2a2-PeiWyJWI9I5GCWGBajOPtbZ2xWA7q7Vxx6cbQK4=.1a47be52-2707-4293-b1f6-95a9a7f61329@github.com> Message-ID: On Fri, 19 Dec 2025 20:22:10 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. This pull request has now been integrated. Changeset: 4d0ad0a4 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/4d0ad0a4a391286c683ebb8c8d711ea0be68c31a Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8373718: jdk/internal/misc/VM/RuntimeArguments.java test fails in Virtual threads mode Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/28935 From anthonyv.be at outlook.com Tue Jan 13 20:13:40 2026 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Tue, 13 Jan 2026 21:13:40 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> References: <873180DD-3178-43EB-BB6E-7A9EB170B05B@oracle.com> <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> Message-ID: There are 3 questions: (1) should we deprecate `Path::startsWith(String)`? (2) should we deprecate `Path::endsWith(String)`? (3) should we add a file extension API? And the TL;DR: no, no, yes. Let's first establish why `startsWith/endsWith` add tangible value: because `path.startsWith("foo")` is not equivalent to `path.startsWith(Path.of("foo"))` and is much more readable than `path.startsWith(getFileSystem().getPath("foo"))`. Next, let's consider why people might want to use String-based `startsWith/endsWith` testing on Path instances: * testing file extensions = 99.9999% of the times: covered by `FileSystem::getPathMatcher` * testing name elements = 0.0000999% of the times: covered by `Path` * any other use cases = ~0% of the times: covered by `FileSystem::getPathMatcher` So it is always possible to do without String conversion. In fact, it is arguably always a bad idea to do String-based testing, because `path.toString().endsWith(".java")` will also match a file named ".java", which on Linux-like OSes would be considered a hidden file named "java" that has no file extension. So using a dedicated `PathMatcher` for testing file extensions is more robust and elegant. However, when testing file extensions we inevitably start by typing `path.` (assuming we don't just use a third-party library), first notice there's no method `getFileExtension` or such, and then notice `endsWith(String)` (and maybe we've also noticed `getFileName` and already have `path.getFileName().`). At this point it's pure psychology: we're looking for a method that behaves like String's `endsWith(String)`, we're looking at a method with the same method signature, and we can't imagine that the Path class does *not* have a method to test the filename extension, so surely this must be it. And obviously we ignore any hints at the contrary (like our IDE proposing both `endsWith(Path)` and `endsWith(String)` for autocompletion). And we don't bother to read the Javadoc, because in cases like this we can easily verify our assumptions with JShell and equally quickly realize our assumptions are wrong. So yes, this is a common mistake. But this is actually an argument for *not* deprecating it. Many developers have bumped into this, but as far as I can tell the mailing list thread in September was the first in the existence of the API. And I'm unable to find any previous bug reports either. And here's why: when we realized our assumptions were wrong, we read the Javadoc, realized our mistake, learned from it, and moved on. The Javadoc is crystal-clear, the method overloads another method with the same behavior, it clearly adds value over the other method. In other words: we conclude "makes sense" and don't see any reason to complain. To turn this common mistake into a rare-if-ever mistake, I see two (combinable) options: * introduce a file extension API * replace `startsWith/endsWith` with methods `startsWithNames/endsWithNames` I don't consider deprecating `startsWith/endsWith` without replacement an option because: * these methods add value (as was also argued by Rob Spoor), so it's a net loss for the Java SE APIs. And all the people that are happily using these methods today and are unaware of this mailing list thread will be unpleasantly surprised to see it deprecated * this means breaking compilation for everyone that builds with "-Werror" and "no usage of deprecated APIs" is a very common policy. So people will end up adding a duplicate of the deprecated methods in their own utility libraries * this trades one trap for another, much more subtle trap, since people will blindly replace `"foo"` with `Path.of("foo")`. (We're having this very discussion because people don't read Javadoc. So surely we're not expecting people to read the deprecation text and follow the recommendations, are we?) Eventually they'll notice there's a bug, add `IO.println(foo)` and `IO.println(Path.of("foo"))`, notice these both print "foo", but somehow `foo.endsWith(Path.of("foo"))` results in `false`, eventually find the culprit ... and then notice the deprecated `endsWith` method did exactly what they wanted all along * what would the rationale for the deprecation be? How would you document this in the Javadoc? Now you might still say: "People who were looking for a file extension API regularly ended up here. If you're one of them, use Path::toString instead." But once a file extension API will be available, it'll be extremely hard to come up with a reasonable justification for the deprecation. And as argued above, simple String-based comparisons are rarely, if ever, the most robust solution * for `startsWith` in particular: the only argument to deprecate it seems to be "for the sake of symmetry" Anthony On 1/12/2026 8:36 PM, Stuart Marks wrote: > > Let's not tie these two issues together. > > The discussion clearly shows that the startsWith/endsWith(String) APIs > are a trap that several people have fallen into. On that basis it > should be deprecated. (Ordinarily, so as to emit a warning, and not > for removal, so there won't be any compatibility issue.) > > There is also no requirement that a new API be introduced to replace > any deprecated API. As the earlier discussion in the thread shows, > both the path-based and the string-based use cases can be written > using existing APIs, somewhat less conveniently and more verbosely; > but these constructs are much more explicit and so are preferable to > the APIs to be deprecated. The deprecation text should steer people > toward the preferred constructs. > > It would indeed be nice to have a file extension API, but this has > been discussed several times and has run aground each time for a > variety of reasons. Tying these together will hold up the deprecation > for no good reason. > > Let's proceed with just the deprecation first and work on the file > extension API separately. > > s'marks > > On 1/11/26 12:45 PM, David Alayachew wrote: >> Thanks for the response Anthony. Messages have been arriving >> out-of-order for me, so I didn't see yours at the time of me writing >> that message. >> >> I think introducing the file extension API first, then gauging the >> need for a deprecation before doing it is fine. Sounds like then that >> we are universally agreed on the first step being to add the file >> extension API, yes? >> >> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe >> wrote: >> >> I dissent. (Apparently my previous message wasn't clear.) >> >> The right order of things is to first introduce a file extension >> API. Then see if there's still complaints about >> `Path::endsWith(String)`. And only then, if there are, consider >> taking action. >> >> In my previous message I've already explained how these methods >> add real, tangible value and actually are intuitive. >> (Again, ask developers to guess how `A::foo(B)` behaves, given >> that both `A::foo(A)` and `B::foo(B)` exist, and a large majority >> of them will intuitively guess it converts its `b` argument to an >> instance of `A` and passes it on to `A::foo(A)`. And their >> intuition would be correct in the case of >> `Path::endsWith(String)`. That being said, I'll be the first to >> admit that I've also made the mistake of attempting to use >> `Path::endsWith(String)` to test the file extension.) >> >> In hindsight, maybe `endsWithNames(String)` would've been a >> better choice, but hindsight is 20/20. >> >> Deprecating these methods now is premature. And deprecating them >> without replacement methods would result in way more complaints >> than there have ever been about `endsWith(String)`. >> >> Anthony >> >> On 1/11/2026 12:19 AM, David Alayachew wrote: >>> Of course. >>> >>> I see lots of approvals and not really any dissenters. Are we >>> waiting for more responses? Or is there anything we can do to >>> kick start this? >>> >>> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter >>> wrote: >>> >>> Thanks for the corroboration. >>> >>>> On Jan 8, 2026, at 1:50?PM, David Alayachew >>>> wrote: >>>> >>>> Thanks for reviving this. >>>> >>>> I am perfectly happy with the idea of deprecating the >>>> Path.{start,ends}With(String), and then only add the file >>>> extension method. Originally, I didn't know that new method >>>> was on the table, so I suggested a rename. But the file >>>> extension api feels like the superior solution. >>>> >>>> 10 times out of 10, if I am calling endsWith, the only time >>>> I am not looking for "whole" path elements is when I am >>>> looking for a file extension. In every other instance, the >>>> api does exactly what I expect and want. And plus, >>>> something like looking for a file extension is better off >>>> being explicit. >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Tue Jan 13 20:35:23 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 20:35:23 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: <_OBEkatnYiCZ9cvRGxXCDAx0hmqGa09CiMFb1uVMihY=.d8ff56e0-142e-424d-b141-2ac821413d74@github.com> References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> <_OBEkatnYiCZ9cvRGxXCDAx0hmqGa09CiMFb1uVMihY=.d8ff56e0-142e-424d-b141-2ac821413d74@github.com> Message-ID: On Mon, 12 Jan 2026 15:27:30 GMT, Alan Bateman wrote: > I wonder if it could throw a more specific mismatch exception for this case so that the jimage tool can handle, and translate into something that includes a path to itself. Following Alan's suggestion, keep the exception message concise so JImage tool can recognize it and produce a full error message with context. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3746446333 From duke at openjdk.org Tue Jan 13 20:50:57 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Tue, 13 Jan 2026 20:50:57 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:05:43 GMT, Jan Lahoda wrote: > The SwitchBootstraps.enumSwitch is documented to throw a NullPointerException when lookup is null, but it does not throw the exception in all cases. Nothing against failing fast, but wouldn't this argumentation open a can of worms? The method documents that it can throw multiple exceptions but there is no guaranteed order of argument checking. So even if the method documents that it rejects a null `labels` parameter it is still valid to throw a IllegalArgumentException first when checking the `invocationType` parameter. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29202#issuecomment-3746511952 From weijun at openjdk.org Tue Jan 13 21:17:13 2026 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 13 Jan 2026 21:17:13 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8] In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com> > Rewrite the native calls with FFM. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: new naming style; use VarHandle to access fields ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28931/files - new: https://git.openjdk.org/jdk/pull/28931/files/cfd794b8..bf91106e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=06-07 Stats: 36 lines in 1 file changed: 1 ins; 6 del; 29 mod Patch: https://git.openjdk.org/jdk/pull/28931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931 PR: https://git.openjdk.org/jdk/pull/28931 From weijun at openjdk.org Tue Jan 13 21:27:03 2026 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 13 Jan 2026 21:27:03 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8] In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com> Message-ID: On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new naming style; use VarHandle to access fields A new commit pushed after some offline discussion. Now using a new naming style with an uppercase PREFIX followed by the original C name. For example, a `MethodHandle` for `getgroups` becomes `MH_getgroups`. Also, switching to `VarHandle` for struct field retrieval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3746638101 From weijun at openjdk.org Tue Jan 13 21:27:04 2026 From: weijun at openjdk.org (Weijun Wang) Date: Tue, 13 Jan 2026 21:27:04 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Mon, 12 Jan 2026 11:37:17 GMT, Martin Doerr wrote: >>> It's unfortunate that the FFM doesn't provide a good abstraction for passing `uint32_t`. Maybe we should implement an enhancement? >> >> Indeed, the status quo with respect to unsigned values passed to downcalls is a bit suboptimal, esp. in certain ABIs where sign/zero extension is required. This is tracked here: >> >> https://bugs.openjdk.org/browse/JDK-8336664 >> >> (apologies -- this link was already shared by @dmlloyd ) > > Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions? @TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2688164522 From rriggs at openjdk.org Tue Jan 13 21:47:01 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 21:47:01 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 16:52:36 GMT, Ioi Lam wrote: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. src/java.base/windows/classes/java/lang/ProcessImpl.java line 118: > 116: } > 117: > 118: Redirect file1 = null; Remove src/java.base/windows/classes/java/lang/ProcessImpl.java line 125: > 123: if (stdHandles[1] == -1L) { > 124: // FileDescriptor.out has been closed. > 125: file1 = Redirect.DISCARD; Suggestion: // FileDescriptor.out has been closed. f1 = newFileOutputStream(Redirect.DISCARD.file(), Redirect.DISCARD.append()); stdHandles[1] = fdAccess.getHandle(f1.getFD()); Inline the change and avoid extra local state variable src/java.base/windows/classes/java/lang/ProcessImpl.java line 137: > 135: if (file1 != null) { > 136: f1 = newFileOutputStream(file1.file(), > 137: file1.append()); Revert to original. src/java.base/windows/classes/java/lang/ProcessImpl.java line 141: > 139: } > 140: > 141: Redirect file2 = null; Remove src/java.base/windows/classes/java/lang/ProcessImpl.java line 148: > 146: if (stdHandles[2] == -1L) { > 147: // FileDescriptor.err has been closed. > 148: file2 = Redirect.DISCARD; Suggestion: // FileDescriptor.err has been closed. f2 = newFileOutputStream(Redirect.DISCARD.file(), Redirect.DISCARD.append()); stdHandles[2] = fdAccess.getHandle(f2.getFD()); Inline the change to discard stderr. src/java.base/windows/classes/java/lang/ProcessImpl.java line 157: > 155: if (file2 != null) { > 156: f2 = newFileOutputStream(file2.file(), > 157: file2.append()); Revert to original. test/jdk/java/lang/ProcessBuilder/InheritIOClosed.java line 52: > 50: "1234567890" + > 51: "1234567890" + > 52: "1234567890"; Suggestion: private final static Path JAVA_EXE = Path.of(System.getProperty("java.home"), "bin", "java"); private static final String s = "1234567890".repeat(10); Path is more compact. test/jdk/java/lang/ProcessBuilder/InheritIOClosed.java line 65: > 63: > 64: ProcessBuilder pb = new ProcessBuilder().inheritIO() > 65: .command(JAVA_EXE, Suggestion: .command(JAVA_EXE.toString(), ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687961657 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687960154 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687961222 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687965150 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687964194 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687964792 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687982258 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2687984357 From rriggs at openjdk.org Tue Jan 13 21:47:40 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 21:47:40 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v3] In-Reply-To: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: > On Linux and Mac, when a process is started, pipes are created to communicate with the child. > In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. > > Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. > Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) > Converted PipelineLeaksFD test to JUnit. Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: - Some test platforms do not have `lsof` installed, if not available, the tests are skipped. - Remove extra -Xint test run, its purpose is unknown. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29143/files - new: https://git.openjdk.org/jdk/pull/29143/files/83d03292..38328d56 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=01-02 Stats: 29 lines in 1 file changed: 21 ins; 8 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29143/head:pull/29143 PR: https://git.openjdk.org/jdk/pull/29143 From rriggs at openjdk.org Tue Jan 13 22:04:39 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 13 Jan 2026 22:04:39 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset In-Reply-To: References: Message-ID: <-qTE7Ac7lWOtINGFlc43ZX_fkW08IV8uHhqLX7q0K8I=.c8562893-8b3e-4940-909e-9dc14008dc74@github.com> On Fri, 21 Nov 2025 14:58:55 GMT, Liam Miller-Cushon wrote: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... The test has an odd mix of throwing Exception and RuntimeException. It would be good to upgrade the test to use JUnit (though it could/should be a separate PR). src/java.base/share/classes/java/lang/String.java line 2112: > 2110: * > 2111: *

The result will be the same value as {@code getBytes(charset).length}. > 2112: * An @implNote or @apiNote maybe useful to indicate that this may allocate memory to compute the length for some Charsets. src/java.base/share/classes/java/lang/String.java line 2120: > 2118: return encodedLengthUTF8(coder, value); > 2119: } > 2120: if (bytesCompatible(cs, 0, value.length)) { BytesCompatible gives a non-optimal answer for a US_ASCII input that has chars > 0x7f. src/java.base/share/classes/java/lang/String.java line 2125: > 2123: if (cs instanceof sun.nio.cs.UTF_16LE || > 2124: cs instanceof sun.nio.cs.UTF_16BE) { > 2125: return value.length << (1 - coder()); Please encapsulate this computation `byteFor(int length, coder) {...}` to make it easier to re-use and document. ------------- PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3658097768 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2688260162 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2688257004 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2688253744 From almatvee at openjdk.org Tue Jan 13 22:32:54 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Tue, 13 Jan 2026 22:32:54 GMT Subject: RFR: 8375061: Multiple jpackage tool providers may share the same logging config [v3] In-Reply-To: References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: On Tue, 13 Jan 2026 16:37:44 GMT, Alexey Semenyuk wrote: >> The patch addresses two issues: >> - Each jpackage tool provider instance should have its own logging config instance. >> - The test lib should be able to keep output from concurrently running tests isolated from each other. >> >> These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. >> >> The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. >> >> Supplementary changes: >> - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > BasicTest: rollback accidental change. Latest changes looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29175#pullrequestreview-3658183144 From asemenyuk at openjdk.org Tue Jan 13 22:42:33 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Tue, 13 Jan 2026 22:42:33 GMT Subject: Integrated: 8375061: Multiple jpackage tool providers may share the same logging config In-Reply-To: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> References: <80BLt8OjrXkpBO7jQit2yTnqiMLZ5Iwa-q03zOtMa24=.33327f80-6728-4a75-87d2-12e9c069699e@github.com> Message-ID: <2Gya55RgnhZc9zb-iep_PG4nENszn2FpLVOftq-Fdis=.34db3038-534b-4614-9805-4d45946b652e@github.com> On Mon, 12 Jan 2026 19:03:25 GMT, Alexey Semenyuk wrote: > The patch addresses two issues: > - Each jpackage tool provider instance should have its own logging config instance. > - The test lib should be able to keep output from concurrently running tests isolated from each other. > > These two fixes are bundled together because it is impossible to verify the jpackage implementation fix without fixing the test lib. > > The test lib fix replaces all inheritable thread-local variables with scoped values. It fixes the interleaved output issue and simplifies the implementation. > > Supplementary changes: > - jdk.jpackage.internal.cli.Main: when creating a `java.io.PrintWriter` from a `java.io.PrintStream`, copy the charset instead of using the default one. This pull request has now been integrated. Changeset: 9ed0ecbc Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/9ed0ecbcc1b4796bc56b7cb341ff8f9d3898713d Stats: 688 lines in 13 files changed: 386 ins; 162 del; 140 mod 8375061: Multiple jpackage tool providers may share the same logging config Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29175 From jlu at openjdk.org Tue Jan 13 23:02:35 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 13 Jan 2026 23:02:35 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit Message-ID: This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. The first commit is from the automated tool, the rest are manual changes done after. Before ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit After ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit ------------- Commit messages: - Copyright years - Clean up some lambdas for exception tests - TestInstance.Lifecycle.PER_CLASS -> _.PER_METHOD - Replacing groups option w/ tag for StringJoiner tests - Apply auto conversion tool Changes: https://git.openjdk.org/jdk/pull/29210/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29210&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375231 Stats: 408 lines in 11 files changed: 93 ins; 33 del; 282 mod Patch: https://git.openjdk.org/jdk/pull/29210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29210/head:pull/29210 PR: https://git.openjdk.org/jdk/pull/29210 From duke at openjdk.org Tue Jan 13 23:18:44 2026 From: duke at openjdk.org (Roger Calnan) Date: Tue, 13 Jan 2026 23:18:44 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page [v2] In-Reply-To: References: Message-ID: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option Roger Calnan 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/28954/files - new: https://git.openjdk.org/jdk/pull/28954/files/e259d698..5cfbc2c7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28954&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28954.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28954/head:pull/28954 PR: https://git.openjdk.org/jdk/pull/28954 From duke at openjdk.org Tue Jan 13 23:18:45 2026 From: duke at openjdk.org (duke) Date: Tue, 13 Jan 2026 23:18:45 GMT Subject: RFR: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option @calnan Your change (at version 5cfbc2c7e15bed6394595ad389452058eeb9e685) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28954#issuecomment-3746975759 From naoto at openjdk.org Wed Jan 14 00:06:38 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jan 2026 00:06:38 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 22:42:41 GMT, Justin Lu wrote: > This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. > The first commit is from the automated tool, the rest are manual changes done after. > > Before > ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit > StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit > Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit > > After > ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit > StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit > Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit LGTM. test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 171: > 169: loadProviders(mods, TEST1_MODULE).forEach(Provider::get); > 170: }); > 171: } I think it is done by the tool, but I think retaining the blank lines may read better (and probably intended). test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 201: > 199: // load providers and instantiate each one > 200: loadProviders(mods, TEST2_MODULE).forEach(Provider::get); > 201: }); Same here ------------- PR Review: https://git.openjdk.org/jdk/pull/29210#pullrequestreview-3658358364 PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2688496372 PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2688496964 From jlu at openjdk.org Wed Jan 14 00:12:09 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 Jan 2026 00:12:09 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v2] In-Reply-To: References: Message-ID: > This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. > The first commit is from the automated tool, the rest are manual changes done after. > > Before > ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit > StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit > Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit > > After > ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit > StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit > Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Retain the removed whitespace in BadProvidersTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29210/files - new: https://git.openjdk.org/jdk/pull/29210/files/e717570a..dedfc033 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29210&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29210&range=00-01 Stats: 6 lines in 1 file changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29210/head:pull/29210 PR: https://git.openjdk.org/jdk/pull/29210 From asemenyuk at openjdk.org Wed Jan 14 00:50:38 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 00:50:38 GMT Subject: RFR: 8356684: jpackage error messages are not helpful Message-ID: If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. E.g. (unit test output): jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files Command output: It fell apart ------------- Commit messages: - Update copyright year - CommandOutputControlTest: improve coverage - Add CommandOutputControl.ExecutableAttributes.printableCommandLine() - 8356684: jpackage error messages are not helpful - Add SelfContainedException annotation to the model. Use it mark exception classes with error messages suitable for presenting to a user without the need to provide an additional context (class name, stack trace). Changes: https://git.openjdk.org/jdk/pull/29197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8356684 Stats: 484 lines in 13 files changed: 412 ins; 47 del; 25 mod Patch: https://git.openjdk.org/jdk/pull/29197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29197/head:pull/29197 PR: https://git.openjdk.org/jdk/pull/29197 From asemenyuk at openjdk.org Wed Jan 14 00:50:38 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 00:50:38 GMT Subject: RFR: 8356684: jpackage error messages are not helpful In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 16:42:43 GMT, Alexey Semenyuk wrote: > If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. > > E.g. (unit test output): > > jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console > Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files > Command output: > It > fell > apart @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29197#issuecomment-3747172601 From asemenyuk at openjdk.org Wed Jan 14 01:24:03 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 01:24:03 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v2] In-Reply-To: References: Message-ID: > If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. > > E.g. (unit test output): > > jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console > Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files > Command output: > It > fell > apart 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: - Update copyright year - CommandOutputControlTest: improve coverage ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29197/files - new: https://git.openjdk.org/jdk/pull/29197/files/e97093d9..591f5692 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29197/head:pull/29197 PR: https://git.openjdk.org/jdk/pull/29197 From erfang at openjdk.org Wed Jan 14 02:10:03 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 14 Jan 2026 02:10:03 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 17:37:25 GMT, Paul Sandoz wrote: > > Hi @PaulSandoz , if you?ve already had a chance to run the tests, could you let me know how they turned out? Thanks~ > > Yes, all good! Thank you ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3747348489 From duke at openjdk.org Wed Jan 14 02:10:09 2026 From: duke at openjdk.org (duke) Date: Wed, 14 Jan 2026 02:10:09 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:11:19 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 eight commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8372978-fix-umin-umax-identity > - wrap the test loop within a try/catch to speed up the tests > - Refine the tests for identity values > - 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. @erifan Your change (at version 1e6ff0886159881388f8cbbedeea5f0f544bc785) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3747352706 From asemenyuk at openjdk.org Wed Jan 14 02:13:10 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 02:13:10 GMT Subject: RFR: 8375240: Make bundling progress messages issued by jpackage consistent across platforms Message-ID: Replace platform-specific progress messages with shared ones. Remove explicit log statements from the packagers and make them "before" and "after" actions of pipeline tasks. Additionally: - Unify the deletion of an old bundle between platforms. For this, add a new `DELETE_OLD_PACKAGE_FILE` pipeline task, which is a prerequisite for the `CREATE_PACKAGE_FILE` task. - Add `BundleType` to the module. Make it a supertype for the existing `AppImagePackageType` (renamed to `AppImageBundleType`) and `PackageType` interfaces. ------------- Commit messages: - Update copyright year - Add test coverage for "error.output-bundle-cannot-be-overwritten" error - Support log messages for tasks in the packaging pipeline. Unify logging of app image and package generation across all packagers. - PackagingPipeline: add PackageTaskID.DELETE_OLD_PACKAGE_FILE task - BundleType: add label(); AppImageBundleType: make it enum with three items for each supported platforms; MainResources.properties: make package type names consistent - Add BundleType to the model. Changes: https://git.openjdk.org/jdk/pull/29199/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29199&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375240 Stats: 857 lines in 28 files changed: 539 ins; 189 del; 129 mod Patch: https://git.openjdk.org/jdk/pull/29199.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29199/head:pull/29199 PR: https://git.openjdk.org/jdk/pull/29199 From asemenyuk at openjdk.org Wed Jan 14 02:13:11 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 02:13:11 GMT Subject: RFR: 8375240: Make bundling progress messages issued by jpackage consistent across platforms In-Reply-To: References: Message-ID: <7Vm0vRD52CZ8V41kVxC4N1a3P5zpUPI1bedjVOmV0kk=.8878bdc0-d773-46eb-8ef1-d4fb94dca945@github.com> On Tue, 13 Jan 2026 16:55:30 GMT, Alexey Semenyuk wrote: > Replace platform-specific progress messages with shared ones. > > Remove explicit log statements from the packagers and make them "before" and "after" actions of pipeline tasks. > > Additionally: > - Unify the deletion of an old bundle between platforms. For this, add a new `DELETE_OLD_PACKAGE_FILE` pipeline task, which is a prerequisite for the `CREATE_PACKAGE_FILE` task. > - Add `BundleType` to the module. Make it a supertype for the existing `AppImagePackageType` (renamed to `AppImageBundleType`) and `PackageType` interfaces. @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29199#issuecomment-3747348261 From almatvee at openjdk.org Wed Jan 14 02:22:10 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 02:22:10 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 01:24:03 GMT, Alexey Semenyuk wrote: >> If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. >> >> E.g. (unit test output): >> >> jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console >> Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files >> Command output: >> It >> fell >> apart > > 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: > > - Update copyright year > - CommandOutputControlTest: improve coverage Looks good with minor typo issue. src/jdk.jpackage/share/classes/jdk/jpackage/internal/Executor.java line 236: > 234: } > 235: > 236: return ExecutableAttributesWithCapturedOutput.augmenResultWithOutput(result, printableOutput); `augmen` -> 'augment' ------------- PR Review: https://git.openjdk.org/jdk/pull/29197#pullrequestreview-3658491787 PR Review Comment: https://git.openjdk.org/jdk/pull/29197#discussion_r2688620920 From asemenyuk at openjdk.org Wed Jan 14 02:41:13 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 02:41:13 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v3] In-Reply-To: References: Message-ID: > If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. > > E.g. (unit test output): > > jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console > Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files > Command output: > It > fell > apart Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: ExecutableAttributesWithCapturedOutput: augmenResultWithOutput() -> augmentResultWithOutput() ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29197/files - new: https://git.openjdk.org/jdk/pull/29197/files/591f5692..612629d8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=01-02 Stats: 6 lines in 3 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29197/head:pull/29197 PR: https://git.openjdk.org/jdk/pull/29197 From almatvee at openjdk.org Wed Jan 14 02:50:47 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 02:50:47 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v3] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 02:41:13 GMT, Alexey Semenyuk wrote: >> If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. >> >> E.g. (unit test output): >> >> jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console >> Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files >> Command output: >> It >> fell >> apart > > Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: > > ExecutableAttributesWithCapturedOutput: augmenResultWithOutput() -> augmentResultWithOutput() Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29197#pullrequestreview-3658623991 From almatvee at openjdk.org Wed Jan 14 03:06:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 03:06:59 GMT Subject: RFR: 8375240: Make bundling progress messages issued by jpackage consistent across platforms In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 16:55:30 GMT, Alexey Semenyuk wrote: > Replace platform-specific progress messages with shared ones. > > Remove explicit log statements from the packagers and make them "before" and "after" actions of pipeline tasks. > > Additionally: > - Unify the deletion of an old bundle between platforms. For this, add a new `DELETE_OLD_PACKAGE_FILE` pipeline task, which is a prerequisite for `CREATE_PACKAGE_FILE`. > - Add `BundleType` to the model. Make it a supertype for the existing `AppImagePackageType` (renamed to `AppImageBundleType`) and `PackageType` interfaces. Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29199#pullrequestreview-3658649326 From iklam at openjdk.org Wed Jan 14 03:22:33 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 Jan 2026 03:22:33 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Review comments from @RogerRiggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/30b312e1..e9006f5e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=00-01 Stats: 43 lines in 2 files changed: 9 ins; 25 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From iklam at openjdk.org Wed Jan 14 03:22:36 2026 From: iklam at openjdk.org (Ioi Lam) Date: Wed, 14 Jan 2026 03:22:36 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 20:04:49 GMT, Roger Riggs wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments from @RogerRiggs > > src/java.base/windows/classes/java/lang/ProcessImpl.java line 125: > >> 123: if (stdHandles[1] == -1L) { >> 124: // FileDescriptor.out has been closed. >> 125: file1 = Redirect.DISCARD; > > Suggestion: > > // FileDescriptor.out has been closed. > f1 = newFileOutputStream(Redirect.DISCARD.file(), > Redirect.DISCARD.append()); > stdHandles[1] = fdAccess.getHandle(f1.getFD()); > > Inline the change and avoid extra local state variable To avoid cut-and-pasting the same code 4 times, I refactored the code into a separate function, `setFileOutput()`. > test/jdk/java/lang/ProcessBuilder/InheritIOClosed.java line 52: > >> 50: "1234567890" + >> 51: "1234567890" + >> 52: "1234567890"; > > Suggestion: > > private final static Path JAVA_EXE = > Path.of(System.getProperty("java.home"), "bin", "java"); > > private static final String s = "1234567890".repeat(10); > > Path is more compact. Fixed as suggested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2688783638 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2688784628 From asemenyuk at openjdk.org Wed Jan 14 04:07:12 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 04:07:12 GMT Subject: Integrated: 8375240: Make bundling progress messages issued by jpackage consistent across platforms In-Reply-To: References: Message-ID: <9dnKZMPsvd4J2oKSDI63b8RnOwgrHAaWYePXH8rRXT8=.c1a65d7b-dba0-483b-bc6d-6bf349f8bbb6@github.com> On Tue, 13 Jan 2026 16:55:30 GMT, Alexey Semenyuk wrote: > Replace platform-specific progress messages with shared ones. > > Remove explicit log statements from the packagers and make them "before" and "after" actions of pipeline tasks. > > Additionally: > - Unify the deletion of an old bundle between platforms. For this, add a new `DELETE_OLD_PACKAGE_FILE` pipeline task, which is a prerequisite for `CREATE_PACKAGE_FILE`. > - Add `BundleType` to the model. Make it a supertype for the existing `AppImagePackageType` (renamed to `AppImageBundleType`) and `PackageType` interfaces. This pull request has now been integrated. Changeset: b082a390 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/b082a390b77fca7134000bfe631f73bfd082bfa1 Stats: 857 lines in 28 files changed: 539 ins; 189 del; 129 mod 8375240: Make bundling progress messages issued by jpackage consistent across platforms Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29199 From asemenyuk at openjdk.org Wed Jan 14 04:21:59 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 04:21:59 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v4] In-Reply-To: References: Message-ID: > If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. > > E.g. (unit test output): > > jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console > Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files > Command output: > It > fell > apart 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: - Merge branch 'master' into JDK-8356684 - ExecutableAttributesWithCapturedOutput: augmenResultWithOutput() -> augmentResultWithOutput() - Update copyright year - CommandOutputControlTest: improve coverage - Add CommandOutputControl.ExecutableAttributes.printableCommandLine() - 8356684: jpackage error messages are not helpful - Add SelfContainedException annotation to the model. Use it mark exception classes with error messages suitable for presenting to a user without the need to provide an additional context (class name, stack trace). ------------- Changes: https://git.openjdk.org/jdk/pull/29197/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29197&range=03 Stats: 486 lines in 13 files changed: 413 ins; 47 del; 26 mod Patch: https://git.openjdk.org/jdk/pull/29197.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29197/head:pull/29197 PR: https://git.openjdk.org/jdk/pull/29197 From almatvee at openjdk.org Wed Jan 14 04:21:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 04:21:59 GMT Subject: RFR: 8356684: jpackage error messages are not helpful [v4] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 04:18:10 GMT, Alexey Semenyuk wrote: >> If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. >> >> E.g. (unit test output): >> >> jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console >> Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files >> Command output: >> It >> fell >> apart > > 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: > > - Merge branch 'master' into JDK-8356684 > - ExecutableAttributesWithCapturedOutput: augmenResultWithOutput() -> augmentResultWithOutput() > - Update copyright year > - CommandOutputControlTest: improve coverage > - Add CommandOutputControl.ExecutableAttributes.printableCommandLine() > - 8356684: jpackage error messages are not helpful > - Add SelfContainedException annotation to the model. Use it mark exception classes with error messages suitable for presenting to a user without the need to provide an additional context (class name, stack trace). Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29197#pullrequestreview-3658775120 From almatvee at openjdk.org Wed Jan 14 04:47:11 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 04:47:11 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" [v2] 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: <5yjoXCd8YLor0bMBlRnOBGuXOmI-oMUO4xBJVTHj3uA=.f2690c49-3e47-42d6-9227-cb0143b99c5b@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. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8374215: [macos] Clean "lic_template.plist" [v2] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28959/files - new: https://git.openjdk.org/jdk/pull/28959/files/48763b1a..d8c3b0aa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=00-01 Stats: 241 lines in 6 files changed: 86 ins; 127 del; 28 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 almatvee at openjdk.org Wed Jan 14 04:51:04 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 04:51:04 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" [v3] 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: > - 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. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits: - merge upstream/master - 8374215: [macos] Clean "lic_template.plist" [v2] - 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=02 Stats: 246 lines in 6 files changed: 82 ins; 137 del; 27 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 almatvee at openjdk.org Wed Jan 14 04:55:05 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 04:55:05 GMT Subject: RFR: 8374215: [macos] Clean "lic_template.plist" [v4] 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: > - 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. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: Added missing import from merge ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28959/files - new: https://git.openjdk.org/jdk/pull/28959/files/981066c2..3acafc5a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=02-03 Stats: 1 line in 1 file changed: 1 ins; 0 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 darcy at openjdk.org Wed Jan 14 06:08:18 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Jan 2026 06:08:18 GMT Subject: RFR: 8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned Message-ID: Happened to notice the divideUnsigned and reminaderUnsigned methods don't document throwing ArithmeticException for a zero divisor so added I'm proposing to add the appropriate throws clauses. The CSR is ready to review too. ------------- Commit messages: - 8375244: Document existing exceptional behavior of divideUnsigned and remainderUnsigned Changes: https://git.openjdk.org/jdk/pull/29215/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29215&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375237 Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29215.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29215/head:pull/29215 PR: https://git.openjdk.org/jdk/pull/29215 From darcy at openjdk.org Wed Jan 14 06:08:18 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Jan 2026 06:08:18 GMT Subject: RFR: 8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 05:59:54 GMT, Joe Darcy wrote: > Happened to notice the divideUnsigned and reminaderUnsigned methods don't document throwing ArithmeticException for a zero divisor so added I'm proposing to add the appropriate throws clauses. > The CSR is ready to review too. The regression tests already cover the exceptional behavior so this PR doesn't include any test updates: https://github.com/openjdk/jdk/blob/b082a390b77fca7134000bfe631f73bfd082bfa1/test/jdk/java/lang/Integer/Unsigned.java#L364 https://github.com/openjdk/jdk/blob/b082a390b77fca7134000bfe631f73bfd082bfa1/test/jdk/java/lang/Long/Unsigned.java#L435 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29215#issuecomment-3747922752 From erfang at openjdk.org Wed Jan 14 06:19:44 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 14 Jan 2026 06:19:44 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 17:37:25 GMT, Paul Sandoz wrote: >> This looks good. Before we integrate we will run it through our test system and report back to you. > >> Hi @PaulSandoz , if you?ve already had a chance to run the tests, could you let me know how they turned out? Thanks~ > > Yes, all good! @PaulSandoz Since this is correctness bug fix, p3 priority. I think we should backport the fix to JDK26 and JDK25, right ? JDK24 has been archived, no need to backport to it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3747955656 From erfang at openjdk.org Wed Jan 14 06:19:45 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 14 Jan 2026 06:19:45 GMT Subject: Integrated: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: Message-ID: 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. This pull request has now been integrated. Changeset: 56d7b524 Author: Eric Fang Committer: Xiaohong Gong URL: https://git.openjdk.org/jdk/commit/56d7b524b3ddb49b985b4e6f061a7128b10cffb5 Stats: 13975 lines in 48 files changed: 7543 ins; 3660 del; 2772 mod 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions Reviewed-by: psandoz, qamai, xgong ------------- PR: https://git.openjdk.org/jdk/pull/28692 From alan.bateman at oracle.com Wed Jan 14 07:15:11 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Wed, 14 Jan 2026 07:15:11 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> Message-ID: <74591132-0606-4013-abab-5d71256d6f2a@oracle.com> On 13/01/2026 20:13, Anthony Vanelverdinghe wrote: > > There are 3 questions: > > (1) should we deprecate `Path::startsWith(String)`? > (2) should we deprecate `Path::endsWith(String)`? > (3) should we add a file extension API? > The "plan" is to deprecate startsWith(String) and endsWith(String), and to reboot the effort to add the file extension API. -Alan From jpai at openjdk.org Wed Jan 14 07:33:02 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 14 Jan 2026 07:33:02 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v3] In-Reply-To: References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: <1bPUqCHJXanDtoWURWX9kOrIK2zDhNn45oh07bfKR20=.9b07802c-d9ab-4817-9674-2744804a38a1@github.com> On Tue, 13 Jan 2026 21:47:40 GMT, Roger Riggs wrote: >> On Linux and Mac, when a process is started, pipes are created to communicate with the child. >> In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. >> >> Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. >> Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) >> Converted PipelineLeaksFD test to JUnit. > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Some test platforms do not have `lsof` installed, if not available, > the tests are skipped. > - Remove extra -Xint test run, its purpose is unknown. The test updates look good to me. I see that the test now uses `EnabledIf` from JUnit. Do you know if the test gets skipped then would it show up in the skipped count listed for the test: > [ JUnit Tests: found 5, started 5, succeeded 5, failed 0, aborted 0, skipped 0] Actually, the GitHub actions job test failure looks related to this change: Extra pipes in pipesAfter: [0] org.opentest4j.AssertionFailedError: More or fewer pipes than expected at org.junit.jupiter.api.AssertionUtils.fail(AssertionUtils.java:38) at org.junit.jupiter.api.Assertions.fail(Assertions.java:138) at PipelineLeaksFD.checkForLeaks(PipelineLeaksFD.java:133) ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29143#pullrequestreview-3659261972 PR Comment: https://git.openjdk.org/jdk/pull/29143#issuecomment-3748198076 From alanb at openjdk.org Wed Jan 14 07:36:48 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 07:36:48 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v2] In-Reply-To: References: Message-ID: <28KO3c_cSbDadToTxzR1tehQDOwgEst19uBXOgP2iVU=.abdcd431-3207-47bb-9b28-fa5bc9981761@github.com> On Wed, 14 Jan 2026 00:12:09 GMT, Justin Lu wrote: >> This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. >> The first commit is from the automated tool, the rest are manual changes done after. >> >> Before >> ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit >> StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit >> Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit >> >> After >> ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit >> StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit >> Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Retain the removed whitespace in BadProvidersTest.java test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 142: > 140: > 141: > 142: public static Object[][] createBadFactories() { I assume the method source doesn't need to be public. Also it could be changed to return `Stream` and that would allow the "ignore" parameter to be dropped. test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 173: > 171: // load providers and instantiate each one > 172: loadProviders(mods, TEST1_MODULE).forEach(Provider::get); > 173: }); The scope of the function passed to assertThrows is way too large. The code to compile the factory and copy the compiled class into the module should not be in this block. Was this tool or manual edit? Asking because we should only assert that the SL use throws ServiceConfigurationError. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2689298479 PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2689295671 From alanb at openjdk.org Wed Jan 14 08:13:02 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 08:13:02 GMT Subject: [jdk26] RFR: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks [v2] In-Reply-To: References: Message-ID: > This PR is for the jdk26 branch, not main line. > > The changes in [JDK-8360046](https://bugs.openjdk.org/browse/JDK-8360046) improve the scalability of virtual threads but introduce a subtle issue with signal filtering and a regression in some SPECjbb2015 runs. [pull/28797](https://git.openjdk.org/jdk/pull/28797) is in progress for main line to address these issues. > > For the jdk26 branch, the proposal is to backout the changes to ForkJoinPool from JDK-8360046 but leave the small change to setParallelism to trigger worker activation and the small change to VirtualThread to submit(ForkJoinTask) consistently. As part of the change, the acquire fence change to address [JDK-8372835](https://bugs.openjdk.org/browse/JDK-8372835) are proposed to be included, to avoid bringing back an issue that was fixed by JDK-8360046. So a somewhat complicated story due to jdk26 being in RDP1. > > > Testing: test1-5, repeat testing of java/util/concurrent and java/lang/Thread/virtual tests. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Change setParallelism to signalWork ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29187/files - new: https://git.openjdk.org/jdk/pull/29187/files/49339c3e..c89cab20 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29187&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29187&range=00-01 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29187.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29187/head:pull/29187 PR: https://git.openjdk.org/jdk/pull/29187 From rgiulietti at openjdk.org Wed Jan 14 09:01:29 2026 From: rgiulietti at openjdk.org (Raffaello Giulietti) Date: Wed, 14 Jan 2026 09:01:29 GMT Subject: RFR: 8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 05:59:54 GMT, Joe Darcy wrote: > Happened to notice the divideUnsigned and reminaderUnsigned methods don't document throwing ArithmeticException for a zero divisor so added I'm proposing to add the appropriate throws clauses. > The CSR is ready to review too. looks fine ------------- Marked as reviewed by rgiulietti (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29215#pullrequestreview-3659591250 From aph at openjdk.org Wed Jan 14 09:01:29 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 14 Jan 2026 09:01:29 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Tue, 13 Jan 2026 11:35:17 GMT, Ruben wrote: > From an initial experiment, is appears oopmap_index increments about every 8 instructions on average - though this observation might be specific to a certain workload. However, if that's the case, current implementation allows us to encode post-call NOPs metadata for offsets up to 8K. The above approach would be an improvement in this case: the MOVK/MOVZ-based chunks would allow us to encode the metadata for offsets up to 16K, while MOVN-based chunks would improve search for the rest of the cases. > > What do you think about this option? It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. Why not use MOVN, and put the data into a stub at the end of the nmethod? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3748496614 From vklang at openjdk.org Wed Jan 14 09:13:00 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 14 Jan 2026 09:13:00 GMT Subject: [jdk26] RFR: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks [v2] In-Reply-To: References: Message-ID: <8_iQwWbWCa-zqcllaE-Ic4glmjzlnN4syido8StKIlk=.dfeb8551-2984-4a95-999b-2bec508b34c7@github.com> On Wed, 14 Jan 2026 08:13:02 GMT, Alan Bateman wrote: >> This PR is for the jdk26 branch, not main line. >> >> The changes in [JDK-8360046](https://bugs.openjdk.org/browse/JDK-8360046) improve the scalability of virtual threads but introduce a subtle issue with signal filtering and a regression in some SPECjbb2015 runs. [pull/28797](https://git.openjdk.org/jdk/pull/28797) is in progress for main line to address these issues. >> >> For the jdk26 branch, the proposal is to backout the changes to ForkJoinPool from JDK-8360046 but leave the small change to setParallelism to trigger worker activation and the small change to VirtualThread to submit(ForkJoinTask) consistently. As part of the change, the acquire fence change to address [JDK-8372835](https://bugs.openjdk.org/browse/JDK-8372835) are proposed to be included, to avoid bringing back an issue that was fixed by JDK-8360046. So a somewhat complicated story due to jdk26 being in RDP1. >> >> >> Testing: test1-5, repeat testing of java/util/concurrent and java/lang/Thread/virtual tests. > > Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: > > Change setParallelism to signalWork Marked as reviewed by vklang (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29187#pullrequestreview-3659639975 From alanb at openjdk.org Wed Jan 14 09:15:56 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 09:15:56 GMT Subject: [jdk26] Integrated: 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 09:22:14 GMT, Alan Bateman wrote: > This PR is for the jdk26 branch, not main line. > > The changes in [JDK-8360046](https://bugs.openjdk.org/browse/JDK-8360046) improve the scalability of virtual threads but introduce a subtle issue with signal filtering and a regression in some SPECjbb2015 runs. [pull/28797](https://git.openjdk.org/jdk/pull/28797) is in progress for main line to address these issues. > > For the jdk26 branch, the proposal is to backout the changes to ForkJoinPool from JDK-8360046 but leave the small change to setParallelism to trigger worker activation and the small change to VirtualThread to submit(ForkJoinTask) consistently. As part of the change, the acquire fence change to address [JDK-8372835](https://bugs.openjdk.org/browse/JDK-8372835) are proposed to be included, to avoid bringing back an issue that was fixed by JDK-8360046. So a somewhat complicated story due to jdk26 being in RDP1. > > > Testing: test1-5, repeat testing of java/util/concurrent and java/lang/Thread/virtual tests. This pull request has now been integrated. Changeset: 283da4dd Author: Alan Bateman URL: https://git.openjdk.org/jdk/commit/283da4ddcbd7e0f46d996c698c9c7195c6545197 Stats: 467 lines in 2 files changed: 143 ins; 140 del; 184 mod 8375130: [BACKOUT] Scalability issue when submitting virtual threads with almost empty tasks Reviewed-by: vklang ------------- PR: https://git.openjdk.org/jdk/pull/29187 From anthonyv.be at outlook.com Wed Jan 14 10:01:31 2026 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Wed, 14 Jan 2026 11:01:31 +0100 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: <74591132-0606-4013-abab-5d71256d6f2a@oracle.com> References: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> <74591132-0606-4013-abab-5d71256d6f2a@oracle.com> Message-ID: On 1/14/2026 8:15 AM, Alan Bateman wrote: > On 13/01/2026 20:13, Anthony Vanelverdinghe wrote: >> There are 3 questions: >> >> (1) should we deprecate `Path::startsWith(String)`? >> (2) should we deprecate `Path::endsWith(String)`? >> (3) should we add a file extension API? >> > The "plan" is to deprecate startsWith(String) and endsWith(String), > and to reboot the effort to add the file extension API. > > -Alan Just for the record, emptying my bag of arguments: Google's Error Prone has a whole catalog of bug patterns, including confusing Java SE APIs. Shall we deprecate all of those as well then? And note that it does *not* have a bug pattern for `Path::{starts,ends}With`. So nobody at Google ever bothered to add it. And nobody outside Google ever bothered to file an issue to add it. (Same for SonarQube, SpotBugs, or FindBugs: no pattern for this.) Virtually every Java developer has made the mistake of using `Thread.sleep(5)` to mean "sleep 5 seconds" (which is the behavior in pretty much every shell). So why are we not deprecating that method then? Even `String::endsWith(String)` itself is confusing, since some people assume its argument is a regex (as with some other String methods like `matches`) [1]. So why not e.g., replace `String::matches(String)` with `String::matches(Pattern)`? [1] https://stackoverflow.com/questions/9943609/checking-if-string-ends-with-something-with-java-regex Anthony From mdoerr at openjdk.org Wed Jan 14 10:13:21 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 14 Jan 2026 10:13:21 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error In-Reply-To: References: Message-ID: <73nhI9qLs1GPuJq4OfNM2VTUg-QqNA4O-GZLUl-TYcY=.b247fd6e-d909-46c7-885a-01c0930a01e9@github.com> 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: It would be good to have someone from the VectorAPI folks to review it. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 3627: > 3625: VectorShuffle shuffle = normalizeSubLanesForSpecies(this.vspecies(), subLanesPerSrc); > 3626: return this.rearrange(shuffle); > 3627: } I think the code could be refactored such that we don't need copies of the `subLanesPerSrc` computation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3748781569 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2689795229 From alanb at openjdk.org Wed Jan 14 10:56:34 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 10:56:34 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v5] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: On Tue, 13 Jan 2026 18:00:23 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: > > Review suggestions to remove extra spaces, duplicate annotation, and > the last remaining use of PER_CLASS. test/jdk/java/io/Serializable/serialFilter/SerialFilterTest.java line 92: > 90: * @return an array of arrays of the parameters including factories > 91: */ > 92: static Object[][] patterns() { Maybe some future cleanup could change these method sources to return `Stream` instead of `Object[][]`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28877#discussion_r2689958445 From cushon at openjdk.org Wed Jan 14 10:59:32 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 14 Jan 2026 10:59:32 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/5c6c4f13..791954d6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=00-01 Stats: 36 lines in 1 file changed: 29 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Wed Jan 14 10:59:36 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 14 Jan 2026 10:59:36 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: <-qTE7Ac7lWOtINGFlc43ZX_fkW08IV8uHhqLX7q0K8I=.c8562893-8b3e-4940-909e-9dc14008dc74@github.com> References: <-qTE7Ac7lWOtINGFlc43ZX_fkW08IV8uHhqLX7q0K8I=.c8562893-8b3e-4940-909e-9dc14008dc74@github.com> Message-ID: On Tue, 13 Jan 2026 22:02:13 GMT, Roger Riggs wrote: > The test has an odd mix of throwing Exception and RuntimeException. It would be good to upgrade the test to use JUnit (though it could/should be a separate PR). It seemed like `test/jdk/java/lang/String/Encodings.java` mostly uses `Exception`, and `test/jdk/sun/nio/cs/TestStringCoding.java` mostly uses `RuntimeException`, I was trying to be consistent with the existing code. I can take a look at migrating to Junit as a separate cleanup. > src/java.base/share/classes/java/lang/String.java line 2112: > >> 2110: * >> 2111: *

The result will be the same value as {@code getBytes(charset).length}. >> 2112: * > > An @implNote or @apiNote maybe useful to indicate that this may allocate memory to compute the length for some Charsets. Done, thanks > src/java.base/share/classes/java/lang/String.java line 2120: > >> 2118: return encodedLengthUTF8(coder, value); >> 2119: } >> 2120: if (bytesCompatible(cs, 0, value.length)) { > > BytesCompatible gives a non-optimal answer for a US_ASCII input that has chars > 0x7f. I updated this to not use `bytesCompatible`, and optimized the US_ASCII case. > src/java.base/share/classes/java/lang/String.java line 2125: > >> 2123: if (cs instanceof sun.nio.cs.UTF_16LE || >> 2124: cs instanceof sun.nio.cs.UTF_16BE) { >> 2125: return value.length << (1 - coder()); > > Please encapsulate this computation `byteFor(int length, coder) {...}` to make it easier to re-use and document. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3748957104 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2689955692 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2689958009 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2689959343 From alanb at openjdk.org Wed Jan 14 11:02:18 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 11:02:18 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:22:33 GMT, Ioi Lam wrote: >> The bug is here on line 121: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 >> >> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 >> >> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. >> >> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @RogerRiggs I think this is an okay approach but it is inherently racy, and this is on top of the issues with async close of the streams. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29198#issuecomment-3748981061 From alanb at openjdk.org Wed Jan 14 11:02:21 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 11:02:21 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v5] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: <_cnEPb3U_8-W9IGhn5DZR89A_Q4IOVilPZPtbi86VPk=.3d95cc25-676b-4d1b-b7ea-e0ed0002f100@github.com> On Tue, 13 Jan 2026 18:00:23 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: > > Review suggestions to remove extra spaces, duplicate annotation, and > the last remaining use of PER_CLASS. I see Justin has done a detailed review so I think you are good to go. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28877#issuecomment-3748973619 From jbhateja at openjdk.org Wed Jan 14 11:02:26 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 14 Jan 2026 11:02:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 10:22:25 GMT, Fei Yang wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Adding testpoint for JDK-8373574 > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: > >> 1651: * >> 1652: * @param e the input scalar >> 1653: * @return the result of multiplying this vector by the given scalar > > The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? This is the problem in JDK-mainline code also, we should address it separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2689974123 From fyang at openjdk.org Wed Jan 14 11:14:06 2026 From: fyang at openjdk.org (Fei Yang) Date: Wed, 14 Jan 2026 11:14:06 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v11] In-Reply-To: References: Message-ID: <53ngdNhoWJy4Cacq2Xs1bC0ulSPPVcUdz6WoSb3Pp6U=.699dfca7-3a7c-4f6b-addb-3c26b8f4c357@github.com> On Wed, 14 Jan 2026 10:58:44 GMT, Jatin Bhateja wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16Vector.java line 1653: >> >>> 1651: * >>> 1652: * @param e the input scalar >>> 1653: * @return the result of multiplying this vector by the given scalar >> >> The code comment mentions "multiplying", which doesn't seem correct to me. Are we doing any multiplication for min/max? > > This is the problem in JDK-mainline code also, we should address it separately. Sure. I just realized that it is there for Float / Double varients as well in mainline. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2690008963 From pminborg at openjdk.org Wed Jan 14 11:21:28 2026 From: pminborg at openjdk.org (Per Minborg) Date: Wed, 14 Jan 2026 11:21:28 GMT Subject: RFR: 8374155: Add @AOTSafeClassInitializer to Record [v4] In-Reply-To: References: Message-ID: <-_hxaf2lfkrMsp3TzRwDWlriu3UMHoSSb-uqg5wqNWo=.dcb53190-b3f8-4313-a739-5b558a78101e@github.com> > This PR proposes to add the `@AOTSafeClassInitializer` annotation to the `Record` class. This allows user-created records to be annotated with `AOTSafeClassInitializer`. > > On multiple platforms, tested and passed: > - [x] tier1 > - [x] tier2 > - [x] tier3 > > Not tested: > - [ ] tier4 > - [ ] tier5 > - [ ] tier6 Per Minborg 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: - Add annotation in test - Merge branch 'master' into record-AOTSafeClassInitializer - Add a real test - Add a test - Annotate Record with AOTSafeClassInitializer ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29084/files - new: https://git.openjdk.org/jdk/pull/29084/files/898e1e41..3e9d6730 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29084&range=02-03 Stats: 35171 lines in 482 files changed: 22472 ins; 8151 del; 4548 mod Patch: https://git.openjdk.org/jdk/pull/29084.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29084/head:pull/29084 PR: https://git.openjdk.org/jdk/pull/29084 From alanb at openjdk.org Wed Jan 14 12:02:29 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 12:02:29 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v6] In-Reply-To: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> References: <10YcFooDOHT6M4PWRHBAUzYNhQW1X1nnaLPGIcDrgFE=.1e66f22a-8643-4ee1-bd88-e854fd4d48f7@github.com> Message-ID: On Fri, 9 Jan 2026 18:38:53 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > sperate VM.sec_props command I think the latest proposal with `jcmd VM.security_properties` looks reasonable. My guess is that many developers don't know about security properties, or might think they are system properties that do something magic with security. So I think expand the current help/description from "Print security properties" to include "java.security.Security" in the text so there is somewhere to go and learn what this is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3749232175 From dl at openjdk.org Wed Jan 14 12:38:53 2026 From: dl at openjdk.org (Doug Lea) Date: Wed, 14 Jan 2026 12:38:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v25] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Tue, 13 Jan 2026 15:57:34 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix missing undo > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2591: > >> 2589: unlockRunState(); >> 2590: } >> 2591: ForkJoinTask[] a; > > `a` is not used Thanks for finding remnants of incomplete undo/redos! > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2593: > >> 2591: ForkJoinTask[] a; >> 2592: if (q != null && (lock = q.tryLockPhase()) != 1) { >> 2593: int unlock = lock + NEXTIDLE; > > Suggestion: > > int unlock = lock + NEXTIDLE; Same > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2604: > >> 2602: throw new RejectedExecutionException(); >> 2603: } >> 2604: private void poolSubmit(ForkJoinTask task, boolean signalIfEmpty) { > > Suggestion: > > > private void poolSubmit(ForkJoinTask task, boolean signalIfEmpty) { And another one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690252073 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690253141 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690253986 From dl at openjdk.org Wed Jan 14 12:38:50 2026 From: dl at openjdk.org (Doug Lea) Date: Wed, 14 Jan 2026 12:38:50 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v23] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Mon, 12 Jan 2026 12:44:49 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 33 additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8373118 >> - reunify push; improve contention vs activation vs park balance >> - Undo unrelated change >> - Re-introduce acquiring array reads; re-arrange to rely on volatile base index >> - Change signalWork fencing; in-progress activation changes >> - Merge branch 'openjdk:master' into JDK-8373118 >> - Split external push >> - Undo/redo ordering changes >> - Strengthen some orderings >> - Merge branch 'openjdk:master' into JDK-8373118 >> - ... and 23 more: https://git.openjdk.org/jdk/compare/8e9ec950...f42d2475 > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1830: > >> 1828: int pc = parallelism, i, sp; // rely on caller sync for initial reads >> 1829: long c = U.getLong(this, CTL); >> 1830: WorkQueue[] qs = queues; > > If we only read this on entry, doesn't that risk not observing the number of queues growing? No, see your other comment :-) > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1854: > >> 1852: break; >> 1853: } >> 1854: qs = queues; > > Regarding https://github.com/openjdk/jdk/pull/28797/changes#r2682127585 , so we're refresh-reading it here, relying on (at least) the https://github.com/openjdk/jdk/pull/28797/changes#diff-e398beb49cd8d3e6c2f3a8ca8eee97172c57d7f88f3ccd8a3c704632cab32f5fR1844 load? Right. doing iit here also allows qs read and src read to be unordered ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690261219 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690259920 From dl at openjdk.org Wed Jan 14 12:41:50 2026 From: dl at openjdk.org (Doug Lea) Date: Wed, 14 Jan 2026 12:41:50 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] 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 set of contend vs deactivate vs park tradeoffs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/bb492a04..88f1466d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=24-25 Stats: 122 lines in 1 file changed: 49 ins; 41 del; 32 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 vklang at openjdk.org Wed Jan 14 13:05:28 2026 From: vklang at openjdk.org (Viktor Klang) Date: Wed, 14 Jan 2026 13:05:28 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 14 Jan 2026 12:41:50 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: > > Another set of contend vs deactivate vs park tradeoffs src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1988: > 1986: } > 1987: } > 1988: if (rescans > 0) If avoiding arithmetic turns out successful, we might just introduce `static final` constants and treat this as a regular state machine :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690340971 From jlahoda at openjdk.org Wed Jan 14 13:43:14 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 14 Jan 2026 13:43:14 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: <9Pqwk4JvBNxjlf3vozinYLbgKvT1IuZxSfV1-D1sGtY=.fd3fbfa3-4b42-43a2-9ec8-2adcf62c4229@github.com> On Tue, 13 Jan 2026 20:48:52 GMT, Johannes D?bler wrote: > > The SwitchBootstraps.enumSwitch is documented to throw a NullPointerException when lookup is null, but it does not throw the exception in all cases. > > Nothing against failing fast, but wouldn't this argumentation open a can of worms? The method documents that it can throw multiple exceptions but there is no guaranteed order of argument checking. So even if the method documents that it rejects a null `labels` parameter it is still valid to throw a IllegalArgumentException first when checking the `invocationType` parameter. The point of adding the explicit checks for `invocationType` and `labels` is to avoid the need to analyze the code/reason about the code to find out whether the check is carried or not. Because even for `lookup`, the code mostly seemed like it will throw NPE for `lookup == null`, but it didn't. And when explicitly checking `lookup`, it seems weird to not explicitly check all of them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29202#issuecomment-3749609146 From asemenyuk at openjdk.org Wed Jan 14 13:51:06 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 13:51:06 GMT Subject: Integrated: 8356684: jpackage error messages are not helpful In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 16:42:43 GMT, Alexey Semenyuk wrote: > If the output of an external command execution results in a fatal error, jpackage will print the command line of the external command. In quiet mode (without "--vrebose"), it will also print the command's output. > > E.g. (unit test output): > > jpackage --input MainTest\testFailedCommandOutput\input --dest MainTest\testFailedCommandOutput\output --name FailedCommandOutputMainTest --type app-image --main-jar hello.jar --main-class Hello --win-console > Error: Unexpected exit code 17 from executing the command jlink-mock --output MainTest\testFailedCommandOutput\output\FailedCommandOutputMainTest\runtime --module-path runtime\jmods --add-modules java.base,jdk.xml.dom,jdk.zipfs --strip-native-commands --strip-debug --no-man-pages --no-header-files > Command output: > It > fell > apart This pull request has now been integrated. Changeset: 703665c1 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/703665c13f754f3ba7858c4bb2549c76cbc22a62 Stats: 486 lines in 13 files changed: 413 ins; 47 del; 26 mod 8356684: jpackage error messages are not helpful Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29197 From dl at openjdk.org Wed Jan 14 14:03:16 2026 From: dl at openjdk.org (Doug Lea) Date: Wed, 14 Jan 2026 14:03:16 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 14 Jan 2026 13:01:14 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Another set of contend vs deactivate vs park tradeoffs > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1988: > >> 1986: } >> 1987: } >> 1988: if (rescans > 0) > > If avoiding arithmetic turns out successful, we might just introduce `static final` constants and treat this as a regular state machine :) Ideally, runWorker would take its original form: while(scanState != stop) scanState = scan(scanState, ...); But there are too many bits of state, and sometimes-slow encoding/decoding to do this. But I'll look into some compromises. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2690538961 From duke at openjdk.org Wed Jan 14 14:12:21 2026 From: duke at openjdk.org (Roger Calnan) Date: Wed, 14 Jan 2026 14:12:21 GMT Subject: Integrated: 8373836: add anchors to the java options in the java man page In-Reply-To: References: Message-ID: <9QDCTo1YDdU4RuJOU3mbU98ZbVFqaRc_zCU4lc8YVKE=.3d6bcb99-356f-4522-8fe1-955c2a05419e@github.com> On Mon, 22 Dec 2025 13:31:54 GMT, Roger Calnan wrote: > adjust each of the command line options to include an html anchor so that one can give a link that goes directly to the section in the man page that covers a specific option This pull request has now been integrated. Changeset: 20bd178b Author: Roger Calnan Committer: Jesper Wilhelmsson URL: https://git.openjdk.org/jdk/commit/20bd178b997b8bbf895877774d55d1a9e87c3038 Stats: 247 lines in 1 file changed: 0 ins; 0 del; 247 mod 8373836: add anchors to the java options in the java man page Reviewed-by: jwilhelm, iris ------------- PR: https://git.openjdk.org/jdk/pull/28954 From rriggs at openjdk.org Wed Jan 14 14:26:58 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 14:26:58 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v3] In-Reply-To: <1bPUqCHJXanDtoWURWX9kOrIK2zDhNn45oh07bfKR20=.9b07802c-d9ab-4817-9674-2744804a38a1@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> <1bPUqCHJXanDtoWURWX9kOrIK2zDhNn45oh07bfKR20=.9b07802c-d9ab-4817-9674-2744804a38a1@github.com> Message-ID: On Wed, 14 Jan 2026 07:28:44 GMT, Jaikiran Pai wrote: > I see that the test now uses `EnabledIf` from JUnit. Do you know if the test gets skipped then would it show up in the skipped count listed for the test: Yes, they show up as Skipped, manually verified by substituting a non-existent program. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29143#issuecomment-3749796741 From rriggs at openjdk.org Wed Jan 14 14:37:24 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 14:37:24 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:22:33 GMT, Ioi Lam wrote: >> The bug is here on line 121: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 >> >> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 >> >> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. >> >> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @RogerRiggs src/java.base/windows/classes/java/lang/ProcessImpl.java line 133: > 131: if (stdHandles[1] == -1L) { > 132: // FileDescriptor.out has been closed. > 133: f1 = setFileOutput(Redirect.DISCARD, stdHandles, 1); More compact yes, but I prefer to update local state inline, its easier to see the consistent pattern of state updates across the different cases. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2690701865 From rriggs at openjdk.org Wed Jan 14 14:43:44 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 14:43:44 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 03:22:33 GMT, Ioi Lam wrote: >> The bug is here on line 121: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 >> >> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 >> >> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. >> >> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Review comments from @RogerRiggs The change in behavior should be documented in an APINote on Process.inheritIO() to say that the output is discarded if it has been closed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29198#issuecomment-3749879254 From kfarrell at openjdk.org Wed Jan 14 15:31:21 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Wed, 14 Jan 2026 15:31:21 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: update to print java.security.Security properties ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/db9e0e97..bb3b243c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=05-06 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From cushon at openjdk.org Wed Jan 14 15:39:43 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Wed, 14 Jan 2026 15:39:43 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:59:32 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback I drafted a CSR: https://bugs.openjdk.org/browse/JDK-8375318 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3750134777 From asemenyuk at openjdk.org Wed Jan 14 16:18:33 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 16:18:33 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage Message-ID: Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). ------------- Commit messages: - Update copyright year - InOutPathTest: remove tests cases for non-existent paths specified for --app-content and --mac-dmg-content options; AppContentTest: add a test case for --app-content set to the output app image - FileUtils: remove redundant functionality - Add and integrate RootedPath - AppContentTest: don't verify app image if jpackage is expected to fail - Support two-step OptionValueConverter - Add ValueConverterFunction - Change signature of OptionValueConverter. - Validator, OptionValueConverter: better javadoc - Change signature of ValueConverter::convert() - ... and 2 more: https://git.openjdk.org/jdk/compare/20bd178b...46375e6f Changes: https://git.openjdk.org/jdk/pull/29194/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29194&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375323 Stats: 2000 lines in 45 files changed: 1420 ins; 293 del; 287 mod Patch: https://git.openjdk.org/jdk/pull/29194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29194/head:pull/29194 PR: https://git.openjdk.org/jdk/pull/29194 From asemenyuk at openjdk.org Wed Jan 14 16:18:33 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 16:18:33 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage In-Reply-To: References: Message-ID: <7qyLJqbzOzB20T-s1EsZcL237AOSormbwx067IWYp9s=.82cec17b-379e-4915-bc87-5023fc783889@github.com> On Tue, 13 Jan 2026 15:11:37 GMT, Alexey Semenyuk wrote: > Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. > > This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29194#issuecomment-3750327215 From asemenyuk at openjdk.org Wed Jan 14 16:24:23 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 16:24:23 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage [v2] In-Reply-To: References: Message-ID: > Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. > > This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). 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 12 new commits since the last revision: - Update copyright year - InOutPathTest: remove tests cases for non-existent paths specified for --app-content and --mac-dmg-content options; AppContentTest: add a test case for --app-content set to the output app image - FileUtils: remove redundant functionality - Add and integrate RootedPath - AppContentTest: don't verify app image if jpackage is expected to fail - Support two-step OptionValueConverter - Add ValueConverterFunction - Change signature of OptionValueConverter. - Validator, OptionValueConverter: better javadoc - Change signature of ValueConverter::convert() - ... and 2 more: https://git.openjdk.org/jdk/compare/46375e6f...5c47219b ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29194/files - new: https://git.openjdk.org/jdk/pull/29194/files/46375e6f..5c47219b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29194&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29194&range=00-01 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29194.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29194/head:pull/29194 PR: https://git.openjdk.org/jdk/pull/29194 From almatvee at openjdk.org Wed Jan 14 16:35:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 16:35:59 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Tue, 23 Dec 2025 03:58:32 GMT, Alexey Semenyuk wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - 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. @alexeysemenyukoracle Please review it again. I updated description with all changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3750426044 From naoto at openjdk.org Wed Jan 14 17:04:54 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jan 2026 17:04:54 GMT Subject: RFR: 8373913: Refactor serialization tests to use JUnit [v5] In-Reply-To: References: <4OS5_NcbHhpBnbvkKA7dQDMiWxengGolqDHnbqS_LRg=.37d2c88d-1d49-41e4-88cd-8a031cebf55b@github.com> Message-ID: <-GWFZp1QlRl1nlKcaS9uirjXeJbCzu5hMdyNjGNbz_I=.9eef9e12-e30b-40d7-b159-efe20128e784@github.com> On Tue, 13 Jan 2026 18:00:23 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: > > Review suggestions to remove extra spaces, duplicate annotation, and > the last remaining use of PER_CLASS. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28877#pullrequestreview-3661785414 From asemenyuk at openjdk.org Wed Jan 14 17:21:27 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 17:21:27 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v4] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: <6hqwmGBYixyu97N1088DbdeOih31Ws7i3elLVC19wk8=.662c45a6-8634-411e-9c3a-c44969552491@github.com> On Wed, 14 Jan 2026 04:55:05 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > Added missing import from merge Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 1: > 1: /* I suggest moving the license building code to a separate class. Say MacDmgLicense. This way, we will have the license-building code isolated in a separate class rather than a bunch of license-related methods scattered across the MacDmgPackager class. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist line 68: > 66: 5003 > 67: Name > 68: Chinese (Simplified) Shouldn't we have the values of the "Name" key localized too? ------------- PR Review: https://git.openjdk.org/jdk/pull/28959#pullrequestreview-3661821546 PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2691334472 PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2691322313 From asemenyuk at openjdk.org Wed Jan 14 17:25:00 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 17:25:00 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v4] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: On Wed, 14 Jan 2026 04:55:05 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > Added missing import from merge Shall we add an automated license test once we are touching this area? `/usr/bin/hdiutil attach` command should print the license to the console. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3750675133 From jlu at openjdk.org Wed Jan 14 18:03:53 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 Jan 2026 18:03:53 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v3] In-Reply-To: References: Message-ID: <6N8sTpB7AQ1NWO1YC85DktK5fF9hlHVHOQahHE_MjC8=.ee268852-4475-4361-9277-0000da2ba762@github.com> > This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. > The first commit is from the automated tool, the rest are manual changes done after. > > Before > ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit > StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit > Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit > > After > ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit > StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit > Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit Justin Lu has updated the pull request incrementally with two additional commits since the last revision: - Clean up data providers - Narrow down the scope of where the exception may occur ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29210/files - new: https://git.openjdk.org/jdk/pull/29210/files/dedfc033..8e50c6ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29210&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29210&range=01-02 Stats: 168 lines in 4 files changed: 32 ins; 70 del; 66 mod Patch: https://git.openjdk.org/jdk/pull/29210.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29210/head:pull/29210 PR: https://git.openjdk.org/jdk/pull/29210 From jlu at openjdk.org Wed Jan 14 18:03:55 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 14 Jan 2026 18:03:55 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v2] In-Reply-To: <28KO3c_cSbDadToTxzR1tehQDOwgEst19uBXOgP2iVU=.abdcd431-3207-47bb-9b28-fa5bc9981761@github.com> References: <28KO3c_cSbDadToTxzR1tehQDOwgEst19uBXOgP2iVU=.abdcd431-3207-47bb-9b28-fa5bc9981761@github.com> Message-ID: On Wed, 14 Jan 2026 07:32:42 GMT, Alan Bateman wrote: >> Justin Lu has updated the pull request incrementally with one additional commit since the last revision: >> >> Retain the removed whitespace in BadProvidersTest.java > > test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 142: > >> 140: >> 141: >> 142: public static Object[][] createBadFactories() { > > I assume the method source doesn't need to be public. Also it could be changed to return `Stream` and that would allow the "ignore" parameter to be dropped. Both true. Instead, I replaced the `MethodSource` with a `ValueSource` to simplify it further. > test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 173: > >> 171: // load providers and instantiate each one >> 172: loadProviders(mods, TEST1_MODULE).forEach(Provider::get); >> 173: }); > > The scope of the function passed to assertThrows is way too large. The code to compile the factory and copy the compiled class into the module should not be in this block. Was this tool or manual edit? Asking because we should only assert that the SL use throws ServiceConfigurationError. This is done by the tool, presumably because when testNG uses the `expectedExceptions` attribute, it permits the exception to be thrown _anywhere_ in the test, so the conversion tool is guranteeing that the JUnit replacement has the _exact_ same behavior. I agree we should narrow down the scope though. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2691483763 PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2691482346 From stuart.marks at oracle.com Wed Jan 14 18:20:19 2026 From: stuart.marks at oracle.com (Stuart Marks) Date: Wed, 14 Jan 2026 10:20:19 -0800 Subject: [External] : Re: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> Message-ID: <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com> You're making this too complicated. On their face, startsWith/endsWith(String) are misleading to both code authors and code readers, and that justifies their deprecation. It will help code authors avoid making new mistakes. Readers of code that uses these APIs -- even correctly -- can easily misinterpret the code as if it performed string-based testing and thus be misled about what the code is actually doing. In both cases, the code is better replaced with more explicit, if more verbose, alternatives that already exist. Certainly a file extension API would facilitate use cases that involve file extensions, such as inspecting a file's extension to determine how to process the file. I'm in favor of adding such an API. But that's a different topic from this one, and it should be handled independently. I did read all of your message but I'm not responding to most of it, because it doesn't establish a dependency between these two topics. s'marks On 1/13/26 12:13 PM, Anthony Vanelverdinghe wrote: > > There are 3 questions: > > (1) should we deprecate `Path::startsWith(String)`? > (2) should we deprecate `Path::endsWith(String)`? > (3) should we add a file extension API? > > And the TL;DR: no, no, yes. > > Let's first establish why `startsWith/endsWith` add tangible value: > because `path.startsWith("foo")` is not equivalent to > `path.startsWith(Path.of("foo"))` > and is much more readable than `path.startsWith(getFileSystem().getPath("foo"))`. > > Next, let's consider why people might want to use String-based > `startsWith/endsWith` testing on Path instances: > > * testing file extensions = 99.9999% of the times: covered by > `FileSystem::getPathMatcher` > * testing name elements = 0.0000999% of the times: covered by `Path` > * any other use cases = ~0% of the times: covered by `FileSystem::getPathMatcher` > > So it is always possible to do without String conversion. > In fact, it is arguably always a bad idea to do String-based testing, > because `path.toString().endsWith(".java")` will also match a file named ".java", > which on Linux-like OSes would be considered a hidden file named "java" that has > no file extension. > So using a dedicated `PathMatcher` for testing file extensions is more robust and > elegant. > > However, when testing file extensions we inevitably start by typing `path.` > (assuming we don't just use a third-party library), > first notice there's no method `getFileExtension` or such, > and then notice `endsWith(String)` > (and maybe we've also noticed `getFileName` and already have `path.getFileName().`). > At this point it's pure psychology: > we're looking for a method that behaves like String's `endsWith(String)`, > we're looking at a method with the same method signature, > and we can't imagine that the Path class does *not* have a method to test the > filename extension, > so surely this must be it. > And obviously we ignore any hints at the contrary > (like our IDE proposing both `endsWith(Path)` and `endsWith(String)` for > autocompletion). > And we don't bother to read the Javadoc, because in cases like this we can easily > verify our assumptions with JShell > and equally quickly realize our assumptions are wrong. > > So yes, this is a common mistake. But this is actually an argument for *not* > deprecating it. > Many developers have bumped into this, but as far as I can tell the mailing list > thread in September was the first in the existence of the API. > And I'm unable to find any previous bug reports either. > And here's why: when we realized our assumptions were wrong, we read the Javadoc, > realized our mistake, learned from it, and moved on. > The Javadoc is crystal-clear, the method overloads another method with the same > behavior, it clearly adds value over the other method. > In other words: we conclude "makes sense" and don't see any reason to complain. > > To turn this common mistake into a rare-if-ever mistake, I see two (combinable) > options: > > * introduce a file extension API > * replace `startsWith/endsWith` with methods `startsWithNames/endsWithNames` > > I don't consider deprecating `startsWith/endsWith` without replacement an option > because: > > * these methods add value (as was also argued by Rob Spoor), so it's a net loss > for the Java SE APIs. > And all the people that are happily using these methods today and are unaware of > this mailing list thread will be unpleasantly surprised to see it deprecated > * this means breaking compilation for everyone that builds with "-Werror" and "no > usage of deprecated APIs" is a very common policy. > So people will end up adding a duplicate of the deprecated methods in their own > utility libraries > * this trades one trap for another, much more subtle trap, since people will > blindly replace `"foo"` with `Path.of("foo")`. > (We're having this very discussion because people don't read Javadoc. > So surely we're not expecting people to read the deprecation text and follow the > recommendations, are we?) > Eventually they'll notice there's a bug, add `IO.println(foo)` and > `IO.println(Path.of("foo"))`, notice these both print "foo", > but somehow `foo.endsWith(Path.of("foo"))` results in `false`, eventually find the > culprit ... and then notice the deprecated `endsWith` method did exactly > what they wanted all along > * what would the rationale for the deprecation be? How would you document this in > the Javadoc? > Now you might still say: "People who were looking for a file extension API > regularly ended up here. If you're one of them, use Path::toString instead." > But once a file extension API will be available, it'll be extremely hard to come > up with a reasonable justification for the deprecation. > And as argued above, simple String-based comparisons are rarely, if ever, the most > robust solution > * for `startsWith` in particular: the only argument to deprecate it seems to be > "for the sake of symmetry" > > Anthony > > On 1/12/2026 8:36 PM, Stuart Marks wrote: >> >> Let's not tie these two issues together. >> >> The discussion clearly shows that the startsWith/endsWith(String) APIs are a trap >> that several people have fallen into. On that basis it should be deprecated. >> (Ordinarily, so as to emit a warning, and not for removal, so there won't be any >> compatibility issue.) >> >> There is also no requirement that a new API be introduced to replace any >> deprecated API. As the earlier discussion in the thread shows, both the >> path-based and the string-based use cases can be written using existing APIs, >> somewhat less conveniently and more verbosely; but these constructs are much more >> explicit and so are preferable to the APIs to be deprecated. The deprecation text >> should steer people toward the preferred constructs. >> >> It would indeed be nice to have a file extension API, but this has been discussed >> several times and has run aground each time for a variety of reasons. Tying these >> together will hold up the deprecation for no good reason. >> >> Let's proceed with just the deprecation first and work on the file extension API >> separately. >> >> s'marks >> >> On 1/11/26 12:45 PM, David Alayachew wrote: >>> Thanks for the response Anthony. Messages have been arriving out-of-order for >>> me, so I didn't see yours at the time of me writing that message. >>> >>> I think introducing the file extension API first, then gauging the need for a >>> deprecation before doing it is fine. Sounds like then that we are universally >>> agreed on the first step being to add the file extension API, yes? >>> >>> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe >>> wrote: >>> >>> I dissent. (Apparently my previous message wasn't clear.) >>> >>> The right order of things is to first introduce a file extension API. Then >>> see if there's still complaints about `Path::endsWith(String)`. And only >>> then, if there are, consider taking action. >>> >>> In my previous message I've already explained how these methods add real, >>> tangible value and actually are intuitive. >>> (Again, ask developers to guess how `A::foo(B)` behaves, given that both >>> `A::foo(A)` and `B::foo(B)` exist, and a large majority of them will >>> intuitively guess it converts its `b` argument to an instance of `A` and >>> passes it on to `A::foo(A)`. And their intuition would be correct in the >>> case of `Path::endsWith(String)`. That being said, I'll be the first to >>> admit that I've also made the mistake of attempting to use >>> `Path::endsWith(String)` to test the file extension.) >>> >>> In hindsight, maybe `endsWithNames(String)` would've been a better choice, >>> but hindsight is 20/20. >>> >>> Deprecating these methods now is premature. And deprecating them without >>> replacement methods would result in way more complaints than there have ever >>> been about `endsWith(String)`. >>> >>> Anthony >>> >>> On 1/11/2026 12:19 AM, David Alayachew wrote: >>>> Of course. >>>> >>>> I see lots of approvals and not really any dissenters. Are we waiting for >>>> more responses? Or is there anything we can do to kick start this? >>>> >>>> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter >>>> wrote: >>>> >>>> Thanks for the corroboration. >>>> >>>>> On Jan 8, 2026, at 1:50?PM, David Alayachew >>>>> wrote: >>>>> >>>>> Thanks for reviving this. >>>>> >>>>> I am perfectly happy with the idea of deprecating the >>>>> Path.{start,ends}With(String), and then only add the file extension >>>>> method. Originally, I didn't know that new method was on the table, so >>>>> I suggested a rename. But the file extension api feels like the >>>>> superior solution. >>>>> >>>>> 10 times out of 10, if I am calling endsWith, the only time I am not >>>>> looking for "whole" path elements is when I am looking for a file >>>>> extension. In every other instance, the api does exactly what I expect >>>>> and want. And plus, something like looking for a file extension is >>>>> better off being explicit. >>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From asemenyuk at openjdk.org Wed Jan 14 18:28:25 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 18:28:25 GMT Subject: RFR: 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException. Message-ID: Throw an exception with a proper message instead of "throw new AssertionError()" ------------- Commit messages: - 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException. Changes: https://git.openjdk.org/jdk/pull/29233/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29233&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373001 Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29233.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29233/head:pull/29233 PR: https://git.openjdk.org/jdk/pull/29233 From asemenyuk at openjdk.org Wed Jan 14 18:28:25 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 18:28:25 GMT Subject: RFR: 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException. In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 18:20:43 GMT, Alexey Semenyuk wrote: > Throw an exception with a proper message instead of "throw new AssertionError()" @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29233#issuecomment-3750982569 From darcy at openjdk.org Wed Jan 14 19:30:47 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 14 Jan 2026 19:30:47 GMT Subject: Integrated: 8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 05:59:54 GMT, Joe Darcy wrote: > Happened to notice the divideUnsigned and reminaderUnsigned methods don't document throwing ArithmeticException for a zero divisor so added I'm proposing to add the appropriate throws clauses. > The CSR is ready to review too. This pull request has now been integrated. Changeset: a7507ffa Author: Joe Darcy URL: https://git.openjdk.org/jdk/commit/a7507ffa1dda403110a61c4b61143b76e8a7911e Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod 8375237: Document existing exceptional behavior of divideUnsigned and remainderUnsigned Reviewed-by: rgiulietti ------------- PR: https://git.openjdk.org/jdk/pull/29215 From rriggs at openjdk.org Wed Jan 14 19:30:52 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 19:30:52 GMT Subject: Integrated: 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. This pull request has now been integrated. Changeset: 3007365b Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/3007365b73d400ee6a5ea9a9041899bb81cf357a Stats: 443 lines in 14 files changed: 89 ins; 87 del; 267 mod 8373913: Refactor serialization tests to use JUnit Reviewed-by: jlu, naoto ------------- PR: https://git.openjdk.org/jdk/pull/28877 From alanb at openjdk.org Wed Jan 14 19:39:22 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 19:39:22 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v3] In-Reply-To: <6N8sTpB7AQ1NWO1YC85DktK5fF9hlHVHOQahHE_MjC8=.ee268852-4475-4361-9277-0000da2ba762@github.com> References: <6N8sTpB7AQ1NWO1YC85DktK5fF9hlHVHOQahHE_MjC8=.ee268852-4475-4361-9277-0000da2ba762@github.com> Message-ID: <4IDUw5YDS4kP4qFqrTg66VWmsXzh-UNYshREWC30iDc=.cc5cb332-e412-4f21-99cd-d9f90e1a7816@github.com> On Wed, 14 Jan 2026 18:03:53 GMT, Justin Lu wrote: >> This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. >> The first commit is from the automated tool, the rest are manual changes done after. >> >> Before >> ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit >> StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit >> Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit >> >> After >> ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit >> StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit >> Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Clean up data providers > - Narrow down the scope of where the exception may occur Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29210#pullrequestreview-3662427971 From alanb at openjdk.org Wed Jan 14 19:39:25 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 14 Jan 2026 19:39:25 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v2] In-Reply-To: References: <28KO3c_cSbDadToTxzR1tehQDOwgEst19uBXOgP2iVU=.abdcd431-3207-47bb-9b28-fa5bc9981761@github.com> Message-ID: On Wed, 14 Jan 2026 17:58:36 GMT, Justin Lu wrote: >> test/jdk/java/util/ServiceLoader/BadProvidersTest.java line 173: >> >>> 171: // load providers and instantiate each one >>> 172: loadProviders(mods, TEST1_MODULE).forEach(Provider::get); >>> 173: }); >> >> The scope of the function passed to assertThrows is way too large. The code to compile the factory and copy the compiled class into the module should not be in this block. Was this tool or manual edit? Asking because we should only assert that the SL use throws ServiceConfigurationError. > > This is done by the tool, presumably because when testNG uses the `expectedExceptions` attribute, it permits the exception to be thrown _anywhere_ in the test, so the conversion tool is guranteeing that the JUnit replacement has the _exact_ same behavior. I agree we should narrow down the scope though. Okay, maybe not a good use of expectedExceptions because the scope is entire method. Your update looks good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29210#discussion_r2691772851 From almatvee at openjdk.org Wed Jan 14 20:16:54 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 20:16:54 GMT Subject: RFR: 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException. In-Reply-To: References: Message-ID: <8pRBd1Q8fM9B1jn_XSnnIWaDjr4ji-sjTeoMw5v4pLI=.a8024470-34b0-4ec1-96e4-6480810e276c@github.com> On Wed, 14 Jan 2026 18:20:43 GMT, Alexey Semenyuk wrote: > Throw an exception with a proper message instead of "throw new AssertionError()" Looks good. Can you fix: `Found trailing period in issue title for 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException.` before integration? ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29233#pullrequestreview-3662580746 From naoto at openjdk.org Wed Jan 14 20:57:18 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 14 Jan 2026 20:57:18 GMT Subject: RFR: 8375231: Refactor util/ServiceLoader tests to use JUnit [v3] In-Reply-To: <6N8sTpB7AQ1NWO1YC85DktK5fF9hlHVHOQahHE_MjC8=.ee268852-4475-4361-9277-0000da2ba762@github.com> References: <6N8sTpB7AQ1NWO1YC85DktK5fF9hlHVHOQahHE_MjC8=.ee268852-4475-4361-9277-0000da2ba762@github.com> Message-ID: On Wed, 14 Jan 2026 18:03:53 GMT, Justin Lu wrote: >> This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. >> The first commit is from the automated tool, the rest are manual changes done after. >> >> Before >> ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit >> StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit >> Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit >> >> After >> ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit >> StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit >> Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit > > Justin Lu has updated the pull request incrementally with two additional commits since the last revision: > > - Clean up data providers > - Narrow down the scope of where the exception may occur Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29210#pullrequestreview-3662734323 From asemenyuk at openjdk.org Wed Jan 14 21:41:04 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 21:41:04 GMT Subject: Integrated: 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 18:20:43 GMT, Alexey Semenyuk wrote: > Throw an exception with a proper message instead of "throw new AssertionError()" This pull request has now been integrated. Changeset: fb526c8f Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/fb526c8f45de6ca9a57608f728ac223cbca118be Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod 8373001: LauncherFromOptions.create() not properly handling FileAssociationNoExtensionsException Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29233 From asemenyuk at openjdk.org Wed Jan 14 22:12:34 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 22:12:34 GMT Subject: [jdk26] RFR: 8373448: jpackage: StackOverflowError when processing a very long argument Message-ID: Clean backport of the https://github.com/openjdk/jdk/pull/29104 PR ------------- Commit messages: - Backport 8737a8ca73952d60129e7fc2f7e17eea3b800af7 Changes: https://git.openjdk.org/jdk/pull/29238/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373448 Stats: 37 lines in 2 files changed: 31 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29238/head:pull/29238 PR: https://git.openjdk.org/jdk/pull/29238 From almatvee at openjdk.org Wed Jan 14 22:23:03 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 22:23:03 GMT Subject: [jdk26] RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:05:33 GMT, Alexey Semenyuk wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/29104 PR Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29238#pullrequestreview-3663082100 From asemenyuk at openjdk.org Wed Jan 14 22:23:04 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 22:23:04 GMT Subject: [jdk26] RFR: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:05:33 GMT, Alexey Semenyuk wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/29104 PR @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29238#issuecomment-3751953801 From asemenyuk at openjdk.org Wed Jan 14 22:48:17 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 22:48:17 GMT Subject: [jdk26] Integrated: 8373448: jpackage: StackOverflowError when processing a very long argument In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:05:33 GMT, Alexey Semenyuk wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/29104 PR This pull request has now been integrated. Changeset: 9f78c71f Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/9f78c71f88fc6b869f7494376e68d756e5c7a071 Stats: 37 lines in 2 files changed: 31 ins; 0 del; 6 mod 8373448: jpackage: StackOverflowError when processing a very long argument Reviewed-by: almatvee Backport-of: 8737a8ca73952d60129e7fc2f7e17eea3b800af7 ------------- PR: https://git.openjdk.org/jdk/pull/29238 From rriggs at openjdk.org Wed Jan 14 22:53:51 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 14 Jan 2026 22:53:51 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 10:59:32 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback src/java.base/share/classes/java/lang/String.java line 1080: > 1078: return value.length; > 1079: } > 1080: int len = value.length >> 1; I don't think I understand what's being done and what Charset encoder it is mimicking. It probably needs to document the assumptions about unmappable characters and malformed surrogates. (Likely it is correct since the test of US_ASCII passes, but could use an explanation). src/java.base/share/classes/java/lang/String.java line 2130: > 2128: > 2129: /** > 2130: * Returns the length in bytes of the given String encoded with the given {@link Charset}. You can use the javadoc tag `@return` and skip the duplication. This first sentence reads better then the @return below since it emphasies the "encoded string" aspect. src/java.base/share/classes/java/lang/String.java line 2136: > 2134: * @implNote This method may allocate memory to compute the length for some charsets. > 2135: * > 2136: * @param cs the charset used to the compute the length Capitalize and perhaps link "Charset". src/java.base/share/classes/java/lang/String.java line 2155: > 2153: } > 2154: > 2155: private int byteFor(int length, int coder) { Add a //comment please. The method name should be plural. `bytesForCoder`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2692343837 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2692299982 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2692301234 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2692304224 From almatvee at openjdk.org Wed Jan 14 23:12:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 23:12:59 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 16:24:23 GMT, Alexey Semenyuk wrote: >> Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. >> >> This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). > > 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 12 new commits since the last revision: > > - Update copyright year > - InOutPathTest: remove tests cases for non-existent paths specified for --app-content and --mac-dmg-content options; AppContentTest: add a test case for --app-content set to the output app image > - FileUtils: remove redundant functionality > - Add and integrate RootedPath > - AppContentTest: don't verify app image if jpackage is expected to fail > - Support two-step OptionValueConverter > - Add ValueConverterFunction > - Change signature of OptionValueConverter. > - Validator, OptionValueConverter: better javadoc > - Change signature of ValueConverter::convert() > - ... and 2 more: https://git.openjdk.org/jdk/compare/46375e6f...5c47219b Looks good with minor comment. src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties line 94: > 92: error.properties-parameter-not-path=The value "{0}" provided for property "{1}" in "{2}" file is not a valid path > 93: error.properties-parameter-not-file=The value "{0}" provided for property "{1}" in "{2}" file is not a file > 94: error.properties-parameter-not-directory=The value "{0}" provided for property "{1}" in "{2}" file is not a directory `file is not a directory` -> `is not a directory`? ------------- PR Review: https://git.openjdk.org/jdk/pull/29194#pullrequestreview-3663219254 PR Review Comment: https://git.openjdk.org/jdk/pull/29194#discussion_r2692370671 From almatvee at openjdk.org Wed Jan 14 23:19:11 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 23:19:11 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v4] In-Reply-To: <6hqwmGBYixyu97N1088DbdeOih31Ws7i3elLVC19wk8=.662c45a6-8634-411e-9c3a-c44969552491@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <6hqwmGBYixyu97N1088DbdeOih31Ws7i3elLVC19wk8=.662c45a6-8634-411e-9c3a-c44969552491@github.com> Message-ID: On Wed, 14 Jan 2026 17:11:32 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> Added missing import from merge > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist line 68: > >> 66: 5003 >> 67: Name >> 68: Chinese (Simplified) > > Shouldn't we have the values of the "Name" key localized too? No. It is internal and not being displayed to user. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692401595 From asemenyuk at openjdk.org Wed Jan 14 23:22:26 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 23:22:26 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:00:29 GMT, Alexander Matveev wrote: >> 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 12 new commits since the last revision: >> >> - Update copyright year >> - InOutPathTest: remove tests cases for non-existent paths specified for --app-content and --mac-dmg-content options; AppContentTest: add a test case for --app-content set to the output app image >> - FileUtils: remove redundant functionality >> - Add and integrate RootedPath >> - AppContentTest: don't verify app image if jpackage is expected to fail >> - Support two-step OptionValueConverter >> - Add ValueConverterFunction >> - Change signature of OptionValueConverter. >> - Validator, OptionValueConverter: better javadoc >> - Change signature of ValueConverter::convert() >> - ... and 2 more: https://git.openjdk.org/jdk/compare/46375e6f...5c47219b > > src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/MainResources.properties line 94: > >> 92: error.properties-parameter-not-path=The value "{0}" provided for property "{1}" in "{2}" file is not a valid path >> 93: error.properties-parameter-not-file=The value "{0}" provided for property "{1}" in "{2}" file is not a file >> 94: error.properties-parameter-not-directory=The value "{0}" provided for property "{1}" in "{2}" file is not a directory > > `file is not a directory` -> `is not a directory`? The "file" refers to the input property file. E.g.: for `jpackage --add-launcher=foo.properties` command line, if the `foo.properties` file contains a property `input` with the value of "not-a-directory" that should be a directory, then the error message will be: Error: The value "not-a-directory" provided for property "input" in "foo.properties" file is not a directory The wording is consistent with the similar error messages. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29194#discussion_r2692403490 From psandoz at openjdk.org Wed Jan 14 23:24:05 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 14 Jan 2026 23:24:05 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: References: Message-ID: <0Q-cAI_GZLJrFFrdn9Jvh0wdii9nNxGDRDCHFRqyPk4=.4776099c-7226-47e9-b7a5-a2eead4e0358@github.com> On Tue, 13 Jan 2026 17:37:25 GMT, Paul Sandoz wrote: >> This looks good. Before we integrate we will run it through our test system and report back to you. > >> Hi @PaulSandoz , if you?ve already had a chance to run the tests, could you let me know how they turned out? Thanks~ > > Yes, all good! > @PaulSandoz Since this is correctness bug fix, p3 priority. I think we should backport the fix to JDK26 and JDK25, right ? JDK24 has been archived, no need to backport to it. Given the Vector API is an incubating feature I would not considered it as urgent as if a final feature, but given the nature of the bug I have no objections to backporting and the risk seems minimal. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3752152512 From asemenyuk at openjdk.org Wed Jan 14 23:25:18 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 23:25:18 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v4] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <6hqwmGBYixyu97N1088DbdeOih31Ws7i3elLVC19wk8=.662c45a6-8634-411e-9c3a-c44969552491@github.com> Message-ID: On Wed, 14 Jan 2026 23:16:12 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/resources/lic_template.plist line 68: >> >>> 66: 5003 >>> 67: Name >>> 68: Chinese (Simplified) >> >> Shouldn't we have the values of the "Name" key localized too? > > No. It is internal and not being displayed to user. Please document it in the comment ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692410001 From almatvee at openjdk.org Wed Jan 14 23:28:54 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 23:28:54 GMT Subject: [jdk26] RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil Message-ID: Clean backport of the https://github.com/openjdk/jdk/pull/28912 PR. ------------- Commit messages: - Backport 2d0928406027a848cf2d2d0574024970b8fb535c Changes: https://git.openjdk.org/jdk/pull/29239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373105 Stats: 8 lines in 1 file changed: 6 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29239/head:pull/29239 PR: https://git.openjdk.org/jdk/pull/29239 From almatvee at openjdk.org Wed Jan 14 23:28:54 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 23:28:54 GMT Subject: [jdk26] RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:18:08 GMT, Alexander Matveev wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/28912 PR. @alexeysemenyukoracle Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29239#issuecomment-3752163948 From asemenyuk at openjdk.org Wed Jan 14 23:35:17 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Wed, 14 Jan 2026 23:35:17 GMT Subject: [jdk26] RFR: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:18:08 GMT, Alexander Matveev wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/28912 PR. Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29239#pullrequestreview-3663294268 From almatvee at openjdk.org Wed Jan 14 23:39:44 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Wed, 14 Jan 2026 23:39:44 GMT Subject: [jdk26] Integrated: 8373105: Test tools/jpackage/share/AsyncTest.java failed: problem running hdiutil In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 23:18:08 GMT, Alexander Matveev wrote: > Clean backport of the https://github.com/openjdk/jdk/pull/28912 PR. This pull request has now been integrated. Changeset: f4ddafcd Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/f4ddafcd7073994e9b6672df79128c9474b45dcd 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 Backport-of: 2d0928406027a848cf2d2d0574024970b8fb535c ------------- PR: https://git.openjdk.org/jdk/pull/29239 From almatvee at openjdk.org Thu Jan 15 00:46:55 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 00:46:55 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v5] 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: <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> > - Fixed plist file so translation works. It did not worked before. > - All strings which needs translations moved to .properties files. > - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. > - I tested all translations. > - Adding same license text for all translations is required. > - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8374215: [macos] Clean "lic_template.plist" [v3] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28959/files - new: https://git.openjdk.org/jdk/pull/28959/files/3acafc5a..66b483ec Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=03-04 Stats: 214 lines in 5 files changed: 140 ins; 70 del; 4 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 almatvee at openjdk.org Thu Jan 15 00:46:56 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 00:46:56 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v4] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> Message-ID: <7HShijl3SoVszJef9aJW4jxVoZuSXWzVZHlW2HhGQCQ=.c21e5c32-f358-479e-b320-a6313348a1cd@github.com> On Wed, 14 Jan 2026 04:55:05 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > Added missing import from merge 8374215: [macos] Clean "lic_template.plist" [v3] - Moved DMG license related code to `MacDmgLicense`. - Added DMG license verification code to `LicenseTest.java`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3752346622 From asemenyuk at openjdk.org Thu Jan 15 01:33:36 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 01:33:36 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v5] In-Reply-To: <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> Message-ID: On Thu, 15 Jan 2026 00:46:55 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8374215: [macos] Clean "lic_template.plist" [v3] Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java line 43: > 41: final class MacDmgLicense { > 42: > 43: public static void prepareLicense(MacDmgPackage pkg, BuildEnv env, It is hard to tell from the method's signature what its inputs and outputs are. It is only clear that it somehow prepares the license. Sometimes it does not, but this becomes clear only after reading the code. The `env` parameter is only used to create an `OveridableResource` instance. That said, I suggest changing the signature to: public static void prepareLicense(Path inputLicenseFile, Path outputLicenseFile) throws IOException; And in the body replace env.createResource(DEFAULT_LICENSE_PLIST) ``` with new OverridableResource(DEFAULT_LICENSE_PLIST, ResourceLocator.class) If the package is configured without the license, `MacDmgLicense.prepareLicense()` should not be called. src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java line 107: > 105: } > 106: > 107: private static final String DEFAULT_LICENSE_PLIST="lic_template.plist"; Missing spaces: `T="` -> `T = "` ------------- PR Review: https://git.openjdk.org/jdk/pull/28959#pullrequestreview-3663496711 PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692614897 PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692616145 From almatvee at openjdk.org Thu Jan 15 01:53:02 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 01:53:02 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v5] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> Message-ID: On Thu, 15 Jan 2026 01:22:08 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374215: [macos] Clean "lic_template.plist" [v3] > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java line 43: > >> 41: final class MacDmgLicense { >> 42: >> 43: public static void prepareLicense(MacDmgPackage pkg, BuildEnv env, > > It is hard to tell from the method's signature what its inputs and outputs are. It is only clear that it somehow prepares the license. Sometimes it does not, but this becomes clear only after reading the code. > > The `env` parameter is only used to create an `OveridableResource` instance. > > That said, I suggest changing the signature to: > > public static void prepareLicense(Path inputLicenseFile, Path outputLicenseFile) throws IOException; > > > And in the body replace > > env.createResource(DEFAULT_LICENSE_PLIST) > ``` > with > > new OverridableResource(DEFAULT_LICENSE_PLIST, ResourceLocator.class) > > > If the package is configured without the license, `MacDmgLicense.prepareLicense()` should not be called. How about: `public static void prepareLicensePListFile(Path licenseFile, Path licensePListFile) throws IOException;` It creates PList file from input license. Also, I will rename `licenseFile()` to `licensePListFile()`, otherwise proposed call will look like `MacDmgLicense.prepareLicense(pkg.licenseFile(), licenseFile());` vs `MacDmgLicense.prepareLicensePListFile(pkg.licenseFile(), licensePListFile());`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692666167 From almatvee at openjdk.org Thu Jan 15 02:27:41 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 02:27:41 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v6] 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: <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> > - Fixed plist file so translation works. It did not worked before. > - All strings which needs translations moved to .properties files. > - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. > - I tested all translations. > - Adding same license text for all translations is required. > - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8374215: [macos] Clean lic_template.plist [v4] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28959/files - new: https://git.openjdk.org/jdk/pull/28959/files/66b483ec..c1b9cd8b Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28959&range=04-05 Stats: 17 lines in 2 files changed: 2 ins; 5 del; 10 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 almatvee at openjdk.org Thu Jan 15 02:27:43 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 02:27:43 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v5] In-Reply-To: <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> Message-ID: <_L88FvfvSfi7TkelnoCxUZSUtYIFvtZZDAaEcCMao1w=.facdc338-f864-4ddd-9b37-e8376d2ef062@github.com> On Thu, 15 Jan 2026 00:46:55 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8374215: [macos] Clean "lic_template.plist" [v3] 8374215: [macos] Clean "lic_template.plist" [v4] - Renamed `prepareLicense()` to `prepareLicensePListFile()` and `licenseFile()` to `licensePListFile()`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28959#issuecomment-3752568848 From asemenyuk at openjdk.org Thu Jan 15 02:27:45 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 02:27:45 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v5] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <-ocfJLuYuQ75ejSKkCf2LAt_xSIS9pvIOB_9WYhShP0=.695bc369-3a9f-41b3-b102-5efc0e98cbd1@github.com> Message-ID: <7Fqt50iqqi6xIkE2qOq0siKvd8wHag6l2MVYzdwqigo=.fe0ceb27-9ed9-4aab-a1fa-424757edef6d@github.com> On Thu, 15 Jan 2026 01:50:53 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgLicense.java line 43: >> >>> 41: final class MacDmgLicense { >>> 42: >>> 43: public static void prepareLicense(MacDmgPackage pkg, BuildEnv env, >> >> It is hard to tell from the method's signature what its inputs and outputs are. It is only clear that it somehow prepares the license. Sometimes it does not, but this becomes clear only after reading the code. >> >> The `env` parameter is only used to create an `OveridableResource` instance. >> >> That said, I suggest changing the signature to: >> >> public static void prepareLicense(Path inputLicenseFile, Path outputLicenseFile) throws IOException; >> >> >> And in the body replace >> >> env.createResource(DEFAULT_LICENSE_PLIST) >> ``` >> with >> >> new OverridableResource(DEFAULT_LICENSE_PLIST, ResourceLocator.class) >> >> >> If the package is configured without the license, `MacDmgLicense.prepareLicense()` should not be called. > > How about: `public static void prepareLicensePListFile(Path licenseFile, Path licensePListFile) throws IOException;` > It creates PList file from input license. Also, I will rename `licenseFile()` to `licensePListFile()`, otherwise proposed call will look like `MacDmgLicense.prepareLicense(pkg.licenseFile(), licenseFile());` vs `MacDmgLicense.prepareLicensePListFile(pkg.licenseFile(), licensePListFile());`. Agreed! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692735158 From asemenyuk at openjdk.org Thu Jan 15 02:31:29 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 02:31:29 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v6] In-Reply-To: <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> Message-ID: On Thu, 15 Jan 2026 02:27:41 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8374215: [macos] Clean lic_template.plist [v4] src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 190: > 188: if (pkg.licenseFile().isPresent()) { > 189: MacDmgLicense.prepareLicensePListFile(pkg.licenseFile().get(), licensePListFile()); > 190: } Isn't the following easier to read? pkg.licenseFile().ifPresent(licenseFile -> { MacDmgLicense.prepareLicensePListFile(licenseFile, licensePListFile()); }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692741856 From almatvee at openjdk.org Thu Jan 15 02:41:07 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 02:41:07 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v6] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> Message-ID: On Thu, 15 Jan 2026 02:28:01 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8374215: [macos] Clean lic_template.plist [v4] > > src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 190: > >> 188: if (pkg.licenseFile().isPresent()) { >> 189: MacDmgLicense.prepareLicensePListFile(pkg.licenseFile().get(), licensePListFile()); >> 190: } > > Isn't the following easier to read? > > pkg.licenseFile().ifPresent(licenseFile -> { > MacDmgLicense.prepareLicensePListFile(licenseFile, licensePListFile()); > }); We should catch exception, so not sure if it is easy to read. I do not have exact opinion on this one. If you think it is better to use `ifPresent` I will change it. pkg.licenseFile().ifPresent(licenseFile -> { try { MacDmgLicense.prepareLicensePListFile(licenseFile, licensePListFile()); } catch (IOException ex) { throw new UncheckedIOException(ex); } }); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692755753 From asemenyuk at openjdk.org Thu Jan 15 02:49:51 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 02:49:51 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v6] In-Reply-To: <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> Message-ID: On Thu, 15 Jan 2026 02:27:41 GMT, Alexander Matveev wrote: >> - Fixed plist file so translation works. It did not worked before. >> - All strings which needs translations moved to .properties files. >> - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. >> - I tested all translations. >> - Adding same license text for all translations is required. >> - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. >> - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8374215: [macos] Clean lic_template.plist [v4] Marked as reviewed by asemenyuk (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28959#pullrequestreview-3663715001 From asemenyuk at openjdk.org Thu Jan 15 02:49:53 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 02:49:53 GMT Subject: RFR: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages [v6] In-Reply-To: References: <6FcV-8El2hA_KtKIE4X0Vl1CzOm_Q5jKhnGRnLfXkuQ=.4e9ac663-4118-4f5e-9bdf-0e63a939a6cf@github.com> <4PxtYNGSViB6ZhSJ5brlDnUxLSW11fr8lX2I5u-__ms=.4200ab27-895e-4faa-a4ce-b400947f92a8@github.com> Message-ID: On Thu, 15 Jan 2026 02:36:49 GMT, Alexander Matveev wrote: >> src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java line 190: >> >>> 188: if (pkg.licenseFile().isPresent()) { >>> 189: MacDmgLicense.prepareLicensePListFile(pkg.licenseFile().get(), licensePListFile()); >>> 190: } >> >> Isn't the following easier to read? >> >> pkg.licenseFile().ifPresent(licenseFile -> { >> MacDmgLicense.prepareLicensePListFile(licenseFile, licensePListFile()); >> }); > > We should catch exception, so not sure if it is easy to read. I do not have exact opinion on this one. If you think it is better to use `ifPresent` I will change it. > > pkg.licenseFile().ifPresent(licenseFile -> { > try { > MacDmgLicense.prepareLicensePListFile(licenseFile, licensePListFile()); > } catch (IOException ex) { > throw new UncheckedIOException(ex); > } > }); Ah, right, that checked exception. Scratch it then ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28959#discussion_r2692776928 From asemenyuk at openjdk.org Thu Jan 15 03:35:51 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 03:35:51 GMT Subject: RFR: 8375364: Some jpackage signing tests fail after JDK-8375240 Message-ID: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> Fix a regression from the JDK-8375240 ------------- Commit messages: - 8375364: Some jpackage signing tests fail after JDK-8375240 Changes: https://git.openjdk.org/jdk/pull/29241/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29241&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375364 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29241/head:pull/29241 PR: https://git.openjdk.org/jdk/pull/29241 From asemenyuk at openjdk.org Thu Jan 15 03:35:52 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 03:35:52 GMT Subject: RFR: 8375364: Some jpackage signing tests fail after JDK-8375240 In-Reply-To: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> References: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> Message-ID: On Thu, 15 Jan 2026 03:28:20 GMT, Alexey Semenyuk wrote: > Fix a regression from the JDK-8375240 @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29241#issuecomment-3752747266 From asemenyuk at openjdk.org Thu Jan 15 03:39:01 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 03:39:01 GMT Subject: RFR: 8375242: Improve jpackage signing coverage Message-ID: Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). Old test signatures: SigningAppImageTest.test(true, true, ASCII_INDEX) SigningAppImageTest.test(true, true, UNICODE_INDEX) SigningAppImageTest.test(true, false, UNICODE_INDEX) SigningAppImageTest.test(false, true, INVALID_INDEX) SigningAppImageTwoStepsTest.test(true, true) SigningAppImageTwoStepsTest.test(true, false) SigningAppImageTwoStepsTest.test(false, true) SigningPackageTest.test(true, true, true, ASCII_INDEX) SigningPackageTest.test(true, true, true, UNICODE_INDEX) SigningPackageTest.test(false, true, true, UNICODE_INDEX) SigningPackageTest.test(false, true, false, UNICODE_INDEX) SigningPackageTest.test(false, false, true, UNICODE_INDEX) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) SigningRuntimeImagePackageTest.test(true, INVALID_INDEX, INVALID_INDEX) SigningRuntimeImagePackageTest.test(true, INVALID_INDEX, ASCII_INDEX) SigningRuntimeImagePackageTest.test(true, UNICODE_INDEX, INVALID_INDEX) SigningRuntimeImagePackageTest.test(true, UNICODE_INDEX, ASCII_INDEX) SigningRuntimeImagePackageTest.test(false, INVALID_INDEX, INVALID_INDEX) SigningRuntimeImagePackageTest.test(false, INVALID_INDEX, ASCII_INDEX) New test signatures: SigningAppImageTest.test({--mac-signing-key-user-name: CODESIGN}@jpackagerTest.keychain) SigningAppImageTest.test({--mac-signing-key-user-name/full: CODESIGN}@jpackagerTest.keychain) SigningAppImageTest.test({--mac-app-image-sign-identity: CODESIGN}@jpackagerTest.keychain) SigningAppImageTest.test({--mac-signing-key-user-name: CODESIGN_UNICODE}@jpackagerTest.keychain) SigningAppImageTest.test({--mac-signing-key-user-name/full: CODESIGN_UNICODE}@jpackagerTest.keychain) SigningAppImageTest.test({--mac-app-image-sign-identity: CODESIGN_UNICODE}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image=unsigned; {--mac-signing-key-user-name: CODESIGN}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image=unsigned; {--mac-signing-key-user-name/full: CODESIGN}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image=unsigned; {--mac-app-image-sign-identity: CODESIGN}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image={--mac-app-image-sign-identity: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-signing-key-user-name: CODESIGN}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image={--mac-app-image-sign-identity: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-signing-key-user-name/full: CODESIGN}@jpackagerTest.keychain) SigningAppImageTwoStepsTest.test(app-image={--mac-app-image-sign-identity: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-app-image-sign-identity: CODESIGN}@jpackagerTest.keychain) SigningPackageTest.test({--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningPackageTest.test({--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningPackageTest.test({--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningPackageTest.test({--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningPackageTest.test({--mac-installer-sign-identity: PKG}, MAC_PKG) SigningPackageTest.test({--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) SigningPackageTest.test({--mac-signing-key-user-name: CODESIGN_UNICODE}, MAC_DMG) SigningPackageTest.test({--mac-signing-key-user-name: CODESIGN_UNICODE}, {--mac-signing-key-user-name: PKG_UNICODE}, MAC_DMG+MAC_PKG) SigningPackageTest.test({--mac-signing-key-user-name/full: CODESIGN_UNICODE}, MAC_DMG) SigningPackageTest.test({--mac-app-image-sign-identity: CODESIGN_UNICODE}, MAC_DMG+MAC_PKG) SigningPackageTest.test({--mac-installer-sign-identity: PKG_UNICODE}, MAC_PKG) SigningPackageTest.test({--mac-app-image-sign-identity: CODESIGN_UNICODE}, {--mac-installer-sign-identity: PKG_UNICODE}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.testBundleSignedAppImage SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-installer-sign-identity: PKG}, MAC_PKG) SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain; {--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-installer-sign-identity: PKG}, MAC_PKG) SigningPackageTwoStepTest.test(app-image=unsigned; {--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.testBundleSignedRuntime() SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-installer-sign-identity: PKG}, MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={IMAGE}; {--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-installer-sign-identity: PKG}, MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE}; {--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-signing-key-user-name: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-signing-key-user-name: CODESIGN}, {--mac-signing-key-user-name: PKG}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-signing-key-user-name/full: CODESIGN}, MAC_DMG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-app-image-sign-identity: CODESIGN}, MAC_DMG+MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-installer-sign-identity: PKG}, MAC_PKG) SigningRuntimeImagePackageTest.test(runtime={BUNDLE, {--mac-signing-key-user-name: CODESIGN_ACME_TECH_LTD}@jpackagerTest.keychain}; {--mac-app-image-sign-identity: CODESIGN}, {--mac-installer-sign-identity: PKG}, MAC_DMG+MAC_PKG) MacSignTest.java and EntitlementsTest.java tests refactored without functional changes. Additionally: - Move "SigningBase.java" to the correct location in the test source tree. Blocked by https://github.com/openjdk/jdk/pull/29241 PR. ------------- Commit messages: - SigningPackageTest: fix the test selector - SigningRuntimeImagePackageTest: remove redundant test cases and improve performance - Make JPackageCommand.createInputRuntimeImage() and MacHelper.createRuntimeBundle() configurable - Undo 8371438 - Update copyright year - Add MacHelper.NamedCertificateRequestSupplier; Use MacHelper.SignKeyOption.Type.SIGN_KEY_USER_FULL_NAME; add SignKeyOption.Name enum; streamline MacSignTest and MacHelper.SignKeyOption - Document MacHelper.SignKeyOption.Type; rename MacHelper.SignKeyOption.Type.SIGN_KEY_USER_NAME into MacHelper.SignKeyOption.Type.SIGN_KEY_USER_SHORT_NAME - SigningPackageTest: simplify - Add MacHelper.ResolvableCertificateRequest class; add SignKeyOption.asCmdlineArgs() - Refactor signing tests to support --mac-sign without signing key option and improve test coverage; Move SigningBase.java to the correct location in the source tree. - ... and 3 more: https://git.openjdk.org/jdk/compare/20bd178b...f55906bc Changes: https://git.openjdk.org/jdk/pull/29205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375242 Stats: 1943 lines in 13 files changed: 974 ins; 550 del; 419 mod Patch: https://git.openjdk.org/jdk/pull/29205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29205/head:pull/29205 PR: https://git.openjdk.org/jdk/pull/29205 From asemenyuk at openjdk.org Thu Jan 15 03:39:02 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 03:39:02 GMT Subject: RFR: 8375242: Improve jpackage signing coverage In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:23:00 GMT, Alexey Semenyuk wrote: > Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). > > Old test signatures: > > SigningAppImageTest.test(true, true, ASCII_INDEX) > SigningAppImageTest.test(true, true, UNICODE_INDEX) > SigningAppImageTest.test(true, false, UNICODE_INDEX) > SigningAppImageTest.test(false, true, INVALID_INDEX) > > SigningAppImageTwoStepsTest.test(true, true) > SigningAppImageTwoStepsTest.test(true, false) > SigningAppImageTwoStepsTest.test(false, true) > > SigningPackageTest.test(true, true, true, ASCII_INDEX) > SigningPackageTest.test(true, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, false, UNICODE_INDEX) > SigningPackageTest.test(false, false, true, UNICODE_INDEX) > > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > > SigningRuntimeImagePackageTest.test(true, INVALID_INDEX,... @sashamatveev PTAL ------------- PR Comment: https://git.openjdk.org/jdk/pull/29205#issuecomment-3752758694 From almatvee at openjdk.org Thu Jan 15 03:57:28 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Thu, 15 Jan 2026 03:57:28 GMT Subject: Integrated: 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages 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: > - Fixed plist file so translation works. It did not worked before. > - All strings which needs translations moved to .properties files. > - Added translated strings, since it is required to have all of them. We cannot have English strings in localized files, since different charset is required for each language. > - I tested all translations. > - Adding same license text for all translations is required. > - See JBS for screenshot of dialog. It is same except it now has drop down box with 4 languages we support. There are no way to remove it once translations implemented correctly in plist file. > - NOTE: License dialog for DMG was deprecated since macOS 12. Also, there are no alternative for it. This pull request has now been integrated. Changeset: 499b5882 Author: Alexander Matveev URL: https://git.openjdk.org/jdk/commit/499b58820225eb96c728816af9ea2ade47d1fc6b Stats: 365 lines in 9 files changed: 173 ins; 160 del; 32 mod 8374215: [macos] Clean and fix "lic_template.plist" to correctly work with multiple languages Reviewed-by: asemenyuk ------------- PR: https://git.openjdk.org/jdk/pull/28959 From erfang at openjdk.org Thu Jan 15 04:27:34 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 15 Jan 2026 04:27:34 GMT Subject: RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions [v6] In-Reply-To: <0Q-cAI_GZLJrFFrdn9Jvh0wdii9nNxGDRDCHFRqyPk4=.4776099c-7226-47e9-b7a5-a2eead4e0358@github.com> References: <0Q-cAI_GZLJrFFrdn9Jvh0wdii9nNxGDRDCHFRqyPk4=.4776099c-7226-47e9-b7a5-a2eead4e0358@github.com> Message-ID: On Wed, 14 Jan 2026 23:19:49 GMT, Paul Sandoz wrote: > > @PaulSandoz Since this is correctness bug fix, p3 priority. I think we should backport the fix to JDK26 and JDK25, right ? JDK24 has been archived, no need to backport to it. > > Given the Vector API is an incubating feature I would not considered it as urgent as if a final feature, but given the nature of the bug I have no objections to backporting and the risk seems minimal. Considering we've already backported a test bug fix for the vector API to JDK26, and this is a functional correctness fix, I'd prefer to backport it. Thanks for your insight. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28692#issuecomment-3752850291 From vpaprotski at openjdk.org Thu Jan 15 04:33:45 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 15 Jan 2026 04:33:45 GMT Subject: RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings Message-ID: Failure always for UU case, needle=2, len=17 - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) Following down the code layout: if len==0 return 0 if len>needle return -1 if len<=16|32 && needle<=3|6 optimized_short_cases if len>16|32 // big switch switch(needle) { default >10 cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 } else // small switch switch(needle) { cases 7..10 // others under optimized_short_cases } Furthermore.. big switch case itself has two cases.. if len-needle>31 // works // loop else // len-needle<=31 // BUG HERE The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. ----- Why not found before? - testcase issue, needle was UTF8 for UTF16 case Why only needle==2? - Possibly because the mask for words has two bits, so tolerated off-by-one ------------- Commit messages: - whitespace - off-by-1 in UU/UL case Changes: https://git.openjdk.org/jdk/pull/29242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360271 Stats: 19 lines in 2 files changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29242/head:pull/29242 PR: https://git.openjdk.org/jdk/pull/29242 From asemenyuk at openjdk.org Thu Jan 15 04:56:22 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Thu, 15 Jan 2026 04:56:22 GMT Subject: RFR: 8375364: Some jpackage signing tests fail after JDK-8375240 [v2] In-Reply-To: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> References: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> Message-ID: > Fix a regression from the JDK-8375240 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: 8375364: Some jpackage signing tests fail after JDK-8375240 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29241/files - new: https://git.openjdk.org/jdk/pull/29241/files/7c02bb55..381bd016 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29241&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29241&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29241.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29241/head:pull/29241 PR: https://git.openjdk.org/jdk/pull/29241 From epeter at openjdk.org Thu Jan 15 07:27:24 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 15 Jan 2026 07:27:24 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 12 Jan 2026 08:47:29 GMT, Emanuel Peter wrote: >> Hmm, I see. That sounds like a deficiency in the auto unboxing of Float16. >> >> Suggestion: You should create both variants of the IR tests. And then file an RFE for the one that does not yet vectorize because of the boxing issues. >> >> Because the way things are now, it's not a huge win, to be honest. Which user is supposed to write their code in such a convoluted way, having to cast back and forth? Would they not expect they could just use Float16 all the way through? > > @jatin-bhateja What do you think? Someone filed the RFE: https://bugs.openjdk.org/browse/JDK-8375321 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2693259787 From jbhateja at openjdk.org Thu Jan 15 08:56:21 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 15 Jan 2026 08:56:21 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] 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 28 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Fix incorrect argument passed to smokeTest - 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 - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519849 lines in 228 files changed: 285040 ins; 233032 del; 1777 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 cushon at openjdk.org Thu Jan 15 09:13:15 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 09:13:15 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v3] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/791954d6..972553f5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=01-02 Stats: 15 lines in 1 file changed: 6 ins; 0 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Thu Jan 15 09:13:18 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 09:13:18 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 22:49:06 GMT, Roger Riggs wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/java.base/share/classes/java/lang/String.java line 1080: > >> 1078: return value.length; >> 1079: } >> 1080: int len = value.length >> 1; > > I don't think I understand what's being done and what Charset encoder it is mimicking. > It probably needs to document the assumptions about unmappable characters and malformed surrogates. > (Likely it is correct since the test of US_ASCII passes, but could use an explanation). I added some `//` comments documenting which methods the `encodedLength*` methods are mimicking. The logic here should be identical to `encodeASCII` (except that it isn't allocating and writing to a destination array). The handling of unmappable characters and malformed surrogates should match `encodeASCII`. > src/java.base/share/classes/java/lang/String.java line 2130: > >> 2128: >> 2129: /** >> 2130: * Returns the length in bytes of the given String encoded with the given {@link Charset}. > > You can use the javadoc tag `@return` and skip the duplication. This first sentence reads better then the @return below since it emphasies the "encoded string" aspect. Sorry I'm not sure I understand, can you clarify how that would work? The javadoc can't start with `@return`, it needs to be a non-tag sentence fragment (the build enables doclint to enforce this). > src/java.base/share/classes/java/lang/String.java line 2136: > >> 2134: * @implNote This method may allocate memory to compute the length for some charsets. >> 2135: * >> 2136: * @param cs the charset used to the compute the length > > Capitalize and perhaps link "Charset". Done > src/java.base/share/classes/java/lang/String.java line 2155: > >> 2153: } >> 2154: >> 2155: private int byteFor(int length, int coder) { > > Add a //comment please. > The method name should be plural. `bytesForCoder`. Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2693532105 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2693479863 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2693480259 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2693532859 From mdoerr at openjdk.org Thu Jan 15 09:34:47 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 15 Jan 2026 09:34:47 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Tue, 13 Jan 2026 21:21:58 GMT, Weijun Wang wrote: >> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions? > > @TheRealMDoerr I haven't used your `calling_convention_requires_int_as_long` flag in my new commit. Can you investigate the approach in a different JBS issue? I would prefer to have no undefined behavior from the beginning. However, if you don't feed comfortable with it, we could file a follow-up issue. I don't think there's much to investigate because there's no alternative before we get [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2693634221 From thartmann at openjdk.org Thu Jan 15 12:33:37 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Thu, 15 Jan 2026 12:33:37 GMT Subject: RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: <3GHpdG1lUc6errJsYXUAfKMXw_6xeOi0iLT79IoGlE8=.976148c9-bf0e-4c02-b3ed-adc8b4eaeea3@github.com> On Thu, 15 Jan 2026 04:24:24 GMT, Volodymyr Paprotski wrote: > Failure always for UU case, needle=2, len=17 > - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) > > Following down the code layout: > > if len==0 > return 0 > if len>needle > return -1 > if len<=16|32 && needle<=3|6 > optimized_short_cases > if len>16|32 > // big switch > switch(needle) { > default >10 > cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 > } > else > // small switch > switch(needle) { > cases 7..10 > // others under optimized_short_cases > } > > Furthermore.. big switch case itself has two cases.. > > if len-needle>31 > // works > // loop > else // len-needle<=31 > // BUG HERE > > The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. > > ----- > Why not found before? > - testcase issue, needle was UTF8 for UTF16 case > > Why only needle==2? > - Possibly because the mask for words has two bits, so tolerated off-by-one Looks good to me but @jatin-bhateja should have a look as well. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29242#pullrequestreview-3665370816 From vklang at openjdk.org Thu Jan 15 12:43:47 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 15 Jan 2026 12:43:47 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 14 Jan 2026 12:41:50 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: > > Another set of contend vs deactivate vs park tradeoffs src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1861: > 1859: break; > 1860: } > 1861: } The following might be a potential alternative encoding of signalWork?it would be interesting to hear if it makes any difference on your testing array, Doug: final void signalWork(WorkQueue src, int base) { int pc = parallelism, i, sp; // rely on caller sync for initial reads long c = U.getLong(this, CTL); WorkQueue[] qs; while ((short)(c >>> RC_SHIFT) < pc && (qs = queues) != null && qs.length > (i = (sp = (int)c) & SMASK) && (src == null || src.base - base < 1)) { if (i == 0) { if ((short)(c >>> TC_SHIFT) >= pc) break; if (c == (c = U.compareAndExchangeLong(this, CTL, c, ((c + TC_UNIT) & TC_MASK) | ((c + RC_UNIT) & RC_MASK)))) { createWorker(); break; } } else { WorkQueue v; if ((v = qs[i]) == null) break; if (c == (c = U.compareAndExchangeLong(this, CTL, c, (v.stackPred & LMASK) | ((c + RC_UNIT) & UMASK)))) { v.phase = sp; if (v.parking != 0) U.unpark(v.owner); break; } } } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2694226850 From syan at openjdk.org Thu Jan 15 12:44:48 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 15 Jan 2026 12:44:48 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 Test-fix only, should we backport this fix to jdk26? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28826#issuecomment-3754555700 From vklang at openjdk.org Thu Jan 15 13:02:25 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 15 Jan 2026 13:02:25 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <4qvrNVW2vJiKIJh19Nn2gBLv2uvDTKHxFSrdZddxLT8=.140a8f17-2e35-49e5-a56c-1aa66f8f693c@github.com> On Wed, 14 Jan 2026 12:41:50 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: > > Another set of contend vs deactivate vs park tradeoffs src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1267: > 1265: pool.signalWork(this, s); // may have appeared empty > 1266: } > 1267: } Not sure if it helps in practice, but we could elide the getReferenceAcquire in certain cases while still ensuring that its performed prior to the unlock with something like: final void push(ForkJoinTask task, ForkJoinPool pool, int unlock) { ForkJoinTask[] a = array; int b = base, s = top, cap, m; if (a == null || (cap = a.length) <= s + 1 - b || (m = cap - 1) < 0) growAndPush(task, pool, unlock); else { top = s + 1; U.getAndSetReference(a, slotOffset(m & s), task); if (pool != null && U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null) pool = null; if (unlock != 1) { // release external lock U.putInt(this, PHASE, unlock); U.storeFence(); } if (pool != null) pool.signalWork(this, s); // may have appeared empty } } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2694290976 From rriggs at openjdk.org Thu Jan 15 13:19:46 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 13:19:46 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v4] In-Reply-To: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: > On Linux and Mac, when a process is started, pipes are created to communicate with the child. > In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. > > Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. > Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) > Converted PipelineLeaksFD test to JUnit. Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: Refactor execution of lsof to provide more debugging information. The raw lsof output is retained and printed to the log on a failure. A couple of intermittent failures have reported too many or too few pipes. Additional lsof information can help identify the extra pipes. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29143/files - new: https://git.openjdk.org/jdk/pull/29143/files/38328d56..131f4ccb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29143&range=02-03 Stats: 56 lines in 1 file changed: 41 ins; 7 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29143.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29143/head:pull/29143 PR: https://git.openjdk.org/jdk/pull/29143 From rriggs at openjdk.org Thu Jan 15 13:19:50 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 13:19:50 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v3] In-Reply-To: References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: On Tue, 13 Jan 2026 21:47:40 GMT, Roger Riggs wrote: >> On Linux and Mac, when a process is started, pipes are created to communicate with the child. >> In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. >> >> Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. >> Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) >> Converted PipelineLeaksFD test to JUnit. > > Roger Riggs has updated the pull request incrementally with two additional commits since the last revision: > > - Some test platforms do not have `lsof` installed, if not available, > the tests are skipped. > - Remove extra -Xint test run, its purpose is unknown. The refactored error reporting passed the CI multiple times. If there are future failures, the new information will help diagnose the cause. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29143#issuecomment-3754752278 From rriggs at openjdk.org Thu Jan 15 13:31:41 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 13:31:41 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:47:47 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 2130: >> >>> 2128: >>> 2129: /** >>> 2130: * Returns the length in bytes of the given String encoded with the given {@link Charset}. >> >> You can use the javadoc tag `@return` and skip the duplication. This first sentence reads better then the @return below since it emphasies the "encoded string" aspect. > > Sorry I'm not sure I understand, can you clarify how that would work? > > The javadoc can't start with `@return`, it needs to be a non-tag sentence fragment (the build enables doclint to enforce this). fyi, New javadoc functionality in JDK 22 enabled @return as an inline tag. (see the [Javadoc tag specification](https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html)) `As an inline tag, provides content for the first sentence of a method's main description, and a "Returns" section, as if @return description were also present. In the default English locale, the first sentence is Returns description .` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2694390929 From cushon at openjdk.org Thu Jan 15 13:41:08 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 13:41:08 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v4] In-Reply-To: References: Message-ID: <7NQ2MCXYWVpXWXsGYGHR9DtPNxB1H9Wv9BqNqi7smdw=.d4d850cb-1dcb-4b69-a44d-9584bdb68ec8@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Use the @return inline tag ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/972553f5..cf4e59f3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From rriggs at openjdk.org Thu Jan 15 13:41:11 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 13:41:11 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 09:04:09 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 1080: >> >>> 1078: return value.length; >>> 1079: } >>> 1080: int len = value.length >> 1; >> >> I don't think I understand what's being done and what Charset encoder it is mimicking. >> It probably needs to document the assumptions about unmappable characters and malformed surrogates. >> (Likely it is correct since the test of US_ASCII passes, but could use an explanation). > > I added some `//` comments documenting which methods the `encodedLength*` methods are mimicking. The logic here should be identical to `encodeASCII` (except that it isn't allocating and writing to a destination array). > > The handling of unmappable characters and malformed surrogates should match `encodeASCII`. Thanks for the doc update. Duplicating code (almost) is a unfortunate side-effect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2694424323 From cushon at openjdk.org Thu Jan 15 13:41:12 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 13:41:12 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v2] In-Reply-To: References: Message-ID: <_aVd-ZtOFww9VJ5xUH1r_9iIdPPyIE-bXYFveiwQ1U4=.a03c9434-fe43-4d1b-b9b2-75548759253f@github.com> On Thu, 15 Jan 2026 13:28:23 GMT, Roger Riggs wrote: >> Sorry I'm not sure I understand, can you clarify how that would work? >> >> The javadoc can't start with `@return`, it needs to be a non-tag sentence fragment (the build enables doclint to enforce this). > > fyi, New javadoc functionality in JDK 22 enabled @return as an inline tag. (see the [Javadoc tag specification](https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html)) > `As an inline tag, provides content for the first sentence of a method's main description, and a "Returns" section, as if @return description were also present. In the default English locale, the first sentence is Returns description .` Thanks, that's good to know! I updated to use an `@return` inline tag. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2694423894 From rriggs at openjdk.org Thu Jan 15 13:54:04 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 13:54:04 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v4] In-Reply-To: <7NQ2MCXYWVpXWXsGYGHR9DtPNxB1H9Wv9BqNqi7smdw=.d4d850cb-1dcb-4b69-a44d-9584bdb68ec8@github.com> References: <7NQ2MCXYWVpXWXsGYGHR9DtPNxB1H9Wv9BqNqi7smdw=.d4d850cb-1dcb-4b69-a44d-9584bdb68ec8@github.com> Message-ID: <0YR50Asq8EGZTHIhl0wUwPYLuTDgy4GSwED7oDI9rUk=.b792a4fd-b909-4875-a0e3-e49561a5e16c@github.com> On Thu, 15 Jan 2026 13:41:08 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Use the @return inline tag There should also be a test of the API basics in the test/jdk/java/lang/String directory including NullPointerException. And it can reference the encoding tests in sun/nio/cs/... There is also existing tests of encoding functions in test/jdk/java/lang/String/Encodings.java (but may not be the right place). ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3754969182 From duke at openjdk.org Thu Jan 15 13:54:08 2026 From: duke at openjdk.org (Roger Calnan) Date: Thu, 15 Jan 2026 13:54:08 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors Message-ID: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> removed duplicate -Xlog anchor ------------- Commit messages: - Update full name - removed duplicate -Xlog anchor Changes: https://git.openjdk.org/jdk/pull/29252/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29252&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375342 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29252.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29252/head:pull/29252 PR: https://git.openjdk.org/jdk/pull/29252 From anthonyv.be at outlook.com Thu Jan 15 13:56:08 2026 From: anthonyv.be at outlook.com (Anthony Vanelverdinghe) Date: Thu, 15 Jan 2026 14:56:08 +0100 Subject: [External] : Re: Can we deprecate Path.endsWith(String)? In-Reply-To: <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com> References: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> <1867a1b2-d534-47c7-9554-3188a86bc60f@oracle.com> Message-ID: Thank you for taking the time to clarify the trade-offs, especially highlighting the importance of code readers and readability. Please bear with me and allow me to express my point of view in terms of code authors and code readers. Regarding code authors, I hold that when they are misled, they were looking for a file extension API in virtually all cases. So I see a dependency here in that adding a file extension API would reduce the number of misleads to a negligible frequency, no larger than the frequency with other Java SE APIs. For example, being misled to write `Duration.from(aPeriod)`. By deprecating these methods, I believe code authors will be misled to simply write `path.endsWith(Path.of("foo"))`, without considering alternative file systems (AFSs). Even code authors that actually know about AFSs, as it's a subtle consideration that is easily overlooked. And this will in turn impact code readers as well, as they'll wonder whether it is acceptable to ignore AFSs (unless the code author documented why it is). With `path.endsWith("foo")`, authors don't have to document anything and readers don't have to wonder: it just works. Regarding code readers, I hold that it is rare to be misled and that the code author is best placed to judge whether `path.endsWith("foo")` is misleading. For example, code readers would readily see that `Files.isDirectory(path) && path.endsWith(".git")` looks for Git repositories. And in cases where the code author considers `path.endsWith("foo")` to be misleading, they'd simply introduce a variable to eliminate any confusion, e.g., `var filename = "foo"; path.endsWith(filename)`. By deprecating these methods, code authors have one less tool for writing readable code. Since something like `path.endsWith(path.getFileSystem().getPath("foo"))` can hardly be considered readable, either code authors have to constrain their code to the default file system, or they have to introduce a new local variable for the argument to `endsWith`. In case of the former, code readers may be left to wonder whether it is acceptable to ignore AFSs (as explained above). In case of the latter, code readers might be misled to simplify `var foo = path.getFileSystem().getPath("foo")` to `var foo = Path.of("foo")`, thinking these are equivalent. Thanks again for reading. I don't mean to drag on the discussion, so if there's nothing in here that you hadn't already considered, we can leave it at this. Kind regards, Anthony On 1/14/2026 7:20 PM, Stuart Marks wrote: > > You're making this too complicated. > > On their face, startsWith/endsWith(String) are misleading to both code > authors and code readers, and that justifies their deprecation. It > will help code authors avoid making new mistakes. Readers of code that > uses these APIs -- even correctly -- can easily misinterpret the code > as if it performed string-based testing and thus be misled about what > the code is actually doing. In both cases, the code is better replaced > with more explicit, if more verbose, alternatives that already exist. > > Certainly a file extension API would facilitate use cases that involve > file extensions, such as inspecting a file's extension to determine > how to process the file. I'm in favor of adding such an API. But > that's a different topic from this one, and it should be handled > independently. > > I did read all of your message but I'm not responding to most of it, > because it doesn't establish a dependency between these two topics. > > s'marks > > On 1/13/26 12:13 PM, Anthony Vanelverdinghe wrote: >> >> There are 3 questions: >> >> (1) should we deprecate `Path::startsWith(String)`? >> (2) should we deprecate `Path::endsWith(String)`? >> (3) should we add a file extension API? >> >> And the TL;DR: no, no, yes. >> >> Let's first establish why `startsWith/endsWith` add tangible value: >> because `path.startsWith("foo")` is not equivalent to >> `path.startsWith(Path.of("foo"))` >> and is much more readable than >> `path.startsWith(getFileSystem().getPath("foo"))`. >> >> Next, let's consider why people might want to use String-based >> `startsWith/endsWith` testing on Path instances: >> >> * testing file extensions = 99.9999% of the times: covered by >> `FileSystem::getPathMatcher` >> * testing name elements = 0.0000999% of the times: covered by `Path` >> * any other use cases = ~0% of the times: covered by >> `FileSystem::getPathMatcher` >> >> So it is always possible to do without String conversion. >> In fact, it is arguably always a bad idea to do String-based testing, >> because `path.toString().endsWith(".java")` will also match a file >> named ".java", >> which on Linux-like OSes would be considered a hidden file named >> "java" that has no file extension. >> So using a dedicated `PathMatcher` for testing file extensions is >> more robust and elegant. >> >> However, when testing file extensions we inevitably start by typing >> `path.` >> (assuming we don't just use a third-party library), >> first notice there's no method `getFileExtension` or such, >> and then notice `endsWith(String)` >> (and maybe we've also noticed `getFileName` and already have >> `path.getFileName().`). >> At this point it's pure psychology: >> we're looking for a method that behaves like String's `endsWith(String)`, >> we're looking at a method with the same method signature, >> and we can't imagine that the Path class does *not* have a method to >> test the filename extension, >> so surely this must be it. >> And obviously we ignore any hints at the contrary >> (like our IDE proposing both `endsWith(Path)` and `endsWith(String)` >> for autocompletion). >> And we don't bother to read the Javadoc, because in cases like this >> we can easily verify our assumptions with JShell >> and equally quickly realize our assumptions are wrong. >> >> So yes, this is a common mistake. But this is actually an argument >> for *not* deprecating it. >> Many developers have bumped into this, but as far as I can tell the >> mailing list thread in September was the first in the existence of >> the API. >> And I'm unable to find any previous bug reports either. >> And here's why: when we realized our assumptions were wrong, we read >> the Javadoc, realized our mistake, learned from it, and moved on. >> The Javadoc is crystal-clear, the method overloads another method >> with the same behavior, it clearly adds value over the other method. >> In other words: we conclude "makes sense" and don't see any reason to >> complain. >> >> To turn this common mistake into a rare-if-ever mistake, I see two >> (combinable) options: >> >> * introduce a file extension API >> * replace `startsWith/endsWith` with methods >> `startsWithNames/endsWithNames` >> >> I don't consider deprecating `startsWith/endsWith` without >> replacement an option because: >> >> * these methods add value (as was also argued by Rob Spoor), so it's >> a net loss for the Java SE APIs. >> And all the people that are happily using these methods today and are >> unaware of this mailing list thread will be unpleasantly surprised to >> see it deprecated >> * this means breaking compilation for everyone that builds with >> "-Werror" and "no usage of deprecated APIs" is a very common policy. >> So people will end up adding a duplicate of the deprecated methods in >> their own utility libraries >> * this trades one trap for another, much more subtle trap, since >> people will blindly replace `"foo"` with `Path.of("foo")`. >> (We're having this very discussion because people don't read Javadoc. >> So surely we're not expecting people to read the deprecation text and >> follow the recommendations, are we?) >> Eventually they'll notice there's a bug, add `IO.println(foo)` and >> `IO.println(Path.of("foo"))`, notice these both print "foo", >> but somehow `foo.endsWith(Path.of("foo"))` results in `false`, >> eventually find the culprit ... and then notice the deprecated >> `endsWith` method did exactly >> what they wanted all along >> * what would the rationale for the deprecation be? How would you >> document this in the Javadoc? >> Now you might still say: "People who were looking for a file >> extension API regularly ended up here. If you're one of them, use >> Path::toString instead." >> But once a file extension API will be available, it'll be extremely >> hard to come up with a reasonable justification for the deprecation. >> And as argued above, simple String-based comparisons are rarely, if >> ever, the most robust solution >> * for `startsWith` in particular: the only argument to deprecate it >> seems to be "for the sake of symmetry" >> >> Anthony >> >> On 1/12/2026 8:36 PM, Stuart Marks wrote: >>> >>> Let's not tie these two issues together. >>> >>> The discussion clearly shows that the startsWith/endsWith(String) >>> APIs are a trap that several people have fallen into. On that basis >>> it should be deprecated. (Ordinarily, so as to emit a warning, and >>> not for removal, so there won't be any compatibility issue.) >>> >>> There is also no requirement that a new API be introduced to replace >>> any deprecated API. As the earlier discussion in the thread shows, >>> both the path-based and the string-based use cases can be written >>> using existing APIs, somewhat less conveniently and more verbosely; >>> but these constructs are much more explicit and so are preferable to >>> the APIs to be deprecated. The deprecation text should steer people >>> toward the preferred constructs. >>> >>> It would indeed be nice to have a file extension API, but this has >>> been discussed several times and has run aground each time for a >>> variety of reasons. Tying these together will hold up the >>> deprecation for no good reason. >>> >>> Let's proceed with just the deprecation first and work on the file >>> extension API separately. >>> >>> s'marks >>> >>> On 1/11/26 12:45 PM, David Alayachew wrote: >>>> Thanks for the response Anthony. Messages have been arriving >>>> out-of-order for me, so I didn't see yours at the time of me >>>> writing that message. >>>> >>>> I think introducing the file extension API first, then gauging the >>>> need for a deprecation before doing it is fine. Sounds like then >>>> that we are universally agreed on the first step being to add the >>>> file extension API, yes? >>>> >>>> On Sun, Jan 11, 2026 at 2:06?PM Anthony Vanelverdinghe >>>> wrote: >>>> >>>> I dissent. (Apparently my previous message wasn't clear.) >>>> >>>> The right order of things is to first introduce a file >>>> extension API. Then see if there's still complaints about >>>> `Path::endsWith(String)`. And only then, if there are, consider >>>> taking action. >>>> >>>> In my previous message I've already explained how these methods >>>> add real, tangible value and actually are intuitive. >>>> (Again, ask developers to guess how `A::foo(B)` behaves, given >>>> that both `A::foo(A)` and `B::foo(B)` exist, and a large >>>> majority of them will intuitively guess it converts its `b` >>>> argument to an instance of `A` and passes it on to `A::foo(A)`. >>>> And their intuition would be correct in the case of >>>> `Path::endsWith(String)`. That being said, I'll be the first to >>>> admit that I've also made the mistake of attempting to use >>>> `Path::endsWith(String)` to test the file extension.) >>>> >>>> In hindsight, maybe `endsWithNames(String)` would've been a >>>> better choice, but hindsight is 20/20. >>>> >>>> Deprecating these methods now is premature. And deprecating >>>> them without replacement methods would result in way more >>>> complaints than there have ever been about `endsWith(String)`. >>>> >>>> Anthony >>>> >>>> On 1/11/2026 12:19 AM, David Alayachew wrote: >>>>> Of course. >>>>> >>>>> I see lots of approvals and not really any dissenters. Are we >>>>> waiting for more responses? Or is there anything we can do to >>>>> kick start this? >>>>> >>>>> On Fri, Jan 9, 2026, 10:22?PM Brian Burkhalter >>>>> wrote: >>>>> >>>>> Thanks for the corroboration. >>>>> >>>>>> On Jan 8, 2026, at 1:50?PM, David Alayachew >>>>>> wrote: >>>>>> >>>>>> Thanks for reviving this. >>>>>> >>>>>> I am perfectly happy with the idea of deprecating the >>>>>> Path.{start,ends}With(String), and then only add the file >>>>>> extension method. Originally, I didn't know that new >>>>>> method was on the table, so I suggested a rename. But the >>>>>> file extension api feels like the superior solution. >>>>>> >>>>>> 10 times out of 10, if I am calling endsWith, the only >>>>>> time I am not looking for "whole" path elements is when I >>>>>> am looking for a file extension. In every other instance, >>>>>> the api does exactly what I expect and want. And plus, >>>>>> something like looking for a file extension is better off >>>>>> being explicit. >>>>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From alanb at openjdk.org Thu Jan 15 14:24:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 15 Jan 2026 14:24:53 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29252#pullrequestreview-3665884308 From iris at openjdk.org Thu Jan 15 14:29:33 2026 From: iris at openjdk.org (Iris Clark) Date: Thu, 15 Jan 2026 14:29:33 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29252#pullrequestreview-3665903400 From vklang at openjdk.org Thu Jan 15 14:32:33 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 15 Jan 2026 14:32:33 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 14 Jan 2026 12:41:50 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: > > Another set of contend vs deactivate vs park tradeoffs src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2593: > 2591: break; > 2592: if ((q = qs[i = (id = r & EXTERNAL_ID_MASK) & (n - 1)]) == null) { > 2593: WorkQueue newq = new WorkQueue(null, id, 0, false); @DougLea Is there a specific reason as to why CLEAR_TLS is false here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2694612904 From cushon at openjdk.org Thu Jan 15 14:42:34 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 14:42:34 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: Message-ID: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/cf4e59f3..f9139b24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=03-04 Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Thu Jan 15 14:42:35 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 14:42:35 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v4] In-Reply-To: <0YR50Asq8EGZTHIhl0wUwPYLuTDgy4GSwED7oDI9rUk=.b792a4fd-b909-4875-a0e3-e49561a5e16c@github.com> References: <7NQ2MCXYWVpXWXsGYGHR9DtPNxB1H9Wv9BqNqi7smdw=.d4d850cb-1dcb-4b69-a44d-9584bdb68ec8@github.com> <0YR50Asq8EGZTHIhl0wUwPYLuTDgy4GSwED7oDI9rUk=.b792a4fd-b909-4875-a0e3-e49561a5e16c@github.com> Message-ID: On Thu, 15 Jan 2026 13:49:54 GMT, Roger Riggs wrote: > There should also be a test of the API basics in the test/jdk/java/lang/String directory including NullPointerException. Thanks, I added test coverage of `NullPointerException` to `test/jdk/java/lang/String/Exceptions.java`. There is also an assertion in `test/jdk/java/lang/String/Encodings.java` to ensure it matches `getBytes(...).length`. Is there additional API test coverage that should be added to `test/jdk/java/lang/String/`? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3755197805 From jpai at openjdk.org Thu Jan 15 15:08:09 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 15 Jan 2026 15:08:09 GMT Subject: RFR: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available [v4] In-Reply-To: References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: <2Rsh9mxX0PnR8byFSI-DM9_kbh03EZgBPLG-45sBoJQ=.573b1565-735a-407c-8e7d-9bcb4e3e2706@github.com> On Thu, 15 Jan 2026 13:19:46 GMT, Roger Riggs wrote: >> On Linux and Mac, when a process is started, pipes are created to communicate with the child. >> In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. >> >> Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. >> Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) >> Converted PipelineLeaksFD test to JUnit. > > Roger Riggs has updated the pull request incrementally with one additional commit since the last revision: > > Refactor execution of lsof to provide more debugging information. > The raw lsof output is retained and printed to the log on a failure. > A couple of intermittent failures have reported too many or too few pipes. > Additional lsof information can help identify the extra pipes. The test update looks reasonable to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29143#pullrequestreview-3666075225 From rriggs at openjdk.org Thu Jan 15 15:45:12 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 15:45:12 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 14:42:34 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update tests src/java.base/share/classes/java/lang/String.java line 2135: > 2133: * {@return the length in bytes of the given String encoded with the given {@link Charset}} > 2134: * > 2135: *

The result will be the same value as {@code getBytes(charset).length}. Please @linkplain to the getBytes(cs) method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2694897294 From rriggs at openjdk.org Thu Jan 15 15:51:12 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 15:51:12 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 14:42:34 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update tests This looks good. In the CSR, I'd move the paragraph starting "Computing the..." to the solution section and describe the possible optimizations without referring to specific implementation details. The javadoc in the specification section needs an update. Moving from Draft to Proposed and fixVersion = 27 will get it on the radar of the CSR reviewers. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3755500610 From rriggs at openjdk.org Thu Jan 15 15:57:47 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 15:57:47 GMT Subject: Integrated: 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available In-Reply-To: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> References: <1gkWuC4Lnnwe16KbrBclXEKHFzfHgTqezHV7caKDdVU=.9f196fbc-8de8-4374-95ef-1bd8e1199a56@github.com> Message-ID: On Fri, 9 Jan 2026 17:46:45 GMT, Roger Riggs wrote: > On Linux and Mac, when a process is started, pipes are created to communicate with the child. > In the case where the stderr is redirected to stdout using `ProcessBuilder.redirectErrorStream()`, the pipe is not needed and should not be created. > > Added a test to check pipe creation when spawning with and without `redirectErrorStream(t/f)`. > Rewrote the extraction of pipes to use `lsof` available on Mac and Linux. (previously used Linux /proc/pid/fd/...) > Converted PipelineLeaksFD test to JUnit. This pull request has now been integrated. Changeset: 203eb701 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/203eb70110dd546784e03243bf98ff3ddb407030 Stats: 230 lines in 3 files changed: 184 ins; 2 del; 44 mod 8291986: ProcessBuilder.redirectErrorStream(true) leaves error stream available Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29143 From jbhateja at openjdk.org Thu Jan 15 16:07:00 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 15 Jan 2026 16:07:00 GMT Subject: RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 04:24:24 GMT, Volodymyr Paprotski wrote: > Failure always for UU case, needle=2, len=17 > - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) > > Following down the code layout: > > if len==0 > return 0 > if len>needle > return -1 > if len<=16|32 && needle<=3|6 > optimized_short_cases > if len>16|32 > // big switch > switch(needle) { > default >10 > cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 > } > else > // small switch > switch(needle) { > cases 7..10 > // others under optimized_short_cases > } > > Furthermore.. big switch case itself has two cases.. > > if len-needle>31 > // works > // loop > else // len-needle<=31 > // BUG HERE > > The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. > > ----- > Why not found before? > - testcase issue, needle was UTF8 for UTF16 case > > Why only needle==2? > - Possibly because the mask for words has two bits, so tolerated off-by-one Marked as reviewed by jbhateja (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29242#pullrequestreview-3666397738 From duke at openjdk.org Thu Jan 15 16:22:10 2026 From: duke at openjdk.org (duke) Date: Thu, 15 Jan 2026 16:22:10 GMT Subject: RFR: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor @calnan Your change (at version 970d38fc13e13b76ac78592475ba073c4233f89e) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29252#issuecomment-3755667838 From cushon at openjdk.org Thu Jan 15 16:27:58 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 16:27:58 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v6] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: @linkplain ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/f9139b24..818162de Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Thu Jan 15 16:28:01 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 16:28:01 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 15:40:42 GMT, Roger Riggs wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Update tests > > src/java.base/share/classes/java/lang/String.java line 2135: > >> 2133: * {@return the length in bytes of the given String encoded with the given {@link Charset}} >> 2134: * >> 2135: *

The result will be the same value as {@code getBytes(charset).length}. > > Please @linkplain to the getBytes(cs) method. Done, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695088558 From mullan at openjdk.org Thu Jan 15 16:30:56 2026 From: mullan at openjdk.org (Sean Mullan) Date: Thu, 15 Jan 2026 16:30:56 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update to print java.security.Security properties Please wait until someone from the Security Group reviews this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3755710214 From vyazici at openjdk.org Thu Jan 15 16:33:30 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 Jan 2026 16:33:30 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 14:42:34 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update tests src/java.base/share/classes/java/lang/String.java line 1097: > 1095: return dp; > 1096: } > 1097: Verified that this is indeed identical to `encodeASCII` such that only the length computation is taken into account. src/java.base/share/classes/java/lang/String.java line 1512: > 1510: return dp; > 1511: } > 1512: Verified that this is indeed identical to `encodeUTF8` such that only the length computation is taken into account. src/java.base/share/classes/java/lang/String.java line 1585: > 1583: > 1584: // This follows the implementation of encodeUTF8_UTF16 > 1585: private static int encodedLengthUTF8_UTF16(byte[] val) { Doesn't this duplicate the `computeSizeUTF8_UTF16`? AFAICS, `computeSizeUTF8_UTF16` is missing the ASCII fast loop, but we can enhance it. FWIW, if we decide reuse `computeSizeUTF8_UTF16`, it might be better to rename it to `encodedLengthUTF8_UTF16`, which will be in line with the introduced `encodedLength*` method family. src/java.base/share/classes/java/lang/String.java line 2143: > 2141: */ > 2142: public int getBytesLength(Charset cs) { > 2143: if (cs == UTF_8.INSTANCE) { It'd be nice to catch null values as early as possible. I suggest adding a `Objects.requireNonNull(cs)` along with `@throws NullPointerException If {@code cs} is null` in docs. src/java.base/share/classes/java/lang/String.java line 2148: > 2146: if (isLatin1()) { > 2147: return value.length; > 2148: } Any particular reason you avoided introducing a `encodedLength8859_1` here? (There is a `encode8859_1` method.) src/java.base/share/classes/java/lang/String.java line 2151: > 2149: } else if (cs == US_ASCII.INSTANCE) { > 2150: return encodedLengthASCII(coder, value); > 2151: } else if (cs instanceof sun.nio.cs.UTF_16LE || cs instanceof sun.nio.cs.UTF_16BE) { I see that `sun.nio.cs.UTF_16{LE,BE}` specialization is suggested by @ExE-Boss [here]. Though I'm not really sure if this is really needed. I cannot spot any other usage of these constants in `java.base`, except `jdk.internal.foreign.StringSupport`, which is irrelevant. [here]: https://github.com/openjdk/jdk/pull/28454/files#r2552768341 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695007692 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695024667 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695036430 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695065623 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695076034 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695105076 From vyazici at openjdk.org Thu Jan 15 16:33:33 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 Jan 2026 16:33:33 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: <94U314HJBN96ktT1MqD-GOo43rAbnQZAEFcJzdHGa6E=.e9b215c1-b1ec-4522-b257-d098d4663783@github.com> On Thu, 15 Jan 2026 16:22:05 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 2135: >> >>> 2133: * {@return the length in bytes of the given String encoded with the given {@link Charset}} >>> 2134: * >>> 2135: *

The result will be the same value as {@code getBytes(charset).length}. >> >> Please @linkplain to the getBytes(cs) method. > > Done, thanks The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695118671 From dfuchs at openjdk.org Thu Jan 15 16:43:54 2026 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Thu, 15 Jan 2026 16:43:54 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v4] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 06:05:43 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 continue... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - merge latest from master branch > - Mark's suggestion - move the duration check to separate method > - merge latest from master branch > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds LGTM - but would be good to have @stuart-marks approval too. ------------- Marked as reviewed by dfuchs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28919#pullrequestreview-3666579349 From cushon at openjdk.org Thu Jan 15 16:52:33 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 16:52:33 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 15:46:57 GMT, Roger Riggs wrote: > This looks good. Thanks for the review! > In the CSR, I'd move the paragraph starting "Computing the..." to the solution section and describe the possible optimizations without referring to specific implementation details. Done, thanks, I rephrased the 'Solution' section a bit to try to discuss the potential optimizations in a more general way. > The javadoc in the specification section needs an update. Moving from Draft to Proposed and fixVersion = 27 will get it on the radar of the CSR reviewers. Done ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3755845597 From cushon at openjdk.org Thu Jan 15 17:05:57 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 17:05:57 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 16:10:57 GMT, Volkan Yazici wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Update tests > > src/java.base/share/classes/java/lang/String.java line 1585: > >> 1583: >> 1584: // This follows the implementation of encodeUTF8_UTF16 >> 1585: private static int encodedLengthUTF8_UTF16(byte[] val) { > > Doesn't this duplicate the `computeSizeUTF8_UTF16`? > > AFAICS, `computeSizeUTF8_UTF16` is missing the ASCII fast loop, but we can enhance it. > > FWIW, if we decide reuse `computeSizeUTF8_UTF16`, it might be better to rename it to `encodedLengthUTF8_UTF16`, which will be in line with the introduced `encodedLength*` method family. Thanks for the catch, good point I will look at switching to `computeSizeUTF8_UTF16`. `computeSizeUTF8_UTF16` returns `long`, this raises a question of what to do in that case. The return type of `getBytesLength` could potentially be `long` and allow computing the encoded length of strings that wouldn't fit into an array if they were encoded. Or it could throw an exception in that case, similar to `getBytes`, and have an `int` return type ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695225769 From duke at openjdk.org Thu Jan 15 17:13:57 2026 From: duke at openjdk.org (Roger Calnan) Date: Thu, 15 Jan 2026 17:13:57 GMT Subject: Integrated: 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors In-Reply-To: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> References: <43PmNX7rB80uIxoJbleBPXm4ocKVNwxoXtYg9GFK1Sc=.967145ca-8468-44e7-8919-676379600dbb@github.com> Message-ID: On Thu, 15 Jan 2026 13:40:30 GMT, Roger Calnan wrote: > removed duplicate -Xlog anchor This pull request has now been integrated. Changeset: ee0387be Author: Roger Calnan Committer: Roger Riggs URL: https://git.openjdk.org/jdk/commit/ee0387be4c562c7f7ad5240f412d4d5363358855 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8375342: jdk/javadoc/doccheck/checks/jdkCheckHtml.java failed with duplicate anchors Reviewed-by: alanb, iris ------------- PR: https://git.openjdk.org/jdk/pull/29252 From cushon at openjdk.org Thu Jan 15 17:20:09 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 17:20:09 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v7] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Deduplicate with computeSizeUTF8_UTF16 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/818162de..855b1298 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=05-06 Stats: 60 lines in 1 file changed: 15 ins; 41 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From rriggs at openjdk.org Thu Jan 15 17:34:42 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 17:34:42 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v7] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:20:09 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Deduplicate with computeSizeUTF8_UTF16 src/java.base/share/classes/java/lang/String.java line 1498: > 1496: if (length > (long)Integer.MAX_VALUE) { > 1497: throw new IllegalStateException("Required length exceeds implementation limit"); > 1498: } This is more like a should never reach here; the OOME thrown by encodedLengthUTF8_UTF16 should ocur. IllegalStateException usually refers to a programming error. The other occurrence like this throws OOME. src/java.base/share/classes/java/lang/String.java line 2112: > 2110: * > 2111: * @param cs The {@link Charset} used to the compute the length > 2112: * @throws NullPointerException If {@code cs} is {@code null} @throws clauses for NPE are usually omitted, the class javadoc specifies the behavior for the whole class. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695311406 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695316740 From vyazici at openjdk.org Thu Jan 15 17:34:52 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Thu, 15 Jan 2026 17:34:52 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 17:02:01 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 1585: >> >>> 1583: >>> 1584: // This follows the implementation of encodeUTF8_UTF16 >>> 1585: private static int encodedLengthUTF8_UTF16(byte[] val) { >> >> Doesn't this duplicate the `computeSizeUTF8_UTF16`? >> >> AFAICS, `computeSizeUTF8_UTF16` is missing the ASCII fast loop, but we can enhance it. >> >> FWIW, if we decide reuse `computeSizeUTF8_UTF16`, it might be better to rename it to `encodedLengthUTF8_UTF16`, which will be in line with the introduced `encodedLength*` method family. > > Thanks for the catch, good point I will look at switching to `computeSizeUTF8_UTF16`. > > `computeSizeUTF8_UTF16` returns `long`, this raises a question of what to do in that case. The return type of `getBytesLength` could potentially be `long` and allow computing the encoded length of strings that wouldn't fit into an array if they were encoded. Or it could throw an exception in that case, similar to `getBytes`, and have an `int` return type `computeSizeUTF8_UTF16` is only used in `encodeUTF8_UTF16`: long allocLen = (sl * 3 < 0) ? computeSizeUTF8_UTF16(val, exClass) : sl * 3; if (allocLen > (long)Integer.MAX_VALUE) { throw new OutOfMemoryError("Required length exceeds implementation limit"); } I guess we can move `if (allocLen > (long)Integer.MAX_VALUE)` check to `computeSizeUTF8_UTF16` and make its return type `int`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695315669 From jlu at openjdk.org Thu Jan 15 17:45:33 2026 From: jlu at openjdk.org (Justin Lu) Date: Thu, 15 Jan 2026 17:45:33 GMT Subject: Integrated: 8375231: Refactor util/ServiceLoader tests to use JUnit In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 22:42:41 GMT, Justin Lu wrote: > This PR converts the TestNG tests in _util/ServiceLoader_ (7), _util/StringJoiner_ (3), and _util/Vector_ (1) to JUnit. > The first commit is from the automated tool, the rest are manual changes done after. > > Before > ServiceLoader: Framework-based tests: 62 = 62 TestNG + 0 JUnit > StringJoiner: Framework-based tests: 32 = 32 TestNG + 0 JUnit > Vector: Framework-based tests: 9 = 9 TestNG + 0 JUnit > > After > ServiceLoader: Framework-based tests: 62 = 0 TestNG + 62 JUnit > StringJoiner: Framework-based tests: 32 = 0 TestNG + 32 JUnit > Vector: Framework-based tests: 9 = 0 TestNG + 9 JUnit This pull request has now been integrated. Changeset: 34705a77 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/34705a77f9a90da5ab2a440c11d79aef7bb3ba54 Stats: 357 lines in 11 files changed: 81 ins; 53 del; 223 mod 8375231: Refactor util/ServiceLoader tests to use JUnit 8375232: Refactor util/StringJoiner tests to use JUnit 8375233: Refactor util/Vector tests to use JUnit Reviewed-by: naoto, alanb ------------- PR: https://git.openjdk.org/jdk/pull/29210 From weijun at openjdk.org Thu Jan 15 18:11:14 2026 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 15 Jan 2026 18:11:14 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Mon, 12 Jan 2026 13:25:09 GMT, Maurizio Cimadamore wrote: >> Should we use the workaround I have proposed above until a better solution for [JDK-8336664](https://bugs.openjdk.org/browse/JDK-8336664) is available? Or are there other suggestions? > > At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround. I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2695433254 From pchilanomate at openjdk.org Thu Jan 15 18:29:04 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 15 Jan 2026 18:29:04 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state Message-ID: Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. Thanks, Patricio ------------- Commit messages: - v1 Changes: https://git.openjdk.org/jdk/pull/29255/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373120 Stats: 147 lines in 2 files changed: 136 ins; 8 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From cushon at openjdk.org Thu Jan 15 18:29:34 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 18:29:34 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Review feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/855b1298..d725c8b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=06-07 Stats: 42 lines in 1 file changed: 25 ins; 10 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Thu Jan 15 18:29:38 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 18:29:38 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v7] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:27:11 GMT, Roger Riggs wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Deduplicate with computeSizeUTF8_UTF16 > > src/java.base/share/classes/java/lang/String.java line 1498: > >> 1496: if (length > (long)Integer.MAX_VALUE) { >> 1497: throw new IllegalStateException("Required length exceeds implementation limit"); >> 1498: } > > This is more like a should never reach here; the OOME thrown by encodedLengthUTF8_UTF16 should ocur. > IllegalStateException usually refers to a programming error. > The other occurrence like this throws OOME. Thanks, what do you think about refactoring the OOME into `encodedLengthUTF8_UTF16` and having it return `int`? > src/java.base/share/classes/java/lang/String.java line 2112: > >> 2110: * >> 2111: * @param cs The {@link Charset} used to the compute the length >> 2112: * @throws NullPointerException If {@code cs} is {@code null} > > @throws clauses for NPE are usually omitted, the class javadoc specifies the behavior for the whole class. Removed, thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695393117 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695393824 From cushon at openjdk.org Thu Jan 15 18:29:42 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 18:29:42 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 16:17:22 GMT, Volkan Yazici wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Update tests > > src/java.base/share/classes/java/lang/String.java line 2143: > >> 2141: */ >> 2142: public int getBytesLength(Charset cs) { >> 2143: if (cs == UTF_8.INSTANCE) { > > It'd be nice to catch null values as early as possible. I suggest adding a `Objects.requireNonNull(cs)` along with `@throws NullPointerException If {@code cs} is null` in docs. I added the `requireNonNull`, omitting the `@throws` as suggested in https://github.com/openjdk/jdk/pull/28454/changes#r2695394410 > src/java.base/share/classes/java/lang/String.java line 2148: > >> 2146: if (isLatin1()) { >> 2147: return value.length; >> 2148: } > > Any particular reason you avoided introducing a `encodedLength8859_1` here? (There is a `encode8859_1` method.) I have tentatively added `encodedLength8859_1` `encode8859_1` is implemented in terms of the `implEncodeISOArray`, so it is less similar than the other examples. In general I figured there was a tradeoff between the performance benefit and the additional code to have fast paths for each charset, and UTF-8 may be more frequently used. > src/java.base/share/classes/java/lang/String.java line 2151: > >> 2149: } else if (cs == US_ASCII.INSTANCE) { >> 2150: return encodedLengthASCII(coder, value); >> 2151: } else if (cs instanceof sun.nio.cs.UTF_16LE || cs instanceof sun.nio.cs.UTF_16BE) { > > I see that `sun.nio.cs.UTF_16{LE,BE}` specialization is suggested by @ExE-Boss [here]. Though I'm not really sure if this is really needed. I cannot spot any other usage of these constants in `java.base`, except `jdk.internal.foreign.StringSupport`, which is irrelevant. > > [here]: https://github.com/openjdk/jdk/pull/28454/files#r2552768341 I don't have a strong opinion about these charsets. It's nice that the encoded length for them can be calculated in constant time, but on the other hand if they are less frequently used and there isn't precedent for special casing them in `java.base`, then this part could be dropped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695394410 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695468134 PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695471999 From rriggs at openjdk.org Thu Jan 15 19:27:10 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 19:27:10 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: On Thu, 15 Jan 2026 18:18:31 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 2151: >> >>> 2149: } else if (cs == US_ASCII.INSTANCE) { >>> 2150: return encodedLengthASCII(coder, value); >>> 2151: } else if (cs instanceof sun.nio.cs.UTF_16LE || cs instanceof sun.nio.cs.UTF_16BE) { >> >> I see that `sun.nio.cs.UTF_16{LE,BE}` specialization is suggested by @ExE-Boss [here]. Though I'm not really sure if this is really needed. I cannot spot any other usage of these constants in `java.base`, except `jdk.internal.foreign.StringSupport`, which is irrelevant. >> >> [here]: https://github.com/openjdk/jdk/pull/28454/files#r2552768341 > > I don't have a strong opinion about these charsets. It's nice that the encoded length for them can be calculated in constant time, but on the other hand if they are less frequently used and there isn't precedent for special casing them in `java.base`, then this part could be dropped. While is convenient that those UTF16 charsets have a easy to compute size, I doubt those two are in sufficient use to justify a commitment support them in the fast path. If you are going to support charsets beyond the most common utf8, ascii, and ISO-8856-1, then computing the encoded length should delegated to the Charset itself and have separate code in different packages. Have you looked at `CharsetEncoder.maxBytesPerChar()`, It might only be useful for single byte formats, but if `maxBytesPerChar` is equal to `averageBytesPerChar` that might be a useful shortcut. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695660230 From naoto at openjdk.org Thu Jan 15 19:42:19 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Jan 2026 19:42:19 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 18:29:34 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Review feedback src/java.base/share/classes/java/lang/String.java line 2127: > 2125: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. > 2126: * > 2127: * @implNote This method may allocate memory to compute the length for some charsets. Would it help if we describe the benefit of this method? Ie, for some charsets it won't allocate memory thus faster than getBytes(Charset)? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695707693 From cushon at openjdk.org Thu Jan 15 20:05:04 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 20:05:04 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 19:39:28 GMT, Naoto Sato wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Review feedback > > src/java.base/share/classes/java/lang/String.java line 2127: > >> 2125: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. >> 2126: * >> 2127: * @implNote This method may allocate memory to compute the length for some charsets. > > Would it help if we describe the benefit of this method? Ie, for some charsets it won't allocate memory thus faster than getBytes(Charset)? I think that makes sense, I'm not sure what the best way to characterize it is. Probably we don't want to promise specific optimizations. What do you think about: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}, * and will have equivalent or better performance. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695775575 From cushon at openjdk.org Thu Jan 15 20:05:05 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 20:05:05 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> Message-ID: <1Lx3cEk1vZnCgoRMNbocsykbFMitu3LtLgAX3k8iAo8=.b8a22bac-246c-479c-8acf-175427e32e5b@github.com> On Thu, 15 Jan 2026 19:23:43 GMT, Roger Riggs wrote: > While is convenient that those UTF16 charsets have a easy to compute size, I doubt those two are in sufficient use to justify a commitment support them in the fast path. If you are going to support charsets beyond the most common utf8, ascii, and ISO-8856-1, then computing the encoded length should delegated to the Charset itself and have separate code in different packages. Thanks, that makes sense to me. My opinion is that a large amount of the value here is in optimizing UTF-8, and that there's an argument to optimize the other standard charsets that `String` has other fast paths for, but sharply diminishing returns beyond that. I would be inclined to stop at the standard charsets, but also happy to make changes if there's a preference for having more or fewer fast paths. > Have you looked at `CharsetEncoder.maxBytesPerChar()`, It might only be useful for single byte formats, but if `maxBytesPerChar` is equal to `averageBytesPerChar` that might be a useful shortcut. I had a quick look at that, and saw errors for `IBM-Thai`: CharsetEncoder encoder = cs.newEncoder(); if (encoder.maxBytesPerChar() == 1f && encoder.maxBytesPerChar() == encoder.averageBytesPerChar()) { return value.length * (int) encoder.maxBytesPerChar(); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695769015 From cushon at openjdk.org Thu Jan 15 20:07:58 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 20:07:58 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v9] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Mention performance in the docs, and drop UTF_16BE/LE fast paths ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/d725c8b1..81d132f8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=07-08 Stats: 11 lines in 1 file changed: 1 ins; 9 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From rriggs at openjdk.org Thu Jan 15 20:27:57 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 20:27:57 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v7] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:51:57 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 1498: >> >>> 1496: if (length > (long)Integer.MAX_VALUE) { >>> 1497: throw new IllegalStateException("Required length exceeds implementation limit"); >>> 1498: } >> >> This is more like a should never reach here; the OOME thrown by encodedLengthUTF8_UTF16 should ocur. >> IllegalStateException usually refers to a programming error. >> The other occurrence like this throws OOME. > > Thanks, what do you think about refactoring the OOME into `encodedLengthUTF8_UTF16` and having it return `int`? That's fine, the `long` return was to simplify handling of too large returns. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695831889 From naoto at openjdk.org Thu Jan 15 20:27:59 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 15 Jan 2026 20:27:59 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 20:02:59 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 2127: >> >>> 2125: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. >>> 2126: * >>> 2127: * @implNote This method may allocate memory to compute the length for some charsets. >> >> Would it help if we describe the benefit of this method? Ie, for some charsets it won't allocate memory thus faster than getBytes(Charset)? > > I think that makes sense, I'm not sure what the best way to characterize it is. Probably we don't want to promise specific optimizations. What do you think about: > > > *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}, > * and will have equivalent or better performance. I think this won't be a normative spec, so I'd move the performance description to `@apiNote` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695837680 From rriggs at openjdk.org Thu Jan 15 20:28:00 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 15 Jan 2026 20:28:00 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: <1Lx3cEk1vZnCgoRMNbocsykbFMitu3LtLgAX3k8iAo8=.b8a22bac-246c-479c-8acf-175427e32e5b@github.com> References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> <1Lx3cEk1vZnCgoRMNbocsykbFMitu3LtLgAX3k8iAo8=.b8a22bac-246c-479c-8acf-175427e32e5b@github.com> Message-ID: <-_Cf-s2WvPvCPen3n-Nly4PPX8OZHOQmjKn3UJH95KU=.3afd762b-16a9-4327-9e0d-76d026d55779@github.com> On Thu, 15 Jan 2026 20:00:43 GMT, Liam Miller-Cushon wrote: >> While is convenient that those UTF16 charsets have a easy to compute size, I doubt those two are in sufficient use to justify a commitment support them in the fast path. >> If you are going to support charsets beyond the most common utf8, ascii, and ISO-8856-1, then >> computing the encoded length should delegated to the Charset itself and have separate code in different packages. >> Have you looked at `CharsetEncoder.maxBytesPerChar()`, It might only be useful for single byte formats, but if `maxBytesPerChar` is equal to `averageBytesPerChar` that might be a useful shortcut. > >> While is convenient that those UTF16 charsets have a easy to compute size, I doubt those two are in sufficient use to justify a commitment support them in the fast path. If you are going to support charsets beyond the most common utf8, ascii, and ISO-8856-1, then computing the encoded length should delegated to the Charset itself and have separate code in different packages. > > Thanks, that makes sense to me. My opinion is that a large amount of the value here is in optimizing UTF-8, and that there's an argument to optimize the other standard charsets that `String` has other fast paths for, but sharply diminishing returns beyond that. I would be inclined to stop at the standard charsets, but also happy to make changes if there's a preference for having more or fewer fast paths. > >> Have you looked at `CharsetEncoder.maxBytesPerChar()`, It might only be useful for single byte formats, but if `maxBytesPerChar` is equal to `averageBytesPerChar` that might be a useful shortcut. > > I had a quick look at that, and saw errors for `IBM-Thai`: > > > CharsetEncoder encoder = cs.newEncoder(); > if (encoder.maxBytesPerChar() == 1f && encoder.maxBytesPerChar() == encoder.averageBytesPerChar()) { > return value.length * (int) encoder.maxBytesPerChar(); > } Its good to start with only the most common Charsets, and see if the API is adopted and anyone comments on a performance problem with other Charsets. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2695835410 From cushon at openjdk.org Thu Jan 15 22:17:14 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 22:17:14 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v10] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: implNote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/81d132f8..a6b37002 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=08-09 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Thu Jan 15 22:17:16 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 15 Jan 2026 22:17:16 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 20:23:55 GMT, Naoto Sato wrote: >> I think that makes sense, I'm not sure what the best way to characterize it is. Probably we don't want to promise specific optimizations. What do you think about: >> >> >> *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}, >> * and will have equivalent or better performance. > > I think this won't be a normative spec, so I'd move the performance description to `@apiNote` Done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2696149599 From pavel.rappo at gmail.com Thu Jan 15 22:59:02 2026 From: pavel.rappo at gmail.com (Pavel Rappo) Date: Thu, 15 Jan 2026 22:59:02 +0000 Subject: Can we deprecate Path.endsWith(String)? In-Reply-To: References: <663F1544-5770-447E-B8B1-E5F4E826035D@oracle.com> <02035CE4-61CA-4A85-BEE9-27CDA6B698EC@oracle.com> <3316a206-c9c3-4bc0-896a-2e5a03c9b472@oracle.com> <74591132-0606-4013-abab-5d71256d6f2a@oracle.com> Message-ID: Apologies if this is painfully obvious to everyone in this thread, but I want to explicitly draw attention to what Anthony is saying. Among other things, he is saying that Path.endsWith(String, String...) is NOT equivalent to Path.endsWith(Path.of(String, String...)), which people will be tempted to use without reading the javadoc or IDE hand-holding. The reason it's not equivalent is that two paths -- the receiver and the argument -- might be incompatible. That is, they might be produced by two different file systems. If paths in Path.endsWith(Path) are from different file systems, it's extremely likely to be a bug. And the way to maximise the odds of this bug is to construct the argument as Path.of(String, String...). Knowing the main author of this API a bit, this String-taking method wasn't introduced willy-nilly. It was likely introduced specifically to eliminate the described hazard. However, it looks like the method backfired in a really unexpected way. I guess no amount of thinking, even by a very smart person, can foresee all real-life issues. -Pavel On Wed, Jan 14, 2026 at 10:01?AM Anthony Vanelverdinghe wrote: > > On 1/14/2026 8:15 AM, Alan Bateman wrote: > > On 13/01/2026 20:13, Anthony Vanelverdinghe wrote: > >> There are 3 questions: > >> > >> (1) should we deprecate `Path::startsWith(String)`? > >> (2) should we deprecate `Path::endsWith(String)`? > >> (3) should we add a file extension API? > >> > > The "plan" is to deprecate startsWith(String) and endsWith(String), > > and to reboot the effort to add the file extension API. > > > > -Alan > > > Just for the record, emptying my bag of arguments: > > Google's Error Prone has a whole catalog of bug patterns, including > confusing Java SE APIs. Shall we deprecate all of those as well then? > And note that it does *not* have a bug pattern for > `Path::{starts,ends}With`. So nobody at Google ever bothered to add it. > And nobody outside Google ever bothered to file an issue to add it. > (Same for SonarQube, SpotBugs, or FindBugs: no pattern for this.) > > Virtually every Java developer has made the mistake of using > `Thread.sleep(5)` to mean "sleep 5 seconds" (which is the behavior in > pretty much every shell). So why are we not deprecating that method then? > > Even `String::endsWith(String)` itself is confusing, since some people > assume its argument is a regex (as with some other String methods like > `matches`) [1]. So why not e.g., replace `String::matches(String)` with > `String::matches(Pattern)`? > > [1] > https://stackoverflow.com/questions/9943609/checking-if-string-ends-with-something-with-java-regex > > Anthony > From lmesnik at openjdk.org Thu Jan 15 23:02:23 2026 From: lmesnik at openjdk.org (Leonid Mesnik) Date: Thu, 15 Jan 2026 23:02:23 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v7] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 15:31:21 GMT, Kieran Farrell wrote: >> The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. >> >> This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. > > Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: > > update to print java.security.Security properties This fix requires test for new added functionality. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29124#issuecomment-3757287652 From mdoerr at openjdk.org Thu Jan 15 23:11:02 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 15 Jan 2026 23:11:02 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Thu, 15 Jan 2026 18:06:03 GMT, Weijun Wang wrote: >> At the moment doing the conversion in Java and using a bigger carrier type (like `long`) is the only possible workaround. > > I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633? For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs` for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2696282888 From sviswanathan at openjdk.org Thu Jan 15 23:14:54 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 15 Jan 2026 23:14:54 GMT Subject: RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 04:24:24 GMT, Volodymyr Paprotski wrote: > Failure always for UU case, needle=2, len=17 > - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) > > Following down the code layout: > > if len==0 > return 0 > if len>needle > return -1 > if len<=16|32 && needle<=3|6 > optimized_short_cases > if len>16|32 > // big switch > switch(needle) { > default >10 > cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 > } > else > // small switch > switch(needle) { > cases 7..10 > // others under optimized_short_cases > } > > Furthermore.. big switch case itself has two cases.. > > if len-needle>31 > // works > // loop > else // len-needle<=31 > // BUG HERE > > The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. > > ----- > Why not found before? > - testcase issue, needle was UTF8 for UTF16 case > > Why only needle==2? > - Possibly because the mask for words has two bits, so tolerated off-by-one Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29242#pullrequestreview-3668028315 From vpaprotski at openjdk.org Thu Jan 15 23:14:55 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 15 Jan 2026 23:14:55 GMT Subject: RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 04:24:24 GMT, Volodymyr Paprotski wrote: > Failure always for UU case, needle=2, len=17 > - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) > > Following down the code layout: > > if len==0 > return 0 > if len>needle > return -1 > if len<=16|32 && needle<=3|6 > optimized_short_cases > if len>16|32 > // big switch > switch(needle) { > default >10 > cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 > } > else > // small switch > switch(needle) { > cases 7..10 > // others under optimized_short_cases > } > > Furthermore.. big switch case itself has two cases.. > > if len-needle>31 > // works > // loop > else // len-needle<=31 > // BUG HERE > > The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. > > ----- > Why not found before? > - testcase issue, needle was UTF8 for UTF16 case > > Why only needle==2? > - Possibly because the mask for words has two bits, so tolerated off-by-one Thanks for the approvals! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29242#issuecomment-3757320799 From vpaprotski at openjdk.org Thu Jan 15 23:14:55 2026 From: vpaprotski at openjdk.org (Volodymyr Paprotski) Date: Thu, 15 Jan 2026 23:14:55 GMT Subject: Integrated: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 04:24:24 GMT, Volodymyr Paprotski wrote: > Failure always for UU case, needle=2, len=17 > - (Note: `len=len-offset` in `library_call.cpp`, ie. stub does not see the same len as the test case) > > Following down the code layout: > > if len==0 > return 0 > if len>needle > return -1 > if len<=16|32 && needle<=3|6 > optimized_short_cases > if len>16|32 > // big switch > switch(needle) { > default >10 > cases 2..10 // BUG IS HERE: len 17|34, needle 2|4, case=4 > } > else > // small switch > switch(needle) { > cases 7..10 > // others under optimized_short_cases > } > > Furthermore.. big switch case itself has two cases.. > > if len-needle>31 > // works > // loop > else // len-needle<=31 > // BUG HERE > > The else case corrects mask misalignment; the 'correction shift' is off-by-1 for the UTF16 case. > > ----- > Why not found before? > - testcase issue, needle was UTF8 for UTF16 case > > Why only needle==2? > - Possibly because the mask for words has two bits, so tolerated off-by-one This pull request has now been integrated. Changeset: 1d889b92 Author: Volodymyr Paprotski URL: https://git.openjdk.org/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7 Stats: 19 lines in 2 files changed: 11 ins; 0 del; 8 mod 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings Reviewed-by: thartmann, jbhateja, sviswanathan ------------- PR: https://git.openjdk.org/jdk/pull/29242 From naoto at openjdk.org Fri Jan 16 00:23:30 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jan 2026 00:23:30 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: Message-ID: <7w_dZZlP0wD8At5LkqzovVSKb8UAFy6fN3kLDH-7lRk=.4c1a29bf-a10e-4a12-8f18-ab92369ed7c1@github.com> On Thu, 15 Jan 2026 22:13:43 GMT, Liam Miller-Cushon wrote: >> I think this won't be a normative spec, so I'd move the performance description to `@apiNote` > > Done I think `@apiNote` is more appropriate here, as the message applies to the API users, not API implementors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2696423836 From sviswanathan at openjdk.org Fri Jan 16 00:24:02 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 Jan 2026 00:24:02 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 22:59:16 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad src/hotspot/cpu/x86/x86.ad line 1706: > 1704: Label done; > 1705: __ setcc(Assembler::above, dst); > 1706: __ jcc(Assembler::aboveEqual, done); It would be better to keep the original sequence with optimization: __ movl(dst, -1); __ jcc(Assembler::below, done); __ setcc(Assembler::notEqual, dst); This would work for both AVX10_2 and prior as the Assembler::below covers both unordered and less. src/hotspot/cpu/x86/x86.ad line 9186: > 9184: %} > 9185: > 9186: instruct cmovI_regUCFE(cmpOpUCFE cop, rFlagsRegUCFE cr, rRegI dst, rRegI src) %{ The following instructs could be removed and only the ndd version need to be kept: cmovI_regUCFE cmovI_memUCFE cmovN_regUCFE cmovP_regUCFE cmovL_regUCFE cmovL_memUCFE cmpOpUCFE/rFlagsRegUCFE should only match when both AVX10_2 and APX is available otherwise fallback to cmpOpUCF/cmpOfUCF2/rFlagsRegUCF. We can then remove the predicates from cmovI_reg/cmovI_regUCFE_ndd etc. This is to avoid explosion of ad file instructs for various combination of APX and AVX10_2. src/hotspot/cpu/x86/x86.ad line 14609: > 14607: ins_encode %{ > 14608: __ ucomxss($src1$$XMMRegister, $src2$$XMMRegister); > 14609: emit_cmpfp3(masm, $dst$$Register); It looks to me that the only difference between cmpF_reg and cmpF_regE is ucomxss vs ucomiss. In which case it is better to keep only the original cmpF_reg and remove cmpF_regE. Likewise for cmpF_memE, cmpF_immE, cmpD_regE, cmpD_memE, cmpD_immE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696383810 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696362925 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2684261529 From almatvee at openjdk.org Fri Jan 16 01:21:09 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 01:21:09 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified Message-ID: - Version will be read from JDK's release file if not provided via `--version` for runtime installer. - Added test to cover added functionality. - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. ------------- Commit messages: - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified Changes: https://git.openjdk.org/jdk/pull/29260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357404 Stats: 274 lines in 9 files changed: 267 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From missa at openjdk.org Fri Jan 16 01:22:39 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 16 Jan 2026 01:22:39 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/cd7acad7..2aa782c2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=03-04 Stats: 223 lines in 1 file changed: 2 ins; 204 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From missa at openjdk.org Fri Jan 16 01:22:44 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 16 Jan 2026 01:22:44 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v4] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 23:57:58 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > > src/hotspot/cpu/x86/x86.ad line 1706: > >> 1704: Label done; >> 1705: __ setcc(Assembler::above, dst); >> 1706: __ jcc(Assembler::aboveEqual, done); > > It would be better to keep the original sequence with optimization: > __ movl(dst, -1); > __ jcc(Assembler::below, done); > __ setcc(Assembler::notEqual, dst); > This would work for both AVX10_2 and prior as the Assembler::below covers both unordered and less. Updated. > src/hotspot/cpu/x86/x86.ad line 9186: > >> 9184: %} >> 9185: >> 9186: instruct cmovI_regUCFE(cmpOpUCFE cop, rFlagsRegUCFE cr, rRegI dst, rRegI src) %{ > > The following instructs could be removed and only the ndd version need to be kept: > cmovI_regUCFE > cmovI_memUCFE > cmovN_regUCFE > cmovP_regUCFE > cmovL_regUCFE > cmovL_memUCFE > cmpOpUCFE/rFlagsRegUCFE should only match when both AVX10_2 and APX is available otherwise fallback to cmpOpUCF/cmpOfUCF2/rFlagsRegUCF. > We can then remove the predicates from cmovI_reg/cmovI_regUCFE_ndd etc. > This is to avoid explosion of ad file instructs for various combination of APX and AVX10_2. Updated > src/hotspot/cpu/x86/x86.ad line 14609: > >> 14607: ins_encode %{ >> 14608: __ ucomxss($src1$$XMMRegister, $src2$$XMMRegister); >> 14609: emit_cmpfp3(masm, $dst$$Register); > > It looks to me that the only difference between cmpF_reg and cmpF_regE is ucomxss vs ucomiss. In which case it is better to keep only the original cmpF_reg and remove cmpF_regE. Likewise for cmpF_memE, cmpF_immE, cmpD_regE, cmpD_memE, cmpD_immE. Updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696513365 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696513175 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2696512969 From almatvee at openjdk.org Fri Jan 16 01:26:37 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 01:26:37 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:13:55 GMT, Alexander Matveev wrote: > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. @alexeysemenyukoracle Please review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3757642387 From almatvee at openjdk.org Fri Jan 16 01:43:00 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 01:43:00 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: Message-ID: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29260/files - new: https://git.openjdk.org/jdk/pull/29260/files/bdf1c939..a891e85f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From dholmes at openjdk.org Fri Jan 16 01:54:55 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 16 Jan 2026 01:54:55 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3757721807 From almatvee at openjdk.org Fri Jan 16 02:30:21 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 02:30:21 GMT Subject: RFR: 8375364: Some jpackage signing tests fail after JDK-8375240 [v2] In-Reply-To: References: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> Message-ID: <-dKbo12PPH0qFf8vDh-uHQh8hIztnwNj_44bqurzpmA=.3991d3fb-c745-4171-8681-68f1aff7f0b9@github.com> On Thu, 15 Jan 2026 04:56:22 GMT, Alexey Semenyuk wrote: >> Fix a regression from the JDK-8375240 > > 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: > > 8375364: Some jpackage signing tests fail after JDK-8375240 Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29241#pullrequestreview-3668471895 From asemenyuk at openjdk.org Fri Jan 16 02:54:25 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 02:54:25 GMT Subject: Integrated: 8375364: [macos] Some jpackage signing tests fail after JDK-8375240 In-Reply-To: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> References: <0tYTcWZKaYFVEuEUBWFA-ZZE4ANyQ4cS18iqh_6Z5yM=.465eab85-39dc-48b5-a24a-935935e1612b@github.com> Message-ID: On Thu, 15 Jan 2026 03:28:20 GMT, Alexey Semenyuk wrote: > Fix a regression from the JDK-8375240 This pull request has now been integrated. Changeset: 9876875e Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/9876875e37b5cd4ac5263007ff96611ab0707cd5 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8375364: [macos] Some jpackage signing tests fail after JDK-8375240 Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29241 From almatvee at openjdk.org Fri Jan 16 03:07:53 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 03:07:53 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:23:00 GMT, Alexey Semenyuk wrote: > Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). > > Old test signatures: > > SigningAppImageTest.test(true, true, ASCII_INDEX) > SigningAppImageTest.test(true, true, UNICODE_INDEX) > SigningAppImageTest.test(true, false, UNICODE_INDEX) > SigningAppImageTest.test(false, true, INVALID_INDEX) > > SigningAppImageTwoStepsTest.test(true, true) > SigningAppImageTwoStepsTest.test(true, false) > SigningAppImageTwoStepsTest.test(false, true) > > SigningPackageTest.test(true, true, true, ASCII_INDEX) > SigningPackageTest.test(true, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, false, UNICODE_INDEX) > SigningPackageTest.test(false, false, true, UNICODE_INDEX) > > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > > SigningRuntimeImagePackageTest.test(true, INVALID_INDEX,... Looks good with some questions/comments. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 295: > 293: } > 294: > 295: public JPackageCommand setFakeRuntime() { I updated this function in https://github.com/openjdk/jdk/pull/29260 to include version for release file. Do you have suggestion on how resolve this conflict? I think we need ability to pass additional arguments to `setFakeRuntime(String version)`. In this case we will have `createInputRuntimeImage(RuntimeImageType role, String version)`, but it will not be clear to which runtime version should be applied. test/jdk/tools/jpackage/macosx/SigningBase.java line 2: > 1: /* > 2: * Copyright (c) 2019, 2026, Oracle and/or its affiliates. All rights reserved. Do you know why moving this file is not recorded as rename? test/jdk/tools/jpackage/macosx/SigningPackageTwoStepTest.java line 199: > 197: JPackageStringBundle.MAIN.cannedFormattedString("warning.unsigned.app.image", "pkg"); > 198: > 199: // The warnings are mutual exclusive `mutual` -> `mutually` ------------- PR Review: https://git.openjdk.org/jdk/pull/29205#pullrequestreview-3668410198 PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696588745 PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696666005 PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696675195 From almatvee at openjdk.org Fri Jan 16 04:04:56 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 04:04:56 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] In-Reply-To: References: Message-ID: > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29260/files - new: https://git.openjdk.org/jdk/pull/29260/files/a891e85f..6cd84550 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=01-02 Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From asemenyuk at openjdk.org Fri Jan 16 04:05:03 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:05:03 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: On Fri, 16 Jan 2026 01:43:00 GMT, Alexander Matveev wrote: >> - Version will be read from JDK's release file if not provided via `--version` for runtime installer. >> - Added test to cover added functionality. >> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] Changes requested by asemenyuk (Reviewer). src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacFromOptions.java line 365: > 363: components = version.split("\\.", 4); > 364: return String.join(".", Arrays.copyOf(components, components.length - 1)); > 365: } Use jdk.jpackage.internal.model.DottedVersion class to break the version string into components. This will stop at the first invalid character: DottedVersion ver = DottedVersion.lazy(str); This will throw `IllegalArgumentException` if it hits the first non-parsable character: DottedVersion ver = DottedVersion.greedy(str); src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 1: > 1: /* The class should include a single function that takes a path to the "release" file and returns a non-null String version extracted from it. It should throw an exception if it can not find a version in the file. A custom or a standard one, e.g. `java.util.NoSuchElementException`. Alternatively, it may return an `Optional` and not throw exceptions if it fails to extract a version string from the "release" file. It should not swallow I/O errors. If it can't handle them on the spot, let them out. It should not detect where the "release" file is located in the runtime image. It should not have platform-specific branching, because there is nothing platform-specific in extracting the version from the "release" file. "jdk.jpackage.internal.Log" class should not be referenced from other jpackage packages. The only exception is configuring the logger in the "cli" package (this one should eventually be cleaned up). Adding a reference to the "Log" class here will leak it into the test code, where it will be used outside the jpackage tool provider context. This is undefined behavior. Which, I guess, could have been caught early with a unit test :) The class should be covered with unit tests: - Read a version from the valid "release" file - Read a version from an invalid "release" file - Read a version from any "release" file, but fail because of I/O error. Easy to simulate this condition by passing a directory into the `readVersion()` method. src/jdk.jpackage/share/classes/jdk/jpackage/internal/util/RuntimeVersionReader.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Copyright year should be 2026 src/jdk.jpackage/windows/classes/jdk/jpackage/internal/WinFromOptions.java line 157: > 155: components = version.split("\\.", 5); > 156: return String.join(".", Arrays.copyOf(components, components.length - 1)); > 157: } Use the DottedVersion class to break the version string into components. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 270: > 268: } > 269: > 270: return getArgumentValue("--app-version", () -> "1.0"); The idea of the Optional class is to reduce branching and null checks in the code. The entire body of the method can be simplified down to: public String version() { return Optional.ofNullable(getArgumentValue("--app-version")).or(() -> { if (isRuntime()) { return RuntimeVersionReader.readVersion(Path.of(getArgumentValue("--runtime-image"))).map(releaseVersion -> { if (TKit.isWindows()) { return WindowsHelper.getNormalizedVersion(releaseVersion); } else if (TKit.isOSX()) { return MacHelper.getNormalizedVersion(releaseVersion); } else { return releaseVersion; } }); } else { return Optional.empty(); } }).orElse("1.0"); } test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 362: > 360: } > 361: }); > 362: The fake runtime's version configuration doesn't belong here. It is specific to a single test and should be part of the test. test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 765: > 763: > 764: static String getNormalizedVersion(JPackageCommand cmd, String version) { > 765: cmd.verifyIsOfType(PackageType.MAC); The JPackageCommand instance is unrelated to the version string and is used only to check that it is configured for Mac. It doesn't supply any information required by the method to operate. The method should take a single parameter - a version string. Why does the MacHelper class have this method, though jpackage doesn't do version normalization on macOS? test/jdk/tools/jpackage/share/RuntimePackageTest.java line 119: > 117: @Parameter("27.1.2.3") > 118: @Parameter("27.1.2.3.4") > 119: public static void testReleaseFileVersion(String version) { The test is missing coverage for the new "message.release-version" and "message.version-normalized" messages ------------- PR Review: https://git.openjdk.org/jdk/pull/29260#pullrequestreview-3668524711 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696675804 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696760330 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696676762 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696688751 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696726813 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696684510 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696708342 PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696729972 From almatvee at openjdk.org Fri Jan 16 04:05:04 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 04:05:04 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: On Fri, 16 Jan 2026 01:43:00 GMT, Alexander Matveev wrote: >> - Version will be read from JDK's release file if not provided via `--version` for runtime installer. >> - Added test to cover added functionality. >> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] - `normalizeVersion()` should be called only for runtime installer, otherwise it will normalize version read from module. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3758023757 From almatvee at openjdk.org Fri Jan 16 04:11:59 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 04:11:59 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: On Fri, 16 Jan 2026 03:15:39 GMT, Alexey Semenyuk wrote: >> Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: >> >> 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] > > test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 765: > >> 763: >> 764: static String getNormalizedVersion(JPackageCommand cmd, String version) { >> 765: cmd.verifyIsOfType(PackageType.MAC); > > The JPackageCommand instance is unrelated to the version string and is used only to check that it is configured for Mac. It doesn't supply any information required by the method to operate. The method should take a single parameter - a version string. > > Why does the MacHelper class have this method, though jpackage doesn't do version normalization on macOS? I added it to reduce to 3 components due to `MacApplicationBuilder.validateAppVersion()`. Mac packages does not require 3 component version, so maybe this logic by normalizing application version should change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696814647 From asemenyuk at openjdk.org Fri Jan 16 04:21:07 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:21:07 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage In-Reply-To: References: Message-ID: <1rpkNjX_0DOvIc0JRVkrY30jZWgLhHum9HW78SBcjoo=.7042659d-0223-4efa-bbcd-d73d462a58e3@github.com> On Fri, 16 Jan 2026 02:03:03 GMT, Alexander Matveev wrote: > I think we need ability to pass additional arguments to setFakeRuntime(String version) To suit the needs of a single test? Any chance we need a fake runtime with the "release" file in other tests? > In this case we will have `createInputRuntimeImage(RuntimeImageType role, String version)` Two major problems with this approach: - Eventually, we will end up with `createInputRuntimeImage(RuntimeImageType role, String version, String fooProperty, boolean barProperty, Date dateProperty)` signature. Which will be unreadable, just like we had it at https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java#L108 The calls will be equally unreadable to: https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java#L330 - When the external runtime is specified for the test with the "jdk.jpackage.runtime-image" system property, what to do with the "version" parameter? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696835672 From asemenyuk at openjdk.org Fri Jan 16 04:25:07 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:25:07 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 02:49:41 GMT, Alexander Matveev wrote: >> Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). >> >> Old test signatures: >> >> SigningAppImageTest.test(true, true, ASCII_INDEX) >> SigningAppImageTest.test(true, true, UNICODE_INDEX) >> SigningAppImageTest.test(true, false, UNICODE_INDEX) >> SigningAppImageTest.test(false, true, INVALID_INDEX) >> >> SigningAppImageTwoStepsTest.test(true, true) >> SigningAppImageTwoStepsTest.test(true, false) >> SigningAppImageTwoStepsTest.test(false, true) >> >> SigningPackageTest.test(true, true, true, ASCII_INDEX) >> SigningPackageTest.test(true, true, true, UNICODE_INDEX) >> SigningPackageTest.test(false, true, true, UNICODE_INDEX) >> SigningPackageTest.test(false, true, false, UNICODE_INDEX) >> SigningPackageTest.test(false, false, true, UNICODE_INDEX) >> >> SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) >> SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) >> >> Si... > > test/jdk/tools/jpackage/macosx/SigningBase.java line 2: > >> 1: /* >> 2: * Copyright (c) 2019, 2026, Oracle and/or its affiliates. All rights reserved. > > Do you know why moving this file is not recorded as rename? Absolutely no idea. I may be able to fix this by using `git mv` command, ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696846668 From asemenyuk at openjdk.org Fri Jan 16 04:30:14 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:30:14 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: On Fri, 16 Jan 2026 04:08:43 GMT, Alexander Matveev wrote: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MacHelper.java line 765: >> >>> 763: >>> 764: static String getNormalizedVersion(JPackageCommand cmd, String version) { >>> 765: cmd.verifyIsOfType(PackageType.MAC); >> >> The JPackageCommand instance is unrelated to the version string and is used only to check that it is configured for Mac. It doesn't supply any information required by the method to operate. The method should take a single parameter - a version string. >> >> Why does the MacHelper class have this method, though jpackage doesn't do version normalization on macOS? > > I added it to reduce to 3 components due to `MacApplicationBuilder.validateAppVersion()`. Mac packages does not require 3 component version, so maybe this logic by normalizing application version should change. Sorry, I still don't get it. jpackage doesn't run normalization on the version it reads from the "release" file, right? Why does the testing code do it? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696858526 From almatvee at openjdk.org Fri Jan 16 04:36:16 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 04:36:16 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: <-25Qjxn-TPFfBQJvJ-QYf8fpQJRG0WCcczoqIMksA1c=.c8e196de-ebaf-48df-8e97-84c052f5d3a2@github.com> On Fri, 16 Jan 2026 04:27:11 GMT, Alexey Semenyuk wrote: >> I added it to reduce to 3 components due to `MacApplicationBuilder.validateAppVersion()`. Mac packages does not require 3 component version, so maybe this logic by normalizing application version should change. > > Sorry, I still don't get it. jpackage doesn't run normalization on the version it reads from the "release" file, right? Why does the testing code do it? jpackage will normalize macOS version read from release file to 3 components and Windows to 4 components. See `MacFromOptions` and `WinApplication`. Normalization is done for application and package builder just use it from application. macOS limits application version CFBundleVersion to 3 components, thus to align with Windows it was limited to 3. Testing code needs to do same. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696869000 From asemenyuk at openjdk.org Fri Jan 16 04:36:16 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:36:16 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: <-25Qjxn-TPFfBQJvJ-QYf8fpQJRG0WCcczoqIMksA1c=.c8e196de-ebaf-48df-8e97-84c052f5d3a2@github.com> References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <-25Qjxn-TPFfBQJvJ-QYf8fpQJRG0WCcczoqIMksA1c=.c8e196de-ebaf-48df-8e97-84c052f5d3a2@github.com> Message-ID: <9dZcrg4MHnxzPsXL16h6j9pvmxzgXgGmum5MkFcX-bk=.7e2a5126-a6de-487a-a279-43e61de6541e@github.com> On Fri, 16 Jan 2026 04:31:54 GMT, Alexander Matveev wrote: >> Sorry, I still don't get it. jpackage doesn't run normalization on the version it reads from the "release" file, right? Why does the testing code do it? > > jpackage will normalize macOS version read from release file to 3 components and Windows to 4 components. See `MacFromOptions` and `WinApplication`. Normalization is done for application and package builder just use it from application. macOS limits application version CFBundleVersion to 3 components, thus to align with Windows it was limited to 3. Testing code needs to do same. Never mind, I assumed that version normalization would be implemented only on Windows, based on our offline conversation yesterday. But it applies to both macOS and Windows. So the function itself is alright, only the signature needs updating ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29260#discussion_r2696871654 From asemenyuk at openjdk.org Fri Jan 16 04:43:49 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:43:49 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 04:04:56 GMT, Alexander Matveev wrote: >> - Version will be read from JDK's release file if not provided via `--version` for runtime installer. >> - Added test to cover added functionality. >> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. > > Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: > > 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] There is duplicated code in the MacFromOptions and WinFromOptions classes. I suggest moving it into `Application ApplicationBuilder.normalizeVersion(Application app, UnaryOperator versionNormalizer)` utility function. This class already has code copying Application instances with mods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3758127555 From asemenyuk at openjdk.org Fri Jan 16 04:47:06 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:47:06 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> Message-ID: <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> On Fri, 16 Jan 2026 04:01:33 GMT, Alexander Matveev wrote: > normalizeVersion() should be called only for runtime installer, otherwise it will normalize version read from module. Isn't it the right thing to do in general, even though unrelated to the subject of this PR? Maybe step back, file a CR to implement version normalization, and implement version reading from the "release" file on top of it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3758135267 From asemenyuk at openjdk.org Fri Jan 16 04:55:01 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 04:55:01 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage [v2] In-Reply-To: References: Message-ID: <8_Z6uXMN9h-JvWnsdog-JW4jq2AZTj9iFVxCs8OEwPg=.4f9e4193-d8bb-4164-9d9b-706df2cf76b8@github.com> > Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). > > Old test signatures: > > SigningAppImageTest.test(true, true, ASCII_INDEX) > SigningAppImageTest.test(true, true, UNICODE_INDEX) > SigningAppImageTest.test(true, false, UNICODE_INDEX) > SigningAppImageTest.test(false, true, INVALID_INDEX) > > SigningAppImageTwoStepsTest.test(true, true) > SigningAppImageTwoStepsTest.test(true, false) > SigningAppImageTwoStepsTest.test(false, true) > > SigningPackageTest.test(true, true, true, ASCII_INDEX) > SigningPackageTest.test(true, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, false, UNICODE_INDEX) > SigningPackageTest.test(false, false, true, UNICODE_INDEX) > > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > > SigningRuntimeImagePackageTest.test(true, INVALID_INDEX,... Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision: SigningPackageTwoStepTest: fix a typo in the comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29205/files - new: https://git.openjdk.org/jdk/pull/29205/files/f55906bc..8224f5e5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29205&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29205&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29205/head:pull/29205 PR: https://git.openjdk.org/jdk/pull/29205 From almatvee at openjdk.org Fri Jan 16 05:05:43 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 05:05:43 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> Message-ID: On Fri, 16 Jan 2026 04:44:24 GMT, Alexey Semenyuk wrote: > > normalizeVersion() should be called only for runtime installer, otherwise it will normalize version read from module. > > Isn't it the right thing to do in general, even though unrelated to the subject of this PR? Not sure. Do we want to normalize module version? What possible format for module version? https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/module/ModuleDescriptor.Version.html Module version is more complicated then release file. It can contain "-", "+" and any characters if I am reading doc file correctly. > > Maybe step back, file a CR to implement version normalization, and implement version reading from the "release" file on top of it? Not sure. I think we can file a bug to normalize module version for all platforms to "N.N.N..." (just numbers and "."). Then remove platform specific normalization check for runtime installer only. In this case it should just work. Having generic normalization for both module, release file or anything else is probably over complicated. Platform specific code should just handle numbers and digit for normalization and code which reads module version or anything else should provide all numbers and digits. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3758174327 From asemenyuk at openjdk.org Fri Jan 16 05:06:39 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 05:06:39 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage [v3] In-Reply-To: References: Message-ID: > Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). > > Old test signatures: > > SigningAppImageTest.test(true, true, ASCII_INDEX) > SigningAppImageTest.test(true, true, UNICODE_INDEX) > SigningAppImageTest.test(true, false, UNICODE_INDEX) > SigningAppImageTest.test(false, true, INVALID_INDEX) > > SigningAppImageTwoStepsTest.test(true, true) > SigningAppImageTwoStepsTest.test(true, false) > SigningAppImageTwoStepsTest.test(false, true) > > SigningPackageTest.test(true, true, true, ASCII_INDEX) > SigningPackageTest.test(true, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, false, UNICODE_INDEX) > SigningPackageTest.test(false, false, true, UNICODE_INDEX) > > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > > SigningRuntimeImagePackageTest.test(true, INVALID_INDEX,... Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: - Revert "SigningBase: move to the "base"" This reverts commit b50c717d83096b67ff530d90715d87fa0d9ade20. - SigningBase: move to the "base" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29205/files - new: https://git.openjdk.org/jdk/pull/29205/files/8224f5e5..0deb3b69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29205&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29205&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29205/head:pull/29205 PR: https://git.openjdk.org/jdk/pull/29205 From asemenyuk at openjdk.org Fri Jan 16 05:06:41 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 05:06:41 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 04:21:38 GMT, Alexey Semenyuk wrote: >> test/jdk/tools/jpackage/macosx/SigningBase.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2019, 2026, Oracle and/or its affiliates. All rights reserved. >> >> Do you know why moving this file is not recorded as rename? > > Absolutely no idea. I may be able to fix this by using `git mv` command, Git actually recorded the file as moved in the commit - https://github.com/openjdk/jdk/pull/29205/changes/519304d36b9502d734250b5b95ab3f167e54fdf0#diff-1e9f8fc53464a23ef8d99de74261e068d584db064b17bcc2433babf202d78b6d GitHub doesn't display the move correctly. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2696919515 From asemenyuk at openjdk.org Fri Jan 16 05:19:51 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 05:19:51 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> Message-ID: On Fri, 16 Jan 2026 05:02:46 GMT, Alexander Matveev wrote: > Do we want to normalize module version? When jpackage derives bundle properties from the input data, it should get the valid values. If it can't do it, it should fail. > What possible format for module version? No idea. How is it relevant? If jpackage can't get a valid platform-specific bundle version from the module version, it should fail. > Having generic normalization for both module, release file or anything else is probably over complicated. It is the opposite: applying the same normalization function to any input is simple. If it can't produce a valid output, stop further processing if there are no other options. Besides a command line, jpackage can derive the app version from the main jar, module, and now from the runtime. Do you suggest handling these cases differently? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3758208238 From erfang at openjdk.org Fri Jan 16 06:10:25 2026 From: erfang at openjdk.org (Eric Fang) Date: Fri, 16 Jan 2026 06:10:25 GMT Subject: [jdk26] RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions Message-ID: Hi all, This pull request contains a backport of commit 56d7b524 from the openjdk/jdk repository. The commit being backported was authored by Eric Fang on 14 Jan 2026 and was reviewed by Paul Sandoz, Quan Anh Mai and Xiaohong Gong. Thanks! ------------- Commit messages: - Backport 56d7b524b3ddb49b985b4e6f061a7128b10cffb5 Changes: https://git.openjdk.org/jdk/pull/29262/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29262&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8372978 Stats: 13975 lines in 48 files changed: 7543 ins; 3660 del; 2772 mod Patch: https://git.openjdk.org/jdk/pull/29262.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29262/head:pull/29262 PR: https://git.openjdk.org/jdk/pull/29262 From alanb at openjdk.org Fri Jan 16 07:09:46 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 07:09:46 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:50:50 GMT, David Holmes wrote: > It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? Parking (including timed-parking) is much simpler, and okay to be unparked during transition. We have a lot of tests for this. Timed-Object.wait is more complex due to the two block states (the equivalent of Thread.State TIMED_WAITING and BLOCKED), and timed and unblocking working asynchronously. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3758486123 From thartmann at openjdk.org Fri Jan 16 07:14:07 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Fri, 16 Jan 2026 07:14:07 GMT Subject: [jdk26] RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings Message-ID: Hi all, This pull request contains a backport of commit [1d889b92](https://github.com/openjdk/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Volodymyr Paprotski on 15 Jan 2026 and was reviewed by Tobias Hartmann, Jatin Bhateja and Sandhya Viswanathan. Thanks! ------------- Commit messages: - Backport 1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7 Changes: https://git.openjdk.org/jdk/pull/29263/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29263&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8360271 Stats: 19 lines in 2 files changed: 11 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29263.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29263/head:pull/29263 PR: https://git.openjdk.org/jdk/pull/29263 From mhaessig at openjdk.org Fri Jan 16 08:57:36 2026 From: mhaessig at openjdk.org (Manuel =?UTF-8?B?SMOkc3NpZw==?=) Date: Fri, 16 Jan 2026 08:57:36 GMT Subject: [jdk26] RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 07:08:06 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [1d889b92](https://github.com/openjdk/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 15 Jan 2026 and was reviewed by Tobias Hartmann, Jatin Bhateja and Sandhya Viswanathan. > > Thanks! Thank you for taking care of the backport. Looks good. ------------- Marked as reviewed by mhaessig (Committer). PR Review: https://git.openjdk.org/jdk/pull/29263#pullrequestreview-3669616756 From cushon at openjdk.org Fri Jan 16 09:46:54 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 16 Jan 2026 09:46:54 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: Message-ID: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Switch to @apiNote ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/a6b37002..2614c356 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=09-10 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Fri Jan 16 09:46:55 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 16 Jan 2026 09:46:55 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: <7w_dZZlP0wD8At5LkqzovVSKb8UAFy6fN3kLDH-7lRk=.4c1a29bf-a10e-4a12-8f18-ab92369ed7c1@github.com> References: <7w_dZZlP0wD8At5LkqzovVSKb8UAFy6fN3kLDH-7lRk=.4c1a29bf-a10e-4a12-8f18-ab92369ed7c1@github.com> Message-ID: On Fri, 16 Jan 2026 00:19:51 GMT, Naoto Sato wrote: >> Done > > I think `@apiNote` is more appropriate here, as the message applies to the API users, not API implementors. Thanks, I switched to `@apiNote`. Is https://openjdk.org/jeps/8068562 a good reference for distinction between these tags? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2697737150 From cushon at openjdk.org Fri Jan 16 11:07:56 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 16 Jan 2026 11:07:56 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v5] In-Reply-To: <94U314HJBN96ktT1MqD-GOo43rAbnQZAEFcJzdHGa6E=.e9b215c1-b1ec-4522-b257-d098d4663783@github.com> References: <5zNvMwXRSYwIPJXv7E9WI7hFI4WKrAmYuOIkGr8LP6E=.191d9b99-851e-4b2f-b200-6a7ade231cb3@github.com> <94U314HJBN96ktT1MqD-GOo43rAbnQZAEFcJzdHGa6E=.e9b215c1-b1ec-4522-b257-d098d4663783@github.com> Message-ID: On Thu, 15 Jan 2026 16:30:26 GMT, Volkan Yazici wrote: >> Done, thanks > > The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. Thanks, I switched to just `@link` instead of `@linkplain`+`@code` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2698076823 From dgredler at openjdk.org Fri Jan 16 12:34:29 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 16 Jan 2026 12:34:29 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 15:12:23 GMT, Alan Bateman wrote: > Is your real concern with buf.length getting close to Integer.MAX_VALUE? No, the main concern is to be able to hook into the standard buffer growth logic. Right now users are given one chance to explicitly request growth to a minimum size (via the constructor), and thereafter can only implicitly do so as part of write operations. > BAOS is more of an implementation class By this do you mean that subclassing BAOS is not encouraged? In my experience this is relatively common, and the class design seems to encourage it (the class is not final, instance variables are protected). > Aside from writeLong, could you list out the methods that you've since in BAOS subclasses. I'm wondering if BAOS should implement some of the methods defined by DataOutput to avoid needing to subclass I have seen e.g. `writeInt16` and `writeInt32` methods added, especially when the focus is on writing binary file or wire formats. It's an interesting idea, but I would think that the risk of adding a public `writeLong` method is higher than the risk of adding this protected method. The inclination will then be to add methods for more (all?) primitive types, further increasing the risk. Allowing users to request buffer growth via `ensureCapacity` seems to me both more flexible / general (addressing a broader set of user needs) and less risky. Having said that -- I think the main risk of this change (this was raised by @RogerRiggs in the CSR in JBS) are conflicts with subclasses which already tried to work around this limitation by adding an `ensureCapacity` method, but made that subclass method private or package-private (public or protected would be fine). This risk is non-negligible because `ensureCapacity` is a well-established method name both in `ByteArrayOutputStream` and in other core classes like `ArrayList` and `StringBuilder`. Thus, it is more likely that subclasses will have used this name for this type of functionality (my own `LongStream2` workaround example above would fail to compile). Changing the protected method name (to e.g. `ensureSpace` or `growToAtLeast`) would reduce risk, but would be slightly inconsistent with established nomenclature... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3759722722 From alanb at openjdk.org Fri Jan 16 12:34:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 12:34:31 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 12:01:18 GMT, Daniel Gredler wrote: > By this do you mean that subclassing BAOS is not encouraged? In my experience this is relatively common, and the class design seems to encourage it (the class is not final, instance variables are protected). Many JDK 1.0/1.1 were designed for subclassing. The java.io package has many non-final/sealed classes with protected fields so the subclass can access the byte[], position, mark, etc. If designed today then I'm sure they would look differently. OutputStream would probably be an interface and there would be factory methods, would not be synchronized, there would be a lot less decorator pattern. I don't object to adding an ensureCapacity method but we need to think about whether to re-specify the existing methods writeXXX methods to invoke it. With the current proposal I can extend BAOS, override ensureCapacity, but it wouldn't be called when using the existing methods to write. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3759825378 From dgredler at openjdk.org Fri Jan 16 12:45:58 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Fri, 16 Jan 2026 12:45:58 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 12:31:09 GMT, Alan Bateman wrote: > With the current proposal I can extend BAOS, override ensureCapacity, but it wouldn't be called when using the existing methods to write. True. I'll tweak the PR to address this and see how it looks. What would you think about renaming the method to `setMinCapacity` in order to reduce conflict risk? Roger's point about reduced visibility conflicts is a good one, given the established use of the `ensureCapacity` name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3759861538 From jbhateja at openjdk.org Fri Jan 16 12:50:39 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 16 Jan 2026 12:50:39 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: <3uKUR2sP_jgcwbuDsrH8iIf2V9b-N8H6bv_tJPWNL20=.74a841cb-df9b-443a-8bbe-4ea4e7dd9996@github.com> On Thu, 15 Jan 2026 07:23:41 GMT, Emanuel Peter wrote: >> @jatin-bhateja What do you think? > > Someone filed the RFE: https://bugs.openjdk.org/browse/JDK-8375321 I experience problems with auto-vectorization of reduction kernels for other box types also. Added an example in the JDK-8375321 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2698390695 From alanb at openjdk.org Fri Jan 16 13:49:46 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 13:49:46 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Great sleuthing, this was a really hard one to diagnose. src/java.base/share/classes/java/lang/VirtualThread.java line 644: > 642: setState(newState = TIMED_WAIT); > 643: // May have been notified while in transition. This must be done while > 644: // holding the monitor to avoid changing the state of a new timed wait call. "to avoid changing the state of a new timed wait call". It might be clearer to say move to the blocked state before the timeout task can execute. src/java.base/share/classes/java/lang/VirtualThread.java line 652: > 650: // may have been unblocked already > 651: if (blockPermit && compareAndSetState(BLOCKED, UNBLOCKED)) { > 652: lazySubmitRunContinuation(); Moving to lazySubmit is good here, this helps improve the chance of continuing with the current platform thread as the carrier when notified and unblocked during the transition. test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: > 75: } > 76: }); > 77: var pthread = Thread.ofPlatform().start(() -> { A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. ------------- PR Review: https://git.openjdk.org/jdk/pull/29255#pullrequestreview-3670903428 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698546064 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698550733 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2698564280 From rriggs at openjdk.org Fri Jan 16 13:59:42 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 13:59:42 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 22:13:06 GMT, Daniel Gredler wrote: > ByteArrayOutputStream.ensureCapacity(int) is currently private. It would be useful if it were protected, so that it can be more easily extended by subclasses. > > Mailing list discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/156983.html Existing subclasses of BAOS, that are adding new methods, either have to check the capacity directly with the buffer themselves or call superclass implementations to write to the buffer, and those ensure the capacity. So I don't think there is a risk to existing subclasses. Calling `ensureCapacity` is an optimization to pre-size the buffer. A new subclass still has to deal with checking against the buffer array size or use existing methods to do the writes. So no new risk in that. If there is any new advice to be given, it is just being explicit about the current advice, check the buffer sizes yourself or call existing write methods. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3760130999 From rriggs at openjdk.org Fri Jan 16 15:39:15 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 16 Jan 2026 15:39:15 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Fri, 16 Jan 2026 09:46:54 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to @apiNote Looks good. A second reviewer is a good idea for new APIs. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3671471698 PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3760625524 From sviswanathan at openjdk.org Fri Jan 16 15:59:43 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 Jan 2026 15:59:43 GMT Subject: [jdk26] RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 07:08:06 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [1d889b92](https://github.com/openjdk/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 15 Jan 2026 and was reviewed by Tobias Hartmann, Jatin Bhateja and Sandhya Viswanathan. > > Thanks! Marked as reviewed by sviswanathan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29263#pullrequestreview-3671578823 From alanb at openjdk.org Fri Jan 16 16:27:49 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 16 Jan 2026 16:27:49 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 12:42:25 GMT, Daniel Gredler wrote: > True. I'll tweak the PR to address this and see how it looks. Thanks. It would need to be specified so that it's clear that the method is not a "hook" to expand the capacity, it's simply a connivance method for subclasses override the existing methods or adding new write methods that are not based on the write methods in the superclass. > What would you think about renaming the method to `setMinCapacity` in order to reduce conflict risk? Roger's point about reduced visibility conflicts is a good one, given the established use of the `ensureCapacity` name. I think it would be useful some static analysis to get a sense for how many libraries extend BAOS and have their own ensureCapacity method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3760827724 From pchilanomate at openjdk.org Fri Jan 16 17:07:34 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:07:34 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: add comment in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29255/files - new: https://git.openjdk.org/jdk/pull/29255/files/39d7ac79..b69a40f1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=00-01 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From pchilanomate at openjdk.org Fri Jan 16 17:12:15 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:12:15 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:50:50 GMT, David Holmes wrote: > @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. > > It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > Thanks for looking at this anyway David. Yes, that case is fine. Just to add to Alan's answer, the unparker can set `parkPermit` but it won't be able to change the state and submit the vthread to run again while in `TIMED_PARKING` state. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3760993471 From pchilanomate at openjdk.org Fri Jan 16 17:12:21 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Fri, 16 Jan 2026 17:12:21 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 13:37:49 GMT, Alan Bateman wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment in test > > src/java.base/share/classes/java/lang/VirtualThread.java line 644: > >> 642: setState(newState = TIMED_WAIT); >> 643: // May have been notified while in transition. This must be done while >> 644: // holding the monitor to avoid changing the state of a new timed wait call. > > "to avoid changing the state of a new timed wait call". It might be clearer to say move to the blocked state before the timeout task can execute. I wanted to keep it more general because the thread can also run again due to notification+unblock or interruption. > test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: > >> 75: } >> 76: }); >> 77: var pthread = Thread.ofPlatform().start(() -> { > > A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699306583 PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2699307350 From eirbjo at gmail.com Fri Jan 16 18:26:28 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Fri, 16 Jan 2026 19:26:28 +0100 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? Message-ID: Hi, java.lang.Shutdown uses a static nested Lock class for synchronization. This seems trivially replaceable with new Object() which would reduce class loading during shutdown. java.lang.ref.ReferenceQueue uses a similar idiom and could potentially be cleaned up as well. I'd be happy to contribute a PR for this cleanup. Worth pursuing? Thoughts? Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sviswanathan at openjdk.org Fri Jan 16 18:27:31 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 16 Jan 2026 18:27:31 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 01:22:39 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 src/hotspot/cpu/x86/assembler_x86.cpp line 7357: > 7355: } > 7356: > 7357: void Assembler::ucomxss(XMMRegister dst, Address src) { ucomxss should be named as vucomxss. ucomxsd should be named as vucomxsd. src/hotspot/cpu/x86/x86.ad line 1703: > 1701: static void emit_cmpfp3(MacroAssembler* masm, Register dst) { > 1702: // If any floating point comparison instruction is used, unordered case always triggers jump > 1703: // For below condition, CF=1 is true when at least one input is NaN // for lowercase f in for. test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 64: > 62: @IR(counts = {IRNode.X86_CMOVEL_IMM01UCFE, "1"}, > 63: applyIfPlatform = {"x64", "true"}, > 64: applyIfCPUFeature = {"apx_f", "true"}, Need to include avx10_2 check here as well. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699354660 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699427353 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2699527070 From naoto at openjdk.org Fri Jan 16 18:34:04 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jan 2026 18:34:04 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Fri, 16 Jan 2026 09:46:54 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to @apiNote Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3672192064 From naoto at openjdk.org Fri Jan 16 18:34:05 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 16 Jan 2026 18:34:05 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v8] In-Reply-To: References: <7w_dZZlP0wD8At5LkqzovVSKb8UAFy6fN3kLDH-7lRk=.4c1a29bf-a10e-4a12-8f18-ab92369ed7c1@github.com> Message-ID: <3gBidrzlHSA7ev-2GRarh-WG5rjhK0uDoZfqcAVoO8c=.5ea2f86b-715d-4bea-8ab5-3a04db2a7459@github.com> On Fri, 16 Jan 2026 09:43:30 GMT, Liam Miller-Cushon wrote: > Is https://openjdk.org/jeps/8068562 a good reference for distinction between these tags? Yes. It does state that `@implNote` can state performance characteristics, but in this case I think `@apiNote` is more appropriate so that users will know the rationale behind the introduction of this method. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2699558630 From almatvee at openjdk.org Fri Jan 16 19:55:33 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 19:55:33 GMT Subject: RFR: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 16:24:23 GMT, Alexey Semenyuk wrote: >> Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. >> >> This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). > > 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 12 new commits since the last revision: > > - Update copyright year > - InOutPathTest: remove tests cases for non-existent paths specified for --app-content and --mac-dmg-content options; AppContentTest: add a test case for --app-content set to the output app image > - FileUtils: remove redundant functionality > - Add and integrate RootedPath > - AppContentTest: don't verify app image if jpackage is expected to fail > - Support two-step OptionValueConverter > - Add ValueConverterFunction > - Change signature of OptionValueConverter. > - Validator, OptionValueConverter: better javadoc > - Change signature of ValueConverter::convert() > - ... and 2 more: https://git.openjdk.org/jdk/compare/46375e6f...5c47219b Marked as reviewed by almatvee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29194#pullrequestreview-3672479454 From almatvee at openjdk.org Fri Jan 16 19:58:56 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 19:58:56 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage [v3] In-Reply-To: <1rpkNjX_0DOvIc0JRVkrY30jZWgLhHum9HW78SBcjoo=.7042659d-0223-4efa-bbcd-d73d462a58e3@github.com> References: <1rpkNjX_0DOvIc0JRVkrY30jZWgLhHum9HW78SBcjoo=.7042659d-0223-4efa-bbcd-d73d462a58e3@github.com> Message-ID: <3FoShdrA9D4Kv1eWgIY_FbCAJqtJNtF_M9ZiNrqoNLk=.ce89a30e-388a-42c2-9f4f-68b784522b0c@github.com> On Fri, 16 Jan 2026 04:17:32 GMT, Alexey Semenyuk wrote: >> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 295: >> >>> 293: } >>> 294: >>> 295: public JPackageCommand setFakeRuntime() { >> >> I updated this function in https://github.com/openjdk/jdk/pull/29260 to include version for release file. Do you have suggestion on how resolve this conflict? I think we need ability to pass additional arguments to `setFakeRuntime(String version)`. In this case we will have `createInputRuntimeImage(RuntimeImageType role, String version)`, but it will not be clear to which runtime version should be applied. > >> I think we need ability to pass additional arguments to setFakeRuntime(String version) > > To suit the needs of a single test? Any chance we need a fake runtime with the "release" file in other tests? > >> In this case we will have `createInputRuntimeImage(RuntimeImageType role, String version)` > > Two major problems with this approach: > - Eventually, we will end up with `createInputRuntimeImage(RuntimeImageType role, String version, String fooProperty, boolean barProperty, Date dateProperty)` signature. Which will be unreadable, just like we had it at https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/jdk.jpackage/share/classes/jdk/jpackage/internal/IOUtils.java#L108 The calls will be equally unreadable to: https://github.com/openjdk/jdk/blob/6c48f4ed707bf0b15f9b6098de30db8aae6fa40f/src/jdk.jpackage/macosx/classes/jdk/jpackage/internal/MacDmgPackager.java#L330 > - When the external runtime is specified for the test with the "jdk.jpackage.runtime-image" system property, what to do with the "version" parameter? Agree. I reverted `setFakeRuntime(String version)` change in my PR and move this code under test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29205#discussion_r2699782734 From sparasa at openjdk.org Fri Jan 16 20:05:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:05:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v12] In-Reply-To: References: Message-ID: <5TOCDJo87eQTeAT-DRPgoAsEza_1fgaEApMW7OfObqQ=.263ac729-d5d8-4236-980d-d4613a8a7e84@github.com> > The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively. > > To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size. > > > ### **Performance comparison for byte array fills in a loop for 1 million times** > > > UseAVX=3 ByteArray Size | +OptimizeFill (Masked store stub) [secs] | -OptimizeFill (No stub) [secs] | --->This PR: +OptimizeFill (Unmasked store stub) [secs] > -- | -- | -- | -- > 1 | 0.46 | 0.14 | 0.189 > 2 | 0.46 | 0.16 | 0.191 > 3 | 0.46 | 0.176 | 0.199 > 4 | 0.46 | 0.244 | 0.212 > 5 | 0.46 | 0.29 | 0.364 > 10 | 0.46 | 0.58 | 0.354 > 15 | 0.46 | 0.42 | 0.325 > 16 | 0.46 | 0.46 | 0.281 > 17 | 0.21 | 0.5 | 0.365 > 20 | 0.21 | 0.37 | 0.326 > 25 | 0.21 | 0.59 | 0.343 > 31 | 0.21 | 0.53 | 0.317 > 32 | 0.21 | 0.58 | 0.249 > 35 | 0.5 | 0.77 | 0.303 > 40 | 0.5 | 0.61 | 0.312 > 45 | 0.5 | 0.52 | 0.364 > 48 | 0.5 | 0.66 | 0.283 > 49 | 0.22 | 0.69 | 0.367 > 50 | 0.22 | 0.78 | 0.344 > 55 | 0.22 | 0.67 | 0.332 > 60 | 0.22 | 0.67 | 0.312 > 64 | 0.22 | 0.82 | 0.253 > 70 | 0.51 | 1.1 | 0.394 > 80 | 0.49 | 0.89 | 0.346 > 90 | 0.225 | 0.68 | 0.385 > 100 | 0.54 | 1.09 | 0.364 > 110 | 0.6 | 0.98 | 0.416 > 120 | 0.26 | 0.75 | 0.367 > 128 | 0.266 | 1.1 | 0.342 Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Update the ArraysFill JMH benchmark ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28442/files - new: https://git.openjdk.org/jdk/pull/28442/files/1b401dcf..5edff7f7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=10-11 Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/28442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28442/head:pull/28442 PR: https://git.openjdk.org/jdk/pull/28442 From almatvee at openjdk.org Fri Jan 16 20:06:21 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 20:06:21 GMT Subject: RFR: 8375242: [macos] Improve jpackage signing coverage [v3] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 05:06:39 GMT, Alexey Semenyuk wrote: >> Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). >> >> Old test signatures: >> >> SigningAppImageTest.test(true, true, ASCII_INDEX) >> SigningAppImageTest.test(true, true, UNICODE_INDEX) >> SigningAppImageTest.test(true, false, UNICODE_INDEX) >> SigningAppImageTest.test(false, true, INVALID_INDEX) >> >> SigningAppImageTwoStepsTest.test(true, true) >> SigningAppImageTwoStepsTest.test(true, false) >> SigningAppImageTwoStepsTest.test(false, true) >> >> SigningPackageTest.test(true, true, true, ASCII_INDEX) >> SigningPackageTest.test(true, true, true, UNICODE_INDEX) >> SigningPackageTest.test(false, true, true, UNICODE_INDEX) >> SigningPackageTest.test(false, true, false, UNICODE_INDEX) >> SigningPackageTest.test(false, false, true, UNICODE_INDEX) >> >> SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) >> SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) >> SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) >> >> Si... > > Alexey Semenyuk has updated the pull request incrementally with two additional commits since the last revision: > > - Revert "SigningBase: move to the "base"" > > This reverts commit b50c717d83096b67ff530d90715d87fa0d9ade20. > - SigningBase: move to the "base" Looks good. ------------- Marked as reviewed by almatvee (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29205#pullrequestreview-3672513135 From asemenyuk at openjdk.org Fri Jan 16 20:07:30 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 20:07:30 GMT Subject: Integrated: 8375323: Improve handling of the "--app-content" and "--input" options in jpackage In-Reply-To: References: Message-ID: <8yM6LS4qGmKSKYsPzD1fi6q5gzk-Z1G3oWS8KjZuHI4=.fd3bf991-542c-49a9-995d-e8b4d6b19624@github.com> On Tue, 13 Jan 2026 15:11:37 GMT, Alexey Semenyuk wrote: > Change how the values of the "--app-content", "--input", and "--mac-dmg-content" options are handled. Traverse the input directories during the configuration phase, before jpackage creates any output, rather than during the packaging phase. > > This change required rework of the cli package to support converting values of any type to any type (`T -> T2`). Previously, it supported only String converters (`String -> T`). This pull request has now been integrated. Changeset: e7432d57 Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/e7432d574540109e2c4faca11cf49d9272a147e6 Stats: 1999 lines in 45 files changed: 1420 ins; 293 del; 286 mod 8375323: Improve handling of the "--app-content" and "--input" options in jpackage Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29194 From sparasa at openjdk.org Fri Jan 16 20:14:31 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:14:31 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: > The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively. > > To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size. > > > ### **Performance comparison for byte array fills in a loop for 1 million times** > > > UseAVX=3 ByteArray Size | +OptimizeFill (Masked store stub) [secs] | -OptimizeFill (No stub) [secs] | --->This PR: +OptimizeFill (Unmasked store stub) [secs] > -- | -- | -- | -- > 1 | 0.46 | 0.14 | 0.189 > 2 | 0.46 | 0.16 | 0.191 > 3 | 0.46 | 0.176 | 0.199 > 4 | 0.46 | 0.244 | 0.212 > 5 | 0.46 | 0.29 | 0.364 > 10 | 0.46 | 0.58 | 0.354 > 15 | 0.46 | 0.42 | 0.325 > 16 | 0.46 | 0.46 | 0.281 > 17 | 0.21 | 0.5 | 0.365 > 20 | 0.21 | 0.37 | 0.326 > 25 | 0.21 | 0.59 | 0.343 > 31 | 0.21 | 0.53 | 0.317 > 32 | 0.21 | 0.58 | 0.249 > 35 | 0.5 | 0.77 | 0.303 > 40 | 0.5 | 0.61 | 0.312 > 45 | 0.5 | 0.52 | 0.364 > 48 | 0.5 | 0.66 | 0.283 > 49 | 0.22 | 0.69 | 0.367 > 50 | 0.22 | 0.78 | 0.344 > 55 | 0.22 | 0.67 | 0.332 > 60 | 0.22 | 0.67 | 0.312 > 64 | 0.22 | 0.82 | 0.253 > 70 | 0.51 | 1.1 | 0.394 > 80 | 0.49 | 0.89 | 0.346 > 90 | 0.225 | 0.68 | 0.385 > 100 | 0.54 | 1.09 | 0.364 > 110 | 0.6 | 0.98 | 0.416 > 120 | 0.26 | 0.75 | 0.367 > 128 | 0.266 | 1.1 | 0.342 Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: Update ALL of ArraysFill JMH micro ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28442/files - new: https://git.openjdk.org/jdk/pull/28442/files/5edff7f7..620ae44e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28442&range=11-12 Stats: 8 lines in 1 file changed: 4 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28442/head:pull/28442 PR: https://git.openjdk.org/jdk/pull/28442 From sparasa at openjdk.org Fri Jan 16 20:26:42 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:26:42 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v11] In-Reply-To: References: <07NHyGU8bmzafUXXdLP3X81f7OZrqP6JcXZmtPh78J4=.5551605a-ade3-4190-9cf8-ae2a68857694@github.com> Message-ID: On Tue, 6 Jan 2026 08:47:56 GMT, Emanuel Peter wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> cleanup code related to labels > > And since this is a regression ... why not also plot the performance from before [JDK-8275047](https://bugs.openjdk.org/browse/JDK-8275047), so we have a more complete picture? Hi Emanuel (@eme64), Please see the updated data as you suggested. This PR (ArrayFill intrinsic with unmasked stores) only applies for: - Arrays of data type `byte`, `short` and `int` only - size <= 128 bytes for `MaxVectorSize=32` or `AVX3Threshold > 0` - size <=192 bytes for `MaxVectorSize=64` or `AVX3Threshold = 0` Thus, the performance data using your vector bulk operations JMH micro was obtained for sizes upto 200. Below are the plots for array fill with a variable value starting from a variable offset for `MaxVectorSize=32` @Benchmark @OperationsPerInvocation(REPETITIONS) public void fill_var_byte_arrays_fill() { for (int r = 0; r < REPETITIONS; r++) { int offset_store = offsetStore(r) + REGION_SIZE + REGION_2_BYTE_OFFSET; Arrays.fill(aB, offset_store, offset_store + NUM_ACCESS_ELEMENTS, varB); } } image image image [continued below with more data] ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3761659799 From sparasa at openjdk.org Fri Jan 16 20:34:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 16 Jan 2026 20:34:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively. >> >> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size. >> >> >> ### **Performance comparison for byte array fills in a loop for 1 million times** >> >> >> UseAVX=3 ByteArray Size | +OptimizeFill (Masked store stub) [secs] | -OptimizeFill (No stub) [secs] | --->This PR: +OptimizeFill (Unmasked store stub) [secs] >> -- | -- | -- | -- >> 1 | 0.46 | 0.14 | 0.189 >> 2 | 0.46 | 0.16 | 0.191 >> 3 | 0.46 | 0.176 | 0.199 >> 4 | 0.46 | 0.244 | 0.212 >> 5 | 0.46 | 0.29 | 0.364 >> 10 | 0.46 | 0.58 | 0.354 >> 15 | 0.46 | 0.42 | 0.325 >> 16 | 0.46 | 0.46 | 0.281 >> 17 | 0.21 | 0.5 | 0.365 >> 20 | 0.21 | 0.37 | 0.326 >> 25 | 0.21 | 0.59 | 0.343 >> 31 | 0.21 | 0.53 | 0.317 >> 32 | 0.21 | 0.58 | 0.249 >> 35 | 0.5 | 0.77 | 0.303 >> 40 | 0.5 | 0.61 | 0.312 >> 45 | 0.5 | 0.52 | 0.364 >> 48 | 0.5 | 0.66 | 0.283 >> 49 | 0.22 | 0.69 | 0.367 >> 50 | 0.22 | 0.78 | 0.344 >> 55 | 0.22 | 0.67 | 0.332 >> 60 | 0.22 | 0.67 | 0.312 >> 64 | 0.22 | 0.82 | 0.253 >> 70 | 0.51 | 1.1 | 0.394 >> 80 | 0.49 | 0.89 | 0.346 >> 90 | 0.225 | 0.68 | 0.385 >> 100 | 0.54 | 1.09 | 0.364 >> 110 | 0.6 | 0.98 | 0.416 >> 120 | 0.26 | 0.75 | 0.367 >> 128 | 0.266 | 1.1 | 0.342 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Update ALL of ArraysFill JMH micro Also, we can see the benefit of using unmasked stores (this PR) instead of masked vector stores (existing implementation) when we update the ArraysFill.java JMH micro-benchmark to perform fill (write) followed by read of the filled data as shown below using short array fill as an example: @Benchmark public short testShortFill() { Arrays.fill(testShortArray, (short) -1); return (short) (testShortArray[0] + testShortArray[size - 1]); } **(Higher is better)** Benchmark (ops/ms) MaxVectorSize = 32 | SIZE | +OptimizeFill (Masked Store) | +OptimizeFill (Unmasked Store - This PR) | Delta -- | -- | -- | -- | -- ArraysFill.testByteFill | 1 | 175381 | 342456 | 95% ArraysFill.testByteFill | 10 | 175421 | 264607 | 51% ArraysFill.testByteFill | 20 | 175447 | 271111 | 55% ArraysFill.testByteFill | 30 | 175454 | 253351 | 44% ArraysFill.testByteFill | 40 | 162429 | 273043 | 68% ArraysFill.testByteFill | 50 | 162443 | 251734 | 55% ArraysFill.testByteFill | 60 | 162454 | 248156 | 53% ArraysFill.testByteFill | 70 | 156659 | 236497 | 51% ArraysFill.testByteFill | 80 | 175403 | 269433 | 54% ArraysFill.testByteFill | 90 | 175422 | 230276 | 31% ArraysFill.testByteFill | 100 | 168662 | 252394 | 50% ArraysFill.testByteFill | 110 | 146182 | 217917 | 49% ArraysFill.testByteFill | 120 | 168693 | 239126 | 42% ArraysFill.testByteFill | 130 | 162378 | 166159 | 2% ArraysFill.testByteFill | 140 | 156569 | 168296 | 7% ArraysFill.testByteFill | 150 | 151214 | 167388 | 11% ArraysFill.testByteFill | 160 | 156594 | 173529 | 11% ArraysFill.testByteFill | 170 | 156590 | 167976 | 7% ArraysFill.testByteFill | 180 | 156561 | 173015 | 11% ArraysFill.testByteFill | 190 | 156601 | 173073 | 11% ArraysFill.testByteFill | 200 | 168277 | 174293 | 4% ArraysFill.testIntFill | 1 | 175403 | 334460 | 91% ArraysFill.testIntFill | 10 | 162437 | 273799 | 69% ArraysFill.testIntFill | 20 | 156636 | 273483 | 75% ArraysFill.testIntFill | 30 | 162440 | 243303 | 50% ArraysFill.testIntFill | 40 | 156592 | 175162 | 12% ArraysFill.testIntFill | 50 | 156585 | 168433 | 8% ArraysFill.testIntFill | 60 | 151193 | 195235 | 29% ArraysFill.testIntFill | 70 | 141406 | 167060 | 18% ArraysFill.testIntFill | 80 | 141406 | 167119 | 18% ArraysFill.testIntFill | 90 | 141437 | 166976 | 18% ArraysFill.testIntFill | 100 | 168349 | 173943 | 3% ArraysFill.testIntFill | 110 | 132864 | 173096 | 30% ArraysFill.testIntFill | 120 | 128972 | 173722 | 35% ArraysFill.testIntFill | 130 | 128958 | 149835 | 16% ArraysFill.testIntFill | 140 | 167934 | 165903 | -1% ArraysFill.testIntFill | 150 | 121799 | 133351 | 9% ArraysFill.testIntFill | 160 | 121824 | 154654 | 27% ArraysFill.testIntFill | 170 | 121800 | 163515 | 34% ArraysFill.testIntFill | 180 | 121770 | 150235 | 23% ArraysFill.testIntFill | 190 | 121808 | 145138 | 19% ArraysFill.testIntFill | 200 | 112433 | 142084 | 26% ArraysFill.testShortFill | 1 | 99696 | 309697 | 211% ArraysFill.testShortFill | 10 | 175433 | 290773 | 66% ArraysFill.testShortFill | 20 | 175417 | 270345 | 54% ArraysFill.testShortFill | 30 | 162459 | 257180 | 58% ArraysFill.testShortFill | 40 | 175438 | 273348 | 56% ArraysFill.testShortFill | 50 | 162445 | 272307 | 68% ArraysFill.testShortFill | 60 | 168669 | 241798 | 43% ArraysFill.testShortFill | 70 | 156509 | 174347 | 11% ArraysFill.testShortFill | 80 | 151207 | 168424 | 11% ArraysFill.testShortFill | 90 | 162332 | 197780 | 22% ArraysFill.testShortFill | 100 | 156583 | 174738 | 12% ArraysFill.testShortFill | 110 | 151147 | 175170 | 16% ArraysFill.testShortFill | 120 | 167078 | 191352 | 15% ArraysFill.testShortFill | 130 | 146102 | 171682 | 18% ArraysFill.testShortFill | 140 | 151206 | 203786 | 35% ArraysFill.testShortFill | 150 | 146133 | 167027 | 14% ArraysFill.testShortFill | 160 | 141426 | 167047 | 18% ArraysFill.testShortFill | 170 | 136974 | 167049 | 22% ArraysFill.testShortFill | 180 | 141420 | 173568 | 23% ArraysFill.testShortFill | 190 | 136164 | 172806 | 27% ArraysFill.testShortFill | 200 | 141464 | 167048 | 18% ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3761712841 From almatvee at openjdk.org Fri Jan 16 22:45:36 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Fri, 16 Jan 2026 22:45:36 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> Message-ID: On Fri, 16 Jan 2026 05:16:19 GMT, Alexey Semenyuk wrote: > > Do we want to normalize module version? > > When jpackage derives bundle properties from the input data, it should get the valid values. If it can't do it, it should fail. > > > What possible format for module version? > > No idea. How is it relevant? If jpackage can't get a valid platform-specific bundle version from the module version, it should fail. Why we need to normalize version then? > > > Having generic normalization for both module, release file or anything else is probably over complicated. > > It is the opposite: applying the same normalization function to any input is simple. If it can't produce a valid output, stop further processing if there are no other options. > > Besides a command line, jpackage can derive the app version from the main jar, module, and now from the runtime. > > Do you suggest handling these cases differently? Yes. Lets add corresponding classes to read versions: `RuntimeVersionReader`, `JarVersionReader`, `ModuleVersionReader`. All these classes will return version in following format: N.N.... These classes will be responsible to convert version if needed. For example jar can have: `1.2.3-SNAPSHOT`. In this case `JarVersionReader` will return `1.2.3` and `WinFromOptions` will normalize it to `1.2.3.0`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3762093253 From asemenyuk at openjdk.org Fri Jan 16 23:21:21 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 23:21:21 GMT Subject: Integrated: 8375242: [macos] Improve jpackage signing coverage In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:23:00 GMT, Alexey Semenyuk wrote: > Refactor signing tests covering gaps listed in the [CR description](https://bugs.openjdk.org/browse/JDK-8375242). > > Old test signatures: > > SigningAppImageTest.test(true, true, ASCII_INDEX) > SigningAppImageTest.test(true, true, UNICODE_INDEX) > SigningAppImageTest.test(true, false, UNICODE_INDEX) > SigningAppImageTest.test(false, true, INVALID_INDEX) > > SigningAppImageTwoStepsTest.test(true, true) > SigningAppImageTwoStepsTest.test(true, false) > SigningAppImageTwoStepsTest.test(false, true) > > SigningPackageTest.test(true, true, true, ASCII_INDEX) > SigningPackageTest.test(true, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, true, UNICODE_INDEX) > SigningPackageTest.test(false, true, false, UNICODE_INDEX) > SigningPackageTest.test(false, false, true, UNICODE_INDEX) > > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-signing-key-user-name: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}; {MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test({MAC_DMG={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}, MAC_PKG={--mac-installer-sign-identity: CertificateRequest[name=Developer ID Installer: jpackage.openjdk.java.net, ...]}}) > SigningPackageTwoStepTest.test(app-image={--mac-app-image-sign-identity: CertificateRequest[name=Developer ID Application: jpackage.openjdk.java.net, ...]}) > > SigningRuntimeImagePackageTest.test(true, INVALID_INDEX,... This pull request has now been integrated. Changeset: 9b47c23b Author: Alexey Semenyuk URL: https://git.openjdk.org/jdk/commit/9b47c23b4b809f7070c6c8279b7ffdf83234dcdb Stats: 1943 lines in 13 files changed: 974 ins; 550 del; 419 mod 8375242: [macos] Improve jpackage signing coverage Reviewed-by: almatvee ------------- PR: https://git.openjdk.org/jdk/pull/29205 From vlivanov at openjdk.org Fri Jan 16 23:24:20 2026 From: vlivanov at openjdk.org (Vladimir Ivanov) Date: Fri, 16 Jan 2026 23:24:20 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 ... Currently, I'm in process of conducting performance testing. I plan to finish it in a week and post for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28675#issuecomment-3762195958 From asemenyuk at openjdk.org Fri Jan 16 23:34:44 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Fri, 16 Jan 2026 23:34:44 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> Message-ID: On Fri, 16 Jan 2026 22:42:10 GMT, Alexander Matveev wrote: > Why we need to normalize version then? Same reason why we do this for the app version in the "release" file. Why would it be different? > For example jar can have: 1.2.3-SNAPSHOT. In this case JarVersionReader will return 1.2.3 - What would `RuntimeVersionReader` and `ModuleVersionReader` return for this input? - Why would the `JarVersionReader` strip the "-SNAPSHOT" prefix? On Linux, there are no restrictions similar to those of macOS and Windows for version string. "1.2.3-SNAPSHOT" is a valid rpm/deb version. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3762212499 From almatvee at openjdk.org Sat Jan 17 03:26:08 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 17 Jan 2026 03:26:08 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] In-Reply-To: References: Message-ID: > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29260/files - new: https://git.openjdk.org/jdk/pull/29260/files/6cd84550..6da59917 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=02-03 Stats: 473 lines in 14 files changed: 277 ins; 105 del; 91 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From almatvee at openjdk.org Sat Jan 17 03:29:13 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 17 Jan 2026 03:29:13 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] In-Reply-To: References: Message-ID: > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: - merge with upstream - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified ------------- Changes: https://git.openjdk.org/jdk/pull/29260/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=04 Stats: 496 lines in 15 files changed: 450 ins; 12 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From almatvee at openjdk.org Sat Jan 17 03:35:09 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 17 Jan 2026 03:35:09 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] In-Reply-To: References: Message-ID: <10WmDMV5zOyloNaTTYNmfFlNfQbDect207bFK-YF-so=.c9a55863-35af-4ded-bbcf-ace0ccf06069@github.com> On Sat, 17 Jan 2026 03:29:13 GMT, Alexander Matveev wrote: >> - Version will be read from JDK's release file if not provided via `--version` for runtime installer. >> - Added test to cover added functionality. >> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - merge with upstream > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] - Fixed all review comments. - Version normalization is still enabled only for runtime installer as in v4. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3762587066 From almatvee at openjdk.org Sat Jan 17 03:45:33 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sat, 17 Jan 2026 03:45:33 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] In-Reply-To: References: <65-vesKkIYx0SNRu8unBbdXbakmWRlC4FgWvkN0egeI=.4e776974-21e4-469f-a0e4-ae4062fc4f91@github.com> <_qmL32fqzbpdynfJqlCu3_CRSfQ5LeuqJOazZgAx6c0=.5ace6aa0-9145-496a-828a-d0e63fd65fe7@github.com> Message-ID: On Fri, 16 Jan 2026 23:31:01 GMT, Alexey Semenyuk wrote: > > Why we need to normalize version then? > > Same reason why we do this for the app version in the "release" file. Why would it be different? > > > For example jar can have: 1.2.3-SNAPSHOT. In this case JarVersionReader will return 1.2.3 > > * What would `RuntimeVersionReader` and `ModuleVersionReader` return for this input? > * Why would the `JarVersionReader` strip the "-SNAPSHOT" prefix? On Linux, there are no restrictions similar to those of macOS and Windows for version string. "1.2.3-SNAPSHOT" is a valid rpm/deb version. On macOS when generating runtime installer DMG package version is only used in file name. For example `TestJDK-27.0.0.dmg`. Which makes `1.2.3-SNAPSHOT` valid version for macOS runtime installer DMG case. I think we need follow up bug to figure out all possible combinations on how version is being used and normalized it for specific cases. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3762596166 From duke at openjdk.org Sat Jan 17 06:24:47 2026 From: duke at openjdk.org (Ruben) Date: Sat, 17 Jan 2026 06:24:47 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Wed, 14 Jan 2026 08:59:14 GMT, Andrew Haley wrote: > It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. > Why not use MOVN, and put the data into a stub at the end of the nmethod? If the data is stored in the stub code, the method size depends on whether `cb_offset`/`oopmap_index` fit in the respective post-call NOP - if I understand correctly, that would require calculating values of `cb_offset`/`oopmap_index` during the code generation because stub code size should be known prior to allocation in the code cache. It can't be postponed until `NativePostCallNop::patch`. Avoiding the estimation step would simplify the change. Also, referencing the stub code via MOVN - which can be used to store up to 18 bits of metadata - would limit the method size by approximately 1MB (`4 * (1 << 18)`). It might be a reasonable limit for a compiled method, however as far as I understand, right now the limit is `branch_range` (128MB). Would the 1MB limit be acceptable? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3762774275 From jbhateja at openjdk.org Sat Jan 17 11:42:32 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sat, 17 Jan 2026 11:42:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <8Z84JAkAC6yVFA_1j82FXuoqn1Gu5qQLBlgbcVDAuLQ=.ec5f98c0-42de-4395-a46e-bb2b0be3c12a@github.com> Message-ID: On Fri, 19 Dec 2025 22:48:50 GMT, Paul Sandoz wrote: >> 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! Hi @PaulSandoz , your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3763199964 From dgredler at openjdk.org Sat Jan 17 13:39:11 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Sat, 17 Jan 2026 13:39:11 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 16:24:44 GMT, Alan Bateman wrote: > I think it would be useful some static analysis to get a sense for how many libraries extend BAOS and have their own ensureCapacity method. I ran [this script](https://gist.github.com/gredler/001089395b81bfe72ab3362d6f622096) on my local Gradle JAR cache of ~1.1k JARs, and it found about 50 classes with `ensureCapacity` methods, but none of them extend BAOS (they were mostly collections). So no issues detected using this approach. It would be good if others could check their own Gradle or Maven caches locally. A broader text-based [GitHub search](https://github.com/search?q=%22extends+ByteArrayOutputStream%22+%22private+void+ensureCapacity%28int%22&type=code&p=1) turns up about 30 distinct instances of BAOS subclasses with a conflicting private `ensureCapacity` method. Some of these are copies of `sun.security.ssl.OutputRecord`, which included a private `ensureCapacity` method in earlier versions of the JDK. The ones which stood out to me were: - Apache Dubbo (`org.apache.dubbo.remoting.http12.LimitedByteArrayOutputStream`) - Apache AsterixDB (`org.apache.hyracks.data.std.util.ByteArrayAccessibleOutputStream`) - Apache TsFile (`org.apache.tsfile.utils.PublicBAOS`) - MuleSoft APIKit Rest (`org.mule.module.apikit.validation.body.form.transformation.LimitedByteArrayOutputStream`) - Microsphere (`io.microsphere.io.FastByteArrayOutputStream`) - Subclipse (`org.tigris.subversion.subclipse.core.resources.ResourceStatus.StatusToBytesStream`) ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3763739173 From vklang at openjdk.org Sat Jan 17 16:14:11 2026 From: vklang at openjdk.org (Viktor Klang) Date: Sat, 17 Jan 2026 16:14:11 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:07:34 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. >> >> The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. >> >> The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > add comment in test src/java.base/share/classes/java/lang/VirtualThread.java line 641: > 639: synchronized (timedWaitLock()) { > 640: byte seqNo = ++timedWaitSeqNo; > 641: timeoutTask = schedule(() -> waitTimeoutExpired(seqNo), timeout, MILLISECONDS); Just a sidenote, I think it would be nice to see if we could eliminate the need for the seqNo if we were able to allocate the timeoutTask before submitting it, then using getAndSet or compareAndExchange to install it in the timeoutTask-field, and on cancellation we can CAS out it to null and only if we succeed we have successfully uninstalled it and can cancel it. Not high priority, but I find it valuable to always have an idea of how to do it differently. This might also make it possible to avoid having to use the timedWaitLock. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701250823 From dgredler at openjdk.org Sat Jan 17 17:17:23 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Sat, 17 Jan 2026 17:17:23 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected [v2] In-Reply-To: References: Message-ID: <4k7wQhKkZ8p2POnpzJXTg9dKbPcmeC70ZGLE6IRF1u0=.f47e986b-fa83-4cbf-b3da-221e70701ea7@github.com> > ByteArrayOutputStream.ensureCapacity(int) is currently private. It would be useful if it were protected, so that it can be more easily extended by subclasses. > > Mailing list discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/156983.html Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: Update per latest feedback ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29180/files - new: https://git.openjdk.org/jdk/pull/29180/files/ecd31f59..dee9d96a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29180&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29180&range=00-01 Stats: 66 lines in 2 files changed: 42 ins; 17 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29180.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29180/head:pull/29180 PR: https://git.openjdk.org/jdk/pull/29180 From dgredler at openjdk.org Sat Jan 17 17:24:16 2026 From: dgredler at openjdk.org (Daniel Gredler) Date: Sat, 17 Jan 2026 17:24:16 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected [v2] In-Reply-To: <4k7wQhKkZ8p2POnpzJXTg9dKbPcmeC70ZGLE6IRF1u0=.f47e986b-fa83-4cbf-b3da-221e70701ea7@github.com> References: <4k7wQhKkZ8p2POnpzJXTg9dKbPcmeC70ZGLE6IRF1u0=.f47e986b-fa83-4cbf-b3da-221e70701ea7@github.com> Message-ID: On Sat, 17 Jan 2026 17:17:23 GMT, Daniel Gredler wrote: >> ByteArrayOutputStream.ensureCapacity(int) is currently private. It would be useful if it were protected, so that it can be more easily extended by subclasses. >> >> Mailing list discussion: https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/156983.html > > Daniel Gredler has updated the pull request incrementally with one additional commit since the last revision: > > Update per latest feedback Thanks for the feedback, I've pushed a revision which I think addresses most of it. The two existing write methods will now call subclass-provided `ensureCapacity` methods. The test verifies this behavior. I've added some subclassing advice to the class-level JavaDoc, let me know if it meets the needs. I've added a "since" tag to the JavaDoc for the existing (promoted) method, because this will be the first time that it is visible to users. The handling of non-positive input does not change, subclasses are trusted to validate input before calling `ensureCapacity` or face the consequences (possible OOME). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3764123759 From alanb at openjdk.org Sat Jan 17 19:53:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 19:53:31 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 16:11:35 GMT, Viktor Klang wrote: >> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: >> >> add comment in test > > src/java.base/share/classes/java/lang/VirtualThread.java line 641: > >> 639: synchronized (timedWaitLock()) { >> 640: byte seqNo = ++timedWaitSeqNo; >> 641: timeoutTask = schedule(() -> waitTimeoutExpired(seqNo), timeout, MILLISECONDS); > > Just a sidenote, I think it would be nice to see if we could eliminate the need for the seqNo if we were able to allocate the timeoutTask before submitting it, then using getAndSet or compareAndExchange to install it in the timeoutTask-field, and on cancellation we can CAS out it to null and only if we succeed we have successfully uninstalled it and can cancel it. Not high priority, but I find it valuable to always have an idea of how to do it differently. This might also make it possible to avoid having to use the timedWaitLock. The seqNo is because the timeout task executes asynchronously, and can be executing when cancelled. It reduces the potential for interference and spurious wakeups when there is tight sequence of waits. There may be better designs, we went through when the changes were baking in the loom repo. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701418098 From alanb at openjdk.org Sat Jan 17 19:53:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 19:53:31 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v2] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:09:21 GMT, Patricio Chilano Mateo wrote: >> test/jdk/java/lang/Thread/virtual/stress/NotifiedThenTimedOutWait.java line 77: >> >>> 75: } >>> 76: }); >>> 77: var pthread = Thread.ofPlatform().start(() -> { >> >> A future maintainer may wonder why the notify is done in a platform thread in race1, and a virtual thread in race2. We should probably add a comment. > > Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? Good idea, could be TLR or just different runs of test but the effective would be adding more timing scenarios to the testing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2701419978 From alanb at openjdk.org Sat Jan 17 20:11:04 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 17 Jan 2026 20:11:04 GMT Subject: RFR: 8374610: Make ByteArrayOutputStream.ensureCapacity(int) protected [v2] In-Reply-To: References: <4k7wQhKkZ8p2POnpzJXTg9dKbPcmeC70ZGLE6IRF1u0=.f47e986b-fa83-4cbf-b3da-221e70701ea7@github.com> Message-ID: On Sat, 17 Jan 2026 17:19:58 GMT, Daniel Gredler wrote: > Thanks for the feedback, I've pushed a revision which I think addresses most of it. BAOS dates from JDK 1.0 and we have to assume that there are subclasses doing wild things. We can't assume that subclasses use buf + count, they might accumulate in the bytes off-heap or under the couch. So I think it will require working through the compatibility issues to see if it make sense to re-specify the existing methods or not. Separately, Jai ran a corpus analysis to get more data on BAOS subclasses with an "ensureCapacity" method. Some of these are non-public so would run into both a source and binary compatibility issue with the current proposal. More analysis is required but it may be that any proposal here will need to use a different name. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29180#issuecomment-3764283343 From jaikiran.pai at oracle.com Sun Jan 18 01:55:10 2026 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Sun, 18 Jan 2026 07:25:10 +0530 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: Message-ID: <7686a8af-8b66-4714-9529-12bf5cf2472d@oracle.com> Hello Eirik, On 16/01/26 11:56 pm, Eirik Bj?rsn?s wrote: > Hi, > > java.lang.Shutdown uses a static nested Lock class for > synchronization. This seems trivially replaceable?with new Object() > which would reduce class loading during shutdown. > Replacing the custom private class with Object instance looks OK to me. I had a look at the history of that code and it appears that it has been that way ever since Shutdown code was introduced, so doesn't look like that private class was introduced for any specific bug fix. While at it, you might also want to mark both the lock fields final. > java.lang.ref.ReferenceQueue uses a similar idiom and could > potentially be cleaned up as well. Looks OK to replace there too. -Jaikiran From jaikiran.pai at oracle.com Sun Jan 18 01:55:10 2026 From: jaikiran.pai at oracle.com (Jaikiran Pai) Date: Sun, 18 Jan 2026 07:25:10 +0530 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: Message-ID: <7686a8af-8b66-4714-9529-12bf5cf2472d@oracle.com> Hello Eirik, On 16/01/26 11:56 pm, Eirik Bj?rsn?s wrote: > Hi, > > java.lang.Shutdown uses a static nested Lock class for > synchronization. This seems trivially replaceable?with new Object() > which would reduce class loading during shutdown. > Replacing the custom private class with Object instance looks OK to me. I had a look at the history of that code and it appears that it has been that way ever since Shutdown code was introduced, so doesn't look like that private class was introduced for any specific bug fix. While at it, you might also want to mark both the lock fields final. > java.lang.ref.ReferenceQueue uses a similar idiom and could > potentially be cleaned up as well. Looks OK to replace there too. -Jaikiran From vklang at openjdk.org Sun Jan 18 02:43:42 2026 From: vklang at openjdk.org (Viktor Klang) Date: Sun, 18 Jan 2026 02:43:42 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 14 Jan 2026 12:41:50 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: > > Another set of contend vs deactivate vs park tradeoffs src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1980: > 1978: signalWork(q, nb); > 1979: rescans = 1; > 1980: if (taken++ == 0 || src != qid) or `++taken == 1` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702013524 From almatvee at openjdk.org Sun Jan 18 05:17:40 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sun, 18 Jan 2026 05:17:40 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6] In-Reply-To: References: Message-ID: > - Version will be read from JDK's release file if not provided via `--version` for runtime installer. > - Added test to cover added functionality. > - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. Alexander Matveev has updated the pull request incrementally with one additional commit since the last revision: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6] ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29260/files - new: https://git.openjdk.org/jdk/pull/29260/files/81c97565..06bbad82 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29260&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29260.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29260/head:pull/29260 PR: https://git.openjdk.org/jdk/pull/29260 From almatvee at openjdk.org Sun Jan 18 05:17:42 2026 From: almatvee at openjdk.org (Alexander Matveev) Date: Sun, 18 Jan 2026 05:17:42 GMT Subject: RFR: 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] In-Reply-To: References: Message-ID: <_ba5agaOGo7acY3eMQ1J_J33Tuc5-nI0FC_i1ETnhNM=.78be092d-f39a-4d6a-9e51-8b1a37595629@github.com> On Sat, 17 Jan 2026 03:29:13 GMT, Alexander Matveev wrote: >> - Version will be read from JDK's release file if not provided via `--version` for runtime installer. >> - Added test to cover added functionality. >> - On macOS and Windows version from JDK's release file will be normalized if it does not fit platform requirements. > > Alexander Matveev has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits: > > - merge with upstream > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v5] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v4] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v3] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v2] > - 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified 8357404: jpackage should attempt to get a package version from the JDK's release file if the --version option is not specified [v6] - Fixed build issue after merge. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29260#issuecomment-3764922856 From liach at openjdk.org Sun Jan 18 07:32:17 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 07:32:17 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:36:33 GMT, Hannes Greule wrote: > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29174#pullrequestreview-3675298028 From liach at openjdk.org Sun Jan 18 08:16:30 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 08:16:30 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Fri, 16 Jan 2026 09:46:54 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to @apiNote Question: Have you considered the handling of replacement characters? They currently are counted into the returned length, but I wonder whether users actually want to print those characters as-is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3765042910 From liach at openjdk.org Sun Jan 18 08:38:34 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 08:38:34 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:05:43 GMT, Jan Lahoda wrote: > The `SwitchBootstraps.enumSwitch` is documented to throw a `NullPointerException` when `lookup` is `null`, but it does not throw the exception in all cases. > > Given the `lookup` is in some cases required, the proposal herein is to properly check `lookup` is not `null`. And while doing that, I added similar checks for `invocationType` and `labels` - those were checked implicitly, but doing the check explicitly is better. Note `invocationName` is unused and is permitted to be `null`, and hence there's no check for it. > > Please also review the CSR: > https://bugs.openjdk.org/browse/JDK-8375120 Ok, though ideally tests should use dedicated throws detection tools ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29202#pullrequestreview-3675325350 From liach at openjdk.org Sun Jan 18 08:38:34 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 08:38:34 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: <9Pqwk4JvBNxjlf3vozinYLbgKvT1IuZxSfV1-D1sGtY=.fd3fbfa3-4b42-43a2-9ec8-2adcf62c4229@github.com> References: <9Pqwk4JvBNxjlf3vozinYLbgKvT1IuZxSfV1-D1sGtY=.fd3fbfa3-4b42-43a2-9ec8-2adcf62c4229@github.com> Message-ID: On Wed, 14 Jan 2026 13:38:45 GMT, Jan Lahoda wrote: > The method documents that it can throw multiple exceptions but there is no guaranteed order of argument checking. @jdlib The JDK by convention may throw any of the permitted exceptions if multiple exceptions apply. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29202#issuecomment-3765059382 From alanb at openjdk.org Sun Jan 18 09:09:52 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 18 Jan 2026 09:09:52 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Sun, 18 Jan 2026 08:13:40 GMT, Chen Liang wrote: > Question: Have you considered the handling of replacement characters? They currently are counted into the returned length, but I wonder whether users actually want to print those characters as-is. That is a good point. As `getBytes(Charset)` is specified to replace malformed-input and unmappable-character sequences, and the proposed method is specified to return the equivalent of `getBytes(Charset).length` then the returned length has to include them. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3765082490 From liach at openjdk.org Sun Jan 18 09:22:50 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 18 Jan 2026 09:22:50 GMT Subject: [jdk26] RFR: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:25:33 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [821e9ff9](https://github.com/openjdk/jdk/commit/821e9ff965cad52cdd26c08785312db49bcce539) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jorn Vernee on 19 Dec 2025 and was reviewed by Chen Liang. > Thanks! > > We are currently in RDP1 (https://openjdk.org/projects/jdk/26/), and this issue is a test bug (noreg-self), so it is allowed without approval. Should be still eligible in RDP 2. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29031#pullrequestreview-3675348815 From dl at openjdk.org Sun Jan 18 18:52:53 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 18 Jan 2026 18:52:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v26] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Thu, 15 Jan 2026 12:39:43 GMT, Viktor Klang wrote: >> Doug Lea has updated the pull request incrementally with one additional commit since the last revision: >> >> Another set of contend vs deactivate vs park tradeoffs > > src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1861: > >> 1859: break; >> 1860: } >> 1861: } > > The following might be a potential alternative encoding of signalWork?it would be interesting to hear if it makes any difference on your testing array, Doug: > > > final void signalWork(WorkQueue src, int base) { > int pc = parallelism, i, sp; // rely on caller sync for initial reads > long c = U.getLong(this, CTL); > WorkQueue[] qs; > while ((short)(c >>> RC_SHIFT) < pc && (qs = queues) != null && > qs.length > (i = (sp = (int)c) & SMASK) && (src == null || src.base - base < 1)) { > if (i == 0) { > if ((short)(c >>> TC_SHIFT) >= pc) > break; > if (c == (c = U.compareAndExchangeLong(this, CTL, c, ((c + TC_UNIT) & TC_MASK) | ((c + RC_UNIT) & RC_MASK)))) { > createWorker(); > break; > } > } > else { > WorkQueue v; > if ((v = qs[i]) == null) > break; > if (c == (c = U.compareAndExchangeLong(this, CTL, c, (v.stackPred & LMASK) | ((c + RC_UNIT) & UMASK)))) { > v.phase = sp; > if (v.parking != 0) > U.unpark(v.owner); > break; > } > } > } > } Thanks for prodding me to instrument current version. I saw that retries are no longer very common -- max seen across various contention-prone tests was 17, but in most never more than 4 except more during warmup before code is compiled. Versions that did filter check before CAS systematically have more retries though. And as I noticed in some previous versions, separating the branches with different CAes invites the compiler to rearrange code in a worse way to only have one CAS. at least in the surprisingly common case where it inlines signalWork in callers. So net change from all this so far was a couple of cosmetic tweaks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702638385 From dl at openjdk.org Sun Jan 18 21:07:48 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 18 Jan 2026 21:07:48 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] 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: Simplify scan mode control by moving and reworking topLevelExec and throwing on trim ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/88f1466d..a1e5ce94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=25-26 Stats: 192 lines in 1 file changed: 57 ins; 60 del; 75 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 david.holmes at oracle.com Sun Jan 18 22:02:58 2026 From: david.holmes at oracle.com (David Holmes) Date: Mon, 19 Jan 2026 08:02:58 +1000 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: Message-ID: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> On 17/01/2026 4:26 am, Eirik Bj?rsn?s wrote: > Hi, > > java.lang.Shutdown uses a static nested Lock class for synchronization. > This seems trivially replaceable?with new Object() which would reduce > class loading during shutdown. > > java.lang.ref.ReferenceQueue uses a similar idiom and could potentially > be cleaned up as well. > > I'd be happy to contribute a PR for this cleanup. Worth pursuing? Thoughts? You would lose potentially important information when reporting monitors owned by a thread. Also I think Valhalla is trying to dissuade/move-away-from using "new Object()". Cheers, David > Cheers, > Eirik. From vklang at openjdk.org Mon Jan 19 00:38:03 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 00:38:03 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1950: > 1948: if (q.array == a && q.base == b && > 1949: U.getReference(a, bp) == t) { > 1950: if (t == null) { @DougLea Does it make any difference if we only confirm `t` in case of null, and if that now shows anything different, we can use that for the later CAS? if (q.array == a && q.base == b) { if (t == null && (t = (ForkJoinTask)U.getReference(a, bp)) == null) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702907317 From vklang at openjdk.org Mon Jan 19 00:56:17 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 00:56:17 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <5mwYGdYx8wOlZxdwbtHOiw9Z_cyOnPcnnFHjzYdTnl8=.0d4d84ac-be1e-41c8-b5c1-06360c46efc6@github.com> On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2008: > 2006: a, bp = slotOffset((cap - 1) & (b = q.base))); > 2007: Object nt = U.getReference( > 2008: a, np = slotOffset((cap - 1) & (nb = b + 1))); @DougLea `nt` isn't used until it is overwritten by `nt = U.getReference(a, np);` I presume this is not intentional? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702922891 From vklang at openjdk.org Mon Jan 19 01:01:29 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 01:01:29 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1175: > 1173: */ > 1174: @SuppressWarnings("serial") > 1175: static final class WorkerTrimmedException extends RuntimeException { } I presume that the intent is not to have this surface outside of FJP?might make sense to create a cached instance to make it less risky to throw (cheaper to construct + no risk of it triggering OOME under heavy load scenarios?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702927621 From vklang at openjdk.org Mon Jan 19 01:13:57 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 01:13:57 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2059: > 2057: if (idle != 0 && (runState & STOP) == 0L) { > 2058: int noise = (phase ^ (phase >>> 16)) & (SPIN_WAITS - 1); > 2059: int spins = (SPIN_WAITS << 1) | noise; @DougLea Haha, it's a funny coincidence, because just last night I was thinking we should try a randomized backoff, and now I saw this. :) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2702938962 From pminborg at openjdk.org Mon Jan 19 07:48:16 2026 From: pminborg at openjdk.org (Per Minborg) Date: Mon, 19 Jan 2026 07:48:16 GMT Subject: Integrated: 8374717: Unclear wording in docs for recursion for List, Map and LazyConstant In-Reply-To: <-cqudLsu7pgmEjbxAxz3vM9k7fayqCeEZJrcgstOf34=.9cae792d-b902-4582-9b64-7b02c2cd9792@github.com> References: <-cqudLsu7pgmEjbxAxz3vM9k7fayqCeEZJrcgstOf34=.9cae792d-b902-4582-9b64-7b02c2cd9792@github.com> Message-ID: On Wed, 7 Jan 2026 13:20:20 GMT, Per Minborg wrote: > The factory methods `(List|Map)::ofLazy` and `LazyConstant::get` specify that an `IllegalStateException` is thrown upon a recursive invocation of the computing function. However, it is not clear that this *only* applies if recursion is made through the lazy entity (and not direct recursion on the computing function itself). > > This PR proposes to improve the wording in the docs for lazy constructs. This is a doc-only change. > > For example, we could replace the word "or" with the word "via" in the `List::ofLazy` specification so that it says: > > * If the provided computing function recursively calls itself via the returned > * lazy list for the same index, an {@linkplain IllegalStateException} > * will be thrown. This pull request has now been integrated. Changeset: 75172e06 Author: Per Minborg URL: https://git.openjdk.org/jdk/commit/75172e06585060e5efca080a11d8a8a51b40afed Stats: 8 lines in 3 files changed: 0 ins; 1 del; 7 mod 8374717: Unclear wording in docs for recursion for List, Map and LazyConstant Reviewed-by: rriggs ------------- PR: https://git.openjdk.org/jdk/pull/29091 From epeter at openjdk.org Mon Jan 19 08:14:41 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 08:14:41 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Fri, 16 Jan 2026 20:31:28 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > Also, we can see the benefit of using unmasked stores (this PR) instead of masked vector stores (existing implementation) when we update the ArraysFill.java JMH micro-benchmark to perform fill (write) followed by read of the filled data as shown below using short array fill as an example: > > > @Benchmark > public short testShortFill() { > Arrays.fill(testShortArray, (short) -1); > return (short) (testShortArray[0] + testShortArray[size - 1]); > } > > > > > > ### Table shows throughput (ops/ms); **(Higher is better)** > Benchmark (ops/ms) MaxVectorSize = 32 | SIZE | +OptimizeFill (Masked Store) | +OptimizeFill (Unmasked Store - This PR) | Delta > -- | -- | -- | -- | -- > ArraysFill.testByteFill | 1 | 175381 | 342456 | 95% > ArraysFill.testByteFill | 10 | 175421 | 264607 | 51% > ArraysFill.testByteFill | 20 | 175447 | 271111 | 55% > ArraysFill.testByteFill | 30 | 175454 | 253351 | 44% > ArraysFill.testByteFill | 40 | 162429 | 273043 | 68% > ArraysFill.testByteFill | 50 | 162443 | 251734 | 55% > ArraysFill.testByteFill | 60 | 162454 | 248156 | 53% > ArraysFill.testByteFill | 70 | 156659 | 236497 | 51% > ArraysFill.testByteFill | 80 | 175403 | 269433 | 54% > ArraysFill.testByteFill | 90 | 175422 | 230276 | 31% > ArraysFill.testByteFill | 100 | 168662 | 252394 | 50% > ArraysFill.testByteFill | 110 | 146182 | 217917 | 49% > ArraysFill.testByteFill | 120 | 168693 | 239126 | 42% > ArraysFill.testByteFill | 130 | 162378 | 166159 | 2% > ArraysFill.testByteFill | 140 | 156569 | 168296 | 7% > ArraysFill.testByteFill | 150 | 151214 | 167388 | 11% > ArraysFill.testByteFill | 160 | 156594 | 173529 | 11% > ArraysFill.testByteFill | 170 | 156590 | 167976 | 7% > ArraysFill.testByteFill | 180 | 156561 | 173015 | 11% > ArraysFill.testByteFill | 190 | 156601 | 173073 | 11% > ArraysFill.testByteFill | 200 | 168277 | 174293 | 4% > ArraysFill.testIntFill | 1 | 175403 | 334460 | 91% > ArraysFill.testIntFill | 10 | 162437 | 273799 | 69% > ArraysFill.testIntFill | 20 | 156636 | 273483 | 75% > ArraysFill.testIntFill | 30 | 162440 | 243303 | 50% > ArraysFill.testIntFill | 40 | 156592 | 175162 | 12% > ArraysFill.testIntFill | 50 | 156585 | 168433 | 8% > ArraysFill.testIntFill | 60 | 151193 | 195235 | 29% > ArraysFill.testIntFill | 70 | 141406 | 167060 | 18% > ArraysFill.testIntFill | 80 | 141406 | 167119 | 18% > ArraysFill.testIntFill | 90 | 141437 | 166976 | 18% > ArraysFill.testIntFill | 100 | 168349 | 173943 | 3% > ArraysFill.testIntFill | 110 | 132864 | 173096 | 30% > ArraysFill.testIntFill | 120 | 128972 | 173722 | 35% > ArraysFill.... @vamsi-parasa Thanks for the extra data! Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. Can you explain the difference between the two results? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3767004043 From cushon at openjdk.org Mon Jan 19 08:16:17 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 08:16:17 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Sun, 18 Jan 2026 09:06:31 GMT, Alan Bateman wrote: > > Question: Have you considered the handling of replacement characters? They currently are counted into the returned length, but I wonder whether users actually want to print those characters as-is. > > That is a good point. As `getBytes(Charset)` is specified to replace malformed-input and unmappable-character sequences, and the proposed method is specified to return the equivalent of `getBytes(Charset).length` then the returned length has to include them. The motivating use cases I've seen for this method are to compute the length of encoded data that contains strings, where the strings would be encoded with `getBytes`. The CSR gives the example of encoding multiple large strings into a single array. Specifying the output in terms of `getBytes(cs).length` is necessary for that use-case, and requires the handling of replacement characters and unpaired surrogates to be the same between the two methods. Do you see alternatives that should be considered? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3767013988 From jlahoda at openjdk.org Mon Jan 19 08:52:12 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 19 Jan 2026 08:52:12 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: <-5rYe8rSZ7aZbWM_rrkLvMymjZbq4Nf-RDJP4UkpBBo=.4676e66f-6ffa-4bfc-8867-43e61abb6fbb@github.com> On Sun, 18 Jan 2026 08:35:36 GMT, Chen Liang wrote: > Ok, though ideally tests should use dedicated throws detection tools This test is still a TestNG test, and AFAIK TestNG does not have so nice assert for thrown exception (it is an attribute to the `@Test` annotation). So this whole test is using the same pattern. My plan is to convert all tests in this directory to JUnit, at which point using the JUnit' `assertThrows` should be used. Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29202#issuecomment-3767141867 From jbhateja at openjdk.org Mon Jan 19 09:04:26 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:26 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v9] In-Reply-To: References: Message-ID: > 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 ... Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits: - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Update callGenerator.hpp copyright year - Review comments resolution - Cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Updating predicate checks - Fixes for failing regressions - Optimizing AVX2 backend and some re-factoring - ... and 3 more: https://git.openjdk.org/jdk/compare/b7346c30...9da1f862 ------------- Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=08 Stats: 1347 lines in 29 files changed: 1243 ins; 1 del; 103 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Mon Jan 19 09:04:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 06:03:15 GMT, Jatin Bhateja wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > Hi @erifan , Thanks for your comments. I will address them soon, please keep reviewing in the meantime :-) > @jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks! Thanks @erifan , I think partial case is specific for AARCH64 backend and tests should accompany relevant AARCH64 changes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3767179812 From jbhateja at openjdk.org Mon Jan 19 09:04:34 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 19 Jan 2026 09:04:34 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: On Mon, 29 Sep 2025 03:24:32 GMT, Eric Fang wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Update callGenerator.hpp copyright year > > test/hotspot/jtreg/compiler/vectorapi/TestSliceOptValueTransforms.java line 101: > >> 99: .slice(0, ByteVector.fromArray(BSP, bsrc2, i)) >> 100: .intoArray(bdst, i); >> 101: } > > Would you mind adding a correctness check for these tests, for byte type, like: > > @DontInline > static void verifyVectorSliceByte(int origin) { > for (int i = 0; i < BSP.loopBound(SIZE); i += BSP.length()) { > int index = i; > for (int j = i + origin; j < i + BSP.length(); j++) { > Asserts.assertEquals(bsrc1[j], bdst[index++]); > } > for (int j = i; j < i + origin; j++) { > Asserts.assertEquals(bsrc2[j], bdst[index++]); > } > } > } There are enough number of functional correctness tests in existing VectorAPI JTREG suite, this test specifically checks for newly added VectorSlice IR node and associated ideal transformations. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2703827513 From thartmann at openjdk.org Mon Jan 19 10:04:08 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 19 Jan 2026 10:04:08 GMT Subject: [jdk26] RFR: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 07:08:06 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [1d889b92](https://github.com/openjdk/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 15 Jan 2026 and was reviewed by Tobias Hartmann, Jatin Bhateja and Sandhya Viswanathan. > > Thanks! Thanks for the reviews! Waiting for approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29263#issuecomment-3767468632 From eirbjo at gmail.com Mon Jan 19 10:16:53 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 11:16:53 +0100 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> Message-ID: David, On Sun, Jan 18, 2026 at 11:04?PM David Holmes wrote: > You would lose potentially important information when reporting monitors > owned by a thread. I get that the class name may be useful for diagnostic purposes. However, the new Object() idiom has several thousand occurrences across the JDK, while new Lock() revealed only these two (plus a few in tests). These Lock classes seem like an easy win in the effort to trim the list of JDK class loading during startup/shutdown. Do you feel that the diagnostic value added by using named classes for these two instances outweighs the benefit of trimming class loading during startup? Also I think Valhalla is trying to dissuade/move-away-from using "new > Object()". Hmm.. The alternative solution cannot be to introduce custom Lock classes everywhere, right? Thanks, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kfarrell at openjdk.org Mon Jan 19 11:25:41 2026 From: kfarrell at openjdk.org (Kieran Farrell) Date: Mon, 19 Jan 2026 11:25:41 GMT Subject: RFR: 8364182: Add jcmd VM.properties command [v8] In-Reply-To: References: Message-ID: > The goal of this PR is to add a means of exposing security properties at runtime to aid the debugging security related issues/misconfigurations etc. Currently, only initial security properties set at start up can be exposed via the `InitialSecurityProperty` JFR event. > > This patch introduces a new jcmd diagnostic command `VM.properties`, which enables developers to print either the current system properties or security properties of a running Java process via command-line arguments (-system or -security). To avoid clutter within the jcmd command list, the old `VM.system_properties` command is hidden, but not removed so will not break existing usages. The implementation of each is shared to reduce duplication. Kieran Farrell has updated the pull request incrementally with one additional commit since the last revision: add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29124/files - new: https://git.openjdk.org/jdk/pull/29124/files/bb3b243c..2b1de0f0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29124&range=06-07 Stats: 57 lines in 1 file changed: 57 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29124.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29124/head:pull/29124 PR: https://git.openjdk.org/jdk/pull/29124 From cushon at openjdk.org Mon Jan 19 11:34:10 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 11:34:10 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Fri, 16 Jan 2026 09:46:54 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Switch to @apiNote src/java.base/share/classes/java/lang/String.java line 1169: > 1167: while (sp < sl) { > 1168: char c = StringUTF16.getChar(val, sp++); > 1169: if (c > 0x80) { The handling of `c == 0x80` isn't consistent with `encodedLengthASCII`, but also it doesn't matter because this is redundant with the `isHighSurrogate` test below. Thinking about this a little more, `encodedLength8859_1` and `encodedLengthASCII` are identical, and could be merged together. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2704380997 From cushon at openjdk.org Mon Jan 19 11:39:57 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 11:39:57 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v12] In-Reply-To: References: Message-ID: <5KNXQmMrEmm3gY7F6idi3SYbA-QikCyVzwkuz3w6Clk=.a3c7039a-f554-436d-ae2d-25ce7cf09060@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Merge and optimize latin1 and ascii paths ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/2614c356..fd989e87 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=10-11 Stats: 41 lines in 1 file changed: 8 ins; 26 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Mon Jan 19 11:39:58 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 11:39:58 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Mon, 19 Jan 2026 11:30:51 GMT, Liam Miller-Cushon wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Switch to @apiNote > > src/java.base/share/classes/java/lang/String.java line 1169: > >> 1167: while (sp < sl) { >> 1168: char c = StringUTF16.getChar(val, sp++); >> 1169: if (c > 0x80) { > > The handling of `c == 0x80` isn't consistent with `encodedLengthASCII`, but also it doesn't matter because this is redundant with the `isHighSurrogate` test below. > > Thinking about this a little more, `encodedLength8859_1` and `encodedLengthASCII` are identical, and could be merged together. I have tentatively merged `encodedLength8859_1` and `encodedLengthASCII` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2704396396 From jpai at openjdk.org Mon Jan 19 14:04:38 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 19 Jan 2026 14:04:38 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v4] In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 06:05:43 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 continue... > > Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: > > - merge latest from master branch > - Mark's suggestion - move the duration check to separate method > - merge latest from master branch > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds Thank you Mark and Daniel for the reviews. I'll give Stuart a chance to take a look at this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3768488979 From jvernee at openjdk.org Mon Jan 19 14:29:44 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 19 Jan 2026 14:29:44 GMT Subject: [jdk26] Integrated: 8372493: [asan] java/foreign/sharedclosejvmti/TestSharedCloseJvmti.java triggers heap-use-after-free In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 10:25:33 GMT, Jorn Vernee wrote: > Hi all, > > This pull request contains a backport of commit [821e9ff9](https://github.com/openjdk/jdk/commit/821e9ff965cad52cdd26c08785312db49bcce539) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Jorn Vernee on 19 Dec 2025 and was reviewed by Chen Liang. > Thanks! > > We are currently in RDP1 (https://openjdk.org/projects/jdk/26/), and this issue is a test bug (noreg-self), so it is allowed without approval. This pull request has now been integrated. Changeset: 671d8561 Author: Jorn Vernee URL: https://git.openjdk.org/jdk/commit/671d8561343dee1f198db7f5b10132a0ca4d664e 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 Backport-of: 821e9ff965cad52cdd26c08785312db49bcce539 ------------- PR: https://git.openjdk.org/jdk/pull/29031 From aph at openjdk.org Mon Jan 19 14:59:30 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 19 Jan 2026 14:59:30 GMT Subject: RFR: 8373696: AArch64: Refine post-call NOPs In-Reply-To: References: <9G7UQDZGLfV0nhrQSv-a9EMvhIAkCdTB3hA9Pf6hRIo=.59b380be-e009-420e-8f76-7771e205467b@github.com> Message-ID: On Sat, 17 Jan 2026 06:21:27 GMT, Ruben wrote: > > It sounds rather complicated. It's important that the performance work we do doesn't over complexify the implementation. Whatever we do should be proportionate to the scale of the problem. Post-call NOPs are not a huge deal. > > > Why not use MOVN, and put the data into a stub at the end of the nmethod? > > If the data is stored in the stub code, the method size depends on whether `cb_offset`/`oopmap_index` fit in the respective post-call NOP - if I understand correctly, that would require calculating values of `cb_offset`/`oopmap_index` during the code generation because stub code size should be known prior to allocation in the code cache. It can't be postponed until `NativePostCallNop::patch`. Avoiding the estimation step would simplify the change. It doesn't have to be hard. We can just guess. In the odd instance that the guess is wrong, emit zeroes. > Also, referencing the stub code via MOVN - which can be used to store up to 18 bits of metadata - would limit the method size by approximately 1MB (`4 * (1 << 18)`). It might be a reasonable limit for a compiled method, however as far as I understand, right now the limit is `branch_range` (128MB). Would the 1MB limit be acceptable? Yes, 1M is plenty. Andrew. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28855#issuecomment-3768728964 From epeter at openjdk.org Mon Jan 19 16:10:04 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:10:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 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 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - 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 > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e @jatin-bhateja I had a quick look at some of the changes. The patch is HUGE (80k+ lines), so it will take me a bit more time to review. I also realized that quite some changes are not directly related. For example, you are renaming lots of existing files. I would prefer if those changes were done separately. The issue is that at some point GitHub chokes, and it is no fun doing the review :/ src/hotspot/share/opto/vectorIntrinsics.cpp line 2895: > 2893: opd1 = gvn().transform(VectorNode::make(Op_AndV, opd1, wrap_mask_vec, opd1->bottom_type()->is_vect())); > 2894: operation = gvn().transform(VectorNode::make(Op_SelectFromTwoVector, opd1, opd2, opd3, vt)); > 2895: VectorNode::trace_new_vector(operation, "VectorAPI"); I thought you wanted to add that in a separate RFE? src/hotspot/share/prims/vectorSupport.cpp line 206: > 204: } > 205: > 206: int VectorSupport::vop2ideal(jint id, int lane_type) { I think it would be nice if there was a name for `LaneType`. It's just nicer to have types named. After all, the code here used to use `BasicType`, and it helps the user know what is expected here. src/hotspot/share/prims/vectorSupport.cpp line 244: > 242: case T_FLOAT: return Op_MulF; > 243: case T_DOUBLE: return Op_MulD; > 244: default: fatal("MUL: %s", lanetype2name(lane_type)); You should fix the indentation here as well, since you are already doing it everywhere else ;) src/hotspot/share/utilities/globalDefinitions.hpp line 719: > 717: > 718: inline bool is_java_primitive(BasicType t) { > 719: return (t != T_FLOAT16 && T_BOOLEAN <= t && t <= T_LONG); This change seems unnecessary, right? `T_FLOAT16` is outside the range, as far as I can see. src/hotspot/share/utilities/globalDefinitions.hpp line 741: > 739: inline bool is_custom_basic_type(BasicType t) { > 740: return (t == T_FLOAT16); > 741: } What exactly is the definition of a "custom" basic type? Is it defined somewhere? If not, it would be useful to define it here. I assume you chose the name because we expect more such "custom" basic types in the future? ------------- Changes requested by epeter (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28002#pullrequestreview-3678699226 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705309070 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705323981 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705316085 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705333596 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705291064 From epeter at openjdk.org Mon Jan 19 16:19:02 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 19 Jan 2026 16:19:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 08:56:21 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 28 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Fix incorrect argument passed to smokeTest > - 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 > - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); > 67: > 68: static void AssertEquals(int actual, int expected) { There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2705376899 From duke at openjdk.org Mon Jan 19 17:29:35 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 Jan 2026 17:29:35 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml. Message-ID: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Allow replacement string to contain embedded newlines to split entries. This turns output like: ... another 10k chars on the end of this line ... into: ... one entry per line ... ------------- Commit messages: - 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml Changes: https://git.openjdk.org/jdk/pull/29305/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29305&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375649 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29305.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29305/head:pull/29305 PR: https://git.openjdk.org/jdk/pull/29305 From liach at openjdk.org Mon Jan 19 17:43:34 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:43:34 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont wrote: > Allow replacement string to contain embedded newlines to split entries. > This turns output like: > > > > ... another 10k chars on the end of this line ... > > > into: > > > > > > ... one entry per line ... Should we just leave the newline in SOURCE_POSTFIX? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3769511305 From eirbjo at openjdk.org Mon Jan 19 17:44:53 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 17:44:53 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath Message-ID: Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any "loader discovered" class path URLs are inserted at the head such that they are processed first. By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. Advantages: * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) * One data structure is simpler than two * We no longer need to manage search path URLs across two different collections * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed * I think this PR leaves the code overall simpler and easier to follow. Testing: This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. ------------- Commit messages: - Fold synchronization into the nextURL method - Be specific about which list is consumed tail-first - Fix comments in nextURL - Rename fields and improve their documentation - Add test to verify DFS discovery order of a multi-level Class-Path JAR tree. - Spell fix 'guarded' - Simplify reversed-order adding to loaderPath - Initialize 'loaderPath' ArrayList eagerly - Document that access to the 'path', 'pathCursor', 'loaderPath' and nextURL() method requires holding a lock on 'path' - Revert added leading whitespace - ... and 1 more: https://git.openjdk.org/jdk/compare/a0e6f028...6d21f049 Changes: https://git.openjdk.org/jdk/pull/29288/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375580 Stats: 249 lines in 2 files changed: 206 ins; 20 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/29288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29288/head:pull/29288 PR: https://git.openjdk.org/jdk/pull/29288 From liach at openjdk.org Mon Jan 19 17:44:57 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:44:57 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any "loader discovered" class path URLs are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Looks much better and thanks for the test, but I still think `loaderPath` might be renamed to `expandedJars` or something similar to indicate the nature of those urls. (You can consider renaming `push` too) The code looks good to me logically. The rename is a net improvement for code readability. ? src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 107: > 105: > 106: /* A list of loader-discovered URLs, if any */ > 107: private ArrayList loaderPath; Document these three variables' accesses are guarded by monitor on `path`. In addition, this is probably more accurately called `dfsUrls`, because they are paths waiting for expansion from a DFS. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 371: > 369: * Returns the next URL to process or null if finished > 370: */ > 371: private URL nextURL() { Document that this method must be called when holding a lock on `path` src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 485: > 483: // Lazily create list > 484: if (loaderPath == null) { > 485: loaderPath = new ArrayList<>(); This will always be used if we are using `JarLoader`, which seems to be used in the majority of cases. I recommend initializing this dfs variable unconditionally. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 490: > 488: for (int i = urls.length - 1; i >= 0; --i) { > 489: loaderPath.addLast(urls[i]); > 490: } Should we do `dfsUrls.addAll(Arrays.asList(urls).reversed())` for simplicity? src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 490: > 488: private void addExpandedPaths(URL[] urls) { > 489: synchronized (searchPath) { > 490: // Adding in reversed order since URLs are consumed tail-first Suggestion: // Adding in reversed order since expandedPath is consumed tail-first ------------- PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3676106618 Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3679120128 PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3769348993 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702193525 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702193246 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702220970 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702222377 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2705527983 From eirbjo at openjdk.org Mon Jan 19 17:44:59 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 17:44:59 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any "loader discovered" class path URLs are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. This PR now includes a test to verify DFS search order of a multi-level tree of JARs related by `Class-Path` attributes. Current testing verifies basic `Class-Path` functionality, but does not catch regressions introduced by subtle changes in ordering. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 403: > 401: while (loaders.size() < index + 1) { > 402: final URL url; > 403: synchronized (searchPath) { @liach Do you think it would be prudent to fold the synchronization here into `nextURL`? This way `nextURL()` would claim full responsibility for its own accesses and we could remove the note on holding the lock when calling the method? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3765753966 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2705168431 From eirbjo at openjdk.org Mon Jan 19 17:44:59 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 17:44:59 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> References: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> Message-ID: On Mon, 19 Jan 2026 03:12:14 GMT, Chen Liang wrote: > You can consider renaming `push` too How do you like the following: /* * Adds the specified URLs to the queue of 'Class-Path' expanded URLs */ private void addExpandedPaths(URL[] urls) { //... } > Looks much better and thanks for the test, but I still think `loaderPath` might be renamed to `expandedJars` or something similar to indicate the nature of those urls. Thanks for poking. I was pondering this, not being quite happy with any of the names floated. Maybe we should rename `path` as well, since this is competely generic and doesn't contrast well with anything. I think names and comments here should aid maintainers to quickly get some understanding of why we have two different lists, which URLs go where and where they originate from. How do you like the following? /* Search path of URLs passed to the constructor or by calls to addURL(URL) * Access is guarded by a monitor on 'searchPath' itself */ private final ArrayList searchPath; /* Index of the next URL in the search path to process * Access is guarded by a monitor on 'searchPath' */ private int nextURL = 0; /* Queue of URLs found during expansion of JAR 'Class-Path' attributes * Access is guarded by a monitor on 'searchPath' */ private final ArrayList expandedPath = new ArrayList<>(); > The rename is a net improvement for code readability. ? Thanks a lot for very helpful feedback. I went ahead and folded the synchronization into `nextURL`. With all initial concerns addressed, I'm moving this out of Draft state to invite more reviewers. Channeling @jaikiran and Code Historian @Martin-Buchholz who was the one to introduce `ArrayDeque` in this code. > Document these three variables' accesses are guarded by monitor on `path`. Thanks, see above. > In addition, this is probably more accurately called `dfsUrls`, because they are paths waiting for expansion from a DFS. Excuse my ignorance, what do you mean by 'DFS' in this context? > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 371: > >> 369: * Returns the next URL to process or null if finished >> 370: */ >> 371: private URL nextURL() { > > Document that this method must be called when holding a lock on `path` Thanks, I have added notes to the three fields and this method. > This will always be used if we are using `JarLoader`, which seems to be used in the majority of cases. Not exactly, `push` is only called when the JAR uses the 'Class-Path:' attribute. I don't have data to support this, but from personal experience I don't see this being used too often. > I recommend initializing this dfs variable unconditionally. GIven the above, do you still think it's worth initializing this eagerly? It would allow us to make the field final and avoid a null check. EDIT: Decided to initialize eagerly and make the field final, see below. > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 490: > >> 488: for (int i = urls.length - 1; i >= 0; --i) { >> 489: loaderPath.addLast(urls[i]); >> 490: } > > Should we do `dfsUrls.addAll(Arrays.asList(urls).reversed())` for simplicity? Sympathizing with Alan's concern in the JBS about being extra cautious about introducing subtle behaviour changes in this change, I have tried to limit any cleanups not motivated by the change itself to the absolute minimum. Leaving iteration as-is also simplifies the analysis of performance implications. I agree that the code you suggest expresses the intent much better though. If you feel confident reviewing it despite the stated concerns, I'm happy to apply it. I leave it to you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3767376134 PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3767412140 PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3769506874 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702267790 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702267133 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702269596 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702273490 From liach at openjdk.org Mon Jan 19 17:45:00 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:45:00 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> Message-ID: <_hT_Y8o8r_tdZS5Wk2jO-Zv4i2I2X7bq6HuJRRN1P2I=.234c432e-863c-4ea5-a653-553e7b18ba6e@github.com> On Sun, 18 Jan 2026 09:48:55 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 107: >> >>> 105: >>> 106: /* A list of loader-discovered URLs, if any */ >>> 107: private ArrayList loaderPath; >> >> Document these three variables' accesses are guarded by monitor on `path`. >> >> In addition, this is probably more accurately called `dfsUrls`, because they are paths waiting for expansion from a DFS. > >> Document these three variables' accesses are guarded by monitor on `path`. > > Thanks, see above. > >> In addition, this is probably more accurately called `dfsUrls`, because they are paths waiting for expansion from a DFS. > > Excuse my ignorance, what do you mean by 'DFS' in this context? Depth-first search. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702504594 From liach at openjdk.org Mon Jan 19 17:45:02 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:45:02 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:15:18 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any "loader discovered" class path URLs are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 403: > >> 401: while (loaders.size() < index + 1) { >> 402: final URL url; >> 403: synchronized (searchPath) { > > @liach Do you think it would be prudent to fold the synchronization here into `nextURL`? > > This way `nextURL()` would claim full responsibility for its own accesses and we could remove the note on holding the lock when calling the method? Sure! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2705526483 From hgreule at openjdk.org Mon Jan 19 17:45:03 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 19 Jan 2026 17:45:03 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> Message-ID: On Sun, 18 Jan 2026 09:51:39 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 485: >> >>> 483: // Lazily create list >>> 484: if (loaderPath == null) { >>> 485: loaderPath = new ArrayList<>(); >> >> This will always be used if we are using `JarLoader`, which seems to be used in the majority of cases. I recommend initializing this dfs variable unconditionally. > >> This will always be used if we are using `JarLoader`, which seems to be used in the majority of cases. > > Not exactly, `push` is only called when the JAR uses the 'Class-Path:' attribute. I don't have data to support this, but from personal experience I don't see this being used too often. > >> I recommend initializing this dfs variable unconditionally. > > GIven the above, do you still think it's worth initializing this eagerly? It would allow us to make the field final and avoid a null check. > > EDIT: Decided to initialize eagerly and make the field final, see below. `ArrayList` initializes its backing array lazily when using that constructor, so I think there isn't much reason to do a "double lazy" initialization. (It *might* make sense to initialize the list with a different size (e.g. `urls.length`), but I guess we'd need some real-world data on this. And I don't think that's worth the effort.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702293940 From eirbjo at openjdk.org Mon Jan 19 17:45:03 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 17:45:03 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> Message-ID: On Sun, 18 Jan 2026 10:32:57 GMT, Hannes Greule wrote: >>> This will always be used if we are using `JarLoader`, which seems to be used in the majority of cases. >> >> Not exactly, `push` is only called when the JAR uses the 'Class-Path:' attribute. I don't have data to support this, but from personal experience I don't see this being used too often. >> >>> I recommend initializing this dfs variable unconditionally. >> >> GIven the above, do you still think it's worth initializing this eagerly? It would allow us to make the field final and avoid a null check. >> >> EDIT: Decided to initialize eagerly and make the field final, see below. > > `ArrayList` initializes its backing array lazily when using that constructor, so I think there isn't much reason to do a "double lazy" initialization. > > (It *might* make sense to initialize the list with a different size (e.g. `urls.length`), but I guess we'd need some real-world data on this. And I don't think that's worth the effort.) Alright, seems I was too eager on this lazy initialization :) I have made the field final. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702321343 From eirbjo at openjdk.org Mon Jan 19 17:45:04 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 17:45:04 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: <9UKFPIOaSa7by6bcPMdeF2KBNaKqhr1GHKb_q1fIGp8=.2f21837c-eaf4-4a4d-9335-23bea1a41752@github.com> Message-ID: On Sun, 18 Jan 2026 09:57:51 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 490: >> >>> 488: for (int i = urls.length - 1; i >= 0; --i) { >>> 489: loaderPath.addLast(urls[i]); >>> 490: } >> >> Should we do `dfsUrls.addAll(Arrays.asList(urls).reversed())` for simplicity? > > Sympathizing with Alan's concern in the JBS about being extra cautious about introducing subtle behaviour changes in this change, I have tried to limit any cleanups not motivated by the change itself to the absolute minimum. Leaving iteration as-is also simplifies the analysis of performance implications. > > I agree that the code you suggest expresses the intent much better though. If you feel confident reviewing it despite the stated concerns, I'm happy to apply it. I leave it to you. > Should we do `dfsUrls.addAll(Arrays.asList(urls).reversed())` for simplicity? I was overthinking this, suggestion applied, thanks :-) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2702340003 From liach at openjdk.org Mon Jan 19 17:51:35 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 19 Jan 2026 17:51:35 GMT Subject: RFR: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:05:43 GMT, Jan Lahoda wrote: > The `SwitchBootstraps.enumSwitch` is documented to throw a `NullPointerException` when `lookup` is `null`, but it does not throw the exception in all cases. > > Given the `lookup` is in some cases required, the proposal herein is to properly check `lookup` is not `null`. And while doing that, I added similar checks for `invocationType` and `labels` - those were checked implicitly, but doing the check explicitly is better. Note `invocationName` is unused and is permitted to be `null`, and hence there's no check for it. > > Please also review the CSR: > https://bugs.openjdk.org/browse/JDK-8375120 TestNG has a `org.testng.Assert.assertThrows` method, but sure we can migrate later. ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29202#issuecomment-3769533609 From vyazici at openjdk.org Mon Jan 19 19:22:57 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Mon, 19 Jan 2026 19:22:57 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v12] In-Reply-To: <5KNXQmMrEmm3gY7F6idi3SYbA-QikCyVzwkuz3w6Clk=.a3c7039a-f554-436d-ae2d-25ce7cf09060@github.com> References: <5KNXQmMrEmm3gY7F6idi3SYbA-QikCyVzwkuz3w6Clk=.a3c7039a-f554-436d-ae2d-25ce7cf09060@github.com> Message-ID: On Mon, 19 Jan 2026 11:39:57 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Merge and optimize latin1 and ascii paths fd989e87da4 LGTM and I've confirmed that the following tests pass on all supported major platforms: test/jdk/java/lang/String/Encodings.java test/jdk/java/lang/String/Exceptions.java test/jdk/sun/nio/cs/TestStringCoding.java ------------- Marked as reviewed by vyazici (Committer). PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3679326198 From alanb at openjdk.org Mon Jan 19 19:36:22 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 19 Jan 2026 19:36:22 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: On Mon, 19 Jan 2026 08:14:11 GMT, Liam Miller-Cushon wrote: > The motivating use cases I've seen for this method are to compute the length of encoded data that contains strings, where the strings would be encoded with `getBytes`. The CSR gives the example of encoding multiple large strings into a single array. Specifying the output in terms of `getBytes(cs).length` is necessary for that use-case, and requires the handling of replacement characters and unpaired surrogates to be the same between the two methods. Do you see alternatives that should be considered? The comment wasn't questing the addition. Instead we are saying that there is no mention of coding-error actions. More specifically, I think we should insert a sentence before "The result will be the same ..." to say that the returned length takes account of the replacement of malformed-input and unmappable-character sequences with the charset's default replacement byte array. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3769823410 From iklam at openjdk.org Mon Jan 19 19:52:42 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Jan 2026 19:52:42 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v3] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. Ioi Lam has updated the pull request incrementally with two additional commits since the last revision: - Reverted previous unintended commit - 8375654: Exclude all array classes from dynamic CDS archive ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/e9006f5e..6ef4a4da Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=01-02 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From duke at openjdk.org Mon Jan 19 20:08:56 2026 From: duke at openjdk.org (David Beaumont) Date: Mon, 19 Jan 2026 20:08:56 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:39:58 GMT, Chen Liang wrote: > Should we just leave the newline in SOURCE_POSTFIX? You end up with an extra blank line in the output if you do that, unless you mess with the template file as well. The postfix is output +1 times more than the intermediate separator (fence posts). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3769946094 From iklam at openjdk.org Mon Jan 19 20:24:46 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Jan 2026 20:24:46 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v4] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. 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 seven additional commits since the last revision: - fixed typo - Merge branch 'master' into 8366736-closed-system-out-causes-child-process-to-hang-on-windows - Review comments from @RogerRiggs - Reverted previous unintended commit - 8375654: Exclude all array classes from dynamic CDS archive - Review comments from @RogerRiggs - 8366736: Closed System.out causes child process to hang on Windows ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/6ef4a4da..7785fde1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=02-03 Stats: 26705 lines in 491 files changed: 14871 ins; 6166 del; 5668 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From iklam at openjdk.org Mon Jan 19 20:24:51 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Jan 2026 20:24:51 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v2] In-Reply-To: References: Message-ID: On Wed, 14 Jan 2026 14:40:04 GMT, Roger Riggs wrote: > The change in behavior should be documented in an APINote on Process.inheritIO() to say that the output is discarded if it has been closed. I added an APINote for `Process.inheritIO()`: * @apiNote * If {#code System.out} and/or {#code System.err} have been * closed in the current process, the corresponding output * in the subprocess will be discarded. > src/java.base/windows/classes/java/lang/ProcessImpl.java line 133: > >> 131: if (stdHandles[1] == -1L) { >> 132: // FileDescriptor.out has been closed. >> 133: f1 = setFileOutput(Redirect.DISCARD, stdHandles, 1); > > More compact yes, but I prefer to update local state inline, its easier to see the consistent pattern of state updates across the different cases. I updated the code as you suggested. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29198#issuecomment-3769993899 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2705980676 From vklang at openjdk.org Mon Jan 19 21:06:25 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 21:06:25 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1271: > 1269: } > 1270: if (pred == null && pool != null) > 1271: pool.signalWork(this, s); // may have appeared empty @DougLea I presume we don't need to do the getReferenceAcquire if the pool is null? If so, then we could do something like: boolean signal = pool != null && U.getReferenceAcquire(a, slotOffset(m & (s - 1))) == null; if (unlock != 1) { // release external lock U.putInt(this, PHASE, unlock); U.storeFence(); } if (signal) pool.signalWork(this, s); // may have appeared empty ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2706064195 From vklang at openjdk.org Mon Jan 19 21:11:36 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 19 Jan 2026 21:11:36 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v27] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 18 Jan 2026 21:07:48 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: > > Simplify scan mode control by moving and reworking topLevelExec and throwing on trim src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1299: > 1297: break; // lost to pollers > 1298: newArray[k & newMask] = u; > 1299: } @DougLea Not sure if it helps loop unrolling, but a possible change might be something like: for (int k = s - 1, j = cap; j > 0 && (u = (ForkJoinTask)U.getAndSetReference(a, slotOffset(k & mask), null)) != null; // lost to pollers --j, --k) { newArray[k & newMask] = u; } src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1303: > 1301: if (unlock != 1) > 1302: phase = unlock; > 1303: if (pool != null) @DougLea Are we 100% sure we always need to signal upon resize? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2706072253 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2706073001 From redestad at openjdk.org Mon Jan 19 21:36:35 2026 From: redestad at openjdk.org (Claes Redestad) Date: Mon, 19 Jan 2026 21:36:35 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 212: > 210: return; > 211: synchronized (searchPath) { > 212: if (! searchPath.contains(url)) { Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? I guess you'd need something like `!searchPath.subList(nextURL, searchPath.size() + 1).contains(url)` to be perfectly neutral semantically here, but I'm not sure if re-adding previously opened URLs is a valid use-case. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2706119367 From iklam at openjdk.org Mon Jan 19 21:47:26 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 19 Jan 2026 21:47:26 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v5] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: Fixed typo ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/7785fde1..4b7d30c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From cushon at openjdk.org Mon Jan 19 22:06:45 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 22:06:45 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v13] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Add a note about malformed-input and unmappable-character sequences ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/fd989e87..08929964 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=11-12 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Mon Jan 19 22:06:45 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 22:06:45 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v11] In-Reply-To: References: <8XbPxy1-8hhVxCIC6T4SXyH7v48UjNry2qJ_MQnqyfg=.f68b328d-dd68-43fc-9846-6bccf9dbf9ca@github.com> Message-ID: <86vTkfnNdJ6oX58wLLIQMRoEIGjXR71SU4EJu31lY18=.8c7a2c4d-4591-44e8-8dcc-cb5b3a33e434@github.com> On Mon, 19 Jan 2026 19:33:26 GMT, Alan Bateman wrote: > The comment wasn't questing the addition. Instead we are saying that there is no mention of coding-error actions. More specifically, I think we should insert a sentence before "The result will be the same ..." to say that the returned length takes account of the replacement of malformed-input and unmappable-character sequences with the charset's default replacement byte array. Got it, thanks! I added a sentence, suggestions welcome if you have a better phrasing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3770259967 From cushon at openjdk.org Mon Jan 19 22:10:44 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Mon, 19 Jan 2026 22:10:44 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v3] In-Reply-To: References: Message-ID: > See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). > > Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. > > This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. Liam Miller-Cushon has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8374654' into JDK-8208752 - Only resolve object methods on interfaces ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28943/files - new: https://git.openjdk.org/jdk/pull/28943/files/10ee13db..1f803bcc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=01-02 Stats: 28 lines in 2 files changed: 22 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/28943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28943/head:pull/28943 PR: https://git.openjdk.org/jdk/pull/28943 From eirbjo at openjdk.org Mon Jan 19 22:46:17 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 19 Jan 2026 22:46:17 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 21:32:48 GMT, Claes Redestad wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 212: > >> 210: return; >> 211: synchronized (searchPath) { >> 212: if (! searchPath.contains(url)) { > > Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? I guess you'd need something like `!searchPath.subList(nextURL, searchPath.size() + 1).contains(url)` to be perfectly neutral semantically here, but I'm not sure if re-adding previously opened URLs is a valid use-case. Hello Claes! > Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? Not sure I follow. If by "scan through" you mean the `contains` call, then we scan through the same list of URLs before and after this PR. It's the list of URLs passed in the constructor, possibly amended by calls to `addURL`. It was renamed from `path` to `searchPath`. Whether URLs where processed/loaded did not matter before this PR, and it does not matter now. Before we needed to add URLs to both `unopenedUrls` (to find it during loading) and to `paths` (because we needed to return the amended list in `getURLs`. Perhaps I misunderstood what you're saying here.. Could you also re-read the code and check that you got it right on your side? We should definitely get to the bottom of this, we don't want to introduce any behavior changes in this PR, should be a pure refactoring. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2706246854 From missa at openjdk.org Mon Jan 19 23:08:40 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 19 Jan 2026 23:08:40 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v6] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 23 commits: - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - Fix CMove IR tests to account for APX presence - Merge branch 'master' into user/missa-prime/avx10_2 - Update the copyright year in modified files - Happy New Year! - Re-introduce two missing UseAPX flag checks in cmov section of x86.ad file - ... and 13 more: https://git.openjdk.org/jdk/compare/e7432d57...2fecf9f5 ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=05 Stats: 863 lines in 10 files changed: 663 ins; 105 del; 95 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From missa at openjdk.org Mon Jan 19 23:15:06 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 19 Jan 2026 23:15:06 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v5] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 17:25:08 GMT, Sandhya Viswanathan wrote: >> Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > > src/hotspot/cpu/x86/assembler_x86.cpp line 7357: > >> 7355: } >> 7356: >> 7357: void Assembler::ucomxss(XMMRegister dst, Address src) { > > ucomxss should be named as vucomxss. > ucomxsd should be named as vucomxsd. I re-named them. > src/hotspot/cpu/x86/x86.ad line 1703: > >> 1701: static void emit_cmpfp3(MacroAssembler* masm, Register dst) { >> 1702: // If any floating point comparison instruction is used, unordered case always triggers jump >> 1703: // For below condition, CF=1 is true when at least one input is NaN > > // for > lowercase f in for. This is modified now. > test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 64: > >> 62: @IR(counts = {IRNode.X86_CMOVEL_IMM01UCFE, "1"}, >> 63: applyIfPlatform = {"x64", "true"}, >> 64: applyIfCPUFeature = {"apx_f", "true"}, > > Need to include avx10_2 check here as well. I added the avx10_2 checks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706285643 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706285351 PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2706286308 From jrose at openjdk.org Mon Jan 19 23:22:06 2026 From: jrose at openjdk.org (John R Rose) Date: Mon, 19 Jan 2026 23:22:06 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:36:33 GMT, Hannes Greule wrote: > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. (see previous comment) Good catch; that is more correct, since it covers primitive types. I would prefer to keep the bind-to language, since it teaches about that API point as well. Should be: *

The returned method handle is equivalent to {@code identity(type).bindTo(value)}, * for reference types. For all types it is equivalent to * {@code insertArguments(identity(type), 0, value)}. ------------- Changes requested by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29174#pullrequestreview-3679849448 PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3770398331 From redestad at openjdk.org Tue Jan 20 00:32:27 2026 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 20 Jan 2026 00:32:27 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 22:42:35 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 212: >> >>> 210: return; >>> 211: synchronized (searchPath) { >>> 212: if (! searchPath.contains(url)) { >> >> Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? I guess you'd need something like `!searchPath.subList(nextURL, searchPath.size() + 1).contains(url)` to be perfectly neutral semantically here, but I'm not sure if re-adding previously opened URLs is a valid use-case. > > Hello Claes! > >> Does it matter that this would now search through all opened URLs while before we'd only scan through the list of unopened? > > Not sure I follow. If by "scan through" you mean the `contains` call, then we scan through the same list of URLs before and after this PR. It's the list of URLs passed in the constructor, possibly amended by calls to `addURL`. It was renamed from `path` to `searchPath`. > > Whether URLs had been loaded or not did not matter before this PR, and it does not matter now. Before we needed to add URLs to both `unopenedUrls` (to find it during loading) and to `paths` (because we needed to return the amended list in `getURLs`. > > The only change in this `addURL` method (besides renaming) is that we no longer need to update `unopenedUrls`. This is because `nextURL` now looks for URLs first in `expandedPath`, then directly in `searchPath`. Before, URLs were processed strictly from `unopenedUrls` and the only purpose of having the `path` field seems to have been `getURLs`. > > Perhaps I misunderstood what you're saying here.. Could you also re-read the code and check that you got it right on your side? > > We should definitely get to the bottom of this, we don't want to introduce any behavior changes in this PR, should be a pure refactoring. Yeah, I simply misread. What you have seems fine. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2706381466 From erfang at openjdk.org Tue Jan 20 01:33:36 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 20 Jan 2026 01:33:36 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v8] In-Reply-To: References: Message-ID: <6_ZqCg4GNfBg0NonFKzf24z0NCkuRKRZQ9T2VVXUg0E=.745f107f-985f-4e7a-ac51-63c86ac7034f@github.com> On Mon, 19 Jan 2026 08:57:23 GMT, Jatin Bhateja wrote: > > @jatin-bhateja I have no further comments, great work. After this PR is merged, I will complete the backend optimization of the aarch64 part based on it. Thanks! > > Thanks @erifan , I think partial case is specific for AARCH64 backend and tests should accompany relevant AARCH64 changes. Thanks, @jatin-bhateja. Make sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3770638063 From missa at openjdk.org Tue Jan 20 01:48:53 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 20 Jan 2026 01:48:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v7] In-Reply-To: References: Message-ID: <4r0vCH4670oyysJREP_VTToXt8DLQh6uuvrWyANuzXg=.5d7073b2-988f-41fd-8efc-f84af358c9f5@github.com> > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa 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 branch 'master' into user/missa-prime/avx10_2 - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - Fix CMove IR tests to account for APX presence - Merge branch 'master' into user/missa-prime/avx10_2 - Update the copyright year in modified files - Happy New Year! - ... and 14 more: https://git.openjdk.org/jdk/compare/496af3cf...6a02cab7 ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=06 Stats: 862 lines in 10 files changed: 663 ins; 105 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From thartmann at openjdk.org Tue Jan 20 06:46:46 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Tue, 20 Jan 2026 06:46:46 GMT Subject: [jdk26] Integrated: 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 07:08:06 GMT, Tobias Hartmann wrote: > Hi all, > > This pull request contains a backport of commit [1d889b92](https://github.com/openjdk/jdk/commit/1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Volodymyr Paprotski on 15 Jan 2026 and was reviewed by Tobias Hartmann, Jatin Bhateja and Sandhya Viswanathan. > > Thanks! This pull request has now been integrated. Changeset: 2f0d03d6 Author: Tobias Hartmann URL: https://git.openjdk.org/jdk/commit/2f0d03d64e14fb2fd9d99e1885e584421aacca6b Stats: 19 lines in 2 files changed: 11 ins; 0 del; 8 mod 8360271: String.indexOf intrinsics fail with +EnableX86ECoreOpts and -CompactStrings Reviewed-by: mhaessig, sviswanathan Backport-of: 1d889b92bde5dfcb1fbe6cddb389a77f92eb1ce7 ------------- PR: https://git.openjdk.org/jdk/pull/29263 From duke at openjdk.org Tue Jan 20 08:57:52 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 08:57:52 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: References: Message-ID: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> > `jcmd` provides great diagnostics but many commands lack a timestamp in their output. > Adding a timestamp to the output of some would add value for those debugging JVM data. > > Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. > > With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": > > jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename > ^^^^ > > * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. > * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. > > I haven't added a timestamp to the following diagnostic command: > * `VM.uptime` - command run with `-date` argument will also print a timestamp; > * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. > * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; Ivan Bereziuk 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: - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - introduce -T as a commong flag - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - ... and 5 more: https://git.openjdk.org/jdk/compare/d1597314...5f1cefe0 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27368/files - new: https://git.openjdk.org/jdk/pull/27368/files/bfa2a927..5f1cefe0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27368&range=00-01 Stats: 648983 lines in 8151 files changed: 439394 ins; 124768 del; 84821 mod Patch: https://git.openjdk.org/jdk/pull/27368.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27368/head:pull/27368 PR: https://git.openjdk.org/jdk/pull/27368 From smonteith at openjdk.org Tue Jan 20 09:37:08 2026 From: smonteith at openjdk.org (Stuart Monteith) Date: Tue, 20 Jan 2026 09:37:08 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: >> 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... > > I'll start a discussion soon on panama-dev. At the very least, this PR provides a point of discussion. > @stooart-mon This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply issue a `/touch` or `/keepalive` command to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration! It's OK bot, I'm sure people are looking at this. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3771899705 From erfang at openjdk.org Tue Jan 20 10:01:31 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 20 Jan 2026 10:01:31 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: References: Message-ID: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> > 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... 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: - Rebase commit 56d7b52 - Merge branch 'master' into JDK-8372980-umin-umax-intrinsic - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations 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 ``` - 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/28693/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=01 Stats: 1101 lines in 12 files changed: 685 ins; 16 del; 400 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 duke at openjdk.org Tue Jan 20 10:07:19 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 10:07:19 GMT Subject: RFR: 8357828: Add a timestamp to jcmd diagnostic commands [v2] In-Reply-To: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> References: <8sOGIUdhIChpJbEOpFivzEHfkYJGyzQpw0eaPSp9DVI=.648165ee-a2e4-4fd3-857f-fd21aa5dfc3f@github.com> Message-ID: On Tue, 20 Jan 2026 08:57:52 GMT, Ivan Bereziuk wrote: >> `jcmd` provides great diagnostics but many commands lack a timestamp in their output. >> Adding a timestamp to the output of some would add value for those debugging JVM data. >> >> Some diagnostic commands already provide timestamps. For example `Thread.print` already prints one of "yyyy-MM-dd HH:mm:ss" format. >> >> With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": >> >> jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename >> ^^^^ >> >> * The choice for time format is "yyyy-MM-dd HH:mm:ss" as it is already used in `Thread.print`. >> * `Thread.print` prints timestamp irrespectively from "-T" flag presence to preserve backwards compatibility. >> >> I haven't added a timestamp to the following diagnostic command: >> * `VM.uptime` - command run with `-date` argument will also print a timestamp; >> * `VM.system_properties` - as the output already lists a timestamp. Not sure if we need more timestamps here. >> * `Thread.dump_to_file` - the content dumped to a file already has a timestamp; > > Ivan Bereziuk 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: > > - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - changes to jcmd.md > - undo changes to reorder_help_cmd() > - cleanup > - add timestamp to VM.version. Add test > - updated jcmd usage text > - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible > - introduce -T as a commong flag > - Merge branch 'master' into 8357828_add_timestamp_to_jcmd > - ... and 5 more: https://git.openjdk.org/jdk/compare/e1bc2481...5f1cefe0 I've made timestamping optional with "-T" flag. The flag is part of the command sent to the target JVM. jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ The target diagnostic command handler can decide how to act on it. @dholmes-ora > ... what form should this timestamp take? Shouldn't it be configurable to allow matching with what may be presented by Unified Logging e.g. VM uptime rather than wall-clock time? > And rather than add timestamp printing code to each dcmd it would make more sense to me to have a global dcmd flag that says "print a timestamp" (with a given format). `Thread.print` already prints a timestamp, hence explicit "-T" has no effect for this particular command. This also affected my choice for using format "yyyy-MM-dd HH:mm:ss". At least as a default. Do you think we need to be able changing the timestamp format (say "-T=UTC")? Should we add time-stamping to STDOUT from commands that are of "action" type? E.g. "GC.run". ------------- PR Comment: https://git.openjdk.org/jdk/pull/27368#issuecomment-3772022851 From erfang at openjdk.org Tue Jan 20 10:07:24 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 20 Jan 2026 10:07:24 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> References: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> Message-ID: On Tue, 20 Jan 2026 10:01:31 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 >> ... > > 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: > > - Rebase commit 56d7b52 > - Merge branch 'master' into JDK-8372980-umin-umax-intrinsic > - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations > > 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 4... Hi, the patch adds intrinsic support for VectorAPI umin/umax reduction, it is ready for review, would you mind take a look, thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3772017425 From alanb at openjdk.org Tue Jan 20 10:13:15 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jan 2026 10:13:15 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v13] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 22:06:45 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Add a note about malformed-input and unmappable-character sequences src/java.base/share/classes/java/lang/String.java line 2112: > 2110: * sequences with the charset's default replacement byte array. > 2111: * > 2112: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. The wording is good. As "The result will be the same ..." follows the previous sentence then I think you can drop the paragraph tag so that it goes into the same paragraph. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2707658422 From cushon at openjdk.org Tue Jan 20 10:20:10 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 20 Jan 2026 10:20:10 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v14] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Remove paragraph break ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/08929964..77bc5b9e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=13 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=12-13 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Tue Jan 20 10:20:14 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Tue, 20 Jan 2026 10:20:14 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:09:39 GMT, Alan Bateman wrote: >> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: >> >> Add a note about malformed-input and unmappable-character sequences > > src/java.base/share/classes/java/lang/String.java line 2112: > >> 2110: * sequences with the charset's default replacement byte array. >> 2111: * >> 2112: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. > > The wording is good. As "The result will be the same ..." follows the previous sentence then I think you can drop the paragraph tag so that it goes into the same paragraph. Thanks, done ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2707682613 From sgehwolf at openjdk.org Tue Jan 20 11:37:16 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 11:37:16 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name Message-ID: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. Thoughts? **Testing:** - [x] GHA - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. ------------- Commit messages: - 8375692: Hotspot container tests assert with non-ascii vendor name Changes: https://git.openjdk.org/jdk/pull/29315/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375692 Stats: 5 lines in 3 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From syan at openjdk.org Tue Jan 20 11:52:03 2026 From: syan at openjdk.org (SendaoYan) Date: Tue, 20 Jan 2026 11:52:03 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { > 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; > 380: } Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708015583 From jbhateja at openjdk.org Tue Jan 20 11:56:16 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:16 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] 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: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/273b219e..fe7075ee Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=11-12 Stats: 85 lines in 4 files changed: 0 ins; 3 del; 82 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 Jan 20 11:56:19 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 20 Jan 2026 11:56:19 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Mon, 19 Jan 2026 15:49:49 GMT, Emanuel Peter wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 28 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Fix incorrect argument passed to smokeTest >> - 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 >> - ... and 18 more: https://git.openjdk.org/jdk/compare/499b5882...273b219e > > src/hotspot/share/utilities/globalDefinitions.hpp line 741: > >> 739: inline bool is_custom_basic_type(BasicType t) { >> 740: return (t == T_FLOAT16); >> 741: } > > What exactly is the definition of a "custom" basic type? Is it defined somewhere? > If not, it would be useful to define it here. > > I assume you chose the name because we expect more such "custom" basic types in the future? You are right, primarily basic types are driven by JVM language specification...in this case T_FLOAT16 is a non standard basic type. > test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: > >> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >> 67: >> 68: static void AssertEquals(int actual, int expected) { > > There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708024220 PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2708023788 From sgehwolf at openjdk.org Tue Jan 20 13:34:27 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 13:34:27 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:48:49 GMT, SendaoYan wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: > >> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >> 380: } > > Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java Sure. I can do that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2708370629 From alanb at openjdk.org Tue Jan 20 14:43:12 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 20 Jan 2026 14:43:12 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v13] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:15:12 GMT, Liam Miller-Cushon wrote: >> src/java.base/share/classes/java/lang/String.java line 2112: >> >>> 2110: * sequences with the charset's default replacement byte array. >>> 2111: * >>> 2112: *

The result will be the same value as {@link #getBytes(Charset) getBytes(cs).length}. >> >> The wording is good. As "The result will be the same ..." follows the previous sentence then I think you can drop the paragraph tag so that it goes into the same paragraph. > > Thanks, done Update API docs looks okay to me. I cleaned up the CSR a bit, and added myself as Reviewer. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28454#discussion_r2708647875 From aph at openjdk.org Tue Jan 20 15:01:59 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 20 Jan 2026 15:01:59 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> References: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> Message-ID: On Tue, 20 Jan 2026 10:01:31 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 >> ... > > 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: > > - Rebase commit 56d7b52 > - Merge branch 'master' into JDK-8372980-umin-umax-intrinsic > - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations > > 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 4... I found the selection logic getting more complex and harder to follow. If you refactor things a little by making signed/unsigned a parameter to the assembly instruction, you can do this. While this approach makes the assembler a bit more fiddly, `neon_reduce_minmax_integral()` is better. See what you think. diff --git a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp index fc6e58b801c..35f29db1675 100644 --- a/src/hotspot/cpu/aarch64/assembler_aarch64.hpp +++ b/src/hotspot/cpu/aarch64/assembler_aarch64.hpp @@ -2625,17 +2625,27 @@ template #undef INSN // Advanced SIMD three different -#define INSN(NAME, opc, opc2, acceptT2D) \ - void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, FloatRegister Vm) { \ + +#define neon3different(U, opc, acceptT2D, Vd, T, Vn, Vm) \ + { \ guarantee(T != T1Q && T != T1D, "incorrect arrangement"); \ if (!acceptT2D) guarantee(T != T2D, "incorrect arrangement"); \ - if (opc2 == 0b101101) guarantee(T != T8B && T != T16B, "incorrect arrangement"); \ + if (opc == 0b101101) guarantee(T != T8B && T != T16B, "incorrect arrangement"); \ starti; \ - f(0, 31), f((int)T & 1, 30), f(opc, 29), f(0b01110, 28, 24); \ - f((int)T >> 1, 23, 22), f(1, 21), rf(Vm, 16), f(opc2, 15, 10); \ + f(0, 31), f((int)T & 1, 30), f(U, 29), f(0b01110, 28, 24); \ + f((int)T >> 1, 23, 22), f(1, 21), rf(Vm, 16), f(opc, 15, 10); \ rf(Vn, 5), rf(Vd, 0); \ } +#define INSN(NAME, U, opc, acceptT2D) \ + void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, FloatRegister Vm) { \ + neon3different(U, opc, acceptT2D, Vd, T, Vn, Vm); \ + } +#define INSN2(NAME, opc, acceptT2D) \ +void NAME(int U, FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn, FloatRegister Vm) { \ + neon3different(U, opc, acceptT2D, Vd, T, Vn, Vm); \ + } + INSN(addv, 0, 0b100001, true); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D INSN(subv, 1, 0b100001, true); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D INSN(sqaddv, 0, 0b000011, true); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D @@ -2663,21 +2673,33 @@ template INSN(sqdmulh,0, 0b101101, false); // accepted arrangements: T4H, T8H, T2S, T4S INSN(shsubv, 0, 0b001001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S + INSN2(maxp, 0b101001, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S + INSN2(minp, 0b101011, false); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S + #undef INSN +#undef INSN2 // Advanced SIMD across lanes -#define INSN(NAME, opc, opc2, accepted) \ - void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) { \ +#define neonAcrossLanes(U, opc, accepted, Vd, T, Vn) \ + { \ guarantee(T != T1Q && T != T1D, "incorrect arrangement"); \ if (accepted < 3) guarantee(T != T2D, "incorrect arrangement"); \ if (accepted < 2) guarantee(T != T2S, "incorrect arrangement"); \ if (accepted < 1) guarantee(T == T8B || T == T16B, "incorrect arrangement"); \ starti; \ - f(0, 31), f((int)T & 1, 30), f(opc, 29), f(0b01110, 28, 24); \ - f((int)T >> 1, 23, 22), f(opc2, 21, 10); \ + f(0, 31), f((int)T & 1, 30), f(U, 29), f(0b01110, 28, 24); \ + f((int)T >> 1, 23, 22), f(opc, 21, 10); \ rf(Vn, 5), rf(Vd, 0); \ } +#define INSN(NAME, U, opc, accepted) \ + void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) { \ + neonAcrossLanes(U, opc, accepted, Vd, T, Vn); \ + } +#define INSN2(NAME, opc, accepted) \ + void NAME(int U, FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) { \ + neonAcrossLanes(U, opc, accepted, Vd, T, Vn); \ + } INSN(absr, 0, 0b100000101110, 3); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D INSN(negr, 1, 0b100000101110, 3); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S, T2D INSN(notr, 1, 0b100000010110, 0); // accepted arrangements: T8B, T16B @@ -2692,7 +2714,11 @@ template INSN(uaddlp, 1, 0b100000001010, 2); // accepted arrangements: T8B, T16B, T4H, T8H, T2S, T4S INSN(uaddlv, 1, 0b110000001110, 1); // accepted arrangements: T8B, T16B, T4H, T8H, T4S + INSN2(maxv, 0b110000101010, 1); // accepted arrangements: T8B, T16B, T4H, T8H, T4S + INSN2(minv, 0b110001101010, 1); // accepted arrangements: T8B, T16B, T4H, T8H, T4S + #undef INSN +#undef INSN2 #define INSN(NAME, opc) \ void NAME(FloatRegister Vd, SIMD_Arrangement T, FloatRegister Vn) { \ diff --git a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp index 3431b4f700a..b6e5e04e1e8 100644 --- a/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp +++ b/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp @@ -1973,10 +1973,22 @@ void C2_MacroAssembler::neon_reduce_minmax_integral(int opc, Register dst, Basic assert(bt == T_BYTE || bt == T_SHORT || bt == T_INT || bt == T_LONG, "unsupported"); assert_different_registers(dst, isrc); bool isQ = vector_length_in_bytes == 16; - bool is_min = (opc == Op_MinReductionV || opc == Op_UMinReductionV); - bool is_unsigned = (opc == Op_UMinReductionV || opc == Op_UMaxReductionV); - Assembler::Condition cond = is_min ? (is_unsigned ? Assembler::LO : Assembler::LT) - : (is_unsigned ? Assembler::HI : Assembler::GT); + + bool is_min; + int is_unsigned; + Condition cond; + switch(opc) { + case Op_MinReductionV: + is_min = true; is_unsigned = false; cond = LT; break; + case Op_MaxReductionV: + is_min = false; is_unsigned = false; cond = GT; break; + case Op_UMinReductionV: + is_min = true; is_unsigned = true; cond = LO; break; + case Op_UMaxReductionV: + is_min = false; is_unsigned = true; cond = HI; break; + default: + ShouldNotReachHere(); + } BLOCK_COMMENT("neon_reduce_minmax_integral {"); if (bt == T_LONG) { @@ -1993,18 +2005,12 @@ void C2_MacroAssembler::neon_reduce_minmax_integral(int opc, Register dst, Basic if (size == T2S) { // For T2S (2x32-bit elements), use pairwise instructions because // uminv/umaxv/sminv/smaxv don't support arrangement 2S. - if (is_unsigned) { - is_min ? uminp(vtmp, size, vsrc, vsrc) : umaxp(vtmp, size, vsrc, vsrc); - } else { - is_min ? sminp(vtmp, size, vsrc, vsrc) : smaxp(vtmp, size, vsrc, vsrc); - } + is_min ? minp(is_unsigned, vtmp, size, vsrc, vsrc) + : maxp(is_unsigned, vtmp, size, vsrc, vsrc); } else { // For other sizes, use reduction to scalar instructions. - if (is_unsigned) { - is_min ? uminv(vtmp, size, vsrc) : umaxv(vtmp, size, vsrc); - } else { - is_min ? sminv(vtmp, size, vsrc) : smaxv(vtmp, size, vsrc); - } + is_min ? minv(is_unsigned, vtmp, size, vsrc) + : maxv(is_unsigned, vtmp, size, vsrc); } if (bt == T_INT) { umov(dst, vtmp, S, 0); ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3773303625 From duke at openjdk.org Tue Jan 20 15:59:41 2026 From: duke at openjdk.org (Ivan Bereziuk) Date: Tue, 20 Jan 2026 15:59:41 GMT Subject: RFR: 8357828: add timestamp to jcmd v2 Message-ID: `jcmd` provides great diagnostics but many commands lack a timestamp in their output. Adding a timestamp to the output of some would add value for those debugging JVM data. With this MR I propose to introduce time-stamping to all diagnostic `jcmd` commands in a form of an additional common flag "-T": jcmd [pid | main-class] [-T] command... | PerfCounter.print | -f filename ^^^^ This is a simplified approach to handle timestamp (v1 is [here](https://github.com/openjdk/jdk/pull/27368)) Some diagnostic commands already provide timestamps information. For example `Thread.print` already starts with a timestamp of "yyyy-MM-dd HH:mm:ss" format. In that case the timestamp is printed twice if "-T" flag is passed to `Thread.print`. ------------- Commit messages: - improve TestJcmdTimestamp.java. add '-f - implementation v2, top level timestamping - remove TimeStamp::No as it's not used. virtual should be flipped to override in bulk (afressed clang warning) - Merge branch 'master' into 8357828_add_timestamp_to_jcmd - changes to jcmd.md - undo changes to reorder_help_cmd() - cleanup - add timestamp to VM.version. Add test - updated jcmd usage text - undo the changes to the modified earlier tests as timestamp presence is fully backwards compatible - ... and 7 more: https://git.openjdk.org/jdk/compare/f2d5290c...eaea764d Changes: https://git.openjdk.org/jdk/pull/29325/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29325&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8357828 Stats: 189 lines in 6 files changed: 169 ins; 4 del; 16 mod Patch: https://git.openjdk.org/jdk/pull/29325.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29325/head:pull/29325 PR: https://git.openjdk.org/jdk/pull/29325 From varadam at openjdk.org Tue Jan 20 16:46:04 2026 From: varadam at openjdk.org (Varada M) Date: Tue, 20 Jan 2026 16:46:04 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v2] In-Reply-To: References: Message-ID: <6N_Yj5njGNPnfJVNxfXventZ53ciKys9nYRYaVEevvM=.128229b4-181f-44a8-b1ba-410ac6f61662@github.com> > 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) Varada M 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: - 8371187: [BigEndian Platforms] Vector lane reversal error - Merge remote-tracking branch 'origin/vecalign' into vecalign - fix for vector alignment issue on big-endian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28425/files - new: https://git.openjdk.org/jdk/pull/28425/files/05d4b806..7c87d2bc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=00-01 Stats: 489139 lines in 7084 files changed: 306787 ins; 107695 del; 74657 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 sgehwolf at openjdk.org Tue Jan 20 16:57:26 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:26 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/73bad7f9..9f93451f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=00-01 Stats: 3 lines in 3 files changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Tue Jan 20 16:57:29 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Tue, 20 Jan 2026 16:57:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 13:30:43 GMT, Severin Gehwolf wrote: >> test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java line 380: >> >>> 378: if (baseImage.contains("ubuntu") && DockerfileConfig.isUbsan()) { >>> 379: template += "RUN apt-get update && apt-get install -y libubsan1\n"; >>> 380: } >> >> Should we update the copyright for test/lib/jdk/test/lib/containers/docker/DockerTestUtils.java > > Sure. I can do that. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/9f93451faae3e4f168386e7367ba75c54797deb7 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2709230655 From varadam at openjdk.org Tue Jan 20 17:12:15 2026 From: varadam at openjdk.org (Varada M) Date: Tue, 20 Jan 2026 17:12:15 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: 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) Varada M 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: - 8371187: [BigEndian Platforms] Vector lane reversal error - fix for vector alignment issue on big-endian ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28425/files - new: https://git.openjdk.org/jdk/pull/28425/files/7c87d2bc..670043ae Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=01-02 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 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 varadam at openjdk.org Tue Jan 20 17:12:18 2026 From: varadam at openjdk.org (Varada M) Date: Tue, 20 Jan 2026 17:12:18 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: <73nhI9qLs1GPuJq4OfNM2VTUg-QqNA4O-GZLUl-TYcY=.b247fd6e-d909-46c7-885a-01c0930a01e9@github.com> References: <73nhI9qLs1GPuJq4OfNM2VTUg-QqNA4O-GZLUl-TYcY=.b247fd6e-d909-46c7-885a-01c0930a01e9@github.com> Message-ID: On Wed, 14 Jan 2026 10:09:42 GMT, Martin Doerr wrote: >> Varada M 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: >> >> - 8371187: [BigEndian Platforms] Vector lane reversal error >> - fix for vector alignment issue on big-endian > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/DoubleVector.java line 3627: > >> 3625: VectorShuffle shuffle = normalizeSubLanesForSpecies(this.vspecies(), subLanesPerSrc); >> 3626: return this.rearrange(shuffle); >> 3627: } > > I think the code could be refactored such that we don't need copies of the `subLanesPerSrc` computation. Thanks Martin!! I have refactored the code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2709281681 From dfenacci at openjdk.org Tue Jan 20 18:54:04 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:04 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics Message-ID: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> ## Issue This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. ## Causes The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. ## Fix A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. # Testing * Tier 1-3+ * 2 JTReg tests added * `TestRangeCheck.java` as regression test for the reported issue * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion ------------- Commit messages: - JDK-8374852: revert unchanged tests - JDK-8374852: shorten line lenght in test - JDK-8374852: revert comment change - JDK-8374852: correct comment and make more concise - Update test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java - JDK-8374852: fix generate_limit_guard opaque handling and remove unneeded positive flag - JDK-8374852: remove compileonly - JDK-8374852: remove VerifyIntrinsicChecks and refactor opaque flag - JDK-8374852: add forgotten opaque guard node handling in clone_iff - JDK-8374852: 120 max char for comment - ... and 8 more: https://git.openjdk.org/jdk/compare/6d1bfdf7...ff228576 Changes: https://git.openjdk.org/jdk/pull/29164/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8374582 Stats: 435 lines in 28 files changed: 328 ins; 20 del; 87 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From vyazici at openjdk.org Tue Jan 20 18:54:09 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:09 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Marked as reviewed by vyazici (Committer). Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210]. [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 src/hotspot/share/opto/c2_globals.hpp line 680: > 678: develop(bool, VerifyIntrinsicChecks, false, \ > 679: "Verify in intrinsic that Java level checks work as expected") \ > 680: \ I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore? src/hotspot/share/opto/library_call.hpp line 170: > 168: Node* length, bool char_count, > 169: bool halt_on_oob = false, > 170: bool is_opaque = false); Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` 2. defaults (i.e., `halt_on_oob=is_opaque=false`) Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? src/hotspot/share/opto/loopopts.cpp line 1: > 1: /* What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`? src/hotspot/share/opto/macro.cpp line 2565: > 2563: // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds, > 2564: // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug), > 2565: // we will execute a Halt node. *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file? src/hotspot/share/opto/macro.cpp line 2569: > 2567: _igvn.replace_node(n, n->in(1)); > 2568: #else > 2569: _igvn.replace_node(n, _igvn.intcon(0)); Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above? src/hotspot/share/opto/opaquenode.hpp line 160: > 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode > 159: // inputs instead). > 160: class OpaqueGuardNode : public Node { With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1: > 1: /* Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted: git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java git checkout upstream/HEAD -- \ test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \ test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \ test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \ test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32: > 30: * -XX:CompileCommand=inline,java.lang.StringCoding::* > 31: * -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize > 32: * -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test Is this necessary? (This wasn't used in `TestStringConstruction`.) test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: > 56: // cut off the dead code. As a result, -1 is fed as input into the > 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a > 58: // failure in the matcher. I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? Suggestion: // Calling `StringCoding::countPositives`, which is a "front door" // to the `StringCoding::countPositives0` intrinsic. // `countPositives` validates its input using // `Preconditions::checkFromIndexSize`, which also maps to an // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not // know about the explicit range checks, and does not cut off the // dead code. As a result, an invalid value (e.g., `-1`) can be fed // as input into the `countPositives0` intrinsic, got replaced // by TOP, and cause a failure in the matcher. ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3681112226 PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3738455817 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689568427 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2687948444 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685859575 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2685838328 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705884654 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2705885810 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2704760982 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689735070 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689780537 From dfenacci at openjdk.org Tue Jan 20 18:54:10 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:10 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Mon, 12 Jan 2026 13:03:58 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Verified that 3c466d372b7 is a clean revert of 7e18de137c3 delivered in [JDK-8374210]. > > [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 Thanks for your review @vy. In addition to the changes you suggested I also fixed the opaque node value in `LibraryCallKit::generate_limit_guard` which was wrong (I then removed the `is_positive` flag altogether since it was `false` in both cases) and added `TestOpaqueGuardNodes.java` to test that the opaque nodes are added and later removed. > src/hotspot/share/opto/c2_globals.hpp line 680: > >> 678: develop(bool, VerifyIntrinsicChecks, false, \ >> 679: "Verify in intrinsic that Java level checks work as expected") \ >> 680: \ > > I suggest removing the `VerifyIntrinsicChecks` flag. Given `OpaqueGuard` already verifies the value when `#ifdef ASSERT`, does `VerifyIntrinsicChecks` serve any purpose anymore? Done. > src/hotspot/share/opto/loopopts.cpp line 1: > >> 1: /* > > What is the reason that the new `OpaqueGuard` is not taken into account in `PhaseIdealLoop::clone_iff`? Oversight ? Thanks! Fixed. > src/hotspot/share/opto/macro.cpp line 2565: > >> 2563: // Tests with OpaqueGuard nodes are implicitly known to be true or false. Replace the node with appropriate value. In debug builds, >> 2564: // we leave the test in the graph to have an additional sanity check at runtime. If the test fails (i.e. a bug), >> 2565: // we will execute a Halt node. > > *Nit:* Can we adhere to the max. 120 (or even better, 80!) characters per line limit of the file? Fair enough (good to know: I wasn't aware of such limit). > src/hotspot/share/opto/macro.cpp line 2569: > >> 2567: _igvn.replace_node(n, n->in(1)); >> 2568: #else >> 2569: _igvn.replace_node(n, _igvn.intcon(0)); > > Curious: why do we invoke `intcon(0)` for `OpaqueGuard`, whereas it was `intcon(1)` for `OpaqueNotNull` slightly above? In `OpaqueGuard`'s case we know that the input is always "false" (so, we set 0 as its input). For `OpaqueNotNull` we know that the input is always "true" (so, we set 1 as its input). > src/hotspot/share/opto/opaquenode.hpp line 160: > >> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode >> 159: // inputs instead). >> 160: class OpaqueGuardNode : public Node { > > With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? > test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java line 1: > >> 1: /* > > Since the `VerifyIntrinsicChecks` flag is gone, AFAICT, all following changes can be reverted: > > > git rm test/hotspot/jtreg/compiler/intrinsics/TestVerifyIntrinsicChecks.java > git checkout upstream/HEAD -- \ > test/hotspot/jtreg/compiler/intrinsics/string/TestCountPositives.java \ > test/hotspot/jtreg/compiler/intrinsics/string/TestEncodeIntrinsics.java \ > test/hotspot/jtreg/compiler/intrinsics/string/TestHasNegatives.java \ > test/hotspot/jtreg/compiler/patches/java.base/java/lang/Helper.java Totally. Done. > test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 32: > >> 30: * -XX:CompileCommand=inline,java.lang.StringCoding::* >> 31: * -XX:CompileCommand=exclude,jdk.internal.util.Preconditions::checkFromIndexSize >> 32: * -XX:CompileCommand=compileonly,compiler.intrinsics.string.TestRangeCheck::test > > Is this necessary? (This wasn't used in `TestStringConstruction`.) Nope (leftover from debugging). Removed ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3755585217 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787876 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785777 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694785429 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707280040 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707283139 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707272331 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694788432 From vyazici at openjdk.org Tue Jan 20 18:54:11 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:11 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 13 Jan 2026 20:01:31 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > src/hotspot/share/opto/library_call.hpp line 170: > >> 168: Node* length, bool char_count, >> 169: bool halt_on_oob = false, >> 170: bool is_opaque = false); > > Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: > > 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` > 2. defaults (i.e., `halt_on_oob=is_opaque=false`) > > Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? Giving this a second thought, do we need these two flags anyway? That is, 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.) 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2689690430 From dfenacci at openjdk.org Tue Jan 20 18:54:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 09:38:40 GMT, Volkan Yazici wrote: >> src/hotspot/share/opto/library_call.hpp line 170: >> >>> 168: Node* length, bool char_count, >>> 169: bool halt_on_oob = false, >>> 170: bool is_opaque = false); >> >> Do we really need to introduce two new toggles: `halt_on_oob` and `is_opaque`? At all call-sites either one of the following is used: >> >> 1. `halt_on_oob=true, is_opaque=!VerifyIntrinsicChecks` >> 2. defaults (i.e., `halt_on_oob=is_opaque=false`) >> >> Can we instead only settle one, e.g., `halt_on_oob=VerifyIntrinsicChecks`? > > Giving this a second thought, do we need these two flags anyway? That is, > > 1. We can remove `if (is_opaque)` add the `OpaqueGuard` anyway, since it is ineffective for `!ASSERT`. (This is what `must_be_not_null` does too.) > 2. We can replace `if (halt_on_oob) { ... } else { ... }` with `#ifdef ASSERT ...`. 1. I'm not sure we can always do that: `LibraryCallKit::generate_string_range_check` is called from places that don't yet have Java range checks and we must not add an opaque node in those cases (or we end up without checks in prod builds). 2. For a similar reason I'd leave `if (halt_on_oob)` condition: for calls to `LibraryCallKit::generate_string_range_check` that don't yet have Java range checks the method behaves like it did before. For "new" calls it adds the `Halt` node (which will then be removed together with the guard in prod builds). So, on the one hand we can keep `halt_on_oob` alone as discriminant between "new" and "old" call sites. On the other we can get rid of `VerifyIntrinsicChecks` because we implicitly add the additional range check in debug builds (always). I've modified the code accordingly. What do you think? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694787303 From vyazici at openjdk.org Tue Jan 20 18:54:12 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Tue, 20 Jan 2026 18:54:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 20 Jan 2026 08:27:59 GMT, Damon Fenacci wrote: >> src/hotspot/share/opto/opaquenode.hpp line 160: >> >>> 158: // we keep the actual checks as additional verification code (i.e. removing OpaqueGuardNode and use the BoolNode >>> 159: // inputs instead). >>> 160: class OpaqueGuardNode : public Node { >> >> With the `OpaqueGuardNode::is_positive` flag gone, `OpaqueGuardNode` looks pretty much identical to `OpaqueNotNullNode`. Is there a code reuse opportunity we can take advantage of? > > It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? Fair enough ? I was just curious. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2707418513 From duke at openjdk.org Tue Jan 20 18:54:14 2026 From: duke at openjdk.org (ExE Boss) Date: Tue, 20 Jan 2026 18:54:14 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 10:05:23 GMT, Volkan Yazici wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: > >> 56: // cut off the dead code. As a result, -1 is fed as input into the >> 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a >> 58: // failure in the matcher. > > I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? > > Suggestion: > > // Calling `StringCoding::countPositives`, which is a "front door" > // to the `StringCoding::countPositives0` intrinsic. > // `countPositives` validates its input using > // `Preconditions::checkFromIndexSize`, which also maps to an > // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not > // know about the explicit range checks, and does not cut off the > // dead code. As a result, an invalid value (e.g., `-1`) can be fed > // as input into the `countPositives0` intrinsic, got replaced > // by TOP, and cause a failure in the matcher. **Nit:** Using??get??here is?grammatically?better: // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not // know about the explicit range checks, and does not cut off the - // as input into the `countPositives0` intrinsic, got replaced + // as input into the `countPositives0` intrinsic, get replaced // by TOP, and cause a failure in the matcher. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2690260434 From dfenacci at openjdk.org Tue Jan 20 18:54:14 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 20 Jan 2026 18:54:14 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Wed, 14 Jan 2026 12:34:51 GMT, ExE Boss wrote: >> test/hotspot/jtreg/compiler/intrinsics/string/TestRangeCheck.java line 58: >> >>> 56: // cut off the dead code. As a result, -1 is fed as input into the >>> 57: // StringCoding::countPositives0 intrinsic which is replaced by TOP and causes a >>> 58: // failure in the matcher. >> >> I'd appreciate it if we can be more elaborate for less C2-illiterate people like myself. ? >> >> Suggestion: >> >> // Calling `StringCoding::countPositives`, which is a "front door" >> // to the `StringCoding::countPositives0` intrinsic. >> // `countPositives` validates its input using >> // `Preconditions::checkFromIndexSize`, which also maps to an >> // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not >> // know about the explicit range checks, and does not cut off the >> // dead code. As a result, an invalid value (e.g., `-1`) can be fed >> // as input into the `countPositives0` intrinsic, got replaced >> // by TOP, and cause a failure in the matcher. > > **Nit:** Using??get??here is?grammatically?better: > > // intrinsic. When `checkFromIndexSize` is not inlined, C2 does not > // know about the explicit range checks, and does not cut off the > - // as input into the `countPositives0` intrinsic, got replaced > + // as input into the `countPositives0` intrinsic, get replaced > // by TOP, and cause a failure in the matcher. Done. Thanks for the suggestion! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2694948915 From mdoerr at openjdk.org Tue Jan 20 18:58:54 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 20 Jan 2026 18:58:54 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 17:12:15 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) > > Varada M 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: > > - 8371187: [BigEndian Platforms] Vector lane reversal error > - fix for vector alignment issue on big-endian Thanks! I have more questions and suggestions. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 185: > 183: // NOTE: This assumes that convert0('X') > 184: // respects REGISTER_ENDIAN order. > 185: return convert0('X', vspecies().withLanes(laneType)).maybeSwapOnConverted(java.nio.ByteOrder.nativeOrder(), vspecies()); Would `swapIfNeeded` be a better name? I think we could determine the ByteOrder where it is used. Then, we don't have to pass it any more. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 194: > 192: int[] id = new int[lanes]; > 193: for (int i = 0; i < lanes; ++i) id[i] = i; > 194: return VectorShuffle.fromArray(targetSpecies, id, 0); Some comments would be helpful describing what you do in which case. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 211: > 209: > 210: @ForceInline > 211: final int subLanesPerSrcIfNeeded(ByteOrder bo, AbstractSpecies srcSpecies) { Would `subLanesToSwap` be a better name? Shouldn't it be `protected`, too? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 217: > 215: int sBytes = srcSpecies.elementSize(); > 216: int tBytes = vspecies().elementSize(); > 217: if (sBytes == tBytes || (sBytes % tBytes) != 0) { What do we do if it's not divisible? Should we better throw an exception? ------------- PR Review: https://git.openjdk.org/jdk/pull/28425#pullrequestreview-3683652415 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2709564720 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2709629154 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2709553616 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2709673998 From erikj at openjdk.org Tue Jan 20 19:13:56 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Tue, 20 Jan 2026 19:13:56 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont wrote: > Allow replacement string to contain embedded newlines to split entries. > This turns output like: > > > > ... another 10k chars on the end of this line ... > > > into: > > > > > > ... one entry per line ... Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29305#pullrequestreview-3683874366 From aph at openjdk.org Tue Jan 20 19:28:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 20 Jan 2026 19:28:04 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> References: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> Message-ID: On Tue, 20 Jan 2026 10:01:31 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 >> ... > > 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: > > - Rebase commit 56d7b52 > - Merge branch 'master' into JDK-8372980-umin-umax-intrinsic > - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations > > 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 4... I'm sorry, I _completely_ overthought that one. All you need are definitions for `min[vp]` and `max[vp]` in C2_Macroassembler. Like so: `void minv(bool is_unsigned, ...) { if (is_unsigned) { uminv(... } else { sminv(... } }` No need to mess with class `Assembler`. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3774562567 From liach at openjdk.org Tue Jan 20 19:50:14 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 19:50:14 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 Wed, 17 Dec 2025 23:56:54 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/CompileThresholdBootstrapTest.java line 46: > >> 44: public static void main(String ... args) throws Throwable { >> 45: CompileThresholdBootstrapTest test = new CompileThresholdBootstrapTest(); >> 46: test.testBootstrap(); > > Does this main method even do anything? Looks like it's not being run. I know @cl4es loves to add main to small programs for easy profiling. Claes, do you think we should keep this main entrypoint for easy profiling? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2709833295 From liach at openjdk.org Tue Jan 20 19:50:17 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 19:50:17 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 Wed, 7 Jan 2026 18:00:08 GMT, Chen Liang wrote: >> test/jdk/java/lang/invoke/MethodHandleProxies/Unnamed.java line 46: >> >>> 44: // inaccessible interface >>> 45: Method m = intf.getMethod("test"); >>> 46: assertFalse(m.canAccess(t)); >> >> This looks like a semantic change? Fixing an existing bug in the test? > > Yes. I should extract this to a separate patch - this plus the `@run testng/othervm Unnamed` should be converted to `@run main/othervm Unnamed`. Opened PR #29330 to fix this. Please help review.. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2709835463 From liach at openjdk.org Tue Jan 20 19:51:50 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 19:51:50 GMT Subject: RFR: 8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java Message-ID: This test program `Unnamed` ran from `java/lang/invoke/MethodHandleProxies/Driver.java` is incorrectly run by testng, which does nothing. It is intended to be a main test. The conversion reveals the test itself has some problems as well, also fixed within this patch. Testing: This test itself. This change is test-only. ------------- Commit messages: - 8375742 Changes: https://git.openjdk.org/jdk/pull/29330/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29330&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375742 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29330.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29330/head:pull/29330 PR: https://git.openjdk.org/jdk/pull/29330 From bchristi at openjdk.org Tue Jan 20 20:31:18 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:31:18 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/a67979c4...07f981f6 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29331/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From bchristi at openjdk.org Tue Jan 20 20:34:55 2026 From: bchristi at openjdk.org (Brent Christian) Date: Tue, 20 Jan 2026 20:34:55 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 Message-ID: This brings in cpu26_01 changes. ------------- Commit messages: - 8368032: Enhance Certificate Checking - 8365280: Enhance JOptionPane - 8359501: Enhance Handling of URIs - 8362632: Improve HttpServer Request handling - 8367277: Fix copyright header in JMXInterfaceBindingTest.java - 8366446: Test java/awt/geom/ConcurrentDrawPolygonTest.java fails intermittently - 8341496: Improve JMX connections - 8365058: Enhance CopyOnWriteArraySet - 8365271: Improve Swing supports - 8362308: Enhance Bitmap operations - ... and 2 more: https://git.openjdk.org/jdk/compare/f4ddafcd...4b0189c4 The merge commit only contains trivial merges, so no merge-specific webrevs have been generated. Changes: https://git.openjdk.org/jdk/pull/29332/files Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From pchilanomate at openjdk.org Tue Jan 20 20:46:04 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 20:46:04 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: Randomly choose platform or virtual notifier ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29255/files - new: https://git.openjdk.org/jdk/pull/29255/files/b69a40f1..c31f41fa Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29255&range=01-02 Stats: 15 lines in 1 file changed: 7 ins; 0 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29255.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29255/head:pull/29255 PR: https://git.openjdk.org/jdk/pull/29255 From pchilanomate at openjdk.org Tue Jan 20 20:50:22 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Tue, 20 Jan 2026 20:50:22 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 19:49:55 GMT, Alan Bateman wrote: >> Added a comment. Maybe we should use `ThreadLocalRandom` in both cases to decide whether the notifier should be a platform or virtual thread? > > Good idea, could be TLR or just different runs of test but the effect would be adding more timing scenarios to the testing. Done. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29255#discussion_r2710015709 From kcr at openjdk.org Tue Jan 20 21:34:45 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:34:45 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684377505 From kcr at openjdk.org Tue Jan 20 21:35:46 2026 From: kcr at openjdk.org (Kevin Rushforth) Date: Tue, 20 Jan 2026 21:35:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. LGTM ------------- Marked as reviewed by kcr (Author). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684378038 From jvernee at openjdk.org Tue Jan 20 21:42:17 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 20 Jan 2026 21:42:17 GMT Subject: RFR: 8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:44:31 GMT, Chen Liang wrote: > This test program `Unnamed` ran from `java/lang/invoke/MethodHandleProxies/Driver.java` is incorrectly run by testng, which does nothing. It is intended to be a main test. The conversion reveals the test itself has some problems as well, also fixed within this patch. > > Testing: This test itself. This change is test-only. Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29330#pullrequestreview-3684401078 From naoto at openjdk.org Tue Jan 20 21:45:57 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 21:45:57 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v14] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 10:20:10 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Remove paragraph break Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28454#pullrequestreview-3684413844 From liach at openjdk.org Tue Jan 20 21:58:09 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 21:58:09 GMT Subject: RFR: 8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:44:31 GMT, Chen Liang wrote: > This test program `Unnamed` ran from `java/lang/invoke/MethodHandleProxies/Driver.java` is incorrectly run by testng, which does nothing. It is intended to be a main test. The conversion reveals the test itself has some problems as well, also fixed within this patch. > > Testing: This test itself. This change is test-only. Thanks for the review. I will integrate early given this change is isolated and blocks java/lang/invoke overall testng to junit migration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29330#issuecomment-3775125646 From liach at openjdk.org Tue Jan 20 21:58:10 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 21:58:10 GMT Subject: Integrated: 8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 19:44:31 GMT, Chen Liang wrote: > This test program `Unnamed` ran from `java/lang/invoke/MethodHandleProxies/Driver.java` is incorrectly run by testng, which does nothing. It is intended to be a main test. The conversion reveals the test itself has some problems as well, also fixed within this patch. > > Testing: This test itself. This change is test-only. This pull request has now been integrated. Changeset: aaca0a2c Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/aaca0a2c1f3de06a1349ae9084e9e9dbec991421 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod 8375742: Test java/lang/invoke/MethodHandleProxies/Driver.java does not run Unnamed.java Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/29330 From prr at openjdk.org Tue Jan 20 22:05:29 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:05:29 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684486562 From prr at openjdk.org Tue Jan 20 22:08:39 2026 From: prr at openjdk.org (Phil Race) Date: Tue, 20 Jan 2026 22:08:39 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. Marked as reviewed by prr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684495706 From dnguyen at openjdk.org Tue Jan 20 22:33:58 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Tue, 20 Jan 2026 22:33:58 GMT Subject: RFR: 8375775: JDK 26 RDP2 L10n resource files update Message-ID: Open l10n drop. Files have been updated with translated versions. There are no new changes from RDP1 to RDP2. The changes here are updates from the translation team regarding our suggested fixes from review comments in the RDP1 drop. ------------- Commit messages: - Initial commit Changes: https://git.openjdk.org/jdk/pull/29334/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29334&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375775 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29334.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29334/head:pull/29334 PR: https://git.openjdk.org/jdk/pull/29334 From naoto at openjdk.org Tue Jan 20 22:38:35 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:38:35 GMT Subject: RFR: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <0zvDd2c0zlDopqgiRlwvQ1U5ZKyqLTvnjUVEPlZM6YU=.653d3885-720e-450e-b2eb-f7cd488a01a4@github.com> On Tue, 20 Jan 2026 22:25:51 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. > > There are no new changes from RDP1 to RDP2. The changes here are updates from the translation team regarding our suggested fixes from review comments in the RDP1 drop. Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29334#pullrequestreview-3684597191 From naoto at openjdk.org Tue Jan 20 22:43:41 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:43:41 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM from i18n point of view. Probably needs more reviews from hotspot side test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > 1: /* > 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. nit: needs to keep 2025 ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3684605144 PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710321875 From naoto at openjdk.org Tue Jan 20 22:46:14 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:46:14 GMT Subject: RFR: 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds In-Reply-To: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> References: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> Message-ID: <9MoA5DGyXy6ME2I-5yQZamjzmO18vOxhx3DnBiDtBJ0=.1f8c402d-56af-48b4-9319-2126dfbf2020@github.com> On Fri, 9 Jan 2026 20:48:39 GMT, Naoto Sato wrote: > Clarifying the javadoc for `ZonedDateTime#toString()` about the zero seconds/nanoseconds omission. A corresponding CSR has also been drafted. Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29146#issuecomment-3775299752 From naoto at openjdk.org Tue Jan 20 22:48:25 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 20 Jan 2026 22:48:25 GMT Subject: Integrated: 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds In-Reply-To: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> References: <8lleg0DAJmtNJetK_1z95ZpXTpxS7vpgs7T97FA0V4E=.d57a00a5-8821-477c-9228-517ec63f5fac@github.com> Message-ID: On Fri, 9 Jan 2026 20:48:39 GMT, Naoto Sato wrote: > Clarifying the javadoc for `ZonedDateTime#toString()` about the zero seconds/nanoseconds omission. A corresponding CSR has also been drafted. This pull request has now been integrated. Changeset: 4fd7595f Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/4fd7595f1b607588d9854471a701c2992c6bec60 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8374905: Clarify ZonedDateTime#toString() documentation regarding omitted zero seconds Reviewed-by: rriggs, bpb ------------- PR: https://git.openjdk.org/jdk/pull/29146 From jlu at openjdk.org Tue Jan 20 23:02:32 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 20 Jan 2026 23:02:32 GMT Subject: RFR: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 22:25:51 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. > > There are no new changes from RDP1 to RDP2. The changes here are updates from the translation team regarding our suggested fixes from review comments in the RDP1 drop. Can confirm it addresses the actionable suggestions from the RDP1 PR. ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29334#pullrequestreview-3684657734 From liach at openjdk.org Tue Jan 20 23:02:50 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:02:50 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: <6b4oVAcgwlVTxJ4W9FGh0XDYS3MOVObzmNeod6HmkVI=.078d925c-bb0f-4ea4-94c1-354f4ca0bb27@github.com> On Wed, 17 Dec 2025 23:58:36 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/DefineClassTest.java line 211: > >> 209: >> 210: Class clazz = lookup.defineClass(generateClass("java.lang.Foo")); >> 211: assertEquals("java.lang.Foo", clazz.getName()); > > Looks like the parameter order was already reversed here. No? I think my new order is right that the "actual" should be the value from reflection. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710368951 From liach at openjdk.org Tue Jan 20 23:08:43 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:08:43 GMT Subject: RFR: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 22:25:51 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. > > There are no new changes from RDP1 to RDP2. The changes here are updates from the translation team regarding our suggested fixes from review comments in the RDP1 drop. lgtm! ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29334#pullrequestreview-3684671326 From redestad at openjdk.org Tue Jan 20 23:25:08 2026 From: redestad at openjdk.org (Claes Redestad) Date: Tue, 20 Jan 2026 23:25:08 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: <0zC4ifxFnhc3k8LamLJJ5tSyuTk_ubXwj44p8PrcX6g=.380c6bf0-7669-42e4-8508-0d2183115f73@github.com> On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3684705793 From liach at openjdk.org Tue Jan 20 23:55:02 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:55:02 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: 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. Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: - Another round of copyright year update - Various bugs - assertInstanceOf - loop test review, test instance cleanup - Use static imports - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit - Review - Some omissions - Whitespace - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca ------------- Changes: https://git.openjdk.org/jdk/pull/28879/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28879&range=02 Stats: 6140 lines in 129 files changed: 661 ins; 872 del; 4607 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 Tue Jan 20 23:55:04 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:55:04 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 Wed, 17 Dec 2025 23:52:44 GMT, Jorn Vernee wrote: >> test/jdk/java/lang/invoke/AccessControlTest.java line 217: >> >>> 215: boolean sameClass = (c1 == c2); >>> 216: Assertions.assertTrue(samePackage || !sameTopLevel); >>> 217: Assertions.assertTrue(sameTopLevel || !sameClass); >> >> Suggestion: >> >> assertTrue(samePackage || !sameTopLevel); >> assertTrue(sameTopLevel || !sameClass); > > Looks like you can do this cleanup in other places too. Done, purged qualified calls and replaced with static imports consistently (except the javadoc example test where there is a name clash) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710459676 From liach at openjdk.org Tue Jan 20 23:55:06 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:55:06 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 Tue, 20 Jan 2026 19:45:54 GMT, Chen Liang wrote: >> test/jdk/java/lang/invoke/CompileThresholdBootstrapTest.java line 46: >> >>> 44: public static void main(String ... args) throws Throwable { >>> 45: CompileThresholdBootstrapTest test = new CompileThresholdBootstrapTest(); >>> 46: test.testBootstrap(); >> >> Does this main method even do anything? Looks like it's not being run. > > I know @cl4es loves to add main to small programs for easy profiling. Claes, do you think we should keep this main entrypoint for easy profiling? Removed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710458426 From liach at openjdk.org Tue Jan 20 23:55:10 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 20 Jan 2026 23:55:10 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 Mon, 5 Jan 2026 14:06:50 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Some omissions > > test/jdk/java/lang/invoke/LoopCombinatorTest.java line 236: > >> 234: assertEqualsFIXME(messageOrNull, iae.getMessage()); >> 235: return; >> 236: } > > Could you split this into separate positive and negative tests, with separate sources? Done. > test/jdk/java/lang/invoke/MethodHandles/TestDropReturn.java line 40: > >> 38: import org.junit.jupiter.params.provider.MethodSource; >> 39: >> 40: @TestInstance(TestInstance.Lifecycle.PER_CLASS) > > Why is this annotation needed here? There's only one test method. Reviewed `@TestInstance`, now only exists on VarHandle tests which are harder to restructure. > test/jdk/java/lang/invoke/condy/CondyBSMInvocation.java line 241: > >> 239: var e = Assertions.assertThrows(BootstrapMethodError.class, mh::invoke); >> 240: Throwable t = e.getCause(); >> 241: Assertions.assertTrue(WrongMethodTypeException.class.isAssignableFrom(t.getClass())); > > Suggestion: > > assertInstanceOf(WrongMethodTypeException.class, e.getCause()); Migrated some possible sites to use assertInstanceOf. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710458166 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710457928 PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710456940 From sparasa at openjdk.org Wed Jan 21 00:04:30 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Wed, 21 Jan 2026 00:04:30 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Mon, 19 Jan 2026 08:11:19 GMT, Emanuel Peter wrote: > Can you explain the difference between the two results? > Hi Emanuel (@eme64), Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). Pasting the relevant text below for reference: 18.4 FORWARDING AND MEMORY MASKING When using masked store and load, consider the following: ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation from the same address is blocked, until the data is written to the cache. ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless load and store addresses are exactly the same. ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load operation. ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no In summary, a masked store should be used carefully, for example, if the remainder size is known at compile time to be 1, and there is a load operation from the same cache line after it (or there is an overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than a masked remainder block. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3775508253 From liach at openjdk.org Wed Jan 21 00:04:31 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 00:04:31 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. I think we should wait for an in-area reviewer to verify the logic and the test again. Both Claes and I are more performance oriented and focused mostly on the Java code instead of the business logic. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3775505298 From smarks at openjdk.org Wed Jan 21 01:16:18 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:18 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: <16L6cSilYiC8tbhpmKW2g3X19hE5-A0jHERAtsCJ9S4=.3211d9ae-c184-4ec9-823f-43b77fd49d68@github.com> On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29332#pullrequestreview-3684928489 From smarks at openjdk.org Wed Jan 21 01:16:22 2026 From: smarks at openjdk.org (Stuart Marks) Date: Wed, 21 Jan 2026 01:16:22 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. The changes in this PR match the list of approved changes for this release. ------------- Marked as reviewed by smarks (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29331#pullrequestreview-3684928880 From bchristi at openjdk.org Wed Jan 21 01:33:46 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:46 GMT Subject: [jdk26] RFR: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 [v2] In-Reply-To: References: Message-ID: > This brings in cpu26_01 changes. 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29332/files - new: https://git.openjdk.org/jdk/pull/29332/files/4b0189c4..4b0189c4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29332&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29332.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29332/head:pull/29332 PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:33:48 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:33:48 GMT Subject: [jdk26] Integrated: Merge 4b0189c444a061f4e1e4dd27e7980ebb81252284 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:26:03 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: 7ac780da Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/7ac780da7b98d1a44effc86e75b62a1bedc7954b Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29332 From bchristi at openjdk.org Wed Jan 21 01:34:06 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:06 GMT Subject: RFR: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 [v2] In-Reply-To: References: Message-ID: <_R8gyRrfwT8U_cL4_T9ImlWVN5Q3zLKoa61ZVBXQP5E=.8fbf5d4d-4be3-46a9-94c2-b14c0ddef43d@github.com> > This brings in cpu26_01 changes. 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. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29331/files - new: https://git.openjdk.org/jdk/pull/29331/files/07f981f6..07f981f6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29331&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29331.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29331/head:pull/29331 PR: https://git.openjdk.org/jdk/pull/29331 From bchristi at openjdk.org Wed Jan 21 01:34:09 2026 From: bchristi at openjdk.org (Brent Christian) Date: Wed, 21 Jan 2026 01:34:09 GMT Subject: Integrated: Merge 07f981f6b0bb8a7e444fd744791f73853e9fa325 In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:23:53 GMT, Brent Christian wrote: > This brings in cpu26_01 changes. This pull request has now been integrated. Changeset: e25a5a48 Author: Brent Christian URL: https://git.openjdk.org/jdk/commit/e25a5a4821d03680d00ab6bdbec727732add8206 Stats: 1268 lines in 37 files changed: 965 ins; 148 del; 155 mod Merge Reviewed-by: kcr, prr, smarks ------------- PR: https://git.openjdk.org/jdk/pull/29331 From jvernee at openjdk.org Wed Jan 21 01:50:34 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Wed, 21 Jan 2026 01:50:34 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v2] In-Reply-To: <6b4oVAcgwlVTxJ4W9FGh0XDYS3MOVObzmNeod6HmkVI=.078d925c-bb0f-4ea4-94c1-354f4ca0bb27@github.com> References: <5h4w8k7dWQ0IANHOwctFhCjafdtE4nJZs31mgB_8gRA=.863c0832-b41c-49ea-a43c-eedf1778891c@github.com> <6b4oVAcgwlVTxJ4W9FGh0XDYS3MOVObzmNeod6HmkVI=.078d925c-bb0f-4ea4-94c1-354f4ca0bb27@github.com> Message-ID: On Tue, 20 Jan 2026 23:00:02 GMT, Chen Liang wrote: >> test/jdk/java/lang/invoke/DefineClassTest.java line 211: >> >>> 209: >>> 210: Class clazz = lookup.defineClass(generateClass("java.lang.Foo")); >>> 211: assertEquals("java.lang.Foo", clazz.getName()); >> >> Looks like the parameter order was already reversed here. > > No? I think my new order is right that the "actual" should be the value from reflection. Huh yeah. Maybe I put this in the wrong place. Nvm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2710661444 From syan at openjdk.org Wed Jan 21 02:01:30 2026 From: syan at openjdk.org (SendaoYan) Date: Wed, 21 Jan 2026 02:01:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 16:57:26 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year LGTM ------------- Marked as reviewed by syan (Committer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3685013389 From duke at openjdk.org Wed Jan 21 03:02:33 2026 From: duke at openjdk.org (He-Pin (kerr)) Date: Wed, 21 Jan 2026 03:02:33 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: References: Message-ID: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> On Tue, 4 Nov 2025 21:28:14 GMT, Patricio Chilano Mateo wrote: >> If a thread tries to initialize a class that is already being initialized by another thread, it will block until notified. Since at this blocking point there are native frames on the stack, a virtual thread cannot be unmounted and is pinned to its carrier. Besides harming scalability, this can, in some pathological cases, lead to a deadlock, for example, if the thread executing the class initialization method is blocked waiting for some unmounted virtual thread to run, but all carriers are blocked waiting for that class to be initialized. >> >> As of JDK-8338383, virtual threads blocked in the VM on `ObjectMonitor` operations can be unmounted. Since synchronization on class initialization is implemented using `ObjectLocker`, we can reuse the same mechanism to unmount virtual threads on these cases too. >> >> This patch adds support for unmounting virtual threads on some of the most common class initialization paths, specifically when calling `InterpreterRuntime::_new` (`new` bytecode), and `InterpreterRuntime::resolve_from_cache` for `invokestatic`, `getstatic` or `putstatic` bytecodes. In the future we might consider extending this mechanism to include initialization calls originating from native methods such as `Class.forName0`. >> >> ### Summary of implementation >> >> The ObjectLocker class was modified to not pin the continuation if we are coming from a preemptable path, which will be the case when calling `InstanceKlass::initialize_impl` from new method `InstanceKlass::initialize_preemptable`. This means that for these cases, a virtual thread can now be unmounted either when contending for the init_lock in the `ObjectLocker` constructor, or in the call to `wait_uninterruptibly`. Also, since the call to initialize a class includes a previous call to `link_class` which also uses `ObjectLocker` to protect concurrent calls from multiple threads, we will allow preemption there too. >> >> If preempted, we will throw a pre-allocated exception which will get propagated with the `TRAPS/CHECK` macros all the way back to the VM entry point. The exception will be cleared and on return back to Java the virtual thread will go through the preempt stub and unmount. When running again, at the end of the thaw call we will identify this preemption case and redo the original VM call (either `InterpreterRuntime::_new` or `InterpreterRuntime::resolve_from_cache`). >> >> ### Notes >> >> `InterpreterRuntime::call_VM_preemptable` used previously only for `InterpreterRuntime::mon... > > Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 22 commits: > > - Add check for SingleStep events > - Merge branch 'master' into JDK-8369238 > - fix to JvmtiHideSingleStepping > - Suggested fix in macroAssembler_ppc.cpp > - Improve comment and assert msg > - More fixes from David's comments > - Merge branch 'master' into JDK-8369238 > - add const to references > - Improve comment in anchor_mark_set_pd > - More comments from Coleen > - ... and 12 more: https://git.openjdk.org/jdk/compare/2f455ed1...06f85198 Will this be backported to Java 25 LTS? ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3775903843 From dholmes at openjdk.org Wed Jan 21 05:13:22 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 05:13:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> On Tue, 20 Jan 2026 22:38:26 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: > >> 1: /* >> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. > > nit: needs to keep 2025 Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2710989942 From david.holmes at oracle.com Wed Jan 21 05:38:13 2026 From: david.holmes at oracle.com (David Holmes) Date: Wed, 21 Jan 2026 15:38:13 +1000 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> Message-ID: On 19/01/2026 8:16 pm, Eirik Bj?rsn?s wrote: > David, > > On Sun, Jan 18, 2026 at 11:04?PM David Holmes > wrote: > > You would lose potentially important information when reporting > monitors > owned by a thread. > > > I get that the class name may be useful for diagnostic purposes. > > However, the new Object() idiom has several thousand occurrences across > the JDK, while new Lock() revealed only these two (plus a few in tests). > > These Lock classes seem like an easy win in the effort?to trim the list > of JDK class loading during startup/shutdown. > > Do you feel that the diagnostic value added by using named classes for > these two instances outweighs the benefit of trimming class loading > during startup? No I suppose not. Though I'm not sure trimming the class will make any observable/practical difference in the normal case. > Also I think Valhalla is trying to dissuade/move-away-from using > "new Object()". > > > Hmm.. The alternative solution cannot be to introduce custom Lock > classes everywhere, right? I couldn't recall the exact proposal, but no. From https://github.com/openjdk/valhalla-docs/blob/main/site/design-notes/state-of-valhalla/02-object-model.md "The root class Object poses an unusual problem, in that every class must extend it directly or indirectly, but it itself is (currently) an identity class, and it is common to use new Object() as a way to obtain a new object identity for purposes of locking. If Object were to implement IdentityObject, then primitive classes could not extend Object (and therefore could not interoperate with dynamically typed libraries such as reflection). We address this problem by treating Object like we do interfaces and certain abstract classes -- they can be extended by both identity and primitive classes -- but redefine the idiom new Object() to evaluate to a fresh instance of an anonymous identity subclass of Object." So effectively this is like declaring a single global class that all "new Object()'s" would be instances of. So using new Object() will not be a problem. Cheers, David ----- > > Thanks, > Eirik. From eirbjo at openjdk.org Wed Jan 21 05:50:45 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 21 Jan 2026 05:50:45 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. I'll wait for Jai or others who have visited this class in the past. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3776308166 From eirbjo at gmail.com Wed Jan 21 06:28:22 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Wed, 21 Jan 2026 07:28:22 +0100 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> Message-ID: On Wed, Jan 21, 2026 at 6:38?AM David Holmes wrote: > No I suppose not. Though I'm not sure trimming the class will make any > observable/practical difference in the normal case. > Thanks! I agree trimming these two classes (of ~428 loaded at startup) alone has limited value. But there are other berries to pick and the cumulative impact may have an observable effect on startup. Two berries feed no one, with a handful we can make a delicious jam :) So effectively this is like declaring a single global class that all > "new Object()'s" would be instances of. > > So using new Object() will not be a problem. > Thanks for the Valhalla reference, interesting to see how "new Object()" can be redefined like this. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Wed Jan 21 07:04:04 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 21 Jan 2026 07:04:04 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Fri, 19 Dec 2025 07:01:31 GMT, Emanuel Peter wrote: >> 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 :) Hi @eme64 , Your comments have been addressed ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3776496085 From epeter at openjdk.org Wed Jan 21 08:19:11 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 08:19:11 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: <2lC9m4MZczFpH42mQwumfMaj4Btkl5vgE4kGq4353Qk=.afdf8f74-7491-4b3a-b7e9-4b9904eeb1fd@github.com> On Wed, 21 Jan 2026 00:01:39 GMT, Srinivas Vamsi Parasa wrote: >> @vamsi-parasa Thanks for the extra data! >> >> Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. >> >> Can you explain the difference between the two results? > >> Can you explain the difference between the two results? >> > Hi Emanuel (@eme64), > Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. > > This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). > > Pasting the relevant text below for reference: > > > 18.4 FORWARDING AND MEMORY MASKING > When using masked store and load, consider the following: > ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation > from the same address is blocked, until the data is written to the cache. > ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless > load and store addresses are exactly the same. > ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes > ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes > ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load > operation. > ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no > ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. > ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no > In summary, a masked store should be used carefully, for example, if the remainder size is known at > compile time to be 1, and there is a load operation from the same cache line after it (or there is an > overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than > a masked remainder block. > > > Thanks, > Vamsi @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? It seems that without loads https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799, this patch leads to a regression. Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3776741440 From sgehwolf at openjdk.org Wed Jan 21 09:07:51 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 09:07:51 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 05:10:15 GMT, David Holmes wrote: >> test/jdk/jdk/internal/platform/docker/TestDockerMemoryMetricsSubgroup.java line 2: >> >>> 1: /* >>> 2: * Copyright (c) 2026, BELLSOFT. All rights reserved. >> >> nit: needs to keep 2025 > > Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711604932 From epeter at openjdk.org Wed Jan 21 09:27:09 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:09 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v13] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3777034545 From epeter at openjdk.org Wed Jan 21 09:27:12 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Wed, 21 Jan 2026 09:27:12 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v12] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 11:51:20 GMT, Jatin Bhateja wrote: >> test/jdk/jdk/incubator/vector/IntVectorMaxTests.java line 68: >> >>> 66: static IntVector bcast_vec = IntVector.broadcast(SPECIES, (int)10); >>> 67: >>> 68: static void AssertEquals(int actual, int expected) { >> >> There are lots of changes in this file that do not seem to have anything to do with Float16. Please file them separately. It will make review much easier. > > I have added an assertion wrapper so that float16 values (short) can be converted to float before calling actual Assert.* routines to handle all possible NaN bit patterns. Since the tests are generate from common template hence these changes appear. Can we not do those changes in a separate change, please? It will make it easier to review the rest of the PR. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28002#discussion_r2711675095 From redestad at openjdk.org Wed Jan 21 09:30:22 2026 From: redestad at openjdk.org (Claes Redestad) Date: Wed, 21 Jan 2026 09:30:22 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. FWIW `ArrayDeque` is likely to be loaded early regardless of these changes. I ran this through some of our startup tests and noticed that in the typical case we're net neutral and are just shifting the point of load from URLClassPath to ZipFile.CleanableResource. You might see a reduction on tests that load and run only classes which are not packed into jar files. Still, I think it's useful to reduce the complexity of the class load graph in the earliest loaded classes. Any step in that direction removes trip-wires and hazards for the primordial setup. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3777051399 From erfang at openjdk.org Wed Jan 21 09:42:13 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 21 Jan 2026 09:42:13 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: References: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> Message-ID: On Tue, 20 Jan 2026 19:23:38 GMT, Andrew Haley wrote: > I'm sorry, I _completely_ overthought that one. All you need are definitions for `min[vp]` and `max[vp]` in C2_Macroassembler. > > Like so: > > `void minv(bool is_unsigned, ...) { if (is_unsigned) { uminv(... } else { sminv(... } }` > > No need to mess with class `Assembler`. Make sense, I'll do the modification in next commit soon, thanks for your review! @theRealAph ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3777104550 From alanb at openjdk.org Wed Jan 21 09:46:03 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 09:46:03 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 20:46:04 GMT, Patricio Chilano Mateo wrote: >> Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. >> >> The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. >> >> The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. >> >> Thanks, >> Patricio > > Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision: > > Randomly choose platform or virtual notifier Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29255#pullrequestreview-3686247862 From jpai at openjdk.org Wed Jan 21 09:46:04 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Wed, 21 Jan 2026 09:46:04 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Hello Eirik, > Channeling @jaikiran and Code Historian @Martin-Buchholz who was the one to introduce ArrayDeque in this code. I will take a look shortly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3777120618 From sgehwolf at openjdk.org Wed Jan 21 10:05:30 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:30 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: Restore Bellsoft copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/9f93451f..e539a64f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Wed Jan 21 10:05:31 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 10:05:31 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 09:03:25 GMT, Severin Gehwolf wrote: >> Unless you are a contributor for Bellsoft, or are directed to update this by one of their contributors, you should not update their copyright notice. > > OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2711832957 From erfang at openjdk.org Wed Jan 21 10:15:27 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 21 Jan 2026 10:15:27 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v2] In-Reply-To: References: <3HfqoF6XNWDXq8P95PQ78B1_QquFMPDTkcuXPbmybNs=.cc8fd652-9949-4a0d-bf18-76cad5aac332@github.com> Message-ID: On Tue, 20 Jan 2026 19:23:38 GMT, Andrew Haley 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: >> >> - Rebase commit 56d7b52 >> - Merge branch 'master' into JDK-8372980-umin-umax-intrinsic >> - 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations >> >> 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 >> Long64V... > > I'm sorry, I _completely_ overthought that one. All you need are definitions for `min[vp]` and `max[vp]` in C2_Macroassembler. > > Like so: > > `void minv(bool is_unsigned, ...) { if (is_unsigned) { uminv(... } else { sminv(... } }` > > No need to mess with class `Assembler`. @theRealAph I have made the change, please help take another look, thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3777257496 From erfang at openjdk.org Wed Jan 21 10:15:24 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 21 Jan 2026 10:15:24 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: 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 > Sh... Eric Fang has updated the pull request incrementally with one additional commit since the last revision: Extract some helper functions for better readability ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28693/files - new: https://git.openjdk.org/jdk/pull/28693/files/481c3ee6..fc3dee3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=01-02 Stats: 120 lines in 2 files changed: 95 ins; 10 del; 15 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 eirbjo at openjdk.org Wed Jan 21 10:22:07 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 21 Jan 2026 10:22:07 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Use "list" instead of "queue" when referring to expandedPath which is processed FIFO and as such is not a queue ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29288/files - new: https://git.openjdk.org/jdk/pull/29288/files/6d21f049..d7962442 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=00-01 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29288/head:pull/29288 PR: https://git.openjdk.org/jdk/pull/29288 From eirbjo at openjdk.org Wed Jan 21 10:22:09 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 21 Jan 2026 10:22:09 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. The `expandedPath` is processed in FIFO order, so technically it's a stack. Referring to it as a "queue" in comments may be confusing. I changed "queue" to just "list" in the two comments. I pondered "stack" but decided against it to avoid any confusion with `j.u.Stack`. It's a list, processed as a stack. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3777285552 From eirbjo at openjdk.org Wed Jan 21 11:26:56 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 21 Jan 2026 11:26:56 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: <_8RgrqBRjfH1aAyYW2Y4RLSNFzMF5L_R8HGmU_AjV5k=.ddb66de6-32b9-42c9-ba9f-be50ad50fbdb@github.com> On Wed, 21 Jan 2026 09:26:31 GMT, Claes Redestad wrote: > [..] are just shifting the point of load from URLClassPath to ZipFile.CleanableResource. Thanks for the analysis! At first look that `inflaterCache` seems not particularly order sensitive ("give me a deflater, any will do"). In fact in the past this used `j.util.Stack`. I may take a look at this as a follow up. The change to `ArrayDeque` may have been motivated more by synchronization concerns. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3777561534 From dholmes at openjdk.org Wed Jan 21 12:19:29 2026 From: dholmes at openjdk.org (David Holmes) Date: Wed, 21 Jan 2026 12:19:29 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 10:00:15 GMT, Severin Gehwolf wrote: >> OK, I'll revert this. Never sure when to update it and when not, sorry. I'm also not an Oracle contributor, fwiw. > > Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > I'm also not an Oracle contributor, fwiw. We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712314104 From sgehwolf at openjdk.org Wed Jan 21 12:53:40 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Wed, 21 Jan 2026 12:53:40 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> <7PzkOQIdWnBjGiJtl4XLc7NKRQiicHUFuJPvQvbo5Ds=.e952afeb-b46f-4ee0-a01b-e0af4badb7fe@github.com> Message-ID: On Wed, 21 Jan 2026 12:16:17 GMT, David Holmes wrote: >> Fixed in https://github.com/openjdk/jdk/pull/29315/commits/e539a64f46300c01a03cca5438373022aabcc535 > >> I'm also not an Oracle contributor, fwiw. > > We specifically request that all contributors update any Oracle copyright in a file they modify. Thanks OK. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29315#discussion_r2712437275 From aph at openjdk.org Wed Jan 21 14:15:24 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 21 Jan 2026 14:15:24 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:15:24 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 >> ... > > Eric Fang has updated the pull request incrementally with one additional commit since the last revision: > > Extract some helper functions for better readability src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1965: > 1963: // Helper function to decode min/max reduction operation properties > 1964: static void decode_minmax_reduction_opc(int opc, bool& is_min, bool& is_unsigned, > 1965: Assembler::Condition& cond) { Suggestion: Condition cond) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2712746847 From liach at openjdk.org Wed Jan 21 16:35:14 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 16:35:14 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont wrote: > Allow replacement string to contain embedded newlines to split entries. > This turns output like: > > > > ... another 10k chars on the end of this line ... > > > into: > > > > > > ... one entry per line ... In addition, I see extra spaces presumably for indent after the `\n` - are we sure the number of spaces is correct? Is there a reason we don't need this indent for the 1st line? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3779447248 From dl at openjdk.org Wed Jan 21 16:35:41 2026 From: dl at openjdk.org (Doug Lea) Date: Wed, 21 Jan 2026 16:35:41 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v28] 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: Try out different approach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/a1e5ce94..02ddb13d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=27 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=26-27 Stats: 204 lines in 1 file changed: 79 ins; 75 del; 50 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 jlahoda at openjdk.org Wed Jan 21 16:40:56 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Wed, 21 Jan 2026 16:40:56 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit Message-ID: This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. Thanks! ------------- Depends on: https://git.openjdk.org/jdk/pull/29202 Commit messages: - Removing wrong @Test annotation. - Using assertThrows instead of manual try-catch. - 8375712: Convert java/lang/runtime tests to use JUnit Changes: https://git.openjdk.org/jdk/pull/29350/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29350&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375712 Stats: 220 lines in 3 files changed: 36 ins; 77 del; 107 mod Patch: https://git.openjdk.org/jdk/pull/29350.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29350/head:pull/29350 PR: https://git.openjdk.org/jdk/pull/29350 From azeller at openjdk.org Wed Jan 21 17:08:31 2026 From: azeller at openjdk.org (Arno Zeller) Date: Wed, 21 Jan 2026 17:08:31 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows Message-ID: It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. This change will add the message again to the allowed messages. ------------- Commit messages: - Re-add old message. Changes: https://git.openjdk.org/jdk/pull/29348/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29348&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375999 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29348.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29348/head:pull/29348 PR: https://git.openjdk.org/jdk/pull/29348 From hgreule at openjdk.org Wed Jan 21 18:50:44 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 21 Jan 2026 18:50:44 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:36:33 GMT, Hannes Greule wrote: > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. Sorry for the delay. @jddarcy already approved the CSR, can I still apply @rose00's suggestion? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3780591538 From dnguyen at openjdk.org Wed Jan 21 18:53:08 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 21 Jan 2026 18:53:08 GMT Subject: Integrated: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 22:25:51 GMT, Damon Nguyen wrote: > Open l10n drop. Files have been updated with translated versions. > > There are no new changes from RDP1 to RDP2. The changes here are updates from the translation team regarding our suggested fixes from review comments in the RDP1 drop. This pull request has now been integrated. Changeset: a0ac5b34 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod 8375775: JDK 26 RDP2 L10n resource files update Reviewed-by: naoto, jlu, liach ------------- PR: https://git.openjdk.org/jdk/pull/29334 From darcy at openjdk.org Wed Jan 21 18:55:56 2026 From: darcy at openjdk.org (Joe Darcy) Date: Wed, 21 Jan 2026 18:55:56 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:48:29 GMT, Hannes Greule wrote: > Sorry for the delay. @jddarcy already approved the CSR, can I still apply @rose00's suggestion? If the update changes the semantics compared to the Approved CSR, the CSR should be withdrawn, updated, and re-Finalized so the final version can be Approved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3780624515 From mcimadamore at openjdk.org Wed Jan 21 19:02:10 2026 From: mcimadamore at openjdk.org (Maurizio Cimadamore) Date: Wed, 21 Jan 2026 19:02:10 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Thu, 15 Jan 2026 23:07:47 GMT, Martin Doerr wrote: >> I don't have the expertise to confirm the correctness of that code change. @mcimadamore, are you comfortable to include the patch for PPC64 as described in https://github.com/openjdk/jdk/pull/28931#discussion_r2662361633? > > For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs` for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions). I believe the proposed patch to be reasonable given the limitations we already covered. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2713938064 From henryjen at openjdk.org Wed Jan 21 19:08:51 2026 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 21 Jan 2026 19:08:51 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c Message-ID: Fix dangling pointers. ------------- Commit messages: - 8373928: 4 Dangling pointer defect groups in java.c Changes: https://git.openjdk.org/jdk/pull/29351/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29351&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373928 Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29351/head:pull/29351 PR: https://git.openjdk.org/jdk/pull/29351 From dnguyen at openjdk.org Wed Jan 21 19:13:07 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 21 Jan 2026 19:13:07 GMT Subject: [jdk26] RFR: 8375775: JDK 26 RDP2 L10n resource files update Message-ID: Hi all, This pull request contains a backport of commit [a0ac5b34](https://github.com/openjdk/jdk/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. The commit being backported was authored by Damon Nguyen on 21 Jan 2026 and was reviewed by Naoto Sato, Justin Lu and Chen Liang. Thanks! ------------- Commit messages: - Backport a0ac5b34a742cf18d86f3ac77110bcaa00192169 Changes: https://git.openjdk.org/jdk/pull/29352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375775 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29352/head:pull/29352 PR: https://git.openjdk.org/jdk/pull/29352 From jlu at openjdk.org Wed Jan 21 19:13:07 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 21 Jan 2026 19:13:07 GMT Subject: [jdk26] RFR: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <4Se8e-3qM4j_Yfdsg4Pea_GVj1R9cLXtamIL3B-2XT0=.12922dde-0cb6-4362-a7f2-897e755199bc@github.com> On Wed, 21 Jan 2026 19:01:20 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [a0ac5b34](https://github.com/openjdk/jdk/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 21 Jan 2026 and was reviewed by Naoto Sato, Justin Lu and Chen Liang. > > Thanks! Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29352#pullrequestreview-3688943235 From naoto at openjdk.org Wed Jan 21 19:16:23 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 21 Jan 2026 19:16:23 GMT Subject: [jdk26] RFR: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:01:20 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [a0ac5b34](https://github.com/openjdk/jdk/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 21 Jan 2026 and was reviewed by Naoto Sato, Justin Lu and Chen Liang. > > Thanks! Marked as reviewed by naoto (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29352#pullrequestreview-3688972203 From dnguyen at openjdk.org Wed Jan 21 19:20:59 2026 From: dnguyen at openjdk.org (Damon Nguyen) Date: Wed, 21 Jan 2026 19:20:59 GMT Subject: [jdk26] Integrated: 8375775: JDK 26 RDP2 L10n resource files update In-Reply-To: References: Message-ID: <4n79Bekp-39eZufjmvrBfOFP1sZ3hZy1n-uw5OaKGaI=.c9893213-2bae-426f-aad1-24b03868711a@github.com> On Wed, 21 Jan 2026 19:01:20 GMT, Damon Nguyen wrote: > Hi all, > > This pull request contains a backport of commit [a0ac5b34](https://github.com/openjdk/jdk/commit/a0ac5b34a742cf18d86f3ac77110bcaa00192169) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository. > > The commit being backported was authored by Damon Nguyen on 21 Jan 2026 and was reviewed by Naoto Sato, Justin Lu and Chen Liang. > > Thanks! This pull request has now been integrated. Changeset: fb6e53e3 Author: Damon Nguyen URL: https://git.openjdk.org/jdk/commit/fb6e53e371094ffbeffeeb9fcbda6aecc5ddaff3 Stats: 6 lines in 6 files changed: 0 ins; 0 del; 6 mod 8375775: JDK 26 RDP2 L10n resource files update Reviewed-by: jlu, naoto Backport-of: a0ac5b34a742cf18d86f3ac77110bcaa00192169 ------------- PR: https://git.openjdk.org/jdk/pull/29352 From weijun at openjdk.org Wed Jan 21 19:23:18 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jan 2026 19:23:18 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v9] In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: > Rewrite the native calls with FFM. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: adding TheRealMDoerr's workaround ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28931/files - new: https://git.openjdk.org/jdk/pull/28931/files/bf91106e..99604e06 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=07-08 Stats: 22 lines in 1 file changed: 18 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/28931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931 PR: https://git.openjdk.org/jdk/pull/28931 From weijun at openjdk.org Wed Jan 21 19:23:20 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jan 2026 19:23:20 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v2] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Tue, 30 Dec 2025 23:00:31 GMT, Martin Doerr wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> rewrite without jextract > > I've made some AIX experiments. Hi @TheRealMDoerr, I've included your workaround. Please try it on your systems. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780725018 From mdoerr at openjdk.org Wed Jan 21 19:23:21 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 21 Jan 2026 19:23:21 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v5] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <1zimwcMvh0RAYy4g7ekntYTORI9Fk5SZfct4CxYNOe0=.a1c9206f-f803-45ed-8439-d14a9ef0cbe9@github.com> <-ud9JT6vDLtnNNHMWobII8uwzdUTeFIm-lYRgvBZdJc=.7a34bec3-9e26-4101-ad49-b5a92eda69e1@github.com> <_PjK5bl-VUU_vwlgy--DRC_lsMIAqQSG5B4LssuQ_mc=.0fb1a5b0-8ffa-4a8e-8671-4054857bd944@github.com> <7LXmvTgwvdUmN39G0X8mQD1lHvca22pca2Gz-rL9pM8=.a1e2baec-3258-4059-8a57-136a1db4f4b4@github.com> Message-ID: On Wed, 21 Jan 2026 18:59:19 GMT, Maurizio Cimadamore wrote: >> For reference: hotspot uses the platform dependent constant `CCallingConventionRequiresIntsAsLongs` for such issues. The value is `true` on PPC64 and s390 platforms (and SPARC in earlier JDK versions). > > I believe the proposed patch to be reasonable given the limitations we already covered. It would be nice to add a comment like: We need to pass the uid as uint32_t which requires zero extension on some 64-bit platforms. JDK-8336664 is not yet available, so we extend it here for these platforms. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714007305 From mdoerr at openjdk.org Wed Jan 21 19:25:10 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 21 Jan 2026 19:25:10 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v8] In-Reply-To: <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <2U0qnmve5UdJf4slhHCAV9mneIXDemtJECjANwbdc7c=.2daad3fd-5029-47f2-acbe-d0eeb830a6e2@github.com> Message-ID: On Tue, 13 Jan 2026 21:17:13 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > new naming style; use VarHandle to access fields Ah, you already added a comment referring to JDK-8336664. Looks good! Thanks a lot for taking care of it! We'll run tests. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28931#issuecomment-3780744019 From hgreule at openjdk.org Wed Jan 21 19:25:30 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 21 Jan 2026 19:25:30 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: References: Message-ID: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: update according John's suggestion ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29174/files - new: https://git.openjdk.org/jdk/pull/29174/files/a9af7fea..7889ae2e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29174&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29174&range=00-01 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29174.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29174/head:pull/29174 PR: https://git.openjdk.org/jdk/pull/29174 From hgreule at openjdk.org Wed Jan 21 19:25:32 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 21 Jan 2026 19:25:32 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: <1RYJnM9qzW0B5vB5egQ0FM7kYTjEOw2iTfDHL25DbXQ=.9be75e5b-87bc-43b8-8c7f-dc5b984b7045@github.com> On Wed, 21 Jan 2026 18:53:08 GMT, Joe Darcy wrote: > If the update changes the semantics compared to the Approved CSR, the CSR should be withdrawn, updated, and re-Finalized so the final version can be Approved. Thanks, the semantics remain the same. I updated this PR to include the suggestion. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3780731970 From alanb at openjdk.org Wed Jan 21 19:31:29 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 21 Jan 2026 19:31:29 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:58:00 GMT, Henry Jen wrote: > Fix dangling pointers. The changes look okay. Do you want to do the same for image_data in ShowSplashScreen. This is first change to the launcher code in 2026 so you'll need to bump the copyright header. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29351#issuecomment-3780766819 From weijun at openjdk.org Wed Jan 21 19:39:49 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jan 2026 19:39:49 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: > Rewrite the native calls with FFM. Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: unnecessary initialization ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28931/files - new: https://git.openjdk.org/jdk/pull/28931/files/99604e06..0aec40c0 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28931&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28931.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28931/head:pull/28931 PR: https://git.openjdk.org/jdk/pull/28931 From bpb at openjdk.org Wed Jan 21 19:43:23 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Wed, 21 Jan 2026 19:43:23 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c In-Reply-To: References: Message-ID: <5-9f2H2Cq3A054pcmlyMA40EADOgGY93pBMIufTNkZ8=.0064acc4-c05a-4780-8b4e-d91be7df6e13@github.com> On Wed, 21 Jan 2026 18:58:00 GMT, Henry Jen wrote: > Fix dangling pointers. Not in my area but the changes look fine. Does the copyright year need to change? ------------- PR Review: https://git.openjdk.org/jdk/pull/29351#pullrequestreview-3689063052 From liach at openjdk.org Wed Jan 21 19:50:20 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 19:50:20 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:32:06 GMT, Jan Lahoda wrote: > This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. > > Thanks! test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 52: > 50: public class ExactnessConversionsSupportTest { > 51: > 52: public void main(String[] args) { Let's remove this main method altogether. test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 38: > 36: import java.lang.classfile.ClassFile; > 37: > 38: import org.junit.jupiter.api.Assertions; Let's use static imports and remove this import. test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 407: > 405: @Test > 406: public void testNullLookup() throws Throwable { > 407: Assertions.assertThrows(NullPointerException.class, () -> { Can use the static import version instead of fully qualifying here ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714076232 PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714088718 PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714087494 From duke at openjdk.org Wed Jan 21 20:03:07 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Wed, 21 Jan 2026 20:03:07 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:32:06 GMT, Jan Lahoda wrote: > This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. > > Thanks! test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 64: > 62: @Test > 63: public void testByte() { > 64: assertEquals(true, ExactConversionsSupport.isIntToByteExact((byte) (Byte.MAX_VALUE))); could be shortened to assertTrue(Exact...)`` test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 161: > 159: testEnum(E1.B, 1, 3, "B", "C", "A", E1.class); > 160: assertThrows(IllegalArgumentException.class, () -> > 161: testEnum(E1.B, 0, -1, E2.class) for readability it could be worth to add a helper method `testEnumError(Class exceptionClass, Enum target, int start, int result, Object... labels)` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714105478 PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714126640 From liach at openjdk.org Wed Jan 21 20:09:54 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:09:54 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:59:14 GMT, Johannes D?bler wrote: >> This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. >> >> Thanks! > > test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 161: > >> 159: testEnum(E1.B, 1, 3, "B", "C", "A", E1.class); >> 160: assertThrows(IllegalArgumentException.class, () -> >> 161: testEnum(E1.B, 0, -1, E2.class) > > for readability it could be worth to add a helper method > `testEnumError(Class exceptionClass, Enum target, int start, int result, Object... labels)` The `start` and `result` arguments here are completely unused. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2714149186 From liach at openjdk.org Wed Jan 21 20:13:14 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:13:14 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: On Wed, 21 Jan 2026 19:25:30 GMT, Hannes Greule wrote: >> A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > update according John's suggestion Let's turn the CSR back to draft, edit it, and you can then re-finalize it. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29174#pullrequestreview-3689188346 From hgreule at openjdk.org Wed Jan 21 20:21:33 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Wed, 21 Jan 2026 20:21:33 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: <9S4690JFgTdOJberEOMy5bVroa62kG4PYDqM2mbcFCs=.74db1ad8-0e31-4c72-bc90-5bf6877e23c8@github.com> On Wed, 21 Jan 2026 20:10:42 GMT, Chen Liang wrote: > Let's turn the CSR back to draft, edit it, and you can then re-finalize it. @liach, sorry, I'm confused now. Given @jddarcy's comment, I assumed this change is fine and does not need a reapproval. Do you think otherwise? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3780975725 From liach at openjdk.org Wed Jan 21 20:24:48 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 21 Jan 2026 20:24:48 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: On Wed, 21 Jan 2026 19:25:30 GMT, Hannes Greule wrote: >> A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > update according John's suggestion This does need a re-approval. The process of re-approval is that a Closed-Approved CSR can be reverted back to Draft, and once you finish your minor edits you can immediately Finalize the CSR for re-approval. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3780989296 From mdoerr at openjdk.org Wed Jan 21 20:32:14 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 21 Jan 2026 20:32:14 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary initialization The test has passed on linux PPC64le and AIX. @offamitkumar: Do you want to run the test on s390? I think it's good. The JBS issue says "See if it's a better alternative of JNI." Is there any comparison or evaluation planned? src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118: > 116: = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow( > 117: OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), > 118: FunctionDescriptor.of(C_INT, Indentation could be improved, here. ------------- PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689250234 PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714211087 From weijun at openjdk.org Wed Jan 21 21:04:40 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jan 2026 21:04:40 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com> On Wed, 21 Jan 2026 20:23:25 GMT, Martin Doerr wrote: >> Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: >> >> unnecessary initialization > > src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118: > >> 116: = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow( >> 117: OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), >> 118: FunctionDescriptor.of(C_INT, > > Indentation could be improved, here. Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I don't think that's correct. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714326021 From weijun at openjdk.org Wed Jan 21 21:13:58 2026 From: weijun at openjdk.org (Weijun Wang) Date: Wed, 21 Jan 2026 21:13:58 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com> Message-ID: On Wed, 21 Jan 2026 21:01:30 GMT, Weijun Wang wrote: >> src/jdk.security.auth/share/classes/com/sun/security/auth/module/UnixSystem.java line 118: >> >>> 116: = LINKER.downcallHandle(SYMBOL_LOOKUP.findOrThrow( >>> 117: OperatingSystem.isAix() ? "_posix_getpwuid_r" : "getpwuid_r"), >>> 118: FunctionDescriptor.of(C_INT, >> >> Indentation could be improved, here. > > Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading. As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714356450 From mdoerr at openjdk.org Wed Jan 21 21:32:11 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 21 Jan 2026 21:32:11 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: <7sNwX027pt2Pc7AHHZ9xBcTQe34A4UOAZwKGQZv1sZw=.a71ed3a2-d75d-4a2b-8f7b-7ebd8a5677a4@github.com> On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary initialization Marked as reviewed by mdoerr (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3689482675 From mdoerr at openjdk.org Wed Jan 21 21:32:12 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Wed, 21 Jan 2026 21:32:12 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> <14xLBqYrM9A7yRkPrXX2w23d3rBrjx02pZdwTzrte9Y=.aef64278-f25e-4c0c-a38e-de1f4b0b0e6e@github.com> Message-ID: On Wed, 21 Jan 2026 21:11:28 GMT, Weijun Wang wrote: >> Do you have a suggestion? I intentionally indented based on argument nesting. `FunctionDescriptor.of(...` is the 2nd argument of `downcallHandle` so I indented one level (8 spaces) to the method. `OperatingSystem.isAix()...` is argument of `findOrThrow` and `calling_convention_requires_int_as_long...` etc are arguments of `FunctionDescriptor.of` and they are indented one level further. IntelliJ IDEA unindents the `FunctionDescriptor.of(...)` block but I think that's misleading. > > As for whether it's a better alternative of JNI, FFM is usually considered at least as fast as JNI. In this case, on my Mac, the FFM version is much much faster. I guess the main reason is while the C code is quite small it calls back to Java object manipulation too much. > IntelliJ IDEA unindents the FunctionDescriptor.of(...) block but I think that's misleading. That's what I thought. Ok. Another advantage is that we don't need the .c file any more. If performance matters, we could still tune it by using the critical option. But I guess it's fast enough. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28931#discussion_r2714401065 From drwhite at openjdk.org Wed Jan 21 22:10:13 2026 From: drwhite at openjdk.org (Derek White) Date: Wed, 21 Jan 2026 22:10:13 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively. >> >> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size. >> >> >> ### **Performance comparison for byte array fills in a loop for 1 million times** >> >> >> UseAVX=3 ByteArray Size | +OptimizeFill (Masked store stub) [secs] | -OptimizeFill (No stub) [secs] | --->This PR: +OptimizeFill (Unmasked store stub) [secs] >> -- | -- | -- | -- >> 1 | 0.46 | 0.14 | 0.189 >> 2 | 0.46 | 0.16 | 0.191 >> 3 | 0.46 | 0.176 | 0.199 >> 4 | 0.46 | 0.244 | 0.212 >> 5 | 0.46 | 0.29 | 0.364 >> 10 | 0.46 | 0.58 | 0.354 >> 15 | 0.46 | 0.42 | 0.325 >> 16 | 0.46 | 0.46 | 0.281 >> 17 | 0.21 | 0.5 | 0.365 >> 20 | 0.21 | 0.37 | 0.326 >> 25 | 0.21 | 0.59 | 0.343 >> 31 | 0.21 | 0.53 | 0.317 >> 32 | 0.21 | 0.58 | 0.249 >> 35 | 0.5 | 0.77 | 0.303 >> 40 | 0.5 | 0.61 | 0.312 >> 45 | 0.5 | 0.52 | 0.364 >> 48 | 0.5 | 0.66 | 0.283 >> 49 | 0.22 | 0.69 | 0.367 >> 50 | 0.22 | 0.78 | 0.344 >> 55 | 0.22 | 0.67 | 0.332 >> 60 | 0.22 | 0.67 | 0.312 >> 64 | 0.22 | 0.82 | 0.253 >> 70 | 0.51 | 1.1 | 0.394 >> 80 | 0.49 | 0.89 | 0.346 >> 90 | 0.225 | 0.68 | 0.385 >> 100 | 0.54 | 1.09 | 0.364 >> 110 | 0.6 | 0.98 | 0.416 >> 120 | 0.26 | 0.75 | 0.367 >> 128 | 0.266 | 1.1 | 0.342 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Update ALL of ArraysFill JMH micro I'm expecting to see a small regression in a write-only fill, and a larger improvement in write+read fill, but we didn't present the data in a way that makes it easy to compare those two tests. So we should present the graphed data as a table as well. Then we can discuss how common the write+read fill case is. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3781378167 From henryjen at openjdk.org Wed Jan 21 23:27:13 2026 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 21 Jan 2026 23:27:13 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c [v2] In-Reply-To: References: Message-ID: > Fix dangling pointers. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29351/files - new: https://git.openjdk.org/jdk/pull/29351/files/fa7b746e..e946aa2d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29351&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29351&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29351.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29351/head:pull/29351 PR: https://git.openjdk.org/jdk/pull/29351 From henryjen at openjdk.org Wed Jan 21 23:27:15 2026 From: henryjen at openjdk.org (Henry Jen) Date: Wed, 21 Jan 2026 23:27:15 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:28:52 GMT, Alan Bateman wrote: > The changes look okay. Do you want to do the same for image_data in ShowSplashScreen. That's local variable on stack, thus not really needed. > > This is first change to the launcher code in 2026 so you'll need to bump the copyright header. Thanks, I'll update. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29351#issuecomment-3781587584 From jlu at openjdk.org Thu Jan 22 00:49:15 2026 From: jlu at openjdk.org (Justin Lu) Date: Thu, 22 Jan 2026 00:49:15 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit Message-ID: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Please review this PR which converts the JDBC TestNG tests to use JUnit. This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. Framework test stats before: 680 = 680 TestNG + 0 JUnit Framework test stats after: 680 = 0 TestNG + 680 JUnit ------------- Commit messages: - Update copyright years - Remove redundant test instance annotations from BaseTest children - Clean up exception tests (lambdas + narrow scope) - Simplify boolean value sources for base tests - Rename testng folder to junit - Update TEST.properties - Apply conversion Changes: https://git.openjdk.org/jdk/pull/29354/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376038 Stats: 3454 lines in 46 files changed: 1702 ins; 1634 del; 118 mod Patch: https://git.openjdk.org/jdk/pull/29354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29354/head:pull/29354 PR: https://git.openjdk.org/jdk/pull/29354 From ascarpino at openjdk.org Thu Jan 22 00:58:40 2026 From: ascarpino at openjdk.org (Anthony Scarpino) Date: Thu, 22 Jan 2026 00:58:40 GMT Subject: RFR: 8277489: Rewrite JAAS UnixLoginModule with FFM [v10] In-Reply-To: References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Wed, 21 Jan 2026 19:39:49 GMT, Weijun Wang wrote: >> Rewrite the native calls with FFM. > > Weijun Wang has updated the pull request incrementally with one additional commit since the last revision: > > unnecessary initialization Marked as reviewed by ascarpino (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28931#pullrequestreview-3690107628 From pchilanomate at openjdk.org Thu Jan 22 01:17:28 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 01:17:28 GMT Subject: RFR: 8369238: Allow virtual thread preemption on some common class initialization paths [v15] In-Reply-To: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> References: <4hRNhuxziLbGiy8BIhN7Be3NlQ6cOckUF_earAzDDnU=.f00c5720-557f-4b34-b643-b9313cdf7afc@github.com> Message-ID: On Wed, 21 Jan 2026 02:58:33 GMT, He-Pin(kerr) wrote: > Will this be backported to Java 25 LTS? > No plans to backport it. Feel free to follow up on the loom-dev mailing list instead (see https://mail.openjdk.org/pipermail/loom-dev/2025-November/008039.html). ------------- PR Comment: https://git.openjdk.org/jdk/pull/27802#issuecomment-3781955460 From swen at openjdk.org Thu Jan 22 01:31:27 2026 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 Jan 2026 01:31:27 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v25] 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 44 commits: - Merge branch 'master' into optim_parse_int_long_202501 - remove unsafe - 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 - ... and 34 more: https://git.openjdk.org/jdk/compare/a0ac5b34...90778ed9 ------------- Changes: https://git.openjdk.org/jdk/pull/22919/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=24 Stats: 146 lines in 6 files changed: 68 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 erfang at openjdk.org Thu Jan 22 03:13:59 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 22 Jan 2026 03:13:59 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 14:10:39 GMT, Andrew Haley wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Extract some helper functions for better readability > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1965: > >> 1963: // Helper function to decode min/max reduction operation properties >> 1964: static void decode_minmax_reduction_opc(int opc, bool& is_min, bool& is_unsigned, >> 1965: Assembler::Condition& cond) { > > Suggestion: > > Condition cond) { Considering that this function is only used by this file and does not call any instructions, I made it a **file-scope static** function. And as we don't declare `using Assembler::Condition;` in this file, so we have to use `Assembler::Condition&` here, or we'll get the following error: jdk/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp:1965:41: error: ?Condition? has not been declared 1965 | Condition& cond) { As for `&`, this is a reference parameter. To remove `Assembler::`, we can 1. Declare `using Assembler::Condition;` in this file. 2. Make this function as a private method of `C2_MacroAssembler`. WDYT ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2715142364 From jpai at openjdk.org Thu Jan 22 05:59:29 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Jan 2026 05:59:29 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 14:21:26 GMT, Arno Zeller wrote: > It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. > This change will add the message again to the allowed messages. Thank you for fixing this. Looks good to me. Please update the copyright year on the file from 2025 to 2026, before integrating. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29348#pullrequestreview-3690718620 PR Comment: https://git.openjdk.org/jdk/pull/29348#issuecomment-3782628128 From duke at openjdk.org Thu Jan 22 06:27:46 2026 From: duke at openjdk.org (duke) Date: Thu, 22 Jan 2026 06:27:46 GMT Subject: Withdrawn: 8308776: [AArch64] Math.log is 10% slower than StrictMath.log on aarch64 In-Reply-To: References: Message-ID: On Thu, 13 Nov 2025 20:41:56 GMT, Dhamoder Nalla wrote: > This PR Introduces an optimized AArch64 intrinsic for Math.log using reciprocal refinement and a table-driven polynomial. > Improves throughput for double logarithms while preserving IEEE-754 corner case behavior (?0, subnormals, negatives, NaN). > > > > The micro-benchmark results from MathBench and StrictMathBench below show the performance improvement of Math.log: > > > **Before change** > xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > > > > > >

> >
> >
> >
> > Benchmark | Mode | Cnt | Score | Error | Units > -- | -- | -- | -- | -- | -- > MathBench.logDouble | thrpt | 10 | **15549.705** | ?357.439 | ops/ms > StrictMathBench.logDouble | thrpt | 10 | 219408.158 | ?16484.680 | ops/ms > >
> >
> >
> >
> > > > > > > > > **After adding Math.log intrinsic** > > xmlns:dt="uuid:C2F41010-65B3-11d1-A29F-00AA00C14882" > xmlns="http://www.w3.org/TR/REC-html40"> > > > > > > > > > > >
> >
> >
> >
> > Benchmark | Mode | Cnt | Score | Error | Units > -- | -- | -- | -- | -- | -- > MathBench.logDouble | thrpt | 10 | **300086.773** | ?6675.936 | ops/ms > StrictMathBench.logDouble | thrpt | 10 | 226521.817 | ?4038.975 | ops/ms > > >
> >
> >
> >
> > > > > This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28306 From swen at openjdk.org Thu Jan 22 06:34:33 2026 From: swen at openjdk.org (Shaojin Wen) Date: Thu, 22 Jan 2026 06:34:33 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:47:05 GMT, Raffaello Giulietti wrote: >> 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.... > > Thanks @wenshao for trying out without making use of `Unsafe`! > I'll have another look sometimes next week. @rgiulietti Is there any progress on this PR? ------------- PR Comment: https://git.openjdk.org/jdk/pull/22919#issuecomment-3782733867 From varadam at openjdk.org Thu Jan 22 06:35:11 2026 From: varadam at openjdk.org (Varada M) Date: Thu, 22 Jan 2026 06:35:11 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v4] In-Reply-To: References: 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) Varada M has updated the pull request incrementally with one additional commit since the last revision: 8371187: [BigEndian Platforms] Vector lane reversal error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28425/files - new: https://git.openjdk.org/jdk/pull/28425/files/670043ae..e26a5c89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=02-03 Stats: 26 lines in 7 files changed: 11 ins; 0 del; 15 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 varadam at openjdk.org Thu Jan 22 06:35:14 2026 From: varadam at openjdk.org (Varada M) Date: Thu, 22 Jan 2026 06:35:14 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:20:41 GMT, Martin Doerr wrote: >> Varada M 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: >> >> - 8371187: [BigEndian Platforms] Vector lane reversal error >> - fix for vector alignment issue on big-endian > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 185: > >> 183: // NOTE: This assumes that convert0('X') >> 184: // respects REGISTER_ENDIAN order. >> 185: return convert0('X', vspecies().withLanes(laneType)).maybeSwapOnConverted(java.nio.ByteOrder.nativeOrder(), vspecies()); > > Would `swapIfNeeded` be a better name? > I think we could determine the ByteOrder where it is used. Then, we don't have to pass it any more. I agree, looks more clean. I have renamed and made the suggested changes > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 217: > >> 215: int sBytes = srcSpecies.elementSize(); >> 216: int tBytes = vspecies().elementSize(); >> 217: if (sBytes == tBytes || (sBytes % tBytes) != 0) { > > What do we do if it's not divisible? Should we better throw an exception? I have tried adding the exception but many tests failed! what I understood is asVectorRawTemplate is called in many cases which eventually calls swapIfNeeded and exception is thrown for the widening cases. When we reinterpret smaller elements into larger ones we don't need to swap elements so we could opt out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2715485291 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2715486090 From azeller at openjdk.org Thu Jan 22 06:36:10 2026 From: azeller at openjdk.org (Arno Zeller) Date: Thu, 22 Jan 2026 06:36:10 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows [v2] In-Reply-To: References: Message-ID: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> > It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. > This change will add the message again to the allowed messages. Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29348/files - new: https://git.openjdk.org/jdk/pull/29348/files/128eb130..1423f9dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29348&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29348&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29348.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29348/head:pull/29348 PR: https://git.openjdk.org/jdk/pull/29348 From alanb at openjdk.org Thu Jan 22 06:44:15 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jan 2026 06:44:15 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 23:27:13 GMT, Henry Jen wrote: >> Fix dangling pointers. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29351#pullrequestreview-3690849233 From jpai at openjdk.org Thu Jan 22 06:47:08 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Jan 2026 06:47:08 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows [v2] In-Reply-To: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> References: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> Message-ID: On Thu, 22 Jan 2026 06:36:10 GMT, Arno Zeller wrote: >> It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. >> This change will add the message again to the allowed messages. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29348#pullrequestreview-3690858205 From jpai at openjdk.org Thu Jan 22 06:56:51 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Jan 2026 06:56:51 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 23:27:13 GMT, Henry Jen wrote: >> Fix dangling pointers. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29351#pullrequestreview-3690896722 From jbhateja at openjdk.org Thu Jan 22 08:17:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:17:57 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v2] In-Reply-To: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> References: <1Vs8Ud-yh7FtFJN9sddNXDVM6Mc0ue9oi_oa0w5pRzU=.022172f3-1622-4d05-888b-c7afc66a5254@github.com> Message-ID: On Mon, 11 Aug 2025 03:07:13 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Updating predicate checks > > Thanks for your work @jatin-bhateja! This PR also provides help on AArch64 that we also have plan to do the same intrinsifaction in our side. Hi @XiaohongGong , @eme64 , Let me know if you have comments / suggestions here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3783097561 From jbhateja at openjdk.org Thu Jan 22 08:17:55 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:17:55 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v10] In-Reply-To: References: Message-ID: > 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 ... Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Update callGenerator.hpp copyright year - Review comments resolution - Cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 - Updating predicate checks - Fixes for failing regressions - ... and 4 more: https://git.openjdk.org/jdk/compare/0f4d7750...4b807102 ------------- Changes: https://git.openjdk.org/jdk/pull/24104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=09 Stats: 1350 lines in 29 files changed: 1247 ins; 2 del; 101 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Thu Jan 22 08:31:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 22 Jan 2026 08:31:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: > 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 ... Jatin Bhateja 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: Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/4b807102..2c7eb96d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=09-10 Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From duke at openjdk.org Thu Jan 22 09:41:14 2026 From: duke at openjdk.org (duke) Date: Thu, 22 Jan 2026 09:41:14 GMT Subject: Withdrawn: 8321283: Reuse StringLatin1::equals in regionMatches In-Reply-To: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com> References: <8EwNSqlljBOhacexcHooICmEWdV7BdSAAokjrmL3hnI=.9bf1f3da-8643-40da-a21c-7dcb3f2d71a4@github.com> Message-ID: On Sat, 2 Dec 2023 16:56:22 GMT, Francesco Nigro wrote: > This improvement has been found on https://github.com/vert-x3/vertx-web/pull/2526. > > It can potentially affect the existing ArraysSupport.mismatch caller code-path performance ie requires investigation. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/16933 From xgong at openjdk.org Thu Jan 22 09:45:30 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Thu, 22 Jan 2026 09:45:30 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 08:31:30 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 >> VectorSliceB... > > Jatin Bhateja 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: > > Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 Overall, looks good to me; I?ve just left a few minor comments. src/hotspot/share/opto/vectorIntrinsics.cpp line 1712: > 1710: log_if_needed(" ** vector slice from non-constant index not supported"); > 1711: return false; > 1712: } Is it better floating this check up to an earlier line? Maybe followed line-1704 or merged into line-1689. src/hotspot/share/opto/vectornode.cpp line 2440: > 2438: > 2439: Node* VectorSliceNode::Identity(PhaseGVN* phase) { > 2440: if (origin()->is_Con()) { `origin` must be a constant now? src/hotspot/share/opto/vectornode.cpp line 2443: > 2441: jint index = origin()->get_int(); > 2442: uint vlen = vect_type()->length_in_bytes(); > 2443: if (vlen == (uint)index) { Suggestion: if (vlen == (uint) index) { src/hotspot/share/opto/vectornode.hpp line 1697: > 1695: class VectorSliceNode : public VectorNode { > 1696: public: > 1697: VectorSliceNode(Node* vec1, Node* vec2, Node* origin, const TypeVect* vt) Do we need an assertion for `origin` which is always a constant ? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/FloatVector.java line 2173: > 2171: FloatVector slice(int origin, Vector v1); > 2172: > 2173: Revert this new added blank line? ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3691494636 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716077178 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716083174 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716080787 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716090510 PR Review Comment: https://git.openjdk.org/jdk/pull/24104#discussion_r2716094647 From mdoerr at openjdk.org Thu Jan 22 10:36:00 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 22 Jan 2026 10:36:00 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 06:29:26 GMT, Varada M wrote: >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 185: >> >>> 183: // NOTE: This assumes that convert0('X') >>> 184: // respects REGISTER_ENDIAN order. >>> 185: return convert0('X', vspecies().withLanes(laneType)).maybeSwapOnConverted(java.nio.ByteOrder.nativeOrder(), vspecies()); >> >> Would `swapIfNeeded` be a better name? >> I think we could determine the ByteOrder where it is used. Then, we don't have to pass it any more. > > I agree, looks more clean. I have renamed and made the suggested changes Thanks! My idea was to move `java.nio.ByteOrder.nativeOrder()` to `subLanesToSwap` where the only usage is AFAICS. >> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 217: >> >>> 215: int sBytes = srcSpecies.elementSize(); >>> 216: int tBytes = vspecies().elementSize(); >>> 217: if (sBytes == tBytes || (sBytes % tBytes) != 0) { >> >> What do we do if it's not divisible? Should we better throw an exception? > > I have tried adding the exception but many tests failed! > what I understood is asVectorRawTemplate is called in many cases which eventually calls swapIfNeeded and exception is thrown for the widening cases. When we reinterpret smaller elements into larger ones we don't need to swap elements so we could opt out. Ok, a comment would be helpful. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2716289852 PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2716283133 From mdoerr at openjdk.org Thu Jan 22 10:36:04 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Thu, 22 Jan 2026 10:36:04 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 18:40:08 GMT, Martin Doerr wrote: >> Varada M 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: >> >> - 8371187: [BigEndian Platforms] Vector lane reversal error >> - fix for vector alignment issue on big-endian > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractVector.java line 194: > >> 192: int[] id = new int[lanes]; >> 193: for (int i = 0; i < lanes; ++i) id[i] = i; >> 194: return VectorShuffle.fromArray(targetSpecies, id, 0); > > Some comments would be helpful describing what you do in which case. Wouldn't it be more efficient to handle this case by if (subLanesPerSrc <= 1) { return this; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2716282144 From duke at openjdk.org Thu Jan 22 10:49:55 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 22 Jan 2026 10:49:55 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont wrote: > Allow replacement string to contain embedded newlines to split entries. > This turns output like: > > > > ... another 10k chars on the end of this line ... > > > into: > > > > > > ... one entry per line ... The spaces are correct (6) and the first line's indent is in the template file itself. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29305#issuecomment-3783728479 From jpai at openjdk.org Thu Jan 22 11:05:06 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 22 Jan 2026 11:05:06 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v5] In-Reply-To: References: 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 te... Jaikiran Pai 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: - merge latest from master branch - merge latest from master branch - Mark's suggestion - move the duration check to separate method - merge latest from master branch - Mark's review - use CountDownLatch - merge latest from master branch - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/029f71a0..932520b9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=03-04 Stats: 34480 lines in 692 files changed: 20152 ins; 6847 del; 7481 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 jwaters at openjdk.org Thu Jan 22 11:32:21 2026 From: jwaters at openjdk.org (Julian Waters) Date: Thu, 22 Jan 2026 11:32:21 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 23:27:13 GMT, Henry Jen wrote: >> Fix dangling pointers. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Not my area but looks good and is trivial enough that I can actually give a thumbs up. ------------- Marked as reviewed by jwaters (Committer). PR Review: https://git.openjdk.org/jdk/pull/29351#pullrequestreview-3691992826 From cushon at openjdk.org Thu Jan 22 11:45:08 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 22 Jan 2026 11:45:08 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: > See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). > > Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. > > This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: - Merge branch 'JDK-8374654' into JDK-8208752 - Test cleanup - Updates for --debug=dumpLambdaDeserializationStats - Merge branch 'JDK-8374654' into JDK-8208752 - Merge branch 'JDK-8374654' into JDK-8208752 - Update test - Merge branch 'JDK-8374654' into JDK-8208752 - Don't rely on the iteration order of Map.of entries - 8208752: Calling a deserialized Lambda might fail with ClassCastException ------------- Changes: https://git.openjdk.org/jdk/pull/28943/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28943&range=03 Stats: 123 lines in 7 files changed: 97 ins; 6 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/28943.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28943/head:pull/28943 PR: https://git.openjdk.org/jdk/pull/28943 From alanb at openjdk.org Thu Jan 22 12:16:26 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 22 Jan 2026 12:16:26 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Thu, 22 Jan 2026 00:41:13 GMT, Justin Lu wrote: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java line 45: > 43: * via the service-provider loading mechanism. > 44: */ > 45: @TestInstance(TestInstance.Lifecycle.PER_CLASS) Has migration replaces a data provider with a method source that is an instance method, when JUnit prefers a static method? I'm trying to understand why Lifecycle.PER_CLASS is needed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2716655736 From weijun at openjdk.org Thu Jan 22 12:19:07 2026 From: weijun at openjdk.org (Weijun Wang) Date: Thu, 22 Jan 2026 12:19:07 GMT Subject: Integrated: 8277489: Rewrite JAAS UnixLoginModule with FFM In-Reply-To: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> References: <1T4ueSZkYzjrTF_-jPF4PMWU5d2_U1tNAh9fNNGvEGs=.399d6ef1-167c-45e8-8f41-9cae211754b2@github.com> Message-ID: On Fri, 19 Dec 2025 17:56:23 GMT, Weijun Wang wrote: > Rewrite the native calls with FFM. This pull request has now been integrated. Changeset: eda15aa1 Author: Weijun Wang URL: https://git.openjdk.org/jdk/commit/eda15aa19c36142984edaa08850132ca6ae7a369 Stats: 355 lines in 6 files changed: 190 ins; 135 del; 30 mod 8277489: Rewrite JAAS UnixLoginModule with FFM Co-authored-by: Martin Doerr Reviewed-by: mdoerr, ascarpino, erikj ------------- PR: https://git.openjdk.org/jdk/pull/28931 From sgehwolf at openjdk.org Thu Jan 22 13:30:58 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:30:58 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: - Merge branch 'master' into jdk-8375692-container-test-assert - Restore Bellsoft copyright - Update copyright year - 8375692: Hotspot container tests assert with non-ascii vendor name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29315/files - new: https://git.openjdk.org/jdk/pull/29315/files/e539a64f..dbe943dc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29315&range=02-03 Stats: 14011 lines in 386 files changed: 8639 ins; 2067 del; 3305 mod Patch: https://git.openjdk.org/jdk/pull/29315.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29315/head:pull/29315 PR: https://git.openjdk.org/jdk/pull/29315 From sgehwolf at openjdk.org Thu Jan 22 13:31:01 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Thu, 22 Jan 2026 13:31:01 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v3] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Wed, 21 Jan 2026 10:05:30 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: > > Restore Bellsoft copyright @dholmes-ora Any more thoughts on this? OK as it is? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3784411173 From pchilanomate at openjdk.org Thu Jan 22 14:55:39 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 14:55:39 GMT Subject: RFR: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: <4drncZpNzFFT-ME7n27r4V2l_8AXgn3CGMgLvPzNjEI=.bfb662ab-541b-40d1-bd42-1cbd05eb84ce@github.com> On Fri, 16 Jan 2026 07:05:45 GMT, Alan Bateman wrote: >> @pchilano I took a look at this out of interest but there is nothing Hotspot related to review. The state machine for VTs is too complex for me to comment on the actual fix - though I understand how the timedWaitLock forces the calls to be serialized. >> >> It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > >> It did make we wonder why the timed-park doesn't need any locking. Can't it have a similar problem if the virtual thread is unparked before the carrier can set the state to TIMED_PARK? > > Parking (including timed-parking) is much simpler, and okay to be unparked during transition. We have a lot of tests for this. Timed-Object.wait is more complex due to the two block states (the equivalent of Thread.State TIMED_WAITING and BLOCKED), and timed and unblocking working asynchronously. Thanks for the reviews and comments @AlanBateman, @dholmes-ora and @viktorklang-ora! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29255#issuecomment-3784826784 From pchilanomate at openjdk.org Thu Jan 22 14:59:40 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 22 Jan 2026 14:59:40 GMT Subject: Integrated: 8373120: Virtual thread stuck in BLOCKED state In-Reply-To: References: Message-ID: On Thu, 15 Jan 2026 17:42:33 GMT, Patricio Chilano Mateo wrote: > Please review the following patch. This fixes a bug in how we handle state changes for the timed `Object.wait` case in `afterYield`, which can leave a virtual thread stuck in the `BLOCKED` state. It can be triggered by two consecutive calls to timed `Object.wait`, if the first call receives a notification and the second call relies on the timeout task to wake up the thread. I added the full sequence of events that leads to the vthread getting stuck in JBS. > > The fix is to check for `notified` and attempt to change the state to `BLOCKED` inside the synchronized block. This guarantees that we don't change the state of an already new timed `Object.wait` call. > > The PR includes a new test which reproduces the issue when run several times in mach5. It's a hybrid of my original repro test and another one created by @AlanBateman. > > Thanks, > Patricio This pull request has now been integrated. Changeset: 26aab3cc Author: Patricio Chilano Mateo URL: https://git.openjdk.org/jdk/commit/26aab3cccdbcf98c329c8d67093eb2dbf4b164e5 Stats: 156 lines in 2 files changed: 145 ins; 8 del; 3 mod 8373120: Virtual thread stuck in BLOCKED state Co-authored-by: Alan Bateman Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29255 From cstein at openjdk.org Thu Jan 22 15:27:01 2026 From: cstein at openjdk.org (Christian Stein) Date: Thu, 22 Jan 2026 15:27:01 GMT Subject: RFR: 8375433: jar should validate automatic module names Message-ID: Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. Prior to this commit, a `MANFEST.MF` reading Automatic-Module-Name: default added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: $ java --module-path a.jar --describe-module default Error occurred during initialization of boot layer java.lang.module.FindException: Unable to derive module descriptor for a.jar Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: invalid module name of Automatic-Module-Name entry in manifest: default The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. ------------- Commit messages: - Add tests for automatic module names - 8375433: jar should validate module names Changes: https://git.openjdk.org/jdk/pull/29316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375433 Stats: 85 lines in 3 files changed: 76 ins; 6 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29316/head:pull/29316 PR: https://git.openjdk.org/jdk/pull/29316 From bpb at openjdk.org Thu Jan 22 15:59:29 2026 From: bpb at openjdk.org (Brian Burkhalter) Date: Thu, 22 Jan 2026 15:59:29 GMT Subject: RFR: 8373928: 4 Dangling pointer defect groups in java.c [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 23:27:13 GMT, Henry Jen wrote: >> Fix dangling pointers. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by bpb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29351#pullrequestreview-3693221392 From jlahoda at openjdk.org Thu Jan 22 16:28:51 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 Jan 2026 16:28:51 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon wrote: >> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'JDK-8374654' into JDK-8208752 > - Test cleanup > - Updates for --debug=dumpLambdaDeserializationStats > - Merge branch 'JDK-8374654' into JDK-8208752 > - Merge branch 'JDK-8374654' into JDK-8208752 > - Update test > - Merge branch 'JDK-8374654' into JDK-8208752 > - Don't rely on the iteration order of Map.of entries > - 8208752: Calling a deserialized Lambda might fail with ClassCastException This looks reasonable to me, and I don't see how this could break anything (although that does not mean nothing will be broken, of course). Aside for making the method a bit bigger, of course, but that hopefully shouldn't be a big deal. So, overall, I am OK with this patch. What I am not as OK with is the dependency on PR #29075 - that PR without this one will cause a regression, and even if it was a transient/short-term regression, I don't think we should knowingly do it. So, my proposal would be to do one of these: - change the order of the patches. Integrate this one (which should be OK, right?), and then PR #29075 - do both this and #29075 together ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3785329343 From cushon at openjdk.org Thu Jan 22 16:33:08 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 22 Jan 2026 16:33:08 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon wrote: >> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'JDK-8374654' into JDK-8208752 > - Test cleanup > - Updates for --debug=dumpLambdaDeserializationStats > - Merge branch 'JDK-8374654' into JDK-8208752 > - Merge branch 'JDK-8374654' into JDK-8208752 > - Update test > - Merge branch 'JDK-8374654' into JDK-8208752 > - Don't rely on the iteration order of Map.of entries > - 8208752: Calling a deserialized Lambda might fail with ClassCastException Thanks, I agree with not doing #29075 separately first to avoid a breakage. However doing this one first also doesn't work, this change by itself would regress `tools/javac/lambda/SerializableObjectMethods.java` and `tools/javac/lambda/LambdaLambdaSerialized.java`. Currently those tests rely on lambdas being incorrectly merged together, and with this fix they no longer get merged because they have different target types, but then they don't deserialize because the `getImplClass` doesn't match. Those test failures were what led me down the path of that other fix: https://bugs.openjdk.org/browse/JDK-8208752?focusedId=14636922&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14636922 So I think maybe we should just merge both of these changes into a single fix? I will update the PR if that makes sense. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3785351727 From jlahoda at openjdk.org Thu Jan 22 16:38:15 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 Jan 2026 16:38:15 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 16:30:03 GMT, Liam Miller-Cushon wrote: > Thanks, I agree with not doing #29075 separately first to avoid a breakage. However doing this one first also doesn't work, this change by itself would regress `tools/javac/lambda/SerializableObjectMethods.java` and `tools/javac/lambda/LambdaLambdaSerialized.java`. Currently those tests rely on lambdas being incorrectly merged together, and with this fix they no longer get merged because they have different target types, but then they don't deserialize because the `getImplClass` doesn't match. Those test failures were what led me down the path of that other fix: https://bugs.openjdk.org/browse/JDK-8208752?focusedId=14636922&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-14636922 > > So I think maybe we should just merge both of these changes into a single fix? I will update the PR if that makes sense. Ah, OK. Then I would say merge the patches - if they cannot be separated, then merging/combining them is the only real option. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3785380123 From cushon at openjdk.org Thu Jan 22 16:40:51 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Thu, 22 Jan 2026 16:40:51 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 16:35:29 GMT, Jan Lahoda wrote: > Ah, OK. Then I would say merge the patches - if they cannot be separated, then merging/combining them is the only real option. Thanks, will do. I'm leaning towards merging into this one, since JDK-8208752 was the original bug. Let me know if you have a preference. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3785396416 From jlahoda at openjdk.org Thu Jan 22 16:58:12 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Thu, 22 Jan 2026 16:58:12 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon wrote: >> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'JDK-8374654' into JDK-8208752 > - Test cleanup > - Updates for --debug=dumpLambdaDeserializationStats > - Merge branch 'JDK-8374654' into JDK-8208752 > - Merge branch 'JDK-8374654' into JDK-8208752 > - Update test > - Merge branch 'JDK-8374654' into JDK-8208752 > - Don't rely on the iteration order of Map.of entries > - 8208752: Calling a deserialized Lambda might fail with ClassCastException Using the original bug and this PR seems sensible. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3785500908 From vklang at openjdk.org Thu Jan 22 16:58:13 2026 From: vklang at openjdk.org (Viktor Klang) Date: Thu, 22 Jan 2026 16:58:13 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v28] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 21 Jan 2026 16:35:41 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: > > Try out different approach src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1460: > 1458: ++taken; > 1459: } > 1460: return taken; Since `q` can never be null, and `task` initially is never null, perhaps we could do: final int topLevelExec(ForkJoinTask task, WorkQueue q, ForkJoinPool pool, int fifo) { int taken = 0; if (task != null && q != null) { ForkJoinPool p = (fifo == 0) ? null : pool; do { task.doExec(); ++taken; } while ((task = nextLocalTask(fifo)) != null || (task = q.tryPoll(p)) != null)); } return taken; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2717771468 From henryjen at openjdk.org Thu Jan 22 17:24:42 2026 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 Jan 2026 17:24:42 GMT Subject: Integrated: 8373928: 4 Dangling pointer defect groups in java.c In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 18:58:00 GMT, Henry Jen wrote: > Fix dangling pointers. This pull request has now been integrated. Changeset: 5dfda66e Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/5dfda66e13df5a88a66a6e4b1ae1bcd4e20ac674 Stats: 5 lines in 1 file changed: 3 ins; 0 del; 2 mod 8373928: 4 Dangling pointer defect groups in java.c Reviewed-by: bpb, alanb, jpai, jwaters ------------- PR: https://git.openjdk.org/jdk/pull/29351 From aph at openjdk.org Thu Jan 22 17:31:36 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 17:31:36 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: <0Sb85mfgAvhtvGsNtdZvcwvaaOYvfDyTS-2TmnRW95Q=.6a523d10-6f54-4af0-b7f9-bef49e995fa3@github.com> On Wed, 21 Jan 2026 10:15:24 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 >> ... > > Eric Fang has updated the pull request incrementally with one additional commit since the last revision: > > Extract some helper functions for better readability src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.hpp line 50: > 48: void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size, > 49: PRegister pg, FloatRegister src); > 50: Using separate definitions here is adding unnecessary complexity. I'd do something like this in the header file: // Typedefs used to disambiguate overloaded member functions. typedef void (Assembler::*neon_reduction2) (FloatRegister, Assembler::SIMD_Arrangement, FloatRegister); typedef void (Assembler::*sve_reduction3) (FloatRegister, Assembler::SIMD_RegVariant, PRegister, FloatRegister); // Helper functions for min/max reduction operations void neon_minp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size, FloatRegister src1, FloatRegister src2) { auto m = is_unsigned ? &Assembler::uminp : &Assembler::sminp; (this->*m)(dst, size, src1, src2); } void neon_maxp(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size, FloatRegister src1, FloatRegister src2) { auto m = is_unsigned ? &Assembler::umaxp : &Assembler::smaxp; (this->*m)(dst, size, src1, src2); } void neon_minv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size, FloatRegister src) { auto m = is_unsigned ? (neon_reduction2)&Assembler::uminv : &Assembler::sminv; (this->*m)(dst, size, src); } void neon_maxv(bool is_unsigned, FloatRegister dst, SIMD_Arrangement size, FloatRegister src) { auto m = is_unsigned ? (neon_reduction2)&Assembler::umaxv : &Assembler::smaxv; (this->*m)(dst, size, src); } void sve_minv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size, PRegister pg, FloatRegister src) { auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_uminv : &Assembler::sve_sminv; (this->*m)(dst, size, pg, src); } void sve_maxv(bool is_unsigned, FloatRegister dst, SIMD_RegVariant size, PRegister pg, FloatRegister src) { auto m = is_unsigned ? (sve_reduction3)&Assembler::sve_umaxv : &Assembler::sve_smaxv; (this->*m)(dst, size, pg, src); } To some extent it's a matter of taste, but please try not to use much more repetitive and boilerplate code than you need to. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2717902945 From aph at openjdk.org Thu Jan 22 17:37:43 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 17:37:43 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 03:11:04 GMT, Eric Fang wrote: >> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1965: >> >>> 1963: // Helper function to decode min/max reduction operation properties >>> 1964: static void decode_minmax_reduction_opc(int opc, bool& is_min, bool& is_unsigned, >>> 1965: Assembler::Condition& cond) { >> >> Suggestion: >> >> Condition cond) { > > Considering that this function is only used by this file and does not call any instructions, I made it a **file-scope static** function. And as we don't declare `using Assembler::Condition;` in this file, so we have to use `Assembler::Condition&` here, or we'll get the following error: > > jdk/src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp:1965:41: error: ?Condition? has not been declared > 1965 | Condition& cond) { > > As for `&`, this is a reference parameter. > > To remove `Assembler::`, we can > 1. Declare `using Assembler::Condition;` in this file. > 2. Make this function as a private method of `C2_MacroAssembler`. > > WDYT ? I can't see any positive reason not to use Option 2. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2717926249 From aph at openjdk.org Thu Jan 22 17:37:48 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 17:37:48 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:15:24 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 >> ... > > Eric Fang has updated the pull request incrementally with one additional commit since the last revision: > > Extract some helper functions for better readability src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1980: > 1978: } > 1979: > 1980: // neon minp: pairwise minimum operation This comment, and the ones like it, is unnecessary. src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 2176: > 2174: bool is_unsigned; > 2175: Condition cond; > 2176: decode_minmax_reduction_opc(opc, is_min, is_unsigned, cond); Suggestion: decode_minmax_reduction_opc(opc, &is_min, &is_unsigned, &cond); In this case, passing address arguments is easier for the reader to understand because they are visible at the call site as well as the declaration. It is obvious at a glance that some arguments are passed by address. We do use C++ reference parameters in cases where it helps to do so, but I don't think it does here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2717929066 PR Review Comment: https://git.openjdk.org/jdk/pull/28693#discussion_r2717920250 From aph at openjdk.org Thu Jan 22 17:43:22 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 22 Jan 2026 17:43:22 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:15:24 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 >> ... > > Eric Fang has updated the pull request incrementally with one additional commit since the last revision: > > Extract some helper functions for better readability Please add the `TypeNNVector` JMH test files to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3785770324 From sviswanathan at openjdk.org Thu Jan 22 17:43:21 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 22 Jan 2026 17:43:21 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: <_9OkAqddCk8CbA-51qgdecI23f03MBsZE9kiES5cU0I=.d1adead1-45ff-40be-b139-2f9fa32c7d42@github.com> Message-ID: On Wed, 21 Jan 2026 00:01:39 GMT, Srinivas Vamsi Parasa wrote: >> @vamsi-parasa Thanks for the extra data! >> >> Do I see this right? In the plots [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), the masked performance lies lower/better than unmasked performance (here we measure ns/ops). But in your tables [here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761712841) you are measuring ops/ms, and are getting the opposite trend: masked is slower than unmasked. >> >> Can you explain the difference between the two results? > >> Can you explain the difference between the two results? >> > Hi Emanuel (@eme64), > Yes, the conclusions you mentioned are correct. The store only benchmark shows that masked store is slightly better than the unmasked store. However, the store followed by load benchmarks shows that the unmasked store is better than masked vector store as masked vector stores have very limited store forwarding support in the hardware. > > This is because the load operation following the masked vector store is blocked until the data is written into the cache. This is also mentioned in the [Intel Software optimization manual](https://www.intel.com/content/www/us/en/content-details/671488/intel-64-and-ia-32-architectures-optimization-reference-manual-volume-1.html) (Chapter 18, section 18.4, page 578). > > Pasting the relevant text below for reference: > > > 18.4 FORWARDING AND MEMORY MASKING > When using masked store and load, consider the following: > ? When the mask is not all-ones or all-zeroes, the load operation, following the masked store operation > from the same address is blocked, until the data is written to the cache. > ? Unlike GPR forwarding rules, vector loads whether or not they are masked, do not forward unless > load and store addresses are exactly the same. > ? st_mask = 10101010, ld_mask = 01010101, can forward: no, should block: yes > ? st_mask = 00001111, ld_mask = 00000011, can forward: no, should block: yes > ? When the mask is all-ones, blocking does not occur, because the data may be forwarded to the load > operation. > ? st_mask = 11111111, ld_mask = don?t care, can forward: yes, should block: no > ? When mask is all-zeroes, blocking does not occur, though neither does forwarding. > ? st_mask = 00000000, ld_mask = don?t care, can forward: no, should block: no > In summary, a masked store should be used carefully, for example, if the remainder size is known at > compile time to be 1, and there is a load operation from the same cache line after it (or there is an > overlap in addresses + vector lengths), it may be better to use scalar remainder processing, rather than > a masked remainder block. > > > Thanks, > Vamsi > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3785772087 From lancea at openjdk.org Thu Jan 22 18:02:57 2026 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 22 Jan 2026 18:02:57 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: <8kA7V2u-PisHbRwbe_7d-XDU1inhMHTK2sz1zLDDQVA=.85dc19a8-062f-4176-aa13-4c5b9fcd0c47@github.com> On Thu, 22 Jan 2026 00:41:13 GMT, Justin Lu wrote: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit Hi Justin Thank you for taking this on. As part of this PR, we should also tackle javax/sql as they refer back to some of the code in this area. We probably can look to convert the JavaTimeTest.java to junit and then we can up level from the junit, formally testing, folder. A couple of other quick comments below test/jdk/java/sql/junit/test/sql/CallableStatementTests.java line 135: > 133: @Test > 134: public void test08() throws SQLException { > 135: Assertions.assertThrows(NullPointerException.class, () -> cstmt.enquoteNCharLiteral(null)); Maybe use an import so we can shorten to just assertThrow? test/jdk/java/sql/junit/util/BaseTest.java line 80: > 78: * DataProvider used to specify the standard JDBC Types > 79: */ > 80: protected Object[][] jdbcTypes() { Suggest converting all of these methods to use Stream and return Stream.of. ------------- PR Review: https://git.openjdk.org/jdk/pull/29354#pullrequestreview-3692915553 PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2717273775 PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2717981622 From sparasa at openjdk.org Thu Jan 22 20:33:00 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 22 Jan 2026 20:33:00 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 22:07:22 GMT, Derek White wrote: > I'm expecting to see a small regression in a write-only fill, and a larger improvement in write+read fill, but we didn't present the data in a way that makes it easy to compare those two tests. So we should present the graphed data as a table as well. Then we can discuss how common the write+read fill case is. Hi Derek, Please see the data for write-only fill operations for byte, short and intel below. Thanks, Vamsi ### Byte VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_byte_arrays_fill | 0 | 0.649 | 0.65 | 0.653 | 0% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 1 | 2.372 | 2.803 | 2.588 | -8% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 2 | 2.37 | 2.596 | 2.471 | -5% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 3 | 2.813 | 2.591 | 2.495 | -4% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 4 | 3.086 | 2.598 | 2.757 | 6% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 5 | 3.343 | 2.59 | 3.644 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 6 | 3.549 | 2.589 | 3.536 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 7 | 3.716 | 2.616 | 3.695 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 8 | 4.854 | 2.59 | 3.252 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 9 | 4.771 | 2.587 | 3.591 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 10 | 4.78 | 2.595 | 3.542 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 11 | 4.532 | 2.589 | 3.669 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 12 | 4.164 | 2.592 | 3.505 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 13 | 4.348 | 2.589 | 3.655 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 14 | 4.703 | 2.594 | 3.637 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 15 | 4.973 | 2.591 | 3.754 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 16 | 5.498 | 2.593 | 3.062 | 18% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 17 | 5.305 | 2.588 | 3.611 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 18 | 5.081 | 2.59 | 3.649 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 19 | 4.782 | 2.586 | 3.642 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 20 | 4.458 | 2.588 | 3.565 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 21 | 4.66 | 2.586 | 3.741 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 22 | 5.112 | 2.591 | 3.681 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 23 | 5.522 | 2.607 | 3.742 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 24 | 6.02 | 2.589 | 3.27 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 25 | 4.84 | 2.588 | 3.691 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 26 | 4.81 | 2.589 | 3.674 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 27 | 4.695 | 2.591 | 3.761 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 28 | 4.828 | 2.589 | 3.578 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 29 | 4.531 | 2.586 | 3.762 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 30 | 5.38 | 2.59 | 3.713 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 31 | 4.948 | 2.588 | 3.887 | 50% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 32 | 5.21 | 2.589 | 2.861 | 11% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 33 | 6.258 | 2.824 | 3.377 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 34 | 4.992 | 2.829 | 3.388 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 35 | 4.918 | 2.812 | 3.577 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 36 | 4.647 | 2.814 | 3.351 | 19% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 37 | 4.762 | 2.815 | 3.775 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 38 | 4.93 | 2.819 | 3.76 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 39 | 5.137 | 2.821 | 3.954 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 40 | 5.377 | 2.815 | 3.483 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 41 | 5.373 | 2.815 | 3.777 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 42 | 5.309 | 2.815 | 3.77 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 43 | 5.157 | 2.815 | 3.835 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 44 | 4.862 | 2.82 | 3.743 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 45 | 4.957 | 2.816 | 3.882 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 46 | 5.207 | 2.814 | 3.85 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 47 | 5.526 | 2.813 | 4.023 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 48 | 5.995 | 2.813 | 3.251 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 49 | 5.923 | 2.815 | 3.775 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 50 | 5.703 | 2.813 | 3.77 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 51 | 5.424 | 2.82 | 3.874 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 52 | 5.087 | 2.625 | 3.869 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 53 | 5.226 | 2.814 | 3.993 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 54 | 5.542 | 2.814 | 3.8 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 55 | 5.931 | 2.813 | 3.971 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 56 | 6.458 | 2.63 | 3.464 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 57 | 6.408 | 2.809 | 3.881 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 58 | 6.137 | 2.822 | 3.925 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 59 | 5.794 | 2.816 | 3.972 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 60 | 5.339 | 2.815 | 3.82 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 61 | 5.512 | 2.811 | 3.966 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 62 | 5.85 | 2.812 | 4.042 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 63 | 6.304 | 2.811 | 4.119 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 64 | 6.684 | 2.809 | 3.128 | 11% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 65 | 6.699 | 2.867 | 3.695 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 66 | 6.471 | 2.883 | 3.669 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 67 | 6.046 | 2.854 | 3.7 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 68 | 5.621 | 2.871 | 3.576 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 69 | 5.788 | 2.862 | 4.064 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 70 | 5.925 | 2.853 | 4.043 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 71 | 5.711 | 2.865 | 4.17 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 72 | 5.482 | 2.872 | 3.758 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 73 | 5.79 | 2.857 | 4.097 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 74 | 6.15 | 2.864 | 4.056 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 75 | 6.543 | 2.88 | 4.149 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 76 | 6.846 | 2.868 | 3.984 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 77 | 7.223 | 2.862 | 4.164 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 78 | 7.218 | 2.869 | 4.102 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 79 | 7.726 | 2.89 | 4.253 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 80 | 7.835 | 2.856 | 3.497 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 81 | 7.132 | 2.84 | 4.096 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 82 | 7.006 | 2.861 | 4.165 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 83 | 6.804 | 2.865 | 4.154 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 84 | 6.605 | 2.869 | 4.022 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 85 | 6.428 | 2.859 | 4.154 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 86 | 6.275 | 2.88 | 4.095 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 87 | 6.129 | 2.875 | 4.28 | 49% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 88 | 6.013 | 2.867 | 3.73 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 89 | 6.367 | 2.872 | 4.13 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 90 | 6.816 | 2.863 | 4.117 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 91 | 7.147 | 2.876 | 4.189 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 92 | 7.487 | 2.87 | 4.063 | 42% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 93 | 7.723 | 2.866 | 4.211 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 94 | 7.708 | 2.893 | 4.235 | 46% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 95 | 8.122 | 2.922 | 4.367 | 49% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 96 | 8.145 | 2.872 | 3.344 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 97 | 7.961 | 3.132 | 3.956 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 98 | 7.744 | 3.106 | 3.784 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 99 | 7.252 | 3.12 | 3.878 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 100 | 7.137 | 3.135 | 3.767 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 101 | 6.872 | 3.125 | 4.374 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 102 | 6.743 | 3.108 | 4.266 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 103 | 6.607 | 3.019 | 4.432 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 104 | 6.544 | 3.108 | 3.942 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 105 | 6.986 | 3.054 | 4.368 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 106 | 7.263 | 3.12 | 4.334 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 107 | 7.612 | 3.022 | 4.387 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 108 | 7.99 | 3.088 | 4.184 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 109 | 8.268 | 3.112 | 4.391 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 110 | 8.261 | 3.406 | 4.358 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 111 | 8.378 | 3.092 | 4.489 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 112 | 8.415 | 3.089 | 3.776 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 113 | 8.3 | 3.125 | 4.482 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 114 | 8.04 | 3.084 | 4.301 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 115 | 8.38 | 3.163 | 4.342 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 116 | 7.726 | 3.077 | 4.216 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 117 | 7.274 | 3.021 | 4.387 | 45% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 118 | 7.086 | 3.065 | 4.256 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 119 | 6.948 | 3.224 | 4.456 | 38% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 120 | 6.922 | 3.102 | 3.939 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 121 | 7.33 | 3.104 | 4.37 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 122 | 7.67 | 3.114 | 4.821 | 55% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 123 | 8.106 | 3.111 | 4.47 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 124 | 8.243 | 3.102 | 4.317 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 125 | 8.507 | 3.099 | 4.469 | 44% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 126 | 8.692 | 3.114 | 4.444 | 43% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 127 | 8.658 | 3.127 | 4.589 | 47% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 128 | 8.789 | 3.102 | 3.532 | 14% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 129 | 8.516 | 4.017 | 5.637 | 40% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 130 | 8.337 | 3.998 | 5.549 | 39% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 131 | 8.197 | 4.017 | 5.669 | 41% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 132 | 7.973 | 4.031 | 5.406 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 133 | 7.76 | 4.649 | 5.774 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 134 | 7.511 | 4.648 | 5.383 | 16% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 135 | 7.276 | 4.355 | 5.413 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 136 | 7.203 | 4.33 | 5.658 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 137 | 7.548 | 4.306 | 5.621 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 138 | 7.897 | 4.518 | 5.541 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 139 | 8.324 | 4.646 | 5.319 | 14% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 140 | 8.534 | 4.305 | 5.446 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 141 | 8.697 | 4.163 | 5.364 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 142 | 8.861 | 4.392 | 5.249 | 20% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 143 | 8.91 | 4.144 | 5.671 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 144 | 8.988 | 4.048 | 5.497 | 36% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 145 | 8.756 | 4.074 | 5.571 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 146 | 8.53 | 4.361 | 5.34 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 147 | 8.375 | 4.599 | 5.379 | 17% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 148 | 8.148 | 4.41 | 5.437 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 149 | 8.665 | 4.101 | 5.394 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 150 | 8.885 | 4.127 | 5.418 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 151 | 9.023 | 4.082 | 5.578 | 37% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 152 | 9.218 | 4.052 | 5.348 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 153 | 9.454 | 4.091 | 5.5 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 154 | 9.74 | 4.259 | 5.469 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 155 | 9.993 | 4.096 | 5.427 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 156 | 10.525 | 4.186 | 5.373 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 157 | 10.607 | 4.093 | 5.43 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 158 | 10.863 | 4.068 | 5.315 | 31% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 159 | 11.333 | 4.056 | 5.463 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 160 | 11.485 | 4.081 | 5.493 | 35% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 161 | 10.983 | 4.068 | 5.196 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 162 | 10.496 | 4.164 | 5.266 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 163 | 10.312 | 4.091 | 5.274 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 164 | 10.223 | 4.254 | 5.339 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 165 | 10.034 | 4.085 | 5.408 | 32% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 166 | 9.883 | 4.171 | 5.349 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 167 | 9.825 | 4.121 | 5.335 | 29% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 168 | 9.722 | 4.063 | 5.428 | 34% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 169 | 9.578 | 4.373 | 5.405 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 170 | 10.637 | 4.207 | 5.327 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 171 | 10.223 | 4.223 | 5.407 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 172 | 9.789 | 4.23 | 5.42 | 28% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 173 | 8.874 | 4.441 | 5.406 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 174 | 8.98 | 4.373 | 5.396 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 175 | 8.503 | 4.476 | 5.51 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 176 | 9.427 | 4.356 | 5.47 | 26% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 177 | 8.081 | 4.162 | 5.524 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 178 | 8.263 | 4.54 | 5.475 | 21% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 179 | 8.566 | 4.43 | 5.537 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 180 | 8.697 | 4.268 | 5.555 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 181 | 8.929 | 4.541 | 5.59 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 182 | 9.135 | 4.208 | 5.577 | 33% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 183 | 9.338 | 4.512 | 5.586 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 184 | 9.617 | 4.514 | 5.601 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 185 | 9.74 | 4.4 | 5.429 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 186 | 10.071 | 4.539 | 5.623 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 187 | 10.36 | 4.404 | 5.474 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 188 | 10.388 | 4.41 | 5.476 | 24% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 189 | 10.653 | 4.458 | 5.653 | 27% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 190 | 10.968 | 4.5 | 5.618 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 191 | 11.156 | 4.492 | 5.626 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 192 | 11.458 | 4.536 | 5.519 | 22% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 193 | 10.922 | 4.511 | 5.256 | 17% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 194 | 10.739 | 4.232 | 5.501 | 30% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 195 | 10.594 | 4.552 | 5.62 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 196 | 10.368 | 4.568 | 5.632 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 197 | 10.264 | 4.535 | 5.678 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 198 | 10.981 | 4.602 | 5.652 | 23% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 199 | 11.254 | 4.592 | 5.72 | 25% VectorBulkOperationsArray.fill_var_byte_arrays_fill | 200 | 11.159 | 4.611 | 5.736 | 24% `[continued]` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786547697 From sparasa at openjdk.org Thu Jan 22 20:33:03 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Thu, 22 Jan 2026 20:33:03 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 20:14:31 GMT, Srinivas Vamsi Parasa wrote: >> The goal of this PR is to fix the performance regression in Arrays.fill() x86 stubs caused by masked AVX stores. The fix is to replace the masked AVX stores with store instructions without masks (i.e. unmasked stores). `fill32_masked()` and `fill64_masked()` stubs are replaced with `fill32_unmasked()` and `fill64_unmasked()` respectively. >> >> To speedup unmasked stores, array fills for sizes < 64 bytes are broken down into sequences of 32B, 16B, 8B, 4B, 2B and 1B stores, depending on the size. >> >> >> ### **Performance comparison for byte array fills in a loop for 1 million times** >> >> >> UseAVX=3 ByteArray Size | +OptimizeFill (Masked store stub) [secs] | -OptimizeFill (No stub) [secs] | --->This PR: +OptimizeFill (Unmasked store stub) [secs] >> -- | -- | -- | -- >> 1 | 0.46 | 0.14 | 0.189 >> 2 | 0.46 | 0.16 | 0.191 >> 3 | 0.46 | 0.176 | 0.199 >> 4 | 0.46 | 0.244 | 0.212 >> 5 | 0.46 | 0.29 | 0.364 >> 10 | 0.46 | 0.58 | 0.354 >> 15 | 0.46 | 0.42 | 0.325 >> 16 | 0.46 | 0.46 | 0.281 >> 17 | 0.21 | 0.5 | 0.365 >> 20 | 0.21 | 0.37 | 0.326 >> 25 | 0.21 | 0.59 | 0.343 >> 31 | 0.21 | 0.53 | 0.317 >> 32 | 0.21 | 0.58 | 0.249 >> 35 | 0.5 | 0.77 | 0.303 >> 40 | 0.5 | 0.61 | 0.312 >> 45 | 0.5 | 0.52 | 0.364 >> 48 | 0.5 | 0.66 | 0.283 >> 49 | 0.22 | 0.69 | 0.367 >> 50 | 0.22 | 0.78 | 0.344 >> 55 | 0.22 | 0.67 | 0.332 >> 60 | 0.22 | 0.67 | 0.312 >> 64 | 0.22 | 0.82 | 0.253 >> 70 | 0.51 | 1.1 | 0.394 >> 80 | 0.49 | 0.89 | 0.346 >> 90 | 0.225 | 0.68 | 0.385 >> 100 | 0.54 | 1.09 | 0.364 >> 110 | 0.6 | 0.98 | 0.416 >> 120 | 0.26 | 0.75 | 0.367 >> 128 | 0.266 | 1.1 | 0.342 > > Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: > > Update ALL of ArraysFill JMH micro ### Short VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_short_arrays_fill | 0 | 0.649 | 0.65 | 0.65 | 0% VectorBulkOperationsArray.fill_var_short_arrays_fill | 1 | 2.366 | 2.806 | 3.025 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 2 | 2.37 | 2.587 | 2.789 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 3 | 2.825 | 2.587 | 3.299 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 4 | 3.09 | 2.59 | 3.024 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 5 | 3.336 | 2.589 | 3.338 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 6 | 3.544 | 2.596 | 3.189 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 7 | 3.712 | 2.719 | 3.449 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 8 | 4.883 | 2.589 | 2.86 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 9 | 4.817 | 2.589 | 3.355 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 10 | 4.774 | 2.585 | 3.16 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 11 | 4.514 | 2.589 | 3.431 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 12 | 4.097 | 2.587 | 3.111 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 13 | 4.351 | 2.599 | 3.393 | 31% VectorBulkOperationsArray.fill_var_short_arrays_fill | 14 | 4.674 | 2.588 | 3.319 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 15 | 4.981 | 2.586 | 3.542 | 37% VectorBulkOperationsArray.fill_var_short_arrays_fill | 16 | 5.406 | 2.586 | 2.833 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 17 | 5.307 | 2.8 | 3.202 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 18 | 5.093 | 2.811 | 3.051 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 19 | 4.68 | 2.817 | 3.568 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 20 | 4.528 | 2.81 | 3.294 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 21 | 4.633 | 2.814 | 3.589 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 22 | 5.102 | 2.809 | 3.495 | 24% VectorBulkOperationsArray.fill_var_short_arrays_fill | 23 | 5.521 | 2.812 | 3.717 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 24 | 6.205 | 2.813 | 3.094 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 25 | 5.92 | 2.816 | 3.58 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 26 | 4.805 | 2.87 | 3.495 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 27 | 4.744 | 2.815 | 3.712 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 28 | 4.45 | 2.811 | 3.361 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 29 | 4.59 | 2.813 | 3.734 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 30 | 4.781 | 2.812 | 3.589 | 28% VectorBulkOperationsArray.fill_var_short_arrays_fill | 31 | 4.992 | 2.81 | 3.817 | 36% VectorBulkOperationsArray.fill_var_short_arrays_fill | 32 | 5.249 | 2.813 | 3.143 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 33 | 5.205 | 3.285 | 3.323 | 1% VectorBulkOperationsArray.fill_var_short_arrays_fill | 34 | 6.086 | 2.858 | 3.104 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 35 | 4.977 | 2.855 | 3.756 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 36 | 4.71 | 2.864 | 3.39 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 37 | 4.822 | 2.887 | 3.815 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 38 | 5.007 | 2.86 | 3.602 | 26% VectorBulkOperationsArray.fill_var_short_arrays_fill | 39 | 5.197 | 2.865 | 3.806 | 33% VectorBulkOperationsArray.fill_var_short_arrays_fill | 40 | 5.5 | 2.862 | 3.267 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 41 | 5.39 | 2.891 | 3.807 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 42 | 5.358 | 2.864 | 3.527 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 43 | 5.214 | 2.871 | 3.801 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 44 | 4.901 | 2.87 | 3.624 | 26% VectorBulkOperationsArray.fill_var_short_arrays_fill | 45 | 5.014 | 2.861 | 3.782 | 32% VectorBulkOperationsArray.fill_var_short_arrays_fill | 46 | 5.252 | 2.849 | 3.717 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 47 | 5.51 | 2.85 | 3.951 | 39% VectorBulkOperationsArray.fill_var_short_arrays_fill | 48 | 5.92 | 2.848 | 3.227 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 49 | 5.896 | 3.417 | 3.558 | 4% VectorBulkOperationsArray.fill_var_short_arrays_fill | 50 | 5.793 | 3.103 | 3.41 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 51 | 5.485 | 3.138 | 3.979 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 52 | 5.137 | 3.117 | 3.652 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 53 | 5.264 | 3.107 | 4 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 54 | 5.563 | 3.113 | 3.835 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 55 | 5.945 | 3.099 | 4.045 | 31% VectorBulkOperationsArray.fill_var_short_arrays_fill | 56 | 6.402 | 3.124 | 3.537 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 57 | 6.347 | 3.175 | 4.029 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 58 | 6.172 | 3.155 | 3.786 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 59 | 5.785 | 3.129 | 4.039 | 29% VectorBulkOperationsArray.fill_var_short_arrays_fill | 60 | 5.405 | 3.124 | 3.752 | 20% VectorBulkOperationsArray.fill_var_short_arrays_fill | 61 | 5.541 | 3.12 | 4.044 | 30% VectorBulkOperationsArray.fill_var_short_arrays_fill | 62 | 5.921 | 3.132 | 3.987 | 27% VectorBulkOperationsArray.fill_var_short_arrays_fill | 63 | 6.239 | 3.105 | 4.202 | 35% VectorBulkOperationsArray.fill_var_short_arrays_fill | 64 | 6.891 | 3.146 | 3.13 | -1% VectorBulkOperationsArray.fill_var_short_arrays_fill | 65 | 6.81 | 4.559 | 5.07 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 66 | 6.489 | 4.523 | 5.084 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 67 | 6.116 | 4.413 | 5.069 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 68 | 5.669 | 4.462 | 5.06 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 69 | 5.838 | 4.408 | 5.084 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 70 | 6.618 | 4.386 | 5.037 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 71 | 6.249 | 4.407 | 5.054 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 72 | 6.183 | 4.295 | 5.055 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 73 | 6.289 | 4.362 | 4.885 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 74 | 6.678 | 4.232 | 4.958 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 75 | 6.909 | 4.219 | 4.989 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 76 | 7.098 | 4.207 | 4.978 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 77 | 7.463 | 4.152 | 4.96 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 78 | 7.66 | 4.113 | 4.976 | 21% VectorBulkOperationsArray.fill_var_short_arrays_fill | 79 | 8.058 | 4.079 | 4.844 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 80 | 7.933 | 4.167 | 4.884 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 81 | 7.713 | 4.189 | 4.895 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 82 | 7.562 | 4.171 | 4.946 | 19% VectorBulkOperationsArray.fill_var_short_arrays_fill | 83 | 7.507 | 4.241 | 4.979 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 84 | 7.252 | 4.252 | 4.958 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 85 | 7.195 | 4.277 | 5 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 86 | 6.871 | 4.293 | 5.004 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 87 | 6.884 | 4.313 | 4.996 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 88 | 6.754 | 4.338 | 5.029 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 89 | 6.711 | 4.36 | 5.017 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 90 | 7.157 | 4.393 | 5.058 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 91 | 7.299 | 4.281 | 5.062 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 92 | 7.467 | 4.435 | 5.017 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 93 | 7.706 | 4.426 | 5.133 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 94 | 7.957 | 4.491 | 5.101 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 95 | 8.253 | 4.475 | 5.139 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 96 | 8.396 | 4.507 | 5.128 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 97 | 8.14 | 4.522 | 5.146 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 98 | 7.935 | 4.564 | 5.172 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 99 | 7.859 | 4.575 | 5.208 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 100 | 7.769 | 4.555 | 5.223 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 101 | 7.533 | 4.587 | 5.212 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 102 | 7.593 | 4.606 | 5.236 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 103 | 7.363 | 4.606 | 5.264 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 104 | 7.355 | 4.639 | 5.257 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 105 | 7.645 | 4.659 | 5.191 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 106 | 8.041 | 4.668 | 5.302 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 107 | 7.872 | 4.682 | 5.322 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 108 | 8.339 | 4.729 | 5.303 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 109 | 8.609 | 4.703 | 5.313 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 110 | 8.804 | 4.74 | 5.347 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 111 | 9.058 | 4.737 | 5.377 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 112 | 9.164 | 4.767 | 5.366 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 113 | 8.673 | 4.637 | 5.455 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 114 | 8.537 | 4.695 | 5.479 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 115 | 8.438 | 4.694 | 5.458 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 116 | 8.232 | 4.706 | 5.458 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 117 | 8.019 | 4.689 | 5.465 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 118 | 8.089 | 4.719 | 5.483 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 119 | 8.155 | 4.727 | 5.544 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 120 | 7.936 | 4.747 | 5.495 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 121 | 7.986 | 4.764 | 5.521 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 122 | 8.168 | 4.845 | 5.541 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 123 | 8.551 | 4.784 | 5.546 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 124 | 8.753 | 4.845 | 5.522 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 125 | 9.028 | 4.822 | 5.553 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 126 | 9.26 | 4.864 | 5.596 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 127 | 9.523 | 4.817 | 5.574 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 128 | 9.654 | 4.8 | 5.492 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 129 | 9.299 | 4.74 | 5.464 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 130 | 9.143 | 4.705 | 5.479 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 131 | 8.721 | 4.685 | 5.451 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 132 | 8.761 | 4.433 | 5.409 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 133 | 8.424 | 4.624 | 5.412 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 134 | 8.232 | 4.599 | 5.379 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 135 | 7.991 | 4.579 | 5.364 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 136 | 7.915 | 4.555 | 5.345 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 137 | 7.843 | 4.527 | 5.319 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 138 | 7.997 | 4.477 | 5.297 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 139 | 8.433 | 4.476 | 5.245 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 140 | 8.673 | 4.41 | 5.21 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 141 | 8.918 | 4.391 | 5.186 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 142 | 9.272 | 4.374 | 5.183 | 18% VectorBulkOperationsArray.fill_var_short_arrays_fill | 143 | 9.421 | 4.364 | 5.05 | 16% VectorBulkOperationsArray.fill_var_short_arrays_fill | 144 | 9.629 | 4.345 | 5.087 | 17% VectorBulkOperationsArray.fill_var_short_arrays_fill | 145 | 9.233 | 4.453 | 5.078 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 146 | 9.039 | 4.209 | 5.172 | 23% VectorBulkOperationsArray.fill_var_short_arrays_fill | 147 | 9.008 | 4.532 | 5.175 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 148 | 8.763 | 4.505 | 5.147 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 149 | 8.992 | 4.584 | 5.258 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 150 | 9.294 | 4.562 | 5.221 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 151 | 9.258 | 4.582 | 5.215 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 152 | 9.516 | 4.582 | 5.213 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 153 | 9.672 | 4.632 | 5.216 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 154 | 9.997 | 4.664 | 5.265 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 155 | 10.182 | 4.673 | 5.255 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 156 | 10.651 | 4.671 | 5.272 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 157 | 11.081 | 4.705 | 5.293 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 158 | 10.959 | 4.794 | 5.315 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 159 | 11.202 | 4.836 | 5.308 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 160 | 11.309 | 4.799 | 5.356 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 161 | 11.023 | 4.816 | 5.352 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 162 | 10.758 | 4.936 | 5.358 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 163 | 10.594 | 4.393 | 5.37 | 22% VectorBulkOperationsArray.fill_var_short_arrays_fill | 164 | 10.48 | 4.938 | 5.417 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 165 | 10.375 | 4.919 | 5.433 | 10% VectorBulkOperationsArray.fill_var_short_arrays_fill | 166 | 10.345 | 4.875 | 5.42 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 167 | 10.514 | 4.911 | 5.454 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 168 | 10.633 | 4.912 | 5.472 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 169 | 10.114 | 4.925 | 5.48 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 170 | 10.069 | 4.973 | 5.51 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 171 | 9.514 | 5.015 | 5.485 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 172 | 9.408 | 5.08 | 5.499 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 173 | 9.071 | 5.056 | 5.534 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 174 | 8.896 | 5.065 | 5.531 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 175 | 8.56 | 5.109 | 5.532 | 8% VectorBulkOperationsArray.fill_var_short_arrays_fill | 176 | 8.453 | 5.099 | 5.533 | 9% VectorBulkOperationsArray.fill_var_short_arrays_fill | 177 | 8.525 | 4.979 | 5.606 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 178 | 8.782 | 4.98 | 5.663 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 179 | 8.944 | 5.012 | 5.619 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 180 | 9.08 | 5.018 | 5.646 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 181 | 9.239 | 5.037 | 5.678 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 182 | 9.36 | 5.057 | 5.686 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 183 | 9.658 | 5.052 | 5.667 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 184 | 9.994 | 5.085 | 5.669 | 11% VectorBulkOperationsArray.fill_var_short_arrays_fill | 185 | 9.996 | 5.08 | 5.703 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 186 | 10.3 | 5.103 | 5.735 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 187 | 10.674 | 5.11 | 5.717 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 188 | 10.753 | 5.101 | 5.723 | 12% VectorBulkOperationsArray.fill_var_short_arrays_fill | 189 | 10.936 | 5.098 | 5.776 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 190 | 11.206 | 5.101 | 5.75 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 191 | 11.383 | 5.099 | 5.788 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 192 | 11.619 | 5.084 | 5.727 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 193 | 11.266 | 5.032 | 5.702 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 194 | 11.263 | 4.976 | 5.678 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 195 | 11.172 | 4.997 | 5.658 | 13% VectorBulkOperationsArray.fill_var_short_arrays_fill | 196 | 10.891 | 4.962 | 5.633 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 197 | 11.311 | 4.907 | 5.588 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 198 | 11.486 | 4.887 | 5.552 | 14% VectorBulkOperationsArray.fill_var_short_arrays_fill | 199 | 11.348 | 4.874 | 5.623 | 15% VectorBulkOperationsArray.fill_var_short_arrays_fill | 200 | 11.102 | 4.823 | 5.511 | 14% `[Continued]` ### Int VectorBulkOperationsArray Fill Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) -- | -- | -- | -- | -- | -- VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 26 | 5.069 | 3.015 | 3.63 | 17% VectorBulkOperationsArray.fill_var_int_arrays_fill | 27 | 5.125 | 3.106 | 3.858 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 28 | 4.759 | 3.111 | 3.514 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 29 | 4.796 | 3.115 | 3.841 | 19% VectorBulkOperationsArray.fill_var_int_arrays_fill | 30 | 5.129 | 3.127 | 3.71 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 31 | 5.671 | 3.247 | 3.97 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 32 | 5.401 | 3.122 | 3.518 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 33 | 5.364 | 4.224 | 4.905 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 34 | 5.231 | 4.189 | 4.877 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 35 | 5.093 | 4.213 | 4.853 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 36 | 4.911 | 4.083 | 4.779 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 37 | 5.045 | 4.088 | 4.699 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 38 | 5.331 | 4.068 | 4.728 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 39 | 5.491 | 4.117 | 4.675 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 40 | 5.741 | 4.077 | 4.596 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 41 | 5.706 | 4.133 | 4.804 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 42 | 5.544 | 4.172 | 4.819 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 43 | 5.32 | 4.233 | 4.811 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 44 | 5.144 | 4.261 | 4.733 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 45 | 5.258 | 4.324 | 4.847 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 46 | 5.49 | 4.337 | 4.885 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 47 | 5.736 | 4.414 | 4.938 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 48 | 5.957 | 4.274 | 4.963 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 49 | 6.035 | 4.442 | 4.96 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 50 | 5.753 | 4.46 | 5.031 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 51 | 5.622 | 4.486 | 5.124 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 52 | 5.407 | 4.491 | 5.132 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 53 | 5.524 | 4.518 | 5.181 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 54 | 5.717 | 4.536 | 5.186 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 55 | 5.971 | 4.557 | 5.139 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 56 | 6.209 | 4.586 | 5.203 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 57 | 6.07 | 4.672 | 5.35 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 58 | 6.041 | 4.64 | 5.37 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 59 | 6.18 | 4.663 | 5.123 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 60 | 5.638 | 4.709 | 5.349 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 61 | 5.751 | 4.724 | 5.398 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 62 | 6.056 | 4.756 | 5.426 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 63 | 6.295 | 4.743 | 5.454 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 64 | 6.523 | 4.639 | 5.288 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 65 | 6.432 | 4.597 | 5.332 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 66 | 6.407 | 4.537 | 5.054 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 67 | 6.12 | 4.533 | 5.19 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 68 | 5.881 | 4.424 | 5.094 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 69 | 5.981 | 4.357 | 5.028 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 70 | 6.133 | 4.309 | 4.88 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 71 | 5.996 | 4.243 | 4.861 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 72 | 5.719 | 4.29 | 4.905 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 73 | 5.977 | 4.352 | 4.975 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 74 | 7.849 | 4.391 | 4.99 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 75 | 6.44 | 4.481 | 5.051 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 76 | 6.729 | 4.479 | 5.1 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 77 | 7.092 | 4.524 | 5.156 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 78 | 7.269 | 4.56 | 5.109 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 79 | 7.464 | 4.62 | 5.131 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 80 | 7.634 | 4.669 | 5.167 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 81 | 7.284 | 4.673 | 5.064 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 82 | 7.157 | 4.671 | 5.227 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 83 | 7.003 | 4.698 | 5.271 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 84 | 6.67 | 4.723 | 5.283 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 85 | 6.752 | 4.793 | 5.812 | 18% VectorBulkOperationsArray.fill_var_int_arrays_fill | 86 | 6.41 | 4.742 | 5.329 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 87 | 6.21 | 4.801 | 5.404 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 88 | 6.07 | 4.798 | 5.398 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 89 | 6.405 | 4.863 | 5.482 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 90 | 6.516 | 4.885 | 5.566 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 91 | 6.705 | 4.912 | 5.565 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 92 | 7.511 | 4.913 | 5.587 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 93 | 7.492 | 4.942 | 5.595 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 94 | 7.565 | 4.978 | 5.62 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 95 | 8.017 | 5.016 | 5.667 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 96 | 8.022 | 4.841 | 5.558 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 97 | 7.767 | 4.793 | 5.536 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 98 | 7.496 | 4.98 | 5.91 | 16% VectorBulkOperationsArray.fill_var_int_arrays_fill | 99 | 7.354 | 4.849 | 5.363 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 100 | 7.106 | 4.649 | 5.312 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 101 | 7.083 | 4.583 | 5.265 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 102 | 6.838 | 4.528 | 5.221 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 103 | 6.752 | 4.457 | 5.099 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 104 | 6.588 | 4.508 | 5.164 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 105 | 6.844 | 4.663 | 5.209 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 106 | 7.066 | 4.617 | 5.262 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 107 | 7.151 | 4.677 | 5.31 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 108 | 7.388 | 4.716 | 5.347 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 109 | 8.063 | 4.796 | 5.369 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 110 | 8.167 | 4.783 | 5.412 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 111 | 8.376 | 4.848 | 5.438 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 112 | 8.389 | 4.885 | 5.481 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 113 | 8.096 | 4.867 | 5.49 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 114 | 7.874 | 4.896 | 5.527 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 115 | 7.707 | 5.061 | 5.586 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 116 | 7.709 | 4.959 | 5.606 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 117 | 7.364 | 4.985 | 5.596 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 118 | 7.32 | 4.981 | 5.638 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 119 | 7.379 | 5.003 | 5.726 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 120 | 6.683 | 5.034 | 5.664 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 121 | 6.902 | 5.061 | 5.732 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 122 | 7.208 | 5.092 | 5.794 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 123 | 7.53 | 5.151 | 5.803 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 124 | 7.471 | 5.135 | 5.817 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 125 | 7.973 | 5.185 | 5.859 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 126 | 8.17 | 5.22 | 5.868 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 127 | 8.439 | 5.252 | 5.917 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 128 | 8.593 | 5.079 | 5.767 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 129 | 8.162 | 5.07 | 5.735 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 130 | 8.201 | 4.995 | 5.655 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 131 | 7.848 | 4.935 | 5.606 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 132 | 7.817 | 4.88 | 5.593 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 133 | 7.584 | 4.821 | 5.491 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 134 | 7.299 | 4.768 | 5.473 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 135 | 6.985 | 4.701 | 5.402 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 136 | 6.817 | 4.724 | 5.47 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 137 | 6.95 | 4.794 | 5.493 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 138 | 7.189 | 4.908 | 5.551 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 139 | 7.439 | 4.906 | 5.562 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 140 | 7.666 | 4.951 | 5.582 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 141 | 7.96 | 5.006 | 5.63 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 142 | 8.354 | 5.043 | 5.715 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 143 | 8.466 | 5.1 | 5.727 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 144 | 8.647 | 5.117 | 5.794 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 145 | 8.286 | 5.111 | 5.81 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 146 | 8.152 | 5.126 | 5.924 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 147 | 7.915 | 5.144 | 5.9 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 148 | 7.652 | 5.147 | 5.943 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 149 | 7.572 | 5.216 | 5.975 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 150 | 7.522 | 5.19 | 6.001 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 151 | 7.51 | 5.217 | 6.077 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 152 | 7.513 | 5.247 | 6.072 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 153 | 7.478 | 5.296 | 6.112 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 154 | 7.543 | 5.311 | 6.173 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 155 | 7.544 | 5.32 | 6.243 | 15% VectorBulkOperationsArray.fill_var_int_arrays_fill | 156 | 7.582 | 5.386 | 6.156 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 157 | 7.624 | 5.415 | 6.201 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 158 | 7.608 | 5.452 | 6.193 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 159 | 7.661 | 5.495 | 6.146 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 160 | 7.649 | 5.313 | 5.874 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 161 | 7.658 | 5.457 | 5.973 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 162 | 7.677 | 5.286 | 5.964 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 163 | 7.859 | 5.29 | 5.884 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 164 | 7.934 | 5.216 | 5.827 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 165 | 7.814 | 5.19 | 5.776 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 166 | 7.84 | 5.785 | 5.72 | -1% VectorBulkOperationsArray.fill_var_int_arrays_fill | 167 | 7.82 | 5.175 | 5.683 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 168 | 7.778 | 5.26 | 5.814 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 169 | 7.758 | 5.239 | 5.849 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 170 | 7.874 | 5.347 | 5.98 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 171 | 7.922 | 5.383 | 5.933 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 172 | 7.959 | 5.459 | 5.989 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 173 | 7.995 | 5.455 | 6.031 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 174 | 7.998 | 5.661 | 5.813 | 3% VectorBulkOperationsArray.fill_var_int_arrays_fill | 175 | 9.418 | 5.573 | 6.086 | 8% VectorBulkOperationsArray.fill_var_int_arrays_fill | 176 | 8.142 | 6.055 | 6.156 | 2% VectorBulkOperationsArray.fill_var_int_arrays_fill | 177 | 8.228 | 5.691 | 6.241 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 178 | 8.272 | 5.645 | 6.281 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 179 | 8.241 | 5.617 | 5.961 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 180 | 8.244 | 5.672 | 6.456 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 181 | 8.427 | 5.646 | 6.487 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 182 | 8.072 | 5.933 | 6.497 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 183 | 8.164 | 5.719 | 6.539 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 184 | 8.063 | 5.703 | 6.646 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 185 | 8.083 | 5.722 | 6.627 | 14% VectorBulkOperationsArray.fill_var_int_arrays_fill | 186 | 8.084 | 5.844 | 6.722 | 13% VectorBulkOperationsArray.fill_var_int_arrays_fill | 187 | 8.118 | 5.881 | 6.701 | 12% VectorBulkOperationsArray.fill_var_int_arrays_fill | 188 | 8.18 | 5.943 | 6.688 | 11% VectorBulkOperationsArray.fill_var_int_arrays_fill | 189 | 8 | 6.03 | 6.668 | 10% VectorBulkOperationsArray.fill_var_int_arrays_fill | 190 | 8.18 | 6.104 | 6.728 | 9% VectorBulkOperationsArray.fill_var_int_arrays_fill | 191 | 8.158 | 6.229 | 6.712 | 7% VectorBulkOperationsArray.fill_var_int_arrays_fill | 192 | 8.069 | 6.14 | 6.457 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 193 | 8.277 | 6.052 | 6.429 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 194 | 8.327 | 6.074 | 6.37 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 195 | 8.453 | 5.951 | 6.293 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 196 | 8.438 | 5.902 | 6.234 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 197 | 8.485 | 5.857 | 6.2 | 6% VectorBulkOperationsArray.fill_var_int_arrays_fill | 198 | 8.458 | 5.754 | 6.082 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 199 | 8.251 | 5.742 | 6.068 | 5% VectorBulkOperationsArray.fill_var_int_arrays_fill | 200 | 8.242 | 5.799 | 5.986 | 3% `----- END --------` ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786553267 PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3786558614 From duke at openjdk.org Thu Jan 22 20:51:32 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 22 Jan 2026 20:51:32 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Thu, 22 Jan 2026 00:41:13 GMT, Justin Lu wrote: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java line 52: > 50: private static final String CONNECTION_CLASS_NAME = "com.luckydogtennis.StubConnection"; > 51: > 52: @BeforeAll seems that setUpClass, tearDownClass, setUpMethod, tearDownMethod can be removed ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2718580673 From duke at openjdk.org Thu Jan 22 20:55:23 2026 From: duke at openjdk.org (Johannes =?UTF-8?B?RMO2Ymxlcg==?=) Date: Thu, 22 Jan 2026 20:55:23 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: <8kA7V2u-PisHbRwbe_7d-XDU1inhMHTK2sz1zLDDQVA=.85dc19a8-062f-4176-aa13-4c5b9fcd0c47@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> <8kA7V2u-PisHbRwbe_7d-XDU1inhMHTK2sz1zLDDQVA=.85dc19a8-062f-4176-aa13-4c5b9fcd0c47@github.com> Message-ID: <_U0qObXIeeeUDElcWeene7OY3tS8OgEr01c_-uY4C_c=.c47aabd3-2496-4241-bbd8-c90bc2fd8aa2@github.com> On Thu, 22 Jan 2026 14:57:16 GMT, Lance Andersen wrote: >> Please review this PR which converts the JDBC TestNG tests to use JUnit. >> >> This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. >> >> Framework test stats before: >> 680 = 680 TestNG + 0 JUnit >> >> Framework test stats after: >> 680 = 0 TestNG + 680 JUnit > > test/jdk/java/sql/junit/test/sql/CallableStatementTests.java line 135: > >> 133: @Test >> 134: public void test08() throws SQLException { >> 135: Assertions.assertThrows(NullPointerException.class, () -> cstmt.enquoteNCharLiteral(null)); > > Maybe use an import so we can shorten to just assertThrow? Justin mentioned that the bulk refactoring was done by an automated tool, so maybe this could be moved to that tool too? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2718593641 From duke at openjdk.org Thu Jan 22 21:45:36 2026 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 22 Jan 2026 21:45:36 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v5] In-Reply-To: References: Message-ID: <0fhR-jmXGNfkqXDhpysfOXl0fTmHnVXAzupT5IoI37E=.f459aea6-4ca8-455b-953a-ec97ef5a013e@github.com> > 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 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: - 8370688: Updated the documentation to describe the behavior using @implSpec - Merge branch 'master' into 8370688 - 8370688: Addressed review comments-removed this method in the return label - 8370688: Addressed review comments-moved the sentence to return label - 8370688: Addressed review comments - add explicit note similar to SSLParameters - 8370688: Addressed review comments - 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28615/files - new: https://git.openjdk.org/jdk/pull/28615/files/cc77e339..548af3e6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=03-04 Stats: 117807 lines in 3863 files changed: 67264 ins; 24612 del; 25931 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 Jan 22 21:54:35 2026 From: duke at openjdk.org (Koushik Muthukrishnan Thirupattur) Date: Thu, 22 Jan 2026 21:54:35 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v6] In-Reply-To: References: Message-ID: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> > 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: Updated the documentation to describe the behavior using @implSpec ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28615/files - new: https://git.openjdk.org/jdk/pull/28615/files/548af3e6..753154a3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28615&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 henryjen at openjdk.org Thu Jan 22 22:46:53 2026 From: henryjen at openjdk.org (Henry Jen) Date: Thu, 22 Jan 2026 22:46:53 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp Message-ID: I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). This PR implements proper cleanup for decompressors to be defensive. ------------- Commit messages: - 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp:90 (ID: 34500) Changes: https://git.openjdk.org/jdk/pull/29371/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373924 Stats: 13 lines in 2 files changed: 9 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From liach at openjdk.org Thu Jan 22 23:22:23 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 Jan 2026 23:22:23 GMT Subject: RFR: 8375649: idea.sh script adds source paths in a single, enormous, line to jdk.iml In-Reply-To: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> References: <8VKFvGh68jUTy_zfGyXsDUS9qu-vxOQ0bbWEnkMrcXU=.a0ad4c14-4181-4752-9780-cdcef5f8a1a2@github.com> Message-ID: On Mon, 19 Jan 2026 17:23:10 GMT, David Beaumont wrote: > Allow replacement string to contain embedded newlines to split entries. > This turns output like: > > > > ... another 10k chars on the end of this line ... > > > into: > > > > > > ... one entry per line ... Sure, I think someone who revisit that template will notice this bash and update here too :) ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29305#pullrequestreview-3695031056 From liach at openjdk.org Thu Jan 22 23:50:30 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 22 Jan 2026 23:50:30 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v6] In-Reply-To: References: Message-ID: On Thu, 25 Dec 2025 02:01:31 GMT, Shaojin Wen wrote: >> 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 requested by liach (Reviewer). src/java.base/share/classes/jdk/internal/util/HexDigits.java line 157: > 155: * > 156: * > 157: */ Documentation here is too long, hard for reading. I recommend something simple like: Prints an unsigned 4-byte number into 8 hexadecimal digits in an ASCII character buffer. The buffer is represented as a big-endian 8 byte integer. Input: 0xA__B__C__D__E__F__0__1 Output: 0x61_62_63_64_65_66_30_31 You can just use `///` to write markdown, which is easier to read too. The performance tricks are in the method already, so I think you can drop them. Also, let's rename this method to `hex8Be` to indicate the return result is big endian, and change the input type to `int` to indicate only the int bits are used. src/java.base/share/classes/jdk/internal/util/HexDigits.java line 181: > 179: long m = (i + 0x0606_0606_0606_0606L) & 0x1010_1010_1010_1010L; > 180: > 181: // Calculate final ASCII values and reverse bytes for proper ordering Outdated comments, you no longer reverse the bytes ------------- PR Review: https://git.openjdk.org/jdk/pull/22942#pullrequestreview-3695099240 PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2719048886 PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2719051562 From liach at openjdk.org Fri Jan 23 00:01:11 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 00:01:11 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v25] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 01:31:27 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 with a new target base due to a merge or a rebase. The pull request now contains 44 commits: > > - Merge branch 'master' into optim_parse_int_long_202501 > - remove unsafe > - 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 > - ... and 34 more: https://git.openjdk.org/jdk/compare/a0ac5b34...90778ed9 src/java.base/share/classes/java/lang/Integer.java line 488: > 486: byte[] value; > 487: if (s == null || radix != 10 || (len = (value = s.value()).length) == 0 || !s.isLatin1()) { > 488: return parseInt0(s, radix); I think you should put radix == 10 optimized code in `parseInt(String)` and redirect `radix == 10` there instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r2719080379 From liach at openjdk.org Fri Jan 23 00:08:52 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 00:08:52 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:14:49 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 I think this PR should be separated into at least 2 PRs to help review: 1. Create `unscaledString`, `scale2`, `getCompactValueString`, `layoutCharsE`, without adding new use of `byte[]`/LATIN1 optimizations; This PR should make the logical updates clear, and there would be no security risk in this patch. 2. The string performance tricks using `uncheckedXxx` and `byte[]` ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/23310#pullrequestreview-3695174105 From liach at openjdk.org Fri Jan 23 00:14:18 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 00:14:18 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 Just noted the Map is passed to both: 1. `Chronology.resolveDate(Map, ResolverStyle)` 2. `TemporalField.resolve(Map, TemporalAccessor, ResolverStyle)` We need to ensure there is no custom `Chronology` for this optimization. ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28471#pullrequestreview-3695184550 From liach at openjdk.org Fri Jan 23 00:17:56 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 00:17:56 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 this wide exposure, I think we might still go back to a custom Map - `Parsed` has little control over Chronology. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28471#issuecomment-3787511735 From swen at openjdk.org Fri Jan 23 01:30:31 2026 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 23 Jan 2026 01:30:31 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v7] 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: from liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22942/files - new: https://git.openjdk.org/jdk/pull/22942/files/d896e365..0c487d3e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=05-06 Stats: 75 lines in 4 files changed: 0 ins; 58 del; 17 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 liach at openjdk.org Fri Jan 23 02:28:09 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 02:28:09 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v7] In-Reply-To: References: Message-ID: <2HNFeIYEk3u3UD915TwbSQ-3Ee1kj7fLf9x-EHK1BdU=.dcc5fc7c-e46c-4d07-8975-c5eae41cc837@github.com> On Fri, 23 Jan 2026 01:30:31 GMT, Shaojin Wen wrote: >> 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: > > from liach src/java.base/share/classes/java/lang/Long.java line 313: > 311: int mag = Long.SIZE - Long.numberOfLeadingZeros(i); > 312: int len = Math.max(((mag + 3) >> 2), 1); > 313: long x = HexDigits.hex8Be((int)i); Suggestion: long x = HexDigits.hex8Be((int) i); src/java.base/share/classes/java/lang/Long.java line 319: > 317: len -= 8; > 318: Unsafe.getUnsafe().putLongUnaligned(chars, Unsafe.ARRAY_BYTE_BASE_OFFSET + len, x, true); > 319: x = HexDigits.hex8Be((int)(i >>> 32)); Suggestion: x = HexDigits.hex8Be((int) (i >>> 32)); Similar indents elsewhere. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2719343056 PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2719343405 From swen at openjdk.org Fri Jan 23 03:42:47 2026 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 23 Jan 2026 03:42:47 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v26] 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: from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/90778ed9..6c770a89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=25 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=24-25 Stats: 126 lines in 2 files changed: 62 ins; 56 del; 8 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 swen at openjdk.org Fri Jan 23 03:44:38 2026 From: swen at openjdk.org (Shaojin Wen) Date: Fri, 23 Jan 2026 03:44:38 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v8] 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 two additional commits since the last revision: - Update src/java.base/share/classes/java/lang/Long.java Co-authored-by: Chen Liang - Update src/java.base/share/classes/java/lang/Long.java Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22942/files - new: https://git.openjdk.org/jdk/pull/22942/files/0c487d3e..53dd387f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=06-07 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 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 Fri Jan 23 04:24:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 04:24:57 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] 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: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/fe7075ee..72d15568 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=12-13 Stats: 1415 lines in 52 files changed: 441 ins; 259 del; 715 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 Fri Jan 23 05:01:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 05:01:46 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> Message-ID: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> On Wed, 21 Jan 2026 07:01:39 GMT, Jatin Bhateja wrote: >> @jatin-bhateja Thanks for the ping! I'll put this on the list for review early in 2026 :) > > Hi @eme64 , Your comments have been addressed > @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) Hi @eme64 , I have done some cleanups, following is the summary of changes included with the patch:- ``` 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... 5 Changes in the LaneType to add a new carrier type field. 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. 8 New IR verification test. 9 New Micro-benchmark. 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. Out of above change 7b consumes 40000+ LOC. Q. Why do we need wrapper assertions ? A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers I think all the tasks are related and since most of source/test are generated using scripts we should not go by the size of patch and review the templates files. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3788233245 From dholmes at openjdk.org Fri Jan 23 06:33:34 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 23 Jan 2026 06:33:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name I was hoping one of our container experts would jump in, but this seems okay. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3695895003 From jbhateja at openjdk.org Fri Jan 23 06:34:00 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 06:34:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: > 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 ... Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24104/files - new: https://git.openjdk.org/jdk/pull/24104/files/2c7eb96d..ae242926 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24104&range=10-11 Stats: 23 lines in 10 files changed: 4 ins; 12 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/24104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24104/head:pull/24104 PR: https://git.openjdk.org/jdk/pull/24104 From jbhateja at openjdk.org Fri Jan 23 06:34:02 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 23 Jan 2026 06:34:02 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v11] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 09:42:06 GMT, Xiaohong Gong wrote: >> Jatin Bhateja 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: >> >> Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8303762 > > Overall, looks good to me; I?ve just left a few minor comments. Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3788537143 From jlahoda at openjdk.org Fri Jan 23 07:43:56 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 Jan 2026 07:43:56 GMT Subject: Integrated: 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases In-Reply-To: References: Message-ID: On Tue, 13 Jan 2026 18:05:43 GMT, Jan Lahoda wrote: > The `SwitchBootstraps.enumSwitch` is documented to throw a `NullPointerException` when `lookup` is `null`, but it does not throw the exception in all cases. > > Given the `lookup` is in some cases required, the proposal herein is to properly check `lookup` is not `null`. And while doing that, I added similar checks for `invocationType` and `labels` - those were checked implicitly, but doing the check explicitly is better. Note `invocationName` is unused and is permitted to be `null`, and hence there's no check for it. > > Please also review the CSR: > https://bugs.openjdk.org/browse/JDK-8375120 This pull request has now been integrated. Changeset: 315bf07b Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/315bf07b23ad6c5f86fc8fe976abd9e9a8548404 Stats: 41 lines in 2 files changed: 35 ins; 0 del; 6 mod 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/29202 From jlahoda at openjdk.org Fri Jan 23 07:50:52 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 Jan 2026 07:50:52 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v2] In-Reply-To: References: Message-ID: > This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. > > Thanks! Jan Lahoda 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/29350/files - new: https://git.openjdk.org/jdk/pull/29350/files/7ea77d11..7ea77d11 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29350&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29350&range=00-01 Stats: 0 lines in 0 files changed: 0 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29350.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29350/head:pull/29350 PR: https://git.openjdk.org/jdk/pull/29350 From epeter at openjdk.org Fri Jan 23 08:11:15 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 08:11:15 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:30:26 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > ### Int VectorBulkOperationsArray Fill > > Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) > -- | -- | -- | -- | -- | -- > VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% > VectorBulkOperationsArray.fill_var_... > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? > > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3788945532 From jlahoda at openjdk.org Fri Jan 23 08:11:13 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 Jan 2026 08:11:13 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:51:56 GMT, Johannes D?bler wrote: >> Jan Lahoda 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. > > test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 64: > >> 62: @Test >> 63: public void testByte() { >> 64: assertEquals(true, ExactConversionsSupport.isIntToByteExact((byte) (Byte.MAX_VALUE))); > > could be shortened to assertTrue(Exact...)`` I took a look at the test, and it seems to me it was written like this intentionally, and that it makes it more obvious what is happening here. This is not a simple assert that something worked (or did not work). This asserts that the return value is exactly this. There's no real difference, of course, but the intent is slightly different. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2720058203 From jlahoda at openjdk.org Fri Jan 23 08:11:15 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 Jan 2026 08:11:15 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 20:07:20 GMT, Chen Liang wrote: >> test/jdk/java/lang/runtime/SwitchBootstrapsTest.java line 161: >> >>> 159: testEnum(E1.B, 1, 3, "B", "C", "A", E1.class); >>> 160: assertThrows(IllegalArgumentException.class, () -> >>> 161: testEnum(E1.B, 0, -1, E2.class) >> >> for readability it could be worth to add a helper method >> `testEnumError(Class exceptionClass, Enum target, int start, int result, Object... labels)` > > The `start` and `result` arguments here are completely unused. TBH, I am not sure if that's more readable. It might be shorter, but it is one more hoop to go through when trying to understand what the test is doing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2720052217 From abimpoudis at openjdk.org Fri Jan 23 08:53:26 2026 From: abimpoudis at openjdk.org (Aggelos Biboudis) Date: Fri, 23 Jan 2026 08:53:26 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 19:43:36 GMT, Chen Liang wrote: >> Jan Lahoda 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. > > test/jdk/java/lang/runtime/ExactnessConversionsSupportTest.java line 52: > >> 50: public class ExactnessConversionsSupportTest { >> 51: >> 52: public void main(String[] args) { > > Let's remove this main method altogether. Agreed! ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29350#discussion_r2720279900 From sgehwolf at openjdk.org Fri Jan 23 09:37:34 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:34 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Failing GHA checks are infra related. `git clone` returned `500`... ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789300277 From sgehwolf at openjdk.org Fri Jan 23 09:37:37 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 09:37:37 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v2] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 22:40:12 GMT, Naoto Sato wrote: >> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision: >> >> Update copyright year > > LGTM from i18n point of view. Probably needs more reviews from hotspot side @naotoj Could you please ack this again? The same change, just the bellsoft copyright left untouched. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3789304289 From jlahoda at openjdk.org Fri Jan 23 09:41:58 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Fri, 23 Jan 2026 09:41:58 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v3] In-Reply-To: References: Message-ID: <0iqWqpUeHXU7kutn2Y74f1xnZlxB9o3stJXiTuwqNp0=.4f8b98ee-a956-4eb6-8bb5-8312accc806b@github.com> > This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. > > Thanks! Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: - Updating per review comments. - Merge remote-tracking branch 'upstream/master' into upgrade-java-lang-runtime-to-junit - Removing wrong @Test annotation. - Using assertThrows instead of manual try-catch. - 8375712: Convert java/lang/runtime tests to use JUnit (automatic conversion) - Cleanup. - 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases ------------- Changes: https://git.openjdk.org/jdk/pull/29350/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29350&range=02 Stats: 243 lines in 3 files changed: 33 ins; 101 del; 109 mod Patch: https://git.openjdk.org/jdk/pull/29350.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29350/head:pull/29350 PR: https://git.openjdk.org/jdk/pull/29350 From alanb at openjdk.org Fri Jan 23 09:46:16 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jan 2026 09:46:16 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: <0WeNkgVxfrblFW0HMa7uK37fqnJJxmRAlGm9k41L-7o=.70dc8af9-45d4-435e-9176-0e5f2b05046b@github.com> On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca test/jdk/java/lang/invoke/AccessControlTest.java line 73: > 71: this.lookupModes = lookup.lookupModes(); > 72: > 73: assertEquals(lookupString(), lookup.toString()); Always amusing to see accidental usages like this. As the tests are run with -ea then it was actually effective, just not as intended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2720469992 From alanb at openjdk.org Fri Jan 23 09:52:06 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jan 2026 09:52:06 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca > I un-problemlisted the updated java/lang/invoke/lambda/LambdaFileEncodingSerialization.java too. Was this reverted? The JBS issue suggests there are different configs involved. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28879#issuecomment-3789378529 From alanb at openjdk.org Fri Jan 23 10:07:14 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jan 2026 10:07:14 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca There are a lot of tests/fails in this PR. I skimmed through the diffs and it looks like a good migration, with some good cleanups along the way. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28879#pullrequestreview-3696752690 From epeter at openjdk.org Fri Jan 23 10:18:23 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:23 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <0xRSPGoZtGTXyFJEH5pvABR-qa2UZjNnQ2mXCxbYP4U=.ac7ab717-3adf-4910-a333-dd15b3fedd32@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja Thanks for your response. And thanks for the list of changes included in the patch :) It seems to me, many of these subtasks you mention could be done as separate tasks prior to the Float16Vector and auto-vectorizer work: 1 Changes to introduce a new (custom) basictype T_FLOAT16 - Global Definition. - Skip over handling where ever applicable. And 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. - Inline expander interface changes mainly. And in the below at least changes that don't include the Float16Vector: 3 Changes in abstract and concrete vector class generation templates. 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... Probably also this: 5 Changes in the LaneType to add a new carrier type field. And maybe also this, as long as it is not Float16 specific: 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have auto-vectorization and backend support in place.. For `7`, probably only the `7b` part, since `7a` is about Float16Vector. 7 Changes in test generation templates. b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not part of Java SE math libraries. Parts 8, 9, 10 seem Float16Vector specific, so those should stay here. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789507594 From epeter at openjdk.org Fri Jan 23 10:18:26 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 23 Jan 2026 10:18:26 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v14] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 04:24:57 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: > > Refactoring and cleanups The goal of separating these is that reviewing is much easier, and so we can reach a higher confidence in the quality of the code. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3789510739 From varadam at openjdk.org Fri Jan 23 10:51:18 2026 From: varadam at openjdk.org (Varada M) Date: Fri, 23 Jan 2026 10:51:18 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v5] In-Reply-To: References: Message-ID: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> > 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) Varada M has updated the pull request incrementally with two additional commits since the last revision: - 8371187: [BigEndian Platforms] Vector lane reversal error - 8371187: [BigEndian Platforms] Vector lane reversal error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28425/files - new: https://git.openjdk.org/jdk/pull/28425/files/e26a5c89..367cc76e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28425&range=03-04 Stats: 21 lines in 6 files changed: 2 ins; 12 del; 7 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 varadam at openjdk.org Fri Jan 23 10:51:19 2026 From: varadam at openjdk.org (Varada M) Date: Fri, 23 Jan 2026 10:51:19 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 10:30:53 GMT, Martin Doerr wrote: >> I have tried adding the exception but many tests failed! >> what I understood is asVectorRawTemplate is called in many cases which eventually calls swapIfNeeded and exception is thrown for the widening cases. When we reinterpret smaller elements into larger ones we don't need to swap elements so we could opt out. > > Ok, a comment would be helpful. same type and widening reinterpret cases are handled here itself. returns this; in swapIfNeeded ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28425#discussion_r2720702055 From liach at openjdk.org Fri Jan 23 11:17:40 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 11:17:40 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 09:49:07 GMT, Alan Bateman wrote: > Was this reverted? The JBS issue suggests there are different configs involved. Oh, I meant that locally, I un-problemlisted the test and ran the migrated test in a linux-x64 build, and it works. I kept the PL; hope this makes future un-problemlisting easier. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28879#issuecomment-3789769457 From liach at openjdk.org Fri Jan 23 11:18:46 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 11:18:46 GMT Subject: RFR: 8375712: Convert java/lang/runtime tests to use JUnit [v3] In-Reply-To: <0iqWqpUeHXU7kutn2Y74f1xnZlxB9o3stJXiTuwqNp0=.4f8b98ee-a956-4eb6-8bb5-8312accc806b@github.com> References: <0iqWqpUeHXU7kutn2Y74f1xnZlxB9o3stJXiTuwqNp0=.4f8b98ee-a956-4eb6-8bb5-8312accc806b@github.com> Message-ID: <6K-dtrkg2IpQgF7KqUD0GrRY__jMt_KyivkASNOlJIo=.f814f846-a5a9-46ce-9d8c-c973dad4d728@github.com> On Fri, 23 Jan 2026 09:41:58 GMT, Jan Lahoda wrote: >> This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. >> >> Thanks! > > Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits: > > - Updating per review comments. > - Merge remote-tracking branch 'upstream/master' into upgrade-java-lang-runtime-to-junit > - Removing wrong @Test annotation. > - Using assertThrows instead of manual try-catch. > - 8375712: Convert java/lang/runtime tests to use JUnit > (automatic conversion) > - Cleanup. > - 8375119: SwitchBoostraps.enumSwitch does not throw an NPE when lookup is null in some cases Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29350#pullrequestreview-3697019574 From vklang at openjdk.org Fri Jan 23 13:13:41 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 Jan 2026 13:13:41 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v28] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 21 Jan 2026 16:35:41 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: > > Try out different approach src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1303: > 1301: U.putReferenceVolatile(this, ARRAY, newArray); > 1302: if (unlock != 1) > 1303: phase = unlock; Not sure if it helps, but if we can piggyback on the volatile write to phase, then we could structure it like so: if (unlock != 1) { U.putReference(this, ARRAY, newArray); phase = unlock; } else { U.putReferenceVolatile(this, ARRAY, newArray); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2721138435 From mdoerr at openjdk.org Fri Jan 23 13:15:44 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Fri, 23 Jan 2026 13:15:44 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v5] In-Reply-To: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> References: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> Message-ID: On Fri, 23 Jan 2026 10:51:18 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) > > Varada M has updated the pull request incrementally with two additional commits since the last revision: > > - 8371187: [BigEndian Platforms] Vector lane reversal error > - 8371187: [BigEndian Platforms] Vector lane reversal error LGTM. We'll also test it. @offamitkumar: Do you want to retest the latest version? ------------- Marked as reviewed by mdoerr (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28425#pullrequestreview-3697415928 From naoto at openjdk.org Fri Jan 23 13:20:02 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jan 2026 13:20:02 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Looks fine. ------------- Marked as reviewed by naoto (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29315#pullrequestreview-3697432626 From vyazici at openjdk.org Fri Jan 23 13:50:39 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Fri, 23 Jan 2026 13:50:39 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion I'd like to provide some help for reviewers: 1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding` 2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue. 3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210 That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.) [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842 [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210 [JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3790314570 From cushon at openjdk.org Fri Jan 23 14:09:43 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 23 Jan 2026 14:09:43 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon wrote: >> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'JDK-8374654' into JDK-8208752 > - Test cleanup > - Updates for --debug=dumpLambdaDeserializationStats > - Merge branch 'JDK-8374654' into JDK-8208752 > - Merge branch 'JDK-8374654' into JDK-8208752 > - Update test > - Merge branch 'JDK-8374654' into JDK-8208752 > - Don't rely on the iteration order of Map.of entries > - 8208752: Calling a deserialized Lambda might fail with ClassCastException I have drafted a CSR in https://bugs.openjdk.org/browse/JDK-8376198, feedback welcome. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3790409938 From mullan at openjdk.org Fri Jan 23 14:21:37 2026 From: mullan at openjdk.org (Sean Mullan) Date: Fri, 23 Jan 2026 14:21:37 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v6] In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> References: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> Message-ID: On Thu, 22 Jan 2026 21:54:35 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: Updated the documentation to describe the behavior using @implSpec Marked as reviewed by mullan (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3697740377 From cushon at openjdk.org Fri Jan 23 14:28:30 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 23 Jan 2026 14:28:30 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v15] In-Reply-To: References: Message-ID: <0zrTlZ3EhMyHLYXbqHOafsaywNA9TOJbf-2fSs3MPsI=.d60ca8e5-9816-4136-b65b-3cbb1dc1e6ff@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Clarify that "It" in the javadoc means "This method" ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/77bc5b9e..51bf1510 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=13-14 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From liach at openjdk.org Fri Jan 23 14:45:28 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 14:45:28 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v8] In-Reply-To: References: Message-ID: <3x6lP09Ct7Ga2o6lyrjCFwmzUR-hBGSNKK241-QuHpA=.20f8f74e-712c-48a6-b028-9053a56a445a@github.com> On Fri, 23 Jan 2026 03:44:38 GMT, Shaojin Wen wrote: >> 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 two additional commits since the last revision: > > - Update src/java.base/share/classes/java/lang/Long.java > > Co-authored-by: Chen Liang > - Update src/java.base/share/classes/java/lang/Long.java > > Co-authored-by: Chen Liang src/java.base/share/classes/java/util/UUID.java line 532: > 530: ByteArrayLittleEndian.setInt(buf, 19, (int) (x1)); > 531: ByteArrayLittleEndian.setInt(buf, 24, (int) (x1 >>> 32)); > 532: ByteArrayLittleEndian.setLong(buf, 28, Long.reverseBytes(HexDigits.hex8Be((int)leastSigBits))); Casts in this file needs proper formatting too ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22942#discussion_r2721488613 From vklang at openjdk.org Fri Jan 23 14:59:58 2026 From: vklang at openjdk.org (Viktor Klang) Date: Fri, 23 Jan 2026 14:59:58 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v28] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Wed, 21 Jan 2026 16:35:41 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: > > Try out different approach src/java.base/share/classes/java/util/concurrent/ForkJoinTask.java line 643: > 641: */ > 642: public final ForkJoinTask fork() { > 643: Thread t; ForkJoinWorkerThread wt; @DougLea Btw, we can likely remove noUserHelp and setNoUserHelp (and associated bits). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2721550518 From duke at openjdk.org Fri Jan 23 15:56:15 2026 From: duke at openjdk.org (duke) Date: Fri, 23 Jan 2026 15:56:15 GMT Subject: Withdrawn: 8336881: [Linux] Support for hierarchical limits for Metrics In-Reply-To: References: Message-ID: <0l0fSe20dOlVvwouhazq9lxFYRD7w_mMnltTrcpeJIw=.b629c441-6b69-44ef-abb2-7008692b2382@github.com> On Mon, 22 Jul 2024 16:56:00 GMT, Severin Gehwolf wrote: > Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes. > > For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`). > > This patch addresses this issue by: > > 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2. > 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value). > > As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems. > > This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests. > > Thoughts? > > Testing: > > - [x] GHA > - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems > - [x] Some manual testing using systemd slices This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/20280 From jvernee at openjdk.org Fri Jan 23 16:42:04 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 16:42:04 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java line 29: > 27: * @build m1/* m2/* Unnamed > 28: * @run junit/othervm m1/p1.Main > 29: * @run junit/othervm Unnamed Is this still correct in combination with the changes from https://github.com/openjdk/jdk/pull/29330? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2721991204 From jvernee at openjdk.org Fri Jan 23 16:44:05 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 16:44: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 Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3698507443 From alanb at openjdk.org Fri Jan 23 16:51:02 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 23 Jan 2026 16:51:02 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp In-Reply-To: References: Message-ID: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> On Thu, 22 Jan 2026 18:57:30 GMT, Henry Jen wrote: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: > 94: _decompressors = NULL; > 95: _decompressors_num = 0; > 96: } What would you think about removing it? Its dead code and not tested. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2722035594 From sgehwolf at openjdk.org Fri Jan 23 16:55:22 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:55:22 GMT Subject: RFR: 8375692: Hotspot container tests assert with non-ascii vendor name [v4] In-Reply-To: References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Thu, 22 Jan 2026 13:30:58 GMT, Severin Gehwolf wrote: >> Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. >> >> Thoughts? >> >> **Testing:** >> - [x] GHA >> - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. > > Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision: > > - Merge branch 'master' into jdk-8375692-container-test-assert > - Restore Bellsoft copyright > - Update copyright year > - 8375692: Hotspot container tests assert with non-ascii vendor name Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29315#issuecomment-3791233146 From liach at openjdk.org Fri Jan 23 16:58:48 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 16:58:48 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: <9iWVXnQ1w86Ab8hNhJq9uLCAiPTzGfCN9oiWlJR9ITE=.dd42df6d-ee2b-46c3-89d9-20566588ca2b@github.com> On Fri, 23 Jan 2026 16:37:30 GMT, Jorn Vernee wrote: >> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits: >> >> - Another round of copyright year update >> - Various bugs >> - assertInstanceOf >> - loop test review, test instance cleanup >> - Use static imports >> - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit >> - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit >> - Review >> - Some omissions >> - Whitespace >> - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca > > test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java line 29: > >> 27: * @build m1/* m2/* Unnamed >> 28: * @run junit/othervm m1/p1.Main >> 29: * @run junit/othervm Unnamed > > Is this still correct in combination with the changes from https://github.com/openjdk/jdk/pull/29330? Yes, I changed the main method in `Unnamed.java` to a junit `@Test` instance method. See https://github.com/openjdk/jdk/pull/28879/files#diff-62821ee0b2327e683a8010d2dff7db40e9552b3f5a4a7403f8b69e0ba38873e9 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2722073533 From sgehwolf at openjdk.org Fri Jan 23 16:58:50 2026 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 23 Jan 2026 16:58:50 GMT Subject: Integrated: 8375692: Hotspot container tests assert with non-ascii vendor name In-Reply-To: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> References: <_MdjqcByZwPxAE7Fr1fsBN_JKuFePCF9RGQ0t6gHVr4=.e6305973-bf68-4f41-a7d0-70c9e8220733@github.com> Message-ID: On Tue, 20 Jan 2026 11:29:41 GMT, Severin Gehwolf wrote: > Please review this test-only fix. For non-ascii vendor strings the hotspot container tests fail in fastdebug because the encoding of the vendor string doesn't match. Full details in [JDK-8375471](https://bugs.openjdk.org/browse/JDK-8375471). In order to avoid the assert, the containers need to set to an UTF-8 encoding. This patch proposes to do so by setting `LANG=C.UTF-8`. > > Thoughts? > > **Testing:** > - [x] GHA > - [x] Linux container tests on cg v1 and cg v2 with a JDK build and vendor string `Foo bar ???` and fastdebug. All pass. Most failed before. This pull request has now been integrated. Changeset: 3fb118a2 Author: Severin Gehwolf URL: https://git.openjdk.org/jdk/commit/3fb118a29ed68f2fbb64de45468b0f014fa01890 Stats: 7 lines in 3 files changed: 4 ins; 0 del; 3 mod 8375692: Hotspot container tests assert with non-ascii vendor name Reviewed-by: naoto, dholmes, syan ------------- PR: https://git.openjdk.org/jdk/pull/29315 From jvernee at openjdk.org Fri Jan 23 17:36:47 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 17:36:47 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28879#pullrequestreview-3698738259 From liach at openjdk.org Fri Jan 23 17:36:48 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 17:36:48 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 23:55:02 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 with a new target base due to a merge or a rebase. The pull request now contains 12 commits: > > - Another round of copyright year update > - Various bugs > - assertInstanceOf > - loop test review, test instance cleanup > - Use static imports > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Merge branch 'master' of https://github.com/openjdk/jdk into cleanup/invoke-junit > - Review > - Some omissions > - Whitespace > - ... and 2 more: https://git.openjdk.org/jdk/compare/aaca0a2c...b152f7ca Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28879#issuecomment-3791419301 From jvernee at openjdk.org Fri Jan 23 17:36:50 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 17:36:50 GMT Subject: RFR: 8373935: Migrate java/lang/invoke tests away from TestNG [v3] In-Reply-To: <9iWVXnQ1w86Ab8hNhJq9uLCAiPTzGfCN9oiWlJR9ITE=.dd42df6d-ee2b-46c3-89d9-20566588ca2b@github.com> References: <9iWVXnQ1w86Ab8hNhJq9uLCAiPTzGfCN9oiWlJR9ITE=.dd42df6d-ee2b-46c3-89d9-20566588ca2b@github.com> Message-ID: <4KkXja1-VzgWiag8M4Su7CN3BG3uJXKwJYHYZb9hdeQ=.dc129dbb-5123-4b4f-93b6-b43a0a428b62@github.com> On Fri, 23 Jan 2026 16:55:42 GMT, Chen Liang wrote: >> test/jdk/java/lang/invoke/MethodHandleProxies/Driver.java line 29: >> >>> 27: * @build m1/* m2/* Unnamed >>> 28: * @run junit/othervm m1/p1.Main >>> 29: * @run junit/othervm Unnamed >> >> Is this still correct in combination with the changes from https://github.com/openjdk/jdk/pull/29330? > > Yes, I changed the main method in `Unnamed.java` to a junit `@Test` instance method. See https://github.com/openjdk/jdk/pull/28879/files#diff-62821ee0b2327e683a8010d2dff7db40e9552b3f5a4a7403f8b69e0ba38873e9 Ah got it ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28879#discussion_r2722185206 From liach at openjdk.org Fri Jan 23 17:36:51 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 17:36:51 GMT Subject: Integrated: 8373935: Migrate java/lang/invoke tests away from TestNG In-Reply-To: References: Message-ID: On Wed, 17 Dec 2025 21:12:32 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. This pull request has now been integrated. Changeset: 40f7a18b Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/40f7a18b2dbf120a95432174664fa897331e8973 Stats: 6140 lines in 129 files changed: 661 ins; 872 del; 4607 mod 8373935: Migrate java/lang/invoke tests away from TestNG Reviewed-by: jvernee, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28879 From jlu at openjdk.org Fri Jan 23 17:38:25 2026 From: jlu at openjdk.org (Justin Lu) Date: Fri, 23 Jan 2026 17:38:25 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: <8crfkb4KKcYlDUoncQz4Y8BWbqQCUZtiVPb8y0cku10=.d27e3877-6601-4eee-9142-2768ec459a4d@github.com> On Thu, 22 Jan 2026 12:14:05 GMT, Alan Bateman wrote: >> Please review this PR which converts the JDBC TestNG tests to use JUnit. >> >> This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. >> >> Framework test stats before: >> 680 = 680 TestNG + 0 JUnit >> >> Framework test stats after: >> 680 = 0 TestNG + 680 JUnit > > test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java line 45: > >> 43: * via the service-provider loading mechanism. >> 44: */ >> 45: @TestInstance(TestInstance.Lifecycle.PER_CLASS) > > Has migration replaces a data provider with a method source that is an instance method, when JUnit prefers a static method? I'm trying to understand why Lifecycle.PER_CLASS is needed. It is my understanding that the migration tool is performing the migration in a way that makes review as easy as possible and follows https://github.com/junit-team/junit-framework/wiki/Migrating-from-TestNG-to-JUnit-Jupiter. So adjusting the JUnit test to launch an instance per class to match the TestNG semantics allows us to make the code diff smaller and the conversion easier (w/o any possible behavioral changes). However, I agree that if writing these JUnit tests from scratch, we would use the default life cycle. I'll update these tests to use per method semantics, but this might be worth bringing up in discussion with the others involved in the JUnit conversions. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29354#discussion_r2722198387 From jvernee at openjdk.org Fri Jan 23 18:23:24 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 18:23:24 GMT Subject: RFR: 8375433: jar should validate automatic module names In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 12:36:54 GMT, Christian Stein wrote: > Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. > > Prior to this commit, a `MANFEST.MF` reading > > Automatic-Module-Name: default > > added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: > > $ java --module-path a.jar --describe-module default > > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for a.jar > Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier > > > With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: > > > invalid module name of Automatic-Module-Name entry in manifest: default > > > The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 296: > 294: } catch (IOException e) { > 295: errorAndInvalid(e.getMessage()); > 296: } I feel like this should be put in a separate method rather then be added in this `if` block. Checking the contents of the manifest feels fundamentally different from what the other code in this method is doing, namely checking the consistency of the `EntryInfo` itself. src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties line 144: > 142: invalid module name of Automatic-Module-Name entry in manifest: {0} > 143: error.validator.manifest.inconsistent.automatic.module.name=\ > 144: expected module name is: {1} - but found Automatic-Module-Name entry in manifest: {0} Would be good here to mention where the expected name is coming from. Suggestion: expected module name is: {1} - but found Automatic-Module-Name entry in manifest: {0} test/jdk/tools/jar/ValidatorTest.java line 323: > 321: try { > 322: jar("--validate --file " + file.toString()); > 323: fail("Expecting non-zero exit code"); Could use `assertThrows` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2722323625 PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2722329155 PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2722335182 From liach at openjdk.org Fri Jan 23 18:26:09 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 18:26:09 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v12] 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 23 additional commits since the last revision: - Design detail updates, thanks to jorn - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache - Missed IR test review, rearrange benches - 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 - ... and 13 more: https://git.openjdk.org/jdk/compare/4ac48240...77ea5565 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/1d5461db..77ea5565 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=10-11 Stats: 93166 lines in 3834 files changed: 46542 ins; 16001 del; 30623 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 henryjen at openjdk.org Fri Jan 23 18:59:53 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 18:59:53 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp In-Reply-To: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> References: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> Message-ID: On Fri, 23 Jan 2026 16:48:47 GMT, Alan Bateman wrote: >> I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). >> >> This PR implements proper cleanup for decompressors to be defensive. > > src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: > >> 94: _decompressors = NULL; >> 95: _decompressors_num = 0; >> 96: } > > What would you think about removing it? Its dead code and not tested. We can do that too since it's by design to have same lifespan as the process. I'll run some more tests to confirm removing is safe. The close can be added when the requirements change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2722455193 From jvernee at openjdk.org Fri Jan 23 19:22:03 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Fri, 23 Jan 2026 19:22:03 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 18:26:09 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 23 additional commits since the last revision: > > - Design detail updates, thanks to jorn > - Merge branch 'master' of https://github.com/openjdk/jdk into fix/vh-adapt-cache > - Missed IR test review, rearrange benches > - 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 > - ... and 13 more: https://git.openjdk.org/jdk/compare/d8405cdd...77ea5565 src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2043: > 2041: // > 2042: // Condition 1 and 2 indicates this access descriptor may see a VarHandle > 2043: // different from the captured VarHandle. Condition 3 requires the Suggestion: // Condition 1 and 2 indicates this access descriptor may see a VarHandle // different from the captured VarHandle. I don't see how this follows from condition 1 and 2 holding. A failure in either condition means we are may see multiple VH instance. I suggest: Suggestion: // If either condition 1 or 2 doesn't hold, we may see different var handle instances using the // same shared AccessDescriptor. In those cases we only cache the adaptation for one of the // var handle instances (the first one). Other instances will always use the slow path. src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2049: > 2047: // such as compareAndSet can appear at two sites, where each site > 2048: // has its own constant VarHandle. Such a usage pattern hurts adaption, > 2049: // but is perfectly dealt by the getMethodType_V constant folding branch. I think this information should be put on the template string instead, since it's mostly referencing that code. I think it's enough to say that we 'skip potentially costly adaptation' by going through the `getMethodType_V` branch. >From the text as written, it's not clear why such usage patterns hurt adaptation. I think It would be more accurate to say that: "in such cases, only one of the two var handles will have its adaptation cached". src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055: > 2053: // invocation type of the underlying MemberName, or MH for indirect VH), > 2054: // perform a foldable lookup with a hash table, and hope C2 inline it > 2055: // all. Such an optimization applies for general MethodHandle.asType. Suggestion: // all. Such an optimization applies to general MethodHandle.asType. src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2055: > 2053: // invocation type of the underlying MemberName, or MH for indirect VH), > 2054: // perform a foldable lookup with a hash table, and hope C2 inline it > 2055: // all. Such an optimization applies for general MethodHandle.asType. This reads as "put a ... to another ... perform", which doesn't sounds grammatically correct. Maybe: Suggestion: // In the long run, we wish to cache each specific-type invoker that converts // from one fixed type (symbolicMethodTypeInvoker) to another (the // invocation type of the underlying MemberName, or MH for indirect VH), // using a foldable lookup with a hash table, and hope C2 inline it // all. Such an optimization applies for general MethodHandle.asType. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722389574 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722416361 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722376203 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2722514070 From liach at openjdk.org Fri Jan 23 20:08:58 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 20:08:58 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] 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: Wording update, thanks Jorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28585/files - new: https://git.openjdk.org/jdk/pull/28585/files/77ea5565..5ba75d45 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28585&range=11-12 Stats: 16 lines in 2 files changed: 1 ins; 3 del; 12 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 Fri Jan 23 20:41:23 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 23 Jan 2026 20:41:23 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets Message-ID: This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29393/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8210336 Stats: 53 lines in 3 files changed: 49 ins; 1 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29393/head:pull/29393 PR: https://git.openjdk.org/jdk/pull/29393 From jrose at openjdk.org Fri Jan 23 21:49:50 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 21:49:50 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 Good work. ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28540#pullrequestreview-3699825444 From jrose at openjdk.org Fri Jan 23 22:13:18 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 22:13:18 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 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: > > Wording update, thanks Jorn make/jdk/src/classes/build/tools/methodhandle/VarHandleGuardMethodGenerator.java line 130: > 128: > 129: // The void bypass is necessary if a (name + return-dropping type) combination has multiple call sites, each > 130: // having its own constant VarHandle. In that case, the AccessMode::adaptedMethodHandle adaption mechanism wrong word: s/adaption/adaptation/ https://grammarist.com/usage/adaption-adaptation/ (Wiktionary implies they are the same, but they apply to different areas of discourse. The grammarist article indicates that "adaptation" is the more correct word here. Also, the word "adaption" seems to be mostly obsolete.) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723023261 From liach at openjdk.org Fri Jan 23 22:19:56 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 23 Jan 2026 22:19:56 GMT Subject: RFR: 8376234: Migrate java/lang/constant tests away from TestNG Message-ID: Convert all TestNG tests in java/lang/constant to JUnit tests. ------------- Commit messages: - Bugs in migration - No testng in constant Changes: https://git.openjdk.org/jdk/pull/29396/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29396&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376234 Stats: 732 lines in 15 files changed: 140 ins; 317 del; 275 mod Patch: https://git.openjdk.org/jdk/pull/29396.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29396/head:pull/29396 PR: https://git.openjdk.org/jdk/pull/29396 From missa at openjdk.org Fri Jan 23 23:04:43 2026 From: missa at openjdk.org (Mohamed Issa) Date: Fri, 23 Jan 2026 23:04:43 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: - Merge branch 'master' into user/missa-prime/avx10_2 - Merge branch 'master' into user/missa-prime/avx10_2 - Change function names and extend IR encoding rules for CMove tests - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad - Also update copyright year in IREncodingPrinter.java - Include apx_f in list of verified CPU features for IR encoding - Fix CMove IR tests to account for APX presence - Merge branch 'master' into user/missa-prime/avx10_2 - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d ------------- Changes: https://git.openjdk.org/jdk/pull/28337/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=07 Stats: 862 lines in 10 files changed: 663 ins; 105 del; 94 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From jrose at openjdk.org Fri Jan 23 23:05:30 2026 From: jrose at openjdk.org (John R Rose) Date: Fri, 23 Jan 2026 23:05:30 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 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: > > Wording update, thanks Jorn src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2022: > 2020: // In a class file, the JVM creates one access descriptor for one (name, type) combination. > 2021: // Many call sites in one class can have the same (name, type) combination. > 2022: // In this case, they share the same access descriptor. I love it when, as part of maintenance, informative comments like these are added. Thanks! Please add a comment something like this as well: // Note: The integers type and mode are proxies for the AccessType and // AccessMode enumerations, and the access type simply summarizes something // about the shape of the access mode. The crucial type here, of the (name, type) // combination, is the MethodType that decorates the access shape with specific // strong types for the handle operation inputs and outputs. I think it was a small faux pas, some time ago, to choose the term `AccessType` instead of `AccessKind`, simply because the term "type" is already disastrously overloaded in our system. But that?s water under the bridge. Now we have one more "type" floating around in this neighborhood. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723131985 From henryjen at openjdk.org Fri Jan 23 23:19:40 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 23:19:40 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v2] In-Reply-To: References: Message-ID: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. 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 two additional commits since the last revision: - Merge origin/master - 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp:90 (ID: 34500) ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29371/files - new: https://git.openjdk.org/jdk/pull/29371/files/a24ab6e1..d8bfef8d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=00-01 Stats: 36265 lines in 732 files changed: 20964 ins; 7321 del; 7980 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From henryjen at openjdk.org Fri Jan 23 23:24:50 2026 From: henryjen at openjdk.org (Henry Jen) Date: Fri, 23 Jan 2026 23:24:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: Message-ID: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. Henry Jen has updated the pull request incrementally with one additional commit since the last revision: remove dead code ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29371/files - new: https://git.openjdk.org/jdk/pull/29371/files/d8bfef8d..bd6a2333 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29371&range=01-02 Stats: 13 lines in 2 files changed: 0 ins; 12 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29371.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29371/head:pull/29371 PR: https://git.openjdk.org/jdk/pull/29371 From jrose at openjdk.org Sat Jan 24 01:16:48 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 24 Jan 2026 01:16:48 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 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: > > Wording update, thanks Jorn src/java.base/share/classes/java/lang/invoke/VarHandle.java line 2014: > 2012: // Exists for the adaption mechanism of AccessDescriptor > 2013: // Each VH should report its explicitly (receiver, coordinates) and > 2014: // implicitly (static declaring class) used class to MethodHandle.isReachableFrom Perhaps add a comment: "Classes which define this abstract method should themselves be final or locally sealed, to make it possible to ensure that all relevant classes are taken into account." ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723365226 From jrose at openjdk.org Sat Jan 24 01:21:04 2026 From: jrose at openjdk.org (John R Rose) Date: Sat, 24 Jan 2026 01:21:04 GMT Subject: RFR: 8160821: VarHandle accesses are penalized when argument conversion is required [v13] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:08:58 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: > > Wording update, thanks Jorn Good work. I?m assuming you will address my previous comments. src/java.base/share/classes/java/lang/invoke/SegmentVarHandle.java line 69: > 67: @Override > 68: boolean isReachableFrom(ClassLoader cl) { > 69: return true; Give a comment explaining why this is correct. Something like: The segment is neither an instance nor an array, so it is effectively common to all class loaders. Compare this to a class on the boot class loader, which also uses only types that are common reachable from all other class loaders. (Or something like that.) ------------- Marked as reviewed by jrose (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28585#pullrequestreview-3700343726 PR Review Comment: https://git.openjdk.org/jdk/pull/28585#discussion_r2723372435 From jpai at openjdk.org Sat Jan 24 01:25:25 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Sat, 24 Jan 2026 01:25:25 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v6] In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> References: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> Message-ID: On Thu, 22 Jan 2026 21:54:35 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: Updated the documentation to describe the behavior using @implSpec Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/28615#pullrequestreview-3700349807 From swen at openjdk.org Sat Jan 24 07:11:43 2026 From: swen at openjdk.org (Shaojin Wen) Date: Sat, 24 Jan 2026 07:11:43 GMT Subject: RFR: 8359424: Eliminate table lookup in Integer/Long toHexString [v9] 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: code style, from @liach ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22942/files - new: https://git.openjdk.org/jdk/pull/22942/files/53dd387f..505bcbdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22942&range=07-08 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 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 alanb at openjdk.org Sat Jan 24 07:18:50 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 24 Jan 2026 07:18:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:24:50 GMT, Henry Jen wrote: >> I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). >> >> This PR implements proper cleanup for decompressors to be defensive. > > Henry Jen has updated the pull request incrementally with one additional commit since the last revision: > > remove dead code Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29371#pullrequestreview-3700924382 From eirbjo at openjdk.org Sat Jan 24 20:20:50 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 24 Jan 2026 20:20:50 GMT Subject: RFR: 8373924: Dangling pointer in ImageDecompressor::image_decompressor_close of imageDecompressor.cpp [v3] In-Reply-To: References: <2Eyztyttm_T8FTk0QITmfzXbVsz9yNpZRNptLnus6fs=.88f55f3e-1014-4dbb-8041-d174a3475e26@github.com> Message-ID: On Fri, 23 Jan 2026 18:56:55 GMT, Henry Jen wrote: >> src/java.base/share/native/libjimage/imageDecompressor.cpp line 96: >> >>> 94: _decompressors = NULL; >>> 95: _decompressors_num = 0; >>> 96: } >> >> What would you think about removing it? Its dead code and not tested. > > We can do that too since it's by design to have same lifespan as the process. I'll run some more tests to confirm removing is safe. > > The close can be added when the requirements change. Consider updating the issue / PR title to reflect the removal instead of fixing. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29371#discussion_r2724573245 From jbhateja at openjdk.org Sun Jan 25 07:05:40 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 07:05:40 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v15] 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: Refactoring and cleanups ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/72d15568..0891bc70 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=13-14 Stats: 822 lines in 48 files changed: 14 ins; 306 del; 502 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 Sun Jan 25 08:00:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Sun, 25 Jan 2026 08:00:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v16] 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: Refactoring vectorIntrinsics ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/0891bc70..aeba2e68 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=14-15 Stats: 150 lines in 1 file changed: 74 ins; 14 del; 62 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 eirbjo at openjdk.org Sun Jan 25 11:16:30 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sun, 25 Jan 2026 11:16:30 GMT Subject: RFR: 8376271: ZipFile comment confusingly refers to "native" ZIP file implementation Message-ID: Please review this comment-only PR which updates a field comment referring to `ZipFile.Source` as "native". ZipFile has not used a native implementation since Java 8, so this comment may be confusing. The comment seems to have been introduced in 2017 as part of JDK-8185582 when ZipFile was updated to use Cleaners instead of finalizers. (The use of quotation marks in "native" may have meant to indicate that this is "not really native", but I still find it confusing). While visiting this comment, I also made an attempt to make the leading sentence of this field comment less mysterious. Comment only, trivial, low risk: `noreg-trivial` ------------- Commit messages: - Improve comment on the ZipFile.res field Changes: https://git.openjdk.org/jdk/pull/29401/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29401&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376271 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29401.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29401/head:pull/29401 PR: https://git.openjdk.org/jdk/pull/29401 From chen.l.liang at oracle.com Sun Jan 25 16:17:53 2026 From: chen.l.liang at oracle.com (Chen Liang) Date: Sun, 25 Jan 2026 16:17:53 +0000 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> Message-ID: Checked this and noted this Lock is used by both lock and shutdownLock - this makes the Lock class less informative to me. Maybe we should replace one of the locks with Object, or add a new class to distinguish these two locks? Confidential- Oracle Internal ________________________________ From: core-libs-dev on behalf of Eirik Bj?rsn?s Sent: Wednesday, January 21, 2026 12:28 AM To: David Holmes Cc: core-libs-dev at openjdk.org Subject: Re: RFD: Replace class java.lang.Shutdown.Lock with Object? On Wed, Jan 21, 2026 at 6:38?AM David Holmes > wrote: No I suppose not. Though I'm not sure trimming the class will make any observable/practical difference in the normal case. Thanks! I agree trimming these two classes (of ~428 loaded at startup) alone has limited value. But there are other berries to pick and the cumulative impact may have an observable effect on startup. Two berries feed no one, with a handful we can make a delicious jam :) So effectively this is like declaring a single global class that all "new Object()'s" would be instances of. So using new Object() will not be a problem. Thanks for the Valhalla reference, interesting to see how "new Object()" can be redefined like this. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Sun Jan 25 19:13:05 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 25 Jan 2026 19:13:05 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement Message-ID: We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! ------------- Commit messages: - 8376274: JSpec preview support and output enhancement Changes: https://git.openjdk.org/jdk/pull/29402/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376274 Stats: 50 lines in 2 files changed: 34 ins; 3 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402 PR: https://git.openjdk.org/jdk/pull/29402 From dl at openjdk.org Sun Jan 25 20:09:13 2026 From: dl at openjdk.org (Doug Lea) Date: Sun, 25 Jan 2026 20:09:13 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v29] 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: Don't oversignal LIFO ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/02ddb13d..04928c94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=28 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=27-28 Stats: 155 lines in 1 file changed: 34 ins; 52 del; 69 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 Jan 26 01:51:00 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 01:51:00 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: <0unjF0mIb3vR8aHBAq6Q_ioqtjwRerQl_slPxcDB5wY=.e9dea4be-2ac8-47f8-a975-d6452f8b4b61@github.com> 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())` Sorry for taking a million years but I finally uploaded your CSR to JBS. Was busy with Valhalla and other things. I proofread and thought it is fine, and asked other JDK engineers to review the CSR too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3797589845 From erfang at openjdk.org Mon Jan 26 01:54:11 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 01:54:11 GMT Subject: [jdk26] RFR: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 06:03:08 GMT, Eric Fang wrote: > Hi all, > > This pull request contains a backport of commit 56d7b524 from the openjdk/jdk repository. > > The commit being backported was authored by Eric Fang on 14 Jan 2026 and was reviewed by Paul Sandoz, Quan Anh Mai and Xiaohong Gong. > > Thanks! I may have misunderstood the importance of this bug; there don't seem to be many use cases for the vector API at the moment. Therefore, not backporting is acceptable, and I will close this PR. Thank you! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29262#issuecomment-3797595569 From erfang at openjdk.org Mon Jan 26 01:54:11 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 01:54:11 GMT Subject: [jdk26] Withdrawn: 8372978: [VectorAPI] Fix incorrect identity values in UMIN/UMAX reductions In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 06:03:08 GMT, Eric Fang wrote: > Hi all, > > This pull request contains a backport of commit 56d7b524 from the openjdk/jdk repository. > > The commit being backported was authored by Eric Fang on 14 Jan 2026 and was reviewed by Paul Sandoz, Quan Anh Mai and Xiaohong Gong. > > Thanks! This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/29262 From erfang at openjdk.org Mon Jan 26 02:02:01 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 02:02:01 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:34:00 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 >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions Marked as reviewed by erfang (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3704448350 From liach at openjdk.org Mon Jan 26 02:04:53 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 02:04:53 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:34:24 GMT, Naoto Sato wrote: > This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. The time tck tests only have toString<>parse round trip and bad parse data. Do you think we need a third type of data for valid parsing but not recoverable in toString? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29393#issuecomment-3797609387 From xgong at openjdk.org Mon Jan 26 02:37:00 2026 From: xgong at openjdk.org (Xiaohong Gong) Date: Mon, 26 Jan 2026 02:37:00 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:34:00 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 >> VectorSliceB... > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions LGTM! Thanks for your updating! ------------- Marked as reviewed by xgong (Committer). PR Review: https://git.openjdk.org/jdk/pull/24104#pullrequestreview-3704485459 From liach at openjdk.org Mon Jan 26 05:27:24 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 05:27:24 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG Message-ID: Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. ------------- Commit messages: - 8376277: Migrate java/lang/reflect tests away from TestNG Changes: https://git.openjdk.org/jdk/pull/29405/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29405&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376277 Stats: 793 lines in 28 files changed: 85 ins; 287 del; 421 mod Patch: https://git.openjdk.org/jdk/pull/29405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29405/head:pull/29405 PR: https://git.openjdk.org/jdk/pull/29405 From eirbjo at openjdk.org Mon Jan 26 06:41:52 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 06:41:52 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 05:19:25 GMT, Chen Liang wrote: > Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. Hmm.. I do understand your caution here. But you're already using a test framework, right? If you look into the implementation of `Asssertions.assertThrows`, the only reflection happening is the call to `Class.isInstance` to check the expected exception type. If you want to avoid reflection entirely, there's always `assertThrowsExactly` which avoids reflection and contains no more exciting/exotic code than the tests themselves..? The net win for code readability with `assertThrows` is very nice, it's a pity not to be able to use it here as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29405#issuecomment-3798099060 From mbaesken at openjdk.org Mon Jan 26 07:38:54 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Mon, 26 Jan 2026 07:38:54 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows [v2] In-Reply-To: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> References: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> Message-ID: On Thu, 22 Jan 2026 06:36:10 GMT, Arno Zeller wrote: >> It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. >> This change will add the message again to the allowed messages. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year Marked as reviewed by mbaesken (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29348#pullrequestreview-3704896646 From duke at openjdk.org Mon Jan 26 07:43:06 2026 From: duke at openjdk.org (duke) Date: Mon, 26 Jan 2026 07:43:06 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows [v2] In-Reply-To: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> References: <8k00Pb2Cw-IgDlAZEjBqw6IH2g5Vph788NIbiMKYcrQ=.5fcc28b3-0fc5-4625-9004-3271cec90c41@github.com> Message-ID: On Thu, 22 Jan 2026 06:36:10 GMT, Arno Zeller wrote: >> It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. >> This change will add the message again to the allowed messages. > > Arno Zeller has updated the pull request incrementally with one additional commit since the last revision: > > Update copyright year @ArnoZeller Your change (at version 1423f9dc66d07c506c5d060c7a3610fc7fdc9077) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29348#issuecomment-3798253275 From azeller at openjdk.org Mon Jan 26 07:43:07 2026 From: azeller at openjdk.org (Arno Zeller) Date: Mon, 26 Jan 2026 07:43:07 GMT Subject: RFR: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 05:56:38 GMT, Jaikiran Pai wrote: >> It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. >> This change will add the message again to the allowed messages. > > Please update the copyright year on the file from 2025 to 2026, before integrating. @jaikiran and @MBaesken: Thanks a lot for reviewing! It would be nice if one of you could also sponsor it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29348#issuecomment-3798254320 From cstein at openjdk.org Mon Jan 26 08:36:39 2026 From: cstein at openjdk.org (Christian Stein) Date: Mon, 26 Jan 2026 08:36:39 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: Message-ID: > Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. > > Prior to this commit, a `MANFEST.MF` reading > > Automatic-Module-Name: default > > added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: > > $ java --module-path a.jar --describe-module default > > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for a.jar > Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier > > > With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: > > > invalid module name of Automatic-Module-Name entry in manifest: default > > > The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. Christian Stein 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/29316/files - new: https://git.openjdk.org/jdk/pull/29316/files/9ca4567d..54f12744 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29316&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29316&range=00-01 Stats: 69 lines in 3 files changed: 32 ins; 28 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/29316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29316/head:pull/29316 PR: https://git.openjdk.org/jdk/pull/29316 From cstein at openjdk.org Mon Jan 26 08:36:41 2026 From: cstein at openjdk.org (Christian Stein) Date: Mon, 26 Jan 2026 08:36:41 GMT Subject: RFR: 8375433: jar should validate automatic module names In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 12:36:54 GMT, Christian Stein wrote: > Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. > > Prior to this commit, a `MANFEST.MF` reading > > Automatic-Module-Name: default > > added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: > > $ java --module-path a.jar --describe-module default > > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for a.jar > Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier > > > With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: > > > invalid module name of Automatic-Module-Name entry in manifest: default > > > The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. Thank you for the review, Jorn. I addressed all three suggestions in the latest commit. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29316#issuecomment-3798412541 From azeller at openjdk.org Mon Jan 26 08:38:10 2026 From: azeller at openjdk.org (Arno Zeller) Date: Mon, 26 Jan 2026 08:38:10 GMT Subject: Integrated: 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 14:21:26 GMT, Arno Zeller wrote: > It seems that [JDK-8287062](https://bugs.openjdk.org/browse/JDK-8287062) did accidentally remove one Exception message that was allowed to pass the test. This message only occurs on Windows. > This change will add the message again to the allowed messages. This pull request has now been integrated. Changeset: 90b54692 Author: Arno Zeller Committer: Jaikiran Pai URL: https://git.openjdk.org/jdk/commit/90b546925397ff7cdd1591291e1b87d0bac5604a Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod 8375999: com/sun/jndi/ldap/LdapPoolTimeoutTest.java fails sporadically on Windows Reviewed-by: jpai, mbaesken ------------- PR: https://git.openjdk.org/jdk/pull/29348 From alanb at openjdk.org Mon Jan 26 08:40:04 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Jan 2026 08:40:04 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 05:19:25 GMT, Chen Liang wrote: > Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. > > Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. test/jdk/java/lang/reflect/ChainedReflection.java line 42: > 40: class Inner { > 41: // JUnit does not allow test class to declare multiple constructors > 42: Inner() throws ReflectiveOperationException { This comment might be confusing to future maintainers, may not immediately seeing the compiler generated constructor. Maybe expand the comment on this and put it on the class rather the constructor. test/jdk/java/lang/reflect/IllegalArgumentsTest.java line 28: > 26: * @bug 8277964 > 27: * @summary Test IllegalArgumentException be thrown when an argument is invalid > 28: * @run junit/othervm/timeout=720 IllegalArgumentsTest On the surface, the test is begging to use assertThrows but this a test for a C2 issue so I agree it shouldn't be changed. test/jdk/java/lang/reflect/Proxy/DefaultMethods.java line 239: > 237: Method m = I12.class.getMethod("concat", Object.class, Object[].class); > 238: assertTrue(m.isDefault()); > 239: assertArrayEquals(new Object[] {100, "foo", true, "bar"}, (Object[]) InvocationHandler.invokeDefault(i12, m, 100, new Object[] {"foo", true, "bar"})); It might be better to put the actuals on new line to make it easier to see expecteds vs. actuals and to avoid the horizontal scroll. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2726740168 PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2726717219 PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2726712044 From hgreule at openjdk.org Mon Jan 26 08:45:36 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 26 Jan 2026 08:45:36 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: On Wed, 21 Jan 2026 19:25:30 GMT, Hannes Greule wrote: >> A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > update according John's suggestion If there aren't any objections/comments, I'd integrate this later. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3798457358 From eirbjo at openjdk.org Mon Jan 26 09:21:08 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 09:21:08 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 08:28:26 GMT, Alan Bateman wrote: > On the surface, the test is begging to use assertThrows but this a test for a C2 issue so I agree it shouldn't be changed. Then perhaps a comment documenting this decision would be helpful to future maintainers who may be tempted to improve the test using `assertThrows`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2726857288 From erfang at openjdk.org Mon Jan 26 09:26:35 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 09:26:35 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: 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 > Sh... Eric Fang has updated the pull request incrementally with one additional commit since the last revision: Move helper functions into c2_MacroAssembler_aarch64.hpp ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28693/files - new: https://git.openjdk.org/jdk/pull/28693/files/fc3dee3d..10d74f13 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28693&range=02-03 Stats: 104 lines in 2 files changed: 26 ins; 64 del; 14 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 erfang at openjdk.org Mon Jan 26 09:29:46 2026 From: erfang at openjdk.org (Eric Fang) Date: Mon, 26 Jan 2026 09:29:46 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:40:31 GMT, Andrew Haley wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Extract some helper functions for better readability > > Please add the `TypeNNVector` JMH test files to this PR. Hi @theRealAph I have addressed all of your comments, thanks for your suggestions. > Please add the TypeNNVector JMH test files to this PR. These micro-benchmarks are already in the `panama-vector` project, do we need to sync that file separately into OpenJDK? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3798625373 From jlahoda at openjdk.org Mon Jan 26 09:45:43 2026 From: jlahoda at openjdk.org (Jan Lahoda) Date: Mon, 26 Jan 2026 09:45:43 GMT Subject: Integrated: 8375712: Convert java/lang/runtime tests to use JUnit In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 16:32:06 GMT, Jan Lahoda wrote: > This PR converts the tests under `test/jdk/java/lang/runtime/` to use JUnit. Mostly converted by the automatic conversion tool, but there's a manual tweak to use `assertThrows` instead of the current manual `try-catch`. Also one manual fix. The changes are in separate commits, which should help reviewing. > > Thanks! This pull request has now been integrated. Changeset: 90d065e6 Author: Jan Lahoda URL: https://git.openjdk.org/jdk/commit/90d065e677535e3f7caa7507f1526062b50ecc67 Stats: 243 lines in 3 files changed: 33 ins; 101 del; 109 mod 8375712: Convert java/lang/runtime tests to use JUnit Reviewed-by: liach ------------- PR: https://git.openjdk.org/jdk/pull/29350 From aph at openjdk.org Mon Jan 26 09:51:59 2026 From: aph at openjdk.org (Andrew Haley) Date: Mon, 26 Jan 2026 09:51:59 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 17:40:31 GMT, Andrew Haley wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Extract some helper functions for better readability > > Please add the `TypeNNVector` JMH test files to this PR. > Hi @theRealAph I have addressed all of your comments, thanks for your suggestions. > > > Please add the TypeNNVector JMH test files to this PR. > > These micro-benchmarks are already in the `panama-vector` project, do we need to sync that file separately into OpenJDK? Ideally, yes. It's a bit much to expect a reviewer to check out another repo. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3798709384 From eirbjo at openjdk.org Mon Jan 26 10:43:41 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 10:43:41 GMT Subject: RFR: 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance Message-ID: Please review this small enhancement which makes `ZipFile.Source.Key` capture the relevant `BasicFileAttributes` fields in its constructor instead of calling into `BasicFileAttributes` for each `hashCode` or `equals` invocation. This reduces the memory footprint of `Key` instances. It should be performance positive since we avoid creating `FileTime` instances once per comparison and avoid synchronization getting the file key. Capturing fields early also improves readability by making it more obvious what this Key class is comparing. Pure refactoring, no tests updated, `noreg-trivial`. ------------- Commit messages: - Update copyright year - Capture relevant BasicFileAttributes fields in the Key constructor Changes: https://git.openjdk.org/jdk/pull/29411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376294 Stats: 15 lines in 1 file changed: 5 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/29411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29411/head:pull/29411 PR: https://git.openjdk.org/jdk/pull/29411 From aartemov at openjdk.org Mon Jan 26 11:54:29 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 11:54:29 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java Message-ID: Hi, please consider the following changes: This is a port of FDLIBM asinh method. Original C vs transliteration port: $ diff -w fdlib_asinh.c Asinh.translit.java 1c1,3 < /* asinh(x) --- > /** > * Return the Inverse Hyperbolic Sine of x > * 2a5 > * 10a14,17 > private static final class Asinh { > private static final double one = 1.0; > private static final double ln2 = 6.93147180559945286227e-01; > private static final double huge = 1.0e300; 12,29c19 < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ < huge= 1.00000000000000000000e+300; < < #ifdef __STDC__ < double asinh(double x) < #else < double asinh(x) < double x; < #endif < { --- > static double compute(double x) { 39c29 < w = __ieee754_log(fabs(x))+ln2; --- > w = log(Math.abs(x))+ln2; 41,42c31,32 < t = fabs(x); < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); --- > t = Math.abs(x); > w = log(2.0*t+one/(sqrt(x*x+one)+t)); 45c35 < w =log1p(fabs(x)+t/(one+sqrt(one+t))); --- > w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); 47a38 > } Transliteration port vs more idiomatic port: $ diff -w Asinh.translit.java Asinh.fdlibm.java 6,9c6,12 < * Based on < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] < * we have < * asinh(x) := x if 1+x*x=1, --- > * > * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF > * and sinh(asinh(x)) = x, -INF < x < INF. > * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. > * 1. Replace x by |x| as the function is odd. > * 2. > * asinh(x) := x, if 1+x^2 = 1, 12a16,22 > * > * > * > * Special cases: > * only asinh(0)=0 is exact for finite x. > * asinh(NaN) is NaN > * asinh(INF) is INF 14,15c24 < private static final class Asinh { < private static final double one = 1.0; --- > static final class Asinh { 24c33,35 < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ --- > if(ix >= 0x7ff00000) { > return x + x; /* x is inf or NaN */ > } 26c37,39 < if(huge+x>one) return x; /* return x inexact except 0 */ --- > if(huge + x > 1.0) { > return x; /* return x inexact except 0 */ > } 29c42 < w = log(Math.abs(x))+ln2; --- > w = Log.compute(Math.abs(x)) + ln2; 32c45 < w = log(2.0*t+one/(sqrt(x*x+one)+t)); --- > w = Log.compute(2.0 * t + 1.0 / (Sqrt.compute(x * x + 1.0) + t)); 35c48 < w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); --- > w = Log1p.compute(Math.abs(x) + t / (1.0 + Sqrt.compute(1.0 + t))); 37c50 < if(hx>0) return w; else return -w; --- > return hx > 0 ? w : -w; ------------- Commit messages: - 8375285: Addressed the reviewer's comments. - 8375285: Port of fdlibm asinh function Changes: https://git.openjdk.org/jdk/pull/29273/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8375285 Stats: 584 lines in 7 files changed: 580 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From darcy at openjdk.org Mon Jan 26 11:54:33 2026 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 26 Jan 2026 11:54:33 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:22:52 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... src/java.base/share/classes/java/lang/FdLibm.java line 3543: > 3541: int hx,ix; > 3542: hx = __HI(x); > 3543: ix = hx&0x7fffffff; As part of making the code more idiomatic, I would include adding space characters around `&` and switching one-line `/* ... */` over to `//` comments where possible. src/java.base/share/classes/java/lang/Math.java line 2762: > 2760: > 2761: /** > 2762: * Returns the inverse hyperbolic sine of a {@code double} value. The method specification should provide some general statements in term of the accuracy of the method in terms of ulps. Explicitly specifying asinh(NaN) is NaN is probably worthwhile too. src/java.base/share/classes/java/lang/StrictMath.java line 2173: > 2171: } > 2172: > 2173: /** The list of "these methods must use FDLIBM algorithms..." up at the class-level specs of StrictMath should be updated to include asinh. test/jdk/java/lang/StrictMath/HyperbolicTests.java line 497: > 495: private static int testAsinh() { > 496: int failures = 0; > 497: double [][] testCases = { How were these values generated? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2719362250 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2719360132 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2719363829 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2719365730 From aartemov at openjdk.org Mon Jan 26 11:54:33 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Mon, 26 Jan 2026 11:54:33 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 02:36:15 GMT, Joe Darcy wrote: >> Hi, please consider the following changes: >> >> This is a port of FDLIBM asinh method. >> >> Original C vs transliteration port: >> >> >> $ diff -w fdlib_asinh.c Asinh.translit.java >> 1c1,3 >> < /* asinh(x) >> --- >>> /** >>> * Return the Inverse Hyperbolic Sine of x >>> * >> 2a5 >>> * >> 10a14,17 >>> private static final class Asinh { >>> private static final double one = 1.0; >>> private static final double ln2 = 6.93147180559945286227e-01; >>> private static final double huge = 1.0e300; >> 12,29c19 >> < #include "fdlibm.h" >> < >> < #ifdef __STDC__ >> < static const double >> < #else >> < static double >> < #endif >> < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ >> < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ >> < huge= 1.00000000000000000000e+300; >> < >> < #ifdef __STDC__ >> < double asinh(double x) >> < #else >> < double asinh(x) >> < double x; >> < #endif >> < { >> --- >>> static double compute(double x) { >> 39c29 >> < w = __ieee754_log(fabs(x))+ln2; >> --- >>> w = log(Math.abs(x))+ln2; >> 41,42c31,32 >> < t = fabs(x); >> < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); >> --- >>> t = Math.abs(x); >>> w = log(2.0*t+one/(sqrt(x*x+one)+t)); >> 45c35 >> < w =log1p(fabs(x)+t/(one+sqrt(one+t))); >> --- >>> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); >> 47a38 >>> } >> >> Transliteration port vs more idiomatic port: >> >> >> $ diff -w Asinh.translit.java Asinh.fdlibm.java >> 6,9c6,12 >> < * Based on >> < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] >> < * we have >> < * asinh(x) := x if 1+x*x=1, >> --- >>> * >>> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >>> * and sinh(asinh(x)) = x, -INF < x < INF. >>> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >>> * 1. Replace x by |x| as the function is odd. >>> * 2. >>> * asinh(x) := x, if 1+x^2 = 1, >> 12a16,22 >>> * >>> * >>> * >>> * Special cases: >>> * only asinh(0)=0 is exact for finite x. >>> * asinh(NaN) is NaN >>> * asinh(INF) is INF >> 14,15c24 >> < private static final class Asinh { >> < private static final double one = 1.0; >> --- >>> static final class Asinh { >> 24c33,35 >> < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ >> --- >>> if(ix >= 0x7ff00000) { >>> return x... > > src/java.base/share/classes/java/lang/FdLibm.java line 3543: > >> 3541: int hx,ix; >> 3542: hx = __HI(x); >> 3543: ix = hx&0x7fffffff; > > As part of making the code more idiomatic, I would include adding space characters around `&` and switching one-line `/* ... */` over to `//` comments where possible. Addressed. > src/java.base/share/classes/java/lang/Math.java line 2762: > >> 2760: >> 2761: /** >> 2762: * Returns the inverse hyperbolic sine of a {@code double} value. > > The method specification should provide some general statements in term of the accuracy of the method in terms of ulps. > > Explicitly specifying asinh(NaN) is NaN is probably worthwhile too. Addressed in the latest commit. > src/java.base/share/classes/java/lang/StrictMath.java line 2173: > >> 2171: } >> 2172: >> 2173: /** > > The list of "these methods must use FDLIBM algorithms..." up at the class-level specs of StrictMath should be updated to include asinh. Addressed. > test/jdk/java/lang/StrictMath/HyperbolicTests.java line 497: > >> 495: private static int testAsinh() { >> 496: int failures = 0; >> 497: double [][] testCases = { > > How were these values generated? These results were generated by running a small C++ program linked to a IEEE-standard built fdlibm. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2727300965 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2727300757 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2727301096 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2727301340 From jbhateja at openjdk.org Mon Jan 26 12:17:02 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Mon, 26 Jan 2026 12:17:02 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] 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 34 commits: - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Clanups - Refactoring vectorIntrinsics - Refactoring and cleanups - Refactoring and cleanups - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - Adding testpoint for JDK-8373574 - Review comments resolutions - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa ------------- Changes: https://git.openjdk.org/jdk/pull/28002/files Webrev: Webrev is not available because diff is too large Stats: 519675 lines in 224 files changed: 284942 ins; 233000 del; 1733 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 vklang at openjdk.org Mon Jan 26 12:46:53 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 26 Jan 2026 12:46:53 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v29] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 25 Jan 2026 20:09:13 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: > > Don't oversignal LIFO src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1058: > 1056: static final int MAX_CAP = 0x7fff; // max # workers > 1057: static final int EXTERNAL_ID_MASK = 0x3ffe; // max external queue id > 1058: static final int INVALID_ID = 0x4000; // unused external queue id @DougLea INVALID_ID looks to be unused now so we could remove it. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2727470227 From jpai at openjdk.org Mon Jan 26 13:23:52 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 13:23:52 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:22:07 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Use "list" instead of "queue" when referring to expandedPath which is processed FIFO and as such is not a queue src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 100: > 98: } > 99: > 100: /* Search path of URLs passed to the constructor or by calls to addURL I don't know if it was intentional, but this comment and some others added in this PR are missing a `.` after the sentence. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 113: > 111: * Access is guarded by a monitor on 'searchPath' > 112: */ > 113: private final ArrayList expandedPath = new ArrayList<>(); I think we should name this `manifestClassPath`. src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 139: > 137: public URLClassPath(URL[] urls, > 138: URLStreamHandlerFactory factory) { > 139: // Reject null URLs Nit - I think it would be better to clarify that it's intentional to (continue) to reject null element in the array. So may be reword this comment to "Reject null URL array or any null element in the array"? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727583497 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727581431 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727574621 From eirbjo at openjdk.org Mon Jan 26 13:35:09 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 13:35:09 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:18:13 GMT, Jaikiran Pai wrote: >> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: >> >> Use "list" instead of "queue" when referring to expandedPath which is processed FIFO and as such is not a queue > > src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 139: > >> 137: public URLClassPath(URL[] urls, >> 138: URLStreamHandlerFactory factory) { >> 139: // Reject null URLs > > Nit - I think it would be better to clarify that it's intentional to (continue) to reject null element in the array. So may be reword this comment to "Reject null URL array or any null element in the array"? Yeah, the issue here is that `ArrayList` is null friendly while `ArrayDeque` was hostile. So since there is no such thing as`Arrays::requireNonNullElements`, I used `List.of`, (as suggested by @stuart-marks in JDK-8301042). But that seemed non-obvious and brittle, hence the addition of the comment. What would you think about being explicit in the null check, such that the code documents itself: // Reject null URL array or any null element in the array Objects.requireNonNull(urls); for (URL url : urls) { Objects.requireNonNull(urls); } this.searchPath = new ArrayList<>(Arrays.asList(urls)); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727618873 From jpai at openjdk.org Mon Jan 26 13:42:26 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 13:42:26 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:32:20 GMT, Eirik Bj?rsn?s wrote: >> src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 139: >> >>> 137: public URLClassPath(URL[] urls, >>> 138: URLStreamHandlerFactory factory) { >>> 139: // Reject null URLs >> >> Nit - I think it would be better to clarify that it's intentional to (continue) to reject null element in the array. So may be reword this comment to "Reject null URL array or any null element in the array"? > > Yeah, the issue here is that `ArrayList` is null friendly while `ArrayDeque` was hostile. > > So since there is no such thing as`Arrays::requireNonNullElements`, I used `List.of`, (as suggested by @stuart-marks in JDK-8301042). > > But that seemed non-obvious and brittle, hence the addition of the comment. > > What would you think about being explicit in the null check, such that the code documents itself: > > > // Reject null URL array or any null element in the array > Objects.requireNonNull(urls); > for (URL url : urls) { > Objects.requireNonNull(urls); > } > > this.searchPath = new ArrayList<>(Arrays.asList(urls)); I think using `List.of()` is the right thing to do, since its behaviour is specified. A iteration as proposed here would very likely be refactored later into a `List.of()` as a clean up, when someone spots this code. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727646276 From jpai at openjdk.org Mon Jan 26 13:42:32 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 13:42:32 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 10:22:07 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Use "list" instead of "queue" when referring to expandedPath which is processed FIFO and as such is not a queue src/java.base/share/classes/jdk/internal/loader/URLClassPath.java line 488: > 486: * Adds the specified URLs to the list of 'Class-Path' expanded URLs > 487: */ > 488: private void addExpandedPaths(URL[] urls) { Once we rename the field to `manifestClassPath`, we should rename this method to `addManifestClassPaths` too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727651738 From eirbjo at openjdk.org Mon Jan 26 13:49:49 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 13:49:49 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v3] In-Reply-To: References: Message-ID: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision: - Be more specific in comment about rejecting null URL elements - Add periods to separate sentences in field comments - Rename expandedPath to manifestClassPath ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29288/files - new: https://git.openjdk.org/jdk/pull/29288/files/d7962442..36fca66c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=01-02 Stats: 11 lines in 1 file changed: 0 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29288/head:pull/29288 PR: https://git.openjdk.org/jdk/pull/29288 From eirbjo at openjdk.org Mon Jan 26 13:49:53 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 13:49:53 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:21:03 GMT, Jaikiran Pai wrote: > I don't know if it was intentional, but this comment and some others added in this PR are missing a `.` after the sentence. Not intentional, I added periods as separators for the field descriptors where this PR adds additional sentences. > I think we should name this `manifestClassPath`. Renamed, along with `addManifestClassPaths` and related comments. I think @liach wanted a name suggesting the DFS search order these URL where "expanded" in, while this better descibes the origin of the URL. I have a slight preference to the latter. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727673188 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727670018 From eirbjo at openjdk.org Mon Jan 26 13:49:54 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 13:49:54 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:38:46 GMT, Jaikiran Pai wrote: > I think using `List.of()` is the right thing to do, since its behaviour is specified. Good, I adopted your suggested comment here. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727662933 From liach at openjdk.org Mon Jan 26 13:54:26 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 13:54:26 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 06:39:30 GMT, Eirik Bj?rsn?s wrote: > If you look into the implementation of `Asssertions.assertThrows`, the only reflection happening is the call to `Class.isInstance` to check the expected exception type. The primary problem is NOT due to the implementation in the utility. It is due to the different code structure (and compiler artifacts, such as lambdas) generating different stack trace and potentially more exception wrapping. Such differences could be crucial to core reflection `Method.invoke` behavior or JVM decisions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29405#issuecomment-3799727304 From jpai at openjdk.org Mon Jan 26 13:59:02 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 13:59:02 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:49:49 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with three additional commits since the last revision: > > - Be more specific in comment about rejecting null URL elements > - Add periods to separate sentences in field comments > - Rename expandedPath to manifestClassPath test/jdk/jdk/internal/loader/URLClassPath/JarClassPathDfsOrder.java line 46: > 44: /* > 45: * @test > 46: * @bug 8375580 The OpenJDK dev guide has been updated to clarify when to use the `@bug` on tests https://openjdk.org/guide/. As per the guideline: > 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. This wasn't a product bug, so the `@bug` isn't necessary for this new test. test/jdk/jdk/internal/loader/URLClassPath/JarClassPathDfsOrder.java line 50: > 48: * @run junit JarClassPathDfsOrder > 49: */ > 50: public class JarClassPathDfsOrder { The JAR specification for the `Class-Path` attribute states: > The resulting URLs are inserted into the class path, immediately following the URL of the context JAR. For example, given the following class path ... so it's good to introduce a test for this (I haven't verified we don't have any). However, I think the use of DFS in the test name and comments can be removed. I think we should name the test `JarManifestClassPathOrder`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727708745 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727701607 From alanb at openjdk.org Mon Jan 26 14:01:31 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Jan 2026 14:01:31 GMT Subject: RFR: 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:23:16 GMT, Eirik Bj?rsn?s wrote: > Please review this small enhancement which makes `ZipFile.Source.Key` capture the relevant `BasicFileAttributes` fields eagerly in its constructor instead of calling into `BasicFileAttributes` for each `hashCode` or `equals` invocation. > > This reduces the memory footprint of `Key` instances. It should be performance positive since we avoid creating `FileTime` instances once per comparison and avoid synchronization getting the file key. > > Capturing fields early also improves readability by making it obvious from the field declarations what information Key uses when comparing equality. > > Pure refactoring, no tests updated, `noreg-trivial`. I think this should be okay, and low risk. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29411#issuecomment-3799756024 From eirbjo at openjdk.org Mon Jan 26 14:04:28 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 14:04:28 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: - Remove @bug tag, no product bug discovered - Rename test and deemphasize DFS is comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29288/files - new: https://git.openjdk.org/jdk/pull/29288/files/36fca66c..835e0141 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29288&range=02-03 Stats: 11 lines in 1 file changed: 0 ins; 1 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29288.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29288/head:pull/29288 PR: https://git.openjdk.org/jdk/pull/29288 From eirbjo at openjdk.org Mon Jan 26 14:08:07 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 14:08:07 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:55:54 GMT, Jaikiran Pai wrote: > This wasn't a product bug, so the `@bug` isn't necessary for this new test. Yes, thanks! I must have thought this was a "product change", but the requirement is indeed a product bug. Tag removed. > test/jdk/jdk/internal/loader/URLClassPath/JarClassPathDfsOrder.java line 50: > >> 48: * @run junit JarClassPathDfsOrder >> 49: */ >> 50: public class JarClassPathDfsOrder { > > The JAR specification for the `Class-Path` attribute states: > >> The resulting URLs are inserted into the class path, immediately following the URL of the context JAR. For example, given the following class path ... > > so it's good to introduce a test for this (I haven't verified we don't have any). However, I think the use of DFS in the test name and comments can be removed. I think we should name the test `JarManifestClassPathOrder`. Thanks, I have renamed the test and deemphasized the "DFS" aspect in comments. The long-standing behavior that we want to prevent regressions of is to find these files in DFS order though, so I left some minimum mentioning of it. Take a look at the updated test and let me know what you think. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727740672 PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727737183 From amaembo at gmail.com Mon Jan 26 14:08:52 2026 From: amaembo at gmail.com (Tagir Valeev) Date: Mon, 26 Jan 2026 15:08:52 +0100 Subject: Arrays.copyOfRange: insufficient range checks Message-ID: Hello! A friend of mine noticed that bounds checks in every overload of Arrays.copyOfRange are not enough. It checks only the following [1]: int newLength = to - from; if (newLength < 0) { throw new IllegalArgumentException(from + " > " + to); } However, a subtraction overflow is possible, which may make newLength positive. I've found an abandoned issue JDK-6530897 [2], which discusses this problem. What's not mentioned there is that the method may not only throw a wrong exception but may also finish successfully (given enough heap space) for obviously incorrect arguments. For example, consider the following code: void main() { byte[] arr = new byte[2_000_000_000]; byte[] arr2 = Arrays.copyOfRange(arr, 2_000_000_000, Integer.MIN_VALUE); IO.println(arr2.length); } On my machine, with openjdk build 25+36-3489 it's executed successfully and prints 147483648. According to the specification, it should throw IllegalArgumentException, as from is greater than to. Does anybody want to take a look at this problem? With best regards, Tagir Valeev [1] https://github.com/openjdk/jdk/blob/512f95cf2632167149e2118853ab4d6d636fe0a3/src/java.base/share/classes/java/util/Arrays.java#L3845 [2] https://bugs.openjdk.org/browse/JDK-6530897 -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at openjdk.org Mon Jan 26 14:31:17 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 14:31:17 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:01 GMT, Eirik Bj?rsn?s wrote: >> test/jdk/jdk/internal/loader/URLClassPath/JarClassPathDfsOrder.java line 50: >> >>> 48: * @run junit JarClassPathDfsOrder >>> 49: */ >>> 50: public class JarClassPathDfsOrder { >> >> The JAR specification for the `Class-Path` attribute states: >> >>> The resulting URLs are inserted into the class path, immediately following the URL of the context JAR. For example, given the following class path ... >> >> so it's good to introduce a test for this (I haven't verified we don't have any). However, I think the use of DFS in the test name and comments can be removed. I think we should name the test `JarManifestClassPathOrder`. > > Thanks, I have renamed the test and deemphasized the "DFS" aspect in comments. > > The long-standing behavior that we want to prevent regressions of is to find these files in DFS order though, so I left some minimum mentioning of it. > > Take a look at the updated test and let me know what you think. > so it's good to introduce a test for this (I haven't verified we don't have any). I removed `reversed()` in `addManifestClassPaths` and ran tests in `jdk/internal/loader` and `java/net/URLClassLoader`. The introduced regression was caught by the new test, but not by any existing test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2727826649 From afarley at openjdk.org Mon Jan 26 14:32:53 2026 From: afarley at openjdk.org (Adam Farley) Date: Mon, 26 Jan 2026 14:32:53 GMT Subject: RFR: 8376188: Win8365790Test cannot run on jtreg versions under 7.5.1+1 Message-ID: This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1. This has been tested elsewhere and seems to work well. Test configs: - JDK17 - jtreg 7.3.1+1 - JDK25 - jtreg 7.5.1+1 https://bugs.openjdk.org/browse/JDK-8376188 ------------- Commit messages: - Removing superfluous trailing whitespace - 8376188 Make Win8365790Test.java compatible with jtregs under 7.5.1+1 Changes: https://git.openjdk.org/jdk/pull/29416/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29416&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376188 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29416.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29416/head:pull/29416 PR: https://git.openjdk.org/jdk/pull/29416 From liach at openjdk.org Mon Jan 26 14:36:06 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 14:36:06 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG [v2] In-Reply-To: References: Message-ID: > Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. > > Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Review remarks ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29405/files - new: https://git.openjdk.org/jdk/pull/29405/files/8f311ea5..f9da740a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29405&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29405&range=00-01 Stats: 10 lines in 3 files changed: 8 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29405.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29405/head:pull/29405 PR: https://git.openjdk.org/jdk/pull/29405 From alanb at openjdk.org Mon Jan 26 14:36:06 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Jan 2026 14:36:06 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:32:26 GMT, Chen Liang wrote: >> Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. >> >> Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review remarks Marked as reviewed by alanb (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29405#pullrequestreview-3706298179 From liach at openjdk.org Mon Jan 26 14:36:08 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 14:36:08 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG [v2] In-Reply-To: References: Message-ID: <603ebyx8OUhBLo9T2CyNDuSzpgpniZ-_c03MhZOoYu4=.2507c004-a1a5-4701-a9c9-1dcf0403add8@github.com> On Mon, 26 Jan 2026 08:37:10 GMT, Alan Bateman wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Review remarks > > test/jdk/java/lang/reflect/ChainedReflection.java line 42: > >> 40: class Inner { >> 41: // JUnit does not allow test class to declare multiple constructors >> 42: Inner() throws ReflectiveOperationException { > > This comment might be confusing to future maintainers, may not immediately seeing the compiler generated constructor. Maybe expand the comment on this and put it on the class rather the constructor. I have expanded this on `Inner` to: > This inner class is declared with a constructor that ctorCallMethodInvoke > reflects on. Such a constructor cannot be declared in ChainedReflection > because JUnit does not allow a test class to declare multiple constructors. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2727818111 From liach at openjdk.org Mon Jan 26 14:36:11 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 14:36:11 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:18:33 GMT, Eirik Bj?rsn?s wrote: >> test/jdk/java/lang/reflect/IllegalArgumentsTest.java line 28: >> >>> 26: * @bug 8277964 >>> 27: * @summary Test IllegalArgumentException be thrown when an argument is invalid >>> 28: * @run junit/othervm/timeout=720 IllegalArgumentsTest >> >> On the surface, the test is begging to use assertThrows but this a test for a C2 issue so I agree it shouldn't be changed. > >> On the surface, the test is begging to use assertThrows but this a test for a C2 issue so I agree it shouldn't be changed. > > Then perhaps a comment documenting this decision would be helpful to future maintainers who may be tempted to improve the test using `assertThrows`. Added a `@comment` tag describing the rationale for not using framework utilities in both `IllegalArgumentsTest` and `ChainedReflection`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29405#discussion_r2727821115 From vklang at openjdk.org Mon Jan 26 15:10:54 2026 From: vklang at openjdk.org (Viktor Klang) Date: Mon, 26 Jan 2026 15:10:54 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v29] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: On Sun, 25 Jan 2026 20:09:13 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: > > Don't oversignal LIFO src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1787: > 1785: (phase = w.phase) != 0 && (phase & IDLE) != 0) > 1786: releaseWaiters(); // ensure released > 1787: if (w == null || w.source != DROPPED) { @DougLea Do we need a volatile read of `source` here, or would a weaker access read be sufficient? (since w.phase is already volatile-y read prior to this read) src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2247: > 2245: int s = 0; > 2246: if (task != null && (s = task.status) >= 0 && internal && w != null) { > 2247: int wid = w.phase & SMASK, r = wid + 2, wsrc = w.source; @DougLea Same comment here w.r.t. the w.source access ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2727970871 PR Review Comment: https://git.openjdk.org/jdk/pull/28797#discussion_r2727978715 From dfuchs at openjdk.org Mon Jan 26 15:28:43 2026 From: dfuchs at openjdk.org (Daniel Fuchs) Date: Mon, 26 Jan 2026 15:28:43 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:05:01 GMT, Eirik Bj?rsn?s wrote: >> test/jdk/jdk/internal/loader/URLClassPath/JarClassPathDfsOrder.java line 46: >> >>> 44: /* >>> 45: * @test >>> 46: * @bug 8375580 >> >> The OpenJDK dev guide has been updated to clarify when to use the `@bug` on tests https://openjdk.org/guide/. As per the guideline: >> >>> 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. >> >> This wasn't a product bug, so the `@bug` isn't necessary for this new test. > >> This wasn't a product bug, so the `@bug` isn't necessary for this new test. > > Yes, thanks! I must have thought this was a "product change", but the requirement is indeed a product bug. Tag removed. I added `noreg-cleanup` to the issue. The rule is that if there's no test with an `@bug` that refers to the issue, then the issue should have a `noreg-xxx` label. Given that this fix is supposed to be a simple refactoring that leaves the behavior unchanged I believe that `noreg-cleanup` applies. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29288#discussion_r2728062895 From eirbjo at gmail.com Mon Jan 26 15:36:28 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 16:36:28 +0100 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key Message-ID: Hi, Where available, ZipFile.Source.Key uses the "file key" from BasicAttributes:fileKey to determine if paths refer to the same file instance. For a "hello world" program in a jar on the classpath, this dependency on the NIO file system API pulls in just about 50 classes. (See diff below). If we rewrite ZipFile to not consider the file key and to use File::lastModified instead of BasicFileAttributes::lastModifiedTime, these classes are no longer loaded. The loading of 50 extra classes (comprising 9 percent of 576 classes) seems like a high price to pay for this caching mechanism! As an experiment, I added File::fileKey which on Unix calls stat and retrieves the device and inode information in similar fashion to what NIO's BasicFileAttributes::fileKey does. This allows us to still consider the same "file key" information as today, but without loading these 50 extra classes. Perhaps we should consider adding File::fileKey as a public class? If not, perhaps we can keep it private and expose it internally through a shared secret? See the draft implementation/experiment in this branch: https://github.com/openjdk/jdk/compare/master...eirbjo:zipfile-java.io-filekey?expand=1 Thoughts and opinions are welcome. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eirbjo at gmail.com Mon Jan 26 15:38:43 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 16:38:43 +0100 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key In-Reply-To: References: Message-ID: For the interested, here's a diff of classes loaded before and after the removal of the NIO dependency: 33a34 > java.io.UnixFileSystem$UnixFileKey 140,142d140 < java.lang.ThreadLocal < java.lang.ThreadLocal$ThreadLocalMap < java.lang.ThreadLocal$ThreadLocalMap$Entry 242,256d239 < java.nio.file.CopyOption < java.nio.file.FileSystem < java.nio.file.Files < java.nio.file.LinkOption < java.nio.file.OpenOption < java.nio.file.Path < java.nio.file.StandardOpenOption < java.nio.file.Watchable < java.nio.file.attribute.AttributeView < java.nio.file.attribute.BasicFileAttributeView < java.nio.file.attribute.BasicFileAttributes < java.nio.file.attribute.FileAttributeView < java.nio.file.attribute.FileTime < java.nio.file.attribute.PosixFileAttributes < java.nio.file.spi.FileSystemProvider 296,299d278 < java.util.IdentityHashMap < java.util.IdentityHashMap$IdentityHashMapIterator < java.util.IdentityHashMap$KeyIterator < java.util.IdentityHashMap$KeySet 348d326 < java.util.concurrent.TimeUnit 438d415 < jdk.internal.misc.CarrierThreadLocal 446,447d422 < jdk.internal.misc.TerminatingThreadLocal < jdk.internal.misc.TerminatingThreadLocal$1 547,571d521 < sun.nio.fs.AbstractBasicFileAttributeView < sun.nio.fs.AbstractFileSystemProvider < sun.nio.fs.BsdFileAttributeViews < sun.nio.fs.BsdFileAttributeViews$Basic < sun.nio.fs.BsdFileSystem < sun.nio.fs.BsdFileSystemProvider < sun.nio.fs.DefaultFileSystemProvider < sun.nio.fs.DynamicFileAttributeView < sun.nio.fs.MacOSXFileSystem < sun.nio.fs.MacOSXFileSystemProvider < sun.nio.fs.NativeBuffer < sun.nio.fs.NativeBuffer$Deallocator < sun.nio.fs.NativeBuffers < sun.nio.fs.NativeBuffers$1 < sun.nio.fs.UnixFileAttributeViews$Basic < sun.nio.fs.UnixFileAttributes < sun.nio.fs.UnixFileAttributes$UnixAsBasicFileAttributes < sun.nio.fs.UnixFileKey < sun.nio.fs.UnixFileStoreAttributes < sun.nio.fs.UnixFileSystem < sun.nio.fs.UnixFileSystemProvider < sun.nio.fs.UnixMountEntry < sun.nio.fs.UnixNativeDispatcher < sun.nio.fs.UnixPath < sun.nio.fs.Util On Mon, Jan 26, 2026 at 4:36?PM Eirik Bj?rsn?s wrote: > Hi, > > Where available, ZipFile.Source.Key uses the "file key" from > BasicAttributes:fileKey to determine if paths refer to the same file > instance. > > For a "hello world" program in a jar on the classpath, this dependency on > the NIO file system API pulls in just about 50 classes. (See diff below). > > If we rewrite ZipFile to not consider the file key and to use > File::lastModified instead of BasicFileAttributes::lastModifiedTime, these > classes are no longer loaded. > > The loading of 50 extra classes (comprising 9 percent of 576 classes) > seems like a high price to pay for this caching mechanism! > > As an experiment, I added File::fileKey which on Unix calls stat and > retrieves the device and inode information in similar fashion to what > NIO's BasicFileAttributes::fileKey does. This allows us to still consider > the same "file key" information as today, but without loading these 50 > extra classes. > > Perhaps we should consider adding File::fileKey as a public class? If not, > perhaps we can keep it private and expose it internally through a shared > secret? > > See the draft implementation/experiment in this branch: > > > https://github.com/openjdk/jdk/compare/master...eirbjo:zipfile-java.io-filekey?expand=1 > > Thoughts and opinions are welcome. > > Eirik. > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From liach at openjdk.org Mon Jan 26 16:04:29 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 16:04:29 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: <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> 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 Changes requested by liach (Reviewer). src/java.base/share/classes/java/util/TreeMap.java line 2028: > 2026: } > 2027: > 2028: public abstract Spliterator> spliterator(); I don't think you need this huge a patch. I think you should just do: Suggestion: public Spliterator> spliterator() { return Spliterators.spliterator(iterator(), Spliterator.DISTINCT); } Your patch is introducing spliterator behavioral changes unrelated to the performance regression fix. ------------- PR Review: https://git.openjdk.org/jdk/pull/28608#pullrequestreview-3706750477 PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2728206435 From epeter at openjdk.org Mon Jan 26 16:04:33 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:04:33 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? Currently, we are using `T_SHORT` for `Float16`, right? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800362594 From alan.bateman at oracle.com Mon Jan 26 16:07:10 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jan 2026 16:07:10 +0000 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key In-Reply-To: References: Message-ID: <9deaff20-8b67-4691-a0ba-0921fd3dbe38@oracle.com> On 26/01/2026 15:36, Eirik Bj?rsn?s wrote: > Hi, > > Where available,?ZipFile.Source.Key uses the "file key" from > BasicAttributes:fileKey to determine if paths refer to the same file > instance. > > For a "hello world" program in a jar on the classpath, this dependency > on the NIO file system API pulls in just about 50 classes. (See diff > below). > > If we rewrite ZipFile to not consider the file key and to use > File::lastModified instead of BasicFileAttributes::lastModifiedTime, > these classes are no longer loaded. > I don't think we should go back to that. Part of it is the FileKey, which was some of motivation for the use in ZipFile There are also experiments that re-implement most of java.io and ZipFile to use FileChannel so these classes will be loaded anyway. Actually, anything non-trivial causes these classes to be loaded. -Alan From jpai at openjdk.org Mon Jan 26 16:08:53 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 16:08:53 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:28:27 GMT, Adam Farley wrote: > This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1. > > > This has been tested elsewhere and seems to work well. > Test configs: > - JDK17 - jtreg 7.3.1+1 > - JDK25 - jtreg 7.5.1+1 > > https://bugs.openjdk.org/browse/JDK-8376188 Hello Adam, the change looks right to me. However, the title of the JBS issue might need adjusting. As far as I know, it's not a requirement to be able to run the mainline JDK against jtreg versions that are lower than the minimum version configured this repo. Can you update the JBS issue title to "Win8365790Test is missing @build jtreg.SkippedException"? I think that would be more accurate. You will then have to update the title of this PR too. ------------- PR Review: https://git.openjdk.org/jdk/pull/29416#pullrequestreview-3706759851 From afarley at openjdk.org Mon Jan 26 16:08:54 2026 From: afarley at openjdk.org (Adam Farley) Date: Mon, 26 Jan 2026 16:08:54 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: <1ZrY_CDwqDilRBhhfKRsdmg7mjMNbaot3WodreRJ2VA=.306cbd59-4d6a-4199-a0e7-5bab3d98fa64@github.com> On Mon, 26 Jan 2026 16:03:20 GMT, Jaikiran Pai wrote: > Hello Adam, the change looks right to me. However, the title of the JBS issue might need adjusting. As far as I know, it's not a requirement to be able to run the mainline JDK against jtreg versions that are lower than the minimum version configured this repo. > > Can you update the JBS issue title to "Win8365790Test is missing @build jtreg.SkippedException"? I think that would be more accurate. You will then have to update the title of this PR too. Sure. On it now. Edit: Done. Thanks for the quick reply. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3800378963 From alan.bateman at oracle.com Mon Jan 26 16:11:50 2026 From: alan.bateman at oracle.com (Alan Bateman) Date: Mon, 26 Jan 2026 16:11:50 +0000 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key In-Reply-To: References: Message-ID: <1f315537-eb14-42d6-9ba5-3c49389a39e4@oracle.com> On 26/01/2026 15:36, Eirik Bj?rsn?s wrote: > : > > Perhaps we should consider adding File::fileKey as a public class? I don't think that would make sense to expose on the legacy File class. We should be pointers developers to the new API. Also the notion of "file key" is an advanced topic, not something for File anyway. -Alan From jpai at openjdk.org Mon Jan 26 16:14:56 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 16:14:56 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:28:27 GMT, Adam Farley wrote: > This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1. > > > This has been tested elsewhere and seems to work well. > Test configs: > - JDK17 - jtreg 7.3.1+1 > - JDK25 - jtreg 7.5.1+1 > > https://bugs.openjdk.org/browse/JDK-8376188 Thank you for the update, this looks OK to me from a jtreg test point of view. Given the area, I will let someone from jpackage area to Review and approve this. Plus, `test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.throwSkippedException(...)` seems to dynamically define the `jtreg.SkippedException` https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L1310, so I'm not sure what kind of impact (if any) this change would have on this or other tests in this area. ------------- PR Review: https://git.openjdk.org/jdk/pull/29416#pullrequestreview-3706802055 From jpai at openjdk.org Mon Jan 26 16:23:31 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 16:23:31 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments The changes look OK to me. I've run some manual tests locally to verify that the ordering hasn't changed after this change. I'll run tier testing in our CI and approve this PR once that comes back fine. ------------- PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3706837528 From jpai at openjdk.org Mon Jan 26 16:34:15 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 16:34:15 GMT Subject: RFR: 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:23:16 GMT, Eirik Bj?rsn?s wrote: > Please review this small enhancement which makes `ZipFile.Source.Key` capture the relevant `BasicFileAttributes` fields eagerly in its constructor instead of calling into `BasicFileAttributes` for each `hashCode` or `equals` invocation. > > This reduces the memory footprint of `Key` instances. It should be performance positive since we avoid creating `FileTime` instances once per comparison and avoid synchronization getting the file key. > > Capturing fields early also improves readability by making it obvious from the field declarations what information Key uses when comparing equality. > > Pure refactoring, no tests updated, `noreg-trivial`. This looks OK to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29411#pullrequestreview-3706893286 From epeter at openjdk.org Mon Jan 26 16:36:39 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:36:39 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 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 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa I asked some people internally, and they seem to be _very_ opposed to a new BasicType. Because it goes across the JVM, as I can also see in your patch. Apparently, they wanted to avoid the use of new BasicTypes, mostly managed except for the new `T_FLAT_ELEMENT`. Using `T_SHORT` for `Float16` would be strongly preferred. I think it may be good to ask @fparain @rose00 @iwanowww @vnkozlov if they have opinions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800525049 From henryjen at openjdk.org Mon Jan 26 16:37:59 2026 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 26 Jan 2026 16:37:59 GMT Subject: RFR: 8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref) Message-ID: Use try-with-resource on the ModuleReader ------------- Commit messages: - 8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref) Changes: https://git.openjdk.org/jdk/pull/29376/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29376&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8373699 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29376.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29376/head:pull/29376 PR: https://git.openjdk.org/jdk/pull/29376 From jpai at openjdk.org Mon Jan 26 16:38:51 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Mon, 26 Jan 2026 16:38:51 GMT Subject: RFR: 8376271: ZipFile comment confusingly refers to "native" ZIP file implementation In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 10:57:52 GMT, Eirik Bj?rsn?s wrote: > Please review this comment-only PR which updates a field comment referring to `ZipFile.Source` as "native". > > ZipFile has not used a native implementation since Java 8, so this comment may be confusing. > > The comment seems to have been introduced in 2017 as part of JDK-8185582 when ZipFile was updated to use Cleaners instead of finalizers. (The use of quotation marks in "native" may have meant to indicate that this is "not really native", but I still find it confusing). > > While visiting this comment, I also made an attempt to make the leading sentence of this field comment less mysterious. > > Comment only, trivial, low risk: `noreg-trivial` This looks good to me. ------------- Marked as reviewed by jpai (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29401#pullrequestreview-3706911928 From henryjen at openjdk.org Mon Jan 26 16:41:24 2026 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 26 Jan 2026 16:41:24 GMT Subject: Integrated: 8373924: Remove unreferenced ImageDecompressor::image_decompressor_close In-Reply-To: References: Message-ID: <-aGCcumJZykUpC56GGxLRVMKNAVIemLLUrwGARXTkbk=.bfede5b8-6617-44e5-9ae3-1fa14565142e@github.com> On Thu, 22 Jan 2026 18:57:30 GMT, Henry Jen wrote: > I don't see image_decompressor_close actually referenced in the code base, as the decompressors are static and setup from image_decompressor_init(). > > This PR implements proper cleanup for decompressors to be defensive. This pull request has now been integrated. Changeset: 67beb9cd Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/67beb9cd812db2af49c62c95d69f2f27d0a20af8 Stats: 8 lines in 2 files changed: 1 ins; 4 del; 3 mod 8373924: Remove unreferenced ImageDecompressor::image_decompressor_close Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29371 From psandoz at openjdk.org Mon Jan 26 16:51:30 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Mon, 26 Jan 2026 16:51:30 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 12:17:02 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 34 commits: > > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Clanups > - Refactoring vectorIntrinsics > - Refactoring and cleanups > - Refactoring and cleanups > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - Adding testpoint for JDK-8373574 > - Review comments resolutions > - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 > - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3800594113 From alanb at openjdk.org Mon Jan 26 16:52:19 2026 From: alanb at openjdk.org (Alan Bateman) Date: Mon, 26 Jan 2026 16:52:19 GMT Subject: RFR: 8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref) In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:57:18 GMT, Henry Jen wrote: > Use try-with-resource on the ModuleReader This looks okay. Not a concern when using the `jlink` on the command line but could be an issue if using ToolProvider and invoking jlink many times. ------------- Marked as reviewed by alanb (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29376#pullrequestreview-3706971902 From epeter at openjdk.org Mon Jan 26 16:54:45 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:54:45 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 29 Dec 2025 17:39:42 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 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... I had another quick look. And I was wondering: In my experience, float/double reductions that just add/mul up values (aka simple reductions) generally have no speedups when vectorized. The reason is that no matter if they are scalar or vector, the bottleneck is the latency along the reduction chain. So why do you measure speedups here for `Float16`? Do you have a good explanation? Because memory bandwidth should be even less the problem here, so the effect of latency along the chain has an even bigger weight. What do you think? src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1929: > 1927: ext(vtmp, T8B, vsrc, vsrc, 6); > 1928: faddh(dst, dst, vtmp); > 1929: if (isQ) { I don't think the `if` should be indented here, right? src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1940: > 1938: } > 1939: BLOCK_COMMENT("} neon_reduce_add_fp16"); > 1940: } Given that the reduction order is sequential: why do you see any speedup in your benchmarks, comparing scalar to vector performance? How do you explain it? I'm just curious ;) ------------- PR Review: https://git.openjdk.org/jdk/pull/27526#pullrequestreview-3706944699 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2728374969 PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2728381603 From epeter at openjdk.org Mon Jan 26 16:54:46 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Mon, 26 Jan 2026 16:54:46 GMT Subject: RFR: 8366444: Add support for add/mul reduction operations for Float16 [v5] In-Reply-To: References: <-ovnBfgX38snqeb0xcSNFTeHOfi6uucPLID1asGwI3E=.7f1c09e9-d14a-4b60-ba9a-2811011881c3@github.com> Message-ID: On Mon, 26 Jan 2026 16:45:43 GMT, Emanuel Peter 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 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 indicate... > > src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 1940: > >> 1938: } >> 1939: BLOCK_COMMENT("} neon_reduce_add_fp16"); >> 1940: } > > Given that the reduction order is sequential: why do you see any speedup in your benchmarks, comparing scalar to vector performance? How do you explain it? I'm just curious ;) Also: why not allow a vector with only 2 elements? Is there some restriction here? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27526#discussion_r2728407382 From eirbjo at gmail.com Mon Jan 26 17:07:24 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 18:07:24 +0100 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key In-Reply-To: <9deaff20-8b67-4691-a0ba-0921fd3dbe38@oracle.com> References: <9deaff20-8b67-4691-a0ba-0921fd3dbe38@oracle.com> Message-ID: On Mon, Jan 26, 2026 at 5:07?PM Alan Bateman wrote: Alan, I don't think we should go back to that. I was not suggesting we ditch the file key information from Key, that was more to demonstrate the change in class loading. > Actually, anything non-trivial causes these classes to be loaded. > Granted, although many useful programs are indeed trivial! I don't think that would make sense to expose on the legacy File class. Okay. I'd be happy with a private API point that wasn't so eager to load these classes at startup. For reference, "java -cp hello.jar Hello" runs in ~62 ms on the mainline. On a branch using a non-NIO "file key" API, it runs in ~58. So startup impact is significant. But the appetite seems meager, so I don't plan to kick this ball any further. Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From darcy at openjdk.org Mon Jan 26 17:23:48 2026 From: darcy at openjdk.org (Joe Darcy) Date: Mon, 26 Jan 2026 17:23:48 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java In-Reply-To: References: Message-ID: <2TnRg2OaCuwmRw-W8wHeA1vPS5ZcaN6xmodjXoh0fp4=.c83878f8-9e6d-406d-8fdf-76fc9e587c46@github.com> On Fri, 16 Jan 2026 09:22:52 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... @toxaart, please file a CSR to cover the API changes of this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3800751669 From henryjen at openjdk.org Mon Jan 26 17:22:51 2026 From: henryjen at openjdk.org (Henry Jen) Date: Mon, 26 Jan 2026 17:22:51 GMT Subject: Integrated: 8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref) In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 06:57:18 GMT, Henry Jen wrote: > Use try-with-resource on the ModuleReader This pull request has now been integrated. Changeset: b42861a2 Author: Henry Jen URL: https://git.openjdk.org/jdk/commit/b42861a2aa5bf5fde348cf17c5e40134148de1b4 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8373699: JLink: ModuleReader should be closed in JlinkTask.getReleaseInfo(mref) Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29376 From sviswanathan at openjdk.org Mon Jan 26 17:46:42 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 26 Jan 2026 17:46:42 GMT Subject: RFR: 8303762: Optimize vector slice operation with constant index using VPALIGNR instruction [v12] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 02:34:30 GMT, Xiaohong Gong wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > LGTM! Thanks for your updating! > Hi @XiaohongGong , your comments have been addressed. Hi @sviswa7, can you kindly review x86 part. Thanks @jatin-bhateja. I will take a look next week. ------------- PR Comment: https://git.openjdk.org/jdk/pull/24104#issuecomment-3800844163 From asemenyuk at openjdk.org Mon Jan 26 17:47:37 2026 From: asemenyuk at openjdk.org (Alexey Semenyuk) Date: Mon, 26 Jan 2026 17:47:37 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 16:12:35 GMT, Jaikiran Pai wrote: >> This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1. >> >> >> This has been tested elsewhere and seems to work well. >> Test configs: >> - JDK17 - jtreg 7.3.1+1 >> - JDK25 - jtreg 7.5.1+1 >> >> https://bugs.openjdk.org/browse/JDK-8376188 > > Thank you for the update, this looks OK to me from a jtreg test point of view. > > Given the area, I will let someone from jpackage area to Review and approve this. Plus, `test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.throwSkippedException(...)` seems to dynamically define the `jtreg.SkippedException` https://github.com/openjdk/jdk/blob/master/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L1310, so I'm not sure what kind of impact (if any) this change would have on this or other tests in this area. Almost any jpackage test can throw `jtreg.SkippedException`. Instead of pulling in this tiny dependency from the JDK test lib, jpackage tests define a copy of this exception type, as @jaikiran correctly pointed out. You either need to add * @library /test/lib * @build jtreg.SkippedException to almost every jpackage test declaration and remove the internal copy of the `jtreg.SkippedException` if this effort justifies the benefit, or find a better solution to the problem. I guess the problem applies to JDK17 where the jpackage test lib doesn't have a copy of the `jtreg.SkippedException`, doesn't reference the one from the JDK test lib, but still supports throwing this exception via reflection: https://github.com/openjdk/jdk17u/blob/20a272cada273ceeec432dc027ddb62a93304143/test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TKit.java#L503 The copy of the `jtreg.SkippedException` exception was added to the jpackage test lib in [JDK-8352419](https://bugs.openjdk.org/browse/JDK-8352419). ------------- PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3800848878 From liach at openjdk.org Mon Jan 26 18:07:28 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:07:28 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: References: Message-ID: > We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: > > > @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions > > > Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. > > As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. > > I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! Chen Liang has updated the pull request incrementally with one additional commit since the last revision: Remove redundant dot ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29402/files - new: https://git.openjdk.org/jdk/pull/29402/files/f76fa06c..74af3243 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=00-01 Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/29402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402 PR: https://git.openjdk.org/jdk/pull/29402 From eirbjo at gmail.com Mon Jan 26 18:14:30 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 19:14:30 +0100 Subject: Observation: The cost of using NIO BasicFileAttributes in ZipFile.Source.Key In-Reply-To: References: <9deaff20-8b67-4691-a0ba-0921fd3dbe38@oracle.com> Message-ID: On Mon, Jan 26, 2026 at 6:07?PM Eirik Bj?rsn?s wrote: > For reference, "java -cp hello.jar Hello" runs in ~62 ms on the mainline. > On a branch using a non-NIO "file key" API, it runs in ~58. > So startup impact is significant. > Interestingly, this change also lowered the JDK-internal native memory usage enough to cause memory allocation in some Unsafe tests to succeed because they expect OOM. Filed https://bugs.openjdk.org/browse/JDK-8376398 to investigate these brittle tests. Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jvernee at openjdk.org Mon Jan 26 18:26:42 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Mon, 26 Jan 2026 18:26:42 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: Message-ID: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> On Mon, 26 Jan 2026 08:36:39 GMT, Christian Stein wrote: >> Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. >> >> Prior to this commit, a `MANFEST.MF` reading >> >> Automatic-Module-Name: default >> >> added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: >> >> $ java --module-path a.jar --describe-module default >> >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for a.jar >> Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier >> >> >> With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: >> >> >> invalid module name of Automatic-Module-Name entry in manifest: default >> >> >> The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 105: > 103: this.zis = zis; > 104: checkModuleDescriptor(MODULE_INFO); > 105: checkAutomaticModuleName(); The separate method is much better. I don't think doing this in the constructor is great though. I suggest moving this, and the existing call to `checkModuleDescriptor` to the `validate` method, then the constructor is for instantiation only, and the validate method handles the validate logic. (but, that's more of a personal preference) src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 480: > 478: errorAndInvalid(formatMsg("error.validator.manifest.invalid.automatic.module.name", automaticModuleName)); > 479: } > 480: if (md == null || automaticModuleName.equals(md.name())) { Realizing this now, but this is only checking the top-level `module-info.class`, not any of the ones under the `META-INF/versions` directories. e.g. `checkModuleDescriptor` is also being called for each versioned `module-info.class` file. Is that something that we should also be doing for this check? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2728711130 PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2728741939 From liach at openjdk.org Mon Jan 26 18:32:47 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:32:47 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 Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28540#issuecomment-3801082528 From eirbjo at openjdk.org Mon Jan 26 18:35:18 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 18:35:18 GMT Subject: RFR: 8376398: [TESTBUG] Testing of Unsafe native (re)allocation is sensitive to current JDK native memory use Message-ID: <2VzXQvgMoYrn4XLcGI-Mk53n53WiaMTlF6VQ--vsj8A=.feec0d1d-a524-4785-b21f-dc420685bd23@github.com> Please consider this PR which bumps the size of attempted allocations with 1m such that the tests are less brittle to JDK-internal native memory use. These tests currently run with `XX:MallocLimit=other:100m:oom`, but also try to allocate `100 * 1024 * 1024` bytes. With current JDK-internal native memory use, these allocation fail with OOM. When the JDK itself uses less memory, these tests start failing because allocation succeeds. I think we should simply try to allocate one more megabyte than the configured limit, which should cause the allocation to fail regardless of internal JVM native memory use. ------------- Commit messages: - Attempt to allocate 1m more than limit Changes: https://git.openjdk.org/jdk/pull/29429/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29429&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376398 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29429.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29429/head:pull/29429 PR: https://git.openjdk.org/jdk/pull/29429 From liach at openjdk.org Mon Jan 26 18:35:22 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 18:35:22 GMT Subject: Integrated: 8372696: Allow boot classes to explicitly opt-in for final field trusting In-Reply-To: References: Message-ID: On Thu, 27 Nov 2025 16:16:05 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. This pull request has now been integrated. Changeset: 3220c4cb Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/3220c4cb431a2c4eb8bb2d60f0d5046e40af69bd Stats: 168 lines in 13 files changed: 154 ins; 13 del; 1 mod 8372696: Allow boot classes to explicitly opt-in for final field trusting Reviewed-by: jvernee, jrose, alanb ------------- PR: https://git.openjdk.org/jdk/pull/28540 From naoto at openjdk.org Mon Jan 26 18:54:54 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 26 Jan 2026 18:54:54 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v2] In-Reply-To: References: Message-ID: > This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Added a test that asserts parse with hour-only offset ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29393/files - new: https://git.openjdk.org/jdk/pull/29393/files/14c4beb1..1b253613 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=00-01 Stats: 5 lines in 1 file changed: 5 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29393/head:pull/29393 PR: https://git.openjdk.org/jdk/pull/29393 From liach at openjdk.org Mon Jan 26 19:34:06 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 19:34:06 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 18:54:54 GMT, Naoto Sato wrote: >> This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Added a test that asserts parse with hour-only offset Thanks, the new test looks good to me. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29393#issuecomment-3801338775 From liach at openjdk.org Mon Jan 26 19:33:51 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 19:33:51 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 17:44:47 GMT, Alexey Semenyuk wrote: > to almost every jpackage test declaration For classes that do not declare `@library` tags, I think you can declare a `TEST.properties` containing a line: lib.dirs = /test/lib ------------- PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3801296036 From liach at openjdk.org Mon Jan 26 19:39:51 2026 From: liach at openjdk.org (Chen Liang) Date: Mon, 26 Jan 2026 19:39:51 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())` src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 539: > 537: * @return the number of Unicode code points in this String > 538: * @since 26 > 539: */ Suggestion: /** * @since 27 */ src/java.base/share/classes/java/lang/CharSequence.java line 262: > 260: * > 261: * @return the number of Unicode code points in this sequence > 262: * @since 26 Suggestion: * {@return the number of Unicode code points in this character sequence} * Unpaired surrogates count as one code point each. * * @since 27 src/java.base/share/classes/java/lang/Character.java line 9965: > 9963: * @since 26 > 9964: */ > 9965: public static int codePointCount(CharSequence seq) { Let's remove this method, given we have a method on CharSequence already. src/java.base/share/classes/java/lang/Character.java line 10011: > 10009: * @throws NullPointerException if {@code a} is null. > 10010: * @since 26 > 10011: */ Suggestion: /** * {@return the number of Unicode code points in the {@code char} array} * Unpaired surrogates count as one code point each. * * @param a the {@code char} array * @throws NullPointerException if {@code a} is null * @since 27 */ src/java.base/share/classes/java/lang/String.java line 1723: > 1721: * > 1722: * @return the number of Unicode code points in this String > 1723: * @since 26 Suggestion: * {@return the number of Unicode code points in this String} * Unpaired surrogates count as one code point each. * * @since 27 src/java.base/share/classes/java/lang/StringBuffer.java line 274: > 272: > 273: /** > 274: * @since 26 Suggestion: * @since 27 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728958484 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728956859 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728961159 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728967673 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728954676 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2728962198 From eirbjo at openjdk.org Mon Jan 26 20:14:36 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 20:14:36 GMT Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile Message-ID: Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`. With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater. No tests updated, strict refactoring, `noreg-cleanup`. ------------- Commit messages: - Replace ArrayDeque with ArrayList Changes: https://git.openjdk.org/jdk/pull/29430/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376403 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29430/head:pull/29430 PR: https://git.openjdk.org/jdk/pull/29430 From hgreule at openjdk.org Mon Jan 26 20:16:38 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 26 Jan 2026 20:16:38 GMT Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: On Wed, 21 Jan 2026 19:25:30 GMT, Hannes Greule wrote: >> A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. > > Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: > > update according John's suggestion Thanks to everyone involved! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29174#issuecomment-3801546875 From hgreule at openjdk.org Mon Jan 26 20:16:39 2026 From: hgreule at openjdk.org (Hannes Greule) Date: Mon, 26 Jan 2026 20:16:39 GMT Subject: Integrated: 8374538: Wrong specification of MethodHandles.constant(...) In-Reply-To: References: Message-ID: On Mon, 12 Jan 2026 18:36:33 GMT, Hannes Greule wrote: > A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. This pull request has now been integrated. Changeset: 82bd3831 Author: Hannes Greule URL: https://git.openjdk.org/jdk/commit/82bd3831b0f1e268ae76b31a803c86094add8e92 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod 8374538: Wrong specification of MethodHandles.constant(...) Reviewed-by: liach, jvernee ------------- PR: https://git.openjdk.org/jdk/pull/29174 From aturbanov at openjdk.org Mon Jan 26 20:39:22 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Mon, 26 Jan 2026 20:39:22 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java In-Reply-To: References: Message-ID: On Fri, 16 Jan 2026 09:22:52 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... src/java.base/share/classes/java/lang/FdLibm.java line 3544: > 3542: hx = __HI(x); > 3543: ix = hx & 0x7fffffff; > 3544: if(ix >= 0x7ff00000) { Suggestion: if (ix >= 0x7ff00000) { src/java.base/share/classes/java/lang/FdLibm.java line 3548: > 3546: } > 3547: if(ix < 0x3e300000) { // |x| < 2**-28 > 3548: if(huge + x > 1.0) { Suggestion: if (ix < 0x3e300000) { // |x| < 2**-28 if (huge + x > 1.0) { src/java.base/share/classes/java/lang/FdLibm.java line 3552: > 3550: } > 3551: } > 3552: if(ix > 0x41b00000) { // |x| > 2**28 Suggestion: if (ix > 0x41b00000) { // |x| > 2**28 test/jdk/java/lang/Math/HyperbolicTests.java line 1535: > 1533: > 1534: > 1535: for(int i = 0; i < testCases.length; i++) { Suggestion: for (int i = 0; i < testCases.length; i++) { test/jdk/java/lang/Math/HyperbolicTests.java line 1544: > 1542: > 1543: > 1544: for(double nan : Tests.NaNs) { Suggestion: for (double nan : Tests.NaNs) { test/jdk/java/lang/Math/HyperbolicTests.java line 1559: > 1557: > 1558: > 1559: for(int i = 0; i < specialTestCases.length; i++) { Suggestion: for (int i = 0; i < specialTestCases.length; i++) { test/jdk/java/lang/Math/HyperbolicTests.java line 1572: > 1570: // double significand. > 1571: > 1572: for(int i = DoubleConsts.MIN_SUB_EXPONENT; i < -27; i++) { Suggestion: for (int i = DoubleConsts.MIN_SUB_EXPONENT; i < -27; i++) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729161991 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729162357 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729162705 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729154923 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729155502 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729156624 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2729157284 From eirbjo at openjdk.org Mon Jan 26 20:45:49 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 20:45:49 GMT Subject: RFR: 8376406: Avoid loading ArrayDeque in jdk.internal.loader.NativeLibraries Message-ID: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com> Please review this PR which replaces `ArrayDeque` with `ArrayList` for the native library context stack in `jdk.internal.loader.NativeLibraries.NativeLibraryContext`. With this follow-up to similar changes in #29288 and #29430, a simple JAR-based "hello world" program no longer loads the `ArrayDeque` class during startup. The change here is mostly a straightforward replacement. The existing processing was a FIFO stack, which it still is after this PR, just backed by ArrayList instead. Since ArrayList is null-friendly, I added an explicit `Objects.requireNullNull` before pushing to the stack. Pure refactoring, no tests updated, `noreg-cleanup`. ------------- Commit messages: - Replace ArrayDeque with ArrayList in NativeLibraries.NativeLibraryContext Changes: https://git.openjdk.org/jdk/pull/29432/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376406 Stats: 14 lines in 1 file changed: 3 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29432/head:pull/29432 PR: https://git.openjdk.org/jdk/pull/29432 From sparasa at openjdk.org Mon Jan 26 21:16:10 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Mon, 26 Jan 2026 21:16:10 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d src/hotspot/cpu/x86/x86.ad line 6075: > 6073: operand cmpOpUCF() %{ > 6074: match(Bool); > 6075: predicate((!UseAPX || !VM_Version::supports_avx10_2()) && Is there a reason why the check is not an and like !UseAPX `&&` !VM_Version::supports_avx10_2() ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2729273938 From eirbjo at openjdk.org Mon Jan 26 21:16:41 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 21:16:41 GMT Subject: RFR: 8376406: Avoid loading ArrayDeque in jdk.internal.loader.NativeLibraries [v2] In-Reply-To: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com> References: <2MTsiQD0RsVBX6TxePBIKbc2ZKisC_BRIVNbh72MeJ4=.18bd1814-41c2-4250-9242-72bdcb113cb0@github.com> Message-ID: > Please review this PR which replaces `ArrayDeque` with `ArrayList` for the native library context stack in `jdk.internal.loader.NativeLibraries.NativeLibraryContext`. > > With this follow-up to similar changes in #29288 and #29430, a simple JAR-based "hello world" program no longer loads the `ArrayDeque` class during startup. > > The change here is mostly a straightforward replacement. The existing processing was a FIFO stack, which it still is after this PR, just backed by ArrayList instead. > > Since ArrayList is null-friendly, I added an explicit `Objects.requireNullNull` before pushing to the stack. > > Pure refactoring, no tests updated, `noreg-cleanup`. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Update copyright year ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29432/files - new: https://git.openjdk.org/jdk/pull/29432/files/62aba370..0a12622c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29432&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29432.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29432/head:pull/29432 PR: https://git.openjdk.org/jdk/pull/29432 From rriggs at openjdk.org Mon Jan 26 21:21:29 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Jan 2026 21:21:29 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v5] In-Reply-To: References: Message-ID: <5xgLKc-ZPAbyGkESLU1q-oBEQxJDM39-GDewSWTH3Qc=.ce699522-77ea-4b4b-88d8-76eb51809868@github.com> On Mon, 19 Jan 2026 21:47:26 GMT, Ioi Lam wrote: >> The bug is here on line 121: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 >> >> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 >> >> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. >> >> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > Fixed typo The APINote will trigger need for a CSR. src/java.base/share/classes/java/lang/ProcessBuilder.java line 936: > 934: * If {#code System.out} and/or {#code System.err} have been > 935: * closed in the current process, the corresponding output > 936: * in the subprocess will be discarded. Suggestion: * When the process is {@link #start started}, * if {#code System.out} and/or {#code System.err} have been * closed in the current process, the corresponding output * in the subprocess will be discarded. Qualified to apply at the time the process is started, not when ProcessBuilder.inheritIO is called. ------------- PR Review: https://git.openjdk.org/jdk/pull/29198#pullrequestreview-3708036042 PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2729282389 From eirbjo at openjdk.org Mon Jan 26 21:33:08 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Mon, 26 Jan 2026 21:33:08 GMT Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile [v2] In-Reply-To: References: Message-ID: > Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`. > > With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater. > > No tests updated, strict refactoring, `noreg-cleanup`. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Remove uninitialized local variable ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29430/files - new: https://git.openjdk.org/jdk/pull/29430/files/80bfe60d..a3f06cdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29430/head:pull/29430 PR: https://git.openjdk.org/jdk/pull/29430 From iklam at openjdk.org Mon Jan 26 21:49:52 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 26 Jan 2026 21:49:52 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v6] In-Reply-To: References: Message-ID: > The bug is here on line 121: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 > > If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: > > https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 > > However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. > > The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: @RogerRiggs review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29198/files - new: https://git.openjdk.org/jdk/pull/29198/files/4b7d30c0..6210d8b2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29198&range=04-05 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29198.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29198/head:pull/29198 PR: https://git.openjdk.org/jdk/pull/29198 From missa at openjdk.org Mon Jan 26 21:50:23 2026 From: missa at openjdk.org (Mohamed Issa) Date: Mon, 26 Jan 2026 21:50:23 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:13:10 GMT, Srinivas Vamsi Parasa wrote: >> Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Change function names and extend IR encoding rules for CMove tests >> - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 >> - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 >> - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad >> - Also update copyright year in IREncodingPrinter.java >> - Include apx_f in list of verified CPU features for IR encoding >> - Fix CMove IR tests to account for APX presence >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d > > src/hotspot/cpu/x86/x86.ad line 6075: > >> 6073: operand cmpOpUCF() %{ >> 6074: match(Bool); >> 6075: predicate((!UseAPX || !VM_Version::supports_avx10_2()) && > > Is there a reason why the check is not an and like !UseAPX `&&` !VM_Version::supports_avx10_2() ? We want to cover the cases where a platform has APX but not AVX10.2 and vice versa. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2729386788 From iklam at openjdk.org Mon Jan 26 21:56:56 2026 From: iklam at openjdk.org (Ioi Lam) Date: Mon, 26 Jan 2026 21:56:56 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v5] In-Reply-To: <5xgLKc-ZPAbyGkESLU1q-oBEQxJDM39-GDewSWTH3Qc=.ce699522-77ea-4b4b-88d8-76eb51809868@github.com> References: <5xgLKc-ZPAbyGkESLU1q-oBEQxJDM39-GDewSWTH3Qc=.ce699522-77ea-4b4b-88d8-76eb51809868@github.com> Message-ID: On Mon, 26 Jan 2026 21:15:55 GMT, Roger Riggs wrote: >> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: >> >> Fixed typo > > src/java.base/share/classes/java/lang/ProcessBuilder.java line 936: > >> 934: * If {#code System.out} and/or {#code System.err} have been >> 935: * closed in the current process, the corresponding output >> 936: * in the subprocess will be discarded. > > Suggestion: > > * When the process is {@link #start started}, > * if {#code System.out} and/or {#code System.err} have been > * closed in the current process, the corresponding output > * in the subprocess will be discarded. > > Qualified to apply at the time the process is started, not when ProcessBuilder.inheritIO is called. Thank Roger. I updated the text as you suggested and create the CSR: [JDK-8376413](https://bugs.openjdk.org/browse/JDK-8376413) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2729403602 From rriggs at openjdk.org Mon Jan 26 22:43:13 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Jan 2026 22:43:13 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v6] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 21:49:52 GMT, Ioi Lam wrote: >> The bug is here on line 121: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/classes/java/lang/ProcessImpl.java#L118-L121 >> >> If `System.out` has been closed, `fdAccess.getHandle()` will return -1. This causes `stdHandles[1]` to have the same value as if the child process's stdout was redirected with `Redirect.PIPE`. This will cause a Pipe to be created here for the child process's STDOUT on line 168: >> >> https://github.com/openjdk/jdk/blob/586846b84a38d285c5905437e903cfc57f609410/src/java.base/windows/native/libjava/ProcessImpl_md.c#L158-L184 >> >> However, the caller of the `ProcessBuilder` is not aware of this and will not drain this pipe. This causes the child process to get stuck when writing to its stdout when the pipe 's buffer is filled up. >> >> The fix is to treat the redirection as `Redirect.DISCARD` when `System.out` and/or `System.err` have been closed. > > Ioi Lam has updated the pull request incrementally with one additional commit since the last revision: > > @RogerRiggs review comments Thanks for the updates. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29198#pullrequestreview-3708363428 From rriggs at openjdk.org Mon Jan 26 22:53:52 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Jan 2026 22:53:52 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())` src/java.base/share/classes/java/lang/Character.java line 10012: > 10010: * @since 26 > 10011: */ > 10012: public static int codePointCount(char[] a) { Regardless of the current usage, the parameter name `a` results in a confusing javadoc line. "a the". My preference would be one of `chars`, `seq`, or .... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2729580337 From sviswanathan at openjdk.org Mon Jan 26 23:04:09 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Mon, 26 Jan 2026 23:04:09 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d Looks good to me. ------------- Marked as reviewed by sviswanathan (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/28337#pullrequestreview-3708421027 From roger.riggs at oracle.com Mon Jan 26 23:04:27 2026 From: roger.riggs at oracle.com (Roger Riggs) Date: Mon, 26 Jan 2026 18:04:27 -0500 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> Message-ID: <1096148f-194b-46f6-b142-d5bd75980b82@oracle.com> Hi, String is also an Identity class? and its value could distinguish between the cases. (Both strings can be very short). About java.lang.Object as a lock, the pervasiveness of `new Object()` for locks resulted in giving it special dispensation in as a supertype of value objects. Trying to change its existing uses was determined to be infeasible. Regards, Roger On 1/25/26 11:17 AM, Chen Liang wrote: > Checked this and noted this Lock is used by both lock and shutdownLock > - this makes the Lock class less informative to me. > Maybe we should replace one of the locks with Object, or add a new > class to distinguish these two locks? > > Confidential- Oracle Internal > > ------------------------------------------------------------------------ > *From:* core-libs-dev on behalf of > Eirik Bj?rsn?s > *Sent:* Wednesday, January 21, 2026 12:28 AM > *To:* David Holmes > *Cc:* core-libs-dev at openjdk.org > *Subject:* Re: RFD: Replace class java.lang.Shutdown.Lock with Object? > On Wed, Jan 21, 2026 at 6:38?AM David Holmes > wrote: > > No I suppose not. Though I'm not sure trimming the class will make > any > observable/practical difference in the normal case. > > > Thanks! I agree trimming these two classes (of ~428 loaded at startup) > alone has limited value. But there are other berries?to pick and > the?cumulative impact may have an observable effect on startup. Two > berries feed no one, with a handful we can make a delicious jam :) > > So effectively this is like declaring a single global class that all > "new Object()'s" would be instances of. > > So using new Object() will not be a problem. > > > Thanks for the Valhalla reference, interesting to see how "new > Object()" can be redefined like this. > > Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From rriggs at openjdk.org Mon Jan 26 23:41:25 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Mon, 26 Jan 2026 23:41:25 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v26] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 03:42:47 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: > > from @liach src/java.base/share/classes/java/lang/Integer.java line 496: > 494: } > 495: int len; > 496: if ((len = s.length()) == 0) { `parseInt(s, begiNIndex, endIndex, radix)` already checks for an empty string and calls `NumberformatException.forInputString("", radix)` See Integer:555. src/java.base/share/classes/java/lang/Long.java line 531: > 529: if ((len = s.length()) == 0) { > 530: throw NumberFormatException.forInputString(s); > 531: } Duplicate check for empty string, already checked in Long:583. src/java.base/share/classes/java/lang/NumberFormatException.java line 58: > 56: > 57: /** > 58: * Factory method for making a {@code NumberFormatException} Should document it is for radix = 10. This method doesn't add much value over calling the version with the radix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r2729632002 PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r2729683484 PR Review Comment: https://git.openjdk.org/jdk/pull/22919#discussion_r2729690061 From duke at openjdk.org Mon Jan 26 23:44:34 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Mon, 26 Jan 2026 23:44:34 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v4] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Improve JavaDoc Co-authored-by: Chen Liang ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/0e55e35c..4744ee69 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=02-03 Stats: 23 lines in 5 files changed: 0 ins; 11 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From naoto at openjdk.org Mon Jan 26 23:58:13 2026 From: naoto at openjdk.org (Naoto Sato) Date: Mon, 26 Jan 2026 23:58:13 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:44:34 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 one additional commit since the last revision: > > Improve JavaDoc > > Co-authored-by: Chen Liang src/java.base/share/classes/java/lang/Character.java line 10004: > 10002: /** > 10003: * {@return the number of Unicode code points in the {@code char} array} > 10004: * Unpaired surrogates count as one code point each. It'd be better to replace "surrogates" with "surrogate code units." Applies to other method descriptions too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2729719433 From duke at openjdk.org Mon Jan 26 23:58:14 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Mon, 26 Jan 2026 23:58:14 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:53:06 GMT, Naoto Sato wrote: >> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: >> >> Improve JavaDoc >> >> Co-authored-by: Chen Liang > > src/java.base/share/classes/java/lang/Character.java line 10004: > >> 10002: /** >> 10003: * {@return the number of Unicode code points in the {@code char} array} >> 10004: * Unpaired surrogates count as one code point each. > > It'd be better to replace "surrogates" with "surrogate code units." Applies to other method descriptions too. Agree. I have personally disliked the expression "surrogate" for such code units. We will need another tickets for JavaDoc for the other methods that are not concerned with this ticket. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2729723123 From sparasa at openjdk.org Tue Jan 27 00:51:53 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Tue, 27 Jan 2026 00:51:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d The PR looks good! Thanks, Vamsi ------------- Marked as reviewed by sparasa (Committer). PR Review: https://git.openjdk.org/jdk/pull/28337#pullrequestreview-3708651889 From missa at openjdk.org Tue Jan 27 01:24:19 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 01:24:19 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: <2yOILe6DNi_1xPH0fCwHfN-I3eUQkbRDyP7eMw1vPZE=.9f68c278-ca0a-414b-8965-51b9641db802@github.com> On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d @TobiHartmann, @mhaessig, @eme64, @vnkozlov Please put through validation when available. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3802579626 From john.r.rose at oracle.com Tue Jan 27 01:28:10 2026 From: john.r.rose at oracle.com (John Rose) Date: Mon, 26 Jan 2026 17:28:10 -0800 Subject: RFR: 8374538: Wrong specification of MethodHandles.constant(...) [v2] In-Reply-To: References: <-OYNq7pyz-Wjp71QAuPo1fRIHJayCXUE4f66qa0ln6E=.42c1cd75-d393-43ea-8bd3-b4b30386b348@github.com> Message-ID: My requested change is a clarification, not a semantic change. (Note that I did not request a code change.) I agree with Joe (Mr. CSR) that this does not need a CSR change. On 21 Jan 2026, at 12:13, Chen Liang wrote: > On Wed, 21 Jan 2026 19:25:30 GMT, Hannes Greule wrote: > >>> A simple correction to the javadocs of `MethodHandles.constant(...)`. Please review and let me know what you think. >> >> Hannes Greule has updated the pull request incrementally with one additional commit since the last revision: >> >> update according John's suggestion > > Let's turn the CSR back to draft, edit it, and you can then re-finalize it. > > ------------- > > Marked as reviewed by liach (Reviewer). > > PR Review: https://git.openjdk.org/jdk/pull/29174#pullrequestreview-3689188346 From swen at openjdk.org Tue Jan 27 01:29:02 2026 From: swen at openjdk.org (Shaojin Wen) Date: Tue, 27 Jan 2026 01:29:02 GMT Subject: RFR: 8347009: Speed =?UTF-8?B?4oCL4oCLdXA=?= parseInt and parseLong [v27] 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: from @RogerRiggs ------------- Changes: - all: https://git.openjdk.org/jdk/pull/22919/files - new: https://git.openjdk.org/jdk/pull/22919/files/6c770a89..54a2cbee Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=26 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22919&range=25-26 Stats: 13 lines in 3 files changed: 2 ins; 8 del; 3 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 erfang at openjdk.org Tue Jan 27 02:12:39 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 02:12:39 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:49:20 GMT, Andrew Haley wrote: > > Hi @theRealAph I have addressed all of your comments, thanks for your suggestions. > > > Please add the TypeNNVector JMH test files to this PR. > > > > > > These micro-benchmarks are already in the `panama-vector` project, do we need to sync that file separately into OpenJDK? > > Ideally, yes. It's a bit much to expect a reviewer to check out another repo. Yeah, I agree. VectorAPI is still in the incubator phase, so some code is first merged into the `panama-vector` project and then periodically synced to `OpenJDK`. Therefore, sometimes when the relevant JMH benchmark already exists in `panama-vector`, we don't add duplicates in the PR target to `OpenJDK`, but this makes code review somewhat inconvenient. But I wonder could we use a separate PR for this sync? Otherwise, we might import dozens or even hundreds of files into this PR, which I think would be difficult to review. Perhaps I should ask @PaulSandoz for his opinion on this issue. I?d really appreciate hearing your thoughts on it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3802689436 From jpai at openjdk.org Tue Jan 27 02:32:30 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 27 Jan 2026 02:32:30 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments tier1, tier2 and tier3 testing went fine with this change. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3802734426 From erfang at openjdk.org Tue Jan 27 02:35:50 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 02:35:50 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:14:10 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 12 commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Convert the check condition for vector length into an assertion > > Also refined the tests. > - Refine code comments > - 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 > - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 Hi, could someone help review this PR? Thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3802742570 From darcy at openjdk.org Tue Jan 27 02:40:56 2026 From: darcy at openjdk.org (Joe Darcy) Date: Tue, 27 Jan 2026 02:40:56 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java In-Reply-To: References: Message-ID: <8HF4SrQHgbuBi1Rg62_MZgVReH0Ng0WGs658eY3qdzI=.36cf3106-9a54-472a-ac9c-05361acd8357@github.com> On Fri, 16 Jan 2026 09:22:52 GMT, Anton Artemov wrote: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Reminder to update the copyright years. I'd also like @rgiulietti to review this PR before it goes back. ------------- Marked as reviewed by darcy (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29273#pullrequestreview-3708846251 From duke at openjdk.org Tue Jan 27 03:43:39 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 03:43:39 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 23:55:12 GMT, Tatsunori Uchino wrote: >> src/java.base/share/classes/java/lang/Character.java line 10004: >> >>> 10002: /** >>> 10003: * {@return the number of Unicode code points in the {@code char} array} >>> 10004: * Unpaired surrogates count as one code point each. >> >> It'd be better to replace "surrogates" with "surrogate code units." Applies to other method descriptions too. > > Agree. I have personally disliked the expression "surrogate" for such code units. We will need another tickets for JavaDoc for the other methods that are not concerned with this ticket. [Unicode seems to treat "_isolated_ surrogate code unit" as a first-class citizen.](https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654) https://www.unicode.org/charts/PDF/UDC00.pdf https://www.google.com/search?q=site:unicode.org+%22isolated+surrogate+code%22 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2730108791 From duke at openjdk.org Tue Jan 27 03:49:34 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 03:49:34 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v5] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Rename parameter names from `a` to `seq` `chars` is too confusing with `char` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/4744ee69..6d2805d3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=03-04 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Tue Jan 27 03:49:37 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 03:49:37 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 22:51:26 GMT, Roger Riggs wrote: >> 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())` > > src/java.base/share/classes/java/lang/Character.java line 10012: > >> 10010: * @since 26 >> 10011: */ >> 10012: public static int codePointCount(char[] a) { > > Regardless of the current usage, the parameter name `a` results in a confusing javadoc line. "a the". > My preference would be one of `chars`, `seq`, or .... I found `chars` is too confusing with `char` in JSDoc. I'll chose `seq`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2730114109 From liach at openjdk.org Tue Jan 27 04:28:06 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 04:28:06 GMT Subject: RFR: 8373186: Improve readability of core reflection toString specifications In-Reply-To: References: Message-ID: On Mon, 8 Dec 2025 22:28:19 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 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. I think you can probably refer to the JLS/JVMS difference, noting JVM (classfile) information may be missing from this string output, such as ACC_SYNTHETIC or future ACC_STRICT_INIT. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2730183925 From liach at openjdk.org Tue Jan 27 04:28:03 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 04:28:03 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 352: > 350: * > 351: * The string includes information about access modifiers of the > 352: * field, the type of the field, the type declaring the field, Suggestion: * field, the type of the field, the class or interface declaring the field, We might also note that the access modifiers might not be comprehensive. Since you link "modifiers" below, I wonder if it's better for us to link up here instead, where we can link to more proper getters like accessFlags, getType, getDeclaringClass, getName. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28688#discussion_r2730178443 From eirbjo at gmail.com Tue Jan 27 06:28:02 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 07:28:02 +0100 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: <1096148f-194b-46f6-b142-d5bd75980b82@oracle.com> References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> <1096148f-194b-46f6-b142-d5bd75980b82@oracle.com> Message-ID: On Tue, Jan 27, 2026 at 12:05?AM Roger Riggs wrote: > Hi, > > String is also an Identity class and its value could distinguish between > the cases. (Both strings can be very short). > > About java.lang.Object as a lock, the pervasiveness of `new Object()` for > locks resulted in giving it special dispensation in as a supertype of value > objects. Trying to change its existing uses was determined to be infeasible. > Great minds are pulling this thread in interesting directions, which is fine! I may go ahead file a PR to focus on the specific small changes initially suggested. Then any broader discussions can continue here. Was there ever any thoughts to add an API point for defining new montor objects, such as Object.newLock() or perhaps even something like Object.newLock(Class context, String tag)? Perhaps this could: a) Make the semantics/purpose of creating a new object more clear b) Allow the JVM to return any object it wants c) Allow monitor objects to be more informative Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From epeter at openjdk.org Tue Jan 27 08:00:06 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:00:06 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: References: Message-ID: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> On Fri, 23 Jan 2026 23:04:43 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: > > - Merge branch 'master' into user/missa-prime/avx10_2 > - Merge branch 'master' into user/missa-prime/avx10_2 > - Change function names and extend IR encoding rules for CMove tests > - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 > - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 > - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad > - Also update copyright year in IREncodingPrinter.java > - Include apx_f in list of verified CPU features for IR encoding > - Fix CMove IR tests to account for APX presence > - Merge branch 'master' into user/missa-prime/avx10_2 > - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 65: > 63: applyIfPlatform = {"x64", "true"}, > 64: applyIfCPUFeatureAnd = {"apx_f", "true", "avx10_2", "true"}, > 65: phase = CompilePhase.FINAL_CODE) These are all `CMove` cases. I see you added branch/call cases in the benchmark. Would it make sense to have some similar cases here? And: this here is a test for `float`. Where do we cover `double`, which you are also making VM changes for? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2730715729 From alanb at openjdk.org Tue Jan 27 08:05:07 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Jan 2026 08:05:07 GMT Subject: RFR: 8366736: Closed System.out causes child process to hang on Windows [v5] In-Reply-To: References: <5xgLKc-ZPAbyGkESLU1q-oBEQxJDM39-GDewSWTH3Qc=.ce699522-77ea-4b4b-88d8-76eb51809868@github.com> Message-ID: On Mon, 26 Jan 2026 21:53:59 GMT, Ioi Lam wrote: >> src/java.base/share/classes/java/lang/ProcessBuilder.java line 936: >> >>> 934: * If {#code System.out} and/or {#code System.err} have been >>> 935: * closed in the current process, the corresponding output >>> 936: * in the subprocess will be discarded. >> >> Suggestion: >> >> * When the process is {@link #start started}, >> * if {#code System.out} and/or {#code System.err} have been >> * closed in the current process, the corresponding output >> * in the subprocess will be discarded. >> >> Qualified to apply at the time the process is started, not when ProcessBuilder.inheritIO is called. > > Thank Roger. I updated the text as you suggested and create the CSR: [JDK-8376413](https://bugs.openjdk.org/browse/JDK-8376413) API notes provide "commentary, rationale, or examples pertaining to the API". They don't strictly require a CSR as they aren't spec. I think the proposed note is closer to an implNote as it is documenting what the JDK implementation does if the out/error streams are closed. We could potentially consider promoting it to spec, requiring all implementations to discard in this case, maybe you've discussed this already? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29198#discussion_r2730733839 From jbhateja at openjdk.org Tue Jan 27 08:11:29 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 08:11:29 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> References: <8hStIcvp252Ik7raxZL5BvFKKkXTflorjyOD9Cyakvc=.c5d1b302-5c49-46b1-91ba-2feda2e6a746@github.com> <1ElN5XvEXAYGINpCIB2smhDrzekGyiXmG6o8-jnxDxk=.83a69a64-2894-40af-a2ee-9c35448c88b2@github.com> <-cin72VWnqAukd5JbCMV9BfsGR1tWcWh_aGpdrlhHlM=.2d22e5da-35d2-4ffc-8ce5-86c90d662fd7@github.com> Message-ID: <5a11-TYC046h3ro4YgCI4oSBFfyjUWlWA2I3pOMTF-k=.bfff183a-d825-45ba-bc75-d515337119be@github.com> On Fri, 23 Jan 2026 04:57:04 GMT, Jatin Bhateja wrote: >> Hi @eme64 , Your comments have been addressed > >> @jatin-bhateja This patch is really really large. There are lots of renamings that could be done in a separate patch first (as a subtask). It would make reviewing easier, allowing focus on the substantial work. See discussion here: [#28002 (comment)](https://github.com/openjdk/jdk/pull/28002#discussion_r2705376899) > > Hi @eme64 , > > I have done some cleanups, following is the summary of changes included with the patch:- > > ``` > 1 Changes to introduce a new (custom) basictype T_FLOAT16 > - Global Definition. > - Skip over handling where ever applicable. > 2 Changes to pass laneType (BasicType) to intrinsific entry point instead of element classes. > - Inline expander interface changes mainly. > 3 Changes in abstract and concrete vector class generation templates. > 4 Changing the nomenclature of Vector classes to avoid Float1664... sort of names... > 5 Changes in the LaneType to add a new carrier type field. > 6 Changes in inline expanders to selectivelty enable intrinsification for opration for which we have > auto-vectorization and backend support in place.. > 7 Changes in test generation templates. > b. Assert wrappers to conver float16 (short) value to float before invoking testng Asserts. > c. Scalar operation wrappers to selectivelty invoke Float16 math routine which are not > part of Java SE math libraries. > > 8 New IR verification test. > 9 New Micro-benchmark. > 10 AARCH64 test failure - patch + test fixed by Bhavana Kilambi. > > > Out of above change 7b consumes 40000+ LOC. > > Q. Why do we need wrapper assertions ? > A. To handle all possible NaN representations of SNaN and QNaN, since float16 uses short carrier type hence we need to promote them float values before invoking TestNG assertions. This conversion is accomplished by assertion wrappers > > All the tasks are related and most of source/test are generated using scripts we should not go by the size of patch and review the templates files. > @jatin-bhateja I was wondering: what prompted the decision to add a new `BasicType` for `Float16`? Would each additional numeric type get a new `BasicType`? How many do we anticipate? > > Currently, we are using `T_SHORT` for `Float16`, right? Hi @eme64 , Currently in JDK mainline we pass element class as the lane type, problem with passing Float16.class is that its part of incubating module an we cannot declare a symbol for it in vmSymbols, thus if we pass Float16.class as element type we will need to do a fragile name based checks over element type to infer Float16 operation in inline expanders. To circumvent this problem started passing additional integer argument vector operation type (VECTOR_TYPE_FP16 / VECTOR_TYPE_PRIM) to intrinsic entry point. Paul suggested in his [prior comment](https://github.com/openjdk/jdk/pull/28002#issuecomment-3529452461) to add a new basicType for Float16 and instead of passing element class and vector operation type pass just the basicType since its already used in the LaneType. [Enum definitions of all the primitive basic types used in LaneType ](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java*L153__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe1bY_kYW$) are as per JVM specification and in synchronism with [BasicType definition in VM side](https://urldefense.com/v3/__https://github.com/openjdk/jdk/blob/master/src/hotspot/share/utilities/globalDefinitions.hpp*L671__;Iw!!ACWV5N9M2RV99hQ!J4ZZ1lwCxaG8mXxtjHB9uET0tlcqBdgJwsC3pCLt4WeUQYULtKPtxo_2NIJw67AYBe6k9ffftGh_EttPe6e5uGFc$). VM also defines some custom basic types like T_METADATA, T_NARROWKLASS. If we just create new basic type on Java side, then there is a chance that its value may conflict with existing custom basic types in VM side. One solution is to maintain the synchronization b/w basic type assignment for primitive type only and not modify any VM side code since current scope of T_FLOAT16 is only limited to intrinsic entry point. Adding a new custom BasicType on VM side is not just a change in one place and is cumbersome and not desirable given that its used all across VM code. Thus there are following options :- 1/ Create new basicType T_FLOAT16 in Java side, add it to LaneType and pass only basic types as element type to intrinsic entry point and maintain an efficient interface 2/ Pass Float16.class as element type to Float16Vector operations and do a fragile and inefficient name base lookup in inline expander to infer Float16 vector IR. 3/ Extend both BasicType definition on Java side and VM side and keep them in synchronism but this is not desirable given that VM makes extensive use of BasicType. 4/ Pass short.class as element type and pass another argument vector operation kind to intrinsic entry point to differentiate b/w ShortVector and Float16Vector operations. 5/ Paul's suggestion to create proxy class in java.base module for Float16 type. I am inclined to go with solution 1, let me know if you have other solutions. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3803701515 From epeter at openjdk.org Tue Jan 27 08:13:40 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:13:40 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:14:10 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 12 commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Convert the check condition for vector length into an assertion > > Also refined the tests. > - Refine code comments > - 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 > - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 src/hotspot/share/opto/vectornode.cpp line 1063: > 1061: return n; > 1062: } > 1063: This has a clear parallel in `Node::uncast`. But there, we may recursively uncast. Your pattern: `(VectorStoreMask (VectorMaskCast* (VectorLoadMask x))) => (x)` We could also have a chain of casts here. Can you explain why you chose only to do a single step here? test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 121: > 119: VectorMask mInt128 = mFloat128.cast(IntVector.SPECIES_128); > 120: return mInt128.not().trueCount(); > 121: } Why can't the casts be eliminated here? Can you please add a comment to the test? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730746738 PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730754926 From epeter at openjdk.org Tue Jan 27 08:13:42 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:13:42 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:09:47 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 12 commits: >> >> - Update copyright year to 2026 >> - Merge branch 'master' into JDK-8370863-mask-cast-opt >> - Convert the check condition for vector length into an assertion >> >> Also refined the tests. >> - Refine code comments >> - 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 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 > > test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 121: > >> 119: VectorMask mInt128 = mFloat128.cast(IntVector.SPECIES_128); >> 120: return mInt128.not().trueCount(); >> 121: } > > Why can't the casts be eliminated here? Can you please add a comment to the test? There used to be a comment, would that one still be accurate? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730756241 From erfang at openjdk.org Tue Jan 27 08:50:26 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 08:50:26 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Mon, 5 Jan 2026 08:14:10 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 12 commits: > > - Update copyright year to 2026 > - Merge branch 'master' into JDK-8370863-mask-cast-opt > - Convert the check condition for vector length into an assertion > > Also refined the tests. > - Refine code comments > - 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 > - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 Thanks for your review ! @eme64 ------------- PR Review: https://git.openjdk.org/jdk/pull/28313#pullrequestreview-3709848369 From erfang at openjdk.org Tue Jan 27 08:50:28 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 08:50:28 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:07:10 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 12 commits: >> >> - Update copyright year to 2026 >> - Merge branch 'master' into JDK-8370863-mask-cast-opt >> - Convert the check condition for vector length into an assertion >> >> Also refined the tests. >> - Refine code comments >> - 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 >> - ... and 2 more: https://git.openjdk.org/jdk/compare/6eaabed5...9c38a6d9 > > src/hotspot/share/opto/vectornode.cpp line 1063: > >> 1061: return n; >> 1062: } >> 1063: > > This has a clear parallel in `Node::uncast`. But there, we may recursively uncast. > > Your pattern: > `(VectorStoreMask (VectorMaskCast* (VectorLoadMask x))) => (x)` > > We could also have a chain of casts here. > Can you explain why you chose only to do a single step here? I'm not sure I fully understood your point. This function can recursively uncast a chain of consecutive `VectorMaskCastNode`, so the pattern you mentioned above can be optimized to `(x)` even when there are multiple `VectorMaskCastNode` in between. I?m not sure I get what you mean. Could you elaborate on it a bit? Thanks~ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730885339 From erfang at openjdk.org Tue Jan 27 08:50:30 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 08:50:30 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:10:14 GMT, Emanuel Peter wrote: >> test/hotspot/jtreg/compiler/vectorapi/VectorMaskCastIdentityTest.java line 121: >> >>> 119: VectorMask mInt128 = mFloat128.cast(IntVector.SPECIES_128); >>> 120: return mInt128.not().trueCount(); >>> 121: } >> >> Why can't the casts be eliminated here? Can you please add a comment to the test? > > There used to be a comment, would that one still be accurate? Yeah, the comment is still there, see line 92 of this file. I refactored this file a bit, now it looks like this: // comment for testXXXCastToSameType testOneCastToSameType() testTwoCastToSameType() // comment for testXXXCastToDifferentType testOneCastToDifferentType() testTwoCastToDifferentType() ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730907001 From epeter at openjdk.org Tue Jan 27 08:58:26 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:58:26 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:46:53 GMT, Eric Fang wrote: >> There used to be a comment, would that one still be accurate? > > Yeah, the comment is still there, see line 92 of this file. I refactored this file a bit, now it looks like this: > > // comment for testXXXCastToSameType > testOneCastToSameType() > testTwoCastToSameType() > > // comment for testXXXCastToDifferentType > testOneCastToDifferentType() > testTwoCastToDifferentType() Honestly, I prefer having comments next to the IR rule. If the IR rule fails, you instantly understand the assumptions with the comment. The IR rule could fail because: but or additional enhancements. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730945272 From erfang at openjdk.org Tue Jan 27 09:01:30 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 09:01:30 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:55:48 GMT, Emanuel Peter wrote: >> Yeah, the comment is still there, see line 92 of this file. I refactored this file a bit, now it looks like this: >> >> // comment for testXXXCastToSameType >> testOneCastToSameType() >> testTwoCastToSameType() >> >> // comment for testXXXCastToDifferentType >> testOneCastToDifferentType() >> testTwoCastToDifferentType() > > Honestly, I prefer having comments next to the IR rule. > If the IR rule fails, you instantly understand the assumptions with the comment. > The IR rule could fail because: but or additional enhancements. Make sense, I'll add a comment for each test, thanks! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730957043 From epeter at openjdk.org Tue Jan 27 08:58:25 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Tue, 27 Jan 2026 08:58:25 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:42:14 GMT, Eric Fang wrote: >> src/hotspot/share/opto/vectornode.cpp line 1063: >> >>> 1061: return n; >>> 1062: } >>> 1063: >> >> This has a clear parallel in `Node::uncast`. But there, we may recursively uncast. >> >> Your pattern: >> `(VectorStoreMask (VectorMaskCast* (VectorLoadMask x))) => (x)` >> >> We could also have a chain of casts here. >> Can you explain why you chose only to do a single step here? > > I'm not sure I fully understood your point. This function can recursively uncast a chain of consecutive `VectorMaskCastNode`, so the pattern you mentioned above can be optimized to `(x)` even when there are multiple `VectorMaskCastNode` in between. > > I?m not sure I get what you mean. Could you elaborate on it a bit? Thanks~ Woops, my bad. I read `if` instead of `while`. Sorry, you are right! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730938160 From erfang at openjdk.org Tue Jan 27 09:05:43 2026 From: erfang at openjdk.org (Eric Fang) Date: Tue, 27 Jan 2026 09:05:43 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v8] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 08:54:04 GMT, Emanuel Peter wrote: >> I'm not sure I fully understood your point. This function can recursively uncast a chain of consecutive `VectorMaskCastNode`, so the pattern you mentioned above can be optimized to `(x)` even when there are multiple `VectorMaskCastNode` in between. >> >> I?m not sure I get what you mean. Could you elaborate on it a bit? Thanks~ > > Woops, my bad. I read `if` instead of `while`. Sorry, you are right! No problem, now I understand that this function behaves as we expect. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28313#discussion_r2730972580 From aartemov at openjdk.org Tue Jan 27 09:06:39 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 27 Jan 2026 09:06:39 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v2] In-Reply-To: References: Message-ID: <_gLAOP_YgiP136GtjmeRtOY2qGkLacw7vVoNJIKa_cU=.2ac9ed17-308d-4e67-a784-1698b5f4ef6a@github.com> > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29273/files - new: https://git.openjdk.org/jdk/pull/29273/files/24a7b7ca..d6ed1b89 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=00-01 Stats: 14 lines in 6 files changed: 0 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From aartemov at openjdk.org Tue Jan 27 09:06:47 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 27 Jan 2026 09:06:47 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 20:36:09 GMT, Andrey Turbanov wrote: >> Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: >> >> 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. > > src/java.base/share/classes/java/lang/FdLibm.java line 3544: > >> 3542: hx = __HI(x); >> 3543: ix = hx & 0x7fffffff; >> 3544: if(ix >= 0x7ff00000) { > > Suggestion: > > if (ix >= 0x7ff00000) { Addressed. > src/java.base/share/classes/java/lang/FdLibm.java line 3548: > >> 3546: } >> 3547: if(ix < 0x3e300000) { // |x| < 2**-28 >> 3548: if(huge + x > 1.0) { > > Suggestion: > > if (ix < 0x3e300000) { // |x| < 2**-28 > if (huge + x > 1.0) { Addressed. > src/java.base/share/classes/java/lang/FdLibm.java line 3552: > >> 3550: } >> 3551: } >> 3552: if(ix > 0x41b00000) { // |x| > 2**28 > > Suggestion: > > if (ix > 0x41b00000) { // |x| > 2**28 Addressed. > test/jdk/java/lang/Math/HyperbolicTests.java line 1535: > >> 1533: >> 1534: >> 1535: for(int i = 0; i < testCases.length; i++) { > > Suggestion: > > for (int i = 0; i < testCases.length; i++) { Addressed. > test/jdk/java/lang/Math/HyperbolicTests.java line 1544: > >> 1542: >> 1543: >> 1544: for(double nan : Tests.NaNs) { > > Suggestion: > > for (double nan : Tests.NaNs) { Addressed. > test/jdk/java/lang/Math/HyperbolicTests.java line 1559: > >> 1557: >> 1558: >> 1559: for(int i = 0; i < specialTestCases.length; i++) { > > Suggestion: > > for (int i = 0; i < specialTestCases.length; i++) { Addressed. > test/jdk/java/lang/Math/HyperbolicTests.java line 1572: > >> 1570: // double significand. >> 1571: >> 1572: for(int i = DoubleConsts.MIN_SUB_EXPONENT; i < -27; i++) { > > Suggestion: > > for (int i = DoubleConsts.MIN_SUB_EXPONENT; i < -27; i++) { Addressed. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730972734 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730972447 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730972291 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730973712 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730973465 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730973218 PR Review Comment: https://git.openjdk.org/jdk/pull/29273#discussion_r2730972916 From hannesw at openjdk.org Tue Jan 27 09:17:38 2026 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 27 Jan 2026 09:17:38 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 18:07:28 GMT, Chen Liang wrote: >> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: >> >> >> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions >> >> >> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. >> >> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. >> >> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Remove redundant dot The change looks technically good. I have some questions regarding formatting of link labels which I have commented inline. make/jdk/src/classes/build/tools/taglet/JSpec.java line 198: > 196: // Change whole text to "?chapter.x" in inline tags. > 197: literal = sectionSign + chapter + section; > 198: } What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)? For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript PREVIEW tag like we use in API references. ------------- PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3709994788 PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2730997254 From aartemov at openjdk.org Tue Jan 27 09:17:57 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Tue, 27 Jan 2026 09:17:57 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v3] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8375285: Added versions. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29273/files - new: https://git.openjdk.org/jdk/pull/29273/files/d6ed1b89..ed1d4d3c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=01-02 Stats: 2 lines in 2 files changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From eirbjo at openjdk.org Tue Jan 27 09:30:19 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 09:30:19 GMT Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile [v3] In-Reply-To: References: Message-ID: > Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`. > > With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater. > > No tests updated, strict refactoring, `noreg-cleanup`. Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: Remove null check of final field istreams which is never null ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29430/files - new: https://git.openjdk.org/jdk/pull/29430/files/a3f06cdc..388306a7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29430&range=01-02 Stats: 13 lines in 1 file changed: 1 ins; 2 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29430.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29430/head:pull/29430 PR: https://git.openjdk.org/jdk/pull/29430 From chagedorn at openjdk.org Tue Jan 27 09:33:02 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 27 Jan 2026 09:33:02 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci wrote: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Overall, the fix idea with `Opaque` nodes looks good to me! src/hotspot/share/opto/library_call.hpp line 161: > 159: Node* generate_negative_guard(Node* index, RegionNode* region, > 160: // resulting CastII of index: > 161: Node* *pos_index = nullptr, Suggestion: Node** pos_index = nullptr, ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3710064929 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731064422 From chagedorn at openjdk.org Tue Jan 27 09:33:03 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Tue, 27 Jan 2026 09:33:03 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 20 Jan 2026 09:06:27 GMT, Volkan Yazici wrote: >> It is true that they do pretty much the same thing ("avoid" C2 optimisations for checks) but I'd argue they are semantically slightly different: one prevents optimisations where we know the value cannot be null, the other where we know the value is in range. We could actually have only one class (e.g. with a `positive` flag like before) but I'm not sure it would be a cleaner/nicer solution. ? > > Fair enough ? I was just curious. I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2731057975 From eirbjo at openjdk.org Tue Jan 27 09:34:10 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 09:34:10 GMT Subject: RFR: 8376403: Avoid loading ArrayDeque in java.util.zip.ZipFile [v3] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 09:30:19 GMT, Eirik Bj?rsn?s wrote: >> Hot on the heals of #29288, this PR replaces `ArrayDeque` with `ArrayList` for the Inflater cache implementation in `ZipFile.CleanableResource`. >> >> With this PR, we change the order of the cache from a LIFO queue to a FIFO stack backed by ArrayList. The order seems unimportant, and has indeed been FIFO in the past when using `java.util.Vector`. Intuitively, it should be better to return the most recently used Inflater. >> >> No tests updated, strict refactoring, `noreg-cleanup`. > > Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision: > > Remove null check of final field istreams which is never null src/java.base/share/classes/java/util/zip/ZipFile.java line 764: > 762: > 763: // Close streams, release their inflaters > 764: if (istreams != null) { Small additional fix to remove unnecessary null check of the final, definitely assigned field `istreams`. Unrelated to issue at hand, included here since it is close code and to avoid the PR churn for such a trivial cleanup if fixed separately. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29430#discussion_r2731082663 From duke at openjdk.org Tue Jan 27 09:54:50 2026 From: duke at openjdk.org (Harshit470250) Date: Tue, 27 Jan 2026 09:54:50 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v5] In-Reply-To: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> References: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> Message-ID: On Fri, 23 Jan 2026 10:51:18 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) > > Varada M has updated the pull request incrementally with two additional commits since the last revision: > > - 8371187: [BigEndian Platforms] Vector lane reversal error > - 8371187: [BigEndian Platforms] Vector lane reversal error I have run the tests on s390. They passed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3804189419 From mdoerr at openjdk.org Tue Jan 27 09:54:51 2026 From: mdoerr at openjdk.org (Martin Doerr) Date: Tue, 27 Jan 2026 09:54:51 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v5] In-Reply-To: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> References: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> Message-ID: On Fri, 23 Jan 2026 10:51:18 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) > > Varada M has updated the pull request incrementally with two additional commits since the last revision: > > - 8371187: [BigEndian Platforms] Vector lane reversal error > - 8371187: [BigEndian Platforms] Vector lane reversal error Tests have passed on our side as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3804197003 From jpai at openjdk.org Tue Jan 27 10:03:20 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 27 Jan 2026 10:03:20 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3710225717 From varadam at openjdk.org Tue Jan 27 10:04:25 2026 From: varadam at openjdk.org (Varada M) Date: Tue, 27 Jan 2026 10:04:25 GMT Subject: RFR: 8371187: [BigEndian Platforms] Vector lane reversal error [v5] In-Reply-To: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> References: <61m6W7G30qJ9m3Hswa06ZJODwcxBD_-i__csHf-BMQU=.135843e1-25c7-487b-b1d8-c059c18ddfc6@github.com> Message-ID: On Fri, 23 Jan 2026 10:51:18 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) > > Varada M has updated the pull request incrementally with two additional commits since the last revision: > > - 8371187: [BigEndian Platforms] Vector lane reversal error > - 8371187: [BigEndian Platforms] Vector lane reversal error Thank you Martin, Harshit and Amit! ------------- PR Comment: https://git.openjdk.org/jdk/pull/28425#issuecomment-3804230258 From varadam at openjdk.org Tue Jan 27 10:04:27 2026 From: varadam at openjdk.org (Varada M) Date: Tue, 27 Jan 2026 10:04:27 GMT Subject: Integrated: 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) This pull request has now been integrated. Changeset: ee2deade Author: Varada M URL: https://git.openjdk.org/jdk/commit/ee2deaded82e5fbd94aff7dd22cf2d5c57caa94e Stats: 109 lines in 7 files changed: 108 ins; 0 del; 1 mod 8371187: [BigEndian Platforms] Vector lane reversal error Reviewed-by: mdoerr, amitkumar ------------- PR: https://git.openjdk.org/jdk/pull/28425 From eirbjo at openjdk.org Tue Jan 27 10:13:57 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:13:57 GMT Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue Message-ID: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes. Additionally, this PR marks the lock objects in `Shutdown` as `final` This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html. Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`. ------------- Commit messages: - Avoid loading custom empty Lock classes Changes: https://git.openjdk.org/jdk/pull/29442/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29442&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376477 Stats: 7 lines in 2 files changed: 0 ins; 2 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/29442.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29442/head:pull/29442 PR: https://git.openjdk.org/jdk/pull/29442 From aph at openjdk.org Tue Jan 27 10:16:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Tue, 27 Jan 2026 10:16:04 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v3] In-Reply-To: References: Message-ID: <0KaSJxnKpyK1_1JvW3V4uAJ0rLJCs7KZBN1EN-ZtyEc=.c4374870-b25b-4d72-a887-5cfe3d770949@github.com> On Tue, 27 Jan 2026 02:10:03 GMT, Eric Fang wrote: > But I wonder could we use a separate PR for this sync? Otherwise, we might import dozens or even hundreds of files into this PR, which I think would be difficult to review. Why? A commit into mainline should be accompanied by its tests. That's a base, (and IMO obvious) requirement. Perhaps I should ask @PaulSandoz for his opinion on this issue. I?d really appreciate hearing your thoughts on it. I can think of no reason not to grab all of them, but that must happen first. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3804295417 From eirbjo at openjdk.org Tue Jan 27 10:28:23 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:28:23 GMT Subject: RFR: 8376271: ZipFile comment confusingly refers to "native" ZIP file implementation In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 10:57:52 GMT, Eirik Bj?rsn?s wrote: > Please review this comment-only PR which updates a field comment referring to `ZipFile.Source` as "native". > > ZipFile has not used a native implementation since Java 8, so this comment may be confusing. > > The comment seems to have been introduced in 2017 as part of JDK-8185582 when ZipFile was updated to use Cleaners instead of finalizers. (The use of quotation marks in "native" may have meant to indicate that this is "not really native", but I still find it confusing). > > While visiting this comment, I also made an attempt to make the leading sentence of this field comment less mysterious. > > Comment only, trivial, low risk: `noreg-trivial` Thanks for reviewing this code comment improvement! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29401#issuecomment-3804347459 From eirbjo at openjdk.org Tue Jan 27 10:29:49 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:29:49 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments Thanks for all the helpful review feedback here, I think this shaped up really nicely! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3804353999 From eirbjo at openjdk.org Tue Jan 27 10:30:00 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:30:00 GMT Subject: RFR: 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:23:16 GMT, Eirik Bj?rsn?s wrote: > Please review this small enhancement which makes `ZipFile.Source.Key` capture the relevant `BasicFileAttributes` fields eagerly in its constructor instead of calling into `BasicFileAttributes` for each `hashCode` or `equals` invocation. > > This reduces the memory footprint of `Key` instances. It should be performance positive since we avoid creating `FileTime` instances once per comparison and avoid synchronization getting the file key. > > Capturing fields early also improves readability by making it obvious from the field declarations what information Key uses when comparing equality. > > Pure refactoring, no tests updated, `noreg-trivial`. Thanks for reviewing this small cleanup! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29411#issuecomment-3804343244 From eirbjo at openjdk.org Tue Jan 27 10:30:01 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:30:01 GMT Subject: Integrated: 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 10:23:16 GMT, Eirik Bj?rsn?s wrote: > Please review this small enhancement which makes `ZipFile.Source.Key` capture the relevant `BasicFileAttributes` fields eagerly in its constructor instead of calling into `BasicFileAttributes` for each `hashCode` or `equals` invocation. > > This reduces the memory footprint of `Key` instances. It should be performance positive since we avoid creating `FileTime` instances once per comparison and avoid synchronization getting the file key. > > Capturing fields early also improves readability by making it obvious from the field declarations what information Key uses when comparing equality. > > Pure refactoring, no tests updated, `noreg-trivial`. This pull request has now been integrated. Changeset: e0445c09 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/e0445c09f7a967843a56634f72c7545446791e15 Stats: 15 lines in 1 file changed: 5 ins; 2 del; 8 mod 8376294: ZipFile.Source.Key should not hold on to its BasicFileAttributes instance Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29411 From eirbjo at openjdk.org Tue Jan 27 10:32:07 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:32:07 GMT Subject: Integrated: 8376271: ZipFile comment confusingly refers to "native" ZIP file implementation In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 10:57:52 GMT, Eirik Bj?rsn?s wrote: > Please review this comment-only PR which updates a field comment referring to `ZipFile.Source` as "native". > > ZipFile has not used a native implementation since Java 8, so this comment may be confusing. > > The comment seems to have been introduced in 2017 as part of JDK-8185582 when ZipFile was updated to use Cleaners instead of finalizers. (The use of quotation marks in "native" may have meant to indicate that this is "not really native", but I still find it confusing). > > While visiting this comment, I also made an attempt to make the leading sentence of this field comment less mysterious. > > Comment only, trivial, low risk: `noreg-trivial` This pull request has now been integrated. Changeset: 4ff5f3a8 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/4ff5f3a8c0910e9ed9d77586bd692c469bdf3460 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod 8376271: ZipFile comment confusingly refers to "native" ZIP file implementation Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29401 From eirbjo at openjdk.org Tue Jan 27 10:58:55 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:58:55 GMT Subject: RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in java.util.zip.ZipCoder Message-ID: Please review this class which removes a dependency on `java.nio.charset.StandardCharsets` introduced in [JDK-8365703](https://bugs.openjdk.org/browse/JDK-8365703). We can use `UTF_8.INSTANCE` here as elsewhere in this class to prevent startup regression loading otherwise unused classes and charsets. Verified that running `java -cp hello.jar Hello" observes the following diff in loaded classes when run with this PR: < java.nio.charset.StandardCharsets < sun.nio.cs.US_ASCII < sun.nio.cs.ISO_8859_1 < sun.nio.cs.UTF_16BE < sun.nio.cs.UTF_16LE < sun.nio.cs.UTF_16 < sun.nio.cs.UTF_32BE < sun.nio.cs.UTF_32LE < sun.nio.cs.UTF_32 This is a strict refactoring, no tests updated, `noreg-trivial`. ------------- Commit messages: - Avoid loading java.nio.charset.StandardCharsets Changes: https://git.openjdk.org/jdk/pull/29443/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29443&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376483 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29443.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29443/head:pull/29443 PR: https://git.openjdk.org/jdk/pull/29443 From eirbjo at openjdk.org Tue Jan 27 10:59:35 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 10:59:35 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Wed, 21 Jan 2026 09:26:31 GMT, Claes Redestad wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > FWIW `ArrayDeque` is likely to be loaded early regardless of these changes. I ran this through some of our startup tests and noticed that in the typical case we're net neutral and are just shifting the point of load from URLClassPath to ZipFile.CleanableResource. You might see a reduction on tests that load and run only classes which are not packed into jar files. > > Still, I think it's useful to reduce the complexity of the class load graph in the earliest loaded classes. Any step in that direction removes trip-wires and hazards for the primordial setup. Since this PR was marked to require two reviewers, then three for an area expert, we are now in the situation where it seems we need @cl4es and @liach to re-review before we can integrate. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3804497181 From duke at openjdk.org Tue Jan 27 11:01:29 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 11:01:29 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v6] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Remove `Character.codePointCount` overload ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/6d2805d3..9af51fc7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=04-05 Stats: 22 lines in 1 file changed: 0 ins; 22 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Tue Jan 27 11:04:49 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 11:04:49 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v6] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 11:01:29 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 one additional commit since the last revision: > > Remove `Character.codePointCount` overload Do I need to merge master? It looks like the CI is failing for reasons unrelated to this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3804516489 From cstein at openjdk.org Tue Jan 27 11:22:50 2026 From: cstein at openjdk.org (Christian Stein) Date: Tue, 27 Jan 2026 11:22:50 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> Message-ID: On Mon, 26 Jan 2026 18:13:46 GMT, Jorn Vernee wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 105: > >> 103: this.zis = zis; >> 104: checkModuleDescriptor(MODULE_INFO); >> 105: checkAutomaticModuleName(); > > The separate method is much better. I don't think doing this in the constructor is great though. I suggest moving this, and the existing call to `checkModuleDescriptor` to the `validate` method, then the constructor is for instantiation only, and the validate method handles the validate logic. (but, that's more of a personal preference) I agree, yet the existing `checkModuleDescriptor(MODULE_INFO);` method initializes the `this.md` field as a side-effect, maybe even more fields. I'd like to defer such cleanup work to a dedicated overhaul of the `jar` tool, or at least a refactoring of the `--validate` operation mode. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2731524384 From duke at openjdk.org Tue Jan 27 11:33:21 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 11:33:21 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v7] In-Reply-To: References: Message-ID: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> > 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 one additional commit since the last revision: Replace "unpaired surrogates" with "isolated surrogate code units" https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 https://www.unicode.org/charts/PDF/UDC00.pdf ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/9af51fc7..471b4308 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=05-06 Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From cstein at openjdk.org Tue Jan 27 11:49:53 2026 From: cstein at openjdk.org (Christian Stein) Date: Tue, 27 Jan 2026 11:49:53 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> Message-ID: <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> On Mon, 26 Jan 2026 18:22:32 GMT, Jorn Vernee wrote: >> Christian Stein has updated the pull request incrementally with one additional commit since the last revision: >> >> Address review comments > > src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 480: > >> 478: errorAndInvalid(formatMsg("error.validator.manifest.invalid.automatic.module.name", automaticModuleName)); >> 479: } >> 480: if (md == null || automaticModuleName.equals(md.name())) { > > Realizing this now, but this is only checking the top-level `module-info.class`, not any of the ones under the `META-INF/versions` directories. e.g. `checkModuleDescriptor` is also being called for each versioned `module-info.class` file. Is that something that we should also be doing for this check? The `this.md` field is initialized (by `checkModuleDescriptor(MODULE_INFO);` from within the constructor) to the "base" compiled module descriptor. It also includes this comment: > ``` > // Initialize the base md if it's not yet. A "base" md can be either the > // root module-info.class or the first versioned module-info.class > ``` With that in place, and the consistency checks being performed in `checkModuleDescriptor(MODULE_INFO);`, we are good. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2731623055 From vklang at openjdk.org Tue Jan 27 12:03:31 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 Jan 2026 12:03:31 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v29] In-Reply-To: References: <0Lisdx1YuiXvfK-tHgB26LfF7VkxHjDTpO6cCMVHh3s=.0997d394-c705-433b-9897-bc5914dc7718@github.com> Message-ID: <8vZ1NCkKVcFCB5ZxOQRFAwXe8mxCn7qHIa0xIZ1116M=.de94736d-ab8a-4c41-9e71-98da5fee096d@github.com> On Sun, 25 Jan 2026 20:09:13 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: > > Don't oversignal LIFO I ran some experiments trying to relax some reads to WorkQueue.source but it does indeed seem like they are required to be at least non-plain reads. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28797#issuecomment-3804809370 From zjx001202 at gmail.com Tue Jan 27 12:05:48 2026 From: zjx001202 at gmail.com (Glavo) Date: Tue, 27 Jan 2026 20:05:48 +0800 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> <1096148f-194b-46f6-b142-d5bd75980b82@oracle.com> Message-ID: > Was there ever any thoughts to add an API point for defining new montor objects, such as Object.newLock() or perhaps even something like Object.newLock(Class context, String tag)? Does it have any advantages over ReentrantLock? Glavo On Tue, Jan 27, 2026 at 2:28?PM Eirik Bj?rsn?s wrote: > On Tue, Jan 27, 2026 at 12:05?AM Roger Riggs > wrote: > >> Hi, >> >> String is also an Identity class and its value could distinguish between >> the cases. (Both strings can be very short). >> >> About java.lang.Object as a lock, the pervasiveness of `new Object()` for >> locks resulted in giving it special dispensation in as a supertype of value >> objects. Trying to change its existing uses was determined to be infeasible. >> > > Great minds are pulling this thread in interesting directions, which is > fine! I may go ahead file a PR to focus on the specific small changes > initially suggested. Then any broader discussions can continue here. > > Was there ever any thoughts to add an API point for defining new montor > objects, such as Object.newLock() or perhaps even something like > Object.newLock(Class context, String tag)? > > Perhaps this could: > > a) Make the semantics/purpose of creating a new object more clear > b) Allow the JVM to return any object it wants > c) Allow monitor objects to be more informative > > Cheers, > Eirik. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dl at openjdk.org Tue Jan 27 12:11:27 2026 From: dl at openjdk.org (Doug Lea) Date: Tue, 27 Jan 2026 12:11:27 GMT Subject: RFR: 8373118: Test java/lang/Thread/virtual/Starvation.java timed out [v30] 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: Avoid yield, for performance test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28797/files - new: https://git.openjdk.org/jdk/pull/28797/files/04928c94..a7f1d63f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=29 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28797&range=28-29 Stats: 89 lines in 1 file changed: 13 ins; 21 del; 55 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 eirbjo at gmail.com Tue Jan 27 12:27:31 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 13:27:31 +0100 Subject: RFD: Replace class java.lang.Shutdown.Lock with Object? In-Reply-To: References: <125ac588-27d1-4441-8f64-3f6b000e9634@oracle.com> <1096148f-194b-46f6-b142-d5bd75980b82@oracle.com> Message-ID: On Tue, Jan 27, 2026 at 1:06?PM Glavo wrote: > > Was there ever any thoughts to add an API point for defining new montor > objects, such as Object.newLock() or perhaps even something like > Object.newLock(Class context, String tag)? > > Does it have any advantages over ReentrantLock? > Hello Glavo, This discussion has been focused on monitor lock objects used for plain old Java synchronization. Whether ReentrantLock has advantages over Java synchronization is an interesting discussion, but probably a side track from this one. A lot of code uses synchronized just fine, that's probably not going to change any day soon. Cheers, Eirik. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Tue Jan 27 12:30:31 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Tue, 27 Jan 2026 12:30:31 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 16:48:11 GMT, Paul Sandoz wrote: > The underlying motivation was to avoid passing two parameters to the vector intrinsics that can get out of sync. Currently, we cannot use `Float16.class` like we can `Integer.class` that describes the vector element type to the intrinsic. Could we use an internal class that acts as a proxy until we can replace it? Hi @PaulSandoz , We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3804950143 From jpbempel at openjdk.org Tue Jan 27 12:41:50 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 12:41:50 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Message-ID: ?retransformed Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL ------------- Commit messages: - add missing files - 8376185: NoSuchFieldError thrown after a record with type annotation retransformed Changes: https://git.openjdk.org/jdk/pull/29445/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376185 Stats: 487 lines in 6 files changed: 485 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From liach at openjdk.org Tue Jan 27 13:34:13 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 13:34:13 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com> References: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com> Message-ID: On Tue, 27 Jan 2026 13:30:50 GMT, Chen Liang wrote: >> make/jdk/src/classes/build/tools/taglet/JSpec.java line 198: >> >>> 196: // Change whole text to "?chapter.x" in inline tags. >>> 197: literal = sectionSign + chapter + section; >>> 198: } >> >> What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)? >> >> For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript PREVIEW tag like we use in API references. > > I don't add section sign before full title because that's how jls/jvms menu entries render. > > For preview, you have a great point. I will add the superscript! I don't add section sign before full title because that's how jls/jvms menu entries render. For preview, you have a great point. I will add the superscript! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028494 From liach at openjdk.org Tue Jan 27 13:34:12 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 13:34:12 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: References: Message-ID: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com> On Tue, 27 Jan 2026 09:08:14 GMT, Hannes Walln?fer wrote: >> Chen Liang has updated the pull request incrementally with one additional commit since the last revision: >> >> Remove redundant dot > > make/jdk/src/classes/build/tools/taglet/JSpec.java line 198: > >> 196: // Change whole text to "?chapter.x" in inline tags. >> 197: literal = sectionSign + chapter + section; >> 198: } > > What is the rationale for only using the section sign when there is no title? If we render a title-less tag as `?1.2.34`, why not also render a titled tag as `?1.2.34 Section Title` (or vice versa)? > > For preview spec links, should there be a marker to indicate the preview status? I'm thinking of adding something like `(preview feature)` after the link, or a superscript PREVIEW tag like we use in API references. I don't add section sign before full title because that's how jls/jvms menu entries render. For preview, you have a great point. I will add the superscript! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732028380 From hannesw at openjdk.org Tue Jan 27 13:51:33 2026 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 27 Jan 2026 13:51:33 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: References: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com> Message-ID: On Tue, 27 Jan 2026 13:30:52 GMT, Chen Liang wrote: >> I don't add section sign before full title because that's how jls/jvms menu entries render. >> >> For preview, you have a great point. I will add the superscript! > > I don't add section sign before full title because that's how jls/jvms menu entries render. > > For preview, you have a great point. I will add the superscript! Following the spec way of rendering section links sounds reasonable to me. If you want to use the default style for the PREVIEW superscript the following should work: `PREVIEW` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732101521 From duke at openjdk.org Tue Jan 27 13:58:31 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Tue, 27 Jan 2026 13:58:31 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v7] In-Reply-To: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> References: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> Message-ID: On Tue, 27 Jan 2026 11:33:21 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 one additional commit since the last revision: > > Replace "unpaired surrogates" with "isolated surrogate code units" > > https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 > https://www.unicode.org/charts/PDF/UDC00.pdf Do we need to remove or preserve `Character.codePointCount(char[])`? I think it's inconsistent to have codePointCount(char[]) and codePointCount(CharSequence, int, int) but not codePointCount(CharSequence). We may need to update the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3805342031 From jvernee at openjdk.org Tue Jan 27 14:03:18 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 27 Jan 2026 14:03:18 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> Message-ID: On Tue, 27 Jan 2026 11:47:04 GMT, Christian Stein wrote: >> src/jdk.jartool/share/classes/sun/tools/jar/Validator.java line 480: >> >>> 478: errorAndInvalid(formatMsg("error.validator.manifest.invalid.automatic.module.name", automaticModuleName)); >>> 479: } >>> 480: if (md == null || automaticModuleName.equals(md.name())) { >> >> Realizing this now, but this is only checking the top-level `module-info.class`, not any of the ones under the `META-INF/versions` directories. e.g. `checkModuleDescriptor` is also being called for each versioned `module-info.class` file. Is that something that we should also be doing for this check? > > The `this.md` field is initialized (by `checkModuleDescriptor(MODULE_INFO);` from within the constructor) to the "base" compiled module descriptor. It also includes this comment: > >> ``` >> // Initialize the base md if it's not yet. A "base" md can be either the >> // root module-info.class or the first versioned module-info.class >> ``` > > With that in place, and the consistency checks being performed in `checkModuleDescriptor(MODULE_INFO);`, we are good. I mean for cases where there are multiple module-info.class files. The automatic module name check only checks the first one, right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2732153058 From liach at openjdk.org Tue Jan 27 14:10:05 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:10:05 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v2] In-Reply-To: References: <-IFICc7RnTJ-s01jPLlY9dK-lTrLHjfaa5TX92vxvG0=.699e96c8-5e09-40ed-b8f8-8c901f132052@github.com> Message-ID: On Tue, 27 Jan 2026 13:48:12 GMT, Hannes Walln?fer wrote: >> I don't add section sign before full title because that's how jls/jvms menu entries render. >> >> For preview, you have a great point. I will add the superscript! > > Following the spec way of rendering section links sounds reasonable to me. > > If you want to use the default style for the PREVIEW superscript the following should work: `PREVIEW` Indeed, double checked, seems we cannot link to something else for the sup unlike for regular html preview links. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29402#discussion_r2732183226 From cstein at openjdk.org Tue Jan 27 14:24:36 2026 From: cstein at openjdk.org (Christian Stein) Date: Tue, 27 Jan 2026 14:24:36 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> Message-ID: On Tue, 27 Jan 2026 14:00:43 GMT, Jorn Vernee wrote: >> The `this.md` field is initialized (by `checkModuleDescriptor(MODULE_INFO);` from within the constructor) to the "base" compiled module descriptor. It also includes this comment: >> >>> ``` >>> // Initialize the base md if it's not yet. A "base" md can be either the >>> // root module-info.class or the first versioned module-info.class >>> ``` >> >> With that in place, and the consistency checks being performed in `checkModuleDescriptor(MODULE_INFO);`, we are good. > > I mean for cases where there are multiple module-info.class files. The automatic module name check only checks the first one, right? Right. > I mean for cases where there are multiple `module-info.class` files. Which are checked for a single name separately. Thus, comparing an automatic module name with the name from the first compiled module is sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2732246538 From liach at openjdk.org Tue Jan 27 14:26:41 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:26:41 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v3] In-Reply-To: References: Message-ID: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com> > We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: > > > @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions > > > Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. > > As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. > > I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! 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: - Add preview superscript when applicable - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance - Remove redundant dot - 8376274: JSpec preview support and output enhancement ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29402/files - new: https://git.openjdk.org/jdk/pull/29402/files/74af3243..1e414f9f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29402&range=01-02 Stats: 3783 lines in 168 files changed: 1984 ins; 859 del; 940 mod Patch: https://git.openjdk.org/jdk/pull/29402.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29402/head:pull/29402 PR: https://git.openjdk.org/jdk/pull/29402 From liach at openjdk.org Tue Jan 27 14:29:33 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:29:33 GMT Subject: RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in java.util.zip.ZipCoder In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:44:42 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which removes a dependency on `java.nio.charset.StandardCharsets` introduced in [JDK-8365703](https://bugs.openjdk.org/browse/JDK-8365703). > > We can use `UTF_8.INSTANCE` here as elsewhere in this class to prevent startup regression loading otherwise unused classes and charsets. > > Verified that running `java -cp hello.jar Hello` observes the following diff in loaded classes when run with this PR: > > > < java.nio.charset.StandardCharsets > < sun.nio.cs.US_ASCII > < sun.nio.cs.ISO_8859_1 > < sun.nio.cs.UTF_16BE > < sun.nio.cs.UTF_16LE > < sun.nio.cs.UTF_16 > < sun.nio.cs.UTF_32BE > < sun.nio.cs.UTF_32LE > < sun.nio.cs.UTF_32 > > > This is a strict refactoring, no tests updated, `noreg-trivial`. I don't think this is worth it - most user programs will refer to UTF_8 as StandardCharsets.UTF_8, so this doesn't really optimize anything. Also in the ArrayDeque to ArrayList case, ArrayList has other allocation benefits in addition to avoiding ArrayDeque class load. So I personally recommend withdrawing this patch, especially that AOT preimage should be able to capture the linked or even initialized state of StandardCharsets class. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3805526018 From liach at openjdk.org Tue Jan 27 14:40:17 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:40:17 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 10:48:41 GMT, Jean-Philippe Bempel wrote: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Please add a copyright header for your affliation for the new files (.java, .jcod, .sh) that you add, or fallback to an Oracle copyright header. See https://openjdk.org/guide/#copyright-headers ------------- PR Comment: https://git.openjdk.org/jdk/pull/29445#issuecomment-3805583503 From eirbjo at openjdk.org Tue Jan 27 14:45:12 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 14:45:12 GMT Subject: RFR: 8376483: Avoid loading java.nio.charset.StandardCharsets in java.util.zip.ZipCoder In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 14:26:45 GMT, Chen Liang wrote: > I don't think this is worth it - most user programs will refer to UTF_8 as StandardCharsets.UTF_8, so this doesn't really optimize anything. Also in the ArrayDeque to ArrayList case, ArrayList has other allocation benefits in addition to avoiding ArrayDeque class load. So I personally recommend withdrawing this patch, especially that AOT preimage should be able to capture the linked or even initialized state of StandardCharsets class. Some context: I spotted this because I've gotten review feedback in the past (from @cl4es IIRC) about avoiding `StandardCharsets` in this class. The current version of the class has three occurrences of `UTF_8.INSTANCE` besides this one recently introduced `StandardCharsets.UTF_8` instance. So there is a consistency issue here as well, besides any (valid or invalid) performance concerns. See also the following note from `StandardCharsets`: // To avoid accidental eager initialization of often unused Charsets // from happening while the VM is booting up, which may delay // initialization of VM components, we should generally avoid depending // on this class from elsewhere in java.base. @cl4es may have opinions about the present validity of this note. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29443#issuecomment-3805613881 From cstein at openjdk.org Tue Jan 27 14:45:12 2026 From: cstein at openjdk.org (Christian Stein) Date: Tue, 27 Jan 2026 14:45:12 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> Message-ID: <3rEQNQx7IaH4xC3Y96CHWIZX-QE1fa3TZiILlo8-f8c=.2b81e7f5-3f66-40b7-90f4-d42fe1ed7567@github.com> On Tue, 27 Jan 2026 14:21:29 GMT, Christian Stein wrote: > Which are checked for a single name separately. https://github.com/openjdk/jdk/blob/8690d263d9dd0fd06ed41d9529fd8cc84e1c08c8/src/jdk.jartool/share/classes/sun/tools/jar/Validator.java#L494-L496 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2732360276 From hannesw at openjdk.org Tue Jan 27 14:54:21 2026 From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=) Date: Tue, 27 Jan 2026 14:54:21 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v3] In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com> References: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com> Message-ID: On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang wrote: >> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: >> >> >> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions >> >> >> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. >> >> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. >> >> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! > > 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: > > - Add preview superscript when applicable > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance > - Remove redundant dot > - 8376274: JSpec preview support and output enhancement Looks good to me! ------------- Marked as reviewed by hannesw (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29402#pullrequestreview-3711671933 From liach at openjdk.org Tue Jan 27 14:54:33 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:54:33 GMT Subject: RFR: 8376277: Migrate java/lang/reflect tests away from TestNG [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:36:06 GMT, Chen Liang wrote: >> Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. >> >> Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. > > Chen Liang has updated the pull request incrementally with one additional commit since the last revision: > > Review remarks Thanks for the review! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29405#issuecomment-3805655668 From liach at openjdk.org Tue Jan 27 14:54:36 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 14:54:36 GMT Subject: Integrated: 8376277: Migrate java/lang/reflect tests away from TestNG In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 05:19:25 GMT, Chen Liang wrote: > Mostly routine conversions. Manual updates are mostly assertThrows migration, assertArrayEquals fixes, and removal of TestInstance to convert method sources to be static. > > Notably, I avoided assertThrows migration in `ChainedReflection` and `IllegalArgumentsTest` because they seem to be very sensitive to low-level reflection and runtime stuff that I fear using test framework may accidentally harm. This pull request has now been integrated. Changeset: bbb4b0d4 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/bbb4b0d498900f929225233008bbdbafaae5d709 Stats: 799 lines in 28 files changed: 91 ins; 286 del; 422 mod 8376277: Migrate java/lang/reflect tests away from TestNG Reviewed-by: alanb ------------- PR: https://git.openjdk.org/jdk/pull/29405 From jpbempel at openjdk.org Tue Jan 27 14:56:31 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Tue, 27 Jan 2026 14:56:31 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: > ?retransformed > > Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. > > Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: add copyright headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29445/files - new: https://git.openjdk.org/jdk/pull/29445/files/33f92068..725f4edb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29445&range=00-01 Stats: 93 lines in 4 files changed: 93 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29445.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29445/head:pull/29445 PR: https://git.openjdk.org/jdk/pull/29445 From liach at openjdk.org Tue Jan 27 15:08:24 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 15:08:24 GMT Subject: Integrated: 8376274: JSpec preview support and output enhancement In-Reply-To: References: Message-ID: On Sun, 25 Jan 2026 19:06:26 GMT, Chen Liang wrote: > We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: > > > @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions > > > Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. > > As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. > > I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! This pull request has now been integrated. Changeset: a5d0b051 Author: Chen Liang URL: https://git.openjdk.org/jdk/commit/a5d0b05136e34871366441a8c8e6bda5f20c617c Stats: 65 lines in 2 files changed: 47 ins; 3 del; 15 mod 8376274: JSpec preview support and output enhancement Reviewed-by: hannesw ------------- PR: https://git.openjdk.org/jdk/pull/29402 From liach at openjdk.org Tue Jan 27 15:08:22 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 15:08:22 GMT Subject: RFR: 8376274: JSpec preview support and output enhancement [v3] In-Reply-To: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com> References: <0Uizngpunu9Nulu4bP76-_obBa-n_poVx2qF985UL-8=.8f446b68-ae5a-4a83-8f10-805cae4336ab@github.com> Message-ID: On Tue, 27 Jan 2026 14:26:41 GMT, Chen Liang wrote: >> We can enhance the `@jls` and `@jvms` tags in-place to support preview JLS/JVMS, such as in this PR: >> >> >> @jls primitive-types-in-patterns-instanceof-switch-5.7.1 Exact Testing Conversions >> >> >> Taglet now parses "primitive-types-in-patterns-instanceof-switch-" preview and links to `primitive-types-in-patterns-instanceof-switch-jls.html` where the 5.7.1 anchor exists. >> >> As a side effect, I adjusted the output to remove the preview prefix, and discovered we can embellish the output more, in particular, including a section sign for inline tags and including a trailing dot for block tags. >> >> I need this feature in project Valhalla, where there are JLS and JVMS for value-objects and strict-fields that we need to link to. Please help review! > > 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: > > - Add preview superscript when applicable > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/jspec-enhance > - Remove redundant dot > - 8376274: JSpec preview support and output enhancement Thanks for the review! I need this for Valhalla (somewhat desperately) so I will integrate immediately. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29402#issuecomment-3805721235 From rriggs at openjdk.org Tue Jan 27 15:16:21 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jan 2026 15:16:21 GMT Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue In-Reply-To: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> Message-ID: <2NqJEv95diY0LQNjWm-Snej58fWoU6M25y6lB8LT-Qg=.8b1105ce-5507-4acb-9ab3-026dfa36d5fd@github.com> On Tue, 27 Jan 2026 10:01:34 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. > > These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes. > > Additionally, this PR marks the lock objects in `Shutdown` as `final` > > This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html. > > Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`. Looks good. Allow some time before integrating for other reviewers. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29442#pullrequestreview-3711786936 From rriggs at openjdk.org Tue Jan 27 15:30:26 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jan 2026 15:30:26 GMT Subject: RFR: 8376509: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed: expected: <9> but was: <11> Message-ID: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> Problem list the test java/lang/ProcessBuilder/PipelineLeaksFD.java. ------------- Commit messages: - JDK-8375585: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed: expected: <9> but was: <11> Changes: https://git.openjdk.org/jdk/pull/29450/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29450&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376509 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29450.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29450/head:pull/29450 PR: https://git.openjdk.org/jdk/pull/29450 From liach at openjdk.org Tue Jan 27 15:30:27 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 15:30:27 GMT Subject: RFR: 8376509: Test java/lang/ProcessBuilder/PipelineLeaksFD.java failed: expected: <9> but was: <11> In-Reply-To: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> References: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> Message-ID: On Tue, 27 Jan 2026 15:06:48 GMT, Roger Riggs wrote: > Problem list the test java/lang/ProcessBuilder/PipelineLeaksFD.java. Marked as reviewed by liach (Reviewer). I think the Problemlisting patch needs a different number from the actual issue being problemlisted. Please change the PR title to `8376509`. The bot will automatically fill in the right title and final commit message for you. ------------- PR Review: https://git.openjdk.org/jdk/pull/29450#pullrequestreview-3711752814 Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29450#pullrequestreview-3711755181 PR Comment: https://git.openjdk.org/jdk/pull/29450#issuecomment-3805787015 From jpai at openjdk.org Tue Jan 27 15:37:54 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Tue, 27 Jan 2026 15:37:54 GMT Subject: RFR: 8376509: Problemlist Test java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> References: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> Message-ID: On Tue, 27 Jan 2026 15:06:48 GMT, Roger Riggs wrote: > Problem list the test java/lang/ProcessBuilder/PipelineLeaksFD.java. Marked as reviewed by jpai (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29450#pullrequestreview-3711905817 From vklang at openjdk.org Tue Jan 27 15:48:49 2026 From: vklang at openjdk.org (Viktor Klang) Date: Tue, 27 Jan 2026 15:48:49 GMT Subject: RFR: 8373243 : EnumSet.spliterator() should specify and document its characteristics [v3] In-Reply-To: References: Message-ID: On Fri, 9 Jan 2026 00:57:39 GMT, ExE Boss wrote: >> 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 > > src/java.base/share/classes/java/util/EnumSet.java line 524: > >> 522: */ >> 523: @Override >> 524: public final Spliterator spliterator() { > > Maybe?keep this?method non?`final` so?that?specialised implementations may?be?provided by?`SimpleEnumSet` or?`JumboEnumSet` in?the?future without?needing to?remove the?`final`?modifier. > Suggestion: > > public Spliterator spliterator() { On the contrary, I think adding `final` here serves as a good indicator to anyone possibly wanting to override spliterator() that they need to consider the behavior of the superclass' implementation. AS EnumSet is `sealed` there is no risk to non-jdk code and dropping the `final`-modifier later is trivial. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28696#discussion_r2732655652 From rriggs at openjdk.org Tue Jan 27 16:11:15 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jan 2026 16:11:15 GMT Subject: Integrated: 8376509: [process] Problemlist Test java/lang/ProcessBuilder/PipelineLeaksFD.java In-Reply-To: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> References: <6VT8PlsBWpBBJjehf1X8mFWAh5hORnVu2T6e8w5oHhE=.88abe741-20ae-4bb7-9519-be4bcedf18d7@github.com> Message-ID: <4Fcjm1Yq_K94X7Nt_AABXNQ4RttXltwpu8nGy-hPdOM=.9c47a251-bfcc-41ed-871a-7c7acda661dd@github.com> On Tue, 27 Jan 2026 15:06:48 GMT, Roger Riggs wrote: > Problem list the test java/lang/ProcessBuilder/PipelineLeaksFD.java. This pull request has now been integrated. Changeset: e8048c87 Author: Roger Riggs URL: https://git.openjdk.org/jdk/commit/e8048c87bc9c152932ee59cb674bdb6670db2a56 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod 8376509: [process] Problemlist Test java/lang/ProcessBuilder/PipelineLeaksFD.java Reviewed-by: jpai ------------- PR: https://git.openjdk.org/jdk/pull/29450 From dfenacci at openjdk.org Tue Jan 27 16:22:52 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:22:52 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v2] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374852: fix macro expansion for OpaqueCheck - JDK-8374852: use only one opaque node ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/ff228576..b79738c3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=00-01 Stats: 95 lines in 15 files changed: 11 ins; 42 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Tue Jan 27 16:22:52 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:22:52 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v2] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <6E6brqNG-kkjvis3nNZrX5YFDNX5dRNTS2igk2BjVzs=.4d6ab39a-b6de-49f1-a51f-6723e8c59833@github.com> Message-ID: On Tue, 27 Jan 2026 09:24:34 GMT, Christian Hagedorn wrote: >> Fair enough ? I was just curious. > > I was about to ask the same question. It seems like both `OpaqueNotNullNode` and `OpaqueGuardNode` behave the same apart from eventually folding to a false or true constant. They might have slightly different reasons for adding them but AFAIU, they are both intended to keep control and data in sync. Apart from duplicating most of the logic and comments, an additional challenge with having both nodes is that we need to special case both nodes at various points in the code which makes it more complex and raises the question if we could really observe them both or not (would not be a problem when only having one node type). Thanks for reviewing @chhagedorn. > special case both nodes at various points Good point. I guess better have only one after all. Changed. (I called it `OpaqueCheck` for lack of a better idea) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2732811990 From dfenacci at openjdk.org Tue Jan 27 16:26:19 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Tue, 27 Jan 2026 16:26:19 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374852: fix star layout Co-authored-by: Christian Hagedorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/b79738c3..0ef73ef9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=01-02 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From jvernee at openjdk.org Tue Jan 27 16:55:15 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 27 Jan 2026 16:55:15 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 08:36:39 GMT, Christian Stein wrote: >> Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. >> >> Prior to this commit, a `MANFEST.MF` reading >> >> Automatic-Module-Name: default >> >> added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: >> >> $ java --module-path a.jar --describe-module default >> >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for a.jar >> Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier >> >> >> With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: >> >> >> invalid module name of Automatic-Module-Name entry in manifest: default >> >> >> The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments Marked as reviewed by jvernee (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29316#pullrequestreview-3712337343 From jvernee at openjdk.org Tue Jan 27 16:55:16 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 27 Jan 2026 16:55:16 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: <3rEQNQx7IaH4xC3Y96CHWIZX-QE1fa3TZiILlo8-f8c=.2b81e7f5-3f66-40b7-90f4-d42fe1ed7567@github.com> References: <0FZFkBvd8-kPlz7G0Inf8DRPbW8LZ1xZTlyTt78xYZA=.dde9c3b7-b3c0-414d-adeb-07e6adf629df@github.com> <2HUOy5SEuTHDg9wTx12LFv_diBuilwau8F9TZchGbTY=.1df49ab4-2b58-435e-a565-8d9c061df367@github.com> <3rEQNQx7IaH4xC3Y96CHWIZX-QE1fa3TZiILlo8-f8c=.2b81e7f5-3f66-40b7-90f4-d42fe1ed7567@github.com> Message-ID: On Tue, 27 Jan 2026 14:42:17 GMT, Christian Stein wrote: >> Right. >> >>> I mean for cases where there are multiple `module-info.class` files. >> >> Which are checked for a single name separately. Thus, comparing an automatic module name with the name from the first compiled module is sufficient. > >> Which are checked for a single name separately. > > https://github.com/openjdk/jdk/blob/8690d263d9dd0fd06ed41d9529fd8cc84e1c08c8/src/jdk.jartool/share/classes/sun/tools/jar/Validator.java#L494-L496 Ah, gotcha ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2732945771 From jvernee at openjdk.org Tue Jan 27 16:57:35 2026 From: jvernee at openjdk.org (Jorn Vernee) Date: Tue, 27 Jan 2026 16:57:35 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 |... Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3806333930 From shade at openjdk.org Tue Jan 27 17:26:35 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Tue, 27 Jan 2026 17:26:35 GMT Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue In-Reply-To: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> Message-ID: On Tue, 27 Jan 2026 10:01:34 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which removes empty nested `Lock` classes in `java.lang.Shutdown` and `java.lang.ref.ReferenceQueue`. > > These are replaced with the more common "new Object()" idiom, which saves us loading these two nested classes. > > Additionally, this PR marks the lock objects in `Shutdown` as `final` > > This was initially discussed in https://mail.openjdk.org/pipermail/core-libs-dev/2026-January/157704.html. > > Except the observability of the lock name class, this should be a strict refactoring. No tests updated, `noreg-cleanup`. This looks fine in principle, and dealing with papercut issues like these does add up to improvements eventually. There is an observability loss, though. I would have suspected it is marginal. But even GHA catches fire in `serviceability/sa/ClhsdbInspect` looking for now-missing named lock. So run more tests and see what else might be depending on it? ------------- PR Review: https://git.openjdk.org/jdk/pull/29442#pullrequestreview-3712511229 From jlu at openjdk.org Tue Jan 27 17:41:35 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 27 Jan 2026 17:41:35 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v2] In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit Justin Lu has updated the pull request incrementally with 11 additional commits since the last revision: - clean up some of the statement lambdas - use static imports for assertions - TestInstance cleanup -> Base test remains PER_CLASS (as needed), child classes remove redundant annotations - Convert testNG Object[][] style data providers to Stream - Convert test/jdk/java/sql/junit/test/sql/ param tests to ensure original semantics - Resolve errors stemming from JUnit auto-closeable resolution - Resolve undetected BaseTest data providers - Resolve no automated replacement for assertEqualsNoOrder - Apply automated conversion to javax/sql and update testng to junit naming for folder & properties - Refactor JavatimeTest.java to use JUnit and migrate under junit folder - ... and 1 more: https://git.openjdk.org/jdk/compare/8ba8213f...06098254 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29354/files - new: https://git.openjdk.org/jdk/pull/29354/files/8ba8213f..06098254 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=00-01 Stats: 14766 lines in 88 files changed: 7375 ins; 6972 del; 419 mod Patch: https://git.openjdk.org/jdk/pull/29354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29354/head:pull/29354 PR: https://git.openjdk.org/jdk/pull/29354 From jlu at openjdk.org Tue Jan 27 17:48:14 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 27 Jan 2026 17:48:14 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v2] In-Reply-To: References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Tue, 27 Jan 2026 17:41:35 GMT, Justin Lu wrote: >> Please review this PR which converts the JDBC TestNG tests to use JUnit. >> >> This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. >> >> Framework test stats before: >> 680 = 680 TestNG + 0 JUnit >> >> Framework test stats after: >> 680 = 0 TestNG + 680 JUnit > > Justin Lu has updated the pull request incrementally with 11 additional commits since the last revision: > > - clean up some of the statement lambdas > - use static imports for assertions > - TestInstance cleanup -> Base test remains PER_CLASS (as needed), child classes remove redundant annotations > - Convert testNG Object[][] style data providers to Stream > - Convert test/jdk/java/sql/junit/test/sql/ param tests to ensure original semantics > - Resolve errors stemming from JUnit auto-closeable resolution > - Resolve undetected BaseTest data providers > - Resolve no automated replacement for assertEqualsNoOrder > - Apply automated conversion to javax/sql and update testng to junit naming for folder & properties > - Refactor JavatimeTest.java to use JUnit and migrate under junit folder > - ... and 1 more: https://git.openjdk.org/jdk/compare/8ba8213f...06098254 The latest batch of commits updates the _javax/sql_ testNG files to use JUnit as well. `BaseTest` which the majority of tests rely on remain `Lifecycle.PER_CLASS` (as needed) but the non `BaseTest` extending classes were able to migrate to the default life cycle. Note that the parameterized tests were updated to have their `autoCloseArgument` attribute set to false, since there were failures when left on the default value of true. For example, `close()` is a no-op for many of the `Stub` classes which get tested. > AutoCloseable arguments > > Arguments that implement java.lang.AutoCloseable (or java.io.Closeable which extends java.lang.AutoCloseable) will be > automatically closed after the parameterized class or test invocation. To prevent this from happening, set the autoCloseArguments attribute in @ParameterizedTest to false. _JavaTimeTest_ was also updated to use JUnit and moved under the folder accordingly. Do we want the _jdk/test/jdk/javax/sql/rowset_ tests to also be migrated to use JUnit as well? Also, is it appropriate to place _jdk/test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java_ under _jdk/test/jdk/java/sql/junit/test/sql/othervm_ since it is now a JUnit test? ------------- PR Comment: https://git.openjdk.org/jdk/pull/29354#issuecomment-3806592650 From alanb at openjdk.org Tue Jan 27 17:54:56 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 27 Jan 2026 17:54:56 GMT Subject: RFR: 8375433: jar should validate automatic module names [v2] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 08:36:39 GMT, Christian Stein wrote: >> Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. >> >> Prior to this commit, a `MANFEST.MF` reading >> >> Automatic-Module-Name: default >> >> added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: >> >> $ java --module-path a.jar --describe-module default >> >> Error occurred during initialization of boot layer >> java.lang.module.FindException: Unable to derive module descriptor for a.jar >> Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier >> >> >> With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: >> >> >> invalid module name of Automatic-Module-Name entry in manifest: default >> >> >> The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. > > Christian Stein has updated the pull request incrementally with one additional commit since the last revision: > > Address review comments test/jdk/tools/jar/ValidatorTest.java line 314: > 312: @Test > 313: public void testInvalidAutomaticModuleName() throws Exception { > 314: System.out.printf("%n%n*****Creating Jar with invalid Automatic-Module-Name in Manifest*****%n%n"); Should this be System.err so that it is inlined with the JUnit output. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29316#discussion_r2733180819 From ogillespie at openjdk.org Tue Jan 27 18:25:59 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 27 Jan 2026 18:25:59 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> References: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> Message-ID: On Mon, 26 Jan 2026 16:01:11 GMT, Chen Liang wrote: >> Oli Gillespie has updated the pull request incrementally with one additional commit since the last revision: >> >> Fix failing test > > src/java.base/share/classes/java/util/TreeMap.java line 2028: > >> 2026: } >> 2027: >> 2028: public abstract Spliterator> spliterator(); > > I don't think you need this huge a patch. I think you should just do: > Suggestion: > > public Spliterator> spliterator() { > return Spliterators.spliterator(iterator(), Spliterator.DISTINCT); > } > > Your patch is introducing spliterator behavioral changes unrelated to the performance regression fix. Thanks for looking. I suppose you mean Spliterators.spliteratorUnknownSize? Hmm - I made the change this way to be consistent with the existing `SubMapKeyIterator` and `DescendingSubMapKeyIterator`, simply adding the same functionality for the Entry versions. Do you think *those* are overcomplicated too, or there's a reason they're like that that doesn't apply to the Entry versions? I don't know why they were originally added, to be honest, I didn't find much useful context in the history. I don't know Spliterator well enough to spot any subtle behavioural differences, that's one reason I chose to follow the existing patterns. DescendingSubMapEntryIterator is SORTED but SubMapEntryIterator is not, so I'd have to account for that too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733284522 From psandoz at openjdk.org Tue Jan 27 18:28:32 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 27 Jan 2026 18:28:32 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 12:27:46 GMT, Jatin Bhateja wrote: > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3806791602 From psandoz at openjdk.org Tue Jan 27 18:41:13 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Tue, 27 Jan 2026 18:41:13 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 09:26:35 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 >> ... > > Eric Fang has updated the pull request incrementally with one additional commit since the last revision: > > Move helper functions into c2_MacroAssembler_aarch64.hpp The general way code flows right now, but not often, is from jdk/master to panama-vector/vectorIntrinsics, since most of the development work is in the mainline (exceptions to that are the float16 and Valhalla alignment work which are large efforts). I am very reluctant to include all the auto-generated micro benchmarks in mainline. There is a huge number of them and i am not certain they provide as much value as they did now we have the IR test framework. In may cases, given the simplicity of what they measure, they were designed to ensure C2 generates the right instructions. The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. The IR test framework is of course no substitute, in general, for performance tests. A better focus for Vector API performance tests is i think Emanuel's work [here](https://github.com/openjdk/jdk/pull/28639/) and use-cases/algorithms that can be implemented concisely. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3806851359 From liach at openjdk.org Tue Jan 27 18:44:29 2026 From: liach at openjdk.org (Chen Liang) Date: Tue, 27 Jan 2026 18:44:29 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: References: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> Message-ID: On Tue, 27 Jan 2026 18:22:52 GMT, Oli Gillespie wrote: > I suppose you mean Spliterators.spliteratorUnknownSize? Yes. Thanks for corecting me. > Hmm - I made the change this way to be consistent with the existing SubMapKeyIterator and DescendingSubMapKeyIterator, simply adding the same functionality for the Entry versions. I made the recommendation given the starting point is to address a performance regression, instead of to enhance the sub-map entry spliterator to be on par with the `DescendingSubMapKeyIterator`. >From this starting point, I believe we can easily identify `EntrySetView` inherits `Set::spliterator` which is slow because the spliterator calls `size()` frequently. This root problem is easily fixed with using `Spliterators.spliteratorUnknownSize`, which also has the minimal behavioral impact. In contrast, functional enhancement to spliterators is really a can of worms where you can never find an end - sometimes you add more flags, sometimes other splitting strategies. And in your example, you already have a test case failing due to the functional enhancements while you did make new tests to verify them. So let's keep it simple, fix the bug, and leave the functional enhancements for another time. This also makes backporting the fix much easier. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733346122 From missa at openjdk.org Tue Jan 27 19:02:44 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 19:02:44 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v9] In-Reply-To: References: Message-ID: > Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. > > Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. > > This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). > > 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` > 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` > 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` > 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` > > Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. > > 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` > > [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: Add double precision test to CMoveLConstants.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28337/files - new: https://git.openjdk.org/jdk/pull/28337/files/09d1e44d..0058e3e8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28337&range=07-08 Stats: 15 lines in 1 file changed: 14 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28337.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28337/head:pull/28337 PR: https://git.openjdk.org/jdk/pull/28337 From missa at openjdk.org Tue Jan 27 19:14:31 2026 From: missa at openjdk.org (Mohamed Issa) Date: Tue, 27 Jan 2026 19:14:31 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v8] In-Reply-To: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> References: <4nlYmoQuUt0GFqk84hZN3YcEjBo1K8fEVZeUUOuN8Qs=.11d29fdf-18df-4c25-be12-146e7954812a@github.com> Message-ID: On Tue, 27 Jan 2026 07:57:03 GMT, Emanuel Peter wrote: >> Mohamed Issa has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 25 commits: >> >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - Change function names and extend IR encoding rules for CMove tests >> - Merge remote-tracking branch 'origin/master' into user/missa-prime/avx10_2 >> - Remove unnecessary CMOV blocks and adjust predicates involving APX and AVX10.2 >> - Remove extra jump instruction in signum floating point and unify three-way floating point comparison logic in x86.ad >> - Also update copyright year in IREncodingPrinter.java >> - Include apx_f in list of verified CPU features for IR encoding >> - Fix CMove IR tests to account for APX presence >> - Merge branch 'master' into user/missa-prime/avx10_2 >> - ... and 15 more: https://git.openjdk.org/jdk/compare/44b74e16...09d1e44d > > test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java line 65: > >> 63: applyIfPlatform = {"x64", "true"}, >> 64: applyIfCPUFeatureAnd = {"apx_f", "true", "avx10_2", "true"}, >> 65: phase = CompilePhase.FINAL_CODE) > > These are all `CMove` cases. I see you added branch/call cases in the benchmark. Would it make sense to have some similar cases here? > > And: this here is a test for `float`. Where do we cover `double`, which you are also making VM changes for? Unlike CMove, the branch/call cases don't have special definitions in the `x86.ad` file for constants. The jump instructions behave the same way for all value types because they only check the register flags. So, I think the branch tests in `TestFPComparison.java` are sufficient since they cover the comparison instructions as well. As for double precision, I just added a test mirroring the single precision one. Thanks for noting that. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28337#discussion_r2733456586 From lancea at openjdk.org Tue Jan 27 20:00:15 2026 From: lancea at openjdk.org (Lance Andersen) Date: Tue, 27 Jan 2026 20:00:15 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v2] In-Reply-To: References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Tue, 27 Jan 2026 17:44:55 GMT, Justin Lu wrote: > The latest batch of commits updates the _javax/sql_ testNG files to use JUnit as well. `BaseTest` which the majority of tests rely on remain `Lifecycle.PER_CLASS` (as needed) but the non `BaseTest` extending classes were able to migrate to the default life cycle. Note that the parameterized tests were updated to have their `autoCloseArgument` attribute set to false, since there were failures when left on the default value of true. For example, `close()` is a no-op for many of the `Stub` classes which get tested. > > > AutoCloseable arguments > > Arguments that implement java.lang.AutoCloseable (or java.io.Closeable which extends java.lang.AutoCloseable) will be > > automatically closed after the parameterized class or test invocation. To prevent this from happening, set the autoCloseArguments attribute in @ParameterizedTest to false. > > _JavaTimeTest_ was also updated to use JUnit and moved under the folder accordingly. Do we want the _jdk/test/jdk/javax/sql/rowset_ tests to also be migrated to use JUnit as well? Yes these should be migrated at the same time, thank you for asking Also, is it appropriate to place _jdk/test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java_ under _jdk/test/jdk/java/sql/junit/test/sql/othervm_ since it is now a JUnit test? No harm in that. As I mentioned previously we probably can get rid of the junit directory(previously testing) given all of the tests are junit now. Or we can do it at a later time. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29354#issuecomment-3807241756 From ogillespie at openjdk.org Tue Jan 27 20:19:40 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Tue, 27 Jan 2026 20:19:40 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: References: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> Message-ID: On Tue, 27 Jan 2026 18:39:54 GMT, Chen Liang wrote: >> Thanks for looking. >> >> I suppose you mean Spliterators.spliteratorUnknownSize? >> >> Hmm - I made the change this way to be consistent with the existing `SubMapKeyIterator` and `DescendingSubMapKeyIterator`, simply adding the same functionality for the Entry versions. Do you think *those* are overcomplicated too, or there's a reason they're like that that doesn't apply to the Entry versions? I don't know why they were originally added, to be honest, I didn't find much useful context in the history. >> >> I don't know Spliterator well enough to spot any subtle behavioural differences, that's one reason I chose to follow the existing patterns. >> >> DescendingSubMapEntryIterator is SORTED but SubMapEntryIterator is not, so I'd have to account for that too. > >> I suppose you mean Spliterators.spliteratorUnknownSize? > > Yes. Thanks for corecting me. > >> Hmm - I made the change this way to be consistent with the existing SubMapKeyIterator and DescendingSubMapKeyIterator, simply adding the same functionality for the Entry versions. > > I made the recommendation given the starting point is to address a performance regression, instead of to enhance the sub-map entry spliterator to be on par with the `DescendingSubMapKeyIterator`. > > From this starting point, I believe we can easily identify `EntrySetView` inherits `Set::spliterator` which is slow because the spliterator calls `size()` frequently. This root problem is easily fixed with using `Spliterators.spliteratorUnknownSize`, which also has the minimal behavioral impact. > > In contrast, functional enhancement to spliterators is really a can of worms where you can never find an end - sometimes you add more flags, sometimes other splitting strategies. And in your example, you already have a test case failing due to the functional enhancements while you did make new tests to verify them. > > So let's keep it simple, fix the bug, and leave the functional enhancements for another time. This also makes backporting the fix much easier. Okay sounds good to me! Thanks for the suggestion, I'll update later this week. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2733671479 From eirbjo at openjdk.org Tue Jan 27 20:58:09 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 20:58:09 GMT Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue In-Reply-To: References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> Message-ID: On Tue, 27 Jan 2026 17:23:58 GMT, Aleksey Shipilev wrote: > This looks fine in principle, and dealing with papercut issues like these does add up to improvements eventually. Yes, that was the idea. Individual weeds may feel insignificant, collectively they reduce the harvest. > There is an observability loss, though. I would have suspected it is marginal. But even GHA catches fire in `serviceability/sa/ClhsdbInspect` looking for now-missing named lock. So run more tests and see what else might be depending on it? Thanks, I should have done more homework here! Indeed there are JDK tests referencing (pun questionable) `ReferenceQueue$Lock`. These are: * `test/jdk/java/util/concurrent/Phaser/Basic.java` * Debug method `dumpTestThreads` inspects lock object to filter out dumping of "Reference Handler" thread. * Solution: Thread name should be sufficent for this purpose * `test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` * Tries to inspect the `ReferenceQueue$Lock` lock object * Solution: Replace with a nested Lock class in `LingeredAppWithLock` * `test/jdk/java/util/concurrent/ConcurrentHashMap/ConcurrentAssociateTest.java` * Debug method `dumpTestThreads` inspects lock object to filter out dumping of "Reference Handler" thread. * Solution: Thread name should be sufficent for this purpose * `test/micro/org/openjdk/bench/jdk/internal/jrtfs/ImageReaderBenchmark.java` * Expects to find `ReferenceQueue$Lock` and `Shutdown$Lock` in the system image * Solution: Remove these names from the list of expected class resources Unless there are other suggestions, I think we can put this PR on hold for now and address the above test issues as a separate PR. They were relatively simple to fix. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29442#issuecomment-3807493059 From naoto at openjdk.org Tue Jan 27 21:22:28 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Jan 2026 21:22:28 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v3] In-Reply-To: References: Message-ID: <2WlcRXVtwHGmCe0zREIeiY_RCmGPllR0but9viDs5l4=.f6ce512b-52bc-4ddb-ae43-065c658e64da@github.com> > This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Modified the test to cover all ISO formatters (sans *LOCAL*), not only the changed ones ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29393/files - new: https://git.openjdk.org/jdk/pull/29393/files/1b253613..659e633a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=01-02 Stats: 7 lines in 1 file changed: 5 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29393/head:pull/29393 PR: https://git.openjdk.org/jdk/pull/29393 From eirbjo at openjdk.org Tue Jan 27 21:23:44 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Tue, 27 Jan 2026 21:23:44 GMT Subject: RFR: 8376477: Avoid loading empty Lock classes in Shutdown and ReferenceQueue In-Reply-To: References: <6-UBeTJZMY7O7Ea5sthTbokGk4m-EQ3kP7R70UZLhWQ=.b5def993-854d-4b44-bd2d-46f978fb40f7@github.com> Message-ID: <2Fnetva7fQGJ0JYl_i4Z7xdrEHYyD9wskvKP60dtdqE=.b7bea802-4e3e-48bc-974b-edaa4b141971@github.com> On Tue, 27 Jan 2026 20:55:26 GMT, Eirik Bj?rsn?s wrote: > Unless there are other suggestions, I think we can put this PR on hold for now and address the above test issues as a separate PR. They were relatively simple to fix. See draft PR #29455, waiting for GHA to run before publishing for review. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29442#issuecomment-3807596328 From rriggs at openjdk.org Tue Jan 27 22:19:38 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Tue, 27 Jan 2026 22:19:38 GMT Subject: Withdrawn: 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. This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/28586 From jlu at openjdk.org Tue Jan 27 23:31:06 2026 From: jlu at openjdk.org (Justin Lu) Date: Tue, 27 Jan 2026 23:31:06 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v3] In-Reply-To: <2WlcRXVtwHGmCe0zREIeiY_RCmGPllR0but9viDs5l4=.f6ce512b-52bc-4ddb-ae43-065c658e64da@github.com> References: <2WlcRXVtwHGmCe0zREIeiY_RCmGPllR0but9viDs5l4=.f6ce512b-52bc-4ddb-ae43-065c658e64da@github.com> Message-ID: <3bnefQnx_P6NVSmfgP_yUs0EQUWUgAH776MX-u3Q160=.44bfc19d-7bea-4cf1-8188-3fb5a1b5d58e@github.com> On Tue, 27 Jan 2026 21:22:28 GMT, Naoto Sato wrote: >> This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > Modified the test to cover all ISO formatters (sans *LOCAL*), not only the changed ones The impl and spec changes look consistent with [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051). I see that `ISO_INSTANT` does not need the fix due to [JDK-8365182](https://bugs.openjdk.org/browse/JDK-8365182). This change looks good to me. test/jdk/java/time/test/java/time/format/TestDateTimeFormatter.java line 361: > 359: @ParameterizedTest > 360: @MethodSource("data_iso_short_offset_parse") > 361: public void test_iso_short_offset_parse(String text, DateTimeFormatter formatter) { Even though this is primarily a parsing test, since we are already adding a test, I think it would not hurt to also check the "+/-00" shorthand offset cases. (Since the formatted text would take a different form than a non zero hour only offset.) ------------- Marked as reviewed by jlu (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29393#pullrequestreview-3713862331 PR Review Comment: https://git.openjdk.org/jdk/pull/29393#discussion_r2734178642 From smarks at openjdk.org Tue Jan 27 23:53:23 2026 From: smarks at openjdk.org (Stuart Marks) Date: Tue, 27 Jan 2026 23:53:23 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v5] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:05:06 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 continue... > > Jaikiran Pai 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: > > - merge latest from master branch > - merge latest from master branch > - Mark's suggestion - move the duration check to separate method > - merge latest from master branch > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds Thanks everybody for working on cleaning up this old test. The current state is a significant simplification from the earlier version. It seems like it's also a lot more reliable, though only time will tell! :-) I think there is a way to simplify the test further and to narrow the timing window. The test forks a subprocess that runs the SelfTerminator program. This obtains a remote ref, causing the parent JVM to create a DGC lease. The subprocess then halts, which stops the JVM without relinquishing the DGC lease. Thus the parent has a lease that nobody will ever renew or cancel, creating the conditions for the lease to time out. The observation is that the timeout logic is entirely within the parent JVM. The child's role is simply to obtain a lease and halt immediately. The parent JVM could be changed to call JavaVM.waitFor() to await the child's termination and to obtain a timestamp. This would remove the need to create a temporary file into which the child writes a timestamp from which the parent reads the timestamp. In addition, waitFor() allows the parent to check the child's exit status and signal an error if the status is nonzero. I guess one could argue that having the child obtain the timestamp immediately after the registry call is closer to the beginning of the actual lease. However, I don't think this makes much of a practical difference. In addition, comparing values of Instant.now() from different JVMs _probably_ ends up using the same time base for comparison, but comparing timestamps from different JVMs might be subject to some weird time skew. With this change the parent's pseudocode is this: 1. fork child 2. await child exit, check exit status 3. get start timestamp 4. latch.await() 5. get end timestamp, compare Note that using the CountDownLatch still works, even if countDown() is called before await(), so this logic is still sound. Anyway I think this simplifies things a bit by avoiding file I/O (and the explanations that go along with it) and make the timestamp logic easier to follow since it's all done in one place. Another small cleanup item: is it necessary to have a `@modules` declaration in the test? I don't see anything in the test that uses RMI internals. (The Test Library might need this stuff, though, not sure.) ------------- PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3808160797 From naoto at openjdk.org Tue Jan 27 23:56:36 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 27 Jan 2026 23:56:36 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v4] In-Reply-To: References: Message-ID: > This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: +00/-00 offsets tests ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29393/files - new: https://git.openjdk.org/jdk/pull/29393/files/659e633a..257272e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29393&range=02-03 Stats: 40 lines in 1 file changed: 22 ins; 5 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/29393.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29393/head:pull/29393 PR: https://git.openjdk.org/jdk/pull/29393 From jlu at openjdk.org Wed Jan 28 00:13:00 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 28 Jan 2026 00:13:00 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:56:36 GMT, Naoto Sato wrote: >> This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > +00/-00 offsets tests Marked as reviewed by jlu (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29393#pullrequestreview-3714023791 From erfang at openjdk.org Wed Jan 28 01:49:52 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 28 Jan 2026 01:49:52 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v9] 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 clearer comments to VectorMaskCastIdentityTest.java ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28313/files - new: https://git.openjdk.org/jdk/pull/28313/files/9c38a6d9..f53d330f Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28313&range=07-08 Stats: 14 lines in 1 file changed: 8 ins; 6 del; 0 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 Jan 28 01:52:38 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 28 Jan 2026 01:52:38 GMT Subject: RFR: 8370863: VectorAPI: Optimize the VectorMaskCast chain in specific patterns [v6] In-Reply-To: References: Message-ID: <_61TOKMrW72QC8X-YzGXJ2Ws5kUz5fhQxB9-Q9XHuKk=.3a271efc-1115-426a-aa94-678b5ba053f5@github.com> On Fri, 26 Dec 2025 11:10:07 GMT, Emanuel Peter wrote: >> 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 ;) @eme64 I have addressed your comments, would you mind taking another look of this PR? Thanks~ ------------- PR Comment: https://git.openjdk.org/jdk/pull/28313#issuecomment-3808501474 From erfang at openjdk.org Wed Jan 28 03:12:03 2026 From: erfang at openjdk.org (Eric Fang) Date: Wed, 28 Jan 2026 03:12:03 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:38:40 GMT, Paul Sandoz wrote: >> Eric Fang has updated the pull request incrementally with one additional commit since the last revision: >> >> Move helper functions into c2_MacroAssembler_aarch64.hpp > > The general way code flows right now, but not often, is from jdk/master to panama-vector/vectorIntrinsics, since most of the development work is in the mainline (exceptions to that are the float16 and Valhalla alignment work which are large efforts). > > I am very reluctant to include all the auto-generated micro benchmarks in mainline. There is a huge number of them and i am not certain they provide as much value as they did now we have the IR test framework. In may cases, given the simplicity of what they measure, they were designed to ensure C2 generates the right instructions. The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. > > The IR test framework is of course no substitute, in general, for performance tests. A better focus for Vector API performance tests is i think Emanuel's work [here](https://github.com/openjdk/jdk/pull/28639/) and use-cases/algorithms that can be implemented concisely. @PaulSandoz thanks for your insight, this really makes sense to me. Hi @theRealAph, I've added a number of IR tests into this PR, and there are also numerous related tests in `test/jdk/jdk/incubator/vector/`, like [UMINByte128VectorTests()](https://github.com/openjdk/jdk/blob/fa1b1d677ac492dfdd3110b9303a4c2b009046c8/test/jdk/jdk/incubator/vector/Byte128VectorTests.java#L3283), which are sufficient to ensure the qulity of this PR. I share your feeling that it's inconvenience to review the JMH test that isn't in the mainline. I should have included the JMH link in the commit message, which is here: [Byte128Vector.UMINLanes](https://github.com/openjdk/panama-vector/blob/2181a35d64762bb3ac3d7fb66212c2559b6b72b5/test/micro/org/openjdk/bench/jdk/incubator/vector/operation/Byte128Vector.java#L1542). Is it fine to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3808702684 From eirbjo at openjdk.org Wed Jan 28 06:00:45 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 06:00:45 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 Message-ID: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. Test only change/cleanup. `noreg-self` ------------- Commit messages: - Remove test dependencies on ReferenceQueue$Lock and Shutdown$Lock Changes: https://git.openjdk.org/jdk/pull/29455/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29455&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376533 Stats: 26 lines in 5 files changed: 6 ins; 8 del; 12 mod Patch: https://git.openjdk.org/jdk/pull/29455.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29455/head:pull/29455 PR: https://git.openjdk.org/jdk/pull/29455 From chagedorn at openjdk.org Wed Jan 28 08:23:31 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Wed, 28 Jan 2026 08:23:31 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Tue, 27 Jan 2026 16:26:19 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8374852: fix star layout > > Co-authored-by: Christian Hagedorn Thanks for unifying the two opaque nodes! I have some more comments. src/hotspot/share/opto/macro.cpp line 2559: > 2557: #else > 2558: bool is_positive = n->as_OpaqueCheck()->is_positive(); > 2559: _igvn.replace_node(n, _igvn.intcon(is_positive?1:0)); Suggestion: _igvn.replace_node(n, _igvn.intcon(is_positive ? 1 : 0)); src/hotspot/share/opto/opaquenode.hpp line 146: > 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the > 145: // BoolNode inputs instead). > 146: class OpaqueCheckNode : public Node { I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think? Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0). src/hotspot/share/opto/opaquenode.hpp line 148: > 146: class OpaqueCheckNode : public Node { > 147: private: > 148: bool _positive; Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`). src/hotspot/share/opto/opaquenode.hpp line 150: > 148: bool _positive; > 149: public: > 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. src/hotspot/share/opto/opaquenode.hpp line 159: > 157: virtual const Type* Value(PhaseGVN* phase) const; > 158: virtual const Type* bottom_type() const { return TypeInt::BOOL; } > 159: bool is_positive() { return _positive; } When going with `_constant`, we could turn this into int constant() const { return _constant ? 1 : 0; } ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3715097474 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735306919 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735376625 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735315675 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735369034 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2735392835 From eirbjo at openjdk.org Wed Jan 28 08:41:20 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 08:41:20 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` Note that `ConcurrentAssociateTest` and `Phaser/Basic` additionally depends on the existence of the long gone class `java.lang.ref.Reference$Lock`. This class was removed by JDK-8156500 back in 2016, so these dump methods have been slightly "broken" in their filtering since then. This PR cleans up that as well. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29455#issuecomment-3809806810 From eirbjo at gmail.com Wed Jan 28 09:26:44 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 10:26:44 +0100 Subject: RFD: Reorganize ZipCoder such that UTF8 is handled by the base class Message-ID: Hi, Bringing this up on core-libs-dev such that the motivation can be explained/discussed here and any future PR can focus on actual code changes. Summary: Reorganize the ZipCoder class hierarchy to let the base class handle UTF8 and the subclass handle arbitrary Charsets. This makes the design better match the ZIP specification and how ZIP files are used in the real world and additionally have some benefits in code quality and performance. Motivation: The ZipCoder class has been central to many ZipFile performance improvements in recent years. Many optimizations are encoding-specific and encapsulating these concerns makes a lot of sense. Currently, the base ZipCoder instance supports any given Charset. Then, a subclass UTF8ZipCoder provides higher performance optimizations specific to UTF-8. However, real-world use of the ZipFile API defaults to UTF-8. The ZIP specification long-ago introduced a flag to explicitly indicate that entries are encoded using UTF-8. The JAR specification has mandated UTF-8 since the beginning. Any use of non-UTF-8 ZIP files is increasingly niche and belongs in the legacy zone. The current UTF8ZipCoder is stateless and documented as thread safe, while the base class ZipCoder is not. As a subclass of ZipCode, UTF8ZipCoder does however inherit CharsetEncoder and CharsetDecoder state fields from its super class and it needs to pass a UTF8 Charset to its parent, without really using it. This makes state and thread safety harder to reason about. Since UTF8ZipCoder is always needed, the JVM must always load it along with the base class ZipCoder. Apart from loading an extra class, this prevents the JVM from seeing calls to ZipCoder methods as monomorphic. A draft implementation of this change indicates a ~3% performance win on ZipFile lookups in ZipFileGetEntry, probably explained by the compiler seeing only one instance of ZipCoder being loaded. Solution: Switch the class hierarchy of ZipCoder around such that the base class handles UTF-8. Introduce a new subclass CharsetZipCoder to handle legacy non-UTF ZIP files. Move the Charset, CharsetEncoder, CharsetDecoder fields to this subclass. Update code comments to reflect the changes. Risks: This should be a pure refactoring, mostly moving code around. Most changes can be performed in-place, such that side by side review will mostly reflect indentation changes. We have good test coverage for UTF8 and non-UTF-8 ZIP files to help us catch regressions. If I see support for this proposal, I'll be happy to submit a PR with the actual changes. Cheers, Eirik :-) -------------- next part -------------- An HTML attachment was scrubbed... URL: From jbhateja at openjdk.org Wed Jan 28 09:39:42 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:42 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v18] In-Reply-To: References: Message-ID: <23D_3Ap5t-E3oXX8yiulKT0bhbumyT4N8ucWDjNMZPE=.054aef2e-8280-448e-88b8-cbfcf91fbfaf@github.com> > 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: Adding new lane type constants for intrinsic entries, removing basictype extension changes ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28002/files - new: https://git.openjdk.org/jdk/pull/28002/files/ce5768fa..68145fd9 Webrevs: - full: Webrev is not available because diff is too large - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28002&range=16-17 Stats: 1162 lines in 58 files changed: 25 ins; 26 del; 1111 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 Wed Jan 28 09:39:44 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Wed, 28 Jan 2026 09:39:44 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz wrote: > > We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3810098116 From aph at openjdk.org Wed Jan 28 09:57:04 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 09:57:04 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:38:40 GMT, Paul Sandoz wrote: > I am very reluctant to include all the auto-generated micro benchmarks in mainline. There is a huge number of them I understand. However, when a performance claim is made for a PR then the proof surely must be included in that PR. This is essential for others to be able easily to verify a claim in their environment. I do not think this should be up for debate because it's a matter of scientific verifiability. There is no reason not to include the _specific benchmark_ that is the basis for a performance claim. Apart from anything else, it will make life much easier for future maintainers reading the history. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3810207659 From aph at openjdk.org Wed Jan 28 10:05:52 2026 From: aph at openjdk.org (Andrew Haley) Date: Wed, 28 Jan 2026 10:05:52 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 18:38:40 GMT, Paul Sandoz wrote: > The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. But as a reviewer I'm not looking at the IR at all, but at the performance. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3810262815 From duke at openjdk.org Wed Jan 28 10:11:29 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 10:11:29 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v7] In-Reply-To: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> References: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> Message-ID: On Tue, 27 Jan 2026 11:33:21 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 one additional commit since the last revision: > > Replace "unpaired surrogates" with "isolated surrogate code units" > > https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 > https://www.unicode.org/charts/PDF/UDC00.pdf /home/runner/work/jdk/jdk/test/jdk/java/lang/Character/Supplementary.java:352: error: incompatible types: String cannot be converted to char[] int n = Character.codePointCount(str); Seeing this error message, users will think that Java is clunky and unhelpful. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3810291676 From afarley at openjdk.org Wed Jan 28 11:38:23 2026 From: afarley at openjdk.org (Adam Farley) Date: Wed, 28 Jan 2026 11:38:23 GMT Subject: RFR: 8376188: Win8365790Test is missing @build jtreg.SkippedException In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 13:28:27 GMT, Adam Farley wrote: > This change ensures that the class "jtreg/SkippedException" can be found and used by the test while running with versions of jtreg that are under 7.5.1+1. > > > This has been tested elsewhere and seems to work well. > Test configs: > - JDK17 - jtreg 7.3.1+1 > - JDK25 - jtreg 7.5.1+1 > > https://bugs.openjdk.org/browse/JDK-8376188 Looks like the PR check failures in win64 serviceability and jdk_tier1 part 2 aren't related to this issue. The system.txt shows no error, and the log for both tasks shows this: 2026-01-26T15:27:13.1401765Z ##[error]Could not find a part of the path 'D:\a'. Rerunning with debug logging. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29416#issuecomment-3810780762 From eirbjo at openjdk.org Wed Jan 28 13:55:16 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 13:55:16 GMT Subject: RFR: 8376582: Remove assert from default method in java.util.zip.Checksum interface Message-ID: Please review this PR which removes an `assert` from the default method `Checksum::update(ByteBuffer)`. Since this is an interface, javac generates a synthetic inner class to capture the `$assertionsDisabled` information. This is the only use of assert within default methods in `java.base`. I do not think it carries its weight in terms of the loading the generated class, so I suggest we simply remove it. The method already returns when `pos > limit`. Trivial cleanup, `noreg-cleanup`. ------------- Commit messages: - Remove assert in default method causing synthetic nested class to be generated Changes: https://git.openjdk.org/jdk/pull/29466/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29466&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376582 Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29466.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29466/head:pull/29466 PR: https://git.openjdk.org/jdk/pull/29466 From rriggs at openjdk.org Wed Jan 28 13:56:21 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Jan 2026 13:56:21 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` The core-libs related changes look fine. So do the others but serviceability review would be good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29455#pullrequestreview-3716828194 From alanb at openjdk.org Wed Jan 28 14:03:38 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jan 2026 14:03:38 GMT Subject: RFR: 8376582: Remove assert from default method in java.util.zip.Checksum interface In-Reply-To: References: Message-ID: <88sCb4WLA1zQ1BSOkK3srN96d2aKGGpinDun2s7ZDss=.94f4fe6a-c105-42d6-8322-46d79e9f173d@github.com> On Wed, 28 Jan 2026 13:46:39 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which removes an `assert` from the default method `Checksum::update(ByteBuffer)`. > > Since this is an interface, javac generates a synthetic inner class to capture the `$assertionsDisabled` information. > > This is the only use of assert within default methods in `java.base`. > > I do not think it carries its weight in terms of the loading the generated class, so I suggest we simply remove it. The method already returns when `pos > limit`. > > Trivial cleanup, `noreg-cleanup`. src/java.base/share/classes/java/util/zip/Checksum.java line 108: > 106: int pos = buffer.position(); > 107: int limit = buffer.limit(); > 108: assert (pos <= limit); I assume the intention was to mutation of buffer in another thread. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29466#discussion_r2736781219 From rriggs at openjdk.org Wed Jan 28 14:12:10 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Wed, 28 Jan 2026 14:12:10 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:56:36 GMT, Naoto Sato wrote: >> This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > +00/-00 offsets tests Looks good. ------------- Marked as reviewed by rriggs (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29393#pullrequestreview-3716922549 From eirbjo at openjdk.org Wed Jan 28 14:17:04 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 14:17:04 GMT Subject: RFR: 8376582: Remove assert from default method in java.util.zip.Checksum interface In-Reply-To: <88sCb4WLA1zQ1BSOkK3srN96d2aKGGpinDun2s7ZDss=.94f4fe6a-c105-42d6-8322-46d79e9f173d@github.com> References: <88sCb4WLA1zQ1BSOkK3srN96d2aKGGpinDun2s7ZDss=.94f4fe6a-c105-42d6-8322-46d79e9f173d@github.com> Message-ID: On Wed, 28 Jan 2026 14:00:58 GMT, Alan Bateman wrote: > I assume the intention was to mutation of buffer in another thread. Right, that would be the only way to reach this state I presume, since Buffer itself seems designed to reject this state when accessed in a thread safe manner? _A buffer's position is never negative and is never greater than its limit_ ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29466#discussion_r2736842829 From eirbjo at openjdk.org Wed Jan 28 14:28:38 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 14:28:38 GMT Subject: RFR: 8376582: Remove assert from default method in java.util.zip.Checksum interface In-Reply-To: References: <88sCb4WLA1zQ1BSOkK3srN96d2aKGGpinDun2s7ZDss=.94f4fe6a-c105-42d6-8322-46d79e9f173d@github.com> Message-ID: On Wed, 28 Jan 2026 14:14:42 GMT, Eirik Bj?rsn?s wrote: > I assume the intention was to mutation of buffer in another thread. Not sure if you are just providing context here or you mean the `assert` is worth keeping. If the latter is the case, I guess we could always code something up manually: // Avoiding assert keyword here to prevent generating nested synthetic class if (pos > limit && Checksum.class.desiredAssertionStatus()) { throw new AssertionError("Concurrent modification of ByteBuffer"); } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29466#discussion_r2736893425 From shade at openjdk.org Wed Jan 28 14:49:41 2026 From: shade at openjdk.org (Aleksey Shipilev) Date: Wed, 28 Jan 2026 14:49:41 GMT Subject: RFR: 8376533: Remove test dependencies on ReferenceQueue$Lock in preparation for JDK-8376477 In-Reply-To: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> References: <4OPEARGcbGpdqoA5LltwYvvfXtgTz_XBvaVydGnKGIc=.199efff1-9306-446c-a3e8-6ddaf7169d7e@github.com> Message-ID: On Tue, 27 Jan 2026 21:11:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which updates a few JDK tests to not depend on the existence of `java.lang.ref.ReferenceQueue$Lock` and `java.lang.Shutdown$Lock` classes. These are suggested for removal in JDK-8376477, see #29442. > > * `ClhsdbInspect` is updated to use add a nested Lock class in the sample app and use that instead. > * `ConcurrentAssociateTest` and `Phaser/Basic` are updated to not use lock name when filtering threads to dump for debugging purposes when failing. > * `ImageReaderBenchmark` micro is updated to remove these classes from the list of expected system image resource names > > I have verified that these tests now run with or without the `Lock` classes present in the JDK. I called the thread dump debug methods manually to verify them since these only run on test failure. GHA run passes. > > Test only change/cleanup. `noreg-self` This looks fine to me. But yes, @plummercj or some other SA maintainer needs to confirm we are good there. ------------- Marked as reviewed by shade (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29455#pullrequestreview-3717115443 From cstein at openjdk.org Wed Jan 28 15:05:31 2026 From: cstein at openjdk.org (Christian Stein) Date: Wed, 28 Jan 2026 15:05:31 GMT Subject: Integrated: 8375433: jar should validate automatic module names In-Reply-To: References: Message-ID: On Tue, 20 Jan 2026 12:36:54 GMT, Christian Stein wrote: > Please review this change to make `jar --validate` check an automatic module name given in a manifest file, via the `Automatic-Module-Name` attribute. > > Prior to this commit, a `MANFEST.MF` reading > > Automatic-Module-Name: default > > added into a JAR file named `a.jar` would not fail when passed to `jar --validate --file a.jar`. However, it does fail when the JAR file is put on the module path of the Java launcher. For example: > > $ java --module-path a.jar --describe-module default > > Error occurred during initialization of boot layer > java.lang.module.FindException: Unable to derive module descriptor for a.jar > Caused by: java.lang.module.FindException: Automatic-Module-Name: default: Invalid module name: 'default' is not a Java identifier > > > With this change applied, `jar --validate --file a.jar` will print an error message and return a non-zero exit value: > > > invalid module name of Automatic-Module-Name entry in manifest: default > > > The new check also fails for when the module name of a compiled module descriptor differs from the value given in the manifest file of the same JAR file. This pull request has now been integrated. Changeset: 8095e33e Author: Christian Stein URL: https://git.openjdk.org/jdk/commit/8095e33ee88759cf2fbe61e2284d95f6b7fb9a3a Stats: 89 lines in 3 files changed: 80 ins; 6 del; 3 mod 8375433: jar should validate automatic module names Reviewed-by: jvernee ------------- PR: https://git.openjdk.org/jdk/pull/29316 From dfenacci at openjdk.org Wed Jan 28 16:10:53 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:10:53 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v4] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with five additional commits since the last revision: - JDK-8374582: fix indent - JDK-8374582: constant - JDK-8374582: add size_of - JDK-8374852: OpaqueCheck -> OpaqueConstantBool - JDK-8374852: fix number of OpaqueCheck nodes in test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/0ef73ef9..a3690526 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=02-03 Stats: 162 lines in 16 files changed: 60 ins; 60 del; 42 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Wed Jan 28 16:10:57 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:10:57 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 08:13:23 GMT, Christian Hagedorn wrote: >> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8374852: fix star layout >> >> Co-authored-by: Christian Hagedorn > > src/hotspot/share/opto/opaquenode.hpp line 146: > >> 144: // builds, we keep the actual checks as additional verification code (i.e. removing OpaqueCheckNodes and use the >> 145: // BoolNode inputs instead). >> 146: class OpaqueCheckNode : public Node { > > I've also thought about the name. `OpaqueCheck` is already a good indication what the node is about. Maybe we could go a step further and call it `OpaqueConstantBoolNode` to emphasize more that it is belonging to a `BoolNode` whose result we already know. What do you think? > > Then we could also think about changing `_positive` to `_constant` (still can be a boolean to just pass true and false which seems more intuitive then passing in 1 and 0). I was still had a doubt about what to put first (`Constant` or `Bool`) but I think `ConstantBool` is actually more correct. I suppose `_constant` is better than `_value` since we use it already ? Done. > src/hotspot/share/opto/opaquenode.hpp line 148: > >> 146: class OpaqueCheckNode : public Node { >> 147: private: >> 148: bool _positive; > > Now that we define a field, we also need to override `size_of()` (see for example `OpaqueMultiversioningNode`). Good to know. Thanks! > src/hotspot/share/opto/opaquenode.hpp line 150: > >> 148: bool _positive; >> 149: public: >> 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { > > `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737356877 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737353309 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2737355777 From alanb at openjdk.org Wed Jan 28 16:15:25 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 28 Jan 2026 16:15:25 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases Message-ID: JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. A summary of the changes: - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state - Thread::getStackTrace is changed to use async_get_stack_trace for all cases - The SUSPENDED substate in VirtualThread is removed - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. ------------- Commit messages: - Cleanup - Merge branch 'master' into Thread.getStackTrace - Initial commit Changes: https://git.openjdk.org/jdk/pull/29461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376568 Stats: 656 lines in 19 files changed: 445 ins; 168 del; 43 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From dfenacci at openjdk.org Wed Jan 28 16:23:21 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Wed, 28 Jan 2026 16:23:21 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374582: fix comment layout - JDK-8374582: fix constructor argument name ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/a3690526..bddec5b5 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=03-04 Stats: 10 lines in 1 file changed: 0 ins; 0 del; 10 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From psandoz at openjdk.org Wed Jan 28 16:45:25 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 28 Jan 2026 16:45:25 GMT Subject: RFR: 8370691: Add new Float16Vector type and enable intrinsification of vector operations supported by auto-vectorizer [v17] In-Reply-To: References: Message-ID: <6-fyVKW-u3b6Bmm1FAhe7gMzlxOqr9wVwzk-FWXvR8s=.db3b9aa0-87f2-4861-b282-d198fc5ae543@github.com> On Tue, 27 Jan 2026 18:25:25 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 34 commits: >> >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Clanups >> - Refactoring vectorIntrinsics >> - Refactoring and cleanups >> - Refactoring and cleanups >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - Adding testpoint for JDK-8373574 >> - Review comments resolutions >> - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8370691 >> - ... and 24 more: https://git.openjdk.org/jdk/compare/0f1b96a5...ce5768fa > >> We will still need to create T_FLOAT16 basic type and associate it with Float16 LaneType, why not directly pass these basic types to intrinsic entry point ? > > The strong feedback from HotSpot folks, which i agree with, is adding a new enum value to `BasicType` is not the way to go - it is too disruptive and does not scale. Sorry if i misled you earlier on, it was my intention in feedback to propose something that was limited in scope to vector support. > > The thought about a proxy class was motivated by a question i had - what would we do if `Float16.class` was already present in `java.base`? and answers to that might motivate what we do now in preparation for when that happens. Regardless i think we need to separate out the Vector API's direct dependence on BasicType and its values. Instead we should define our own constants for the vector element types, and provide mapping of those to BasicType values which might result in "erasure" to the carrier type. We should adjust/adapt LaneType accordingly. Does that make sense to you? > Hi @PaulSandoz , Yes this looks good to me, I have modified the patch accordingly. Thanks, i think this is much better, more localized. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28002#issuecomment-3812429459 From psandoz at openjdk.org Wed Jan 28 17:23:18 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Wed, 28 Jan 2026 17:23:18 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: <2oY0tq0dzrbhoMHy9v68f39P5VAgld8bAsE_rrd6m5U=.229ab632-1e4a-4d43-94e5-491b4c1448e3@github.com> On Wed, 28 Jan 2026 10:02:53 GMT, Andrew Haley wrote: > > The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. > > But as a reviewer I'm not looking at the IR at all, but at the performance. That's a good point. Where i have concerns is introducing a very large set of vector micro benchmarks in bulk or over time in to the mainline under the `test/micro` directory. Further, i am not very happy with the way we generate the vector API benchmarks by leaning on the unit test harness (of which i am also not so happy about). A better approach might be to generate a benchmark on demand for an operation so it can be verified if needed. I think to do this properly we need to invest some resources, which are limited, at least from my side, and so would require some adjustment in priorities. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3812696618 From naoto at openjdk.org Wed Jan 28 18:05:50 2026 From: naoto at openjdk.org (Naoto Sato) Date: Wed, 28 Jan 2026 18:05:50 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v7] In-Reply-To: References: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> Message-ID: On Tue, 27 Jan 2026 13:53:37 GMT, Tatsunori Uchino wrote: > Do we need to remove or preserve `Character.codePointCount(char[])`? I think it's inconsistent to have codePointCount(char[]) and codePointCount(CharSequence, int, int) but not codePointCount(CharSequence). We may need to update the CSR. I would rather focus on addressing the use case, not pursuing the consistency. I would not introduce any methods on Character, and just have CharSequence.codePointCount() (and its implementations) for this PR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3812935919 From vyazici at openjdk.org Wed Jan 28 19:06:27 2026 From: vyazici at openjdk.org (Volkan Yazici) Date: Wed, 28 Jan 2026 19:06:27 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 16:23:21 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8374582: fix comment layout > - JDK-8374582: fix constructor argument name Copyright years don't point to 2026 for the following touched files: src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp src/hotspot/cpu/riscv/c2_MacroAssembler_riscv.cpp src/hotspot/cpu/x86/macroAssembler_x86.cpp src/hotspot/share/classfile/vmIntrinsics.hpp src/hotspot/share/opto/classes.hpp src/hotspot/share/opto/escape.cpp src/hotspot/share/opto/library_call.cpp src/hotspot/share/opto/library_call.hpp src/hotspot/share/opto/loopTransform.cpp src/hotspot/share/opto/loopopts.cpp src/hotspot/share/opto/macro.cpp src/hotspot/share/opto/node.hpp src/hotspot/share/opto/opaquenode.cpp src/hotspot/share/opto/opaquenode.hpp src/hotspot/share/opto/split_if.cpp src/java.base/share/classes/java/lang/String.java src/java.base/share/classes/java/lang/StringCoding.java src/java.base/share/classes/java/lang/System.java src/java.base/share/classes/jdk/internal/access/JavaLangAccess.java src/java.base/share/classes/sun/nio/cs/CESU_8.java src/java.base/share/classes/sun/nio/cs/DoubleByte.java src/java.base/share/classes/sun/nio/cs/ISO_8859_1.java src/java.base/share/classes/sun/nio/cs/SingleByte.java src/java.base/share/classes/sun/nio/cs/US_ASCII.java src/java.base/share/classes/sun/nio/cs/UTF_8.java src/jdk.charsets/share/classes/sun/nio/cs/ext/EUC_JP.java.template test/hotspot/jtreg/compiler/escapeAnalysis/TestCanReduceCheckUsersDifferentIfs.java test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java test/hotspot/jtreg/compiler/unsafe/OpaqueAccesses.java ------------- PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3718529560 From liach at openjdk.org Wed Jan 28 20:19:40 2026 From: liach at openjdk.org (Chen Liang) Date: Wed, 28 Jan 2026 20:19:40 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v7] In-Reply-To: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> References: <3Mtp1GkFexGb5k5VDb8pUuSrrJmu2cZRaa9fZQTLMZI=.52182522-c1f5-40a1-8a2d-186b0c8ea587@github.com> Message-ID: On Tue, 27 Jan 2026 11:33:21 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 one additional commit since the last revision: > > Replace "unpaired surrogates" with "isolated surrogate code units" > > https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 > https://www.unicode.org/charts/PDF/UDC00.pdf I think we can remove `Character.codePointCount(char[])`: users can use `CharBuffer.wrap(char[]).codePointCount()` instead. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3813712436 From pchilanomate at openjdk.org Wed Jan 28 20:59:12 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Wed, 28 Jan 2026 20:59:12 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:35:00 GMT, Alan Bateman wrote: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Nice cleanup, looks good to me. src/hotspot/share/classfile/javaClasses.cpp line 1914: > 1912: > 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); > 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); Suggestion: assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); src/hotspot/share/classfile/javaClasses.cpp line 1944: > 1942: > 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); > 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); The extra `java_thread != nullptr` should not be necessary. ------------- PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3719083411 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2738545829 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2738566963 From eirbjo at openjdk.org Wed Jan 28 21:48:27 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Wed, 28 Jan 2026 21:48:27 GMT Subject: RFR: 8376582: Remove assert from default method in java.util.zip.Checksum interface In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 13:46:39 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which removes an `assert` from the default method `Checksum::update(ByteBuffer)`. > > Since this is an interface, javac generates a synthetic inner class to capture the `$assertionsDisabled` information. > > This is the only use of assert within default methods in `java.base`. > > I do not think it carries its weight in terms of the loading the generated class, so I suggest we simply remove it. The method already returns when `pos > limit`. > > Trivial cleanup, `noreg-cleanup`. I raised a question on `compiler-dev` about why these nested classes need to be eagerly i by the interface: https://mail.openjdk.org/pipermail/compiler-dev/2026-January/032669.html Perhaps we could defer initialization until execution of the asserting bytecode. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29466#issuecomment-3814094705 From duke at openjdk.org Wed Jan 28 23:05:55 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:05:55 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v8] In-Reply-To: References: Message-ID: <_MAwK_d-zDhdmZ7N7BAdUfvFktIp4wqWCB5qndtLiKI=.8adf2f88-8d6e-47fe-bfc6-60de6d82b069@github.com> > 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 one additional commit since the last revision: Fix JavaDoc of `AbstractStringBuilder::codePointCount` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/471b4308..a26398c9 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=06-07 Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Wed Jan 28 23:15:49 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:15:49 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 19:33:10 GMT, Chen Liang wrote: >> 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())` > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 539: > >> 537: * @return the number of Unicode code points in this String >> 538: * @since 26 >> 539: */ > > Suggestion: > > /** > * @since 27 > */ Why did you strip the JSDoc? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2738998166 From jlu at openjdk.org Wed Jan 28 23:23:26 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 28 Jan 2026 23:23:26 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v3] In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: <697SfDDB0DmErmt8Ben4am_wgdRfN2yNdR-bf-k4miY=.7fcc5263-0563-4703-a854-ab6505b79810@github.com> > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit Justin Lu has updated the pull request incrementally with six additional commits since the last revision: - TEST.properties eof newlines - java/sql tests no longer require junit subdir - Move drivermanager tests together - javax/sql tests no longer require junit subdir - Move resourcebundle tests together - Migrate the javax/sql/rowset/serial/ tests to JUnit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29354/files - new: https://git.openjdk.org/jdk/pull/29354/files/06098254..e80ad61a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=01-02 Stats: 224 lines in 108 files changed: 50 ins; 143 del; 31 mod Patch: https://git.openjdk.org/jdk/pull/29354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29354/head:pull/29354 PR: https://git.openjdk.org/jdk/pull/29354 From duke at openjdk.org Wed Jan 28 23:25:30 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:25:30 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v9] In-Reply-To: References: Message-ID: > 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 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: Remove `Character.codePointCount()` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/a26398c9..c9719d4e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=07-08 Stats: 26 lines in 3 files changed: 0 ins; 23 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Wed Jan 28 23:28:38 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:28:38 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v9] In-Reply-To: References: Message-ID: <4gihcQXdppCsDHfrXcO21Iu8PfRKO9LgkbWGvOQoxa8=.2e1ae2f8-1fbe-4e2f-a48e-273cdcd48204@github.com> On Wed, 28 Jan 2026 23:25:30 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 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: > > Remove `Character.codePointCount()` I eliminated the _latest_ commit that has only change like trash. Sorry for the force-push. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3814452281 From jlu at openjdk.org Wed Jan 28 23:29:43 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 28 Jan 2026 23:29:43 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v4] In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit Justin Lu has updated the pull request incrementally with one additional commit since the last revision: Another occurrence of eof newline required ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29354/files - new: https://git.openjdk.org/jdk/pull/29354/files/e80ad61a..18b55f57 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29354&range=02-03 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29354.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29354/head:pull/29354 PR: https://git.openjdk.org/jdk/pull/29354 From jlu at openjdk.org Wed Jan 28 23:34:39 2026 From: jlu at openjdk.org (Justin Lu) Date: Wed, 28 Jan 2026 23:34:39 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v4] In-Reply-To: References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Wed, 28 Jan 2026 23:29:43 GMT, Justin Lu wrote: >> Please review this PR which converts the JDBC TestNG tests to use JUnit. >> >> This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. >> >> Framework test stats before: >> 680 = 680 TestNG + 0 JUnit >> >> Framework test stats after: >> 680 = 0 TestNG + 680 JUnit > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Another occurrence of eof newline required After the latest batch of commits, all tests under _java/sql_ and _javax/sql_ are now JUnit based tests. The respective _junit_ subdirs were removed as well, and all tests were consolidated. Regarding java/sql, https://github.com/openjdk/jdk/pull/29354/changes/a7fed7af952e61e62cd80b3526d3e100249c1f53 grouped _test/jdk/java/sql/driverModuleTests/DriverManagerModuleTests.java_ and _test/jdk/java/sql/junit/test/sql/othervm/DriverManagerInitTests.java_ under a new _drivermanager_ folder and removed the previous _othervm_ folder. (Those test are still run in othervm mode as configured by their TEST.properties). Regarding javax/sql, - https://github.com/openjdk/jdk/pull/29354/changes/a32e4141fbcebf3cc29d6e359c219c8ed9ef009b converted and moved the contents of the non JUnit tests under _test/jdk/javax/sql/rowset/serial/_ into the existing JUnit tests under _test/jdk/javax/sql/test/rowset/serial/_. - https://github.com/openjdk/jdk/pull/29354/changes/4118f44f60928261b33207b5ea0f4d7630264a91 grouped _test/jdk/javax/sql/resourceBundleTests/ValidateGetBundle.java_ and _test/jdk/javax/sql/junit/test/rowset/ValidateResourceBundleAccess.java_ into their own respective _resourcebundle_ folder. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29354#issuecomment-3814482975 From duke at openjdk.org Wed Jan 28 23:34:56 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:34:56 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v10] In-Reply-To: References: Message-ID: <0x9Cl2x8qYLGAs5_rMBy4NYd8NhmXMPBjiK0foy5E14=.54b69e8d-49a6-4036-bcfe-1764c3e48c34@github.com> > 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 one additional commit since the last revision: Fix double empty lines ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/c9719d4e..4f80009e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Wed Jan 28 23:40:14 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:40:14 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: References: Message-ID: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com> > 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 one additional commit since the last revision: Update year in copyright ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/4f80009e..2cf8f448 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=09-10 Stats: 7 lines in 7 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Wed Jan 28 23:58:55 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 28 Jan 2026 23:58:55 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com> References: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com> Message-ID: On Wed, 28 Jan 2026 23:40:14 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 one additional commit since the last revision: > > Update year in copyright "Create sysroot" fails: s390x: Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg I: Retrieving InRelease E: Invalid Release file, no entry for main/binary-s390x/Packages Error: Process completed with exit code 1. ppc64le: Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg I: Retrieving InRelease E: Invalid Release file, no entry for main/binary-ppc64el/Packages Error: Process completed with exit code 1. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3814551416 From liach at openjdk.org Thu Jan 29 00:54:11 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 00:54:11 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 23:13:04 GMT, Tatsunori Uchino wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 539: >> >>> 537: * @return the number of Unicode code points in this String >>> 538: * @since 26 >>> 539: */ >> >> Suggestion: >> >> /** >> * @since 27 >> */ > > Why did you strip the JSDoc? By default the docs will be inherited from `CharSequence` except the `@throws` tags. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2739264010 From erfang at openjdk.org Thu Jan 29 01:41:06 2026 From: erfang at openjdk.org (Eric Fang) Date: Thu, 29 Jan 2026 01:41:06 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 10:02:53 GMT, Andrew Haley wrote: >> The general way code flows right now, but not often, is from jdk/master to panama-vector/vectorIntrinsics, since most of the development work is in the mainline (exceptions to that are the float16 and Valhalla alignment work which are large efforts). >> >> I am very reluctant to include all the auto-generated micro benchmarks in mainline. There is a huge number of them and i am not certain they provide as much value as they did now we have the IR test framework. In may cases, given the simplicity of what they measure, they were designed to ensure C2 generates the right instructions. The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. >> >> The IR test framework is of course no substitute, in general, for performance tests. A better focus for Vector API performance tests is i think Emanuel's work [here](https://github.com/openjdk/jdk/pull/28639/) and use-cases/algorithms that can be implemented concisely. > >> The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. > > But as a reviewer I'm not looking at the IR at all, but at the performance. Hi @theRealAph @PaulSandoz , thanks for your insight! How to synchronize the JMH micro benchmarks between Panama and the mainline may be a more general issue that requires further investigation, design, and resources. As for how to move this PR forward, my idea is to write a new micro benchmark in this PR to demonstrate the optimization effect of this patch. Would that be acceptable to you? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3814866131 From syan at openjdk.org Thu Jan 29 02:42:07 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 29 Jan 2026 02:42:07 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out Message-ID: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Hi all, Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invode cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. Change has been verifed locally. The imtermittent timed out do not observed anymore. ------------- Commit messages: - 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out Changes: https://git.openjdk.org/jdk/pull/29478/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29478&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376630 Stats: 32 lines in 1 file changed: 21 ins; 0 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29478.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29478/head:pull/29478 PR: https://git.openjdk.org/jdk/pull/29478 From duke at openjdk.org Thu Jan 29 03:43:24 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 03:43:24 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 00:51:21 GMT, Chen Liang wrote: >> Why did you strip the JSDoc? > > By default the docs will be inherited from `CharSequence` except the `@throws` tags. I see. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2739776799 From duke at openjdk.org Thu Jan 29 03:51:15 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 03:51:15 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v12] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Don't use removed `Character::codePointCount` overload ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/2cf8f448..5df93771 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=10-11 Stats: 6 lines in 2 files changed: 0 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From dholmes at openjdk.org Thu Jan 29 04:15:35 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:15:35 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 02:35:23 GMT, SendaoYan wrote: > Hi all, > > Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. > > This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invode cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. > > Change has been verifed locally. The imtermittent timed out do not observed anymore. @sendaoYan we don't see this test timeout but we do see it fail - see [JDK-8375585](https://bugs.openjdk.org/browse/JDK-8375585). The test was just added to the ProblemList. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3815399332 From dholmes at openjdk.org Thu Jan 29 04:24:16 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:24:16 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:54:35 GMT, Patricio Chilano Mateo wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/classfile/javaClasses.cpp line 1944: > >> 1942: >> 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); >> 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); > > The extra `java_thread != nullptr` should not be necessary. What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739888377 From dholmes at openjdk.org Thu Jan 29 04:59:48 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:59:48 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 09:35:00 GMT, Alan Bateman wrote: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. I've taken a pass through this. Great to see all the cleanup and simplification but unless you know the detailed back-story here it is difficult to understand some of the changes (or even some of the code that hasn't changed). src/hotspot/share/services/threadService.cpp line 1479: > 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { > 1478: return nullptr; > 1479: } It is not obvious to me why this is only a possibility now? src/hotspot/share/services/threadService.cpp line 1509: > 1507: > 1508: // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace) > 1509: // to properly initialize STEs. Why can this be removed? src/java.base/share/classes/java/lang/StackTraceElement.java line 578: > 576: } > 577: > 578: static StackTraceElement[] finishInit(StackTraceElement[] stackTrace) { Out of curiousity what does this actually do, and why do we need it? src/java.base/share/classes/java/lang/Thread.java line 2218: > 2216: } > 2217: Object trace = getStackTrace0(); > 2218: if (trace instanceof StackTraceElement[] stackTrace) { What can this return other than a `StackTraceElement[]` ?? src/java.base/share/classes/jdk/internal/vm/ThreadSnapshot.java line 65: > 63: ThreadSnapshot snapshot = create(thread); > 64: if (snapshot == null) { > 65: return null; // thread not alive I can understand that you might call this on a thread that terminates before the operation can be performed. But not-alive implies NEW threads too and I would have expected NEW threads to be filtered out long before we get here. test/micro/org/openjdk/bench/java/lang/ThreadGetStackTraceWhenParked.java line 2: > 1: /* > 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. Are these "new" test files from the Loom repo? ------------- PR Review: https://git.openjdk.org/jdk/pull/29461#pullrequestreview-3720632723 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739903913 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739905261 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739932529 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739914245 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739919446 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739928137 From dholmes at openjdk.org Thu Jan 29 04:59:50 2026 From: dholmes at openjdk.org (David Holmes) Date: Thu, 29 Jan 2026 04:59:50 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 20:48:26 GMT, Patricio Chilano Mateo wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/classfile/javaClasses.cpp line 1914: > >> 1912: >> 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); >> 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); > > Suggestion: > > assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); FWIW the same "shape" assert is in threadService.cpp ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2739949321 From jpai at openjdk.org Thu Jan 29 06:43:16 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 Jan 2026 06:43:16 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 02:35:23 GMT, SendaoYan wrote: > because lsof invoke huast lots of time when the tested machine has many processes, and the processes open too many files. More of a FYI - Some version(s) of `lsof` are known to take extremely long time when launched from within some other process. That issue has been addressed in newer versions of lsof https://github.com/lsof-org/lsof/issues/328. We had noticed a similar issue with `lsof` when investigating a test timeout in https://bugs.openjdk.org/browse/JDK-8347001?focusedId=14814531&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14814531. It's possible that the system where this test is timing out for @sendaoYan may have this same problem. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3815788739 From jbhateja at openjdk.org Thu Jan 29 07:25:03 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 07:25:03 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries Message-ID: As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. Patch add new lane type constants and pass them to vector intrinsic entry points. All existing Vector API jtreg test are passing with the patch. Kindly review and share your feedback. Best Regards, Jatin ------------- Commit messages: - [VectorAPI] Define new lane type constants and pass them to intrinsic entries Changes: https://git.openjdk.org/jdk/pull/29481/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376187 Stats: 1744 lines in 52 files changed: 192 ins; 79 del; 1473 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From dfenacci at openjdk.org Thu Jan 29 07:32:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 07:32:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v6] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci 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 31 additional commits since the last revision: - JDK-8374582: merge and update copyright year - Merge branch 'master' into JDK-8374582 - Merge branch 'master' into JDK-8374582 - JDK-8374582: fix comment layout - JDK-8374582: fix constructor argument name - JDK-8374582: fix indent - JDK-8374582: constant - JDK-8374582: add size_of - JDK-8374852: OpaqueCheck -> OpaqueConstantBool - JDK-8374852: fix number of OpaqueCheck nodes in test - ... and 21 more: https://git.openjdk.org/jdk/compare/7e545381...a587a269 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/bddec5b5..a587a269 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=04-05 Stats: 61562 lines in 1281 files changed: 34520 ins; 12116 del; 14926 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Thu Jan 29 07:32:12 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 07:32:12 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v5] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 19:03:23 GMT, Volkan Yazici wrote: > Copyright years don't point to 2026 for the following touched files: Right! Fixed. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3815950950 From qamai at openjdk.org Thu Jan 29 08:13:59 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 08:13:59 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 07:16:35 GMT, Jatin Bhateja wrote: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin src/hotspot/share/prims/vectorSupport.hpp line 140: > 138: }; > 139: > 140: enum { Please use a scoped enum instead. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740433980 From syan at openjdk.org Thu Jan 29 08:22:05 2026 From: syan at openjdk.org (SendaoYan) Date: Thu, 29 Jan 2026 08:22:05 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 06:40:56 GMT, Jaikiran Pai wrote: > It's possible that the system where this test is timing out for @sendaoYan may have this same problem. This timed out failure only observed on a linux-aarch64 machine, which has older linux kernel version. The lsof version is lsof 4.93.2, which same to ubuntu22. But ubuntu22 do not observed this issue for now on. > cat /etc/os-release NAME="Kylin Linux Advanced Server" VERSION="V10 (Halberd)" ID="kylin" VERSION_ID="V10" PRETTY_NAME="Kylin Linux Advanced Server V10 (Halberd)" ANSI_COLOR="0;31" > uname -a Linux KP57 4.19.90-89.11.v2401.ky10.aarch64 #1 SMP Thu Apr 25 18:20:10 CST 2024 aarch64 aarch64 aarch64 GNU/Linux ------------- PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3816181556 From alanb at openjdk.org Thu Jan 29 09:03:48 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:03:48 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:57:11 GMT, David Holmes wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1914: >> >>> 1912: >>> 1913: bool has_java_thread = tlh.cv_internal_thread_to_JavaThread(jthread, &java_thread, &thread_oop); >>> 1914: assert((has_java_thread && thread_oop != nullptr) || !has_java_thread, "Missing Thread oop"); >> >> Suggestion: >> >> assert(!has_java_thread || thread_oop != nullptr, "Missing Thread oop"); > > FWIW the same "shape" assert is in threadService.cpp Thanks, that is a better assert. We can change the assert in threadService.cpp too. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740604845 From alanb at openjdk.org Thu Jan 29 09:03:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:03:53 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:31:43 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/services/threadService.cpp line 1509: > >> 1507: >> 1508: // call static StackTraceElement[] StackTraceElement.of(StackTraceElement[] stackTrace) >> 1509: // to properly initialize STEs. > > Why can this be removed? All "finishing" is now done in ThreadSnapshort.of(Thread) for all the components (locks, blockers, ...). It previously left the finishing of the stack trace to ThreadSnapshotFactory::get_thread_snapshot, so different to Thread::getStackTrace which has always done the finish in Java code. > src/java.base/share/classes/java/lang/Thread.java line 2218: > >> 2216: } >> 2217: Object trace = getStackTrace0(); >> 2218: if (trace instanceof StackTraceElement[] stackTrace) { > > What can this return other than a `StackTraceElement[]` ?? It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. > test/micro/org/openjdk/bench/java/lang/ThreadGetStackTraceWhenParked.java line 2: > >> 1: /* >> 2: * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > > Are these "new" test files from the Loom repo? Yes (and from 2025). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740608688 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740614233 PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740614537 From smonteith at openjdk.org Thu Jan 29 09:03:47 2026 From: smonteith at openjdk.org (Stuart Monteith) Date: Thu, 29 Jan 2026 09:03:47 GMT Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments allocated with shared arenas. In-Reply-To: References: Message-ID: <5izV9DyV060gChX8G_D1BvaYq6AJ2u9abAH8HmSIMKU=.a903cdd2-ec1c-4d4d-8c87-6dac4a8e32a8@github.com> On Tue, 27 Jan 2026 16:54:45 GMT, Jorn Vernee wrote: > Sorry this is taking a while to review. I have been swamped since the start of the year. I want to give this patch the time it deserves, but that also means it's not possible to squeeze in the review between other things Thanke @JornVernee , appreciated. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3816372109 From epeter at openjdk.org Thu Jan 29 09:04:53 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Thu, 29 Jan 2026 09:04:53 GMT Subject: RFR: 8371955: Support AVX10 floating point comparison instructions [v9] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 19:02:44 GMT, Mohamed Issa wrote: >> Intel® AVX10 ISA [1] extensions added new floating point comparison instructions. They set the EFLAGS register so that relationships can be tested independently to avoid extra checks when one of the inputs is NaN. >> >> Most of the work is covered in the architecture definition (`x86.ad`) file. A new comparison operand was created to be used by new CMove and JMP definitions with the APX specific portions of the CMove section being updated to rely on the new instructions because both sets of instructions are always expected to be available on the same platform. New floating point comparison definitions were also added. >> >> This change uses the new AVX10.2 (UCOMXSS or UCOMXSD) instructions on supported platforms to avoid the extra handling required with existing (UCOMISS or UCOMISD) instructions. To make sure no new failures were introduced, tier1, tier2, and tier3 tests were run on builds with and without the changes. Additionally, the JTREG tests listed below were used to verify correctness with `-XX:-UseAPX` / `-XX:+UseAPX` options. The baseline build used is [OpenJDK v26-b26](https://github.com/openjdk/jdk/releases/tag/jdk-26%2B26). >> >> 1. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/CMoveLConstants.java` >> 2. `jtreg:test/hotspot/jtreg/compiler/c2/irTests/TestFPComparison.java` >> 3. `jtreg:test/hotspot/jtreg/compiler/intrinsics/math/TestSignumIntrinsic.java` >> 4. `jtreg:test/hotspot/jtreg/compiler/vectorization/TestSignumVector.java` >> >> Finally, the JMH micro-benchmark listed below was updated to separately exercise CMove and JMP code paths. >> >> 1. `micro:test/micro/org/openjdk/bench/java/lang/FPComparison.java` >> >> [1] https://www.intel.com/content/www/us/en/content-details/856721/intel-advanced-vector-extensions-10-2-intel-avx10-2-architecture-specification.html?wapkw=AVX10 > > Mohamed Issa has updated the pull request incrementally with one additional commit since the last revision: > > Add double precision test to CMoveLConstants.java FYI: testing launched ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28337#issuecomment-3816377081 From jbhateja at openjdk.org Thu Jan 29 09:04:53 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 09:04:53 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 08:09:36 GMT, Quan Anh Mai wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > src/hotspot/share/prims/vectorSupport.hpp line 140: > >> 138: }; >> 139: >> 140: enum { > > Please use a scoped enum instead. Its contained in VectorSupport class which makes it implicitly scoped. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740618259 From alanb at openjdk.org Thu Jan 29 09:08:53 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:08:53 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: <5yJEl4AoQCIk6otjuEKfbtcLJ3cGBWcF3qasy-9ts7Y=.966925dc-f747-4e50-82c3-c0f544139796@github.com> On Thu, 29 Jan 2026 04:47:55 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/java.base/share/classes/java/lang/StackTraceElement.java line 578: > >> 576: } >> 577: >> 578: static StackTraceElement[] finishInit(StackTraceElement[] stackTrace) { > > Out of curiousity what does this actually do, and why do we need it? The format depends on whether the class loader has a name and other complexity as to whether a module version is included. Nothing has changed, only the name of the method to finish the initialization. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740630911 From qamai at openjdk.org Thu Jan 29 09:10:55 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 09:10:55 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:02:29 GMT, Jatin Bhateja wrote: >> src/hotspot/share/prims/vectorSupport.hpp line 140: >> >>> 138: }; >>> 139: >>> 140: enum { >> >> Please use a scoped enum instead. > > Its contained in VectorSupport class which makes it implicitly scoped for external uses without being a named (scoped) enum I mean an `enum class`. With this we just pass `int` around which is not recommended. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2740638154 From alanb at openjdk.org Thu Jan 29 09:15:36 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 09:15:36 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:30:46 GMT, David Holmes wrote: >> JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. >> >> A summary of the changes: >> >> - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state >> - Thread::getStackTrace is changed to use async_get_stack_trace for all cases >> - The SUSPENDED substate in VirtualThread is removed >> - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in >> - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace >> >> The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. >> >> A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. >> >> Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. > > src/hotspot/share/services/threadService.cpp line 1479: > >> 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { >> 1478: return nullptr; >> 1479: } > > It is not obvious to me why this is only a possibility now? ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2740654504 From jbhateja at openjdk.org Thu Jan 29 09:43:30 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 09:43:30 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolution ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/ef96506d..11021544 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=00-01 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From aartemov at openjdk.org Thu Jan 29 09:58:47 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 09:58:47 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v4] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java - 8375285: Added versions. - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. - 8375285: Addressed the reviewer's comments. - 8375285: Port of fdlibm asinh function ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29273/files - new: https://git.openjdk.org/jdk/pull/29273/files/ed1d4d3c..0455b1e2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=02-03 Stats: 52703 lines in 1160 files changed: 27873 ins; 10410 del; 14420 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From duke at openjdk.org Thu Jan 29 10:16:18 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 10:16:18 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v13] In-Reply-To: References: Message-ID: <8LAUF2YRcQ2lzYfhuAf9CN91Yw02rwx89dh3aNSEw-Y=.a17a103e-82ec-430a-a0e8-008f352fa9c5@github.com> > 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 one additional commit since the last revision: Fix comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/5df93771..8835ab3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=12 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=11-12 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From jpai at openjdk.org Thu Jan 29 10:21:25 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 Jan 2026 10:21:25 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v6] In-Reply-To: References: Message-ID: <5K3QplZHL8hWIrPPOk1iRFVrvtVR5yBRkkYFv4i0xCU=.9f851648-7359-41bf-9320-63e56147ae39@github.com> > 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... Jaikiran Pai 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 nine additional commits since the last revision: - Stuart's review - no need to write start time in a file - merge latest from master branch - merge latest from master branch - merge latest from master branch - Mark's suggestion - move the duration check to separate method - merge latest from master branch - Mark's review - use CountDownLatch - merge latest from master branch - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/932520b9..2cf95537 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=04-05 Stats: 18586 lines in 524 files changed: 8004 ins; 3592 del; 6990 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 jpai at openjdk.org Thu Jan 29 10:27:56 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 Jan 2026 10:27:56 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v6] In-Reply-To: <5K3QplZHL8hWIrPPOk1iRFVrvtVR5yBRkkYFv4i0xCU=.9f851648-7359-41bf-9320-63e56147ae39@github.com> References: <5K3QplZHL8hWIrPPOk1iRFVrvtVR5yBRkkYFv4i0xCU=.9f851648-7359-41bf-9320-63e56147ae39@github.com> Message-ID: <15VbURLxrSteSR3dOlZxhT5wk5c0pBGLN6jkXQzNuoc=.d65ed2de-50cc-44da-8534-072a8f125af4@github.com> On Thu, 29 Jan 2026 10:21:25 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 continue... > > Jaikiran Pai 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 nine additional commits since the last revision: > > - Stuart's review - no need to write start time in a file > - merge latest from master branch > - merge latest from master branch > - merge latest from master branch > - Mark's suggestion - move the duration check to separate method > - merge latest from master branch > - Mark's review - use CountDownLatch > - merge latest from master branch > - 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds Thank you Stuart for the review. > The observation is that the timeout logic is entirely within the parent JVM. The child's role is simply to obtain a lease and halt immediately. The parent JVM could be changed to call JavaVM.waitFor() to await the child's termination and to obtain a timestamp. This would remove the need to create a temporary file into which the child writes a timestamp from which the parent reads the timestamp. In addition, waitFor() allows the parent to check the child's exit status and signal an error if the status is nonzero. > > I guess one could argue that having the child obtain the timestamp immediately after the registry call is closer to the beginning of the actual lease. However, I don't think this makes much of a practical difference. What you suggest is reasonable and simpler as well. I've updated the PR to remove the part where we used to write the start time to a file and then read it. With the updated log messages in this PR, I think if this continues to fail intermittently, we will have some useful log messages which can then help us decide if we have to track the start time more closely in the SelfTerminator process. > Another small cleanup item: is it necessary to have a @modules declaration in the test? I don't see anything in the test that uses RMI internals. (The Test Library might need this stuff, though, not sure.) I gave that a try, but turns out the call to a test library class in this test: > TestLibrary.getRegistryPort(localRegistry); requires the use of these explicit "--add-exports" (through the `@modules`) because `TestLibrary` references those internal classes. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28919#issuecomment-3816774725 From aph at openjdk.org Thu Jan 29 10:32:29 2026 From: aph at openjdk.org (Andrew Haley) Date: Thu, 29 Jan 2026 10:32:29 GMT Subject: RFR: 8372980: [VectorAPI] AArch64: Add intrinsic support for unsigned min/max reduction operations [v4] In-Reply-To: References: Message-ID: On Wed, 28 Jan 2026 10:02:53 GMT, Andrew Haley wrote: >> The general way code flows right now, but not often, is from jdk/master to panama-vector/vectorIntrinsics, since most of the development work is in the mainline (exceptions to that are the float16 and Valhalla alignment work which are large efforts). >> >> I am very reluctant to include all the auto-generated micro benchmarks in mainline. There is a huge number of them and i am not certain they provide as much value as they did now we have the IR test framework. In may cases, given the simplicity of what they measure, they were designed to ensure C2 generates the right instructions. The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. >> >> The IR test framework is of course no substitute, in general, for performance tests. A better focus for Vector API performance tests is i think Emanuel's work [here](https://github.com/openjdk/jdk/pull/28639/) and use-cases/algorithms that can be implemented concisely. > >> The IR test framework is better at determining that by testing the right IR nodes are generated - and they get run as part of the existing HotSpot test suite. > > But as a reviewer I'm not looking at the IR at all, but at the performance. > Hi @theRealAph @PaulSandoz , thanks for your insight! How to synchronize the JMH micro benchmarks between Panama and the mainline may be a more general issue that requires further investigation, design, and resources. As for how to move this PR forward, my idea is to write a new micro benchmark in this PR to demonstrate the optimization effect of this patch. Would that be acceptable to you? Sure. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28693#issuecomment-3816786645 From aturbanov at openjdk.org Thu Jan 29 10:32:31 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Thu, 29 Jan 2026 10:32:31 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:58:47 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a port of FDLIBM asinh method. >> >> Original C vs transliteration port: >> >> >> $ diff -w fdlib_asinh.c Asinh.translit.java >> 1c1,3 >> < /* asinh(x) >> --- >>> /** >>> * Return the Inverse Hyperbolic Sine of x >>> * >> 2a5 >>> * >> 10a14,17 >>> private static final class Asinh { >>> private static final double one = 1.0; >>> private static final double ln2 = 6.93147180559945286227e-01; >>> private static final double huge = 1.0e300; >> 12,29c19 >> < #include "fdlibm.h" >> < >> < #ifdef __STDC__ >> < static const double >> < #else >> < static double >> < #endif >> < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ >> < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ >> < huge= 1.00000000000000000000e+300; >> < >> < #ifdef __STDC__ >> < double asinh(double x) >> < #else >> < double asinh(x) >> < double x; >> < #endif >> < { >> --- >>> static double compute(double x) { >> 39c29 >> < w = __ieee754_log(fabs(x))+ln2; >> --- >>> w = log(Math.abs(x))+ln2; >> 41,42c31,32 >> < t = fabs(x); >> < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); >> --- >>> t = Math.abs(x); >>> w = log(2.0*t+one/(sqrt(x*x+one)+t)); >> 45c35 >> < w =log1p(fabs(x)+t/(one+sqrt(one+t))); >> --- >>> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); >> 47a38 >>> } >> >> Transliteration port vs more idiomatic port: >> >> >> $ diff -w Asinh.translit.java Asinh.fdlibm.java >> 6,9c6,12 >> < * Based on >> < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] >> < * we have >> < * asinh(x) := x if 1+x*x=1, >> --- >>> * >>> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >>> * and sinh(asinh(x)) = x, -INF < x < INF. >>> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >>> * 1. Replace x by |x| as the function is odd. >>> * 2. >>> * asinh(x) := x, if 1+x^2 = 1, >> 12a16,22 >>> * >>> * >>> * >>> * Special cases: >>> * only asinh(0)=0 is exact for finite x. >>> * asinh(NaN) is NaN >>> * asinh(INF) is INF >> 14,15c24 >> < private static final class Asinh { >> < private static final double one = 1.0; >> --- >>> static final class Asinh { >> 24c33,35 >> < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ >> --- >>> if(ix >= 0x7ff00000) { >>> return x... > > Anton Artemov has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision: > > - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java > - 8375285: Added versions. > - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. > - 8375285: Addressed the reviewer's comments. > - 8375285: Port of fdlibm asinh function BTW, should issue/PR name be something like "Add asinh() methods to Math and to StrictMath" ? (Similar to https://bugs.openjdk.org/browse/JDK-8301226) I mean main thing we do here - is to introduce new method. Source of original code - is just implementation details. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3816795700 From jpai at openjdk.org Thu Jan 29 10:40:20 2026 From: jpai at openjdk.org (Jaikiran Pai) Date: Thu, 29 Jan 2026 10:40:20 GMT Subject: RFR: 8170896: TEST_BUG: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java failed with unreferenced() not invoked after 20.0 seconds [v7] In-Reply-To: References: 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 te... Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision: print the configured lease expiry time in the test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28919/files - new: https://git.openjdk.org/jdk/pull/28919/files/2cf95537..6c8fe500 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28919&range=05-06 Stats: 3 lines in 1 file changed: 0 ins; 1 del; 2 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 duke at openjdk.org Thu Jan 29 10:47:55 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 10:47:55 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: > 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 with a new target base due to a merge or a rebase. The pull request now contains 20 commits: - Merge remote-tracking branch 'origin/master' into codepoint-count - Fix comments - Don't use removed `Character::codePointCount` overload - Update year in copyright - Fix double empty lines - Remove `Character.codePointCount()` - Replace "unpaired surrogates" with "isolated surrogate code units" https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 https://www.unicode.org/charts/PDF/UDC00.pdf - Remove `Character.codePointCount` overload - Rename parameter names from `a` to `seq` `chars` is too confusing with `char` - Improve JavaDoc Co-authored-by: Chen Liang - ... and 10 more: https://git.openjdk.org/jdk/compare/681e4ec8...198b3188 ------------- Changes: https://git.openjdk.org/jdk/pull/26461/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=13 Stats: 80 lines in 7 files changed: 67 ins; 0 del; 13 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From aartemov at openjdk.org Thu Jan 29 10:57:53 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 10:57:53 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v5] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8375285: Added coma. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29273/files - new: https://git.openjdk.org/jdk/pull/29273/files/0455b1e2..f3766313 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=03-04 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From alanb at openjdk.org Thu Jan 29 11:15:20 2026 From: alanb at openjdk.org (Alan Bateman) Date: Thu, 29 Jan 2026 11:15:20 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <0mAlTvcltJnprgF188hBZ3fJuIUb9OR7YUjGEWyyJo0=.fdeed8d4-a5dd-4185-8809-bbc5ccc4e3ab@github.com> > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Alan Bateman has updated the pull request incrementally with one additional commit since the last revision: Improve asserts ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29461/files - new: https://git.openjdk.org/jdk/pull/29461/files/cb4222e9..12214cd8 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=00-01 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From qamai at openjdk.org Thu Jan 29 11:22:29 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:22:29 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:43:30 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolution src/hotspot/share/prims/vectorSupport.cpp line 202: > 200: } > 201: > 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741153639 From qamai at openjdk.org Thu Jan 29 11:22:31 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:22:31 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:07:54 GMT, Quan Anh Mai wrote: >> Its contained in VectorSupport class which makes it implicitly scoped for external uses without being a named (scoped) enum > > I mean an `enum class`. With this we just pass `int` around which is not recommended. I don't see this gets resolved. My suggestion is to use a scoped enum so we have a strongly typed value instead of using an unscoped enum and passing `int` all over the places. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741147870 From jbhateja at openjdk.org Thu Jan 29 11:39:35 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 11:39:35 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:19:18 GMT, Quan Anh Mai wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolution > > src/hotspot/share/prims/vectorSupport.cpp line 202: > >> 200: } >> 201: >> 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { > > Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. Correct, we are passing an integer laneType from java side to intrinsic entry points. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741207425 From qamai at openjdk.org Thu Jan 29 11:45:33 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:45:33 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:34:51 GMT, Jatin Bhateja wrote: >> src/hotspot/share/prims/vectorSupport.cpp line 202: >> >>> 200: } >>> 201: >>> 202: int VectorSupport::vop2ideal(jint id, BasicType bt) { >> >> Previously, this method accepts a `BasicType`, now it accepts an untyped `int`. > > Correct, we are passing an integer laneType from java side to intrinsic entry points. Please use a separate named type instead of `int`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741235103 From jbhateja at openjdk.org Thu Jan 29 11:50:35 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 11:50:35 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:43:06 GMT, Quan Anh Mai wrote: >> Correct, we are passing an integer laneType from java side to intrinsic entry points. > > Please use a separate named type instead of `int`. It is indeed an integral value which is passed from Java side which is casted to BasicType. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741250148 From qamai at openjdk.org Thu Jan 29 11:56:51 2026 From: qamai at openjdk.org (Quan Anh Mai) Date: Thu, 29 Jan 2026 11:56:51 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 11:47:33 GMT, Jatin Bhateja wrote: >> Please use a separate named type instead of `int`. > > It is indeed an integral value which is passed from Java side which is casted to BasicType. So please cast it in the intrinsics functions in `vectorIntrinsics.cpp` and pass the `LaneType` into this function. static bool is_primitive_lane_type(int laneType) { return laneType >= VectorSupport::LT_FLOAT && laneType <= VectorSupport::LT_LONG; } This function could return a `LaneType` for you. Also, when do we pass in something that is not a valid value? Should this be an `assert`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2741273046 From aartemov at openjdk.org Thu Jan 29 12:01:46 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Thu, 29 Jan 2026 12:01:46 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v6] In-Reply-To: References: Message-ID: > Hi, please consider the following changes: > > This is a port of FDLIBM asinh method. > > Original C vs transliteration port: > > > $ diff -w fdlib_asinh.c Asinh.translit.java > 1c1,3 > < /* asinh(x) > --- >> /** >> * Return the Inverse Hyperbolic Sine of x >> * > 2a5 >> * > 10a14,17 >> private static final class Asinh { >> private static final double one = 1.0; >> private static final double ln2 = 6.93147180559945286227e-01; >> private static final double huge = 1.0e300; > 12,29c19 > < #include "fdlibm.h" > < > < #ifdef __STDC__ > < static const double > < #else > < static double > < #endif > < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ > < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ > < huge= 1.00000000000000000000e+300; > < > < #ifdef __STDC__ > < double asinh(double x) > < #else > < double asinh(x) > < double x; > < #endif > < { > --- >> static double compute(double x) { > 39c29 > < w = __ieee754_log(fabs(x))+ln2; > --- >> w = log(Math.abs(x))+ln2; > 41,42c31,32 > < t = fabs(x); > < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); > --- >> t = Math.abs(x); >> w = log(2.0*t+one/(sqrt(x*x+one)+t)); > 45c35 > < w =log1p(fabs(x)+t/(one+sqrt(one+t))); > --- >> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); > 47a38 >> } > > Transliteration port vs more idiomatic port: > > > $ diff -w Asinh.translit.java Asinh.fdlibm.java > 6,9c6,12 > < * Based on > < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] > < * we have > < * asinh(x) := x if 1+x*x=1, > --- >> * >> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >> * and sinh(asinh(x)) = x, -INF < x < INF. >> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >> * 1. Replace x by |x| as the function is odd. >> * 2. >> * asinh(x) := x, if 1+x^2 = 1, > 12a16,22 >> * >> * >> * >> * Special cases: >> * only asinh(0)=0 is exact for finite x. >> * asinh(NaN) is NaN >> * asinh(INF) is INF > 14,15c24 > < private static final class Asinh { > < private static final double one = 1.0; > --- >> static final class Asinh { > 24c33,35 > < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ > --- >> if(ix >= 0x7ff00000) { >> return x + x; /* x is inf or NaN */ >> } > 26c37,39 > < if(huge+x>one) return x; /* return x inexact except 0... Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: 8375285: Added missed link in documentation. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29273/files - new: https://git.openjdk.org/jdk/pull/29273/files/f3766313..071df0ff Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29273&range=04-05 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/29273.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29273/head:pull/29273 PR: https://git.openjdk.org/jdk/pull/29273 From dfenacci at openjdk.org Thu Jan 29 12:42:44 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Thu, 29 Jan 2026 12:42:44 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v7] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374582: add flagless to test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/a587a269..083d5698 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=05-06 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From ogillespie at openjdk.org Thu Jan 29 12:44:17 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 29 Jan 2026 12:44:17 GMT Subject: RFR: 8372946 - TreeMap sub-map entry spliterator is expensive [v2] In-Reply-To: References: <1rs2gi19pejRoL1x2s069lLUgpotd13cjldAX_RUdnM=.73aaebc7-2019-4f5d-874e-32753cffb501@github.com> <7G6gPB81y-04tNpDEYOfiisYK3yPrtAC0pb6J9FOyl8=.d753fa55-d2ec-41e6-ae05-d012d5a4203a@github.com> Message-ID: On Tue, 27 Jan 2026 20:17:18 GMT, Oli Gillespie wrote: >>> I suppose you mean Spliterators.spliteratorUnknownSize? >> >> Yes. Thanks for corecting me. >> >>> Hmm - I made the change this way to be consistent with the existing SubMapKeyIterator and DescendingSubMapKeyIterator, simply adding the same functionality for the Entry versions. >> >> I made the recommendation given the starting point is to address a performance regression, instead of to enhance the sub-map entry spliterator to be on par with the `DescendingSubMapKeyIterator`. >> >> From this starting point, I believe we can easily identify `EntrySetView` inherits `Set::spliterator` which is slow because the spliterator calls `size()` frequently. This root problem is easily fixed with using `Spliterators.spliteratorUnknownSize`, which also has the minimal behavioral impact. >> >> In contrast, functional enhancement to spliterators is really a can of worms where you can never find an end - sometimes you add more flags, sometimes other splitting strategies. And in your example, you already have a test case failing due to the functional enhancements while you did make new tests to verify them. >> >> So let's keep it simple, fix the bug, and leave the functional enhancements for another time. This also makes backporting the fix much easier. > > Okay sounds good to me! Thanks for the suggestion, I'll update later this week. I created https://github.com/openjdk/jdk/pull/29485 to add test cases before making this change - that required a slight functional tweak so I didn't want to include it in this change. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/28608#discussion_r2741453002 From ogillespie at openjdk.org Thu Jan 29 12:47:49 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 29 Jan 2026 12:47:49 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps Message-ID: Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. Two interesting parts: 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. ------------- Commit messages: - Switch to Objects.requireNonNull - Add tests and fix impl Changes: https://git.openjdk.org/jdk/pull/29485/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29485&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376698 Stats: 30 lines in 2 files changed: 29 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29485.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29485/head:pull/29485 PR: https://git.openjdk.org/jdk/pull/29485 From jbhateja at openjdk.org Thu Jan 29 12:58:57 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Thu, 29 Jan 2026 12:58:57 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/11021544..d81035fd Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=01-02 Stats: 103 lines in 3 files changed: 23 ins; 0 del; 80 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From duke at openjdk.org Thu Jan 29 14:32:08 2026 From: duke at openjdk.org (David Beaumont) Date: Thu, 29 Jan 2026 14:32:08 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> <_OBEkatnYiCZ9cvRGxXCDAx0hmqGa09CiMFb1uVMihY=.d8ff56e0-142e-424d-b141-2ac821413d74@github.com> Message-ID: On Tue, 13 Jan 2026 20:31:16 GMT, Roger Riggs wrote: > > I wonder if it could throw a more specific mismatch exception for this case so that the jimage tool can handle, and translate into something that includes a path to itself. > > Following Alan's suggestion, keep the exception message concise so JImage tool can recognize it and produce a full error message with context. I see, so your suggestion is to make the correct error message in the JLink tool dependent on parsing the text of the exception message from the library code? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3818047632 From rriggs at openjdk.org Thu Jan 29 14:36:05 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 14:36:05 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 02:35:23 GMT, SendaoYan wrote: > Hi all, > > Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. > > This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. > > Change has been verifed locally. The imtermittent timed out do not observed anymore. test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 246: > 244: pids.forEach(pid -> command.append(",").append(pid)); > 245: System.out.println("Running lsof command: " + command); > 246: try (Process p = new ProcessBuilder(command.toString().split(" ")) The purpose of NOT using -p was to be able to identify the other processes that may be linked by their file descriptors/handles if the case of a failure. Without a more complete list of file descriptors, the diagnostic information is not available to track down the other process. I'd prefer that the timeout be increased. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2741948575 From rriggs at openjdk.org Thu Jan 29 14:36:07 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 14:36:07 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 14:30:18 GMT, Roger Riggs wrote: >> Hi all, >> >> Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. >> >> This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. >> >> Change has been verifed locally. The imtermittent timed out do not observed anymore. > > test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 246: > >> 244: pids.forEach(pid -> command.append(",").append(pid)); >> 245: System.out.println("Running lsof command: " + command); >> 246: try (Process p = new ProcessBuilder(command.toString().split(" ")) > > The purpose of NOT using -p was to be able to identify the other processes that may be linked by their file descriptors/handles if the case of a failure. > Without a more complete list of file descriptors, the diagnostic information is not available to track down the other process. > I'd prefer that the timeout be increased. Having just updated this test, I would have been interested in fixing any follow on problems myself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2741961961 From rriggs at openjdk.org Thu Jan 29 14:44:08 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 14:44:08 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 02:35:23 GMT, SendaoYan wrote: > Hi all, > > Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. > > This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. > > Change has been verifed locally. The imtermittent timed out do not observed anymore. The previous version used /proc to determine file descriptors, but lsof was available on all platforms and common code was desirable (though the output format is different). It might make more sense to go back to the /proc/self/fds on Linux. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29478#issuecomment-3818109815 From rriggs at openjdk.org Thu Jan 29 16:44:54 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 16:44:54 GMT Subject: RFR: 8372301: Improve error message for jimage command line tool regarding version mismatch [v3] In-Reply-To: References: <72GDECrm-yngZDebq4GRZVqtQk-IdSpD6PoHU-JzY8s=.1d7b1e64-5807-46d0-b237-382928753d1e@github.com> Message-ID: <2cUyYAyfEiefHtFxY9EYFgm_ehpgR_4GVh3LW9klV2I=.56b5acee-d33e-49f4-b822-968224855b8c@github.com> On Wed, 26 Nov 2025 16:46:41 GMT, David Beaumont wrote: >> Adds a semantic reason for failure which can be optionally interrogated by calling code. >> Use the 'Reason.BAD_VERSION' value to trigger a different translated error message from the JImageTask. >> >> I would consider moving the error message string into the Reason enum to simplify the code triggering the error and avoid message string duplication, but it's not straightforward due to the need to supply the version numbers. >> >> We can use this approach to provide translated messages for all the distinct failure reasons if needed. > > David Beaumont has updated the pull request incrementally with two additional commits since the last revision: > > - Redo bad indentation > - undo blank line Yes, make the prefix of the exception message a fixed value so it can be recognized with String.startsWith(...). The caller already knows the name of the image and since the remedy is to use the matching Java install, that doesn't need any parameters. (The actual jimage version values are meaningless at this point). In addition to the generic action, the message from the exception could be provided, but mostly for debug but is not actionable. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28456#issuecomment-3818897333 From lancea at openjdk.org Thu Jan 29 17:17:37 2026 From: lancea at openjdk.org (Lance Andersen) Date: Thu, 29 Jan 2026 17:17:37 GMT Subject: RFR: 8376038: Refactor java/sql tests to use JUnit [v4] In-Reply-To: References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Wed, 28 Jan 2026 23:29:43 GMT, Justin Lu wrote: >> Please review this PR which converts the JDBC TestNG tests to use JUnit. >> >> This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. >> >> Framework test stats before: >> 680 = 680 TestNG + 0 JUnit >> >> Framework test stats after: >> 680 = 0 TestNG + 680 JUnit > > Justin Lu has updated the pull request incrementally with one additional commit since the last revision: > > Another occurrence of eof newline required Hi Justin, Thank you for taking this on. Overall the changes look fine. Please run the the tests across all of the mach5 platforms so that we get some extra sanity ------------- Marked as reviewed by lancea (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29354#pullrequestreview-3724038853 From pchilanomate at openjdk.org Thu Jan 29 17:55:57 2026 From: pchilanomate at openjdk.org (Patricio Chilano Mateo) Date: Thu, 29 Jan 2026 17:55:57 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 04:21:18 GMT, David Holmes wrote: >> src/hotspot/share/classfile/javaClasses.cpp line 1944: >> >>> 1942: >>> 1943: bool is_virtual = java_lang_VirtualThread::is_instance(_thread_h()); >>> 1944: bool vthread_carrier = !is_virtual && (java_thread != nullptr) && (java_thread->vthread_continuation() != nullptr); >> >> The extra `java_thread != nullptr` should not be necessary. > > What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2742835509 From psandoz at openjdk.org Thu Jan 29 18:15:43 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Thu, 29 Jan 2026 18:15:43 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:58:57 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions src/hotspot/share/prims/vectorSupport.hpp line 146: > 144: LT_SHORT = 9, > 145: LT_INT = 10, > 146: LT_LONG = 11 Are the values designed to be in sync with the `BasicType` values where the lane type and the basic type are the same? If so we should call this out via explicit assignment. Otherwise, i think we should adjust the values (which may require some adjustment elsewhere e.g., VectorOperators.java). src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 152: > 150: public static final int MODE_BITS_COERCED_LONG_TO_MASK = 1; > 151: > 152: // BasicType codes, for primitives only: This comment needs to be updated. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 544: > 542: public byte laneHelper(int i) { > 543: return (byte) VectorSupport.extract( > 544: VCLASS, LT_BYTE, VLENGTH, Can we declare a static final field `LANE_TYPE_ORDINAL` (or `LANE_TYPE_ID`, see comment on `LaneType` as the naming is important) and use that consistently like we already do for `ETYPE`? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 88: > 86: final String printName; > 87: final char typeChar; // one of "BSILFD" > 88: final int laneType; // lg(size/8) | (kind=='F'?4:kind=='I'?8) We need to change the name of this field to more clearly distinguish between it and the class name. If we can change the values of `LT_*` and align them with the enum ordinal values then we can call it `laneTypeOrdinal` and consistently use that, then we don't likely need the `LT_*` constants. If the values need to align with `BasicType` values then it might be better called `laneTypeIdentifier` or `laneTypeId`. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 197: > 195: /*package-private*/ > 196: @ForceInline > 197: static LaneType ofBasicType(int bt) { The method name and argument need updating. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742857369 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742850134 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742840498 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742894994 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2742873650 From vromero at openjdk.org Thu Jan 29 18:17:48 2026 From: vromero at openjdk.org (Vicente Romero) Date: Thu, 29 Jan 2026 18:17:48 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 11:45:08 GMT, Liam Miller-Cushon wrote: >> See [JDK-8208752: Calling a deserialized Lambda might fail with ClassCastException](https://bugs.openjdk.org/browse/JDK-8208752). >> >> Lambda deserialization currently does not consider `SerializedLambda#getInstantiatedMethodType` when deserializing lambdas, which can lead to method references that differ only in `getInstantiatedMethodType` being merged into the same lambda instance, and can result in `ClassCastException`s like the one reported in the bug. >> >> This depends on the fix for [JDK-8374654: Inconsistent handling of lambda deserialization for Object method references on interfaces](https://bugs.openjdk.org/browse/JDK-8374654) in https://github.com/openjdk/jdk/pull/29075. > > Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: > > - Merge branch 'JDK-8374654' into JDK-8208752 > - Test cleanup > - Updates for --debug=dumpLambdaDeserializationStats > - Merge branch 'JDK-8374654' into JDK-8208752 > - Merge branch 'JDK-8374654' into JDK-8208752 > - Update test > - Merge branch 'JDK-8374654' into JDK-8208752 > - Don't rely on the iteration order of Map.of entries > - 8208752: Calling a deserialized Lambda might fail with ClassCastException I have a question: [1] refers to [2] as a possible cause. But actually [2] only did a javadoc change specifying that the identity of a function object produced from a lambda expression or method reference (specifically that produced by the invocation of the LambdaMetafactory's CallSite's target) or produced by deserialization of a serialized lambda can be unpredictable. so it seems like the spec acknowledges that there shouldn't be any assumption that what enters serialization should be equal to what comes out. So two different lambdas after serialization could be equal to each other [1] https://bugs.openjdk.org/browse/JDK-8208752 [2] https://bugs.openjdk.org/browse/JDK-8202922 ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3819376530 From chen.l.liang at oracle.com Thu Jan 29 18:27:24 2026 From: chen.l.liang at oracle.com (Chen Liang) Date: Thu, 29 Jan 2026 18:27:24 +0000 Subject: RFD: Reorganize ZipCoder such that UTF8 is handled by the base class In-Reply-To: References: Message-ID: Hello Eirik, I strongly agree with your proposal. I see such a change has low risk given ZipCoder is an internal class. Regards, Chen ________________________________ From: core-libs-dev on behalf of Eirik Bj?rsn?s Sent: Wednesday, January 28, 2026 3:26 AM To: core-libs-dev Subject: RFD: Reorganize ZipCoder such that UTF8 is handled by the base class Hi, Bringing this up on core-libs-dev such that the motivation can be explained/discussed here and any future PR can focus on actual code changes. Summary: Reorganize the ZipCoder class hierarchy to let the base class handle UTF8 and the subclass handle arbitrary Charsets. This makes the design better match the ZIP specification and how ZIP files are used in the real world and additionally have some benefits in code quality and performance. Motivation: The ZipCoder class has been central to many ZipFile performance improvements in recent years. Many optimizations are encoding-specific and encapsulating these concerns makes a lot of sense. Currently, the base ZipCoder instance supports any given Charset. Then, a subclass UTF8ZipCoder provides higher performance optimizations specific to UTF-8. However, real-world use of the ZipFile API defaults to UTF-8. The ZIP specification long-ago introduced a flag to explicitly indicate that entries are encoded using UTF-8. The JAR specification has mandated UTF-8 since the beginning. Any use of non-UTF-8 ZIP files is increasingly niche and belongs in the legacy zone. The current UTF8ZipCoder is stateless and documented as thread safe, while the base class ZipCoder is not. As a subclass of ZipCode, UTF8ZipCoder does however inherit CharsetEncoder and CharsetDecoder state fields from its super class and it needs to pass a UTF8 Charset to its parent, without really using it. This makes state and thread safety harder to reason about. Since UTF8ZipCoder is always needed, the JVM must always load it along with the base class ZipCoder. Apart from loading an extra class, this prevents the JVM from seeing calls to ZipCoder methods as monomorphic. A draft implementation of this change indicates a ~3% performance win on ZipFile lookups in ZipFileGetEntry, probably explained by the compiler seeing only one instance of ZipCoder being loaded. Solution: Switch the class hierarchy of ZipCoder around such that the base class handles UTF-8. Introduce a new subclass CharsetZipCoder to handle legacy non-UTF ZIP files. Move the Charset, CharsetEncoder, CharsetDecoder fields to this subclass. Update code comments to reflect the changes. Risks: This should be a pure refactoring, mostly moving code around. Most changes can be performed in-place, such that side by side review will mostly reflect indentation changes. We have good test coverage for UTF8 and non-UTF-8 ZIP files to help us catch regressions. If I see support for this proposal, I'll be happy to submit a PR with the actual changes. Cheers, Eirik :-) Confidential- Oracle Internal -------------- next part -------------- An HTML attachment was scrubbed... URL: From sviswanathan at openjdk.org Thu Jan 29 19:46:40 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Thu, 29 Jan 2026 19:46:40 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 22 Jan 2026 20:30:26 GMT, Srinivas Vamsi Parasa wrote: >> Srinivas Vamsi Parasa has updated the pull request incrementally with one additional commit since the last revision: >> >> Update ALL of ArraysFill JMH micro > > ### Int VectorBulkOperationsArray Fill > > Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) > -- | -- | -- | -- | -- | -- > VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% > VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.097 | 3.116 | 3.387 | 8% > VectorBulkOperationsArray.fill_var_... > > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? > > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. > > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? > > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. > > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? > > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? > > > > > > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. > > @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3819899021 From liach at openjdk.org Thu Jan 29 19:50:03 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 19:50:03 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie wrote: > Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. > > Two interesting parts: > > 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. > 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. Thanks for this patch. For this bugfix we need a CSR that some methods in treemap view spliterators now start throwing NPE for empty views, for documentation purposes. I have filed the CSR. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3819918225 From ogillespie at openjdk.org Thu Jan 29 20:08:55 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Thu, 29 Jan 2026 20:08:55 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie wrote: > Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. > > Two interesting parts: > > 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. > 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. Thanks! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29485#issuecomment-3820025823 From rriggs at openjdk.org Thu Jan 29 20:32:18 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 20:32:18 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:40:42 GMT, Oli Gillespie wrote: > Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. > > Two interesting parts: > > 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. > 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. src/java.base/share/classes/java/util/TreeMap.java line 2141: > 2139: } > 2140: public void forEachRemaining(Consumer action) { > 2141: Objects.requireNonNull(action); Is there a test for NPE action on an empty Map? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29485#discussion_r2743399918 From duke at openjdk.org Thu Jan 29 20:37:23 2026 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 29 Jan 2026 20:37:23 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] In-Reply-To: References: Message-ID: <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com> > 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 * Resolved IDE warnings * Set next year 2026 ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27411/files - new: https://git.openjdk.org/jdk/pull/27411/files/cec80653..d9a2f853 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27411&range=04-05 Stats: 69 lines in 6 files changed: 0 ins; 0 del; 69 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 liach at openjdk.org Thu Jan 29 20:37:53 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 20:37:53 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:29:43 GMT, Roger Riggs wrote: >> Add missing cases to SpliteratorTraversingAndSplittingTest. This came up when I was fixing https://bugs.openjdk.org/browse/JDK-8372946, and I noticed the tests do not cover these sub-maps. >> >> Two interesting parts: >> >> 1. These tests failed when first added because `SubMapKeyIterator` and `DescendingSubMapKeyIterator` do not eagerly throw `NullPointerException` for `null` action arguments. The spec says "Throws: NullPointerException - if the specified action is null", so I updated the implementation to match other spliterators. >> 2. Since the descending maps have the reverse expected iteration order, I added support in the test harness for descending maps. > > src/java.base/share/classes/java/util/TreeMap.java line 2141: > >> 2139: } >> 2140: public void forEachRemaining(Consumer action) { >> 2141: Objects.requireNonNull(action); > > Is there a test for NPE action on an empty Map? The new cases for subMap in SpliteratorTraversingAndSplittingTest should be sufficient. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29485#discussion_r2743414552 From duke at openjdk.org Thu Jan 29 20:41:56 2026 From: duke at openjdk.org (Vladimir Yaroslavskiy) Date: Thu, 29 Jan 2026 20:41:56 GMT Subject: RFR: 8266431: Dual-Pivot Quicksort improvements (Radix sort) [v6] In-Reply-To: <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com> References: <7HNoIEEFVQ124VGD57eXmGgEEL7xNixKYtHRGyPAFPU=.a83912db-8b0c-4901-9e9b-dffaad3ceab1@github.com> Message-ID: On Thu, 29 Jan 2026 20:37:23 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 > > * Resolved IDE warnings > * Set next year 2026 Hi team, I applied minor changes (set year 2026, resolved warnings) to sources of sorting. @DougLea Doug Lea @jatin-bhateja, @jbhateja Jatin Bhateja @tarsa Piotr Tarsa Please look at the latest changes. Many thanks, Vladimir ------------- PR Comment: https://git.openjdk.org/jdk/pull/27411#issuecomment-3820191744 From naoto at openjdk.org Thu Jan 29 21:14:37 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 29 Jan 2026 21:14:37 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking Message-ID: Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant. ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29493/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29493&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340830 Stats: 284 lines in 4 files changed: 150 ins; 93 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/29493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29493/head:pull/29493 PR: https://git.openjdk.org/jdk/pull/29493 From rriggs at openjdk.org Thu Jan 29 22:26:01 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Thu, 29 Jan 2026 22:26:01 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 20:33:47 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/util/TreeMap.java line 2141: >> >>> 2139: } >>> 2140: public void forEachRemaining(Consumer action) { >>> 2141: Objects.requireNonNull(action); >> >> Is there a test for NPE action on an empty Map? > > The new cases for subMap in SpliteratorTraversingAndSplittingTest should be sufficient. I'd rather see it tested explicitly; its hard to identify exactly which test expects and catches the NPE. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29485#discussion_r2743794120 From liach at openjdk.org Thu Jan 29 22:31:04 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 22:31:04 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:47:55 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 with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge remote-tracking branch 'origin/master' into codepoint-count > - Fix comments > - Don't use removed `Character::codePointCount` overload > - Update year in copyright > - Fix double empty lines > - Remove `Character.codePointCount()` > - Replace "unpaired surrogates" with "isolated surrogate code units" > > https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 > https://www.unicode.org/charts/PDF/UDC00.pdf > - Remove `Character.codePointCount` overload > - Rename parameter names from `a` to `seq` > > `chars` is too confusing with `char` > - Improve JavaDoc > > Co-authored-by: Chen Liang > - ... and 10 more: https://git.openjdk.org/jdk/compare/681e4ec8...198b3188 Please fix this identified thread safety issue. Submitted your patch to our CI for testing. I built the Javadoc locally, the since-only tag works like this so they are fine: image src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 542: > 540: return count; > 541: } > 542: return StringUTF16.codePointCount(value, 0, count); Suggestion: return StringUTF16.codePointCountSB(value, 0, count); In buggy user program that use StringBuilder from more than one threads, we can have `value.length < count`, so we must perform this call checked. I think we need a new entry for this method in `test/jdk/java/lang/StringBuilder/StressSBTest.java` too. ------------- Changes requested by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/26461#pullrequestreview-3725332918 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743790652 From liach at openjdk.org Thu Jan 29 22:38:22 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 22:38:22 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 22:22:57 GMT, Roger Riggs wrote: >> The new cases for subMap in SpliteratorTraversingAndSplittingTest should be sufficient. > > I'd rather see it tested explicitly; its hard to identify exactly which test expects and catches the NPE. The modification to that test adds new entries to a data provider. The NPE is checked by the preexisting testNullPointerException which tests all speliterators in the data set. I don't think an additional explicit unit test provides much value over the existing "cartesian" setup. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29485#discussion_r2743827273 From liach at openjdk.org Thu Jan 29 23:20:12 2026 From: liach at openjdk.org (Chen Liang) Date: Thu, 29 Jan 2026 23:20:12 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 22:21:41 GMT, Chen Liang wrote: >> Tatsunori Uchino 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 remote-tracking branch 'origin/master' into codepoint-count >> - Fix comments >> - Don't use removed `Character::codePointCount` overload >> - Update year in copyright >> - Fix double empty lines >> - Remove `Character.codePointCount()` >> - Replace "unpaired surrogates" with "isolated surrogate code units" >> >> https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 >> https://www.unicode.org/charts/PDF/UDC00.pdf >> - Remove `Character.codePointCount` overload >> - Rename parameter names from `a` to `seq` >> >> `chars` is too confusing with `char` >> - Improve JavaDoc >> >> Co-authored-by: Chen Liang >> - ... and 10 more: https://git.openjdk.org/jdk/compare/681e4ec8...198b3188 > > src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 542: > >> 540: return count; >> 541: } >> 542: return StringUTF16.codePointCount(value, 0, count); > > Suggestion: > > return StringUTF16.codePointCountSB(value, 0, count); > > In buggy user program that use StringBuilder from more than one threads, we can have `value.length < count`, so we must perform this call checked. > > I think we need a new entry for this method in `test/jdk/java/lang/StringBuilder/StressSBTest.java` too. This should be sufficient for StressSBTest: diff --git a/test/jdk/java/lang/StringBuilder/StressSBTest.java b/test/jdk/java/lang/StringBuilder/StressSBTest.java index a5dc6672f07..6219851ee3b 100644 --- a/test/jdk/java/lang/StringBuilder/StressSBTest.java +++ b/test/jdk/java/lang/StringBuilder/StressSBTest.java @@ -1,5 +1,5 @@ /* - * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -279,6 +279,7 @@ private boolean invokeByMethodNameAndType(String name, MethodType mt, StringBuil case "charAt(StringBuilder,int)char" -> sb.charAt(5); case "codePointAt(StringBuilder,int)int" -> sb.codePointAt(4); case "codePointBefore(StringBuilder,int)int" -> sb.codePointBefore(3); + case "codePointCount(StringBuilder)int" -> sb.codePointCount(); case "codePointCount(StringBuilder,int,int)int" -> sb.codePointCount(3, 9); case "offsetByCodePoints(StringBuilder,int,int)int" -> sb.offsetByCodePoints(3, 7); case "lastIndexOf(StringBuilder,String,int)int" -> sb.lastIndexOf("A", 45); ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743920523 From duke at openjdk.org Thu Jan 29 23:20:13 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 23:20:13 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: <7ewFBUTLHTBhkQscDm-0kI_oZzZhBQHsNwWgyheRXf4=.41edf5e5-ae20-4d97-ab59-11bf3194d637@github.com> On Thu, 29 Jan 2026 23:14:28 GMT, Chen Liang wrote: >> src/java.base/share/classes/java/lang/AbstractStringBuilder.java line 542: >> >>> 540: return count; >>> 541: } >>> 542: return StringUTF16.codePointCount(value, 0, count); >> >> Suggestion: >> >> return StringUTF16.codePointCountSB(value, 0, count); >> >> In buggy user program that use StringBuilder from more than one threads, we can have `value.length < count`, so we must perform this call checked. >> >> I think we need a new entry for this method in `test/jdk/java/lang/StringBuilder/StressSBTest.java` too. > > This should be sufficient for StressSBTest: > > diff --git a/test/jdk/java/lang/StringBuilder/StressSBTest.java b/test/jdk/java/lang/StringBuilder/StressSBTest.java > index a5dc6672f07..6219851ee3b 100644 > --- a/test/jdk/java/lang/StringBuilder/StressSBTest.java > +++ b/test/jdk/java/lang/StringBuilder/StressSBTest.java > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. > + * Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -279,6 +279,7 @@ private boolean invokeByMethodNameAndType(String name, MethodType mt, StringBuil > case "charAt(StringBuilder,int)char" -> sb.charAt(5); > case "codePointAt(StringBuilder,int)int" -> sb.codePointAt(4); > case "codePointBefore(StringBuilder,int)int" -> sb.codePointBefore(3); > + case "codePointCount(StringBuilder)int" -> sb.codePointCount(); > case "codePointCount(StringBuilder,int,int)int" -> sb.codePointCount(3, 9); > case "offsetByCodePoints(StringBuilder,int,int)int" -> sb.offsetByCodePoints(3, 7); > case "lastIndexOf(StringBuilder,String,int)int" -> sb.lastIndexOf("A", 45); Do we not need other additional test cases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743926620 From duke at openjdk.org Thu Jan 29 23:20:13 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Thu, 29 Jan 2026 23:20:13 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: <7ewFBUTLHTBhkQscDm-0kI_oZzZhBQHsNwWgyheRXf4=.41edf5e5-ae20-4d97-ab59-11bf3194d637@github.com> References: <7ewFBUTLHTBhkQscDm-0kI_oZzZhBQHsNwWgyheRXf4=.41edf5e5-ae20-4d97-ab59-11bf3194d637@github.com> Message-ID: On Thu, 29 Jan 2026 23:17:07 GMT, Tatsunori Uchino wrote: >> This should be sufficient for StressSBTest: >> >> diff --git a/test/jdk/java/lang/StringBuilder/StressSBTest.java b/test/jdk/java/lang/StringBuilder/StressSBTest.java >> index a5dc6672f07..6219851ee3b 100644 >> --- a/test/jdk/java/lang/StringBuilder/StressSBTest.java >> +++ b/test/jdk/java/lang/StringBuilder/StressSBTest.java >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. >> + * Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -279,6 +279,7 @@ private boolean invokeByMethodNameAndType(String name, MethodType mt, StringBuil >> case "charAt(StringBuilder,int)char" -> sb.charAt(5); >> case "codePointAt(StringBuilder,int)int" -> sb.codePointAt(4); >> case "codePointBefore(StringBuilder,int)int" -> sb.codePointBefore(3); >> + case "codePointCount(StringBuilder)int" -> sb.codePointCount(); >> case "codePointCount(StringBuilder,int,int)int" -> sb.codePointCount(3, 9); >> case "offsetByCodePoints(StringBuilder,int,int)int" -> sb.offsetByCodePoints(3, 7); >> case "lastIndexOf(StringBuilder,String,int)int" -> sb.lastIndexOf("A", 45); > > Do we not need other additional test cases? Do we not need other additional test cases? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743926750 From naoto at openjdk.org Thu Jan 29 23:32:57 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 29 Jan 2026 23:32:57 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:47:55 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 with a new target base due to a merge or a rebase. The pull request now contains 20 commits: > > - Merge remote-tracking branch 'origin/master' into codepoint-count > - Fix comments > - Don't use removed `Character::codePointCount` overload > - Update year in copyright > - Fix double empty lines > - Remove `Character.codePointCount()` > - Replace "unpaired surrogates" with "isolated surrogate code units" > > https://www.unicode.org/versions/Unicode17.0.0/core-spec/chapter-3/#G1654 > https://www.unicode.org/charts/PDF/UDC00.pdf > - Remove `Character.codePointCount` overload > - Rename parameter names from `a` to `seq` > > `chars` is too confusing with `char` > - Improve JavaDoc > > Co-authored-by: Chen Liang > - ... and 10 more: https://git.openjdk.org/jdk/compare/681e4ec8...198b3188 src/java.base/share/classes/java/lang/String.java line 1886: > 1884: * {@return the number of Unicode code points in this String} > 1885: * Isolated surrogate code units count as one code point each. > 1886: * I think this can be deleted as well. test/jdk/java/lang/StringBuilder/Supplementary.java line 218: > 216: > 217: /** > 218: * Test codePointCount(int, int) & codePointCount() I think a separate test method needs to be added solely for `codePointCount()` to follow the pattern in this test file. Bonus if you could rename each `testX` to `testMethodName` (This test seems to have a lot of room for refactoring, but they are for another time) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743905940 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2743956162 From syan at openjdk.org Fri Jan 30 01:19:16 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 30 Jan 2026 01:19:16 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Thu, 29 Jan 2026 14:32:59 GMT, Roger Riggs wrote: >> test/jdk/java/lang/ProcessBuilder/PipelineLeaksFD.java line 246: >> >>> 244: pids.forEach(pid -> command.append(",").append(pid)); >>> 245: System.out.println("Running lsof command: " + command); >>> 246: try (Process p = new ProcessBuilder(command.toString().split(" ")) >> >> The purpose of NOT using -p was to be able to identify the other processes that may be linked by their file descriptors/handles if the case of a failure. >> Without a more complete list of file descriptors, the diagnostic information is not available to track down the other process. >> I'd prefer that the timeout be increased. > > Having just updated this test, I would have been interested in fixing any follow on problems myself. Do you mean I should close this PR, and you will create a new one. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2744210430 From syan at openjdk.org Fri Jan 30 02:27:01 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 30 Jan 2026 02:27:01 GMT Subject: RFR: 8376760: VerifyJimage.java#compare intermittent timed out with fastdebug Message-ID: Hi all, Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination. The test run all passed 100 times simultancely. ------------- Commit messages: - Save timeout value to fail logs - 8376760: VerifyJimage.java#compare intermittent timed out with fastdebug Changes: https://git.openjdk.org/jdk/pull/29498/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29498&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376760 Stats: 5 lines in 1 file changed: 2 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/29498.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29498/head:pull/29498 PR: https://git.openjdk.org/jdk/pull/29498 From liach at openjdk.org Fri Jan 30 03:58:55 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 03:58:55 GMT Subject: RFR: 8376760: VerifyJimage.java#compare intermittent timed out with fastdebug In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 02:20:09 GMT, SendaoYan wrote: > Hi all, > > Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination. > > The test run all passed 100 times simultaneously. Looks good. @david-beaumont can you review too? Please wait for David's review before integration. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29498#pullrequestreview-3726197416 From dholmes at openjdk.org Fri Jan 30 04:42:45 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:42:45 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 17:53:26 GMT, Patricio Chilano Mateo wrote: >> What would force it to be non-null? (Related: under what conditions will `th` be null and what does that imply about the value of `_thread_h()`?) > > A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? Okay so `!is_virtual => java_thread != nullptr`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744574434 From dholmes at openjdk.org Fri Jan 30 04:47:50 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:47:50 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> On Thu, 29 Jan 2026 09:12:21 GMT, Alan Bateman wrote: >> src/hotspot/share/services/threadService.cpp line 1479: >> >>> 1477: if (cl._thread_status == JavaThreadStatus::NEW || cl._thread_status == JavaThreadStatus::TERMINATED) { >>> 1478: return nullptr; >>> 1479: } >> >> It is not obvious to me why this is only a possibility now? > > ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. > > For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. Still not clear to me why any new thread is not already filtered out long before now; nor why we have not needed this in the past. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744583241 From dholmes at openjdk.org Fri Jan 30 04:50:26 2026 From: dholmes at openjdk.org (David Holmes) Date: Fri, 30 Jan 2026 04:50:26 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 09:01:20 GMT, Alan Bateman wrote: >> src/java.base/share/classes/java/lang/Thread.java line 2218: >> >>> 2216: } >>> 2217: Object trace = getStackTrace0(); >>> 2218: if (trace instanceof StackTraceElement[] stackTrace) { >> >> What can this return other than a `StackTraceElement[]` ?? > > It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. Sorry I have to disagree - a type check screams to me that this could be some other type when it can't. A null check would be better IMO. On the matter of the cast, why doesn't getStackTrace0 return STE[] instead of object? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2744587005 From syan at openjdk.org Fri Jan 30 06:12:34 2026 From: syan at openjdk.org (SendaoYan) Date: Fri, 30 Jan 2026 06:12:34 GMT Subject: RFR: 8376760: VerifyJimage.java#compare intermittent timed out with fastdebug In-Reply-To: References: Message-ID: <3puzGUvUOnEvYeh4W_pBVPGN9f1gyFjEdVXNr6vMqyg=.bc0cda54-d5e9-45ad-b86f-4acc6745f1dc@github.com> On Fri, 30 Jan 2026 03:55:58 GMT, Chen Liang wrote: > Looks good. @david-beaumont can you review too? > > Please wait for David's review before integration. Okey. Thanks @liach ------------- PR Comment: https://git.openjdk.org/jdk/pull/29498#issuecomment-3822044312 From jbhateja at openjdk.org Fri Jan 30 07:35:43 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 30 Jan 2026 07:35:43 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v4] In-Reply-To: References: Message-ID: > As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. > > Patch add new lane type constants and pass them to vector intrinsic entry points. > > All existing Vector API jtreg test are passing with the patch. > > Kindly review and share your feedback. > > Best Regards, > Jatin Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: Review comments resolutions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29481/files - new: https://git.openjdk.org/jdk/pull/29481/files/d81035fd..ff73dc3d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29481&range=02-03 Stats: 858 lines in 48 files changed: 290 ins; 13 del; 555 mod Patch: https://git.openjdk.org/jdk/pull/29481.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29481/head:pull/29481 PR: https://git.openjdk.org/jdk/pull/29481 From jbhateja at openjdk.org Fri Jan 30 07:35:46 2026 From: jbhateja at openjdk.org (Jatin Bhateja) Date: Fri, 30 Jan 2026 07:35:46 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v3] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 18:08:03 GMT, Paul Sandoz wrote: >> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: >> >> Review comments resolutions > > src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 88: > >> 86: final String printName; >> 87: final char typeChar; // one of "BSILFD" >> 88: final int laneType; // lg(size/8) | (kind=='F'?4:kind=='I'?8) > > We need to change the name of this field to more clearly distinguish between it and the class name. > > If we can change the values of `LT_*` and align them with the enum ordinal values then we can call it `laneTypeOrdinal` and consistently use that, then we don't likely need the `LT_*` constants. If the values need to align with `BasicType` values then it might be better called `laneTypeIdentifier` or `laneTypeId`. Thanks @PaulSandoz , I have incorporated your comments, it will still be useful to keep new LT_* constants as its better to pass named constants to intrinsic entries rather than numeric values. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2745013458 From alanb at openjdk.org Fri Jan 30 08:10:33 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 08:10:33 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> References: <6WdkzWF-d6yGLKVUP9pCiYE1ghOdL5sTlcBiA1bE4c0=.802606b6-f958-4dea-a6a7-3d8a406c177c@github.com> Message-ID: On Fri, 30 Jan 2026 04:45:33 GMT, David Holmes wrote: >> ThreadSnapshot.of(Thread) may be invoked with a platform or virtual Thread in any state. It could sample the thread state before calling ThreadSnapshotFactory::get_thread_snapshot. That would allow it to filter out unstarted/NEW threads. It could also filter terminated threads but that would be racy and get_thread_snapshot would still need to handle terminated threads. >> >> For platform threads, get_thread_snapshot will bail out early if there is no JavaThread. So the effect of the above is to have virtual threads also be filtered out. > > Still not clear to me why any new thread is not already filtered out long before now; nor why we have not needed this in the past. We want ThreadSnapshot.of(Thread) to accept a Thread in any state. Existing behavior is to return null for platform threads that are not alive. For virtual threads it will return a snapshot so we want to change that. The ThreadNotAlive test in the PR allows to specifically check these cases as they are hard to demonstrate with the thread dump. ThreadSnapshot.of(Thread) does not filter out the "not alive" cases. It could, in which case ThreadSnapshotFactory::get_thread_snapshot would need to assert if called with a new/unstarted thread. The terminating thread case would still need to be handled by ThreadSnapshotFactory::get_thread_snapshot. For platform threads there is no JavaThread so it bails easy. For virtual threads it needs to examine the state. So would you prefer that? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745112416 From sspitsyn at openjdk.org Fri Jan 30 08:27:26 2026 From: sspitsyn at openjdk.org (Serguei Spitsyn) Date: Fri, 30 Jan 2026 08:27:26 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 14:56:31 GMT, Jean-Philippe Bempel wrote: >> ?retransformed >> >> Fix a retransform error when retransforming a record with type annotation. processing the record type annotation was done by calling the wrong method and using the one to process regular annotation. Regular annotations have not the same structure and decoding was therefore incorrect. The decoding methods detect a problem but this error was not propagated correctly outside of VM_RedfineClass::load_new_class_versions method, swallowing the error and leaving the retransformed class in bad state. >> >> Here we have fixed the call to the right method for decoding the type annotations but also propagated the error when rewriting the constant pool as an JVMTI_ERROR_INTERNAL > > Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: > > add copyright headers src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > 1475: if (res != JVMTI_ERROR_NONE) { > 1476: return res; > 1477: } Pending exception need to be processed and cleared below (see lines: 1478-1487). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745165920 From epeter at openjdk.org Fri Jan 30 08:36:42 2026 From: epeter at openjdk.org (Emanuel Peter) Date: Fri, 30 Jan 2026 08:36:42 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 19:43:27 GMT, Sandhya Viswanathan wrote: >> ### Int VectorBulkOperationsArray Fill >> >> Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) >> -- | -- | -- | -- | -- | -- >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.... > >> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >> > >> > >> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >> >> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? > > @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? ----------------------- I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. Does that make sense? Or do you have a better idea how to make a good decision here? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3822517559 From alanb at openjdk.org Fri Jan 30 08:42:37 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 08:42:37 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 04:47:59 GMT, David Holmes wrote: >> It can only return a StackTraceElement[] or null. Using a type pattern seemed nicer here to avoid a null check + explicit cast. > > Sorry I have to disagree - a type check screams to me that this could be some other type when it can't. A null check would be better IMO. > > On the matter of the cast, why doesn't getStackTrace0 return STE[] instead of object? The idiom is nice, but I can see how it might be confusing. Your question about getStackTrace0 returning Object is a good question. It should return STE[] but I didn't want to change it as we want it to go away. In the mean-time then it would be clearer and avoid any confusion that it could return anything else. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745220496 From cushon at openjdk.org Fri Jan 30 08:54:21 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 30 Jan 2026 08:54:21 GMT Subject: RFR: 8208752: Calling a deserialized Lambda might fail with ClassCastException [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 18:13:44 GMT, Vicente Romero wrote: >> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits: >> >> - Merge branch 'JDK-8374654' into JDK-8208752 >> - Test cleanup >> - Updates for --debug=dumpLambdaDeserializationStats >> - Merge branch 'JDK-8374654' into JDK-8208752 >> - Merge branch 'JDK-8374654' into JDK-8208752 >> - Update test >> - Merge branch 'JDK-8374654' into JDK-8208752 >> - Don't rely on the iteration order of Map.of entries >> - 8208752: Calling a deserialized Lambda might fail with ClassCastException > > I have a question: [1] refers to [2] as a possible cause. But actually [2] only did a javadoc change specifying that the identity of a function object produced from a lambda expression or method reference (specifically that produced by the invocation of the LambdaMetafactory's CallSite's target) or produced by deserialization of a serialized lambda can be unpredictable. > > so it seems like the spec acknowledges that there shouldn't be any assumption that what enters serialization should be equal to what comes out. So two different lambdas after serialization could be equal to each other. Of course this applies more to bug [3] who's PR is now part of this one > > [1] https://bugs.openjdk.org/browse/JDK-8208752 > [2] https://bugs.openjdk.org/browse/JDK-8202922 > [3] https://bugs.openjdk.org/browse/JDK-8374654 @vicente-romero-oracle that is a good point. To be clear I didn't report JDK-8208752, so I can't vouch for what the thinking behind that text was, but I wonder if "this is probably a side effect of JDK-8202922" refers more to it being related to the behaviour discussed in JDK-8202922, than specifically a culprit of the changes in the other bug. My understanding overall is that the spec gives the compiler latitude to merge equivalent lambdas or method references together during serialization, but the key part is that they have to be equivalent, and the issue being fixed here is a case where the merging was incorrectly combining lambdas with different target types. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28943#issuecomment-3822586594 From aartemov at openjdk.org Fri Jan 30 08:56:16 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 30 Jan 2026 08:56:16 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:29:37 GMT, Andrey Turbanov wrote: > I mean main thing we do here - is to introduce new method. Source of original code - is just implementation details. Historically, if a method is implemented in FDLIBM, the corresponding issue gets name "Port fdlib X to Java", see here for instance: https://bugs.openjdk.org/browse/JDK-8171407 ------------- PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3822593335 From alanb at openjdk.org Fri Jan 30 09:01:58 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 09:01:58 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v2] In-Reply-To: References: Message-ID: <-NLqJNjfFWXKcbdxdRtLnPhX9pye6K406JHWzy6kNTQ=.09e2995d-55aa-4a83-b532-7ab80d0a658f@github.com> On Fri, 30 Jan 2026 04:40:11 GMT, David Holmes wrote: >> A null `java_thread` is only possible for the unmounted vthread case. The oop should always be a valid `java.lang.Thread` though. Maybe `thread_oop` should be initialized to `nullptr` and the assert at line 1914 be just `assert(thread_oop != nullptr, "Missing Thread oop");`? > > Okay so `!is_virtual => java_thread != nullptr`. > Maybe thread_oop should be initialized to nullptr and the assert at line 1914 be just assert(thread_oop != nullptr, "Missing Thread oop");? That would be simpler again, thanks. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29461#discussion_r2745279902 From jpbempel at openjdk.org Fri Jan 30 09:09:58 2026 From: jpbempel at openjdk.org (Jean-Philippe Bempel) Date: Fri, 30 Jan 2026 09:09:58 GMT Subject: RFR: 8376185: NoSuchFieldError thrown after a record with type annotation retransformed [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 08:24:22 GMT, Serguei Spitsyn wrote: >> Jean-Philippe Bempel has updated the pull request incrementally with one additional commit since the last revision: >> >> add copyright headers > > src/hotspot/share/prims/jvmtiRedefineClasses.cpp line 1477: > >> 1475: if (res != JVMTI_ERROR_NONE) { >> 1476: return res; >> 1477: } > > Pending exception need to be processed and cleared below (see lines: 1478-1487). @sspitsyn I am not sure to follow your comment. In the case of invalid structure, no exception was pending and therefore the method `load_new_class_versions` returns no error. if `merge_cp_and_rewrite` returns anything else than `JVMTI_ERROR_NONE` it should be propagated. Now, if you want to process pending exception first I can move the check result after, but for example the call above to `compare_and_normalize_class_versions` is done like this also ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29445#discussion_r2745309806 From ogillespie at openjdk.org Fri Jan 30 09:16:44 2026 From: ogillespie at openjdk.org (Oli Gillespie) Date: Fri, 30 Jan 2026 09:16:44 GMT Subject: RFR: 8376698: Add Spliterator tests for TreeMap sub-maps In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 22:35:58 GMT, Chen Liang wrote: >> I'd rather see it tested explicitly; its hard to identify exactly which test expects and catches the NPE. > > The modification to that test adds new entries to a data provider. The NPE is checked by the preexisting testNullPointerException which tests all speliterators in the data set. I don't think an additional explicit unit test provides much value over the existing "cartesian" setup. Thanks, indeed [testNullPointerException](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java#L668) runs on all of the input spliterators and sizes, and empty is [explicitly](https://github.com/openjdk/jdk/blob/master/test/jdk/java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java#L91) one of the chosen sizes, so I think that's appropriate coverage. Naturally I confirmed that it does fail the tests as expected without the fix. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29485#discussion_r2745337433 From aartemov at openjdk.org Fri Jan 30 09:23:18 2026 From: aartemov at openjdk.org (Anton Artemov) Date: Fri, 30 Jan 2026 09:23:18 GMT Subject: RFR: 8376665: Port fdlibm acosh to Java Message-ID: <08ht2N6I4S-u_HvrYlQ4PN3UJA6veT1b7bQkAojMHII=.0d236244-7faf-4883-9fba-178abfa7c908@github.com> Hi, please consider the following changes: This is a port of FDLIBM acosh method. Original C vs transliteration port: $ diff -w fdlib_acosh.c.txt Acosh.translit.java 1c1,3 < /* __ieee754_acosh(x) --- > /** > * Return the Inverse Hyperbolic Cosine of x > * 7,8c9,10 < * acosh(x) := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else < * acosh(x) := log1p(t+sqrt(2.0*t+t*t)); where t=x-1. --- > * := log(2x-1/(sqrt(x*x-1)+x)) if x>2; else > * := log1p(t+sqrt(2.0*t+t*t)); where t=x-1. 14,31c16,19 < < #include "fdlibm.h" < < #ifdef __STDC__ < static const double < #else < static double < #endif < one = 1.0, < ln2 = 6.93147180559945286227e-01; /* 0x3FE62E42, 0xFEFA39EF */ < < #ifdef __STDC__ < double __ieee754_acosh(double x) < #else < double __ieee754_acosh(x) < double x; < #endif < { --- > private static final class Acosh { > private static final double one = 1.0; > private static final double ln2 = 6.93147180559945286227e-01; > static double compute(double x) { 41c29 < return __ieee754_log(x)+ln2; /* acosh(huge)=log(2x) */ --- > return log(x)+ln2; /* acosh(huge)=log(2x) */ 46c34 < return __ieee754_log(2.0*x-one/(x+sqrt(t-one))); --- > return log(2.0*x-one/(x+sqrt(t-one))); 49a38 > } Transliteration vs more idiomatic port: $ diff -w Acosh.translit.java Acosh.fdlibm.java 5,7c5,9 < * Based on < * acosh(x) = log [ x + sqrt(x*x-1) ] < * we have --- > * > * > * acosh(x) is defined so that acosh(cosh(alpha)) = alpha, -INF < alpha < < INF > * and cosh(acosh(x)) = x, 1 <= x < INF. > * It can be written as acosh(x) = ln(x + sqrt(x^2 - 1)), 1 <= x < INF. 11a14,15 > * > * 16,17c20 < private static final class Acosh { < private static final double one = 1.0; --- > static final class Acosh { 18a22 > 23c27 < if(hx<0x3ff00000) { /* x < 1 */ --- > if(hx < 0x3ff00000) { // x < 1 */ 25,26c29,30 < } else if(hx >=0x41b00000) { /* x > 2**28 */ < if(hx >=0x7ff00000) { /* x is inf of NaN */ --- > } else if (hx >= 0x41b00000) { // x > 2**28 > if(hx >= 0x7ff00000) { // x is inf of NaN 28,29c32,34 < } else < return log(x)+ln2; /* acosh(huge)=log(2x) */ --- > } else { > return Log.compute(x) + ln2; // acosh(huge) = log(2x) > } 31,32c36,37 < return 0.0; /* acosh(1) = 0 */ < } else if (hx > 0x40000000) { /* 2**28 > x > 2 */ --- > return 0.0; // acosh(1) = 0 > } else if (hx > 0x40000000) { // 2**28 > x > 2 34,37c39,42 < return log(2.0*x-one/(x+sqrt(t-one))); < } else { /* 1 return Log.compute(2.0 * x - 1.0 / (x + Sqrt.compute(t - 1.0))); > } else { // 1< x <2 > t = x - 1.0; > return Log1p.compute(t + Sqrt.compute(2.0 * t + t * t)); ------------- Commit messages: - 8376665: Fixed whitespaces. - 8376665: Fixed whitespaces. - 8376665: Ported fdlibm acosh function. Added tests. - Merge remote-tracking branch 'origin/master' into JDK-8375285-port-fdlibm-asinh-to-java - 8375285: Added versions. - 8375285: Addressed the reviewer's comments, fixed year in the copyright notice. - 8375285: Addressed the reviewer's comments. - 8375285: Port of fdlibm asinh function Changes: https://git.openjdk.org/jdk/pull/29488/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29488&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376665 Stats: 1163 lines in 7 files changed: 1149 ins; 0 del; 14 mod Patch: https://git.openjdk.org/jdk/pull/29488.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29488/head:pull/29488 PR: https://git.openjdk.org/jdk/pull/29488 From aturbanov at openjdk.org Fri Jan 30 09:33:34 2026 From: aturbanov at openjdk.org (Andrey Turbanov) Date: Fri, 30 Jan 2026 09:33:34 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v6] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 12:01:46 GMT, Anton Artemov wrote: >> Hi, please consider the following changes: >> >> This is a port of FDLIBM asinh method. >> >> Original C vs transliteration port: >> >> >> $ diff -w fdlib_asinh.c Asinh.translit.java >> 1c1,3 >> < /* asinh(x) >> --- >>> /** >>> * Return the Inverse Hyperbolic Sine of x >>> * >> 2a5 >>> * >> 10a14,17 >>> private static final class Asinh { >>> private static final double one = 1.0; >>> private static final double ln2 = 6.93147180559945286227e-01; >>> private static final double huge = 1.0e300; >> 12,29c19 >> < #include "fdlibm.h" >> < >> < #ifdef __STDC__ >> < static const double >> < #else >> < static double >> < #endif >> < one = 1.00000000000000000000e+00, /* 0x3FF00000, 0x00000000 */ >> < ln2 = 6.93147180559945286227e-01, /* 0x3FE62E42, 0xFEFA39EF */ >> < huge= 1.00000000000000000000e+300; >> < >> < #ifdef __STDC__ >> < double asinh(double x) >> < #else >> < double asinh(x) >> < double x; >> < #endif >> < { >> --- >>> static double compute(double x) { >> 39c29 >> < w = __ieee754_log(fabs(x))+ln2; >> --- >>> w = log(Math.abs(x))+ln2; >> 41,42c31,32 >> < t = fabs(x); >> < w = __ieee754_log(2.0*t+one/(sqrt(x*x+one)+t)); >> --- >>> t = Math.abs(x); >>> w = log(2.0*t+one/(sqrt(x*x+one)+t)); >> 45c35 >> < w =log1p(fabs(x)+t/(one+sqrt(one+t))); >> --- >>> w =log1p(Math.abs(x)+t/(one+sqrt(one+t))); >> 47a38 >>> } >> >> Transliteration port vs more idiomatic port: >> >> >> $ diff -w Asinh.translit.java Asinh.fdlibm.java >> 6,9c6,12 >> < * Based on >> < * asinh(x) = sign(x) * log [ |x| + sqrt(x*x+1) ] >> < * we have >> < * asinh(x) := x if 1+x*x=1, >> --- >>> * >>> * asinh(x) is defined so that asinh(sinh(alpha)) = alpha -INF < alpha < < INF >>> * and sinh(asinh(x)) = x, -INF < x < INF. >>> * It can be written as asinh(x) = ln(x + sqrt(x^2 + 1)), -INF < x < INF. >>> * 1. Replace x by |x| as the function is odd. >>> * 2. >>> * asinh(x) := x, if 1+x^2 = 1, >> 12a16,22 >>> * >>> * >>> * >>> * Special cases: >>> * only asinh(0)=0 is exact for finite x. >>> * asinh(NaN) is NaN >>> * asinh(INF) is INF >> 14,15c24 >> < private static final class Asinh { >> < private static final double one = 1.0; >> --- >>> static final class Asinh { >> 24c33,35 >> < if(ix>=0x7ff00000) return x+x; /* x is inf or NaN */ >> --- >>> if(ix >= 0x7ff00000) { >>> return x... > > Anton Artemov has updated the pull request incrementally with one additional commit since the last revision: > > 8375285: Added missed link in documentation. Yes. It was about rewriting implementation of existing method. But here we got a brand new method. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3822743503 From mbaesken at openjdk.org Fri Jan 30 09:45:22 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jan 2026 09:45:22 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code Message-ID: libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. ------------- Commit messages: - JDK-8376703 Changes: https://git.openjdk.org/jdk/pull/29502/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29502&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376703 Stats: 69 lines in 5 files changed: 0 ins; 69 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29502.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29502/head:pull/29502 PR: https://git.openjdk.org/jdk/pull/29502 From chagedorn at openjdk.org Fri Jan 30 10:47:17 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 30 Jan 2026 10:47:17 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v7] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Thu, 29 Jan 2026 12:42:44 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8374582: add flagless to test src/hotspot/share/opto/library_call.cpp line 894: > 892: > 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region, > 894: Node* *pos_index, bool is_opaque) { Suggestion: Node** pos_index, bool is_opaque) { ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745638291 From chagedorn at openjdk.org Fri Jan 30 10:47:19 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Fri, 30 Jan 2026 10:47:19 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v3] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Wed, 28 Jan 2026 16:02:56 GMT, Damon Fenacci wrote: >> src/hotspot/share/opto/opaquenode.hpp line 150: >> >>> 148: bool _positive; >>> 149: public: >>> 150: OpaqueCheckNode(Compile* C, Node* tst, bool positive) : Node(nullptr, tst), _positive(positive) { >> >> `tst` is probably almost always a `BoolNode`. I'm wondering if it could also be a constant because we already folded the `BoolNode`? But then it's probably also useless to create the opaque node in the first place. > > Hmmm... I find it hard to totally exclude a constant (e.g. if its inputs are constant...?). In that case we could skip all the opaque business (I guess in the few places where new `OpaqueConstantBool` nodes are created). On the other hand the opaque node should only really delay the folding... ? I think folding is fine since we implement `Value()` to take the input's `Value()`. My understanding is that we insert an additional check that is actually not needed because we already checked it in Java code. So, it should be true at that point but C2 does not know that. We still insert the check in order to make sure to also fold control away if data is dying. Once we know that data will not die anymore, we can remove the useless check again. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2745545348 From alanb at openjdk.org Fri Jan 30 12:20:04 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 12:20:04 GMT Subject: RFR: 8376568: Change Thread::getStackTrace to use handshake op for all cases [v3] In-Reply-To: References: Message-ID: > JDK-8364343 upgraded the virtual thread transition management to be independent of JVMTI. We can update java_lang_Thread::async_get_stack_trace to use it and remove the suspend + retry code from Thread.getStackTrace. > > A summary of the changes: > > - java_lang_Thread::async_get_stack_trace is changed to use the new handshake op so it can be called to get the stack trace of a started thread in any state > - Thread::getStackTrace is changed to use async_get_stack_trace for all cases > - The SUSPENDED substate in VirtualThread is removed > - JVM_CreateThreadSnapshot is changed to be usable when JVMTI is not compiled in > - ThreadSnapshotFactory::get_thread_snapshot is changed to not upcall to StackTraceElement to complete the init of the stack trace > > The changes mean that Thread::getStackTrace may be slower when sampling a virtual thread in transition. This case should be rare, and it isn't really a performance critical op anyway. I prototyped use a spin loop and an increasing wait time in MountUnmountDisabler::disable_transition_for_one to avoid the wait(10) but decided to leave it out for now. Future work may examine this issue as there may be other cases (with JVMTI) that would benefit from avoiding the wait. > > A future PR might propose to change Thread.getStackTrace to use ThreadSnapshot and allow java_lang_Thread::async_get_stack_trace be removed. This requires more extensive changes to ThreadSnapshotFactory to reduce overhead when only the stack trace is required. > > Testing: tier1-5. The changes has been already been tested in the loom repo for a few months. Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision: - Merge branch 'master' into JDK-8376568 - Review feedback - Improve asserts - Cleanup - Merge branch 'master' into Thread.getStackTrace - Initial commit ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29461/files - new: https://git.openjdk.org/jdk/pull/29461/files/12214cd8..1b7c9ad7 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29461&range=01-02 Stats: 5098 lines in 109 files changed: 3579 ins; 1148 del; 371 mod Patch: https://git.openjdk.org/jdk/pull/29461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29461/head:pull/29461 PR: https://git.openjdk.org/jdk/pull/29461 From alanb at openjdk.org Fri Jan 30 12:25:05 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 12:25:05 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:08:06 GMT, Naoto Sato wrote: > Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant. There is already syncrhonization at the stream level so I think it is okay to do this. Would it be good to have another set of eyes on this too. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29493#issuecomment-3823471993 From alanb at openjdk.org Fri Jan 30 12:28:47 2026 From: alanb at openjdk.org (Alan Bateman) Date: Fri, 30 Jan 2026 12:28:47 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 09:30:14 GMT, Matthias Baesken wrote: > libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . > We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. > On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. This looks okay but would be good to confirm what builds + testing were done. Also can you update the Oracle copyright on these files as it's the first change to them in 2026. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823506738 From mbaesken at openjdk.org Fri Jan 30 12:41:33 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jan 2026 12:41:33 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References: Message-ID: > libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . > We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. > On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: Adjust COPYRIGHT headers ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29502/files - new: https://git.openjdk.org/jdk/pull/29502/files/bcfda923..8a68ef39 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29502&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29502&range=00-01 Stats: 4 lines in 4 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29502.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29502/head:pull/29502 PR: https://git.openjdk.org/jdk/pull/29502 From pminborg at openjdk.org Fri Jan 30 12:43:38 2026 From: pminborg at openjdk.org (Per Minborg) Date: Fri, 30 Jan 2026 12:43:38 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 21:08:06 GMT, Naoto Sato wrote: > Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant. src/java.base/share/classes/java/io/ProxyingConsole.java line 37: > 35: * provided with jdk.internal.io.JdkConsoleProvider. > 36: */ > 37: final class ProxyingConsole extends Console { Would it make sense to make all the classes in this file records and/or value classes, as all the fields are `final`? src/java.base/share/classes/java/io/ProxyingConsole.java line 40: > 38: private final JdkConsole delegate; > 39: private final LazyConstant reader = LazyConstant.of(this::initReader); > 40: private final LazyConstant printWriter = LazyConstant.of(this::initPrintWriter); Great to see `LazyConstant` replacing DCLs! I wonder if we should use an anonymous class here rather than a lambda to improve startup time? I've made that in some other places in the JDK. Something to think about. src/java.base/share/classes/java/io/ProxyingConsole.java line 53: > 51: @Override > 52: public PrintWriter writer() { > 53: PrintWriter printWriter = this.printWriter; So nice to get rid of such code segments! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2746083379 PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2746092237 PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2746098793 From mbaesken at openjdk.org Fri Jan 30 12:48:20 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jan 2026 12:48:20 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 12:26:20 GMT, Alan Bateman wrote: > This looks okay but would be good to confirm what builds + testing were done. Also can you update the Oracle copyright on these files as it's the first change to them in 2026. I adjusted the COPYRIGHT headers . Builds are okay (AIX, Linux, macOS , Windows). Tests (jtreg HS and JDK) look so far good as well, but on some slower platforms a number of tiers still have to be executed (will most likely follow in the next few hours) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823582723 From mbaesken at openjdk.org Fri Jan 30 12:55:07 2026 From: mbaesken at openjdk.org (Matthias Baesken) Date: Fri, 30 Jan 2026 12:55:07 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 12:41:33 GMT, Matthias Baesken wrote: >> libjimage has a few unused functions/methods; those are listed when logging elimination with -Wl,--gc-sections -Wl,--print-gc-sections . >> We could remove them (or with if are still needed for completeness put them into #if 0 ) to reduce lib size on Linux and AIX. >> On Windows and macOS it seems the compiler/linker default settings are good enough to eliminate the code. > > Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision: > > Adjust COPYRIGHT headers one interesting finding seems to be that the linktime-gc can eliminate more methods like `ZipDecompressor::decompress(void*, unsigned long, void*, unsigned long, char**)` which is printed as removed ` /usr/lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/bin/ld: removing unused section '.text._ZN15ZipDecompressor10decompressEPvyS0_yPPc' in file '/builddir/support/native/java.base/libjimage/imageDecompressor.o'` but this is not unused/uncalled in our codebase. I think it is inlined at the 1 or 2 points were it is used. But the method is still generated into the library even in case that it is always inlined ; it may be difficult to address this with the usual linker settings on Linux (means without linktime-gc or LTO or similar stuff ) . ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3823600664 From dfenacci at openjdk.org Fri Jan 30 13:56:01 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Fri, 30 Jan 2026 13:56:01 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v8] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374582: fix star layout Co-authored-by: Christian Hagedorn ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/083d5698..c5390e4a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=07 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=06-07 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From cushon at openjdk.org Fri Jan 30 14:32:19 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 30 Jan 2026 14:32:19 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v16] In-Reply-To: References: Message-ID: <3tyFN2PROU4kkRO5MICX8E01SajaBatOT7vK4Bv-h7Q=.bff53067-5443-4c3b-a1d4-e7708b9d8af1@github.com> > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Update javadoc to refer to 'this {@code String}', not 'the given String' ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/51bf1510..6acd1191 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=14-15 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From rriggs at openjdk.org Fri Jan 30 14:57:17 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 30 Jan 2026 14:57:17 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out In-Reply-To: References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: On Fri, 30 Jan 2026 01:16:52 GMT, SendaoYan wrote: >> Having just updated this test, I would have been interested in fixing any follow on problems myself. > > Do you mean I should close this PR, and you will create a new one. That would be a good option. I would be ok with only increasing the timeout. That would avoid customizing the test to an older OS version and retain the extra information useful for debugging. Since it is intermittent, the current timeout is in the ballpark, so doubling it would be ok. Older OS versions will be replaced in time, but if we complicate the test code, that will stay indefinitely. Please wait to remove the test from the ProblemList. When I fix: [JDK-8375585](https://bugs.openjdk.org/browse/JDK-8375585) I'll take it off the problem list. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2746676005 From duke at openjdk.org Fri Jan 30 15:20:03 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Fri, 30 Jan 2026 15:20:03 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v15] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Use `codePointCountSB` and add its test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/198b3188..585ce36e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=14 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=13-14 Stats: 3 lines in 2 files changed: 1 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Fri Jan 30 15:24:54 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Fri, 30 Jan 2026 15:24:54 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 23:29:40 GMT, Naoto Sato wrote: > Bonus if you could rename each testX to testMethodName "`testCodePointCount`" has already been occupied: https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L365-L376 https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L247-L251 ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2746778790 From liach at openjdk.org Fri Jan 30 15:40:36 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 15:40:36 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v15] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 15:20:03 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 one additional commit since the last revision: > > Use `codePointCountSB` and add its test Since we are touching `CharSequence`, we might need to revise `CharBuffer` (through `X-Buffer.java.template`) to specify `codePointCount` is a relative operation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3824360182 From cushon at openjdk.org Fri Jan 30 15:56:20 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 30 Jan 2026 15:56:20 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v17] In-Reply-To: References: Message-ID: > This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. > > --- > > > Benchmark (encoding) (stringLength) Mode Cnt Score Error Units > StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s > StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s > StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s > StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s > StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s > StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s > StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s > StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s > StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.130 ? 3839233.582 ops/s > StringLoopJmhBenchmark.ge... Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: Rename getBytesLength to getByteLength ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28454/files - new: https://git.openjdk.org/jdk/pull/28454/files/6acd1191..f23b5c24 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28454&range=15-16 Stats: 15 lines in 5 files changed: 0 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/28454.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28454/head:pull/28454 PR: https://git.openjdk.org/jdk/pull/28454 From cushon at openjdk.org Fri Jan 30 15:56:21 2026 From: cushon at openjdk.org (Liam Miller-Cushon) Date: Fri, 30 Jan 2026 15:56:21 GMT Subject: RFR: 8372353: API to compute the byte length of a String encoded in a given Charset [v16] In-Reply-To: <3tyFN2PROU4kkRO5MICX8E01SajaBatOT7vK4Bv-h7Q=.bff53067-5443-4c3b-a1d4-e7708b9d8af1@github.com> References: <3tyFN2PROU4kkRO5MICX8E01SajaBatOT7vK4Bv-h7Q=.bff53067-5443-4c3b-a1d4-e7708b9d8af1@github.com> Message-ID: On Fri, 30 Jan 2026 14:32:19 GMT, Liam Miller-Cushon wrote: >> This implements an API to return the byte length of a String encoded in a given charset. See [JDK-8372353](https://bugs.openjdk.org/browse/JDK-8372353) for background. >> >> --- >> >> >> Benchmark (encoding) (stringLength) Mode Cnt Score Error Units >> StringLoopJmhBenchmark.getBytes ASCII 10 thrpt 5 406782650.595 ? 16960032.852 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100 thrpt 5 172936926.189 ? 4532029.201 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 1000 thrpt 5 38830681.232 ? 2413274.766 ops/s >> StringLoopJmhBenchmark.getBytes ASCII 100000 thrpt 5 458881.155 ? 12818.317 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 10 thrpt 5 37193762.990 ? 3962947.391 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100 thrpt 5 55400876.236 ? 1267331.434 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 1000 thrpt 5 11104514.001 ? 41718.545 ops/s >> StringLoopJmhBenchmark.getBytes LATIN1 100000 thrpt 5 182535.414 ? 10296.120 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 10 thrpt 5 113474681.457 ? 8326589.199 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100 thrpt 5 37854103.127 ? 4808526.773 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 1000 thrpt 5 4139833.009 ? 70636.784 ops/s >> StringLoopJmhBenchmark.getBytes UTF16 100000 thrpt 5 57644.637 ? 1887.112 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 10 thrpt 5 946701647.247 ? 76938927.141 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100 thrpt 5 396615374.479 ? 15167234.884 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 1000 thrpt 5 100464784.979 ? 794027.897 ops/s >> StringLoopJmhBenchmark.getBytesLength ASCII 100000 thrpt 5 1215487.689 ? 1916.468 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 10 thrpt 5 221265102.323 ? 17013983.056 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 100 thrpt 5 137617873.887 ? 5842185.781 ops/s >> StringLoopJmhBenchmark.getBytesLength LATIN1 1000 thrpt 5 92540259.1... > > Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision: > > Update javadoc to refer to 'this {@code String}', not 'the given String' I have made some updates including to the CSR [JDK-8375318](https://bugs.openjdk.org/browse/JDK-8375318) * a Javadoc oversight: "the given String" was updated to "this {@code String}" (the string being operated on is the current instance, not an input to the method). * the method name: I now prefer the name `getByteLength`, which was raised by @jddarcy in the CSR. I think `getBytesLength` is also OK. I updated the CSR to discuss some pros and cons * whether the method should return `int` or `long`. I think that `int` (as originally proposed) is better, but have updated the CSR to discuss that alternative in more detail. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28454#issuecomment-3824421699 From naoto at openjdk.org Fri Jan 30 16:09:57 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 16:09:57 GMT Subject: RFR: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets [v4] In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 23:56:36 GMT, Naoto Sato wrote: >> This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. > > Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: > > +00/-00 offsets tests Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29393#issuecomment-3824486290 From naoto at openjdk.org Fri Jan 30 16:13:38 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 16:13:38 GMT Subject: Integrated: 8210336: DateTimeFormatter predefined formatters should support short time zone offsets In-Reply-To: References: Message-ID: On Fri, 23 Jan 2026 20:34:24 GMT, Naoto Sato wrote: > This PR is a follow-on fix to [JDK-8032051](https://bugs.openjdk.org/browse/JDK-8032051), where it allowed short offsets only for ZonedDateTime parsing. This fix allows all predefined ISO formatters to accept short offsets. A corresponding CSR has been drafted. This pull request has now been integrated. Changeset: c1c543cc Author: Naoto Sato URL: https://git.openjdk.org/jdk/commit/c1c543cc81b4b73ebf228fb817227309b0cff990 Stats: 80 lines in 3 files changed: 76 ins; 1 del; 3 mod 8210336: DateTimeFormatter predefined formatters should support short time zone offsets Reviewed-by: jlu, rriggs ------------- PR: https://git.openjdk.org/jdk/pull/29393 From cstein at openjdk.org Fri Jan 30 16:19:07 2026 From: cstein at openjdk.org (Christian Stein) Date: Fri, 30 Jan 2026 16:19:07 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 Message-ID: Please review the change to update to using jtreg 8.2.1. The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. ------------- Commit messages: - 8376355: Update to use jtreg 8.2.1 - 8376355: Update to use jtreg 8.2 Changes: https://git.openjdk.org/jdk/pull/29452/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29452&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376355 Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/29452.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29452/head:pull/29452 PR: https://git.openjdk.org/jdk/pull/29452 From naoto at openjdk.org Fri Jan 30 16:23:15 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 16:23:15 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 15:21:39 GMT, Tatsunori Uchino wrote: >> test/jdk/java/lang/StringBuilder/Supplementary.java line 218: >> >>> 216: >>> 217: /** >>> 218: * Test codePointCount(int, int) & codePointCount() >> >> I think a separate test method needs to be added solely for `codePointCount()` to follow the pattern in this test file. Bonus if you could rename each `testX` to `testMethodName` >> (This test seems to have a lot of room for refactoring, but they are for another time) > >> Bonus if you could rename each testX to testMethodName > > "`testCodePointCount`" has already been occupied: > > https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L365-L376 > > https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L247-L251 We could distinguish them like `testCodePointCountNoArg` and `testCodePointCountTwoArgs` ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2747019135 From iris at openjdk.org Fri Jan 30 16:28:47 2026 From: iris at openjdk.org (Iris Clark) Date: Fri, 30 Jan 2026 16:28:47 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8.2.1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Marked as reviewed by iris (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729267371 From naoto at openjdk.org Fri Jan 30 16:54:06 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 16:54:06 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking [v2] In-Reply-To: References: Message-ID: > Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant. Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: - Made ProxyingConsole value-based, used anonymous class for LazyConstant - Refine exceptions ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29493/files - new: https://git.openjdk.org/jdk/pull/29493/files/28297eae..4848c481 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29493&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29493&range=00-01 Stats: 27 lines in 2 files changed: 15 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29493/head:pull/29493 PR: https://git.openjdk.org/jdk/pull/29493 From naoto at openjdk.org Fri Jan 30 16:54:08 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 16:54:08 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 12:37:08 GMT, Per Minborg wrote: >> Naoto Sato has updated the pull request incrementally with two additional commits since the last revision: >> >> - Made ProxyingConsole value-based, used anonymous class for LazyConstant >> - Refine exceptions > > src/java.base/share/classes/java/io/ProxyingConsole.java line 37: > >> 35: * provided with jdk.internal.io.JdkConsoleProvider. >> 36: */ >> 37: final class ProxyingConsole extends Console { > > Would it make sense to make all the classes in this file records and/or value classes, as all the fields are `final`? Right, I annotated the class with `@ValueBased`, as it has to extend `Console` class. > src/java.base/share/classes/java/io/ProxyingConsole.java line 53: > >> 51: @Override >> 52: public PrintWriter writer() { >> 53: PrintWriter printWriter = this.printWriter; > > So nice to get rid of such code segments! Yes! It's a bliss ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2747132900 PR Review Comment: https://git.openjdk.org/jdk/pull/29493#discussion_r2747134487 From sviswanathan at openjdk.org Fri Jan 30 17:16:32 2026 From: sviswanathan at openjdk.org (Sandhya Viswanathan) Date: Fri, 30 Jan 2026 17:16:32 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 19:43:27 GMT, Sandhya Viswanathan wrote: >> ### Int VectorBulkOperationsArray Fill >> >> Benchmark (ns/op) | Size | -OptimizeFill (JITed code) | +OptimizeFill (Masked store) | +OptimizeFill (Unmasked store - This PR) | Delta (masked vs. unmasked) >> -- | -- | -- | -- | -- | -- >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 0 | 0.649 | 0.651 | 0.655 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 1 | 2.371 | 2.801 | 2.827 | 1% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 2 | 2.374 | 2.585 | 2.942 | 12% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 3 | 2.809 | 2.589 | 3.094 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 4 | 3.356 | 2.587 | 2.852 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 5 | 3.531 | 2.588 | 3.158 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 6 | 3.747 | 2.589 | 3.118 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 7 | 3.989 | 2.589 | 3.332 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 8 | 5.047 | 2.588 | 2.832 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 9 | 4.79 | 2.845 | 3.056 | 7% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 10 | 4.982 | 2.85 | 3.274 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 11 | 4.551 | 2.852 | 3.521 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 12 | 4.281 | 2.853 | 3.12 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 13 | 4.391 | 2.894 | 3.499 | 17% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 14 | 4.909 | 2.848 | 3.339 | 15% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 15 | 5.269 | 2.853 | 3.524 | 19% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 16 | 5.663 | 2.836 | 3.101 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 17 | 5.553 | 2.924 | 3.111 | 6% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 18 | 5.105 | 2.933 | 3.358 | 13% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 19 | 5.09 | 2.942 | 3.583 | 18% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 20 | 4.457 | 2.927 | 3.272 | 11% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 21 | 4.745 | 3.104 | 3.598 | 14% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 22 | 4.949 | 2.932 | 3.481 | 16% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 23 | 4.992 | 2.939 | 3.761 | 22% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 24 | 5.198 | 2.92 | 3.205 | 9% >> VectorBulkOperationsArray.fill_var_int_arrays_fill | 25 | 5.... > >> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >> > >> > >> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >> >> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? > > @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. > @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > > > The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. > > Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? > > If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? > > Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? > > I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. > > We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. > > Does that make sense? Or do you have a better idea how to make a good decision here? @eme64 Again very good points and suggestions as always. One of the data points that you are requesting is visible from the ByteMatrix numbers posted in PR description. If you see the second column vs fourth column in the table, i.e. +OptimizeFill (Masked store stub) vs +OptimizeFill (Unmasked store stub), you can see that for up to 48 bytes we see significant performance improvement with unmasked scalar stores over masked vector store. Between 48 to 64 byte masked store wins. The same behavior repeats for size range 64-128 bytes as that would involve an unmasked 64 byte vector write, followed by a 64 byte masked write. This is all assuming that the on the platform that Vamsi ran this, we are using 64 byte vectors. Vamsi should be able to confirm this. Regarding whether the slow down is due to masked stores stalls, that was my hypothesis based on the optimization guide, excerpts of which Vamsi shared above. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3824789519 From yassine.damerdji at uliege.be Fri Jan 30 17:21:30 2026 From: yassine.damerdji at uliege.be (Yassine Damerdji) Date: Fri, 30 Jan 2026 18:21:30 +0100 Subject: Simultaneous computation of cosine and sine In-Reply-To: <3baf27d7-2399-434b-af2e-44b509091e14@uliege.be> References: <3baf27d7-2399-434b-af2e-44b509091e14@uliege.be> Message-ID: Dear all, I am a scientist and a Java developer in the ESA/DPAC consortium (https://www.cosmos.esa.int/web/gaia/dpac). I downloaded FdLibm.java from the Open-JDK project, and I wrote a function which computes simultaneously the cosine and sine of an angle. Indeed, in science we very often need both of the cosine and the sine in our computations. I noticed that we can save 25% of the processing time compared to two separate calls to the cos and sin functions. The reason for this is that we won't repeat the common function they share. My local tests were missing the JDK '@stable' annotation, which optimizes a lot and is not possible to keep in my local tests. It would be great if we could include the new function in the official OpenJDK project. I attach my local version of FdLibm.java (without @stable annotations) including the class SinCos (line 2483). Many thanks in advance, Yassine PS : Mr Ivanov redirected me to this mailing list. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: FdLibm.java Type: text/x-java Size: 133306 bytes Desc: not available URL: From jlu at openjdk.org Fri Jan 30 17:45:20 2026 From: jlu at openjdk.org (Justin Lu) Date: Fri, 30 Jan 2026 17:45:20 GMT Subject: Integrated: 8376038: Refactor java/sql tests to use JUnit In-Reply-To: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> References: <5PtjcX3iuO7MfVKynMJZywyqoY2_T1lqHrVQtmsfCE0=.1c3d37be-a86a-47d0-b759-8e4c06cfb78c@github.com> Message-ID: On Thu, 22 Jan 2026 00:41:13 GMT, Justin Lu wrote: > Please review this PR which converts the JDBC TestNG tests to use JUnit. > > This is mainly done using the automated tool in https://github.com/openjdk/jdk/commit/0cec3097aec02e72ccb6ebbf0b2b046220578d1b, with some manual follow up commits. The testng folder is migrated to junit with the TEST.properties updated as well. Most changes are annotation updates and switching from testNG imports to JUnit. I decided to simplify cases of `BaseTest.trueFalse()` to use booleans in a `ValueSource` directly in https://github.com/openjdk/jdk/commit/757e7966666d39748db2912b32ccf8b1df18bd62. > > Framework test stats before: > 680 = 680 TestNG + 0 JUnit > > Framework test stats after: > 680 = 0 TestNG + 680 JUnit This pull request has now been integrated. Changeset: ee60eff1 Author: Justin Lu URL: https://git.openjdk.org/jdk/commit/ee60eff1ec9eddcdedc12c1707fbcca0025e71d6 Stats: 20245 lines in 134 files changed: 10219 ins; 9841 del; 185 mod 8376038: Refactor java/sql tests to use JUnit 8376629: Refactor javax/sql tests to use JUnit Reviewed-by: lancea ------------- PR: https://git.openjdk.org/jdk/pull/29354 From erikj at openjdk.org Fri Jan 30 17:46:27 2026 From: erikj at openjdk.org (Erik Joelsson) Date: Fri, 30 Jan 2026 17:46:27 GMT Subject: RFR: 8376355: Update to use jtreg 8.2.1 In-Reply-To: References: Message-ID: On Tue, 27 Jan 2026 15:26:20 GMT, Christian Stein wrote: > Please review the change to update to using jtreg 8.2.1. > > The primary change is to the `jib-profiles.js` file, which specifies the version of jtreg to use, for those systems that rely on this file. In addition, the `requiredVersion` has been updated in the various `TEST.ROOT` files. Marked as reviewed by erikj (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29452#pullrequestreview-3729610652 From sparasa at openjdk.org Fri Jan 30 19:29:45 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 19:29:45 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 17:13:49 GMT, Sandhya Viswanathan wrote: > Vamsi should be able to confirm this. Regarding whether the slow down is due to masked stores stalls, that was my hypothesis > based on the optimization guide, excerpts of which Vamsi shared above. > The MaxVectorSize=64 for the platform used to collect the data in the PR's description for ByteMatrix fill workload. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3825339469 From sparasa at openjdk.org Fri Jan 30 19:29:47 2026 From: sparasa at openjdk.org (Srinivas Vamsi Parasa) Date: Fri, 30 Jan 2026 19:29:47 GMT Subject: RFR: 8349452: Fix performance regression for Arrays.fill() with AVX512 [v13] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 08:33:57 GMT, Emanuel Peter wrote: >>> > > @vamsi-parasa Ok, so now we have one benchmark that shows a speedup and one that shows a regression. How are we to proceed? >>> > > It seems that without loads [#28442 (comment)](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799), this patch leads to a regression. >>> > > Only if there is a load from one of the last elements that the `Arrays.fill` stored to with a masked operation do we get a slowdown. Because of missing load-to-store forwarding. If we instead started loading from the first elements, those would probably already be in cache, and we would not have any latency issues, right? >>> > > But is it not rather an edge-case that we load from the last elements immediately after the `Arrays.fill`? At least for longer arrays, it seems an edge case. For short arrays it is probably more likely that we access the last element soon after the fill. >>> > > It does not seem like a trivial decision to me if this patch is an improvement or not. What do you think @vamsi-parasa ? >>> > > @sviswa7 @dwhite-intel You already approved this PR. What are your thoughts here? >>> > >>> > >>> > @eme64 My thoughts are to go ahead with this PR replacing masked stores with scalar tail processing. As we have seen from https://bugs.openjdk.org/browse/JDK-8349452 masked stores can cause big regression in certain scenarios: accessing elements just written or any other adjacent data that happens to fall in the masked store range. >>> >>> @sviswa7 But once this PR is integrated, I could file a performance regression with the benchmarks from [up here](https://github.com/openjdk/jdk/pull/28442#issuecomment-3761659799). So what's the argument which choice is better, since we have a mix of speedups/regression going either way, and both are probably in the 10-20% range? >> >> @eme64 You have a point there, but if you see the performance numbers for ByteMatrix.java (from JDK-8349452) in the PR description above we are talking about a recovery of 3x or so. The ByteMatrix.java is doing only Arrays.fill() on individual arrays of a 2D array. The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. That was the reason to look for a solution without masked stores. > > @sviswa7 Ah right, the ByteMatrix.java is yet another case. There, we don't seem to have any loads. > >> The individual arrays happened to be allocated alongside each other by the JVM and the next store sees stalls due to the masked store of previous array initialization. > > Ah, that sounds interesting! Is there some tool that would let me see that it was due to masked store stalls? > My (probably uneducated) guess would have been that it is just because a single element store would be much cheaper than a masked operation. If you only access a single or 2 elements, then a masked store is not yet profitable. What if the masked stores were a bit further away, say a cacheline away? Would that be significantly faster, because there are no stalls? Or still slow because of the inherent higher cost of masked operations? > > If we take the ByteMatrix.java benchmark: how would the performance change if we increase the size of the arrays (height)? Is there some height before which the non-masked solution is faster, and after which the masked is faster? > > Would it be a solution to use scalar stores for very small arrays, and only use the masked loop starting at a certain threshold? > > ----------------------- > > I would like to see a summary of all the benchmarks we have here, and in which cases we get speedups/slowdowns, and for which reason. Maybe listing those reasons lets us see some third option we did not yet consider. And listing all the reasons and code shapes may help us find out which shapes we care about most, and then come to a decision that weighs off the pros and cons. > > We should also document our decision nicely in the code, so that if someone gets a regression in the future, we can see if we had already considered that code shape. > > Does that make sense? Or do you have a better idea how to make a good decision here? Hi Emanuel (@eme64), Based on the discussion, I will run further experiments to see if the regressions can be addressed and get back to you at a later date. Thanks, Vamsi ------------- PR Comment: https://git.openjdk.org/jdk/pull/28442#issuecomment-3825349231 From raffaello.giulietti at oracle.com Fri Jan 30 20:43:43 2026 From: raffaello.giulietti at oracle.com (Raffaello Giulietti) Date: Fri, 30 Jan 2026 20:43:43 +0000 Subject: Simultaneous computation of cosine and sine In-Reply-To: References: <3baf27d7-2399-434b-af2e-44b509091e14@uliege.be> Message-ID: Dear Yassine, you proposal would be a welcome addition. To contribute to the OpenJDK, you or your employer would need to sign the Oracle Contributor Agreement (OCA) [1]. I recommend you read the first 2 or 3 sections of the OpenJDK Developers? Guide [2] for the details before submitting any patch. HTH Raffaello Giulietti ---- [1] https://oca.opensource.oracle.com [2] https://openjdk.org/guide ________________________________________ From: core-libs-dev on behalf of Yassine Damerdji Sent: Friday, January 30, 2026 18:21 To: core-libs-dev at openjdk.org Subject: Simultaneous computation of cosine and sine Dear all, I am a scientist and a Java developer in the ESA/DPAC consortium (https://www.cosmos.esa.int/web/gaia/dpac). I downloaded FdLibm.java from the Open-JDK project, and I wrote a function which computes simultaneously the cosine and sine of an angle. Indeed, in science we very often need both of the cosine and the sine in our computations. I noticed that we can save 25% of the processing time compared to two separate calls to the cos and sin functions. The reason for this is that we won't repeat the common function they share. My local tests were missing the JDK '@stable' annotation, which optimizes a lot and is not possible to keep in my local tests. It would be great if we could include the new function in the official OpenJDK project. I attach my local version of FdLibm.java (without @stable annotations) including the class SinCos (line 2483). Many thanks in advance, Yassine PS : Mr Ivanov redirected me to this mailing list. From dcubed at openjdk.org Fri Jan 30 20:47:42 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 20:47:42 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files Message-ID: A trivial fix to add preview project anchors to main-line ProblemList files. Also backports changes from the Valhalla repo to make/RunTests.gmk to support ProblemList-coh.txt files. This PR also includes the new ProblemList-coh.txt file, but it contains no entries (yet). Since this is NOT a complete backport of the changes for: - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 I'm not handling it as a backport issue. I've also added missing Copyright headers to some files. ------------- Commit messages: - Merge branch 'master' into JDK-8376751 - 8376751: add preview project anchors to main-line ProblemList files Changes: https://git.openjdk.org/jdk/pull/29509/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29509&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8376751 Stats: 402 lines in 26 files changed: 380 ins; 2 del; 20 mod Patch: https://git.openjdk.org/jdk/pull/29509.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29509/head:pull/29509 PR: https://git.openjdk.org/jdk/pull/29509 From joe.darcy at oracle.com Fri Jan 30 21:15:23 2026 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 30 Jan 2026 13:15:23 -0800 Subject: Simultaneous computation of cosine and sine In-Reply-To: References: <3baf27d7-2399-434b-af2e-44b509091e14@uliege.be> Message-ID: PS I've filed ? ? JDK-8376833:?Add sincos method to math library ? ? https://bugs.openjdk.org/browse/JDK-8376833 to track this enhancement. -Joe On 1/30/2026 12:43 PM, Raffaello Giulietti wrote: > Dear Yassine, > > you proposal would be a welcome addition. > > To contribute to the OpenJDK, you or your employer would need to sign the Oracle Contributor Agreement (OCA) [1]. > I recommend you read the first 2 or 3 sections of the OpenJDK Developers? Guide [2] for the details before submitting any patch. > > > HTH > Raffaello Giulietti > > ---- > > [1] https://oca.opensource.oracle.com > [2] https://openjdk.org/guide > > ________________________________________ > From: core-libs-dev on behalf of Yassine Damerdji > Sent: Friday, January 30, 2026 18:21 > To: core-libs-dev at openjdk.org > Subject: Simultaneous computation of cosine and sine > > Dear all, > > I am a scientist and a Java developer in the ESA/DPAC consortium (https://www.cosmos.esa.int/web/gaia/dpac). > > I downloaded FdLibm.java from the Open-JDK project, and I wrote a function which computes simultaneously the cosine and sine of an angle. Indeed, in science we very often need both of the cosine and the sine in our computations. > > I noticed that we can save 25% of the processing time compared to two separate calls to the cos and sin functions. The reason for this is that we won't repeat the common function they share. > > My local tests were missing the JDK '@stable' annotation, which optimizes a lot and is not possible to keep in my local tests. > > It would be great if we could include the new function in the official OpenJDK project. > > I attach my local version of FdLibm.java (without @stable annotations) including the class SinCos (line 2483). > > Many thanks in advance, > > Yassine > > PS : Mr Ivanov redirected me to this mailing list. From darcy at openjdk.org Fri Jan 30 21:23:26 2026 From: darcy at openjdk.org (Joe Darcy) Date: Fri, 30 Jan 2026 21:23:26 GMT Subject: RFR: 8375285: Port fdlibm asinh to Java [v4] In-Reply-To: References: Message-ID: On Thu, 29 Jan 2026 10:29:37 GMT, Andrey Turbanov wrote: > BTW, should issue/PR name be something like "Add asinh() methods to Math and to StrictMath" ? (Similar to https://bugs.openjdk.org/browse/JDK-8301226) I mean main thing we do here - is to introduce new method. Source of original code - is just implementation details. The current title of the issue may not be ideal, but I don't think it rises to the level of needed to be changed before integration. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29273#issuecomment-3825804345 From kvn at openjdk.org Fri Jan 30 21:44:27 2026 From: kvn at openjdk.org (Vladimir Kozlov) Date: Fri, 30 Jan 2026 21:44:27 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by kvn (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730502656 From liach at openjdk.org Fri Jan 30 21:44:29 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 21:44:29 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. test/langtools/ProblemList-enable-preview.txt line 2: > 1: # > 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. Suggestion: # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748067121 From rriggs at openjdk.org Fri Jan 30 22:11:03 2026 From: rriggs at openjdk.org (Roger Riggs) Date: Fri, 30 Jan 2026 22:11:03 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by rriggs (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730618431 From liach at openjdk.org Fri Jan 30 22:11:05 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:11:05 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. Marked as reviewed by liach (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29509#pullrequestreview-3730624896 From dcubed at openjdk.org Fri Jan 30 22:11:07 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:11:07 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> On Fri, 30 Jan 2026 21:40:57 GMT, Chen Liang wrote: >> A trivial fix to add preview project anchors to main-line ProblemList files. >> >> Also backports changes from the Valhalla repo to make/RunTests.gmk >> to support ProblemList-coh.txt files. This PR also includes the new >> ProblemList-coh.txt file, but it contains no entries (yet). Since this is >> NOT a complete backport of the changes for: >> >> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 >> >> I'm not handling it as a backport issue. >> >> I've also added missing Copyright headers to some files. > > test/langtools/ProblemList-enable-preview.txt line 2: > >> 1: # >> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. > > Suggestion: > > # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"... ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748155579 From liach at openjdk.org Fri Jan 30 22:11:07 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:11:07 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> References: <5KuEFNvmGHPEBUYJUuh27qLS60OEJd9Oh2DGPl0lg_c=.88506f78-3713-4217-895a-2c672d0b4a97@github.com> Message-ID: On Fri, 30 Jan 2026 22:04:58 GMT, Daniel D. Daugherty wrote: >> test/langtools/ProblemList-enable-preview.txt line 2: >> >>> 1: # >>> 2: # Copyright (c) 2025, 2026, Oracle and/or its affiliates. All rights reserved. >> >> Suggestion: >> >> # Copyright (c) 2026, Oracle and/or its affiliates. All rights reserved. > > Good catch. In the main-line repo the file is new in 2026, but in the Valhalla repo, the proper copyright is "2025, 2026"... Sure, we can inherit the valhalla copyright years. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29509#discussion_r2748166677 From dcubed at openjdk.org Fri Jan 30 22:28:51 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:28:51 GMT Subject: RFR: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 21:40:15 GMT, Vladimir Kozlov wrote: >> A trivial fix to add preview project anchors to main-line ProblemList files. >> >> Also backports changes from the Valhalla repo to make/RunTests.gmk >> to support ProblemList-coh.txt files. This PR also includes the new >> ProblemList-coh.txt file, but it contains no entries (yet). Since this is >> NOT a complete backport of the changes for: >> >> - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 >> >> I'm not handling it as a backport issue. >> >> I've also added missing Copyright headers to some files. > > Marked as reviewed by kvn (Reviewer). @vnkozlov, @liach, and @RogerRiggs - Thanks for the reviews! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29509#issuecomment-3826088183 From duke at openjdk.org Fri Jan 30 22:30:45 2026 From: duke at openjdk.org (duke) Date: Fri, 30 Jan 2026 22:30:45 GMT Subject: RFR: 8370688: java.util.jar.JarEntry.getCodeSigners() and getCertificates() should specify that they return a copy of the arrays [v6] In-Reply-To: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> References: <1pITviq8ZBtVZGMpfBdyBMmnkLiBak5FrYaLLmKCWqE=.191c3dd6-66d5-48d9-a3cb-e0aa956504bb@github.com> Message-ID: On Thu, 22 Jan 2026 21:54:35 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: Updated the documentation to describe the behavior using @implSpec @koushikthirupattur Your change (at version 753154a393ee8c168d7552bae13a8a79f5ff67cc) is now ready to be sponsored by a Committer. ------------- PR Comment: https://git.openjdk.org/jdk/pull/28615#issuecomment-3826096708 From dcubed at openjdk.org Fri Jan 30 22:40:52 2026 From: dcubed at openjdk.org (Daniel D. Daugherty) Date: Fri, 30 Jan 2026 22:40:52 GMT Subject: Integrated: 8376751: add preview project anchors to main-line ProblemList files In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 20:31:36 GMT, Daniel D. Daugherty wrote: > A trivial fix to add preview project anchors to main-line ProblemList files. > > Also backports changes from the Valhalla repo to make/RunTests.gmk > to support ProblemList-coh.txt files. This PR also includes the new > ProblemList-coh.txt file, but it contains no entries (yet). Since this is > NOT a complete backport of the changes for: > > - [JDK-8375337](https://bugs.openjdk.org/browse/JDK-8375337) [lworld] ProblemList misc svc tests that fail due to JDK-8375332 > > I'm not handling it as a backport issue. > > I've also added missing Copyright headers to some files. This pull request has now been integrated. Changeset: 6ce2f3e1 Author: Daniel D. Daugherty URL: https://git.openjdk.org/jdk/commit/6ce2f3e18f31d1dbffc2c4f5adbb5dfe91613989 Stats: 402 lines in 26 files changed: 380 ins; 2 del; 20 mod 8376751: add preview project anchors to main-line ProblemList files Reviewed-by: kvn, rriggs, liach ------------- PR: https://git.openjdk.org/jdk/pull/29509 From liach at openjdk.org Fri Jan 30 22:44:47 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:44:47 GMT Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API [v6] In-Reply-To: References: <8_XK2UpYcewLX40oL3TS0T7KGAgfBprN4aauvhVQBy4=.420255be-10a3-4a64-bac9-491b21983265@github.com> Message-ID: On Wed, 9 Apr 2025 15:34:25 GMT, Chen Liang wrote: >> Core reflection's generic signature parsing uses an ancient library with outdated visitor pattern on a tree model and contains unnecessary boilerplates. This is a duplication of ClassFile API's signature model. We should just move to ClassFile API, which is more throughoutly tested as well. >> >> To ensure compatibility, new tests are added to ensure consistent behavior when encountering malformed signatures or signatures with missing types. The reflective objects have been preserved and the only change is that lazy expansion now happens from CF objects, to reduce compatibility risks. > > Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits: > > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - Improve BytecodeDescriptor error message > - Years, test facelift > - Merge branch 'master' of https://github.com/openjdk/jdk into feature/new-generic-info > - 8333377: Migrate Generic Signature parsing to ClassFile API Closing in favor of #29510, which should be less invasive. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19281#issuecomment-3826150179 From liach at openjdk.org Fri Jan 30 22:47:36 2026 From: liach at openjdk.org (Chen Liang) Date: Fri, 30 Jan 2026 22:47:36 GMT Subject: RFR: 8333377: Migrate Generic Signature parsing to ClassFile API Message-ID: Replace the legacy sun reflect generics tree API with the classfile signature model API. This allows us to maintain just one set of API for future signature changes like null restricted types. This should be less invasive than #19281. ------------- Commit messages: - Use classfile signature tree parsing Changes: https://git.openjdk.org/jdk/pull/29510/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8333377 Stats: 2206 lines in 42 files changed: 82 ins; 2043 del; 81 mod Patch: https://git.openjdk.org/jdk/pull/29510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29510/head:pull/29510 PR: https://git.openjdk.org/jdk/pull/29510 From naoto at openjdk.org Fri Jan 30 22:58:31 2026 From: naoto at openjdk.org (Naoto Sato) Date: Fri, 30 Jan 2026 22:58:31 GMT Subject: RFR: 8340830: Console.readLine() and Console.printf() are mutually blocking [v3] In-Reply-To: References: Message-ID: > Fixing an issue in Console where write is blocked if other thread is waiting to read, which is caused by unnecessary read/write locks. Removing those would solve the problem, as the read/write synchronization is performed at the StreamEn/Decoder level. One unrelated change is to refactor double-checked locking with LazyConstant. Naoto Sato has updated the pull request incrementally with one additional commit since the last revision: Fixed indentation ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29493/files - new: https://git.openjdk.org/jdk/pull/29493/files/4848c481..84bb6ea4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29493&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29493&range=01-02 Stats: 86 lines in 1 file changed: 34 ins; 33 del; 19 mod Patch: https://git.openjdk.org/jdk/pull/29493.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29493/head:pull/29493 PR: https://git.openjdk.org/jdk/pull/29493 From psandoz at openjdk.org Sat Jan 31 00:03:08 2026 From: psandoz at openjdk.org (Paul Sandoz) Date: Sat, 31 Jan 2026 00:03:08 GMT Subject: RFR: 8376187: [VectorAPI] Define new lane type constants and pass them to intrinsic entries [v4] In-Reply-To: References: Message-ID: <-fsfUEvFpvmAsupQFgx1CBkH9vr_efE5-qYeUzy5VFQ=.4abb05e0-1f82-4d6c-8bc4-ca4bc6fc5e80@github.com> On Fri, 30 Jan 2026 07:35:43 GMT, Jatin Bhateja wrote: >> As per [discussions ](https://github.com/openjdk/jdk/pull/28002#issuecomment-3789507594) on JDK-8370691 pull request, splitting out portion of PR#28002 into a separate patch in preparation of Float16 vector API support. >> >> Patch add new lane type constants and pass them to vector intrinsic entry points. >> >> All existing Vector API jtreg test are passing with the patch. >> >> Kindly review and share your feedback. >> >> Best Regards, >> Jatin > > Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision: > > Review comments resolutions This is looking good. Just one last comment on the location of `LANE_TYPE_ORDINAL`. src/java.base/share/classes/jdk/internal/vm/vector/VectorSupport.java line 152: > 150: public static final int MODE_BITS_COERCED_LONG_TO_MASK = 1; > 151: > 152: // Lane type codes for vector: Suggest you change the comment to indicate the values correspond to `jdk.incubator.vector.LaneType` ordinals e.g., jdk.incubator.vector.LaneType.FLOAT.ordinal() == LT_FLOAT etc. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/AbstractSpecies.java line 152: > 150: int laneTypeOrdinal() { > 151: return laneType.ordinal(); > 152: } Is this needed? Won't all concrete sub types override this? src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Byte128Vector.java line 60: > 58: > 59: static final int LANE_TYPE_ORDINAL = LT_BYTE; > 60: You can move this up to `ByteVector` and then reuse it to replace `byte.class`, so it is used consistently. src/jdk.incubator.vector/share/classes/jdk/incubator/vector/LaneType.java line 270: > 268: > 269: static { > 270: assert(ofLaneTypeOrdinal(LT_FLOAT) == FLOAT); Very good! src/jdk.incubator.vector/share/classes/jdk/incubator/vector/VectorOperators.java line 821: > 819: convert(String name, char kind, Class dom, Class ran, int opCode, int flags) { > 820: int domran = ((LaneType.of(dom).ordinal() << VO_DOM_SHIFT) + > 821: (LaneType.of(ran).ordinal() << VO_RAN_SHIFT)); As i understand this is still correct because the maximum ordinal value is less than 16 (as was already the case for the basic type). ------------- PR Review: https://git.openjdk.org/jdk/pull/29481#pullrequestreview-3730928806 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748410039 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748387527 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748483577 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748392412 PR Review Comment: https://git.openjdk.org/jdk/pull/29481#discussion_r2748427970 From syan at openjdk.org Sat Jan 31 04:40:13 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 31 Jan 2026 04:40:13 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out [v2] In-Reply-To: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: > Hi all, > > Test java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out, because `lsof` invoke huast lots of time when the tested machine has many processes, and the processes open too many files. > > This PR add parameter -p pid to `lsof`, which will only generate output from the wanted processes, rather than all the processes on the machine, this will make `lsof` use less time to finish significantly. And this PR also use `Process.waitFor(long timeout, TimeUnit unit)` instead of `waitFor()` which will avoid waitFor invoke cause test timed out. Delete the history lsof input and output files will make diagnosis more easy. > > Change has been verifed locally. The imtermittent timed out do not observed anymore. SendaoYan has updated the pull request incrementally with two additional commits since the last revision: - Revert the change of lsof -p and only increase timeout value for test - Revert "8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out" This reverts commit 23d6dd1ae20bdd8957826f443a95bd4e69000eab. ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29478/files - new: https://git.openjdk.org/jdk/pull/29478/files/23d6dd1a..c4522418 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29478&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29478&range=00-01 Stats: 22 lines in 1 file changed: 0 ins; 11 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/29478.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29478/head:pull/29478 PR: https://git.openjdk.org/jdk/pull/29478 From syan at openjdk.org Sat Jan 31 04:40:14 2026 From: syan at openjdk.org (SendaoYan) Date: Sat, 31 Jan 2026 04:40:14 GMT Subject: RFR: 8376630: java/lang/ProcessBuilder/PipelineLeaksFD.java intermittent timed out [v2] In-Reply-To: References: <-OeR9W2W_B4RgmE5SC5LeBM0jFxD9gnK8i6YNI0RRUM=.454da1cb-dbc9-46cc-a61a-6899dbaaf731@github.com> Message-ID: <2Ms43SmWChv9_r_ddyshVk1Qn33jpylHzhYbtS8Y6PM=.0f34833c-3510-4ca6-8b25-0d51006e98d5@github.com> On Fri, 30 Jan 2026 14:55:08 GMT, Roger Riggs wrote: >> Do you mean I should close this PR, and you will create a new one. That would be a good option. > > I would be ok with only increasing the timeout. > That would avoid customizing the test to an older OS version and retain the extra information useful for debugging. > Since it is intermittent, the current timeout is in the ballpark, so doubling it would be ok. > Older OS versions will be replaced in time, but if we complicate the test code, that will stay indefinitely. > > Please wait to remove the test from the ProblemList. > When I fix: [JDK-8375585](https://bugs.openjdk.org/browse/JDK-8375585) I'll take it off the problem list. Thanks. I have revert the change of `lsof -p`, and increase the timeout value for this test. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29478#discussion_r2748865771 From duke at openjdk.org Sat Jan 31 08:15:55 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 08:15:55 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v16] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Add `codePointCount` for `CharBuffer` ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/585ce36e..a291e1bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=15 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=14-15 Stats: 19 lines in 1 file changed: 19 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From alanb at openjdk.org Sat Jan 31 08:51:10 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 31 Jan 2026 08:51:10 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v16] In-Reply-To: References: Message-ID: On Sat, 31 Jan 2026 08:15:55 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 one additional commit since the last revision: > > Add `codePointCount` for `CharBuffer` src/java.base/share/classes/java/nio/X-Buffer.java.template line 2062: > 2060: /** > 2061: * {@return the number of Unicode code points in this character sequence} > 2062: * Isolated surrogate code units count as one code point each. I agree the override needs to be specified but it will need to be specified to count the code points in the between the position (inclusive) and the limit (exclusive). src/java.base/share/classes/java/nio/X-Buffer.java.template line 2070: > 2068: int lim = limit(); > 2069: int count = l; > 2070: for (int i = position(); i < lim;) { There will need to a robustness pass done on this override as the CharBuffer may be backed by off-heap memory. Look at the existing overides to see examples where it captures the limit and position once. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749219147 PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749219908 From duke at openjdk.org Sat Jan 31 12:51:41 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 12:51:41 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v17] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Fix incorrect logic ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/a291e1bb..77583bdc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=16 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=15-16 Stats: 5 lines in 1 file changed: 1 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Sat Jan 31 12:51:43 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 12:51:43 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v16] In-Reply-To: References: Message-ID: On Sat, 31 Jan 2026 08:48:09 GMT, Alan Bateman wrote: >> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: >> >> Add `codePointCount` for `CharBuffer` > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 2070: > >> 2068: int lim = limit(); >> 2069: int count = l; >> 2070: for (int i = position(); i < lim;) { > > There will need a robustness pass done on this override as the CharBuffer may be backed by off-heap memory. Look at the existing overrides to see examples where it captures the limit and position once. In the first place the logic turned out to be wrong. Could you give me more concrete comment based on the new change? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749529891 From duke at openjdk.org Sat Jan 31 13:34:49 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 13:34:49 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v18] In-Reply-To: References: Message-ID: <56CnxfQ7B7MlL4-tu2Cs-J1gmwAc0OGKM72ApDqIRmk=.72d806d0-4b0c-44c5-b310-b628c16b24fd@github.com> > 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 three additional commits since the last revision: - Split testcases for `StringBuilder.codePointCount` - Update year - Improve JavaDoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/77583bdc..cabb3efe Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=17 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=16-17 Stats: 31 lines in 3 files changed: 19 ins; 8 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Sat Jan 31 13:34:52 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 13:34:52 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v16] In-Reply-To: References: Message-ID: On Sat, 31 Jan 2026 08:46:52 GMT, Alan Bateman wrote: >> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: >> >> Add `codePointCount` for `CharBuffer` > > src/java.base/share/classes/java/nio/X-Buffer.java.template line 2062: > >> 2060: /** >> 2061: * {@return the number of Unicode code points in this character sequence} >> 2062: * Isolated surrogate code units count as one code point each. > > I agree the override needs to be specified but it will need to be specified to count the code points between the position (inclusive) and the limit (exclusive). JavaDoc updated ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749563799 From duke at openjdk.org Sat Jan 31 13:34:54 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 13:34:54 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v14] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 16:20:13 GMT, Naoto Sato wrote: >>> Bonus if you could rename each testX to testMethodName >> >> "`testCodePointCount`" has already been occupied: >> >> https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L365-L376 >> >> https://github.com/tats-u/jdk/blob/585ce36e125ec2f79483311512d8789ff39b0df9/test/jdk/java/lang/StringBuilder/Supplementary.java#L247-L251 > > We could distinguish them like `testCodePointCountNoArg` and `testCodePointCountTwoArgs` I see ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749563375 From duke at openjdk.org Sat Jan 31 14:31:39 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sat, 31 Jan 2026 14:31:39 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v19] In-Reply-To: References: Message-ID: > 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 one additional commit since the last revision: Add missing semicolon ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/cabb3efe..81245159 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=18 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=17-18 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From alanb at openjdk.org Sat Jan 31 15:59:07 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 31 Jan 2026 15:59:07 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v19] In-Reply-To: References: Message-ID: On Sat, 31 Jan 2026 14:31:39 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 one additional commit since the last revision: > > Add missing semicolon src/java.base/share/classes/java/nio/X-Buffer.java.template line 2061: > 2059: > 2060: /** > 2061: * {@return the number of Unicode code points in this character sequence Can you change the first sentence to : "{@return the number of Unicode code points in this character buffer}". The rest can go into a second paragraph that starts with "The number of Unicode code points in this character buffer is the number of Unicode code points between the position (inclusive) and the limit (exclusive).". ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2749697267 From alanb at openjdk.org Sat Jan 31 16:28:00 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 31 Jan 2026 16:28:00 GMT Subject: RFR: 8376703: Some coding in libjimage seems to be not called at all or not called from PRODUCT code [v2] In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 12:50:18 GMT, Matthias Baesken wrote: > but this is not unused/uncalled in our codebase. I think it is inlined at the 1 or 2 points were it is used. But the method is still generated into the library even in case that it is always inlined ; it may be difficult to address this with the usual linker settings on Linux (means without linktime-gc or LTO or similar stuff ) . That is a bit unnerving but if someone were to use this warning to remove code that is used then there would be build or test failures. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29502#issuecomment-3828786260 From alanb at openjdk.org Sat Jan 31 17:18:05 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sat, 31 Jan 2026 17:18:05 GMT Subject: RFR: 8376760: VerifyJimage.java#compare intermittent failed with fastdebug In-Reply-To: References: Message-ID: On Fri, 30 Jan 2026 02:20:09 GMT, SendaoYan wrote: > Hi all, > > Test tools/jimage/VerifyJimage.java#compare intermittent timed out with fastdebug build. I think it would be better to ajust the jtreg timeout factor(20*timeoutFactor) rather that set the fix timeout value(20) for awaitTermination. > > The test run all passed 100 times simultaneously. test/jdk/tools/jimage/VerifyJimage.java line 152: > 150: long timeout = Utils.adjustTimeout(20); > 151: if (!pool.awaitTermination(timeout, TimeUnit.SECONDS)) { > 152: failed.add("Directory verification timed out in " + timeout + " seconds"); The alternative is to just replace the shutdown + awaitTermination with a call to `pool.close()`. This will wait indefinitely, which is useful for diagnosability if the verification hangs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29498#discussion_r2749755002 From eirbjo at gmail.com Sat Jan 31 18:40:19 2026 From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=) Date: Sat, 31 Jan 2026 19:40:19 +0100 Subject: RFD: Reorganize ZipCoder such that UTF8 is handled by the base class In-Reply-To: References: Message-ID: Thank you Chen! Filed https://bugs.openjdk.org/browse/JDK-8376842 to track this enhancement. Eirik. On Thu, Jan 29, 2026 at 7:27?PM Chen Liang wrote: > Hello Eirik, > I strongly agree with your proposal. I see such a change has low risk > given ZipCoder is an internal class. > > Regards, > Chen > > ------------------------------ > *From:* core-libs-dev on behalf of Eirik > Bj?rsn?s > *Sent:* Wednesday, January 28, 2026 3:26 AM > *To:* core-libs-dev > *Subject:* RFD: Reorganize ZipCoder such that UTF8 is handled by the base > class > > Hi, > > Bringing this up on core-libs-dev such that the motivation can be > explained/discussed here and any future PR can focus on actual code changes. > > Summary: > > Reorganize the ZipCoder class hierarchy to let the base class handle UTF8 > and the subclass handle arbitrary Charsets. This makes the design better > match the ZIP specification and how ZIP files are used in the real world > and additionally have some benefits in code quality and performance. > > Motivation: > > The ZipCoder class has been central to many ZipFile performance > improvements in recent years. Many optimizations are encoding-specific and > encapsulating these concerns makes a lot of sense. > > Currently, the base ZipCoder instance supports any given Charset. Then, a > subclass UTF8ZipCoder provides higher performance optimizations specific to > UTF-8. > > However, real-world use of the ZipFile API defaults to UTF-8. The ZIP > specification long-ago introduced a flag to explicitly indicate that > entries are encoded using UTF-8. The JAR specification has mandated UTF-8 > since the beginning. Any use of non-UTF-8 ZIP files is increasingly niche > and belongs in the legacy zone. > > The current UTF8ZipCoder is stateless and documented as thread safe, while > the base class ZipCoder is not. As a subclass of ZipCode, UTF8ZipCoder does > however inherit CharsetEncoder and CharsetDecoder state fields from its > super class and it needs to pass a UTF8 Charset to its parent, without > really using it. This makes state and thread safety harder to reason about. > > Since UTF8ZipCoder is always needed, the JVM must always load it along > with the base class ZipCoder. Apart from loading an extra class, this > prevents the JVM from seeing calls to ZipCoder methods as monomorphic. > > A draft implementation of this change indicates a ~3% performance win on > ZipFile lookups in ZipFileGetEntry, probably explained by the compiler > seeing only one instance of ZipCoder being loaded. > > Solution: > > Switch the class hierarchy of ZipCoder around such that the base class > handles UTF-8. Introduce a new subclass CharsetZipCoder to handle legacy > non-UTF ZIP files. Move the Charset, CharsetEncoder, CharsetDecoder fields > to this subclass. Update code comments to reflect the changes. > > Risks: > > This should be a pure refactoring, mostly moving code around. Most changes > can be performed in-place, such that side by side review will mostly > reflect indentation changes. We have good test coverage for UTF8 and > non-UTF-8 ZIP files to help us catch regressions. > > If I see support for this proposal, I'll be happy to submit a PR with the > actual changes. > > Cheers, > Eirik :-) > > > > > > > > > > Confidential- Oracle Internal > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acobbs at openjdk.org Sat Jan 31 20:03:49 2026 From: acobbs at openjdk.org (Archie Cobbs) Date: Sat, 31 Jan 2026 20:03:49 GMT Subject: RFR: 8344159: Add lint warnings for unnecessary warning suppression [v7] In-Reply-To: References: Message-ID: <3VvHHah7TVMP4_puXRq4urxiwR8UMSJugMQ3yQZdPJo=.cae130ee-beb0-448f-87f6-a3772894f618@github.com> > This PR adds a new compiler warning for `@SuppressWarnings` annotations that don't actually suppress any warnings. > > Summary of code changes: > > * Add new warning and associated lint category `"suppression"` > * Update `LintMapper` to keep track of which `@SuppressWarnings` suppressions have been validated ? > * Update `Log.warning()` so it validates any current suppression of the warning's lint category in effect. > * Add a new `validate` parameter to `Lint.isEnabled()` and `Lint.isSuppressed()` that specifies whether to also validate any current suppression. > * Add `Lint.isActive()` to check whether a category is enabled _or_ suppression of the category is being tracked - in other words, whether the warning calculation needs to be performed. Used for non-trivial warning calculations. > * Add `-Xlint:-suppression` flags to `*.gmk` build files so the build doesn't break > > ? The suppression of a lint category is "validated" as soon as it suppresses some warning in that category Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 140 commits: - Merge branch 'master' into JDK-8344159 to fix conflicts. - Update copyrights to 2026. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 - Suppress new unnecessary suppresion warnings created by recent commits. - Merge branch 'master' into JDK-8344159 - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflict. - Merge branch 'master' into JDK-8344159 to fix conflicts. - ... and 130 more: https://git.openjdk.org/jdk/compare/6ce2f3e1...ab9af044 ------------- Changes: https://git.openjdk.org/jdk/pull/25167/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25167&range=06 Stats: 1696 lines in 35 files changed: 1494 ins; 49 del; 153 mod Patch: https://git.openjdk.org/jdk/pull/25167.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/25167/head:pull/25167 PR: https://git.openjdk.org/jdk/pull/25167 From redestad at openjdk.org Sat Jan 31 21:39:05 2026 From: redestad at openjdk.org (Claes Redestad) Date: Sat, 31 Jan 2026 21:39:05 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments Marked as reviewed by redestad (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3733536619 From liach at openjdk.org Sat Jan 31 22:51:06 2026 From: liach at openjdk.org (Chen Liang) Date: Sat, 31 Jan 2026 22:51:06 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: <-WA53k6R4eboMFEjQAWT2ceAAbkDyEa0xkHU4xw8xR4=.ccab8601-9b2b-46e7-b59e-8c44265dbef3@github.com> On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments Sure, I can leave a token approval if you ask for it. ------------- Marked as reviewed by liach (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29288#pullrequestreview-3733797079 From eirbjo at openjdk.org Sat Jan 31 23:10:05 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 31 Jan 2026 23:10:05 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: <-WA53k6R4eboMFEjQAWT2ceAAbkDyEa0xkHU4xw8xR4=.ccab8601-9b2b-46e7-b59e-8c44265dbef3@github.com> References: <-WA53k6R4eboMFEjQAWT2ceAAbkDyEa0xkHU4xw8xR4=.ccab8601-9b2b-46e7-b59e-8c44265dbef3@github.com> Message-ID: On Sat, 31 Jan 2026 22:48:04 GMT, Chen Liang wrote: > Sure, I can leave a token approval if you ask for it. Apprechiated Chen! Reapproval was required to get this ready for integration. The number of reviewers for this change was set to 3 and I felt awkward reducing it. ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3829545570 From eirbjo at openjdk.org Sat Jan 31 23:33:18 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 31 Jan 2026 23:33:18 GMT Subject: RFR: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath [v4] In-Reply-To: References: Message-ID: <-abwGpe_GfZnDTf1SDJ7FD_ah8aeA3GaMk7pR90Nfus=.1676574f-1dc7-45e2-8475-e36d18c4a63d@github.com> On Mon, 26 Jan 2026 14:04:28 GMT, Eirik Bj?rsn?s wrote: >> Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. >> >> The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. >> >> By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. >> >> Advantages: >> >> * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) >> * One data structure is simpler than two >> * We no longer need to manage search path URLs across two different collections >> * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed >> * I think this PR leaves the code overall simpler and easier to follow. >> >> Testing: >> >> This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. > > Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision: > > - Remove @bug tag, no product bug discovered > - Rename test and deemphasize DFS is comments Thanks for all the patient review feedback! ------------- PR Comment: https://git.openjdk.org/jdk/pull/29288#issuecomment-3829592003 From eirbjo at openjdk.org Sat Jan 31 23:33:19 2026 From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=) Date: Sat, 31 Jan 2026 23:33:19 GMT Subject: Integrated: 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath In-Reply-To: References: Message-ID: On Sat, 17 Jan 2026 21:56:05 GMT, Eirik Bj?rsn?s wrote: > Please review this PR which proposes we replace `j.u.ArrayDeque` with `j.u.ArrayList` in `jdk.internal.loader.URLClassPath`. > > The motivation for using a double-ended queue may have been that "original" search path URLs are added to the tail of the queue while any URLs discovered during JAR `Class-Path` expansion are inserted at the head such that they are processed first. > > By splitting these two concerns and processing loader discovered class path URLs separately from the original search path, we no longer need a double-ended queue. We can replace `ArrayDeque` with `ArrayList`. > > Advantages: > > * A "hello world" Java program no longer loads `ArrayDeque`, `Deque` and `Queue` (`URLClassPath` is the only consumer of these classes during startup using a directory class path) > * One data structure is simpler than two > * We no longer need to manage search path URLs across two different collections > * Code and comments to dance around `ArrayDeque` calling into lambda too early is no longer a concern and can be removed > * I think this PR leaves the code overall simpler and easier to follow. > > Testing: > > This PR introduces a new test to verify that URLs disovered via a multi-level tree paths discovered via `Class-Path` JAR attributes are found in the expected DFS order. The ordering aspect seems to lack existing coverage. This pull request has now been integrated. Changeset: ca95e5f3 Author: Eirik Bj?rsn?s URL: https://git.openjdk.org/jdk/commit/ca95e5f3ddd5961dd43f825ed6c47054284c6798 Stats: 248 lines in 2 files changed: 205 ins; 20 del; 23 mod 8375580: Avoid using ArrayDeque in jdk.internal.loader.URLClassPath Reviewed-by: liach, redestad, jpai ------------- PR: https://git.openjdk.org/jdk/pull/29288