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