From duke at openjdk.org Sun Feb 1 06:28:49 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 06:28:49 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v20] In-Reply-To: References: Message-ID: > Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. > > > if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { > throw new Exception("exceeding length"); > } > > > Is a CSR required to this change? Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: - Update JavaDoc - Fix broken test methods calls ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/81245159..8b5db22c Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=19 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=18-19 Stats: 7 lines in 2 files changed: 3 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From alanb at openjdk.org Sun Feb 1 08:29:05 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 1 Feb 2026 08:29:05 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: References: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com> Message-ID: On Wed, 28 Jan 2026 23:55:50 GMT, Tatsunori Uchino wrote: >> Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: >> >> Update year in copyright > > "Create sysroot" fails: > > s390x: > > > Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ > W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg > I: Retrieving InRelease > E: Invalid Release file, no entry for main/binary-s390x/Packages > Error: Process completed with exit code 1. > > > ppc64le: > > > Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ > W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg > I: Retrieving InRelease > E: Invalid Release file, no entry for main/binary-ppc64el/Packages > Error: Process completed with exit code 1. @tats-u The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830610479 From alanb at openjdk.org Sun Feb 1 08:33:11 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 1 Feb 2026 08:33:11 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v20] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 06:28:49 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 two additional commits since the last revision: > > - Update JavaDoc > - Fix broken test methods calls src/java.base/share/classes/java/nio/X-Buffer.java.template line 2062: > 2060: /** > 2061: * {@return the number of Unicode code points in this character buffer} > 2062: *

The number of Unicode code points in this character buffer is Keep it consistent with the existing methods if you can, meaning put a blank after before the second paragraph, space after the `

` and drop the trailing `

`. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2750747902 From duke at openjdk.org Sun Feb 1 10:20:46 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 10:20:46 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v21] In-Reply-To: References: Message-ID: > Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. > > > if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { > throw new Exception("exceeding length"); > } > > > Is a CSR required to this change? Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: Reformat JavaDoc ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/8b5db22c..43eb577a Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=20 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=19-20 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Sun Feb 1 10:20:46 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 10:20:46 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: References: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>

Message-ID: On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman wrote: >> "Create sysroot" fails: >> >> s390x: >> >> >> Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ >> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg >> I: Retrieving InRelease >> E: Invalid Release file, no entry for main/binary-s390x/Packages >> Error: Process completed with exit code 1. >> >> >> ppc64le: >> >> >> Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ >> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg >> I: Retrieving InRelease >> E: Invalid Release file, no entry for main/binary-ppc64el/Packages >> Error: Process completed with exit code 1. > > @tats-u The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences. @AlanBateman Fixed, but you might want to use from next time:

------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830816082 From duke at openjdk.org Sun Feb 1 10:31:07 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 10:31:07 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: References: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>

Message-ID: <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com> On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman wrote: >> "Create sysroot" fails: >> >> s390x: >> >> >> Run sudo debootstrap --no-merged-usr --arch=s390x --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ >> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg >> I: Retrieving InRelease >> E: Invalid Release file, no entry for main/binary-s390x/Packages >> Error: Process completed with exit code 1. >> >> >> ppc64le: >> >> >> Run sudo debootstrap --no-merged-usr --arch=ppc64el --verbose --include=fakeroot,symlinks,build-essential,libx11-dev,libxext-dev,libxrender-dev,libxrandr-dev,libxtst-dev,libxt-dev,libcups2-dev,libfontconfig1-dev,libasound2-dev,libfreetype-dev,libpng-dev --resolve-deps --variant=minbase bullseye sysroot https://httpredir.debian.org/debian/ >> W: Cannot check Release signature; keyring file not available /usr/share/keyrings/debian-archive-keyring.gpg >> I: Retrieving InRelease >> E: Invalid Release file, no entry for main/binary-ppc64el/Packages >> Error: Process completed with exit code 1. > > @tats-u The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. It's really important that the method is exercises with CharBuffer views that are backed by heap/direct buffers and char sequences. @AlanBateman > The tests in test/jdk/java/nio/Buffer will need to be updated to add coverage for the new method. Do you know which files new tests should be added to? test/jdk/java/nio/Buffer/CharBufferAsCharSequenceTest.java? ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3830829293 From duke at openjdk.org Sun Feb 1 11:00:41 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 11:00:41 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v22] In-Reply-To: References: Message-ID: > Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. > > > if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { > throw new Exception("exceeding length"); > } > > > Is a CSR required to this change? Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision: Add test ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/43eb577a..b640e68d Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=21 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=20-21 Stats: 12 lines in 1 file changed: 12 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Sun Feb 1 12:55:29 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 12:55:29 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References: Message-ID: > Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. > > > if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { > throw new Exception("exceeding length"); > } > > > Is a CSR required to this change? Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: - Add comment - Fix logic error ------------- Changes: - all: https://git.openjdk.org/jdk/pull/26461/files - new: https://git.openjdk.org/jdk/pull/26461/files/b640e68d..e7d33b94 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=22 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=26461&range=21-22 Stats: 8 lines in 2 files changed: 5 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/26461.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/26461/head:pull/26461 PR: https://git.openjdk.org/jdk/pull/26461 From duke at openjdk.org Sun Feb 1 15:10:12 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Sun, 1 Feb 2026 15:10:12 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: > > - Add comment > - Fix logic error I don't know how to fix the offending "tools/javac/patterns/Exhaustiveness" error. https://github.com/tats-u/jdk/actions/runs/21563196651#summary-62131220808 ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831173111 From liach at openjdk.org Sun Feb 1 15:16:08 2026 From: liach at openjdk.org (Chen Liang) Date: Sun, 1 Feb 2026 15:16:08 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: > > - Add comment > - Fix logic error Oh, it's just a timeout on some special build configuration. It is sometimes due to GitHub Actions machines being not powerful enough. You can safely ignore that. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831183326 From alanb at openjdk.org Sun Feb 1 16:58:09 2026 From: alanb at openjdk.org (Alan Bateman) Date: Sun, 1 Feb 2026 16:58:09 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v11] In-Reply-To: <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com> References: <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>

<7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com> Message-ID: On Sun, 1 Feb 2026 10:28:12 GMT, Tatsunori Uchino wrote: > Do you know which files new tests should be added to? Look at Basic-X.java.template (need to run genBasic.sh to generate the tests when you change it). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3831388783 From dfenacci at openjdk.org Mon Feb 2 09:31:40 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 09:31:40 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v9] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - Merge branch 'JDK-8374582' of https://github.com/dafedafe/jdk into JDK-8374582 - JDK-8374582: add assert in opaque constructor ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/c5390e4a..5e7df6f4 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=07-08 Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Mon Feb 2 09:55:37 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 09:55:37 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v10] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: JDK-8374582: revert wrong copyright change ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/5e7df6f4..5ac3e6e3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=08-09 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From thartmann at openjdk.org Mon Feb 2 11:40:03 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 2 Feb 2026 11:40:03 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v10] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: On Mon, 2 Feb 2026 09:55:37 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: > > JDK-8374582: revert wrong copyright change Thanks for working on this Damon. I added a few comments, otherwise it looks good! src/hotspot/share/opto/library_call.cpp line 894: > 892: > 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region, > 894: Node** pos_index, bool is_opaque) { As we discussed offline, I think `with_opaque` is better here. src/hotspot/share/opto/opaquenode.hpp line 145: > 143: // with false in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > 144: // In debug builds, we keep the actual checks as additional verification code (i.e. removing OpaqueConstantBoolNodes and > 145: // use the BoolNode inputs instead). Nice comment! src/hotspot/share/opto/opaquenode.hpp line 148: > 146: class OpaqueConstantBoolNode : public Node { > 147: private: > 148: bool _constant; Should this be `const`? src/hotspot/share/opto/opaquenode.hpp line 150: > 148: bool _constant; > 149: public: > 150: OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) { An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ? ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3738450475 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753636949 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753548067 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753551976 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2753586409 From dfenacci at openjdk.org Mon Feb 2 12:01:51 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 12:01:51 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v11] In-Reply-To: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> Message-ID: > ## Issue > > This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. > > This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. > > ## Causes > > The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. > > ## Fix > > A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: > https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 > This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. > > # Testing > > * Tier 1-3+ > * 2 JTReg tests added > * `TestRangeCheck.java` as regression test for the reported issue > * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374582: add const - JDK-8374582: with_opaque ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/5ac3e6e3..0d4eef88 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=09-10 Stats: 7 lines in 3 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Mon Feb 2 12:13:36 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 12:13:36 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v10] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>

Message-ID: On Mon, 2 Feb 2026 10:29:20 GMT, Tobias Hartmann wrote: >> Damon Fenacci has updated the pull request incrementally with one additional commit since the last revision: >> >> JDK-8374582: revert wrong copyright change > > src/hotspot/share/opto/library_call.cpp line 894: > >> 892: >> 893: inline Node* LibraryCallKit::generate_negative_guard(Node* index, RegionNode* region, >> 894: Node** pos_index, bool is_opaque) { > > As we discussed offline, I think `with_opaque` is better here. Renamed. Thanks @TobiHartmann. > src/hotspot/share/opto/opaquenode.hpp line 148: > >> 146: class OpaqueConstantBoolNode : public Node { >> 147: private: >> 148: bool _constant; > > Should this be `const`? Yep, fixed. > src/hotspot/share/opto/opaquenode.hpp line 150: > >> 148: bool _constant; >> 149: public: >> 150: OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) { > > An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ? Cool trick! ?... but now I can't decide between the two ? @chhagedorn do you fancy being the tiebreaker? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754030906 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754030537 PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754032138 From chagedorn at openjdk.org Mon Feb 2 13:28:57 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Mon, 2 Feb 2026 13:28:57 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v10] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>

Message-ID: On Mon, 2 Feb 2026 12:10:48 GMT, Damon Fenacci wrote: >> src/hotspot/share/opto/opaquenode.hpp line 150: >> >>> 148: bool _constant; >>> 149: public: >>> 150: OpaqueConstantBoolNode(Compile* C, Node* tst, bool constant) : Node(nullptr, tst), _constant(constant) { >> >> An alternative would be to have the `constant` be an actual input node instead of a field. In macro expansion, you could then do `_igvn.replace_node(n, n->in(2));` instead (maybe define an enum for the input indices). I don't have a strong opinion on this though and leave it up to you to decide ? > > Cool trick! ?... but now I can't decide between the two ? @chhagedorn do you fancy being the tiebreaker? The old `Opaque4` nodes used to have two data inputs where the second one was the replacement. I found it a little harder to view graphs in IGV with one more input. You also do not need to worry about trying to understand what the second input means. So, I would rather have a field if I may break the tie but both options are fine :-) When going with a field, you could add a NOT_PRODUCT(void dump_spec(outputStream* st) const); that prints `#true` or `#false` depending on `_constant` (that could also then be shown in IGV with the "Show custom node info"). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754324868 From dfenacci at openjdk.org Mon Feb 2 14:03:00 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 14:03:00 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v12] 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: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@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 Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: - JDK-8374582: remove empty line - JDK-8374582: add constant dump ------------- Changes: - all: https://git.openjdk.org/jdk/pull/29164/files - new: https://git.openjdk.org/jdk/pull/29164/files/0d4eef88..44b68dbc Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29164&range=10-11 Stats: 7 lines in 2 files changed: 7 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/29164.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29164/head:pull/29164 PR: https://git.openjdk.org/jdk/pull/29164 From dfenacci at openjdk.org Mon Feb 2 14:05:43 2026 From: dfenacci at openjdk.org (Damon Fenacci) Date: Mon, 2 Feb 2026 14:05:43 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v10] In-Reply-To: References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>

Message-ID: <9TRsuJgH4W8hsmU02_3jXvLwPotWWdihBDjXoA_DZ3A=.577eb61f-6333-4cca-ad89-bc17c73bb660@github.com> On Mon, 2 Feb 2026 13:26:12 GMT, Christian Hagedorn wrote: > So, I would rather have a field if I may break Let's go with the field then ? > ```NOT_PRODUCT(void dump_spec(outputStream* st) const);``` Good idea! Added. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29164#discussion_r2754497278 From thartmann at openjdk.org Mon Feb 2 16:02:56 2026 From: thartmann at openjdk.org (Tobias Hartmann) Date: Mon, 2 Feb 2026 16:02:56 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v12] In-Reply-To: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com> Message-ID: <_mVonDnsPn3yCi7haKqAlC_3iD8GNOojYbMt4xuUf_Y=.2c887c19-5dba-4501-bec4-faba0a2dca9b@github.com> On Mon, 2 Feb 2026 14:03:00 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8374582: remove empty line > - JDK-8374582: add constant dump That looks good to me. ------------- Marked as reviewed by thartmann (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3740390312 From alanb at openjdk.org Tue Feb 3 12:04:40 2026 From: alanb at openjdk.org (Alan Bateman) Date: Tue, 3 Feb 2026 12:04:40 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: > > - Add comment > - Fix logic error src/java.base/share/classes/java/lang/String.java line 1886: > 1884: * @since 27 > 1885: */ > 1886: public int codePointCount() { Are you planning to override the API docs here to say that it returns the number of Unicode code points in this String? That would get the API docs consistent with the existing 3-arg codePointCount and avoid referencing the String as a character sequence in the String docs. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2758723775 From naoto at openjdk.org Tue Feb 3 16:53:34 2026 From: naoto at openjdk.org (Naoto Sato) Date: Tue, 3 Feb 2026 16:53:34 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: <0nrxPt9EBTADN3jACynCXe6V3kf0duVrvdT-mcD-nqo=.a0764e66-8f41-4632-aa88-4bdd163e9e79@github.com> On Tue, 3 Feb 2026 11:59:21 GMT, Alan Bateman wrote: >> Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: >> >> - Add comment >> - Fix logic error > > src/java.base/share/classes/java/lang/String.java line 1886: > >> 1884: * @since 27 >> 1885: */ >> 1886: public int codePointCount() { > > Are you planning to override the API docs here to say that it returns the number of Unicode code points in this String? That would get the API docs consistent with the existing 3-arg codePointCount and avoid referencing the String as a character sequence in the String docs. That was my suggestion to remove the text, as the generated javadoc apparently shows the text is from CharSequence. It sure does replacing the CharSequence with String aligns with the other method, but it also introduces copying the almost identical text, which could introduce editorial left over if CharSequence text changes. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/26461#discussion_r2760034348 From duke at openjdk.org Wed Feb 4 12:41:32 2026 From: duke at openjdk.org (Tatsunori Uchino) Date: Wed, 4 Feb 2026 12:41:32 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino wrote: >> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks. >> >> >> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) { >> throw new Exception("exceeding length"); >> } >> >> >> Is a CSR required to this change? > > Tatsunori Uchino has updated the pull request incrementally with two additional commits since the last revision: > > - Add comment > - Fix logic error Can I commit test\jdk\java\nio\Buffer\build\tools\sp\Spp.class? It was generated by `genBasic.sh`. The other files were not changed. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3847208289 From alanb at openjdk.org Wed Feb 4 14:26:21 2026 From: alanb at openjdk.org (Alan Bateman) Date: Wed, 4 Feb 2026 14:26:21 GMT Subject: RFR: 8364007: Add no-argument codePointCount method to CharSequence and String [v23] In-Reply-To: References:

Message-ID: On Wed, 4 Feb 2026 12:39:07 GMT, Tatsunori Uchino wrote: > Can I commit test\jdk\java\nio\Buffer\build\tools\sp\Spp.class? It was generated by `genBasic.sh`. The other files were not changed. Only updated .java files should be commit, not the class files (or the class files for the tool). ------------- PR Comment: https://git.openjdk.org/jdk/pull/26461#issuecomment-3847765110 From prr at openjdk.org Wed Feb 4 20:42:39 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Feb 2026 20:42:39 GMT Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager Message-ID: Remove AppContext from KeyboardFocusManager ------------- Commit messages: - 8377191 Changes: https://git.openjdk.org/jdk/pull/29578/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29578&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377191 Stats: 192 lines in 7 files changed: 6 ins; 142 del; 44 mod Patch: https://git.openjdk.org/jdk/pull/29578.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29578/head:pull/29578 PR: https://git.openjdk.org/jdk/pull/29578 From prr at openjdk.org Wed Feb 4 20:42:40 2026 From: prr at openjdk.org (Phil Race) Date: Wed, 4 Feb 2026 20:42:40 GMT Subject: RFR: 8377191: Remove AppContext from KeyboardFocusManager In-Reply-To: References: Message-ID: On Wed, 4 Feb 2026 20:33:12 GMT, Phil Race wrote: > Remove AppContext from KeyboardFocusManager src/java.desktop/share/classes/sun/awt/SunToolkit.java line 429: > 427: } > 428: > 429: public static void postEvent(AWTEvent event) { The non-app context versions of various SunToolkit methods will eventually replace the overloads with AppContext. I'm adding similar overloads to other methods in other PRs that may be concurrent so please don't ask for a (c) year update - that'll just be a merge conflict. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/29578#discussion_r2765892683 From chagedorn at openjdk.org Thu Feb 5 06:37:32 2026 From: chagedorn at openjdk.org (Christian Hagedorn) Date: Thu, 5 Feb 2026 06:37:32 GMT Subject: RFR: 8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics [v12] In-Reply-To: <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com> References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com> <2_bA8sRgRlbc279Aia0oD9gPBn8bcD5kLP3RnA4Xl4Q=.deaeaaf0-27a1-40f8-81f3-c8283c4d9529@github.com> Message-ID: On Mon, 2 Feb 2026 14:03:00 GMT, Damon Fenacci wrote: >> ## Issue >> >> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details. >> >> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend. >> >> ## Causes >> >> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top. >> >> ## Fix >> >> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null: >> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484 >> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code. >> >> # Testing >> >> * Tier 1-3+ >> * 2 JTReg tests added >> * `TestRangeCheck.java` as regression test for the reported issue >> * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion > > Damon Fenacci has updated the pull request incrementally with two additional commits since the last revision: > > - JDK-8374582: remove empty line > - JDK-8374582: add constant dump Thanks for the updates Damon, looks good to me, too! ------------- Marked as reviewed by chagedorn (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/29164#pullrequestreview-3754821230 From naoto at openjdk.org Thu Feb 5 17:35:37 2026 From: naoto at openjdk.org (Naoto Sato) Date: Thu, 5 Feb 2026 17:35:37 GMT Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta) Message-ID: Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions. Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN. Here is the diff of the generated `conf/tzmappings` for reference: @@ -13,7 +13,7 @@ Arabian Standard Time:ZZ:Etc/GMT-4: Arabian Standard Time:001:Asia/Dubai: Arabic Standard Time:001:Asia/Baghdad: -Argentina Standard Time:001:America/Buenos_Aires: +Argentina Standard Time:001:America/Argentina/Buenos_Aires: Astrakhan Standard Time:001:Europe/Astrakhan: Atlantic Standard Time:BM:Atlantic/Bermuda: Atlantic Standard Time:GL:America/Thule: @@ -58,7 +58,7 @@ Central European Standard Time:MK:Europe/Skopje: Central European Standard Time:001:Europe/Warsaw: Central Pacific Standard Time:AQ:Antarctica/Casey: -Central Pacific Standard Time:FM:Pacific/Ponape: +Central Pacific Standard Time:FM:Pacific/Pohnpei: Central Pacific Standard Time:NC:Pacific/Noumea: Central Pacific Standard Time:VU:Pacific/Efate: Central Pacific Standard Time:ZZ:Etc/GMT-11: @@ -75,7 +75,7 @@ Dateline Standard Time:001:Etc/GMT+12: E. Africa Standard Time:AQ:Antarctica/Syowa: E. Africa Standard Time:DJ:Africa/Djibouti: -E. Africa Standard Time:ER:Africa/Asmera: +E. Africa Standard Time:ER:Africa/Asmara: E. Africa Standard Time:ET:Africa/Addis_Ababa: E. Africa Standard Time:KM:Indian/Comoro: E. Africa Standard Time:MG:Indian/Antananarivo: @@ -101,10 +101,10 @@ FLE Standard Time:FI:Europe/Helsinki: FLE Standard Time:LT:Europe/Vilnius: FLE Standard Time:LV:Europe/Riga: -FLE Standard Time:001:Europe/Kiev: +FLE Standard Time:001:Europe/Kyiv: Fiji Standard Time:001:Pacific/Fiji: GMT Standard Time:ES:Atlantic/Canary: -GMT Standard Time:FO:Atlantic/Faeroe: +GMT Standard Time:FO:Atlantic/Faroe: GMT Standard Time:GG:Europe/Guernsey: GMT Standard Time:IE:Europe/Dublin: GMT Standard Time:IM:Europe/Isle_of_Man: @@ -115,7 +115,7 @@ GTB Standard Time:GR:Europe/Athens: GTB Standard Time:001:Europe/Bucharest: Georgian Standard Time:001:Asia/Tbilisi: -Greenland Standard Time:001:America/Godthab: +Greenland Standard Time:001:America/Nuuk: Greenwich Standard Time:BF:Africa/Ouagadougou: Greenwich Standard Time:CI:Africa/Abidjan: Greenwich Standard Time:GH:Africa/Accra: @@ -136,7 +136,7 @@ Hawaiian Standard Time:PF:Pacific/Tahiti: Hawaiian Standard Time:ZZ:Etc/GMT+10: Hawaiian Standard Time:001:Pacific/Honolulu: -India Standard Time:001:Asia/Calcutta: +India Standard Time:001:Asia/Kolkata: Iran Standard Time:001:Asia/Tehran: Israel Standard Time:001:Asia/Jerusalem: Jordan Standard Time:001:Asia/Amman: @@ -161,10 +161,10 @@ Mountain Standard Time:001:America/Denver: Mountain Standard Time (Mexico):001:America/Mazatlan: Myanmar Standard Time:CC:Indian/Cocos: -Myanmar Standard Time:001:Asia/Rangoon: +Myanmar Standard Time:001:Asia/Yangon: N. Central Asia Standard Time:001:Asia/Novosibirsk: Namibia Standard Time:001:Africa/Windhoek: -Nepal Standard Time:001:Asia/Katmandu: +Nepal Standard Time:001:Asia/Kathmandu: New Zealand Standard Time:AQ:Antarctica/McMurdo: New Zealand Standard Time:001:Pacific/Auckland: Newfoundland Standard Time:001:America/St_Johns: @@ -196,7 +196,7 @@ SA Eastern Standard Time:ZZ:Etc/GMT+3: SA Eastern Standard Time:001:America/Cayenne: SA Pacific Standard Time:BR:America/Rio_Branco: -SA Pacific Standard Time:CA:America/Coral_Harbour: +SA Pacific Standard Time:CA:America/Atikokan: SA Pacific Standard Time:EC:America/Guayaquil: SA Pacific Standard Time:JM:America/Jamaica: SA Pacific Standard Time:KY:America/Cayman: @@ -236,7 +236,7 @@ SE Asia Standard Time:ID:Asia/Jakarta: SE Asia Standard Time:KH:Asia/Phnom_Penh: SE Asia Standard Time:LA:Asia/Vientiane: -SE Asia Standard Time:VN:Asia/Saigon: +SE Asia Standard Time:VN:Asia/Ho_Chi_Minh: SE Asia Standard Time:ZZ:Etc/GMT-7: SE Asia Standard Time:001:Asia/Bangkok: Saint Pierre Standard Time:001:America/Miquelon: @@ -279,7 +279,7 @@ Transbaikal Standard Time:001:Asia/Chita: Turkey Standard Time:001:Europe/Istanbul: Turks And Caicos Standard Time:001:America/Grand_Turk: -US Eastern Standard Time:001:America/Indianapolis: +US Eastern Standard Time:001:America/Indiana/Indianapolis: US Mountain Standard Time:CA:America/Creston: US Mountain Standard Time:MX:America/Hermosillo: US Mountain Standard Time:ZZ:Etc/GMT+7: @@ -292,7 +292,7 @@ UTC+12:UM:Pacific/Wake: UTC+12:WF:Pacific/Wallis: UTC+12:001:Etc/GMT-12: -UTC+13:KI:Pacific/Enderbury: +UTC+13:KI:Pacific/Kanton: UTC+13:TK:Pacific/Fakaofo: UTC+13:001:Etc/GMT-13: UTC-02:BR:America/Noronha: @@ -352,7 +352,7 @@ West Asia Standard Time:001:Asia/Tashkent: West Bank Standard Time:001:Asia/Hebron: West Pacific Standard Time:AQ:Antarctica/DumontDUrville: -West Pacific Standard Time:FM:Pacific/Truk: +West Pacific Standard Time:FM:Pacific/Chuuk: West Pacific Standard Time:GU:Pacific/Guam: West Pacific Standard Time:MP:Pacific/Saipan: West Pacific Standard Time:ZZ:Etc/GMT-10: ------------- Commit messages: - initial commit Changes: https://git.openjdk.org/jdk/pull/29591/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29591&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8377013 Stats: 28 lines in 3 files changed: 23 ins; 1 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/29591.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/29591/head:pull/29591 PR: https://git.openjdk.org/jdk/pull/29591 From jlu at openjdk.org Thu Feb 5 22:53:04 2026 From: jlu at openjdk.org (Justin Lu) Date: Thu, 5 Feb 2026 22:53:04 GMT Subject: RFR: 8377013: TimeZone.getDefault() returns obsolete id on Windows (Asia/Calcutta) In-Reply-To: References: Message-ID: On Thu, 5 Feb 2026 17:27:22 GMT, Naoto Sato wrote: > Fixing the Windows default time zones returned from `TimeZone.getDefault()` for some regions. On Windows, it uses their own regions for time zones that aren't 1-1 match to IANA's TZ database. Thus a mapping table is created as `conf/tzmappings` on Windows Java runtime. It is derived from CLDR's `windowsZones.xml` but it uses the obsolete IANA ids for their compatibility reasons. The fix is to replace the CLDR's old ids to the latest IANA ids for those regions. > Since it is hard to provide an automated test, as it involves the modification of the Windows' default time zone, regression test is not provided. Instead the fix is manually confirmed using the JIRA issue's example. Since this is a change in behavior, I will file a corresponding CSR/RN. > > Here is the diff of the generated `conf/tzmappings` for reference: > > @@ -13,7 +13,7 @@ > Arabian Standard Time:ZZ:Etc/GMT-4: > Arabian Standard Time:001:Asia/Dubai: > Arabic Standard Time:001:Asia/Baghdad: > -Argentina Standard Time:001:America/Buenos_Aires: > +Argentina Standard Time:001:America/Argentina/Buenos_Aires: > Astrakhan Standard Time:001:Europe/Astrakhan: > Atlantic Standard Time:BM:Atlantic/Bermuda: > Atlantic Standard Time:GL:America/Thule: > @@ -58,7 +58,7 @@ > Central European Standard Time:MK:Europe/Skopje: > Central European Standard Time:001:Europe/Warsaw: > Central Pacific Standard Time:AQ:Antarctica/Casey: > -Central Pacific Standard Time:FM:Pacific/Ponape: > +Central Pacific Standard Time:FM:Pacific/Pohnpei: > Central Pacific Standard Time:NC:Pacific/Noumea: > Central Pacific Standard Time:VU:Pacific/Efate: > Central Pacific Standard Time:ZZ:Etc/GMT-11: > @@ -75,7 +75,7 @@ > Dateline Standard Time:001:Etc/GMT+12: > E. Africa Standard Time:AQ:Antarctica/Syowa: > E. Africa Standard Time:DJ:Africa/Djibouti: > -E. Africa Standard Time:ER:Africa/Asmera: > +E. Africa Standard Time:ER:Africa/Asmara: > E. Africa Standard Time:ET:Africa/Addis_Ababa: > E. Africa Standard Time:KM:Indian/Comoro: > E. Africa Standard Time:MG:Indian/Antananarivo: > @@ -101,10 +101,10 @@ > FLE Standard Time:FI:Europe/Helsinki: > FLE Standard Time:LT:Europe/Vilnius: > FLE Standard Time:LV:Europe/Riga: > -FLE Standard Time:001:Europe/Kiev: > +FLE Standard Time:001:Europe/Kyiv: > Fiji Standard Time:001:Pacific/Fiji: > GMT Standard Time:ES:Atlantic/Canary: > -GMT Standard Time:FO:Atlantic/Faeroe: > +GMT Standard Time:FO:Atlantic/Faroe: > GMT Standard Time:GG:Europe/Guernsey: > GMT Standard Time:IE:Europe/Dublin: > GMT Standard Time:IM:Europe/Isle_of_Man: > @@ -115,7 +115,7 @@ > GTB St... make/jdk/src/classes/build/tools/cldrconverter/CLDRConverter.java line 296: > 294: > 295: // Parse data independent of locales > 296: parseBCP47(); Perhaps a comment either here or in `bcp47()` which indicates that parseBCP47 **must** precede `parseSupplemental()` such that the aliases can be derived from _timezone.xml_ first. make/jdk/src/classes/build/tools/cldrconverter/TimeZoneParseHandler.java line 45: > 43: class TimeZoneParseHandler extends AbstractLDMLHandler