From swen at openjdk.org  Tue Jul  1 00:01:21 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 00:01:21 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
Message-ID: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>

> BufferedWriter -> OutputStreamWriter -> StreamEncoder
> 
> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
> 
> LATIN1 -> UTF16 -> UTF8
> 
> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.

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

  Revert "BufferedWriter buffer use StringBuilder"
  
  This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26022/files
  - new: https://git.openjdk.org/jdk/pull/26022/files/da902ca0..fccd9678

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

  Stats: 81 lines in 6 files changed: 31 ins; 32 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/26022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26022/head:pull/26022

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

From duke at openjdk.org  Tue Jul  1 00:01:21 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 00:01:21 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
Message-ID: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>

On Mon, 30 Jun 2025 23:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   BufferedWriter buffer use StringBuilder

What about a benchmark which exercises the actual benefits of buffering?
So many very small writes to a backing OutputStream which is (artificially) slow.
Perhaps have an OutputStream which sleeps 1ms on every call.
The write out more than 8k of data in chunks of less than 8 chars at a time.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021204155

From swen at openjdk.org  Tue Jul  1 00:12:40 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 00:12:40 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
Message-ID: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>

On Mon, 30 Jun 2025 23:57:45 GMT, Brett Okken <duke at openjdk.org> wrote:

> What about a benchmark which exercises the actual benefits of buffering? So many very small writes to a backing OutputStream which is (artificially) slow. Perhaps have an OutputStream which sleeps 1ms on every call. The write out more than 8k of data in chunks of less than 8 chars at a time.

In fact, StreamEncoder has a ByteBuffer that acts as a buffer, so when BufferedBuffer::out is an OutputStreamWirter encoded as UTF8, there is no need for two layers of buffer.


class BufferedWriter {
    Writer out
}

class OutputStreamWriter {
    StreamEncoder se;
}

class StreamEncoder {
    ByteBuffer bb;
}


We often use it like this:

new BufferedWriter(new OutputStreamWriter(out, UTF_8)))

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021227716

From sherman at openjdk.org  Tue Jul  1 00:45:47 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 00:45:47 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

While I understand the motivation behind the PR, it's a bit challenging (as a reviewer) to agree a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. 

It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion?

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021289241

From duke at openjdk.org  Tue Jul  1 02:09:43 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 02:09:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
Message-ID: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>

On Tue, 1 Jul 2025 00:10:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> StreamEncoder has a ByteBuffer that acts as a buffer,

At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter?

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021453158

From swen at openjdk.org  Tue Jul  1 02:16:39 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 02:16:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v5]
In-Reply-To: <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <BMzrwoK47BAqc6yjrZY0QLhxEXXkjk5KEWlYR-GRkrg=.96ca6aba-b94f-43b6-abb8-4bed4bb2e0f2@github.com>
 <2UGoXOQvwftFaOWTuopaoo_r6XaIUp2x5SwelfFsgRw=.574d130b-8d0e-4b0b-9a66-749d2ccb00da@github.com>
 <4F3WghIFVfxGPb1vRYf8Cdx4n35JwYZwOgfsColqCqQ=.4ae6c24f-3a9f-43a7-9af5-03f074c7d0a5@github.com>
 <BYx25B4zYdZLJFjW9aK9Ja2lIFO7dB0P5R_D0LCcte8=.1369de55-cb96-4c89-80ca-20efff5c4ec0@github.com>
Message-ID: <ISQ8YWHEW37dp_fdCDLS89W2f4oGNp-sWQP7mBlgpgI=.11b8656f-16a1-4528-bb2c-7b6bb6f2846b@github.com>

On Tue, 1 Jul 2025 02:07:07 GMT, Brett Okken <duke at openjdk.org> wrote:

> > StreamEncoder has a ByteBuffer that acts as a buffer,
> 
> At a fixed sized of 512 bytes which cannot be affected by size passed into the BufferedWriter?

So I added this method StreamEncoder::growByteBufferIfEmptyNeeded and called it in the BufferedWriter constructor


    private BufferedWriter(Writer out, int initialSize, int maxSize) {
        // ...
        if (out instanceof OutputStreamWriter w && w.se.getCharset() == UTF_8.INSTANCE) {
            w.se.growByteBufferIfEmptyNeeded(initialSize);
            this.impl = new OutputStreamWriterImpl(w);
        }
        // ...
    }

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021479496

From liach at openjdk.org  Tue Jul  1 02:35:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 1 Jul 2025 02:35:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

I think we can split this into two parts:
1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter
2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder

This should make the whole thing more clear.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021520629

From swen at openjdk.org  Tue Jul  1 02:41:37 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 02:41:37 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
Message-ID: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>

On Tue, 1 Jul 2025 00:41:03 GMT, Xueming Shen <sherman at openjdk.org> wrote:

> While I understand the motivation behind the PR, it's a bit challenging, as a reviewer :-) to review a change that is essentially to 'break' the abstraction layer by surfacing a lower-level implementation to the top API solely for performance gains. Maybe it's easier to add an impl note to suggest "it's no longer always a good idea to put a buffered writer on top of an osw", for example.
> 
> It might be better to separate the 'backdoor UTF-8 path' optimization and the 'skip BufferedWriter' change as a first step to start the discussion?

After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021532618

From sherman at openjdk.org  Tue Jul  1 04:00:39 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 04:00:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <6ClkdyctkQbFU6oNWqEWweuKQ9Z2HCjFReka6xpM3R8=.de30d3c6-ce40-418b-be8e-76c930bb1929@github.com>
 <BDp_GKcuOSl2rYKGmWoJ8NaLH1Fg9oF1VsGDin6_2qw=.38af4d8f-ff1b-4070-b0ca-fb37e1d5f583@github.com>
Message-ID: <4sIiDHzczQCMWcgdUU-6uSmPgWm-5Xb66JYx-p0TfW0=.e56c5fcd-b182-402e-81b2-8c5094af331b@github.com>

On Tue, 1 Jul 2025 02:38:52 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> After the introduction of JEP 254 Compact Strings, many java.io-related codes need to be optimized for Compact Strings. If we plan to remove the option COMPACT_STRING = off, we should do these optimizations before that.

now you make me feel guilty :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3021665074

From mdoerr at openjdk.org  Tue Jul  1 06:12:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 06:12:43 GMT
Subject: Integrated: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
Message-ID: <PRSQ74X9VapPKjj34wW_6j_iZiqVNQVrqPKnJ3Qab2M=.813509e8-38cb-4989-a368-4590bc6e6236@github.com>

On Fri, 27 Jun 2025 16:13:14 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
> 
> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924

This pull request has now been integrated.

Changeset: 0572b6ec
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8360887: (fs) Files.getFileAttributeView returns unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)

Co-authored-by: Joachim Kern <jkern at openjdk.org>
Reviewed-by: bpb, mbaesken

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

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

From alanb at openjdk.org  Tue Jul  1 06:28:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:28:47 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <_QMm6eFYxC0A2tcA-_kZPLj9KsBRVTX2rhPF1UvO-Mk=.25eb8a8c-0f0f-4b45-ad22-9429cb44cfe1@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 55:

> 53:     }
> 54: 
> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {

I assume this can be private.

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

> 111:         if (!store1.supportsFileAttributeView(UserDefinedFileAttributeView.class) &&
> 112:             Files.getFileAttributeView(dir, UserDefinedFileAttributeView.class) != null) {
> 113:             throw new RuntimeException("UserDefinedFileAttributeView not supported, getFileAttributeView should return null");

I think it's okay to extend FileStore/Basic.java but to test Files.getFileAttributeView works consistent will require changes to test each of supported views. We shouldn't be testing UserDefinedFileAttributeView in isolation here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176531171
PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176527220

From alanb at openjdk.org  Tue Jul  1 06:32:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:32:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 57:

> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {
> 56:         try {
> 57:             FileStore store = Files.getFileStore(obj);

This needs to be `new AixFileStore(obj)` rather than `Files.getFileStore` to avoid cycles. It might be that no one on AIX replaces the default provider but always have to avoid making use of the API in the API implementation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176536674

From mdoerr at openjdk.org  Tue Jul  1 06:36:55 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 06:36:55 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
Message-ID: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>

Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

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

Commit messages:
 - Backport 0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944

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

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

From alanb at openjdk.org  Tue Jul  1 06:46:45 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 06:46:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <EiGfvTcZ1RQN96bnyBfiP2YtT0BdDd23_EmY1C2HU_4=.4c871b97-d453-4187-b259-f732726ef3b0@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 72:

> 70:         if (type == UserDefinedFileAttributeView.class) {
> 71:             return !supportsUserDefinedFileAttributeView(obj) ? null :
> 72:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options));

I think should this be inverted, meaning use supportsUserDefinedFileAttributeView instead of ! supportsUserDefinedFileAttributeView and it will be clear to read.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2176561100

From mbaesken at openjdk.org  Tue Jul  1 07:25:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 1 Jul 2025 07:25:39 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <Gq2v2qUPcXRK1_sg4KcXRYw8UoUKA-EP0YyskvSaCGY=.d8af36a8-4623-467c-9289-6d623a85c7f4@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26058#pullrequestreview-2973883897

From swen at openjdk.org  Tue Jul  1 09:20:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 1 Jul 2025 09:20:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <8Gw6kEDNuv2UmryKGGqW7QDndJJr29rT6dHKa9pLQLQ=.7d15c0c6-70f2-44e7-a07c-977ec66ed9c7@github.com>
Message-ID: <qDMgvXPFu6XFFsV0CHd3rphymURjIZDLDZ3mNI-Rulo=.54657941-8784-4125-94ec-6642562ce1cb@github.com>

On Tue, 1 Jul 2025 02:33:16 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think we can split this into two parts:
> 
> 1. Update buffering strategy for BufferedWriter when backing writer is an OutputStreamWriter
> 2. Use an alternative StreamDecoder impl if the CharsetDecoder is an ArrayDecoder
> 
> This should make the whole thing more clear.

You are right. The current PR is the fast path optimization of UTF_8 OutputStreamWriter. For UTF_16/UTF_16LE/UTF_16BE, I submitted a draft pr 26034.

And for the buffer of BufferedWriter, if char[] is used, the encodeArrayLoop technique can be used in CharsetEncoder for optimization. If the buffer uses StringBuilder wrap as StringCharBuffer, StringCharBuffer cannot use encodeArrayLoop for optimization, which is the key point affecting performance.

| buffer type | CharBuffer type   | support arrayLoop |
| -- | -- | -- | 
| char[] | HeapCharBuffer | true |
| StringBuilder | StringCharBuffer | false |

Therefore, I recommend continuing to use char[] as buffer in BufferedWriter non-UTF_8 OutputStreamWriter scenarios.


If you are interested, you can take a look at the optimization of these two encodeArrayLoop:

* In UTF_8$Encoder

public final class UTF_8 extends Unicode {
    private static final class Encoder extends CharsetEncoder {
        protected final CoderResult encodeLoop(CharBuffer src,
                                               ByteBuffer dst)
        {
            if (src.hasArray() && dst.hasArray())
                return encodeArrayLoop(src, dst);
            else
                return encodeBufferLoop(src, dst);
        }
        // ...
	}
}


* UnicodeEncoder in PR #26034

public abstract class UnicodeEncoder extends CharsetEncoder {
  protected CoderResult encodeLoop(CharBuffer src, ByteBuffer dst) {
        if (src.hasArray() && dst.hasArray()) {
            return encodeArrayLoop(src, dst);
        }
        return encodeBufferLoop(src, dst);
    }

    private CoderResult encodeArrayLoop(CharBuffer src, ByteBuffer dst) {
        char[] sa = src.array();
        int soff = src.arrayOffset();
        int sp = soff + src.position();
        int sl = soff + src.limit();

        byte[] da = dst.array();
        int doff = dst.arrayOffset();
        int dp = doff + dst.position();
        int dl = doff + dst.limit();

        ....
    }
}

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3022903336

From mdoerr at openjdk.org  Tue Jul  1 10:21:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:21:43 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <NF9OxLM9xE35UNho6MM-0IvDaS34syNIKvb-rDNmGlA=.a3acc029-7f41-4534-9721-b88c7379cadc@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023206935

From alanb at openjdk.org  Tue Jul  1 10:25:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 10:25:39 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <xUtikxYCmGfwiOzQOQiz0Hjm0ihfIysCL_TknlJqwP8=.8714eaa0-d5a4-4fc9-963d-e3ae4afc78b5@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

The change in main line will need follow-up changes so I think hold off on any JDK 25 back ports for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023226128

From mdoerr at openjdk.org  Tue Jul  1 10:26:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:26:45 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
Message-ID: <ThOdbzZeIHhUuOdl57hekjlwQshqxyK8016pJYAwqoQ=.602773c1-865d-4ebf-bb3a-29f81cd25d2a@github.com>

On Mon, 30 Jun 2025 20:57:54 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> We need to fix this wrong behavior on AIX and the test should catch it. Please review!
>> 
>> Returning null is required: https://github.com/openjdk/jdk/blob/c2d76f9844aadf77a0b213a9169a7c5c8c8f1ffb/src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java#L924
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo in comment.

Sorry, I was a bit too fast. We need the fix in jdk25. I'll do a follow-up.

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

PR Comment: https://git.openjdk.org/jdk/pull/26021#issuecomment-3023235613

From mdoerr at openjdk.org  Tue Jul  1 10:30:43 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 10:30:43 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <FICTAd-FjCcYZ7PJEOaw7rb7ZwfZb_sTHdCcnQFaCJM=.f60dcd3a-d796-4674-9017-d677553907ab@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

I'll wait until the follow-up is ready. Thanks, Alan!

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3023257990

From mdoerr at openjdk.org  Tue Jul  1 12:08:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:08:46 GMT
Subject: RFR: 8360887: (fs) Files.getFileAttributeView returns unusable
 FileAttributeView if UserDefinedFileAttributeView unavailable (aix) [v4]
In-Reply-To: <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>
References: <dZ3j4LevMLzDu002gIR3-9EIhR9IyeXOG7OF5HJVEEI=.a9638d50-1d23-4530-8608-72b40472e849@github.com>
 <XcDkOOouhQb8FNVszV8LGCV0A3GjbULFB2yiT7ectAw=.d71cacd9-1dcd-408a-b764-0446670fee54@github.com>
 <SBWT8u9b1gTVxbxRqk-oXoxS4q--RF2QGWnXlBlgTxo=.35bbbee5-f4f1-496c-8971-fda7c161bd2f@github.com>
Message-ID: <xQo_Mf01RrRTkUIGOL-fDClYcKCqNipw_n33v1c6eWU=.bb7faddb-9d93-47fa-aa36-ddb3a5aa7890@github.com>

On Tue, 1 Jul 2025 06:30:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix typo in comment.
>
> src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 57:
> 
>> 55:     static boolean supportsUserDefinedFileAttributeView(Path obj) {
>> 56:         try {
>> 57:             FileStore store = Files.getFileStore(obj);
> 
> This needs to be `new AixFileStore(obj)` rather than `Files.getFileStore` to avoid cycles. It might be that no one on AIX replaces the default provider but always have to avoid making use of the API in the API implementation.

Makes sense, but requires a cast to `UnixPath`.

> test/jdk/java/nio/file/FileStore/Basic.java line 113:
> 
>> 111:         if (!store1.supportsFileAttributeView(UserDefinedFileAttributeView.class) &&
>> 112:             Files.getFileAttributeView(dir, UserDefinedFileAttributeView.class) != null) {
>> 113:             throw new RuntimeException("UserDefinedFileAttributeView not supported, getFileAttributeView should return null");
> 
> I think it's okay to extend FileStore/Basic.java but to test Files.getFileAttributeView works consistently will require changes to test each of supported views. We shouldn't be testing UserDefinedFileAttributeView in isolation here. Can you try this instead:
> 
> 
>     static <V extends FileAttributeView> void testFileAttributes(Path file,
>                                                                  Class<V> viewClass,
>                                                                  String viewName) throws IOException {
>         FileStore store = Files.getFileStore(file);
>         boolean supported = store.supportsFileAttributeView(viewClass);
>         assertTrue(store.supportsFileAttributeView(viewName) == supported);
>         boolean haveView = Files.getFileAttributeView(file, viewClass) != null;
>         assertTrue(haveView == supported);
>     }
> 
> 
> 
>         /**
>          * Test: File and FileStore attributes
>          */
>         assertTrue(store1.supportsFileAttributeView("basic"));
>         testFileAttributes(dir, BasicFileAttributeView.class, "basic");
>         testFileAttributes(dir, PosixFileAttributeView.class, "posix");
>         testFileAttributes(dir, DosFileAttributeView.class, "dos");
>         testFileAttributes(dir, AclFileAttributeView.class, "acl");
>         testFileAttributes(dir, UserDefinedFileAttributeView.class, "user");

Nice! Thanks a lot!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2177427353
PR Review Comment: https://git.openjdk.org/jdk/pull/26021#discussion_r2177426145

From mdoerr at openjdk.org  Tue Jul  1 12:13:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:13:13 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better tests
 (aix)
Message-ID: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>

Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

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

Commit messages:
 - 8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Changes: https://git.openjdk.org/jdk/pull/26066/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26066&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361183
  Stats: 34 lines in 2 files changed: 13 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26066.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26066/head:pull/26066

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

From mdoerr at openjdk.org  Tue Jul  1 12:13:13 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:13:13 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <yhHn_RVhqnNu9V9GBh_PVEiYpFHSnqCkO0ieWOcSHnY=.31577625-0820-48b1-829b-a8672eee9c58@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 56:

> 54: 
> 55:     private static boolean supportsUserDefinedFileAttributeView(Path obj) {
> 56:         if (obj == null || !(obj instanceof UnixPath)) return false;

I think we should have these checks before casting to `UnixPath`. Does this make sense?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2177433884

From mdoerr at openjdk.org  Tue Jul  1 12:15:38 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 12:15:38 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <mDetN318x8MM2YB8eKZxDsV2a4qSrzm7MEK1eYaq9Cw=.c2cd30e2-5439-46e0-8395-f4a5378e5bce@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

@AlanBateman: Thanks for your thorough review of the original change! And sorry that I was too quick. There are currently too many issues...
I have followed your suggestions and added you as contributor.

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3023742559

From alanb at openjdk.org  Tue Jul  1 14:23:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 1 Jul 2025 14:23:41 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 74:

> 72:             return supportsUserDefinedFileAttributeView(obj) ?
> 73:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options))
> 74:                 : null;

Can you try this:

if (type == UserDefinedFileAttributeView.class) { 
    UnixPath file = UnixPath.toUnixPath(obj);
    return supportsUserDefinedFileAttributeView(file) ? ..


That will remove the cast/check from supportsUserDefinedFileAttributeView and also ensure that ProviderMismatchException is thrown if called with a Path from a different provider.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2177737962

From duke at openjdk.org  Tue Jul  1 14:36:39 2025
From: duke at openjdk.org (Brett Okken)
Date: Tue, 1 Jul 2025 14:36:39 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

My initial impression was that the point of this PR was that the BufferedWriter was forcing the conversion to utf-16 and bypassing that would avoid a conversion. However, it seems that it is actually the StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance.

The result (of this PR), then, seems to be that for OutputStreamWriter as a target (and maybe for specific character encodings) BufferedWriter no long buffers, but delegates that responsibility to the OutputStreamWriter (and its StreamEncoder).

Are there any scenarios where wrapping an OutputStreamWriter with a BufferedWriter makes sense? Is it only to control the buffer size? If so, should OutputStreamWriter itself just allow consumers to control the buffer size? (And then just change the doc of OutputStreamWriter to discourage the use of BufferedWriter - and change PrintWriter to not [create this combo](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/io/PrintWriter.java#L167).)

Should the various encoders be optimized to work with a StringCharBuffer? Perhaps only if backed by a String or AbstractStringBuilder? It seems that there could be more target character encodings beyond utf-8 and utf-16 (i.e ascii, iso-8859-1, cp1252, etc.) which could benefit from the source already known whether it is latin 1. 
It feels strange to place the optimizations for specific character encodings directly in StreamEncoder.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3024309269

From sherman at openjdk.org  Tue Jul  1 19:20:40 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Tue, 1 Jul 2025 19:20:40 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
 <hTVnFFy36kIzQ_lQrTR1Xt7GoxpgTdgfj_cL1TC-_aA=.dd2c1bf2-8d64-4d35-833f-c271b2e3337a@github.com>
Message-ID: <iS-XNMV-eUeQo6U19Jp3H6pWXpNty2yeTe0Q7Uh7Iao=.0fa2d70e-7f6f-4bd3-a8d4-71c0f39dd36c@github.com>

On Tue, 1 Jul 2025 14:33:34 GMT, Brett Okken <duke at openjdk.org> wrote:

>  StreamEncoder/CharsetEncoder that is really forcing that - and the conversion to utf-16 is required for optimal encoder performance.

It might be worth exploring the idea of using string-buffer as the buffer to carry the byte[] + coder (delaying the byte[] ? char[] conversion) to the StreamEncoder, and then wrapping it as a StringCharBuffer all the way down to the charset/encoder layer. This could enable potential optimizations at individual charset encoder level.

It's unclear how significant the cost would be for the additional asb + scb wrapping and the access.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3025232418

From rriggs at openjdk.org  Tue Jul  1 19:57:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 1 Jul 2025 19:57:42 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <PYF-6W91JTgpJoUeXxsx54LT2Kk2Rfx_3ygvR4jUDXA=.0b2f430c-7f6a-494e-90eb-0e4e392e9878@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Looks fine

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2976779477

From mdoerr at openjdk.org  Tue Jul  1 20:08:21 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 20:08:21 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

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

  Use UnixPath.toUnixPath().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26066/files
  - new: https://git.openjdk.org/jdk/pull/26066/files/222cea0b..f1659ca3

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

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

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

From mdoerr at openjdk.org  Tue Jul  1 20:08:21 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 1 Jul 2025 20:08:21 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <LnIGmxKc-3HsqHg2ydv_YpiXJzQacnAQzWcVt3b7vDM=.d59019ee-700e-42a1-906e-4caf457bee70@github.com>
Message-ID: <T5bEblZ2Vg7obDj5Zg6ZQ9T-JsVrJHWdomXETWw_fsE=.d0e7ab2d-3823-40e7-9ce3-389a7adb5d66@github.com>

On Tue, 1 Jul 2025 14:20:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use UnixPath.toUnixPath().
>
> src/java.base/aix/classes/sun/nio/fs/AixFileSystemProvider.java line 74:
> 
>> 72:             return supportsUserDefinedFileAttributeView(obj) ?
>> 73:                 (V) new AixUserDefinedFileAttributeView(UnixPath.toUnixPath(obj), Util.followLinks(options))
>> 74:                 : null;
> 
> Can you try this:
> 
> if (type == UserDefinedFileAttributeView.class) { 
>     UnixPath file = UnixPath.toUnixPath(obj);
>     return supportsUserDefinedFileAttributeView(file) ? ..
> 
> 
> That will remove the cast/check from supportsUserDefinedFileAttributeView and also ensure that ProviderMismatchException is thrown if called with a Path from a different provider.

I like this version much better. Changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26066#discussion_r2178430857

From bpb at openjdk.org  Tue Jul  1 22:42:16 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 22:42:16 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
Message-ID: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>

Ignore empty name elements in `WindowsPath.normalize()`.

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

Commit messages:
 - 8360028: (fs) Path.relativize throws StringIndexOutOfBoundsException (win)

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

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

From bpb at openjdk.org  Tue Jul  1 22:46:37 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 22:46:37 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>

On Tue, 1 Jul 2025 22:36:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore empty name elements in `WindowsPath.normalize()`.

Other, alternative changes which also fix this problem include:
- modifying `WindowsPath.initOffsets` not to include empty names;
- modifying `WindowsPath.initOffsets` to ignore consecutive backward slashes (``);
- modifying `WindowsFileSystemProvider.readSymbolicLink` to normalize the path string obtained from the link before creating the `WindowsPath`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3025775020

From bpb at openjdk.org  Tue Jul  1 23:26:42 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 1 Jul 2025 23:26:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v15]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ufWpflFhdrPm4cpC-J2_5GYBXqeZoNnOd7NWZMLCc5U=.e2abe1f8-1f0c-4e54-8fbc-9c493cd99887@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 15 commits:

 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - ... and 5 more: https://git.openjdk.org/jdk/compare/9d518b32...ffa3c469

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=14
  Stats: 1539 lines in 93 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 alanb at openjdk.org  Wed Jul  2 07:33:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Jul 2025 07:33:40 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <8wqwJJexBMPSLAn5kadyuLyfxbH0s7TqYe_e5d6peYk=.c4f2b2ee-2575-4e54-a5b1-d24f49a0c369@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26066#pullrequestreview-2978060252

From alanb at openjdk.org  Wed Jul  2 08:33:43 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 2 Jul 2025 08:33:43 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
Message-ID: <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>

On Tue, 1 Jul 2025 22:44:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> modifying WindowsFileSystemProvider.readSymbolicLink to normalize the path string obtained from the link before creating the WindowsPath.

If the link target can contain redundant slashes then it will need to be normalized so I think we may have do this anyway.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3026951198

From swen at openjdk.org  Wed Jul  2 08:52:43 2025
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 2 Jul 2025 08:52:43 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iAqmPO_vPpWwODDCQ52zwJ_1Y-ICEBFrjLcgxi2t3wI=.1bb06320-dbbb-425d-adc3-4ee5a4ea8f39@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

According to the suggestions of liach and xx, I added the improvement research of BufferedWriter using StringBuilder as buffer + ArrayEncoder to the current PR, which can have a good performance improvement in non-UTF8 scenarios.

The code is this branch: https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4

There are a lot of code changes, which should be another PR.


git remote add wenshao git at github.com:wenshao/jdk.git
git fetch wenshao

## Baseline
# https://github.com/wenshao/jdk/tree/utf8_writer_202506_test
git checkout 2758d6ad7767832db004d28f10cc764f33fa438e
make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030

# Current (PR 26022 & BufferedWriter use StringBuilder as buffer)
# https://github.com/wenshao/jdk/tree/utf8_writer_202506_x4
git checkout 77c5996b6a7b7ea74d03b64c4c8e827a7d76f05a
make test TEST="micro:java.io.BufferedWriterBench" MICRO="OPTIONS=-p charset=ISO_8859_1,ASCII,UTF8,UTF16,GB18030


## Benchmark Numbers on Aliyun ECS c9i (Intel x64 CPU)

Benchmark         (charType)   (charset)  Units Base_Score Current_Score Improvement(%)
writeCharArray         ascii  ISO_8859_1  us/op      3.128         3.027 +3.23%
writeCharArray         ascii       ASCII  us/op      3.126         3.351 -6.88%
writeCharArray         ascii        UTF8  us/op      3.125         3.716 -18.91%
writeCharArray         ascii       UTF16  us/op     32.469        11.404 +64.87%
writeCharArray         ascii     GB18030  us/op      9.642         7.296 +24.34%
writeCharArray  utf8_2_bytes  ISO_8859_1  us/op      3.137         3.016 +3.86%
writeCharArray  utf8_2_bytes       ASCII  us/op     96.779         8.725 +90.99%
writeCharArray  utf8_2_bytes        UTF8  us/op     17.346        12.966 +25.25%
writeCharArray  utf8_2_bytes       UTF16  us/op     32.407        11.267 +65.19%
writeCharArray  utf8_2_bytes     GB18030  us/op     82.994        12.401 +85.14%
writeCharArray  utf8_3_bytes  ISO_8859_1  us/op    100.063         7.486 +92.51%
writeCharArray  utf8_3_bytes       ASCII  us/op     96.061         9.236 +90.40%
writeCharArray  utf8_3_bytes        UTF8  us/op     28.340        13.358 +52.86%
writeCharArray  utf8_3_bytes       UTF16  us/op     32.468        11.785 +63.70%
writeCharArray  utf8_3_bytes     GB18030  us/op     40.864        37.012 +9.66%
writeCharArray         emoji  ISO_8859_1  us/op    190.547        10.149 +94.67%
writeCharArray         emoji       ASCII  us/op    187.803        12.774 +93.17%
writeCharArray         emoji        UTF8  us/op     41.493        23.473 +43.49%
writeCharArray         emoji       UTF16  us/op     48.248        16.227 +66.36%
writeCharArray         emoji     GB18030  us/op    147.360        63.437 +57.01%
writeString            ascii  ISO_8859_1  us/op      3.340         2.770 +17.09%
writeString            ascii       ASCII  us/op      3.340         3.069 +8.11%
writeString            ascii        UTF8  us/op      3.324         2.944 +11.43%
writeString            ascii       UTF16  us/op     32.503        11.214 +65.49%
writeString            ascii     GB18030  us/op      9.023         6.999 +22.43%
writeString     utf8_2_bytes  ISO_8859_1  us/op      3.338         2.827 +15.31%
writeString     utf8_2_bytes       ASCII  us/op     95.964         8.542 +91.10%
writeString     utf8_2_bytes        UTF8  us/op     17.660        10.155 +42.44%
writeString     utf8_2_bytes       UTF16  us/op     32.516        11.173 +65.63%
writeString     utf8_2_bytes     GB18030  us/op     82.369        12.231 +85.14%
writeString     utf8_3_bytes  ISO_8859_1  us/op    100.280         7.363 +92.66%
writeString     utf8_3_bytes       ASCII  us/op     95.279         9.060 +90.48%
writeString     utf8_3_bytes        UTF8  us/op     28.344        18.366 +35.19%
writeString     utf8_3_bytes       UTF16  us/op     32.672        11.284 +65.43%
writeString     utf8_3_bytes     GB18030  us/op     43.798        37.145 +15.16%
writeString            emoji  ISO_8859_1  us/op    189.574         9.904 +94.75%
writeString            emoji       ASCII  us/op    187.021        12.427 +93.35%
writeString            emoji        UTF8  us/op     41.775        25.875 +37.98%
writeString            emoji       UTF16  us/op     48.240        15.696 +67.10%
writeString            emoji     GB18030  us/op    147.097        63.587 +56.78%


## Benchmark Numbers on MacBook M1 Pro (aarch64)

Benchmark                             (charType)   (charset)  Units Base_Score Current_Score Improvement(%)
BufferedWriterBench.writeCharArray         ascii  ISO_8859_1  us/op      2.815         2.133 +24.20%
BufferedWriterBench.writeCharArray         ascii       ASCII  us/op      2.742         2.352 +14.22%
BufferedWriterBench.writeCharArray         ascii        UTF8  us/op      2.704         2.616 +3.25%
BufferedWriterBench.writeCharArray         ascii       UTF16  us/op     31.294         8.489 +72.87%
BufferedWriterBench.writeCharArray         ascii     GB18030  us/op      8.932         3.820 +57.20%
BufferedWriterBench.writeCharArray  utf8_2_bytes  ISO_8859_1  us/op      2.828         2.210 +21.85%
BufferedWriterBench.writeCharArray  utf8_2_bytes       ASCII  us/op    109.255         5.669 +94.80%
BufferedWriterBench.writeCharArray  utf8_2_bytes        UTF8  us/op     22.353        14.039 +37.15%
BufferedWriterBench.writeCharArray  utf8_2_bytes       UTF16  us/op     31.268         8.349 +73.28%
BufferedWriterBench.writeCharArray  utf8_2_bytes     GB18030  us/op     90.835         6.816 +92.50%
BufferedWriterBench.writeCharArray  utf8_3_bytes  ISO_8859_1  us/op    109.734         7.834 +92.88%
BufferedWriterBench.writeCharArray  utf8_3_bytes       ASCII  us/op    106.981         7.906 +92.60%
BufferedWriterBench.writeCharArray  utf8_3_bytes        UTF8  us/op     21.453        16.076 +25.07%
BufferedWriterBench.writeCharArray  utf8_3_bytes       UTF16  us/op     31.294         6.945 +77.75%
BufferedWriterBench.writeCharArray  utf8_3_bytes     GB18030  us/op     49.007        27.891 +43.02%
BufferedWriterBench.writeCharArray         emoji  ISO_8859_1  us/op    223.538        11.189 +94.54%
BufferedWriterBench.writeCharArray         emoji       ASCII  us/op    264.875        11.384 +95.69%
BufferedWriterBench.writeCharArray         emoji        UTF8  us/op     35.704        21.672 +39.29%
BufferedWriterBench.writeCharArray         emoji       UTF16  us/op     45.979        11.255 +75.51%
BufferedWriterBench.writeCharArray         emoji     GB18030  us/op    148.829        57.625 +61.33%
BufferedWriterBench.writeString            ascii  ISO_8859_1  us/op      2.898         2.159 +25.49%
BufferedWriterBench.writeString            ascii       ASCII  us/op      2.876         2.591 +9.91%
BufferedWriterBench.writeString            ascii        UTF8  us/op      2.894         2.466 +14.79%
BufferedWriterBench.writeString            ascii       UTF16  us/op     31.236         8.759 +71.82%
BufferedWriterBench.writeString            ascii     GB18030  us/op      9.010         3.899 +56.70%
BufferedWriterBench.writeString     utf8_2_bytes  ISO_8859_1  us/op      2.894         2.178 +24.71%
BufferedWriterBench.writeString     utf8_2_bytes       ASCII  us/op    108.426         5.611 +94.82%
BufferedWriterBench.writeString     utf8_2_bytes        UTF8  us/op     22.206        12.225 +44.93%
BufferedWriterBench.writeString     utf8_2_bytes       UTF16  us/op     31.305         8.773 +71.98%
BufferedWriterBench.writeString     utf8_2_bytes     GB18030  us/op     90.820         6.907 +92.40%
BufferedWriterBench.writeString     utf8_3_bytes  ISO_8859_1  us/op    108.983         7.931 +92.66%
BufferedWriterBench.writeString     utf8_3_bytes       ASCII  us/op    107.064         7.836 +92.66%
BufferedWriterBench.writeString     utf8_3_bytes        UTF8  us/op     21.664        13.102 +39.47%
BufferedWriterBench.writeString     utf8_3_bytes       UTF16  us/op     31.546         6.930 +78.00%
BufferedWriterBench.writeString     utf8_3_bytes     GB18030  us/op     52.688        27.698 +47.17%
BufferedWriterBench.writeString            emoji  ISO_8859_1  us/op    221.930        11.160 +94.95%
BufferedWriterBench.writeString            emoji       ASCII  us/op    236.791        11.116 +95.30%
BufferedWriterBench.writeString            emoji        UTF8  us/op     35.025        23.210 +33.73%
BufferedWriterBench.writeString            emoji       UTF16  us/op     45.988        11.334 +75.32%
BufferedWriterBench.writeString            emoji     GB18030  us/op    148.202        57.472 +61.23%

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3027011273

From mdoerr at openjdk.org  Wed Jul  2 09:05:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 09:05:44 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <9su5B0CoLULPzH96nt4qCVf0KjzUxyzKnjgp7b_iD2I=.b0e220b3-447d-4daa-8947-97e49802dcae@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Thanks for the review and your guidance!

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3027052356

From jkern at openjdk.org  Wed Jul  2 09:23:39 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 2 Jul 2025 09:23:39 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <s290yyYkoGqC-HWhhIj8S14w6C38RtdejBTJrH7axFA=.4e715e5a-ace2-47f2-b9a1-9e68381a9b8f@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

LGTM

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

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/26066#pullrequestreview-2978409095

From liach at openjdk.org  Wed Jul  2 14:32:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 14:32:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <8eih4k_a1QllWM_vcg81TX0F6_bp8wYJmEP77VoCqT0=.acaceaa8-9203-423b-b6ea-67dbcc61a6a7@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

This latest prototype looks great! It means that we can get rid of the old `BufferedImpl` by using `WriterImpl` as the new code, and remove `StreamEncoder.UTF8Impl`.

I think this prototype can be split this way:
1. Update ArrayEncoder to pass `dp`, open up StringBuilder in JLA, and make BufferedWriter + StreamEncoder use ArrayEncoder. We can use a benchmark writing encodings like CESU for a first step proof of concept.
2. Make UTF8/ISO88591 array encoders. This will open up a few String UTF8 encoding methods in JLA.
3. More array encoders. For example, GB18030 gets a new array encoder in your patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028104142

From rriggs at openjdk.org  Wed Jul  2 14:54:42 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 2 Jul 2025 14:54:42 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <JuEjPqVLztex6JfoWlroOsG5-rqO1Q1kb0NEORsFanQ=.d7e62b4b-ad51-4537-afa3-d4a7d1156a40@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

No more of StringBuilder should be exposed via JLA, it creates new maintenance overhead and risks.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028178422

From liach at openjdk.org  Wed Jul  2 15:03:41 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 15:03:41 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <iiYPhhUbTroTfy-WVFFn0cA_Bi4mSgz6NRxZ0X11IEM=.b597e2be-dfd8-4c53-86f9-7b7828c79338@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

It is not about exposing the implementation details of StringBuilder: it is just exporting a method for StringBuilder to encode itself with an ArrayEncoder (which has LATIN1/UTF16 entrypoints) to general JDK audiences.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3028212631

From bpb at openjdk.org  Wed Jul  2 15:10:39 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 15:10:39 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <bFaXRldUPR06_397rhEic3SPwqTPsQGNcF9c62c7wf4=.5de2628f-d909-4009-a183-54993d38cab1@github.com>
 <VUQQQ8I-3ajzHwxia4QbVqHxDikKdCHHzWn2dg_kzkg=.18ae9808-b367-4f11-bc97-80fd7fb2a18b@github.com>
Message-ID: <ChbejE0YBGNnk7y584YTJ-YxTAXTj2OOjN12BhtMDhA=.93f63e87-b45c-4094-b982-2f2c7674ff64@github.com>

On Wed, 2 Jul 2025 08:30:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > modifying WindowsFileSystemProvider.readSymbolicLink to normalize the path string obtained from the link before creating the WindowsPath.
> 
> If the link target can contain redundant slashes then it will need to be normalized so I think we may have do this anyway.

The link target can contain redundant slashes on both Unix and Windows, but the problem does not manifest on Unix. In both cases, it looks like `readSymbolicLink` just uses whatever is in the link target, unfiltered.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3028235362

From mdoerr at openjdk.org  Wed Jul  2 15:34:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:34:51 GMT
Subject: RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and better
 tests (aix) [v2]
In-Reply-To: <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
 <9wKWdJfOfLz7p4tW1atvCjutc_Mnc4DhTify-eTTbjc=.897e8759-6a11-40ea-920a-7a61e91e8eca@github.com>
Message-ID: <dpeNOSt341Rhh16guZiATVbx2xNA4prIG83XxQ1t0Hk=.0d7f007b-5376-4e96-b478-7c3832bf580d@github.com>

On Tue, 1 Jul 2025 20:08:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.
>
> Martin Doerr has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use UnixPath.toUnixPath().

Thanks! I've verified that the test still catches the bug when I remove the fix. It's a bit more cumbersome to read, but ok:

java.lang.RuntimeException: Assertion failed
        at Basic.assertTrue(Basic.java:57)
        at Basic.testFileAttributes(Basic.java:77)
        at Basic.doTests(Basic.java:114)
        at Basic.main(Basic.java:49)

The fix still works and tier1-4 have passed. Let's ship it!

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

PR Comment: https://git.openjdk.org/jdk/pull/26066#issuecomment-3028312727

From mdoerr at openjdk.org  Wed Jul  2 15:34:51 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:34:51 GMT
Subject: Integrated: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
References: <hbE0XEBIrDvdqXT14NlxDFhvP9_uWEyuiaoNm17ipbU=.fbc8309e-aff7-4d83-ad0d-c27735d38f73@github.com>
Message-ID: <hiUerUj5F7u0liohLbQwgeBTcSLMd23Ayo3J-bLJjok=.a557ef6b-364b-4aba-98de-cff678720ace@github.com>

On Tue, 1 Jul 2025 12:07:13 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Follow-up for https://github.com/openjdk/jdk/pull/26021. See latest comments there.

This pull request has now been integrated.

Changeset: c460f842
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c460f842bf768995b271cd6362940877a4a79665
Stats:     35 lines in 2 files changed: 14 ins; 10 del; 11 mod

8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: alanb, jkern

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

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

From mdoerr at openjdk.org  Wed Jul  2 15:36:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:36:47 GMT
Subject: [jdk25] RFR: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <jxDsxAlAGbRpbRUYVoERlQweKQQODosP5G4_RtESMws=.0a40229a-9685-49f0-9a6d-ab399eacf488@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

Follow-up is integrated. I'll do the backport and test it on top of this after

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

PR Comment: https://git.openjdk.org/jdk/pull/26058#issuecomment-3028322429

From mdoerr at openjdk.org  Wed Jul  2 15:36:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:36:47 GMT
Subject: [jdk25] Integrated: 8360887: (fs) Files.getFileAttributeView returns
 unusable FileAttributeView if UserDefinedFileAttributeView
 unavailable (aix)
In-Reply-To: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
References: <nJAH_kmSohlnULHsxdXhpTewzds3WSiHSUMuMKeQCtg=.749db7b5-2d8e-4d0a-b5e7-655066b37773@github.com>
Message-ID: <u2A1I_rE8kxZWj62ngR8LQr9_H8qYyMQkC84CLjbDTA=.60015640-6bc4-49f2-8454-76683fd6e4fa@github.com>

On Tue, 1 Jul 2025 06:31:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8360887](https://bugs.openjdk.org/browse/JDK-8360887).

This pull request has now been integrated.

Changeset: a98a5e54
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a98a5e54fcb7916ce922a6997c452d2264bc4479
Stats:     22 lines in 2 files changed: 15 ins; 0 del; 7 mod

8360887: (fs) Files.getFileAttributeView returns unusable FileAttributeView if UserDefinedFileAttributeView unavailable (aix)

Reviewed-by: mbaesken
Backport-of: 0572b6ece7a77d13d23ac0c6d72d4fe5d5f0d944

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

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

From mdoerr at openjdk.org  Wed Jul  2 15:43:16 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 2 Jul 2025 15:43:16 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
Message-ID: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>

Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

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

Commit messages:
 - Backport c460f842bf768995b271cd6362940877a4a79665

Changes: https://git.openjdk.org/jdk/pull/26097/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361183
  Stats: 35 lines in 2 files changed: 14 ins; 10 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/26097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26097/head:pull/26097

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

From brian.burkhalter at oracle.com  Wed Jul  2 16:26:02 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 16:26:02 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <SJ2PR10MB7669E8BCB6179EFFB11DC0C6A240A@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <SJ2PR10MB7669E8BCB6179EFFB11DC0C6A240A@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <4CE894FB-AAA1-41D3-8388-04CDB68A9D94@oracle.com>

An issue will need to be filed.

On Jul 2, 2025, at 8:48?AM, Chen Liang <chen.l.liang at oracle.com> wrote:

I think Brett is right. The spec of CharBuffer says:

The methods defined by {@code CharSequence} operate relative to the current
position of the buffer when they are invoked.

Yet getChars is an absolute bulk get method.

Since JDK25 is still in RDP, we still have a chance to fix this up.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/87975d15/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Jul  2 18:55:48 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 18:55:48 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
Message-ID: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>


On Jul 2, 2025, at 11:19?AM, Alan Bateman <alan.bateman at oracle.com> wrote:

On 02/07/2025 16:58, Brett Okken wrote:

:

This makes it very difficult to pass a CharBuffer (where the position
is not 0) to an api taking a CharSequence - because if that api makes
a switch to start using getChars (rather than charAt), it will break.



Thanks for bringing this up. It does need attention. I just chatted with Brian Burkhalter so he's going to look through the spec + implementation changes to address this. If there is any risk or uncertainty then it mean pulling this out.

It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:

https://bugs.openjdk.org/browse/JDK-8361299

The fix is straightforward but will break a test and require a CSR.

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/837d3c8b/attachment.htm>

From brett.okken.os at gmail.com  Wed Jul  2 20:05:43 2025
From: brett.okken.os at gmail.com (Brett Okken)
Date: Wed, 2 Jul 2025 15:05:43 -0500
Subject: StringCharBuffer and bulk get
In-Reply-To: <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
Message-ID: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>

> It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:
>
> https://bugs.openjdk.org/browse/JDK-8361299
>
> The fix is straightforward but will break a test and require a CSR.


Looks like the testNG GetChars has

cb.getChars(cb.position(), cb.limit(), dst, 0);

but that should have been

cb.getChars(0, cb.remaining(), dst, 0);

or

cb.getChars(0, cb.length(), dst, 0);

- Brett

From brian.burkhalter at oracle.com  Wed Jul  2 20:09:36 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 20:09:36 +0000
Subject: StringCharBuffer and bulk get
In-Reply-To: <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
References: <CANBJVOFRV0drYo0DcumwZYGavzNLquhjKijmoXjzNpc4k89Yrg@mail.gmail.com>
 <SJ2PR10MB7669FEA3948E934C7EB92B7AA241A@SJ2PR10MB7669.namprd10.prod.outlook.com>
 <CANBJVOF=Vr3qOosxsYHc+8jfz5uxiB9tYqVheWDyHV5pdea1TQ@mail.gmail.com>
 <08950E51-883A-47E2-B013-F6F4E9B1499B@oracle.com>
 <CANBJVOGVYfJwUxFfqx_-UrvhDCpLenD=Wi_rRMXBHpZ7F=jTTQ@mail.gmail.com>
 <c0c3276d-4eae-4509-afbc-45f4347365d1@oracle.com>
 <892102A7-D6F7-43BE-9753-F4B70091DE76@oracle.com>
 <CANBJVOEshmLcYEhxtxP-2uWCyrksJeMzNepTH96f8S2uoMC7PA@mail.gmail.com>
Message-ID: <07D9B721-4BEB-4070-BA6D-B8A154D15B8F@oracle.com>



> On Jul 2, 2025, at 1:05?PM, Brett Okken <brett.okken.os at gmail.com> wrote:
> 
>> It looks like only CharBuffer.getChars is broken so the rest of the change can stay. I filed this issue to track it:
>> 
>> https://bugs.openjdk.org/browse/JDK-8361299 
>> 
>> The fix is straightforward but will break a test and require a CSR.
> 
> 
> Looks like the testNG GetChars has
> 
> cb.getChars(cb.position(), cb.limit(), dst, 0);
> 
> but that should have been
> 
> cb.getChars(0, cb.remaining(), dst, 0);

It?s this one ^.

Thanks,

Brian

> or
> 
> cb.getChars(0, cb.length(), dst, 0);
> 
> - Brett


From msheppar at openjdk.org  Wed Jul  2 20:17:38 2025
From: msheppar at openjdk.org (Mark Sheppard)
Date: Wed, 2 Jul 2025 20:17:38 GMT
Subject: RFR: 8291652: (ch) java/nio/channels/SocketChannel/VectorIO.java
 failed with "Exception: Server 15: Timed out"
In-Reply-To: <IXJVibtn50UwnCNNfv10Y3fq7EJ_Ax9cEtx_aIrRbbw=.05ab344a-aded-4ca3-bbbd-ab3b6924fee3@github.com>
References: <IXJVibtn50UwnCNNfv10Y3fq7EJ_Ax9cEtx_aIrRbbw=.05ab344a-aded-4ca3-bbbd-ab3b6924fee3@github.com>
Message-ID: <oiFTGcK3n9tjOqkwbTcFx_a9FSC-5W7_G0sjbpQNkCg=.70436937-a2ce-4e8c-b288-ebbbd73178a6@github.com>

On Mon, 30 Jun 2025 15:58:16 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address an intermittent test failure in `java/nio/channels/SocketChannel/VectorIO.java`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8291652, this test has been failing intermittently in our CI. Some years back the test was improved to include additional debug logs to identify the root cause https://bugs.openjdk.org/browse/JDK-8180085. In a recent failure, these test logs indicate that the `Server` thread hadn't yet `accept()`ed a Socket connection, when the client side of the test threw an exception because it had waited for 8 seconds for the server side of the test to complete.
> 
> The change in this PR updates the test to wait for the `Server` thread to reach a point where it is ready to `accept()` a Socket connection. Only after it reaches this state, the client side of the testing will be initiated. Furthermore, the artificial 8 second wait has been removed from this test and it now waits as long as it takes for the testing to complete. If the test waits far too long then the jtreg infrastructure will timeout the test and at the same time capture the necessary artifacts to help debug unexpected time outs.
> 
> While at it, the test has also been updated to use `InetAddress.getLoopbackAddress()` instead of localhost. This should prevent any unexpected address mappings for localhost from playing a role in this test.
> 
> With these changes, I've run the test more than 1000 times in our CI and it hasn't failed.

A couple of observations to consider.

The setLength is a static member variable of the test effectively a global variable, but it has non synchronised access from multiple threads.
Something to consider for amendment ? volatile or synchronized methods for access.

The use of the CountDownLatch is as about the best we can do. It should mitigate against the possibilities of observed race conditions, but won?t absolutely guarantee this.


Consider the following, slightly convoluted scenario:

The Server starts and executes as far as the countDown on the connAcceptLatch, at which point the server thread gets bumped by the OS and is placed in RTR queue waiting its next scheduled time slice.
The main thread execute as far at the sv.awaitFinish (executing bufferTest method), BUT it has closed the connection before the Server has executed accept or read the data from the socket.
This provides a possibility that data will disappear from the socket ? so there is the possibility that a bit of a race condition will still exist.

Thus, it might be more prudent to close the socket on the client or initiator side (i.e. in the main test thread),  after the Server has finished. As such after the sv.awaitFinish call.

In this case the Server will have closed its end of the socket connection also, at that point in time.

To accommodate this logic, pass the Server reference to the bufferTest method  to invoke the sv.awaitFinish,
or arrange for the  bufferTest method to return the  SocketChannel reference
and invoke the close of the SocketChannel after sv.awaitFinish call in the main method.

Another alternative for this is a refactor extract method at line 92

SocketChannel openConnection(in port)  throws  Exception {
        // Get a connection to the server
         InetAddress loopback = InetAddress.getLoopbackAddress();
         InetSocketAddress isa = new InetSocketAddress(loopback, port);
         SocketChannel sc = SocketChannel.open();
         sc.connect(isa);
         sc.configureBlocking(generator.nextBoolean());
         return sc
}
 Call openConnection before bufferTest and pass the SocketChannel reference to bufferTest with sc.close() call removed

Then after awaitFinish call a sc.close in the main

In any case, back to the main point, that is to close the client SocketChannel after the sv.awaitFinish call.

The method waitToStartTest is on the Server class, maybe refactor rename waitServerStart. The waitToStartTest is a private method on Server but is really part of the public interface to the Server (the fact Server is a static inner class gives access to the private waitServerStart)

Line 174 the invocation connAcceptLatch.countDown which sets the test in motion

could, for the sake of symmetry, be encapsulated in a method

void signalServerStarted() {
    connAcceptLatch.countDown
}

Another aspect of the test that caught the eye is the fact that the ServerSocketChannel bind is invoked with just the SocketAddress and doesn?t specify any backlog. IIRC correctly this results in a backlog of 0 being used.

Since back in the day, It has been best practice not to specify a backlog of 0, especially for portability, as it is backlog 0 semantics are ill defined (or in most cases not defined at all) on most OS platforms.
So, maybe add a backlog of 5 in homage to the original in BSD 4.2

A slight digression from this PR, and a general comment on the ServerSocketChannel::bind(SocketAddress local)

 I think it would be better if the ServerSocketChannel  implementation used  a NON zero default backlog value out of the box, e.g. 5 rather than the backlog of 0. This could, also, be overridden with a  System Property java.nio.DefaultSocketBacklog for use when the single arg ServerSocketChannel::bind method call is used. This would then give common uniform semantics across all OS platforms. Rather then the nebulous semantics for backlog value of zero.

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

PR Comment: https://git.openjdk.org/jdk/pull/26049#issuecomment-3029196920

From bpb at openjdk.org  Wed Jul  2 20:30:03 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 20:30:03 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates
 pre-existing specification
Message-ID: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>

Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

Commit messages:
 - 8361299: (bf) CharBuffer.getChars(int,int,char[],int) violates pre-existing specification

Changes: https://git.openjdk.org/jdk/pull/26104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8361299
  Stats: 24 lines in 2 files changed: 9 ins; 3 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/26104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26104/head:pull/26104

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

From bpb at openjdk.org  Wed Jul  2 21:12:25 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 21:12:25 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
Message-ID: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>

> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

  8361299: Fix a type; add a sentence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26104/files
  - new: https://git.openjdk.org/jdk/pull/26104/files/5bbc34d4..e9abd20f

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

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

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

From duke at openjdk.org  Wed Jul  2 21:49:42 2025
From: duke at openjdk.org (Brett Okken)
Date: Wed, 2 Jul 2025 21:49:42 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

Marked as reviewed by bokken at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2980730140

From bpb at openjdk.org  Wed Jul  2 22:36:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 22:36:38 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <nr3D7AJPZnBy8G6lyp7STIzO0QzvpAnljjCVQXg4g5w=.14cb384c-39f9-45de-a0d3-27887e0d2e2b@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

`jdk_core` tests passed on Linux in the CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/26104#issuecomment-3029517213

From brian.burkhalter at oracle.com  Wed Jul  2 22:53:00 2025
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 2 Jul 2025 22:53:00 +0000
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
 <nXCi71a8R5VoRdv9DSQ-H9pdKsdofa69jXeRl98nhT4=.5adb3194-b868-4d14-87df-4153b19a585b@github.com>
Message-ID: <9A313091-2619-441E-81E4-E7ECF07CBC16@oracle.com>



On Jul 2, 2025, at 2:49?PM, Brett Okken <duke at openjdk.org> wrote:

Marked as reviewed by bokken at github.com<mailto:bokken at github.com> (no known OpenJDK username).

Thanks for the review.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20250702/fb756742/attachment-0001.htm>

From liach at openjdk.org  Wed Jul  2 23:03:40 2025
From: liach at openjdk.org (Chen Liang)
Date: Wed, 2 Jul 2025 23:03:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v2]
In-Reply-To: <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <d4ISFqbPErbkAUfgzyNawywWb2c_in6Vp6jWCVeCp8g=.a601c7b0-b7eb-4858-ba26-31635ce3e314@github.com>
Message-ID: <vw_aTubPJDuU0akEAjbMhpmLME-alo2NiMQgqOlcMDM=.5048fc8d-f7ac-4436-85e3-4ae99d6069bc@github.com>

On Wed, 2 Jul 2025 21:12:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Fix a type; add a sentence

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2980868707

From bpb at openjdk.org  Wed Jul  2 23:39:17 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 23:39:17 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/ea30eaf6..86912f3e

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

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

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

From bpb at openjdk.org  Wed Jul  2 23:42:38 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 2 Jul 2025 23:42:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
Message-ID: <6wfiMN8L6H9yzXzuG0__KLgZjoGqaqRjXFFz0UIvx4c=.0dfbe9a2-9a32-454d-84d9-af869f461b89@github.com>

On Wed, 2 Jul 2025 23:39:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

Commit 86912f3 normalizes the link target path string before returning from `WindowsLinkSupport.readLinkImpl`. This change alone without the prior commit ea30eaf would resolve the issue at hand.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3029677297

From bpb at openjdk.org  Thu Jul  3 00:33:58 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 00:33:58 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
Message-ID: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>

> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.

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

  8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26104/files
  - new: https://git.openjdk.org/jdk/pull/26104/files/e9abd20f..a98e8dd4

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

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

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

From duke at openjdk.org  Thu Jul  3 03:20:47 2025
From: duke at openjdk.org (duke)
Date: Thu, 3 Jul 2025 03:20:47 GMT
Subject: Withdrawn: 8353795: Add Writer.of(StringBuilder)
In-Reply-To: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
References: <2xEfp_WiAa-QW5Yao7JoOS3zSOtPKvBq4qV5rk8obWs=.2b1cc84d-2ff4-4d0c-bb0f-bdb276dc109a@github.com>
Message-ID: <oy3WZBhOMCmlmi4lOK5S1u5cNcc5XVzZ4JGzXj6Hopw=.5cf6ac0f-5779-4805-bb48-466c948b1ce5@github.com>

On Sat, 5 Apr 2025 17:36:29 GMT, Markus KARG <duke at openjdk.org> wrote:

> This Pull Requests proposes an implementation for [JDK-8353795](https://bugs.openjdk.org/browse/JDK-8353795): Adding the new method `public static Writer Writer.of(StringBuilder)`, providing a non-synchronized Writer implementation optimized for writing into `StringBuilder`.
> 
> A basic test is provided to proof that the new `Writer` behaves as expected. For comparison, the same test is also run against `StringWriter`.

This pull request has been closed without being integrated.

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

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

From mbaesken at openjdk.org  Thu Jul  3 07:14:42 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 3 Jul 2025 07:14:42 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <Cy9_oVFaF3Wxk1SEy3qmk98S0Mp8XWJ_oWYiaqQqAvQ=.aa8580be-5d89-490d-a2f7-7a00d2331464@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26097#pullrequestreview-2982005536

From jpai at openjdk.org  Thu Jul  3 07:17:44 2025
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 3 Jul 2025 07:17:44 GMT
Subject: RFR: 8361018: Re-examine buffering and encoding conversion in
 BufferedWriter [v6]
In-Reply-To: <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
References: <tG3KsNaA8iDVdZRT-MGKvy8uViCna0ZUJ939oJsilj0=.a12f0cc9-4e47-4fb8-92d4-291c8f211790@github.com>
 <TdnuVxqRVlUzZpF7RYlOhMbsiCqssJiCgKNACfVqaJU=.190b4b40-3bad-44cd-abc8-9d436b2d3a47@github.com>
Message-ID: <6o5VBnWWZEpIwPsRrXFWwRO6S7hwnfPQVMhrnD97FkM=.f9e3d344-2757-48fd-957c-d92e5e83e8e8@github.com>

On Tue, 1 Jul 2025 00:01:21 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> BufferedWriter -> OutputStreamWriter -> StreamEncoder
>> 
>> In this call chain, BufferedWriter has a char[] buffer, and StreamEncoder has a ByteBuffer. There are two layers of cache here, or the BufferedWriter layer can be removed. And when charset is UTF8, if the content of write(String) is LATIN1, a conversion from LATIN1 to UTF16 and then to LATIN1 will occur here.
>> 
>> LATIN1 -> UTF16 -> UTF8
>> 
>> We can improve BufferedWriter. When the parameter Writer instanceof OutputStreamWriter is passed in, remove the cache and call it directly. In addition, improve write(String) in StreamEncoder to avoid unnecessary encoding conversion.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "BufferedWriter buffer use StringBuilder"
>   
>   This reverts commit da902ca0b0bd6acc003deb8ad1ca0d6485a29a27.

I agree with Roger - introducing new methods on JavaLangAccess to access the methods on String/StringBuilder and related core APIs is not the way to engineer the implementation of these APIs.

I believe the whole exercise in this PR is premature, and it's not the first time either. The contributor opened a mail in the core-libs-dev mailing list, did not wait to hear from the people knowledegable in this area, went ahead and created a JBS issue, then created a PR and linked the PR to that issue which generated an official RFR inviting official reviews, when the entire idea is half baked. In all of this, the PR has zero regression tests added/referenced with the changes. In the mailing list discussion, the contributor was asked if they had looked into the tests to ensure whether there is enough coverage for these changes and what kind of testing might have been done https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148231.html. The response from the contributor is this https://mail.openjdk.org/pipermail/core-libs-dev/2025-June/148236.html which says that a new micro benchmark shows some percentage. I haven't seen any indication in the reply, stating what kind of tes
 ting has been done or what tests have been analyzed and why no new tests have been added. This isn't the first PR of such nature either, so I am not leaning towards giving the benefit of doubt that maybe the contributor misunderstood the question, I believe it's way past that point now.

Changes like these require additional tests or a detailed analysis and explanation about which tests cover these changes and why new tests cannot be introduced. I believe pointing to new manually run microbenchmarks and claiming these are performance driven changes isn't appropriate.

Some reviewers try and stay away from PRs like these for valid reasons. Some reviewers do allow some benefit of doubt to the contributors who are new (the current contributor isn't) and help/guide them in such PRs, and that's a good thing. But when PRs are linked against JBS issue and have generated a RFR, it becomes extremely hard to stay away from reviewing those when the proposed changes are going in a direction that isn't maintainable. Dragging in the JBS infrastructure and the official review process in these experimental changes wastes a lot of time, energy and patience.

My suggestion is to put this PR into draft mode, edit the subject of the PR to remove the reference to the JBS issue so that it hopefully doesn't generate additional RFR mails and then go back to the original email discussion in core-libs-dev and seek inputs on how or whether these changes should be done. It's OK if that process takes a (very) long time, that's intentional for changes like these. It's also OK if the contributor doesn't have the time or doesn't wish to follow the slow nature of these discussions and then implementing those changes in a way which keeps it maintainable and adds and exercises the relevant tests. They can ask people familiar with this area whether the proposed idea merits creating a JBS issue and only then create one so that anyone else who is willing to follow these processes can pursue it further.

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

PR Comment: https://git.openjdk.org/jdk/pull/26022#issuecomment-3031150436

From alanb at openjdk.org  Thu Jul  3 07:33:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 07:33:47 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
Message-ID: <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>

On Wed, 2 Jul 2025 23:39:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Returned normalized string from WindowsLinkSupport.readLinkImpl

src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 361:

> 359: 
> 360:             // return normalized path string
> 361:             return WindowsPathParser.parse(target).path();

This looks right, I'm just wondering if we now have cases where this will be parsed again. If then they I think this is good and we can drop the change to WindowsPath.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26080#discussion_r2182070199

From mdoerr at openjdk.org  Thu Jul  3 08:49:44 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Jul 2025 08:49:44 GMT
Subject: [jdk25] RFR: 8361183: JDK-8360887 needs fixes to avoid cycles and
 better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <_gqWV0_CgMLwHI2RBTAdQG_G64JZUH_OgYlAgST1KOE=.50033872-f635-4eb9-b701-91d79285370b@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

Thanks! I'm glad to have this fixed in jdk25. Our tests are green.

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

PR Comment: https://git.openjdk.org/jdk/pull/26097#issuecomment-3031414702

From mdoerr at openjdk.org  Thu Jul  3 08:49:45 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 3 Jul 2025 08:49:45 GMT
Subject: [jdk25] Integrated: 8361183: JDK-8360887 needs fixes to avoid cycles
 and better tests (aix)
In-Reply-To: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
References: <mMEMakASSX0YhE_FZELeKvtKOsjGV37vn3U4Z7KKolc=.e09f8fa9-82d1-474d-8cff-3f0e83ca2c08@github.com>
Message-ID: <rK9MHChRy52ef1-pXSFiJb2o_XZPa3CKPYQ3lr7km8Y=.a392d970-513f-49f1-9592-da30e66e98fb@github.com>

On Wed, 2 Jul 2025 15:36:59 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Clean backport of [JDK-8361183](https://bugs.openjdk.org/browse/JDK-8361183).

This pull request has now been integrated.

Changeset: 8a98738f
Author:    Martin Doerr <mdoerr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a98738f448ac91f517bcc5a67d01522b7ba2025
Stats:     35 lines in 2 files changed: 14 ins; 10 del; 11 mod

8361183: JDK-8360887 needs fixes to avoid cycles and better tests (aix)

Reviewed-by: mbaesken
Backport-of: c460f842bf768995b271cd6362940877a4a79665

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

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

From alanb at openjdk.org  Thu Jul  3 09:42:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:42:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

src/java.base/share/classes/java/nio/X-Buffer.java.template line 1907:

> 1905:      * {@code dstBegin} in the array. The position of this buffer is unchanged.
> 1906:      *
> 1907:      * <p> An invocation of this method behaves exactly the same was as the

I think we can use an implSpec for this and keep "This method is equivalent to".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182337987

From alanb at openjdk.org  Thu Jul  3 09:46:40 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:46:40 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <KLE7F4NU-4BfHUaK9JTkdWgWHMqavbR-oalGT0q6s2w=.bb8eab48-cdb5-4ac0-adaf-782b85cf7f26@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

test/jdk/java/nio/Buffer/GetChars.java line 75:

> 73: 
> 74:     @Test
> 75:     public void testSrcBeginIsNegationOfPosition() {

I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap. I think we change each of these tests to changed to paramterrized tests that test all implementations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182346032

From alanb at openjdk.org  Thu Jul  3 09:53:42 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 09:53:42 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <ieaRiYk_22rX5rEqWY-ZO1qn90qeQvVViGIhlRQYFHo=.c6732280-0ff1-43bc-9a46-2318cb5a8008@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

test/jdk/java/nio/Buffer/GetChars.java line 75:

> 73: 
> 74:     @Test
> 75:     public void testSrcBeginIsNegationOfPosition() {

I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap, only testGetChars tests all char buffers. All the test methods should be tested all char buffer implementations. So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2182361518

From bpb at openjdk.org  Thu Jul  3 15:33:41 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 15:33:41 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
Message-ID: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>

On Thu, 3 Jul 2025 09:40:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we can use an implSpec for this and keep "This method is equivalent to".

I was following the existing convention elsewhere in the file.

> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).

Agreed. I also noticed it is TestNG now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183097880
PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183100891

From alanb at openjdk.org  Thu Jul  3 15:52:46 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 15:52:46 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
Message-ID: <WCxB90vWJIpXa8AscIEd7VW9CcYP5cDPKOC9AARJvyE=.92f53256-f853-421b-bceb-28bb6b6110da@github.com>

On Thu, 3 Jul 2025 15:29:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/X-Buffer.java.template line 1907:
>> 
>>> 1905:      * {@code dstBegin} in the array. The position of this buffer is unchanged.
>>> 1906:      *
>>> 1907:      * <p> An invocation of this method behaves exactly the same was as the
>> 
>> I think we can use an implSpec for this and keep "This method is equivalent to".
>
>> I think we can use an implSpec for this and keep "This method is equivalent to".
> 
> I was following the existing convention elsewhere in the file.

I don't know why JDK-8343110 put the implSpec after the param/return/throws tags so happy it has been fixed. Maybe at some point we can use implSpec to these methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183140295

From bpb at openjdk.org  Thu Jul  3 15:58:55 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 15:58:55 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Revert change to WindowsPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/86912f3e..3e994d2e

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

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

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

From bpb at openjdk.org  Thu Jul  3 16:02:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 16:02:44 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v2]
In-Reply-To: <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <cPQ0x6bcq81WQm4MpTMpVX5c1veTZa2MpLCU4pZSy9k=.1574ede2-a96b-409e-bbe7-ef54438eb1a4@github.com>
 <_dw3E1LolcfxwSq6LC_ggmGJUcaZ5q3S4fEezwK665g=.8a2064f6-6462-48bc-95a7-9f5e5ecef5ae@github.com>
Message-ID: <Q9pk9Sq7yG3TVD_UOxVCUWuO0NYmk430i7i5u3x0uuM=.e09c1c57-da34-41d3-8de3-19dd11734a98@github.com>

On Thu, 3 Jul 2025 07:30:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] we can drop the change to WindowsPath.

`WindowsPath` change reverted in 3e994d2.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26080#discussion_r2183159076

From alanb at openjdk.org  Thu Jul  3 16:19:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 16:19:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
Message-ID: <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>

On Thu, 3 Jul 2025 15:58:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Revert change to WindowsPath

Good, I assume you'll drop the left over copyright update from WindowsPath.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/26080#pullrequestreview-2983801679

From bpb at openjdk.org  Thu Jul  3 17:56:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 17:56:56 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v4]
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>

> Ignore empty name elements in `WindowsPath.normalize()`.

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

  8360028: Revert copyright year in WindowsPath

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26080/files
  - new: https://git.openjdk.org/jdk/pull/26080/files/3e994d2e..74fc8ec9

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

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

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

From bpb at openjdk.org  Thu Jul  3 17:56:56 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 17:56:56 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v3]
In-Reply-To: <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <NUM9QIUW9JzAyD8VZ7v6mediYTqsZOc4In31CujtA48=.a1809453-02c3-4cf1-852f-e3616a21d3e9@github.com>
 <ftAw_-UGhuyC16rd-gbgbUzVqA6cJvcZU7BKN6SesSY=.9a7130ac-6c1d-471b-9c7d-42c582b32169@github.com>
Message-ID: <Kkw2SVQL-kjaPBHd8vBwYcb0vkMqCx4aP_swZwyWnRg=.0903c075-7cb8-4f78-a449-70981ce2fab6@github.com>

On Thu, 3 Jul 2025 16:16:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Good, I assume you'll drop the left over copyright update from WindowsPath.

Done.

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

PR Comment: https://git.openjdk.org/jdk/pull/26080#issuecomment-3033088843

From alanb at openjdk.org  Thu Jul  3 18:00:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:00:38 GMT
Subject: RFR: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win) [v4]
In-Reply-To: <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
 <Ag3CFyo_s2134LYO7Ut9cBmj2TvxOYNHGFJFYJSEHtE=.f88973b8-b8f1-4768-a697-4c5ba732610b@github.com>
Message-ID: <bbi3DJWDRX8n39TFPLf9AV67gBAP5cPj_p7Tu1m5b8E=.bf393f24-837b-4744-a495-602ed4414220@github.com>

On Thu, 3 Jul 2025 17:56:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore empty name elements in `WindowsPath.normalize()`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8360028: Revert copyright year in WindowsPath

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26080#pullrequestreview-2984141312

From alanb at openjdk.org  Thu Jul  3 18:04:39 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:04:39 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
Message-ID: <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>

On Thu, 3 Jul 2025 15:30:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/Buffer/GetChars.java line 75:
>> 
>>> 73: 
>>> 74:     @Test
>>> 75:     public void testSrcBeginIsNegationOfPosition() {
>> 
>> I skimmed through GetChars and I see it only tests a CB created with CharBuffer.wrap, only testGetChars tests all char buffers. All the test methods should be tested all char buffer implementations. So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
>
>> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
> 
> Agreed. I also noticed it is TestNG now.

Okay, let's create a follow-up issue for that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2183428833

From alanb at openjdk.org  Thu Jul  3 18:07:41 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 3 Jul 2025 18:07:41 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
Message-ID: <ySuL9kO_UyzQq6ulEFYIOEV7deBYKmOUjMEjjOZ4zVw=.55bbc36b-27e1-406c-83b5-e6e46d85e8a3@github.com>

On Thu, 3 Jul 2025 00:33:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `CharBuffer.getChars` to respect the class level specification that the provided buffer offset `srcBegin` is relative to the buffer's current position.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8361299: Ensure [srcBegin,srcEnd) is contained in [0,limit()-position())

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26104#pullrequestreview-2984170581

From bchristi at openjdk.org  Thu Jul  3 18:14:40 2025
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 3 Jul 2025 18:14:40 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <9rki3teH2JS04QJZA4zEmory8F8vnRhRnh9bBOIEey0=.3ac76f66-e9e0-45dd-bc5e-0c8bec56632c@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Marked as reviewed by bchristi (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2984204948

From bpb at openjdk.org  Thu Jul  3 18:56:44 2025
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 3 Jul 2025 18:56:44 GMT
Subject: Integrated: 8360028: (fs) Path.relativize throws
 StringIndexOutOfBoundsException (win)
In-Reply-To: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
References: <SNDavQkVq2gj6YONbIhIwDT6LD3siMS8L0icM_vZ-5I=.6ea883ec-be63-4c6c-bcb6-2dd0acd52375@github.com>
Message-ID: <4e3c8RvH9gEIHXAGjg1DYLu46ufAbgNoAK_mrym5Bkk=.e8805bd3-8845-448d-ba6f-16b9f0b3d7d9@github.com>

On Tue, 1 Jul 2025 22:36:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore empty name elements in `WindowsPath.normalize()`.

This pull request has now been integrated.

Changeset: 2d9f0324
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2d9f0324ba21adf216649339c48e49b9cd1e33ff
Stats:     4 lines in 1 file changed: 2 ins; 0 del; 2 mod

8360028: (fs) Path.relativize throws StringIndexOutOfBoundsException (win)

Reviewed-by: alanb

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

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

From rriggs at openjdk.org  Fri Jul  4 03:04:40 2025
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 4 Jul 2025 03:04:40 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
Message-ID: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>

On Sun, 29 Jun 2025 20:43:56 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
>> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
>> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
>> use java.lang.ref.Cleaner.
>> 
>> This change is algorithmically similar to the two previous versions:
>> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
>> Bits::reserveMemory(). For both of those versions and this change, a thread
>> calls that function and tries to reserve some space. If it fails, then it
>> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
>> cleaned. If reservation still fails, then it invokes the GC to try to
>> deactivate more cleaners for cleaning. After that GC it keeps trying the
>> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
>> eventually either succeeding or giving up and throwing OOME.
>> 
>> Retaining that algorithmic approach is one of the goals of this change, since
>> it has been successfully in use since JDK 9 (and was originally developed and
>> extensively tested in JDK 8).
>> 
>> The key to this approach is having a way to determine that deactivated
>> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
>> threads help the reference processor until there was no available work.
>> JDK-8156500 waits for the reference processor to quiesce, relying on its
>> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
>> to do this, which is why this change rolls its own Cleaner-like mechanism from
>> the underlying primitives. Like JDK-6857566, this change has waiting threads
>> help with cleaning references. This was a potentially undesirable feature of
>> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
>> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
>> became internal-only somewhere around that time as well.) That's not a concern
>> here, as the cleaners involved are only from DBB, and we know what they look
>> like.
>> 
>> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
>> being done off the reference processing thread, as it may be expensive and
>> slow down enqueuing other pending references. JDK-6857566 only did some of
>> that, and JDK-8156500 lost that feature. This change moves all of the DBB
>> cleaning off of the reference processing thread. (So does PR 22165.)
>> 
>> Neither JDK-6857566 nor this change are...
>
> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add @Override for clean() method
>  - more commentary for reserveMemory

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/25289#pullrequestreview-2985267261

From kbarrett at openjdk.org  Fri Jul  4 04:11:53 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Jul 2025 04:11:53 GMT
Subject: RFR: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner [v7]
In-Reply-To: <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
 <fsFrk-uILf3zDODjfBhMP2qOFvCPIMHSVVAf6gn-x68=.29863279-7056-4309-b5f4-1a7ea2be7ffb@github.com>
 <96W7Z-kXZQxhp4r-tSvQ8d3T0UjPF4wqt8tKvnATxqw=.9d641157-375c-4f87-acab-cb8e4adb746a@github.com>
Message-ID: <9T0IH7MPf51_gVvSapU43ys6JbPVpWU3gEuAaJyjJ_k=.692c5970-60cc-4392-b80c-9b89c5b8e3bd@github.com>

On Fri, 4 Jul 2025 03:02:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Kim Barrett has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add @Override for clean() method
>>  - more commentary for reserveMemory
>
> Marked as reviewed by rriggs (Reviewer).

Thanks for reviews, @RogerRiggs and @bchristi-git

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

PR Comment: https://git.openjdk.org/jdk/pull/25289#issuecomment-3034379255

From kbarrett at openjdk.org  Fri Jul  4 04:11:55 2025
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 4 Jul 2025 04:11:55 GMT
Subject: Integrated: 8344332: (bf) Migrate DirectByteBuffer away from
 jdk.internal.ref.Cleaner
In-Reply-To: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
References: <Tf3bUauvymNvoeefTDY8gYfjcIAyFKv2d7_ktDemlV4=.ce8a894c-28b2-49c3-a515-2c31be1e6d6f@github.com>
Message-ID: <e2Cn6EXWN9GlXf3sVF3FPLHKZ4FlmiuWn-smzoGrxeE=.935becee-1978-48d0-ba11-02a3180eb89b@github.com>

On Sun, 18 May 2025 11:35:55 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

> This change makes java.nio no longer use jdk.internal.ref.Cleaner to manage
> native memory for Direct-X-Buffers. Instead it uses bespoke PhantomReferences
> and a dedicated ReferenceQueue. This differs from PR 22165, which proposed to
> use java.lang.ref.Cleaner.
> 
> This change is algorithmically similar to the two previous versions:
> JDK-6857566 and JDK-8156500 (current mainline). The critical function is
> Bits::reserveMemory(). For both of those versions and this change, a thread
> calls that function and tries to reserve some space. If it fails, then it
> keeps trying until all cleaners deactivated (cleared) by prior GCs have been
> cleaned. If reservation still fails, then it invokes the GC to try to
> deactivate more cleaners for cleaning. After that GC it keeps trying the
> reservation and waiting for cleaning, with sleeps to avoid a spin loop,
> eventually either succeeding or giving up and throwing OOME.
> 
> Retaining that algorithmic approach is one of the goals of this change, since
> it has been successfully in use since JDK 9 (and was originally developed and
> extensively tested in JDK 8).
> 
> The key to this approach is having a way to determine that deactivated
> cleaners have been cleaned. JDK-6857566 accomplished this by having waiting
> threads help the reference processor until there was no available work.
> JDK-8156500 waits for the reference processor to quiesce, relying on its
> immediate processing of cleaners. java.lang.ref.Cleaner doesn't provide a way
> to do this, which is why this change rolls its own Cleaner-like mechanism from
> the underlying primitives. Like JDK-6857566, this change has waiting threads
> help with cleaning references. This was a potentially undesirable feature of
> JDK-6857566, as arbitrary allocating threads were invoking arbitrary cleaners.
> (Though by the time of JDK-6857566 the cleaners were only used by DBB, and
> became internal-only somewhere around that time as well.) That's not a concern
> here, as the cleaners involved are only from DBB, and we know what they look
> like.
> 
> As noted in the discussion of JDK-6857566, it's good to have DBB cleaning
> being done off the reference processing thread, as it may be expensive and
> slow down enqueuing other pending references. JDK-6857566 only did some of
> that, and JDK-8156500 lost that feature. This change moves all of the DBB
> cleaning off of the reference processing thread. (So does PR 22165.)
> 
> Neither JDK-6857566 nor this change are completely precise. For both, a thread
> may find there is no available work whil...

This pull request has now been integrated.

Changeset: 21f2e9a7
Author:    Kim Barrett <kbarrett at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21f2e9a71c31320a8b1248e3970a82b871c63c2b
Stats:     524 lines in 9 files changed: 480 ins; 24 del; 20 mod

8344332: (bf) Migrate DirectByteBuffer away from jdk.internal.ref.Cleaner

Reviewed-by: rriggs, bchristi

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

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

From duke at openjdk.org  Mon Jul  7 13:17:43 2025
From: duke at openjdk.org (Brett Okken)
Date: Mon, 7 Jul 2025 13:17:43 GMT
Subject: RFR: 8361299: (bf) CharBuffer.getChars(int,int,char[],int)
 violates pre-existing specification [v3]
In-Reply-To: <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>
References: <fWt7Rd5RI0qRXrTQP49WuxMgWDEIEh_C7O6EJhV4F_M=.467cbce1-3e89-4220-88b4-ba6b16d80f1d@github.com>
 <hZFg6RSgQRm1VwBBjDymxNldN32LYzuNaNd6q5MGKaY=.e628f475-88c3-4846-abd4-2ca01c29d7e8@github.com>
 <GqEbXUot4AhR-TVJceR1U4aP03SAlmPOxXTzDt5uEgs=.71f1e175-e740-4e68-9422-bca182691c46@github.com>
 <cBcWiIMbtMQojGbhqluxXnzKSZD2UG2g5UH2s1yGGSc=.fde57cbc-bb0a-4634-a123-7dd3a1c70a49@github.com>
 <pKQ4pwvWQ8c_4pdzriaJH0UevyYy1TnxAyHGiCja3Ac=.854df5f1-8f9f-4253-9ec6-e121abc064fc@github.com>
Message-ID: <yiULwOAeWizw3ZahXxx4vYdEYWfU6JRfNTeO1At6gLA=.05992cbe-e609-4c7a-80d3-db77f78d9c11@github.com>

On Thu, 3 Jul 2025 18:02:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> So maybe we can create a follow-up issue to improve this test (and probably migrate it to a JUnit test too).
>> 
>> Agreed. I also noticed it is TestNG now.
>
> Okay, let's create a follow-up issue for that.

Could there also be value in a more generic `CharBufferAsCharSequenceTest` test which covers the entirety of the `CharSequence` interface on the various `CharBuffer` implementations in various "states" (position, offset, limit, etc.)?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26104#discussion_r2190061803