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: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with 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: <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
Message-ID: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>

On Wed, 28 Jan 2026 23:55:50 GMT, Tatsunori Uchino <duke at openjdk.org> 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: <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <cmtXT31koW4hw4YZk51Jwi6ELCPrkGNIYnZAh1uwmg8=.96ea745b-b536-453e-9715-4fac3929e78f@github.com>
Message-ID: <HcRVi1NlmwvnUmBO4uFYAiptwtZlq33Xic2CKzV7LDQ=.a532f796-7724-462c-98bf-295406e484c0@github.com>

On Sun, 1 Feb 2026 06:28:49 GMT, Tatsunori Uchino <duke at openjdk.org> 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:      * <p>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 `<p>` and drop the trailing `</p>`.

-------------

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: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <GcKt_75EpsyvoCMr19QP31KVAsCbtU1Y8WhJB0dPJm8=.4a3c6b89-5c41-4efa-87d8-854c42f5efc3@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:

  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: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
Message-ID: <uPi_MmsLlYv6nebfLTf6-UrpORqivbI_DQCIFbvjAe4=.2dc3dd56-13c5-4a79-85db-386d6bbf0d17@github.com>

On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman <alanb at openjdk.org> 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:

<img width="783" height="180" alt="image" src="https://github.com/user-attachments/assets/1c0c1498-93b2-44cb-a9f7-1356e573141f" />

-------------

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: <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
Message-ID: <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com>

On Sun, 1 Feb 2026 08:26:28 GMT, Alan Bateman <alanb at openjdk.org> 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: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <ZBnGNuyXuKhfV2ALBAIfRlOY2kOetTiPPjsJ6omxcj4=.d0095f7f-c96d-4a96-bf56-ab59e547263f@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with one additional commit since the last revision:

  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: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
Message-ID: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>

> Adds `codePointCount()` overloads to `String`, `Character`, `(Abstract)StringBuilder`, and `StringBuffer` to make it possible to conveniently retrieve the length of a string as code points without extra boundary checks.
> 
> 
> if (superTremendouslyLongExpressionYieldingAString().codePointCount() > limit) {
>     throw new Exception("exceeding length");
> }
> 
> 
> Is a CSR required to this change?

Tatsunori Uchino has updated the pull request incrementally with 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: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <p2xgMq8mjf89XqMk5tNeRIkbnqu1AFmN6VOosMaIfmM=.f47cf995-dfbd-42ad-876f-5f1eac53e7a5@github.com>

On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino <duke at openjdk.org> 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: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <axZRMryjC5iwd4j8uHC4gZZWZSg2e2ggtqxC7TetO1U=.d3df8bac-f11c-4d1b-a0c8-64b4139905c1@github.com>

On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino <duke at openjdk.org> 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: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <0Ix-aiMznxsuePv7iSAqOId1aV2zTFOsW96OeD2D5cg=.fbd08430-b244-4170-8736-517ce84e08d4@github.com>
 <MowNm_yWhmNzkZQcZL0JWI1faIFqkwONVQA0qOSnq28=.75bf51db-2a3b-4ed3-b128-1d7e372fd449@github.com>
 <O3iuGgwFMGPK8WlS8gbejS2IiFX8e11kxUnyHi2pF0Q=.0079d6e5-5deb-4905-819d-30981669ebd5@github.com>
 <7DMT6Cy1trgRJjQCRCbQ0BfDdoatf6l1kLl8ph30onA=.04c311dd-08b8-4765-8181-8b567d878a2d@github.com>
Message-ID: <fPsUMUPoF_CPIpZ0HjsvJHgQH4brq8XUB_XwV69P9f8=.9b4e1108-92be-433d-a13a-575519522479@github.com>

On Sun, 1 Feb 2026 10:28:12 GMT, Tatsunori Uchino <duke at openjdk.org> 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: <XHY_1jA3Lkfoi7PviI7qzCeyKzvU_YYiEZWcAdiaROc=.cb8b57b6-9ebc-4cb6-9aca-418531b4fc58@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:

 - 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: <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@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 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: <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
Message-ID: <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>

On Mon, 2 Feb 2026 09:55:37 GMT, Damon Fenacci <dfenacci at openjdk.org> 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: <SYNvAd9bK1WOrvH-jV6TmwWGy2QiwvKqmCLBhjjhWIw=.08ac1fbd-9392-47bf-b3d1-3a50787a3902@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: 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: <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
Message-ID: <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>

On Mon, 2 Feb 2026 10:29:20 GMT, Tobias Hartmann <thartmann at openjdk.org> 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: <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
 <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
Message-ID: <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@github.com>

On Mon, 2 Feb 2026 12:10:48 GMT, Damon Fenacci <dfenacci at openjdk.org> 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: <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <iZvhI3BfgpXasgO7gcp4JDKeu2orh2L7EOHioaQkdcM=.3f1d5178-0492-4eff-83f3-7cb7516954bb@github.com>
 <EO0Ag3bbiaPYiLImA_wtxHWk62bDYqyCNWXdKdHPsM4=.4e386436-98b9-4e4e-92c6-82f016390e1f@github.com>
 <imlEoHvlrVgBuwT0cVHZXI9sq1foraqTPr9n_ZftA0o=.35bdbc84-0213-474c-abea-cf72cbf16155@github.com>
 <p1CTwrxY457-B_lhYXpCVgsPkphZvaELerYm4dEM5x8=.d229fbf3-9f3b-4901-94ec-d50d382f3d0a@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 <chagedorn at openjdk.org> 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 <dfenacci at openjdk.org> 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 duke at openjdk.org  Mon Feb  2 17:47:46 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 17:47:46 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
Message-ID: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>

Fix typos in comments:

- in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
- in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

-------------

Commit messages:
 - 8376954: Typos in CharacterRangeInfo and AsynchronousServerSocketChannel

Changes: https://git.openjdk.org/jdk/pull/29513/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29513&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8376954
  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/29513.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29513/head:pull/29513

PR: https://git.openjdk.org/jdk/pull/29513

From liach at openjdk.org  Mon Feb  2 17:47:47 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 17:47:47 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <XuHe7QFOzzRDhNCs6WwHzyQjx6CMGy9m1frWT26ZLn4=.fa5778ad-a35f-4494-933c-cc03a047bfa0@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

Created https://bugs.openjdk.org/browse/JDK-8376954 for you.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3835341422

From liach at openjdk.org  Mon Feb  2 19:02:13 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 2 Feb 2026 19:02:13 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <XTHzfIBlnr1pk1EPxylbuwOxJE3z9gK9vEkn1MmbkGA=.c4066d12-134c-41e4-b43d-31b0ed33cc33@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

The CRT change looks fine. Let another reviewer review the socket channel.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29513#pullrequestreview-3741322251

From bpb at openjdk.org  Mon Feb  2 19:07:23 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Feb 2026 19:07:23 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <ShcOkybzq_FEvjpp7DZRfhRcVwXR9RoKnGQv7f4GOio=.234f09a0-38d8-49b6-8023-a0923ced915e@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

Marked as reviewed by bpb (Reviewer).

src/java.base/share/classes/java/nio/channels/AsynchronousServerSocketChannel.java line 211:

> 209:      * connections on the socket. Its exact semantics are implementation specific.
> 210:      * In particular, an implementation may impose a maximum length or may choose
> 211:      * to ignore the parameter altogether. If the {@code backlog} parameter has

Looks fine.

-------------

PR Review: https://git.openjdk.org/jdk/pull/29513#pullrequestreview-3741341206
PR Review Comment: https://git.openjdk.org/jdk/pull/29513#discussion_r2755815114

From bpb at openjdk.org  Mon Feb  2 19:54:01 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 2 Feb 2026 19:54:01 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <4Tc6Vy1Uozh3-nbsgyAZOboq2nzvuA6C5ahap2rirno=.691b9fbc-364b-4d5f-9d11-e7dc276ec33e@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <4Tc6Vy1Uozh3-nbsgyAZOboq2nzvuA6C5ahap2rirno=.691b9fbc-364b-4d5f-9d11-e7dc276ec33e@github.com>
Message-ID: <K-WdpnB03b_kyGEcnIjlA9NAQ5RugbbE9oshvX0m0Tk=.b71739c0-4d1b-4150-9e59-ce2764564d27@github.com>

On Fri, 30 Jan 2026 01:14:53 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
>> 
>> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert the change of Path.of("file")

Looks all right; passes on the usual mainline CI platforms.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29487#pullrequestreview-3741483557

From duke at openjdk.org  Mon Feb  2 20:43:40 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 20:43:40 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <Xf8kuXKtvPwUK27cUcdP-PZF5wivPuXI-u2in8AGh3s=.6c355af4-c35f-40a8-9ad8-f2b979246356@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

thank you

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3837374382

From duke at openjdk.org  Mon Feb  2 20:43:41 2026
From: duke at openjdk.org (duke)
Date: Mon, 2 Feb 2026 20:43:41 GMT
Subject: RFR: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <o9zKuJnIniH8lWLaamnTGFNZyuJZ0nrjsmq3kHcFSfI=.57ea835b-d6e6-406c-9634-35d5915df524@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

@ky0n 
Your change (at version 374ccbf02657d014a493042c05dc82940bb03f91) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29513#issuecomment-3837375801

From duke at openjdk.org  Mon Feb  2 21:01:21 2026
From: duke at openjdk.org (Hendrik Schick)
Date: Mon, 2 Feb 2026 21:01:21 GMT
Subject: Integrated: 8376954: Typos in CharacterRangeInfo and
 AsynchronousServerSocketChannel
In-Reply-To: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
References: <V-WoUQMA2TpcS3FLso5-PfsPkcYazM9SbQuPg1y86eA=.374992a2-5fb4-4b52-a023-90483404c751@github.com>
Message-ID: <LrLRMV6WDYxpm4ZKj4pt1svexKNPUyUU8gTwqZdJyHo=.079d8bbf-c7b6-41d7-b7ae-f3059d6a539b@github.com>

On Sun, 1 Feb 2026 13:57:36 GMT, Hendrik Schick <duke at openjdk.org> wrote:

> Fix typos in comments:
> 
> - in java.nio.channels.AsynchronousServerSocketChannel: altogther -> altogether
> - in java.lang.classfile.attribute.CharacterRangeInfo: removed duplicated 'the' twice

This pull request has now been integrated.

Changeset: 5607a462
Author:    Hendrik Schick <hendrikjschick at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5607a4620c97ad2650a2dd3f464d03955fe17ef1
Stats:     5 lines in 2 files changed: 0 ins; 0 del; 5 mod

8376954: Typos in CharacterRangeInfo and AsynchronousServerSocketChannel

Reviewed-by: liach, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/29513

From syan at openjdk.org  Tue Feb  3 02:24:17 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 02:24:17 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <K-WdpnB03b_kyGEcnIjlA9NAQ5RugbbE9oshvX0m0Tk=.b71739c0-4d1b-4150-9e59-ce2764564d27@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <4Tc6Vy1Uozh3-nbsgyAZOboq2nzvuA6C5ahap2rirno=.691b9fbc-364b-4d5f-9d11-e7dc276ec33e@github.com>
 <K-WdpnB03b_kyGEcnIjlA9NAQ5RugbbE9oshvX0m0Tk=.b71739c0-4d1b-4150-9e59-ce2764564d27@github.com>
Message-ID: <VBC2Z6_6o9QdDIksHKrYQJ6i6PcObaQljM0ZOsMhM-I=.a207d82f-d7ca-4e5b-a866-89f3548b98cb@github.com>

On Mon, 2 Feb 2026 19:51:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Looks all right; passes on the usual mainline CI platforms.

Thanks @bplb for the reviews, suggesttions and verify.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29487#issuecomment-3838539027

From syan at openjdk.org  Tue Feb  3 02:24:19 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 02:24:19 GMT
Subject: Integrated: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException
In-Reply-To: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
Message-ID: <GEEPYM5NmOYVutFd_s_AOiWHRZh7gqrFwFHlvWxKrQo=.d3ecf8b3-3e6e-4f83-977f-e8a346bd5683@github.com>

On Thu, 29 Jan 2026 13:11:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Before this PR, if the jtreg work directory and the /tmp directory locate in different linux volume or disk partition, test will report fails "java.nio.file.AtomicMoveNotSupportedException: file -> file: Invalid cross-device link". The linux syscall `rename()` doesn't support rename file across different volume, so I think the AtomicMoveNotSupportedException is not a JVM bug.
> 
> This PR try to catch the AtomicMoveNotSupportedException and throw a SkippedException rather report fails. And split this test as two tests, one test for the default temporary directory '/tmp', another test for current jtreg work directory, this will make sure at least one test run non-skipped.

This pull request has now been integrated.

Changeset: caf13382
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/caf1338243004e62c8a9e5fc8ba5d5e19f6edba2
Stats:     35 lines in 1 file changed: 26 ins; 5 del; 4 mod

8376700: java/nio/file/DirectoryStream/SecureDS.java fails AtomicMoveNotSupportedException

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/29487

From syan at openjdk.org  Tue Feb  3 02:28:14 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 02:28:14 GMT
Subject: RFR: 8376700: java/nio/file/DirectoryStream/SecureDS.java fails
 AtomicMoveNotSupportedException [v6]
In-Reply-To: <iDDONLym9nS1CdUF6Gt_PqgAXQQSwSBobXrUhU7q-os=.0057f248-7f14-44e0-9127-65ff2e902240@github.com>
References: <q5TPF6H5U1pp6q65xlqfrF7DEWrvstU-KooLxi_3ayQ=.8087a66e-e46f-48b6-89d7-2080594e73cd@github.com>
 <J8cY4SgURFrlUP9oWmqZYbjkl-yJ34A8uT5R4RQiMGA=.030cab3d-b579-4cba-a084-4baab923612e@github.com>
 <Kyoyu5UeBZEb3GhJblQsKf8RzX1sP7pOBeEV-1N1cGw=.87755cd3-c33f-4f27-a4ab-0ebe399f562b@github.com>
 <iDDONLym9nS1CdUF6Gt_PqgAXQQSwSBobXrUhU7q-os=.0057f248-7f14-44e0-9127-65ff2e902240@github.com>
Message-ID: <hEy8Ko8_Q7yXTa2Ep_n9JnQhu01ZIbmBCdo1QOC7uXM=.b7d7db7a-f424-4491-abfd-3b9aa4b48eb8@github.com>

On Fri, 30 Jan 2026 02:50:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will create a new JBS issue to do that after this PR finish.
>
> Thanks.

The [JBS issue](https://bugs.openjdk.org/browse/JDK-8377018) has been created.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29487#discussion_r2756890036

From jpai at openjdk.org  Tue Feb  3 08:02:28 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 08:02:28 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test fails
 on AIX with java.net.ConnectException: Connection refused
Message-ID: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>

Can I please get a review of this test-only change which addresses the test failure on AIX?

As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.

@MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?

-------------

Commit messages:
 - 8377015: ConnectionRefusedMessage::testFinishConnect test fails on AIX with java.net.ConnectException: Connection refused

Changes: https://git.openjdk.org/jdk/pull/29541/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29541&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377015
  Stats: 25 lines in 1 file changed: 19 ins; 3 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/29541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29541/head:pull/29541

PR: https://git.openjdk.org/jdk/pull/29541

From syan at openjdk.org  Tue Feb  3 08:07:33 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 08:07:33 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java to
 junit
Message-ID: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>

Draft.....................

-------------

Commit messages:
 - 1. Use assertEquals instead of throw new RuntimeException; 2. Use fail instead of throw new RuntimeException
 - use assumeTrue instead of jtreg.SkippedException
 - Use junit fail instead of throw new AssertionError
 - 1. Use junit assertEquals/assertTrue instead of user defined assertTrue; 2. Use junit fail instead of shouldNotGetHere
 - 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java to junit

Changes: https://git.openjdk.org/jdk/pull/29540/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377018
  Stats: 74 lines in 1 file changed: 10 ins; 22 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From mbaesken at openjdk.org  Tue Feb  3 10:25:31 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 10:25:31 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused
In-Reply-To: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
Message-ID: <ZpwR0AYqJLwfDEYyFvhzpBOqxIHE4lvYZ1nC-Xw5UWs=.65c67f16-8563-485f-9114-d92b67ad999d@github.com>

On Tue, 3 Feb 2026 07:54:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which addresses the test failure on AIX?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.
> 
> @MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?

Marked as reviewed by mbaesken (Reviewer).

> could you please run this change against the AIX instances you have access to and see if this address the failures?

The test runs nicely on AIX  with your patch !

-------------

PR Review: https://git.openjdk.org/jdk/pull/29541#pullrequestreview-3744419729
PR Comment: https://git.openjdk.org/jdk/pull/29541#issuecomment-3840435949

From alanb at openjdk.org  Tue Feb  3 11:07:51 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 11:07:51 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <m0nR8q2bdQTEB8L9X_jqM_TI-H7ZEWI_xS_0AMXnvKE=.01f8ad28-ff9a-46e3-bed3-b8ed3289f506@github.com>

On Tue, 3 Feb 2026 07:01:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 50:

> 48: import static org.junit.jupiter.api.Assumptions.assumeTrue;
> 49: 
> 50: @EnabledOnOs({OS.LINUX, OS.MAC, OS.AIX})

I think we should leave the `@requires`, and drop the `@EnabledOnOs` as that is how the tests are selected for specific platforms across the test suite.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 300:

> 298:                 createFile(dir1.resolve(fileEntry));
> 299:                 try {
> 300:                     stream1.move(fileEntry, ts, target);

We can use assertThrows here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2758516276
PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2758518508

From jpai at openjdk.org  Tue Feb  3 11:14:17 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 11:14:17 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused [v2]
In-Reply-To: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
Message-ID: <vvKg1vw4-FtXcVKeIreCBgjM2WDuPcpVL4uM04dzgfI=.5585bfc4-2d9e-4c70-8bd8-46f25ce19557@github.com>

> Can I please get a review of this test-only change which addresses the test failure on AIX?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.
> 
> @MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  trim down code comment in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29541/files
  - new: https://git.openjdk.org/jdk/pull/29541/files/82559d64..6f59e1d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29541&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29541&range=00-01

  Stats: 4 lines in 1 file changed: 0 ins; 3 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29541.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29541/head:pull/29541

PR: https://git.openjdk.org/jdk/pull/29541

From jpai at openjdk.org  Tue Feb  3 11:14:21 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 11:14:21 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused [v2]
In-Reply-To: <lKeRwmwzSpng1WC3yZyjVAacz9Y4lXzIGIe1Z0zkOEI=.47ac4f94-3d31-428d-9982-3df65571988c@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
 <lKeRwmwzSpng1WC3yZyjVAacz9Y4lXzIGIe1Z0zkOEI=.47ac4f94-3d31-428d-9982-3df65571988c@github.com>
Message-ID: <60klnYpH6nefOA0LxFoEBAbg8b0ahOv4FZ8Mbl4u6z4=.819857c4-e019-4740-b5c7-f30ee430aacd@github.com>

On Tue, 3 Feb 2026 10:58:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   trim down code comment in test
>
> test/jdk/java/nio/channels/Selector/ConnectionRefusedMessage.java line 79:
> 
>> 77:                 // SocketChannel.connect() throws a ConnectException
>> 78:                 // even when the channel is non-blocking. Here we verify
>> 79:                 // that it contains the expected exception message.
> 
> I think you can reduce this comment down to something "Connect failed immediately" or something short as the behavior is "normal" and not specific to AIX.

Done, I've trimmed down the comment and updated the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29541#discussion_r2758541175

From alanb at openjdk.org  Tue Feb  3 11:36:19 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 11:36:19 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused [v2]
In-Reply-To: <vvKg1vw4-FtXcVKeIreCBgjM2WDuPcpVL4uM04dzgfI=.5585bfc4-2d9e-4c70-8bd8-46f25ce19557@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
 <vvKg1vw4-FtXcVKeIreCBgjM2WDuPcpVL4uM04dzgfI=.5585bfc4-2d9e-4c70-8bd8-46f25ce19557@github.com>
Message-ID: <IsYD88SgM-z7a_XT_mLbz8tk2PtCm31IoHLIWWTuzqs=.9be1ffe8-200f-41f8-aff9-b3feac032c14@github.com>

On Tue, 3 Feb 2026 11:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses the test failure on AIX?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.
>> 
>> @MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trim down code comment in test

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29541#pullrequestreview-3744748294

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: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>

On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino <duke at openjdk.org> 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 syan at openjdk.org  Tue Feb  3 13:12:16 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:12:16 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v2]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <T-YWQh_L6HYqYK8sCG1-MKnGl-2U1JPZ7_Gsmi-3SdQ=.3e652c75-489b-41c9-adde-3bac549a5c14@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove @EnableOnOS and recover @requires

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/7dc636e4..5acc4765

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=00-01

  Stats: 4 lines in 1 file changed: 1 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Tue Feb  3 13:12:18 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:12:18 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v2]
In-Reply-To: <m0nR8q2bdQTEB8L9X_jqM_TI-H7ZEWI_xS_0AMXnvKE=.01f8ad28-ff9a-46e3-bed3-b8ed3289f506@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <m0nR8q2bdQTEB8L9X_jqM_TI-H7ZEWI_xS_0AMXnvKE=.01f8ad28-ff9a-46e3-bed3-b8ed3289f506@github.com>
Message-ID: <lg6L1fUKk0Z0C8L2dlORzm_M8D6VUpfWO8S2SQnIZRg=.c0df159f-1b1c-45fa-8567-31f800daa32d@github.com>

On Tue, 3 Feb 2026 11:03:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove @EnableOnOS and recover @requires
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 50:
> 
>> 48: import static org.junit.jupiter.api.Assumptions.assumeTrue;
>> 49: 
>> 50: @EnabledOnOs({OS.LINUX, OS.MAC, OS.AIX})
> 
> I think we should leave the `@requires`, and drop the `@EnabledOnOs` as that is how the tests are selected for specific platforms across the test suite.

Thanks, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2759000209

From syan at openjdk.org  Tue Feb  3 13:24:10 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:24:10 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v3]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <3s1RyClDqw4KA2eXu_UrLHU0iTty_XnSnsrDN37zaDQ=.4601a9d4-67c9-48c9-8af3-927d1c49a25b@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException

SendaoYan has updated the pull request incrementally with two additional commits since the last revision:

 - Use assertThrows part2
 - Use assertThrows part1

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/5acc4765..9effc867

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=01-02

  Stats: 18 lines in 1 file changed: 2 ins; 6 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Tue Feb  3 13:26:54 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:26:54 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v4]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <XSDfOn63abPzJteQjenCxaO_cM0bdWOy5XfAJDhdnKY=.20beae44-7071-482a-b0aa-8598fff3d0e0@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use assertThrows part3

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/9effc867..8a1d96e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=02-03

  Stats: 27 lines in 1 file changed: 0 ins; 9 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Tue Feb  3 13:34:53 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:34:53 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v5]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <D2NDz_m8GuWuY1aUUCaUj9xl3U6jsFGY6_htxmk9tJU=.f2c80d8e-3368-4e56-9c4f-ec8668f6628b@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use assertThrows part4

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/8a1d96e2..7df0beae

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=03-04

  Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Tue Feb  3 13:34:54 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Feb 2026 13:34:54 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v5]
In-Reply-To: <m0nR8q2bdQTEB8L9X_jqM_TI-H7ZEWI_xS_0AMXnvKE=.01f8ad28-ff9a-46e3-bed3-b8ed3289f506@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <m0nR8q2bdQTEB8L9X_jqM_TI-H7ZEWI_xS_0AMXnvKE=.01f8ad28-ff9a-46e3-bed3-b8ed3289f506@github.com>
Message-ID: <iEbmOKws0zZPmbZw7Qe_3huKLjrsLx-frnbF_vBYOXw=.e99191c9-620d-424c-869d-efbeda6592ef@github.com>

On Tue, 3 Feb 2026 11:04:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use assertThrows part4
>
> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 300:
> 
>> 298:                 createFile(dir1.resolve(fileEntry));
>> 299:                 try {
>> 300:                     stream1.move(fileEntry, ts, target);
> 
> We can use assertThrows here.

Thanks for the advices. I have replaced all the try-fail-catch as assertThrows.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2759105598

From jpai at openjdk.org  Tue Feb  3 13:37:46 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 13:37:46 GMT
Subject: RFR: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused [v2]
In-Reply-To: <vvKg1vw4-FtXcVKeIreCBgjM2WDuPcpVL4uM04dzgfI=.5585bfc4-2d9e-4c70-8bd8-46f25ce19557@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
 <vvKg1vw4-FtXcVKeIreCBgjM2WDuPcpVL4uM04dzgfI=.5585bfc4-2d9e-4c70-8bd8-46f25ce19557@github.com>
Message-ID: <pEKPzUs9OacbHpZnFuYEMJ3xTgZjY1SkIqu9mEQjXW8=.7c6d1aca-1bc5-4d72-abd5-e281b7b2865a@github.com>

On Tue, 3 Feb 2026 11:14:17 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this test-only change which addresses the test failure on AIX?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.
>> 
>> @MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   trim down code comment in test

Thank you Alan and Matthias for the reviews and running the test. Given that this is a test-only fix of a recently added test, I'll go ahead and integrate it now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29541#issuecomment-3841366751

From jpai at openjdk.org  Tue Feb  3 13:41:19 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 3 Feb 2026 13:41:19 GMT
Subject: Integrated: 8377015: ConnectionRefusedMessage::testFinishConnect test
 fails on AIX with java.net.ConnectException: Connection refused
In-Reply-To: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
References: <BjVZY8F5wq2eBdAgZOokkUO8nwlzwn1DP1vTqq1Hgn4=.5b0f5638-8d04-4c9b-ab58-bd2de057e1f1@github.com>
Message-ID: <SunOczI7tS24_ZKU--oJHvKybwbh8Ki_LZQN6FS1AmA=.835fe8b2-a59e-4cfa-a0a8-31a7e06957d0@github.com>

On Tue, 3 Feb 2026 07:54:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which addresses the test failure on AIX?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8377015, this newly introduced test fails on AIX because the test wasn't expecting `SocketChannel.connect()` to throw a `ConnectException` when the channel was in non-blocking mode. The test has now been updated to allow for that scenario. The test continues to pass in our CI with these changes.
> 
> @MBaesken, could you please run this change against the AIX instances you have access to and see if this address the failures?

This pull request has now been integrated.

Changeset: 99bc9835
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99bc98357dab78bef2cce7a10c98d13d1e5730e3
Stats:     22 lines in 1 file changed: 16 ins; 3 del; 3 mod

8377015: ConnectionRefusedMessage::testFinishConnect test fails on AIX with java.net.ConnectException: Connection refused

Reviewed-by: alanb, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/29541

From alanb at openjdk.org  Tue Feb  3 15:27:30 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 15:27:30 GMT
Subject: RFR: 8374170: I/O Poller updates
Message-ID: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>

The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:

1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.

Testing: tier1 + tier2.

-------------

Commit messages:
 - pollset -> setid
 - Pull update PollsetPoller update from loom repo
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Cleanup IOUtil.configureBlocking
 - Merge branch 'master' into poller
 - ... and 3 more: https://git.openjdk.org/jdk/compare/9c83dff8...0ec1a928

Changes: https://git.openjdk.org/jdk/pull/29195/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29195&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8374170
  Stats: 1144 lines in 33 files changed: 670 ins; 140 del; 334 mod
  Patch: https://git.openjdk.org/jdk/pull/29195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29195/head:pull/29195

PR: https://git.openjdk.org/jdk/pull/29195

From alanb at openjdk.org  Tue Feb  3 15:27:31 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 15:27:31 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>

On Tue, 13 Jan 2026 15:29:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> Testing: tier1 + tier2.

@MBaesken I hope to make this PR "ready for review" soon. Would you be able to check that it builds on AIX?

Thanks, it is missing the close method. I've updated it, would you mind re-testing the build?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3830711446
PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3840652222

From mbaesken at openjdk.org  Tue Feb  3 15:27:32 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 15:27:32 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>
Message-ID: <ccvSbKEBfe25HdjnTaRapSvCA7MGERtf1XKuWaL1rPc=.bfe11a05-9929-469e-bafc-da5551ac31bc@github.com>

On Sun, 1 Feb 2026 09:34:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I hope to make this PR "ready for review" soon. Would you be able to check that it builds on AIX?

Hi @AlanBateman , sure I can add it to our build/test queue .
Should I do so now?

> Thanks, it is missing the close method. I've updated it, would you mind re-testing the build?

Done. Unfortunately it still fails, this time with


/jdk/src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java:57: error: cannot find symbol
        Pollset.pollsetDestroy(pollset);
                               ^
  symbol:   variable pollset
  location: class PollsetPoller
1 error

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3833646732
PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3841302974

From mbaesken at openjdk.org  Tue Feb  3 15:27:34 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 15:27:34 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <glFiH0B0Ghf2Ki3eCpj4mbW7VUrf7wmLqSh1LFeeoCQ=.0d2b829c-56ad-4a90-ae39-7d7f010a191c@github.com>

On Tue, 13 Jan 2026 15:29:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> Testing: tier1 + tier2.

Done, let's see what the builds+tests show .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3833782923

From alanb at openjdk.org  Tue Feb  3 15:27:33 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 15:27:33 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>
Message-ID: <Um8enVHMQOvtNzF56U1MsgA7LzsxGjy3SMBdQQBf0s8=.ead549a7-c727-4912-88f7-d5c17b68e08c@github.com>

On Sun, 1 Feb 2026 09:34:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
>> 
>> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
>> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
>> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
>> 
>> Testing: tier1 + tier2.
>
> @MBaesken I hope to make this PR "ready for review" soon. Would you be able to check that it builds on AIX?

> Hi @AlanBateman , sure I can add it to our build/test queue . Should I do so now?

If you could, that would be great, as I have no way to test changes to AIX specific code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3833713674

From mdoerr at openjdk.org  Tue Feb  3 15:27:34 2026
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 3 Feb 2026 15:27:34 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <8HJ9CuMIenxh72pPCaqAWvvOtZRwyLm0Ca9HeHKoog0=.7d02b62b-7ff9-4ee2-8842-b1846af9e9f4@github.com>

On Tue, 13 Jan 2026 15:29:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> Testing: tier1 + tier2.

The AIX build shows:
PollsetPoller.java:36: error: PollsetPoller is not abstract and does not override abstract method close() in Poller
class PollsetPoller extends Poller {
^
1 error

AIX build has passed. (Haven't run NIO tests, yet.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3837383754
PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3841720995

From mbaesken at openjdk.org  Tue Feb  3 15:27:37 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 3 Feb 2026 15:27:37 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <8HJ9CuMIenxh72pPCaqAWvvOtZRwyLm0Ca9HeHKoog0=.7d02b62b-7ff9-4ee2-8842-b1846af9e9f4@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <8HJ9CuMIenxh72pPCaqAWvvOtZRwyLm0Ca9HeHKoog0=.7d02b62b-7ff9-4ee2-8842-b1846af9e9f4@github.com>
Message-ID: <l9w3iTkogEOfkheuF_DvI0d4c5WyMriI2UKt1DOA5vs=.163d8944-b479-4386-8957-d8e9a033d1c3@github.com>

On Tue, 3 Feb 2026 14:37:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> AIX build has passed. (Haven't run NIO tests, yet.)

The java/nio tests on AIX were fine, except a timeout in java/nio/channels/AsynchronousFileChannel/Lock.java (but this might have some different reason or maybe is related to the machine) .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3841876250

From alanb at openjdk.org  Tue Feb  3 15:27:35 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Feb 2026 15:27:35 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <ccvSbKEBfe25HdjnTaRapSvCA7MGERtf1XKuWaL1rPc=.bfe11a05-9929-469e-bafc-da5551ac31bc@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <mxH81VmZXNAkVdaLNPO-fDLpmkprKScilruCVp1UYYE=.883f80fa-37d3-4be0-a9d8-26a44d7dffe3@github.com>
 <ccvSbKEBfe25HdjnTaRapSvCA7MGERtf1XKuWaL1rPc=.bfe11a05-9929-469e-bafc-da5551ac31bc@github.com>
Message-ID: <7SuRTHMTMHhdN2BKq7dXntNmYUQ5Ta5V2px3ysg-DpI=.191a6fcc-eb10-4e96-80d8-de6d9781fc6a@github.com>

On Tue, 3 Feb 2026 13:24:14 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > Thanks, it is missing the close method. I've updated it, would you mind re-testing the build?
> 
> Done. Unfortunately it still fails, this time with
> 
> ```
> /jdk/src/java.base/aix/classes/sun/nio/ch/PollsetPoller.java:57: error: cannot find symbol
>         Pollset.pollsetDestroy(pollset);

Duh, the pollset ID here is setid. Would you mind changing that locally to see if there is anything else?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3841508007

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: <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
 <Qo7hKF39XC0HuHoizEOI_me6l5BFk4nPV4zA-2NtrIk=.40ac0cbf-3206-49f6-880f-fcb26e4e9e8c@github.com>
Message-ID: <0nrxPt9EBTADN3jACynCXe6V3kf0duVrvdT-mcD-nqo=.a0764e66-8f41-4632-aa88-4bdd163e9e79@github.com>

On Tue, 3 Feb 2026 11:59:21 GMT, Alan Bateman <alanb at openjdk.org> 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 bpb at openjdk.org  Wed Feb  4 02:00:46 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Feb 2026 02:00:46 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v20]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <J0A0uK2ASzYItfVd5QCOjwLwuqWiOMswQNGpNaXLqv4=.58fb0d76-fa2a-46f2-8aa3-401706ec7746@github.com>

> 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 20 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - ... and 10 more: https://git.openjdk.org/jdk/compare/e51ccef9...84337f02

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=19
  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 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: <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
Message-ID: <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>

On Sun, 1 Feb 2026 12:55:29 GMT, Tatsunori Uchino <duke at openjdk.org> 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: <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>
References: <Ox7JWze6XO3MHtYkCjzFg4Oy3595mgT7AEzwzlDufhY=.9c8c43ec-10df-4f4a-857a-4af59b3ac9b2@github.com>
 <QYpVdB0awdZYf1lf1MEzT98AXjIoSZxgZVq4ewAodJc=.ffbb2b00-5dcd-4bdc-8348-9716b8b4259f@github.com>
 <SOaGMTY0_7qUDwbUhyXx1fuKFkP1NQvigq5gljLxPuA=.f0ead578-7107-4466-85ce-77c28982928d@github.com>
Message-ID: <jfcrhHwvEXVpWPHuwJ1oSTui4NklsllenBOn_Lxg0rg=.d62f250d-974a-453e-9d1a-487f42e8651f@github.com>

On Wed, 4 Feb 2026 12:39:07 GMT, Tatsunori Uchino <duke at openjdk.org> 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 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: <iMZBuHGVwxAbYvDpdKJWyrOwpLc5tc0QrHhNDixaKlI=.c94eaa8e-8d9c-454b-9401-b0311e79b917@github.com>

On Mon, 2 Feb 2026 14:03:00 GMT, Damon Fenacci <dfenacci at openjdk.org> 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 mbaesken at openjdk.org  Thu Feb  5 12:32:35 2026
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 5 Feb 2026 12:32:35 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <l9w3iTkogEOfkheuF_DvI0d4c5WyMriI2UKt1DOA5vs=.163d8944-b479-4386-8957-d8e9a033d1c3@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <8HJ9CuMIenxh72pPCaqAWvvOtZRwyLm0Ca9HeHKoog0=.7d02b62b-7ff9-4ee2-8842-b1846af9e9f4@github.com>
 <l9w3iTkogEOfkheuF_DvI0d4c5WyMriI2UKt1DOA5vs=.163d8944-b479-4386-8957-d8e9a033d1c3@github.com>
Message-ID: <yUITm_7BYiVrmSc81DUqlw65fq3QFP7msDverVzHK_8=.1c467f2c-9709-413f-b6cf-03fa32b50df1@github.com>

On Tue, 3 Feb 2026 15:04:07 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > AIX build has passed. (Haven't run NIO tests, yet.)
> 
> The java/nio tests on AIX were fine, except a timeout in java/nio/channels/AsynchronousFileChannel/Lock.java (but this might have some different reason or maybe is related to the machine) .

Our central tests with this patch were fine too, incl. AIX . 
( No timeout there any more in java.nio )

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3853345762

From michaelm at openjdk.org  Thu Feb  5 13:08:22 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 5 Feb 2026 13:08:22 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <J-dDZoJUS5J6wh9xVcMarGDqLDP7acsYGQTsSLsXN7g=.77bee70b-f485-4bcd-88a1-d2c33dc8be45@github.com>

On Tue, 13 Jan 2026 15:29:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
> 
> Testing: tier1 + tier2.

src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 88:

> 86:         }
> 87:         // dup2 and signal platform threads
> 88:         implPreClose(fd, reader, writer);

Can you explain why implPreClose() is called here always, where previously it was only called when reader or writer were platform threads?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29195#discussion_r2769061417

From alanb at openjdk.org  Thu Feb  5 14:34:37 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 14:34:37 GMT
Subject: RFR: 8374170: I/O Poller updates
In-Reply-To: <J-dDZoJUS5J6wh9xVcMarGDqLDP7acsYGQTsSLsXN7g=.77bee70b-f485-4bcd-88a1-d2c33dc8be45@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <J-dDZoJUS5J6wh9xVcMarGDqLDP7acsYGQTsSLsXN7g=.77bee70b-f485-4bcd-88a1-d2c33dc8be45@github.com>
Message-ID: <ez5IfAx6-EZB_vdbckazZFBzvCMc8IpcEYPF9s46qk8=.a6879ec1-7159-4190-b166-8fae67df5ab2@github.com>

On Thu, 5 Feb 2026 13:05:44 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
>> 
>> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
>> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
>> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
>> 
>> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
>> 
>> Testing: tier1 + tier2.
>
> src/java.base/share/classes/sun/nio/ch/NativeDispatcher.java line 88:
> 
>> 86:         }
>> 87:         // dup2 and signal platform threads
>> 88:         implPreClose(fd, reader, writer);
> 
> Can you explain why implPreClose() is called here always, where previously it was only called when reader or writer were platform threads?

implPreClose does signals the reader and/or writer if they are platform threads. It doesn't do any signal if they are both null. So on that front it doesn't matter if it is called or not when they are both null.

There is one small advantage to not calling it when they are both null in that it avoids a needless dup2. So I think that would be better. Thanks for bringing it up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29195#discussion_r2769483019

From alanb at openjdk.org  Thu Feb  5 15:23:31 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Feb 2026 15:23:31 GMT
Subject: RFR: 8374170: I/O Poller updates [v2]
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
> 
> Testing: tier1 + tier2.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:

 - Avoid needless dup2 when there are no platform threads blocked on fd
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - pollset -> setid
 - Pull update PollsetPoller update from loom repo
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - Merge branch 'master' into JDK-8374170
 - ... and 6 more: https://git.openjdk.org/jdk/compare/b77eec91...76e7d498

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29195/files
  - new: https://git.openjdk.org/jdk/pull/29195/files/0ec1a928..76e7d498

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29195&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29195&range=00-01

  Stats: 9641 lines in 195 files changed: 6235 ins; 2126 del; 1280 mod
  Patch: https://git.openjdk.org/jdk/pull/29195.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29195/head:pull/29195

PR: https://git.openjdk.org/jdk/pull/29195

From syan at openjdk.org  Fri Feb  6 02:48:56 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Feb 2026 02:48:56 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v6]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <Ip_uD7PgQjmQT7q2A_KfU6xgsoLYII_yZXWV6cw9DKc=.471b5d7a-f598-4c57-9a04-4834853591e7@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. use assumeTrue instead of jtreg.SkippedException
> 6. abort test instead report fail when SecureDirectoryStream not supported

SendaoYan has updated the pull request incrementally with 22 additional commits since the last revision:

 - Abort test instead report fail when SecureDirectoryStream not supported
 - Revert @build Failure in runtime/logging/ClassLoadUnloadTest.java
 - Fix fails of some cds tests
 - 1. Revert move of Failure.java; 2. Fix fails of test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/HelloDynamicCustom.java
 - Fix javac warnings
 - Remove -sourcepath $(TOPDIR)/test/hotspot/jtreg/vmTestbase
 - Remove the depedency nsk.share in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and  and move CustomClassLoader.java/ClassFileFinder.java/Failure.java to test/lib/jdk/test/lib/classloader/
 - add javac parameter -sourcepath vmTestbase to fix fails when build test-lib
 - Add @library vmTestBase for test/hotspot/jtreg/runtime/logging/ClassLoadUnloadTest.java
 - Update comment
 - ... and 12 more: https://git.openjdk.org/jdk/compare/7df0beae...cb517426

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/7df0beae..cb517426

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=04-05

  Stats: 648 lines in 81 files changed: 258 ins; 289 del; 101 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Fri Feb  6 03:20:05 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Feb 2026 03:20:05 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v7]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. Use assumeTrue instead of jtreg.SkippedException
> 6. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)
> 7. Replaced all the try-fail-catch as assertThrows.

SendaoYan 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:

  Abort test instead report fail when SecureDirectoryStream not supported

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/cb517426..14f5a0fc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=05-06

  Stats: 646 lines in 80 files changed: 288 ins; 259 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From syan at openjdk.org  Fri Feb  6 03:20:07 2026
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Feb 2026 03:20:07 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v6]
In-Reply-To: <Ip_uD7PgQjmQT7q2A_KfU6xgsoLYII_yZXWV6cw9DKc=.471b5d7a-f598-4c57-9a04-4834853591e7@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <Ip_uD7PgQjmQT7q2A_KfU6xgsoLYII_yZXWV6cw9DKc=.471b5d7a-f598-4c57-9a04-4834853591e7@github.com>
Message-ID: <mpfFSAL0Ybdov7cuGbIDS99BwVkghCQPNASBHUn_IDs=.bf10d70f-edc4-4b28-b74f-d996747f886e@github.com>

On Fri, 6 Feb 2026 02:48:56 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
>> 
>> Changes include:
>> 
>> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
>> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
>> 3. Use assertEquals instead of throw new RuntimeException
>> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
>> 5. Use assumeTrue instead of jtreg.SkippedException
>> 6. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)
>> 7. Replaced all the try-fail-catch as assertThrows.
>
> SendaoYan has updated the pull request incrementally with 22 additional commits since the last revision:
> 
>  - Abort test instead report fail when SecureDirectoryStream not supported
>  - Revert @build Failure in runtime/logging/ClassLoadUnloadTest.java
>  - Fix fails of some cds tests
>  - 1. Revert move of Failure.java; 2. Fix fails of test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/HelloDynamicCustom.java
>  - Fix javac warnings
>  - Remove -sourcepath $(TOPDIR)/test/hotspot/jtreg/vmTestbase
>  - Remove the depedency nsk.share in test/lib/jdk/test/lib/classloader/ClassUnloadCommon.java, and  and move CustomClassLoader.java/ClassFileFinder.java/Failure.java to test/lib/jdk/test/lib/classloader/
>  - add javac parameter -sourcepath vmTestbase to fix fails when build test-lib
>  - Add @library vmTestBase for test/hotspot/jtreg/runtime/logging/ClassLoadUnloadTest.java
>  - Update comment
>  - ... and 12 more: https://git.openjdk.org/jdk/compare/7df0beae...cb517426

> @sendaoYan Please do not rebase or force-push to an active PR as it invalidates existing review comments. Note for future reference, the bots always squash all changes into a single commit automatically as part of the integration. See [OpenJDK Developers? Guide](https://openjdk.org/guide/#working-with-pull-requests) for more information.

Sorry for the accidental rebase... I had to remove the accidental rebase by force-push.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29540#issuecomment-3857695893

From alanb at openjdk.org  Fri Feb  6 07:35:30 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Feb 2026 07:35:30 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v7]
In-Reply-To: <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>
Message-ID: <NB-OycerXWkcVArSsk2uNZLg_fl_YwYNV6J9e1Dixho=.4f31469d-9da1-48cc-9bbf-5aaa905e7cd1@github.com>

On Fri, 6 Feb 2026 03:20:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
>> 
>> Changes include:
>> 
>> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
>> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
>> 3. Use assertEquals instead of throw new RuntimeException
>> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
>> 5. Use assumeTrue instead of jtreg.SkippedException
>> 6. Use assertThrows instead of all the try-fail-catch
>> 7. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)
>
> SendaoYan 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:
> 
>   Abort test instead report fail when SecureDirectoryStream not supported

This looks a good migration.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29540#pullrequestreview-3761308878

From dfenacci at openjdk.org  Fri Feb  6 07:44:44 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 6 Feb 2026 07:44:44 GMT
Subject: RFR: 8374582: [REDO] Move input validation checks to Java for
 java.lang.StringCoding intrinsics
In-Reply-To: <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>
References: <3ci9RXEra2BlQPhYl-M0Wnu3hRpWaDvxPnMRzFnJA_k=.67795fb3-95d1-449b-a7a9-44b3776aa626@github.com>
 <ILLRs0p4F_EwS1Qxnn-VCMaNpOG8qp-S06b8pWzuRfQ=.8ae1f46e-60d2-4747-bafb-96e64270caef@github.com>
Message-ID: <SEIKY8PZJsofFbK26THAjugLY3H4aXoqptBFOByz3Mc=.e6a98413-a506-48df-b7f3-04a26fc896ea@github.com>

On Fri, 23 Jan 2026 13:47:53 GMT, Volkan Yazici <vyazici at openjdk.org> wrote:

>> ## Issue
>> 
>> This is a redo of [JDK-8361842](https://bugs.openjdk.org/browse/JDK-8361842) which was backed out by [JDK-8374210](https://bugs.openjdk.org/browse/JDK-8374210) due to C2-related regressions. The original change moved input validation checks for java.lang.StringCoding from the intrinsic to Java code (leaving the intrinsic check only with the `VerifyIntrinsicChecks` flag). Refer to the [original PR](https://github.com/openjdk/jdk/pull/25998) for details.
>> 
>> This additional issue happens because, in some cases, for instance when the Java checking code is not inlined and we give an out-of-range constant as input, we fold the data path but not the control path and we crash in the backend.
>> 
>> ## Causes
>> 
>> The cause of this is that the out-of-range constant (e.g. -1) floats into the intrinsic and there (assuming the input is valid) we add a constraint to its type to positive integers (e.g. to compute the array address) which makes it top.
>> 
>> ## Fix
>> 
>> A possible fix is to introduce an opaque node (OpaqueGuardNode) similar to what we do in `must_be_not_null` for values that we know cannot be null:
>> https://github.com/openjdk/jdk/blob/ce721665cd61d9a319c667d50d9917c359d6c104/src/hotspot/share/opto/graphKit.cpp#L1484
>> This will temporarily add the range check to ensure that C2 figures that out-of-range values cannot reach the intrinsic. Then, during macro expansion, we replace the opaque node with the corresponding constant (true/false) in product builds such that the actually unneeded guards are folded and do not end up in the emitted code.
>> 
>> # Testing
>> 
>> * Tier 1-3+
>> * 2 JTReg tests added
>>   * `TestRangeCheck.java` as regression test for the reported issue
>>   * `TestOpaqueGuardNodes.java` to check that opaque guard nodes are added when parsing and removed at macro expansion
>
> I'd like to provide some help for reviewers:
> 
> 1. [JDK-8361842] (integrated in 655dc516c22) implemented changes for `java.lang.StringCoding`
> 2. [JDK-8374210] (integrated in 7e18de137c3) reported regressions against JDK-8361842, and used as the BACKOUT issue.
> 3. [JDK-8374582] (this PR) is the REDO of JDK-8361842, plus the fix for regressions reported in JDK-8374210
> 
> That is, this PR starts with 3c466d372b7 (i.e, the revert of 7e18de137c3), and continues with the fix, which is **the interesting part, and that can be viewed by diff'ing 3c466d372b7...ff22857609d**. (ff22857609d is the last commit as of date.)
> 
> [JDK-8361842]: https://bugs.openjdk.org/browse/JDK-8361842
> [JDK-8374210]: https://bugs.openjdk.org/browse/JDK-8374210
> [JDK-8374582]: https://bugs.openjdk.org/browse/JDK-8374582

Thanks a lot for your reviews @vy @chhagedorn @TobiHartmann!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29164#issuecomment-3858562112

From dfenacci at openjdk.org  Fri Feb  6 07:47:58 2026
From: dfenacci at openjdk.org (Damon Fenacci)
Date: Fri, 6 Feb 2026 07:47:58 GMT
Subject: Integrated: 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: <RAPvCUiWJQUnfx3ZUKknSjbF-Xf-uNu-yWNjY_fEibc=.ce5bb433-f320-4595-b1cb-3498a8f0096e@github.com>

On Mon, 12 Jan 2026 10:29:39 GMT, Damon Fenacci <dfenacci at openjdk.org> 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

This pull request has now been integrated.

Changeset: bfd5bdaf
Author:    Damon Fenacci <dfenacci at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfd5bdaf7ffd96cf887fbbfe072414be38ee1b84
Stats:     462 lines in 36 files changed: 306 ins; 19 del; 137 mod

8374582: [REDO] Move input validation checks to Java for java.lang.StringCoding intrinsics

Co-authored-by: Volkan Yazici <vyazici at openjdk.org>
Reviewed-by: chagedorn, thartmann, vyazici

-------------

PR: https://git.openjdk.org/jdk/pull/29164

From michaelm at openjdk.org  Fri Feb  6 08:55:27 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 6 Feb 2026 08:55:27 GMT
Subject: RFR: 8374170: I/O Poller updates [v2]
In-Reply-To: <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
Message-ID: <HnH-VgNnOuuyurbHUx0IJKVt3DjOwpa_bFaivihr4Nk=.c4b72924-ba8f-4c02-bcf2-eb4ee5e0d12d@github.com>

On Thu, 5 Feb 2026 15:23:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
>> 
>> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
>> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
>> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
>> 
>> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
>> 
>> Testing: tier1 + tier2.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Avoid needless dup2 when there are no platform threads blocked on fd
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - pollset -> setid
>  - Pull update PollsetPoller update from loom repo
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/fa041031...76e7d498

The implementation looks good to me. I wonder should some of the existing tests like BlockingChannelOps.java be updated to also run in pollerMode=3?

-------------

PR Review: https://git.openjdk.org/jdk/pull/29195#pullrequestreview-3761623879

From alanb at openjdk.org  Fri Feb  6 08:59:26 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 6 Feb 2026 08:59:26 GMT
Subject: RFR: 8374170: I/O Poller updates [v2]
In-Reply-To: <HnH-VgNnOuuyurbHUx0IJKVt3DjOwpa_bFaivihr4Nk=.c4b72924-ba8f-4c02-bcf2-eb4ee5e0d12d@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
 <HnH-VgNnOuuyurbHUx0IJKVt3DjOwpa_bFaivihr4Nk=.c4b72924-ba8f-4c02-bcf2-eb4ee5e0d12d@github.com>
Message-ID: <KUTJUkyX4QqTRAx5PrfsQNyljmOsKbFIRC2tuUHvvKw=.1956ee8b-cfca-405f-b274-67c62585133b@github.com>

On Fri, 6 Feb 2026 08:52:27 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

> The implementation looks good to me. I wonder should some of the existing tests like BlockingChannelOps.java be updated to also run in pollerMode=3?

Thanks for spending time on this, it is a big update. The BlockingChannelOps, BlockingSocketOps and SelectorOps are updated to exercise this mode on Linux and macOS.  They are the main 3 tests that exercise this code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3858894901

From michaelm at openjdk.org  Fri Feb  6 09:13:33 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 6 Feb 2026 09:13:33 GMT
Subject: RFR: 8374170: I/O Poller updates [v2]
In-Reply-To: <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
Message-ID: <DG0GCdp1tlDO_X1AHpR5SmTAHimEd9Ksyd82psV3Dl0=.727f9c13-6b6c-454e-bbc4-afe070711720@github.com>

On Thu, 5 Feb 2026 15:23:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
>> 
>> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
>> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
>> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
>> 
>> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
>> 
>> Testing: tier1 + tier2.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 16 additional commits since the last revision:
> 
>  - Avoid needless dup2 when there are no platform threads blocked on fd
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - pollset -> setid
>  - Pull update PollsetPoller update from loom repo
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - Merge branch 'master' into JDK-8374170
>  - ... and 6 more: https://git.openjdk.org/jdk/compare/98f093a9...76e7d498

Marked as reviewed by michaelm (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/29195#pullrequestreview-3761703579

From michaelm at openjdk.org  Fri Feb  6 09:13:35 2026
From: michaelm at openjdk.org (Michael McMahon)
Date: Fri, 6 Feb 2026 09:13:35 GMT
Subject: RFR: 8374170: I/O Poller updates [v2]
In-Reply-To: <KUTJUkyX4QqTRAx5PrfsQNyljmOsKbFIRC2tuUHvvKw=.1956ee8b-cfca-405f-b274-67c62585133b@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
 <SV74aynPyqaHQRNuJ8_U1LTMVSbms2eO7P6J9ZpLCsM=.d7920a21-5bc8-4f99-921a-c83198c4d079@github.com>
 <HnH-VgNnOuuyurbHUx0IJKVt3DjOwpa_bFaivihr4Nk=.c4b72924-ba8f-4c02-bcf2-eb4ee5e0d12d@github.com>
 <KUTJUkyX4QqTRAx5PrfsQNyljmOsKbFIRC2tuUHvvKw=.1956ee8b-cfca-405f-b274-67c62585133b@github.com>
Message-ID: <1o2IbTmSmf6xFMaICxOjS7Lwxqsr6fH_LSidPwo4lRQ=.33c03d4a-f0ee-481b-b90e-7a451cedce20@github.com>

On Fri, 6 Feb 2026 08:57:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > The implementation looks good to me. I wonder should some of the existing tests like BlockingChannelOps.java be updated to also run in pollerMode=3?
> 
> Thanks for spending time on this, it is a big update. The BlockingChannelOps, BlockingSocketOps and SelectorOps are updated to exercise this mode on Linux and macOS. They are the main 3 tests that exercise this code.

Somehow, I missed the test updates. Thanks. Looks good then.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29195#issuecomment-3858957077

From syan at openjdk.org  Mon Feb  9 21:26:17 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:26:17 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
Message-ID: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>

Hi all,

This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.

Changes include:

1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

-------------

Commit messages:
 - Remove the unused "FileStore prev = null;"
 - Split doTests as 6 junit parameterizedTests
 - Optimise import
 - Use HashSet to detect is there duplication filestore
 - 1. Fix the logic mistake; 2. Use Junit Supplier instead create variable msg
 - Use assumeTrue instead of print skipped info
 - 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit

Changes: https://git.openjdk.org/jdk/pull/29623/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371979
  Stats: 126 lines in 1 file changed: 47 ins; 16 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From alanb at openjdk.org  Mon Feb  9 21:26:18 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Feb 2026 21:26:18 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <Vvht2ZfNddVAQj_eQTOSN_HyGy0lIcd947kOfNxSlkc=.e0b32bb5-e1e8-4104-99d6-f5eca6fac84d@github.com>

On Sun, 8 Feb 2026 11:35:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

I think the migration of this test to JUnit will need to split up doTests so that each of the tests in that method is a paramterized test (with "dir" as the parameter).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29623#issuecomment-3870312552

From syan at openjdk.org  Mon Feb  9 21:26:19 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:26:19 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
In-Reply-To: <Vvht2ZfNddVAQj_eQTOSN_HyGy0lIcd947kOfNxSlkc=.e0b32bb5-e1e8-4104-99d6-f5eca6fac84d@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <Vvht2ZfNddVAQj_eQTOSN_HyGy0lIcd947kOfNxSlkc=.e0b32bb5-e1e8-4104-99d6-f5eca6fac84d@github.com>
Message-ID: <xy80BNJQqZtoJdaiJd7vwS6LcKd7K45dCxJFIJm0ytI=.eda1889c-94d9-4ced-a09c-100d3760e014@github.com>

On Mon, 9 Feb 2026 09:03:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the migration of this test to JUnit will need to split up doTests so that each of the tests in that method is a paramterized test (with "dir" as the parameter).

Thanks. The doTest has been splited to 6 parameterized tests, and the `Platform.isWindows()` has been replaced as `@EnabledOnOs({OS.WINDOWS})`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29623#issuecomment-3872028608

From liach at openjdk.org  Mon Feb  9 21:26:23 2026
From: liach at openjdk.org (Chen Liang)
Date: Mon, 9 Feb 2026 21:26:23 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <t1VI5MdQ1QKG2YTzFwOmqPx-Ri9-vDrn3QE9bR0rEOo=.e213809a-30ae-4e87-95b5-1cfa582ab1a6@github.com>

On Sun, 8 Feb 2026 11:35:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

test/jdk/java/nio/file/FileStore/Basic.java line 64:

> 62:                                        space, actual, expected, diff,
> 63:                                        (float)diff/G);
> 64:         assertTrue(diff < G, msg);

Let's move msg construction into a lambda here to avoid costly string formatting. And the comparison should be `diff <= G` to be strict.

test/jdk/java/nio/file/FileStore/Basic.java line 138:

> 136:          */
> 137:         assumeTrue(FileUtils.areMountPointsAccessibleAndUnique());
> 138:         FileStore prev = null;

This deduplication checking should be done with a `Set` instead of such a variable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2780498172
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2780500578

From syan at openjdk.org  Mon Feb  9 21:26:25 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:26:25 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
In-Reply-To: <t1VI5MdQ1QKG2YTzFwOmqPx-Ri9-vDrn3QE9bR0rEOo=.e213809a-30ae-4e87-95b5-1cfa582ab1a6@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <t1VI5MdQ1QKG2YTzFwOmqPx-Ri9-vDrn3QE9bR0rEOo=.e213809a-30ae-4e87-95b5-1cfa582ab1a6@github.com>
Message-ID: <cEBDAMRSDGMi00wxL-eHn8CMXh8cYLr9cT6uDcIk6II=.04005403-7f6d-4171-9a29-fbda8e3d744a@github.com>

On Mon, 9 Feb 2026 04:13:08 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
>> 
>> Changes include:
>> 
>> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
>> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
>> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
>> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull
>
> test/jdk/java/nio/file/FileStore/Basic.java line 64:
> 
>> 62:                                        space, actual, expected, diff,
>> 63:                                        (float)diff/G);
>> 64:         assertTrue(diff < G, msg);
> 
> Let's move msg construction into a lambda here to avoid costly string formatting. And the comparison should be `diff <= G` to be strict.

Sorry for the logic mistake. Fixed.

> test/jdk/java/nio/file/FileStore/Basic.java line 138:
> 
>> 136:          */
>> 137:         assumeTrue(FileUtils.areMountPointsAccessibleAndUnique());
>> 138:         FileStore prev = null;
> 
> This deduplication checking should be done with a `Set` instead of such a variable.

Thanks. I use HashSet to check is there any duplicate file store.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2781375671
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2781593836

From mcimadamore at openjdk.org  Mon Feb  9 21:32:09 2026
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Feb 2026 21:32:09 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <4XtDzO577CpjYbza6luwnpzsXxuZ9L7ttq80_Ypt_Bw=.9cc3b7ea-dfb5-44d1-a468-c7359c0a7a43@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Overall, I think that this is a good experiment (and I'm very grateful for it), but I'm a bit skeptical in seeing it introduced in the JDK codebase. This is a very sensitive area, with lots of multi-threaded gotchas (lots of different failure modes to take into account). As I commented originally, I still feel like separating the ref counter from the liveness bit (ignoring everything else) brings even more failure modes to the table.

After discussing all of this with @JornVernee, we agreed that we should refrain from integrating this work (even if provided merely as an option), and maybe keep the door open to explore other alternatives that might provide some relief, while keeping the code more maintainable in the long run

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3872916825

From jvernee at openjdk.org  Mon Feb  9 21:31:59 2026
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 9 Feb 2026 21:31:59 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
Message-ID: <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>

On Mon, 1 Dec 2025 11:59:38 GMT, Stuart Monteith <smonteith at openjdk.org> wrote:

> MemorySegments allocated from shared Arena from
> java.lang.foreign.Arena.ofShared() have their lifecycle controlled by jdk.internal.foreign.SharedSession. This class ensures that the MemorySegments can't be freed until after a thread has called Arena.close(). This is implemented using a counter that is atomically incremented when used, and decremented when not used, on every invocation of a downcall. While shared Arenas allow any thread to use it and to close it, this tracking has a cost when multiple threads are contended on it. This patch changes the implementation to use multiple counters to reduce contention. sun.nio.ch.IOUtil, java.nio.Buffer and sun.nio.ch.SimpleAsynchronousFileChannelImpl are modified as they have threads releasing the scope different from the ones that allocated them, so a ticket that tracks the counter has to be passed over.
> 
> The microbenchmark org.openjdk.bench.java.lang.foreign. CallOverheadConstant.panama_identity_memory_address_shared_3 was used to generate the following results. The scalability was checked on a number of platforms with the JMH parameter "-t" specifying the number of threads. Measurements are in ns/op .
> 
> The hardware are the Neoverse-N1, N2, V1 and V2, Intel Xeon 8375c and the AMD Epyc 9654.
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    30.88   |   32.15  |    33.54  |    32.82  |    27.46  |     8.45 |
> |   2    | 142.56    | 134.48  |   132.01 |    131.50 |    116.68   |   46.53 |
> |  4    |  310.18   |  282.75  |   287.59  |   271.82  |   251.88   |   86.11 |
> |  8    |  702.02   |  710.29  |   736.72  |   670.63  |   533.46   |  194.60 |
> |   16  |  1,436.17 |  1,684.80 |  1,833.69 |  1,782.78 |  1,100.15 |    827.28 |
> |  24  | 2,185.55 |  2,508.86 |  2,732.22 |  2,815.26 |  1,646.09 |  1,530.28  |
> |   32  | 2,942.48 |  3,432.84 |  3,643.64 |  3,782.23 |  2,236.81 |  2,278.52 |
> |   48  | 4,466.56 |  5,174.72 |  5,401.95 |  5,621.41 |  4,926.30  | 3,026.58 |
> 
> After:
> 
> | Threads |   N1   |      N2   |         V1  |       V2   |    Xeon   |    Epyc |
> |---------|-------|-------|-------|-------|-------|-------|
> |    1  |    32.41  |    32.11  |    34.43  |  31.32  |    27.94  |     9.82 |
> |    2  |    32.64  |    33.72  |    35.11  |  31.30  |    28.02  |     9.81 |
> |    4  |    32.71  |    36.84  |    34.67  |  31.35  |   28.12   |   10.49 |
> |    8  |    58.22  |    31.60  |    36.87  |  31.72  |    47.09  |...

Thanks for looking at this.

Besides the code comments, there are few points that I'd like to bring up as well:

1. I'm not sure I see using a ticket being worth it vs. just calling `getCounter` again in `release0`. The JIT understands that the current thread doesn't change in most situations, so it should be able to common out the load of the hash code.

2. This adds significant footprint to SharedSession. Especially on server class machines which can have as much as to 512 logical processors (or more), this would add 8 pages of memory use per session instance, assuming the typical 64 byte cache line size, just for the counters.

3. This is already a tricky bit of code in which we've seen several hard to diagnose issues. So, making changes here makes me a bit nervous, and I'm honestly having a hard time judging the cost vs. benefit of this change, considering also that the benchmark is testing the absolute worst case scenario where the acquire/release are being hammered. (and now I _really_ wish I had found the time to look at this earlier).

Given 2. and 3. taken together, and out of an abundance of caution, I suggest keeping both the old and new implementations as separate MemorySessionImpl sub-classes, and then using a system property to select one or the other in `createShared`. Just in case someone wants to switch back to the single counter implementation, or in case we want to use this to diagnose an issue. (Having a single static property select between the impls should also avoid issues with megamorphic call sites since the total number of loaded impls in a given process should stay the same).

src/java.base/share/classes/jdk/internal/foreign/ConfinedSession.java line 54:

> 52:     public int acquire0() {
> 53:         checkValidState();
> 54:         if (acquireCount == MAX_FORKS) {

This acquireCount field should be moved to ConfinedSession

src/java.base/share/classes/jdk/internal/foreign/SharedResourceList.java line 66:

> 64:         if (FST.getAcquire(this) != ResourceCleanup.CLOSED_LIST) {
> 65:             //ok now we're really closing down
> 66:             ResourceCleanup prev = null;

My IDE tells me this `null` assignment is redundant.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 51:

> 49: 
> 50:     final static private int numCounters;
> 51:     final static private int mask;

Suggestion:

    final static private int COUNTER_MASK;

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 54:

> 52: 
> 53:     // The number of ints per cacheline.
> 54:     final static private int multiplier;

Suggestion:

    final static private int INTS_PER_COUNTER;

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 56:

> 54:     final static private int multiplier;
> 55:     final static int CNT_CLOSING = -1;
> 56:     final static int CNT_CLOSED = -2;

Please use the existing style for modifier order here: `private static final`, and capitalize `static final` field names.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 58:

> 56:     final static int CNT_CLOSED = -2;
> 57: 
> 58:     private static final jdk.internal.misc.Unsafe UNSAFE = jdk.internal.misc.Unsafe.getUnsafe();

Could you use an import here?

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 78:

> 76: 
> 77:         // Each counter is an integer on its own cacheline.
> 78:         multiplier = ((cacheLineSize < Integer.BYTES) ? 64 : cacheLineSize) / Integer.BYTES;

Why 64 and not 4? Or just `Math.max(cacheLineSize, Integer.BYTES)`.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 101:

> 99:     private int compareAndExchange(int index, int expected, int value) {
> 100:         assert numCounters > index;
> 101:         return counters.compareAndExchange(index * multiplier, expected, value);

Suggestion:

    @ForceInline
    private int getAcquireCounter(int index) {
        assert numCounters > index;
        return counters.getAcquire(index * multiplier);
    }

    @ForceInline
    private int compareAndExchangeCounter(int index, int expected, int value) {
        assert numCounters > index;
        return counters.compareAndExchange(index * multiplier, expected, value);


Also, maybe you want to use these from `justClose`.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 129:

> 127:                     old = getAcquire(ticket);
> 128:                     Thread.onSpinWait();
> 129:                 } while (old == CNT_CLOSING);

My worry with something like this is that we don't make monotonic progress between the states, but we might back off and retry.

In other words, if a closing thread fails to close the session, we loop back around, but might end up here again if another thread tries to close the session again, so we could theoretically get 'stuck' here.

In this case I believe it's okay since failing to close a session is typically an indication of an issue in the application logic, so we don't expect this to happen over and over again. Although, we've seen this being used in the wild as a fallback where close was called on a maybe-closed session from a cleaner.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 151:

> 149:                 old = compareAndExchange(ticket, value, value - 1);
> 150:             } else {
> 151:                 throw alreadyClosed();

Please keep the existing comment for this case

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 157:

> 155: 
> 156:     synchronized void justClose() {
> 157:         int value;

Why is this declared here?

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 180:

> 178:                 // It is already closed - throw an exception.
> 179:                 throw alreadyClosed();
> 180:             }

I don't see how this could occur. You've made `justClose` synchronized, which means we will always see an up to date `state`, and threads can not race to close the session anymore.

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 220:

> 218:     public boolean isCloseable() {
> 219:         if (state == CLOSED) {
> 220:             return true;

This doesn't look right to me. I don't think any override is needed here. It's not a predicate intended to ask whether a session is closeable in it's current state, but rather to ask whether the session kind can be explicitly closed at all.

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 301:

> 299:                 sessionTickets[i] = ticketLocal;
> 300:                 cb.loadConstant(0)
> 301:                 .istore(ticketLocal);

Suggestion:

                  .istore(ticketLocal);

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 566:

> 564:             int ticketLocal = sessionTickets[i];
> 565:             cb.aload(scopeLocal)
> 566:             .ifThen(Opcode.IFNONNULL, ifCb -> {

Suggestion:

              .ifThen(Opcode.IFNONNULL, ifCb -> {

src/java.base/share/classes/jdk/internal/foreign/abi/BindingSpecializer.java line 569:

> 567:                 ifCb.aload(scopeLocal)
> 568:                 .iload(ticketLocal)
> 569:                 .invokevirtual(CD_MemorySessionImpl, "release0", MTD_RELEASE0);

Suggestion:

                    .iload(ticketLocal)
                    .invokevirtual(CD_MemorySessionImpl, "release0", MTD_RELEASE0);

test/jdk/java/foreign/TestMemorySession.java line 396:

> 394:         int ticket = sessionImpl.acquire0();
> 395: 
> 396:         assertFalse(sessionImpl.isCloseable());

i.e. this should return `true`, shared session may be closed.

test/jdk/java/foreign/TestMemorySession.java line 431:

> 429:         } catch (IllegalStateException e) {
> 430:             fail();
> 431:         }

Failure is implicit if an exception is thrown, so this try/catch shouldn't be necessary.

test/jdk/java/foreign/TestMemorySession.java line 439:

> 437:         } catch (IllegalStateException e) {
> 438:             fail();
> 439:         }

Same here

test/jdk/java/foreign/TestMemorySession.java line 466:

> 464:         boolean closeLose = false;
> 465: 
> 466:         while (true) {

We can't just loop indefinitely. This will definitely result in test timeouts eventually. Please add an upper bound for the number of iterations.

test/jdk/java/foreign/TestMemorySession.java line 481:

> 479:                 threads[i].start();
> 480:             }
> 481:             Thread.sleep(100);

Thread.sleep is not very reliable, especially in highly concurrent CI environment. If the intent is to wait for the threads so start up, I suggest using a CountDownLatch.

-------------

PR Review: https://git.openjdk.org/jdk/pull/28575#pullrequestreview-3544278113
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782215557
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782052307
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782237502
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782236426
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2676944433
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592405598
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782072535
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782322487
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2635843460
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782220024
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782226537
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782264630
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782317235
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2774197899
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592332912
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2592333337
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782350583
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782365127
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782370062
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782403652
PR Review Comment: https://git.openjdk.org/jdk/pull/28575#discussion_r2782390762

From syan at openjdk.org  Mon Feb  9 21:39:35 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:39:35 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v8]
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <5SwRvsKzn1rmsAq-RTBx1GDWF53oi69IBbAInjRKkkc=.f3130690-e91f-438b-87b8-0dccdf8d1389@github.com>

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. Use assumeTrue instead of jtreg.SkippedException
> 6. Use assertThrows instead of all the try-fail-catch
> 7. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  import ParameterizedTest should be before provider

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29540/files
  - new: https://git.openjdk.org/jdk/pull/29540/files/14f5a0fc..b49319bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29540&range=06-07

  Stats: 2 lines in 1 file changed: 1 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29540.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29540/head:pull/29540

PR: https://git.openjdk.org/jdk/pull/29540

From bpb at openjdk.org  Mon Feb  9 21:39:36 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Feb 2026 21:39:36 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v8]
In-Reply-To: <5SwRvsKzn1rmsAq-RTBx1GDWF53oi69IBbAInjRKkkc=.f3130690-e91f-438b-87b8-0dccdf8d1389@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <5SwRvsKzn1rmsAq-RTBx1GDWF53oi69IBbAInjRKkkc=.f3130690-e91f-438b-87b8-0dccdf8d1389@github.com>
Message-ID: <xUpnkerelthXuPCuMzz_43stx94OTxtqU_FEUbxCpEo=.ec0944a7-c5e8-46ab-ae55-9171370d294b@github.com>

On Sun, 8 Feb 2026 11:24:19 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
>> 
>> Changes include:
>> 
>> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
>> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
>> 3. Use assertEquals instead of throw new RuntimeException
>> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
>> 5. Use assumeTrue instead of jtreg.SkippedException
>> 6. Use assertThrows instead of all the try-fail-catch
>> 7. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   import ParameterizedTest should be before provider

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/29540#pullrequestreview-3765893005

From alanb at openjdk.org  Mon Feb  9 21:39:07 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Feb 2026 21:39:07 GMT
Subject: Integrated: 8374170: I/O Poller updates
In-Reply-To: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
References: <3BNiNARWNklBrVzKOXmPeHCgkbP32Mp9An95Pn-pxV4=.31117837-87a0-47a0-bc69-c0eff450cdeb@github.com>
Message-ID: <5WtpHccXoNv8u3qXIdY-ScYPxSwRRwQrgxTB3FB8Xlc=.e5e5b080-b7b6-40a5-8565-aab76b43d5a9@github.com>

On Tue, 13 Jan 2026 15:29:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The I/O Poller used to support virtual threads doing blocking networking I/O has been significantly refactored in the loom repo. There are several improvements that should be brought to main line:
> 
> 1. New poller mode that uses a read poller per carrier, this is beneficial in some workloads.
> 2. Better cleanup/recovery in the event if a file descriptor or memory can't be allocated during initializatio.
> 3. NativeThread changed to cache native thread ID and avoid JNI call to current0 for each blocking I/O op.
> 
> The changes have been in the loom repo for a long time, this is why the copyright header is updated to 2025 (not 2026) in some cases.
> 
> Testing: tier1 + tier2.

This pull request has now been integrated.

Changeset: cd5256d5
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd5256d5a654d436e5ef926f6afb1bcbfc7a8bd1
Stats:     1145 lines in 33 files changed: 672 ins; 140 del; 333 mod

8374170: I/O Poller updates

Reviewed-by: michaelm

-------------

PR: https://git.openjdk.org/jdk/pull/29195

From bpb at openjdk.org  Mon Feb  9 21:39:41 2026
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Feb 2026 21:39:41 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v7]
In-Reply-To: <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>
Message-ID: <DHPoUVWSVZZaRkkqoQx7lDMHYOwzCbwuJWxfWZm8Wfo=.cb6279b8-1474-4bd7-a07e-494bdb082b3a@github.com>

On Fri, 6 Feb 2026 03:20:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
>> 
>> Changes include:
>> 
>> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
>> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
>> 3. Use assertEquals instead of throw new RuntimeException
>> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
>> 5. Use assumeTrue instead of jtreg.SkippedException
>> 6. Use assertThrows instead of all the try-fail-catch
>> 7. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)
>
> SendaoYan 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:
> 
>   Abort test instead report fail when SecureDirectoryStream not supported

Aside from my trivial comment about import order, I think this looks good.

test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 43:

> 41: import jdk.test.lib.Platform;
> 42: import org.junit.jupiter.params.provider.ValueSource;
> 43: import org.junit.jupiter.params.ParameterizedTest;

Nit: I think this import should be before the previous one.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29540#issuecomment-3861964938
PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2775440336

From syan at openjdk.org  Mon Feb  9 21:39:42 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:39:42 GMT
Subject: RFR: 8377018: Convert java/nio/file/DirectoryStream/SecureDS.java
 to junit [v7]
In-Reply-To: <DHPoUVWSVZZaRkkqoQx7lDMHYOwzCbwuJWxfWZm8Wfo=.cb6279b8-1474-4bd7-a07e-494bdb082b3a@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
 <Cdb2JyKbHIQGBtdIwl5eU7vzQ9F8jVfEQ84kqsQu4cQ=.94f78d01-4e29-41ae-96ec-2bc2d8309fc9@github.com>
 <DHPoUVWSVZZaRkkqoQx7lDMHYOwzCbwuJWxfWZm8Wfo=.cb6279b8-1474-4bd7-a07e-494bdb082b3a@github.com>
Message-ID: <64TX3zLwW329hgkd_e0YopYG6W93WkawA2IOvGpaeGo=.63dab5d3-7474-4b82-a45a-beb8c4ff61a2@github.com>

On Fri, 6 Feb 2026 18:26:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan 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:
>> 
>>   Abort test instead report fail when SecureDirectoryStream not supported
>
> Aside from my trivial comment about import order, I think this looks good.

Thanks @bplb @AlanBateman the reviews and suggestions

> test/jdk/java/nio/file/DirectoryStream/SecureDS.java line 43:
> 
>> 41: import jdk.test.lib.Platform;
>> 42: import org.junit.jupiter.params.provider.ValueSource;
>> 43: import org.junit.jupiter.params.ParameterizedTest;
> 
> Nit: I think this import should be before the previous one.

Thanks. Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29540#issuecomment-3863331863
PR Review Comment: https://git.openjdk.org/jdk/pull/29540#discussion_r2776703494

From syan at openjdk.org  Mon Feb  9 21:39:44 2026
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Feb 2026 21:39:44 GMT
Subject: Integrated: 8377018: Convert
 java/nio/file/DirectoryStream/SecureDS.java to junit
In-Reply-To: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
References: <ZI_3Eu0nHK7ULL6txLxOSD2Tx1Zld-tZud4FBy4nMTQ=.5cc95b9e-e1f4-4516-b063-4aa0c9ddae12@github.com>
Message-ID: <-O39NPx73xwUuzitTGDeaQyRgkiJCLaTr3nBBmHwp0A=.4a157a88-adc0-4ee0-9f3a-c181a0227798@github.com>

On Tue, 3 Feb 2026 07:01:28 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR convert test/jdk/java/nio/file/DirectoryStream/SecureDS.java from jtreg/main to jtreg/junit.
> 
> Changes include:
> 
> 1. Use `@ParameterizedTest` and `@ValueSource` instead of jtreg id to test user.dir and /tmp seperately.
> 2. Use junit assertEquals/assertTrue instead of user defined assertTrue
> 3. Use assertEquals instead of throw new RuntimeException
> 4. Use junit fail instead of shouldNotGetHere and throw new RuntimeException
> 5. Use assumeTrue instead of jtreg.SkippedException
> 6. Use assertThrows instead of all the try-fail-catch
> 7. Abort test instead report fail when SecureDirectoryStream not supported, discussed in [JDK-8376700](JDK-8376700)

This pull request has now been integrated.

Changeset: 4c322344
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4c322344cd08608ae4d4e9bf99e7333ac8009f26
Stats:     108 lines in 1 file changed: 8 ins; 41 del; 59 mod

8377018: Convert java/nio/file/DirectoryStream/SecureDS.java to junit

Reviewed-by: bpb, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/29540

From jpai at openjdk.org  Tue Feb 10 09:41:28 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 09:41:28 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
Message-ID: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>

Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.

As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.

A new jtreg test has been introduced to verify this change.

-------------

Commit messages:
 - 8377049: (zipfs) ZipException in ZipFileSystemProvider.newFileSystem() is swallowed

Changes: https://git.openjdk.org/jdk/pull/29646/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=29646&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8377049
  Stats: 97 lines in 2 files changed: 86 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/29646.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29646/head:pull/29646

PR: https://git.openjdk.org/jdk/pull/29646

From alanb at openjdk.org  Tue Feb 10 10:36:10 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 10:36:10 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
Message-ID: <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>

On Tue, 10 Feb 2026 09:33:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.
> 
> As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.
> 
> A new jtreg test has been introduced to verify this change.

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:

> 123:             // file. for others, raise a UnsupportedOperationException.
> 124:             String fname = path.getFileName().toString();
> 125:             // JMOD files are expected to have (case sensitive) .jmod extension

I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787147737

From jpai at openjdk.org  Tue Feb 10 10:55:57 2026
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Feb 2026 10:55:57 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
 <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
Message-ID: <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>

On Tue, 10 Feb 2026 10:32:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to improve the exception reported by `jdk.nio.zipfs.ZipFileSystemProvider.newFileSystem(...)` methods when a `ZipException` occurs for invalid ZIP files? This addresses https://bugs.openjdk.org/browse/JDK-8377049.
>> 
>> As noted in that issue the file whose `ZipException` wasn't being propagated was a JMOD file. The change here will now propagate the `ZipException` for JMOD files similar to ZIP and JAR files. The comments in that JBS issue has additional discussion about this change.
>> 
>> A new jtreg test has been introduced to verify this change.
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:
> 
>> 123:             // file. for others, raise a UnsupportedOperationException.
>> 124:             String fname = path.getFileName().toString();
>> 125:             // JMOD files are expected to have (case sensitive) .jmod extension
> 
> I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.

Hello Alan, I came to that conclusion based on what I see in `JmodArchive` https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java#L78 which rejects any file that doesn't have a case sensitive `.jmod` extension.

Would you prefer if we did a case insensitive check in this exception block like we do for ZIP and JAR files?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787239673

From alanb at openjdk.org  Tue Feb 10 10:59:51 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 10:59:51 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>

On Sun, 8 Feb 2026 11:35:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

test/jdk/java/nio/file/FileStore/Basic.java line 35:

> 33: 
> 34: import static org.junit.jupiter.api.Assertions.*;
> 35: import static org.junit.jupiter.api.Assumptions.assumeTrue;

Can you move these down to be with the other imports of junit classes, it seems very strange to put these at the top.

test/jdk/java/nio/file/FileStore/Basic.java line 99:

> 97:     @ParameterizedTest
> 98:     @MethodSource("factory")
> 99:     @DisplayName("Test: Directory should be on FileStore that is writable")

My preference would be to drop the display name and use a test comment. That will reduce the noise from the .jtr files that we use when seeing which tests failed.

test/jdk/java/nio/file/FileStore/Basic.java line 107:

> 105:     @MethodSource("factory")
> 106:     @DisplayName("Test: Two files should have the same FileStore")
> 107:     public void testFileStoreEquality(Path dir) throws IOException {

If you want you can drop "FileStore" from all the test names as it's in the file path already. Also JUnit does not require test methods to be public.

test/jdk/java/nio/file/FileStore/Basic.java line 114:

> 112:         assertTrue(store1.equals(store2));
> 113:         assertTrue(store2.equals(store1));
> 114:         assertTrue(store1.hashCode() == store2.hashCode());

For a true migration then we should move these to assertEquals and assertSame.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787245176
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787249790
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787256576
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787253122

From alanb at openjdk.org  Tue Feb 10 11:02:26 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Feb 2026 11:02:26 GMT
Subject: RFR: 8377049: (zipfs) ZipException in
 ZipFileSystemProvider.newFileSystem() is swallowed
In-Reply-To: <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>
References: <C6FZXA0K-y26r8STKLd0p3IhHVMsRG2Eg9QifDPamt4=.33b07157-895b-4aab-8c51-ab5458c51630@github.com>
 <bQKoQLPPly4kB7Eb2-CeTrNHKE-OIU1im0xpr0mOGrI=.c362f3fe-4457-4b3d-9b06-1c849f9aebc7@github.com>
 <FLfUGoDyKlWcWAi68F64mc2ctjTssf-EKbWuhSwMB2k=.654955b7-695c-4007-940d-fcdcf6f4e2a9@github.com>
Message-ID: <MpqD4Ku9zfQzZk0k4QEvAQ5VVC_EYKtuEsXN7wJ3Sbo=.1f9fbc66-ab54-4805-97ef-a9d4f1e7cd34@github.com>

On Tue, 10 Feb 2026 10:52:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 125:
>> 
>>> 123:             // file. for others, raise a UnsupportedOperationException.
>>> 124:             String fname = path.getFileName().toString();
>>> 125:             // JMOD files are expected to have (case sensitive) .jmod extension
>> 
>> I don't think this is strictly true but unlikely that there are JMOD files with the extension in upper case.
>
> Hello Alan, I came to that conclusion based on what I see in `JmodArchive` https://github.com/openjdk/jdk/blob/master/src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JmodArchive.java#L78 which rejects any file that doesn't have a case sensitive `.jmod` extension.
> 
> Would you prefer if we did a case insensitive check in this exception block like we do for ZIP and JAR files?

TBH, I don't think the zip provider should know anything about JMOD files, it's just unfortunate that javac relies on this to access JMOD files. I need to think about this more as it might be that the right thing is to include a simple file system provider in jdk.compiler for javac to be able to access the contents of a JMOD file as a file system.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29646#discussion_r2787276808

From syan at openjdk.org  Tue Feb 10 12:19:50 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:19:50 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v2]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <Y7sdBvB_AX1_qKYmSI7J2JiwGRYEsh7Zx4VciAaHaKI=.d5ed522a-7391-4180-8373-c1becb59db0b@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Move the junit imports together

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/78c99548..74654818

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=00-01

  Stats: 7 lines in 1 file changed: 4 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Tue Feb 10 12:19:53 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:19:53 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v2]
In-Reply-To: <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
Message-ID: <jk7Q_fp_lQPv51RS4RD822YH_G0Xllj4G2szLtQL4SQ=.2ab34443-0a79-4ab6-a65e-0b23fa5b83f7@github.com>

On Tue, 10 Feb 2026 10:53:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move the junit imports together
>
> test/jdk/java/nio/file/FileStore/Basic.java line 35:
> 
>> 33: 
>> 34: import static org.junit.jupiter.api.Assertions.*;
>> 35: import static org.junit.jupiter.api.Assumptions.assumeTrue;
> 
> Can you move these down to be with the other imports of junit classes, it seems very strange to put these at the top.

Thanks. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787608330

From syan at openjdk.org  Tue Feb 10 12:23:56 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:23:56 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v3]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <KH4MY0ePh_EG7SUvQZZl28Kp0Z_iLnD0RsxAUVKPPI4=.95ac60af-ee0b-400e-b285-1111ddbc788a@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove all the @DisplayName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/74654818..455ca6d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=01-02

  Stats: 25 lines in 1 file changed: 17 ins; 7 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Tue Feb 10 12:48:00 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:48:00 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v4]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <oRtuCSXZvJkn_GtdZtOa2YY-vuoNLHPHpBCEhsS1R_0=.fea14eec-8da3-4642-af24-aec730d87eb6@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Use assertEquals/assertSame instead of assertTrue to compare two objects

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/455ca6d2..63c356bd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=02-03

  Stats: 10 lines in 1 file changed: 0 ins; 2 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Tue Feb 10 12:53:09 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:53:09 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v5]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <w8ujI2wy42cf0uuRXh97tKggxIsXo6U2hCPhYMOZ7bk=.ada8dc1d-9048-45fa-a567-464d5f4822c7@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove public for test method

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/63c356bd..3222f0c9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Tue Feb 10 12:58:13 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:58:13 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v6]
In-Reply-To: <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
Message-ID: <UIoa4eWLi1WMIRFSU3xzL99mRuShKBe79EaevXf-pkc=.a850f9a1-fb15-4160-8b2f-d16bc0bce471@github.com>

On Tue, 10 Feb 2026 10:55:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove the redundant FileStore test method name
>
> test/jdk/java/nio/file/FileStore/Basic.java line 107:
> 
>> 105:     @MethodSource("factory")
>> 106:     @DisplayName("Test: Two files should have the same FileStore")
>> 107:     public void testFileStoreEquality(Path dir) throws IOException {
> 
> If you want you can drop "FileStore" from all the test names as it's in the file path already. Also JUnit does not require test methods to be public.

Thanks for patient reviews. All test methods has been removed the public modifier. And the redundant FileStore test method name has been removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2787804423

From syan at openjdk.org  Tue Feb 10 12:58:11 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 12:58:11 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v6]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <OuuBCzLyNRdxKbiUm8M5FPSXio-U6uUK8AKTG_fGa-4=.00a00f6c-6fd5-4a88-99f9-a5dfa67abddb@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove the redundant FileStore test method name

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/3222f0c9..a75ab86c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=04-05

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Tue Feb 10 13:07:26 2026
From: syan at openjdk.org (SendaoYan)
Date: Tue, 10 Feb 2026 13:07:26 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v7]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with one additional commit since the last revision:

  Remove unuse variable file2/store2

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/a75ab86c..62b7a9e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From syan at openjdk.org  Wed Feb 11 10:08:32 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Feb 2026 10:08:32 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v8]
In-Reply-To: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
Message-ID: <cirf5mo9ca9hc1Ir9CWfUfQendMEiRU7aSESeDsma9M=.1caa735e-c613-4684-8372-33aee64c24df@github.com>

> Hi all,
> 
> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
> 
> Changes include:
> 
> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull

SendaoYan has updated the pull request incrementally with four additional commits since the last revision:

 - Output the store/name/type to stderr, make test result output more friendly.
 - Use toList() instead of collect()
 - Romove unuse variable store2/file2
 - Use assertEquals to check the wondows FileStore

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/29623/files
  - new: https://git.openjdk.org/jdk/pull/29623/files/62b7a9e3..6cd39f23

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=29623&range=06-07

  Stats: 17 lines in 1 file changed: 0 ins; 2 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/29623.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/29623/head:pull/29623

PR: https://git.openjdk.org/jdk/pull/29623

From alanb at openjdk.org  Wed Feb 11 10:08:51 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Feb 2026 10:08:51 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v7]
In-Reply-To: <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>
Message-ID: <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>

On Tue, 10 Feb 2026 13:07:26 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
>> 
>> Changes include:
>> 
>> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
>> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
>> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
>> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unuse variable file2/store2

Looking good, just two remaining comments from me

I think the latest update looks good. Just testing in our CI on all platforms to be sure there isn't anything missed.

test/jdk/java/nio/file/FileStore/Basic.java line 127:

> 125:         FileStore upper = Files.getFileStore(Path.of("C:\\"));
> 126:         FileStore lower = Files.getFileStore(Path.of("c:\\"));
> 127:         assertSame(lower, upper);

Shouldn't this be assertEquals?

test/jdk/java/nio/file/FileStore/Basic.java line 181:

> 179:         List<FileStore> stores = StreamSupport.stream(FileSystems.getDefault()
> 180:                                  .getFileStores().spliterator(), false)
> 181:                                  .collect(Collectors.toList());

Can you use toList() here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/29623#pullrequestreview-3779128871
PR Comment: https://git.openjdk.org/jdk/pull/29623#issuecomment-3882898565
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2788119369
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2788113882

From alanb at openjdk.org  Wed Feb 11 10:08:59 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Feb 2026 10:08:59 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v7]
In-Reply-To: <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>
 <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>
Message-ID: <06o52kJS5fQpj9AOm6WnpM4UG3DYQwVgouAXdAlPQaw=.ffab8771-55f0-4fb1-ac45-d3f44f7df430@github.com>

On Wed, 11 Feb 2026 08:00:04 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the latest update looks good. Just testing in our CI on all platforms to be sure there isn't anything missed.

All good.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/29623#issuecomment-3883154593

From syan at openjdk.org  Wed Feb 11 10:09:13 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Feb 2026 10:09:13 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v8]
In-Reply-To: <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <WJ0h_Am1LvvuKpT0OyFxtjfIriP6Yhk_bWaimdlutvg=.2361b29e-c60e-4190-be32-8132d74455a6@github.com>
Message-ID: <roNFpuqY2kJEdCKcLTMyP8sHKhSBZjAX57rdYNfeuB0=.450bc834-148b-4d89-b364-64fe92d475ba@github.com>

On Tue, 10 Feb 2026 10:54:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Output the store/name/type to stderr, make test result output more friendly.
>>  - Use toList() instead of collect()
>>  - Romove unuse variable store2/file2
>>  - Use assertEquals to check the wondows FileStore
>
> test/jdk/java/nio/file/FileStore/Basic.java line 99:
> 
>> 97:     @ParameterizedTest
>> 98:     @MethodSource("factory")
>> 99:     @DisplayName("Test: Directory should be on FileStore that is writable")
> 
> My preference would be to drop the display name and use a test comment. That will reduce the noise from the .jtr files that we use when seeing which tests failed.

Fixed.

> test/jdk/java/nio/file/FileStore/Basic.java line 114:
> 
>> 112:         assertTrue(store1.equals(store2));
>> 113:         assertTrue(store2.equals(store1));
>> 114:         assertTrue(store1.hashCode() == store2.hashCode());
> 
> For a true migration then we should move these to assertEquals and assertSame.

Thanks. Most of the assertTrue has been replaced as assertEquals. Seems that there is no check suitable for assertSame.

> test/jdk/java/nio/file/FileStore/Basic.java line 183:
> 
>> 181:         assertEquals(stores.size(), uniqueStores.size(), "FileStores should be unique");
>> 182:         for (FileStore store: stores) {
>> 183:             System.out.format("%s (name=%s type=%s)\n", store, store.name(),
> 
> It might be better to change this to print to System.err so that it inlines with the JUnit output, otherwise testEnumerateFileStores STARTED/result will be in the System.err section of the .jtr file and these traces messages will be in the System.out section.

Thanks. This will make test result more friendly with jtreg parameter -va. Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2791314935
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2791503788
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2792254392

From syan at openjdk.org  Wed Feb 11 10:09:16 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Feb 2026 10:09:16 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v7]
In-Reply-To: <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>
 <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>
Message-ID: <BZwSIX5AwePIMZz_mSsccqKcClFassuGqPOvaXBRtcs=.0c28c74c-457b-4055-9c61-fe72246def23@github.com>

On Tue, 10 Feb 2026 13:57:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unuse variable file2/store2
>
> test/jdk/java/nio/file/FileStore/Basic.java line 127:
> 
>> 125:         FileStore upper = Files.getFileStore(Path.of("C:\\"));
>> 126:         FileStore lower = Files.getFileStore(Path.of("c:\\"));
>> 127:         assertSame(lower, upper);
> 
> Shouldn't this be assertEquals?

I think assertSame is more strict check that assertEquals. assertSame means the two objects has the same address in the heap, then these two object must can pass the check of assertEquals; assertEquals means the contents of these two objects are equals.
In this case, does the FileStore object get from "c:\" and "C:\" on Windows system  should always return the same object? I'am not familar to FileStore.
I have not run jtreg tests on windows, so I think we should use assertEquals consevative for now on.

> test/jdk/java/nio/file/FileStore/Basic.java line 181:
> 
>> 179:         List<FileStore> stores = StreamSupport.stream(FileSystems.getDefault()
>> 180:                                  .getFileStores().spliterator(), false)
>> 181:                                  .collect(Collectors.toList());
> 
> Can you use toList() here?

Thanks. The collect() has been replaced as toList().

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2791210749
PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2791498908

From syan at openjdk.org  Wed Feb 11 10:09:18 2026
From: syan at openjdk.org (SendaoYan)
Date: Wed, 11 Feb 2026 10:09:18 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v7]
In-Reply-To: <BZwSIX5AwePIMZz_mSsccqKcClFassuGqPOvaXBRtcs=.0c28c74c-457b-4055-9c61-fe72246def23@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <HfWgmVMNHd4AgYh6uo0QQ1Mjt64JbNp5UdoXyv8_zv0=.975b2ba5-1e7a-4e51-9e93-7c7037a30635@github.com>
 <6LJ1z6QkZWlTRE5dBiyF8QkjryTHkdPcBVRb30Crxp8=.b7a6e487-9cc2-4f97-8347-802d2e33e462@github.com>
 <BZwSIX5AwePIMZz_mSsccqKcClFassuGqPOvaXBRtcs=.0c28c74c-457b-4055-9c61-fe72246def23@github.com>
Message-ID: <S9hyEqrwqyitRAxDJDLusuRQwZMmuyyTGu053hxprHU=.8cc83f50-6ccd-4133-9f26-51a674fbe037@github.com>

On Wed, 11 Feb 2026 03:05:44 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/FileStore/Basic.java line 127:
>> 
>>> 125:         FileStore upper = Files.getFileStore(Path.of("C:\\"));
>>> 126:         FileStore lower = Files.getFileStore(Path.of("c:\\"));
>>> 127:         assertSame(lower, upper);
>> 
>> Shouldn't this be assertEquals?
>
> I think assertSame is more strict check that assertEquals. assertSame means the two objects has the same address in the heap, then these two object must can pass the check of assertEquals; assertEquals means the contents of these two objects are equals.
> In this case, does the FileStore object get from "c:\" and "C:\" on Windows system  should always return the same object? I'am not familar to FileStore.
> I have not run jtreg tests on windows, so I think we should use assertEquals consevative for now on.

Below code snippet run on Windows show that these two FileStore objects are different objects in heap. So we should not use assertSame. Sorry for the mistake.


        FileStore upper = Files.getFileStore(Path.of("C:\"));
        FileStore lower = Files.getFileStore(Path.of("c:\"));
        System.out.println(System.identityHashCode(upper));
        System.out.println(System.identityHashCode(lower));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2791314121

From alanb at openjdk.org  Wed Feb 11 10:09:19 2026
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Feb 2026 10:09:19 GMT
Subject: RFR: 8371979: Convert java/nio/file/FileStore/Basic.java to JUnit
 [v8]
In-Reply-To: <cirf5mo9ca9hc1Ir9CWfUfQendMEiRU7aSESeDsma9M=.1caa735e-c613-4684-8372-33aee64c24df@github.com>
References: <yy8644-LUjY5WZs5cm7XTP40mJhSw5SWDrzZa9EfeoI=.dbeafdf1-0faa-4cd7-aa2f-750953671874@github.com>
 <cirf5mo9ca9hc1Ir9CWfUfQendMEiRU7aSESeDsma9M=.1caa735e-c613-4684-8372-33aee64c24df@github.com>
Message-ID: <HOgQHWaCOX-S1CEOfPY3_OF4N43XYChzCTmZu29Nols=.9a206de7-fa48-4c84-adf2-541b83ffd74c@github.com>

On Wed, 11 Feb 2026 09:34:27 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR convert java/nio/file/FileStore/Basic.java from jtreg/main to jtreg/junit. This PR do not change the original test logic. Change has been verified locally on linux-x64 and linux-aarch64.
>> 
>> Changes include:
>> 
>> 1. convert test to junit, and the test entry method name was replaced as `testBasic() instead of the `main(String args[])`
>> 2. Use assertTrue instead of check `diff > G` and throw RuntimeException, this make code more concise.
>> 3. Use assumeTrue instead of print skipping info if `FileUtils.areMountPointsAccessibleAndUnique()` return false. This make test more elegant.
>> 4. Use junit AssertTrue/assertNotNull instead of jdk.test.lib.Asserts.assertTrue/assertNotNull
>
> SendaoYan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - Output the store/name/type to stderr, make test result output more friendly.
>  - Use toList() instead of collect()
>  - Romove unuse variable store2/file2
>  - Use assertEquals to check the wondows FileStore

test/jdk/java/nio/file/FileStore/Basic.java line 183:

> 181:         assertEquals(stores.size(), uniqueStores.size(), "FileStores should be unique");
> 182:         for (FileStore store: stores) {
> 183:             System.out.format("%s (name=%s type=%s)\n", store, store.name(),

It might be better to change this to print to System.err so that it inlines with the JUnit output, otherwise testEnumerateFileStores STARTED/result will be in the System.err section of the .jtr file and these traces messages will be in the System.out section.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/29623#discussion_r2792025166

From smonteith at openjdk.org  Wed Feb 11 12:47:29 2026
From: smonteith at openjdk.org (Stuart Monteith)
Date: Wed, 11 Feb 2026 12:47:29 GMT
Subject: RFR: 8371260: Improve scaling of downcalls using MemorySegments
 allocated with shared arenas.
In-Reply-To: <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>
References: <PtMqGiSOL-vqJtsEQxESSNZKmkppc-ZWz9LR0Y01Hsw=.7b19a034-fe50-48c7-bd08-5942330059ff@github.com>
 <kRi61jloPuIqbNpENKgKl5GZ-Dzf_yKO7HkbMW3iP1M=.e61813a6-e51d-4ee0-993b-83c1aa1d7ed5@github.com>
Message-ID: <RZhq9CtQJRbR7S2Dkw2CJSUMQpaRh1RYXs29ZMzwFD4=.a25031da-e393-406d-aac2-596d085ae19f@github.com>

On Mon, 9 Feb 2026 12:50:14 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Thanks for looking at this.
> 
> Besides the code comments, there are few points that I'd like to bring up as well:
> 
>     1. I'm not sure I see using a ticket being worth it vs. just calling `getCounter` again in `release0`. The JIT understands that the current thread doesn't change in most situations, so it should be able to common out the load of the hash code.
> 
>     2. This adds significant footprint to SharedSession. Especially on server class machines which can have as much as to 512 logical processors (or more), this would add 8 pages of memory use per session instance, assuming the typical 64 byte cache line size, just for the counters.
> 
>     3. This is already a tricky bit of code in which we've seen several hard to diagnose issues. So, making changes here makes me a bit nervous, and I'm honestly having a hard time judging the cost vs. benefit of this change, considering also that the benchmark is testing the absolute worst case scenario where the acquire/release are being hammered. (and now I _really_ wish I had found the time to look at this earlier).
> 
> 
> Given 2. and 3. taken together, and out of an abundance of caution, I suggest keeping both the old and new implementations as separate MemorySessionImpl sub-classes, and then using a system property to select one or the other in `createShared`. Just in case someone wants to switch back to the single counter implementation, or in case we want to use this to diagnose an issue. (Having a single static property select between the impls should also avoid issues with megamorphic call sites since the total number of loaded impls in a given process should stay the same).

Thank you both for looking at this in such detail, I know it is a lot of work.

re: 1 - My original version had both release0() and release0(int ticket), as in most cases it was unnecessary. I decided to require a ticket to reduce the chance of a bug being introduced when the ticket actually did need to be passed between threads. The IOUtil Releasers are example of where the tickets are necessary. The side effect, of course, was many more changes. I benchmarked with both, and it didn't make a measurable difference.

re: 2 - I was initially experimenting with a SharedSession and a MultiSharedSession, which was switchable in MemorySessionImp with a property. I didn't submit that, thinking that another option would be undesirable. To avoid the overhead, where it is unnecessary, I have been experimenting with a single counter that only expands to multiple counters when there is contention, but does add to the complexity - I'm not there yet. There doesn't have to be a 1:1 ratio between the number of cores and the number of counters - you can get much of the benefit with a 4:1 or even 8:1 ratio, which would reduce the memory overhead somewhat. 

While the microbenchmark does hammer the code, there was a real issue the patch was addressing. We had an issue where someone had to work the scalability issue in  SharedSession by reimplementing their code with JNI.

> Overall, I think that this is a good experiment (and I'm very grateful for it), but I'm a bit skeptical in seeing it introduced in the JDK codebase. This is a very sensitive area, with lots of multi-threaded gotchas (lots of different failure modes to take into account). As I commented originally, I still feel like separating the ref counter from the liveness bit (ignoring everything else) brings even more failure modes to the table.
> 
> After discussing all of this with @JornVernee, we agreed that we should refrain from integrating this work (even if provided merely as an option), and maybe keep the door open to explore other alternatives that might provide some relief, while keeping the code more maintainable in the long run

Thank you too for taking the time to review this. That is all fair. The circumstance where this was necessary might be quite rare as it only applies when Arena.ofShared() arenas don't scale when memory is shared across a number of threads with many calls to quickly executing native functions. Instead I'd imagine we'd recommend using Arena.ofAuto(), or perhaps confined without sharing the memory, or at worst JNI could be used instead. 

This issue was spotted using the async-profiler. With a large number of threads executing with the same SharedSession. It was observed that more time and more time is spent in SharedSession.acquire0() and SharedSession.release0()  as the load on the server increased.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28575#issuecomment-3884203193