From tprinzing at openjdk.org  Tue Dec  3 00:40:24 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 3 Dec 2024 00:40:24 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

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

  split socket connect failure out to its own event.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/13f81570..f7b3be00

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

  Stats: 327 lines in 16 files changed: 240 ins; 21 del; 66 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From alanb at openjdk.org  Tue Dec  3 08:12:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 08:12:43 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
Message-ID: <5c8gIt8-z91QNINjYzUv5lpgo_0opzxoyFnW3GGMI6w=.d57ac699-6478-4f28-be6b-6fef9f5295e3@github.com>

On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   split socket connect failure out to its own event.

Would it be possible to sync up the branch from master as it hasn't been sync'ed up since Oct.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2513817462

From alanb at openjdk.org  Tue Dec  3 12:36:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 12:36:41 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
Message-ID: <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>

On Mon, 25 Nov 2024 13:23:23 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Having a view for connect failures that doesn't require exceptions=all could be useful. Does this mean two events, one an instant event for the failures, the other a duration event for the connections that are slow to establish?
>
> A connection failure introduces a latency in the application, so probably best to have such an event durational as well.

@egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867647214

From tprinzing at openjdk.org  Tue Dec  3 15:40:02 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 3 Dec 2024 15:40:02 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v7]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into JDK-8310996
   
   # Conflicts:
   #	src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
 - split socket connect failure out to its own event.
 - Added more tests for socket connect events.
   
   - SocketAdapter connect
   - SocketAdapter connect with exception
   - Socket connect with exception
   - SocketChannel connect with exception
   - SocketChannel non-blocking connect
   - SocketChannel non-blocking connect with exception
 - suggested changes
 - improved exception names and handling
 - Added support for connection failure and non-blocking connections.
   
   If an exception is thrown while attempting a connection, the message
   from the exception is stored in the event.  The start time of the
   initial connect call is stored and used when a finishConnect call is
   successful or an exception is thrown.
 - fix default settings
 - fix merge
 - Merge branch 'master' into JDK-8310996
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
 - added tests and support for sockets.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/dfa5620f...a379609e

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

Changes: https://git.openjdk.org/jdk/pull/21528/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=06
  Stats: 738 lines in 16 files changed: 686 ins; 7 del; 45 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From dfuchs at openjdk.org  Tue Dec  3 16:33:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:58 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
Message-ID: <1lHHT0dJUnuCp8V_J__oATyi7XKeVI5ikrlAAv-kgNo=.e300e896-7a46-4de9-94d9-2496452bcef8@github.com>

On Sat, 23 Nov 2024 08:36:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Added more tests for socket connect events.
>>   
>>   - SocketAdapter connect
>>   - SocketAdapter connect with exception
>>   - Socket connect with exception
>>   - SocketChannel connect with exception
>>   - SocketChannel non-blocking connect
>>   - SocketChannel non-blocking connect with exception
>
> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 157:
> 
>> 155:                         while (! sc.finishConnect()) {
>> 156:                             Thread.sleep(1);
>> 157:                         }
> 
> The connect method returns true if the connection is established, you should only need to poll finishConnect if the connection is not established immediately. Using a sleep is okay here (although 1ms is very low) and I'm guessing you've done this to avoid using a Selector.

It should be OK to sleep for longer if you don't want to use a selector.

> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 216:
> 
>> 214:                 } catch (IOException ioe) {
>> 215:                     // we expect this
>> 216:                     connectException = ioe;
> 
> I think you'll need to adjust the try-catch to only set connectException if the connect or finishConnect methods fails. If the open or configureBlocking fails then connectException should not be set, instead the test should fail.

In addition there's no guarantee that connect will fail - so the test should guard for the case where connect might succeed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867981816
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868041972

From dfuchs at openjdk.org  Tue Dec  3 16:33:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:48 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
Message-ID: <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>

On Tue, 3 Dec 2024 00:40:24 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   split socket connect failure out to its own event.

src/java.base/share/classes/jdk/internal/event/SocketConnectFailedEvent.java line 145:

> 143:         if (shouldCommit(duration)) {
> 144:             commit(start, duration, host, address.getHostAddress(), port, connectEx.getMessage());
> 145:         }

Would it be better to pass `connectEx.toString()` here to capture the type of the exception and avoid the awkward case where the message could be the empty string or null? Same in the other offer() method above...

src/jdk.jfr/share/classes/jdk/jfr/events/SocketConnectFailedEvent.java line 52:

> 50:     @Label("Connect Exception Message")
> 51:     public String connectExceptionMessage;
> 52: }

There seem to be a missing newline at the end of this file

src/jdk.jfr/share/conf/jfr/default.jfc line 746:

> 744:       <setting name="enabled">true</setting>
> 745:       <setting name="stackTrace">true</setting>
> 746:       <setting name="threshold" control="socket-threshold">20 ms</setting>

Does this event needs a threshold?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867888476
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867909881
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867912497

From dfuchs at openjdk.org  Tue Dec  3 16:33:55 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 3 Dec 2024 16:33:55 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v7]
In-Reply-To: <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <lCMAOlIQ_nflVjOpkMwLRmXTWS3QGBPN5YlVefIe-dQ=.e08c1bba-a76f-48c2-bba5-207ad65b9229@github.com>
Message-ID: <RgCo5IhbI4VhTMCs0FKeovP_z6weI_jKDd8oSSGxfEY=.f56976af-4c80-4672-b1cc-586411a67c7a@github.com>

On Tue, 3 Dec 2024 15:40:02 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into JDK-8310996
>    
>    # Conflicts:
>    #	src/java.base/share/classes/sun/nio/ch/NioSocketImpl.java
>  - split socket connect failure out to its own event.
>  - Added more tests for socket connect events.
>    
>    - SocketAdapter connect
>    - SocketAdapter connect with exception
>    - Socket connect with exception
>    - SocketChannel connect with exception
>    - SocketChannel non-blocking connect
>    - SocketChannel non-blocking connect with exception
>  - suggested changes
>  - improved exception names and handling
>  - Added support for connection failure and non-blocking connections.
>    
>    If an exception is thrown while attempting a connection, the message
>    from the exception is stored in the event.  The start time of the
>    initial connect call is stored and used when a finishConnect call is
>    successful or an exception is thrown.
>  - fix default settings
>  - fix merge
>  - Merge branch 'master' into JDK-8310996
>    
>    # Conflicts:
>    #	src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java
>    #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
>  - added tests and support for sockets.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/dfa5620f...a379609e

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 149:

> 147:                 } catch (IOException ioe) {
> 148:                     // we expect this
> 149:                     connectException = ioe;

Though unlikely the connect() call could succeed if another (test) process managed to rebind and listen to the port that our server socket just freed. 
An alternative could be to try to connect to a TCP port reserved by IANA, such as ports 225-241 for instance. Hopefully there should be nothing listening at these ports.

Another possibility would be to restart the whole thing untill connect actually fails.

You could try to find a refusing port that will generate an exception using something similar to https://github.com/openjdk/jdk/blob/3eaa7615cd7dc67eb78fb0a8f89d4e6662a0db37/test/jdk/java/nio/channels/SocketChannel/OpenLeak.java#L65
Note that I had some trouble with that on windows (attempting to connect to port 47 was using up the whole connect timeout on windows) so you might need to experiment a bit with different reserved ports if you want to go down this route.
 
In anycase, the case where connect() unexpectedly succeed should be handled, for instance by throwing a `jtreg.SkippedException`, or by simply printing a warning and returning, or by retrying with another port until an exception is obtained.

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 185:

> 183:                     // we expect this
> 184:                     connectException = ioe;
> 185:                 }

Same remark as previouly: it's not guaranteed that connect() will not succeed.
Also I notice that we're using main/othervm here - and this method is not last one called in main() - so we might not want to throw SkippedException here. Possibly printing a warning and returning would be a better option. Or try with another port...

test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 146:

> 144:                     // we expect this
> 145:                     connectException = ioe;
> 146:                 }

Same remark as for the other test: exception is not a guaranteed outcome.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867974742
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1867983998
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868044001

From alanb at openjdk.org  Tue Dec  3 17:11:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Dec 2024 17:11:49 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v6]
In-Reply-To: <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <Xqd9DbVltRdb1Ydv6RMKDJmGxrscFqH0cwFzTpafKwc=.8a458e63-bc54-4ba2-ad27-85ccd0dd3dd7@github.com>
 <d-1Z_pA5-i6YC2h366K3NW-FdJOB_ClRWdP4RkqpBgo=.033e93d2-fbc9-4028-b159-49fb071f98ea@github.com>
Message-ID: <vgFbtAhltSSnmc33pLZH3I9ErEyapbr1GZ4Pi1tHk_4=.b7be426a-3322-410d-b537-19609e0ee908@github.com>

On Tue, 3 Dec 2024 15:12:10 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   split socket connect failure out to its own event.
>
> src/jdk.jfr/share/conf/jfr/default.jfc line 746:
> 
>> 744:       <setting name="enabled">true</setting>
>> 745:       <setting name="stackTrace">true</setting>
>> 746:       <setting name="threshold" control="socket-threshold">20 ms</setting>
> 
> Does this event needs a threshold?

I think it needs to be a duration event, otherwise it's possible to a floor events when connections fail immediately. With the current proposal then it is at least configurable.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868102788

From bpb at openjdk.org  Tue Dec  3 20:04:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Dec 2024 20:04:02 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct buffers
 and the buffer size limit
Message-ID: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>

Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

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

Commit messages:
 - 8345421: (bf) Create specific test for temporary direct buffers and the buffer size limit

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

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

From bpb at openjdk.org  Tue Dec  3 20:04:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 3 Dec 2024 20:04:02 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit
In-Reply-To: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
Message-ID: <WenJc-EMSp9xPpcSOCBX2Cii9x56cr1H0lJakCQuYd8=.0893cda9-4b92-46d6-bed3-f6af678a1968@github.com>

On Tue, 3 Dec 2024 19:57:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

The proposed test fails on all platforms before the fix of JDK-8344882 is applied and succeeds afterwards.

The `noreg-other` label will be removed from `JDK-8344882` once (if) this request is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/22525#issuecomment-2515429300
PR Comment: https://git.openjdk.org/jdk/pull/22525#issuecomment-2515431809

From brian.burkhalter at oracle.com  Tue Dec  3 21:49:22 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Tue, 3 Dec 2024 21:49:22 +0000
Subject: Files.createDirectories throws AccessDeniedException for an
 existing directory
In-Reply-To: <85ad63df-660a-4a6b-bcd3-f569e0c01af3@gmx.de>
References: <trinity-ca4d90f5-57af-4740-b8a2-0ac3bf1b4f77-1732639485728@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-pcfmb>
 <528B7C32-576E-4397-B42B-2912F8C4A766@oracle.com>
 <trinity-b2551d7f-e364-41d1-80f3-a92de7b0e30e-1732705318022@trinity-msg-rest-gmx-gmx-live-5cd5dd5458-r2xnf>
 <B596B512-866A-48F9-BB5F-65E7453E98B5@oracle.com>
 <85ad63df-660a-4a6b-bcd3-f569e0c01af3@gmx.de>
Message-ID: <B9859EF8-61E5-41E1-A147-E70ECA89423D@oracle.com>

Hi Ole,

On Nov 29, 2024, at 2:13?PM, Ole SH <ole.sh at gmx.de> wrote:

To address your problem then the safest approach would appear to be overriding createDirectory() in LinuxFileSystemProvider to have the desired behavior, such as was done on Windows.


As a "user" of the API I would appreciate such a change.

I filed https://bugs.openjdk.org/browse/JDK-8345430 to track this proposal.

Best regards,

Brian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20241203/03249f72/attachment-0001.htm>

From egahlin at openjdk.org  Tue Dec  3 23:45:39 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 3 Dec 2024 23:45:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
Message-ID: <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>

On Tue, 3 Dec 2024 12:34:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> A connection failure introduces a latency in the application, so probably best to have such an event durational as well.
>
> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.

We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.

We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1868506166

From varadam at openjdk.org  Wed Dec  4 11:21:44 2024
From: varadam at openjdk.org (Varada M)
Date: Wed, 4 Dec 2024 11:21:44 GMT
Subject: Withdrawn: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
In-Reply-To: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
References: <uXHa7gCr4oD9z4kNer8tnMKSChn5xovaBeL0iNjkYGk=.25873275-aa93-4808-b317-0f1aa6564c21@github.com>
Message-ID: <97kVHXYIxarbViEAlLaN0n0RsJrtCG1riYo4fTQd2y0=.0d187c24-ebe0-4bc0-b0e9-5fd64e5e70eb@github.com>

On Mon, 14 Oct 2024 07:08:36 GMT, Varada M <varadam at openjdk.org> wrote:

> Intermittent timeout error of StressLoopBack.java is resolved with more straight forward method and similar implementation done for linux [EPollPort.java - L175](https://github.com/openjdk/jdk/blob/master/src/java.base/linux/classes/sun/nio/ch/EPollPort.java#L175) and macos [KQueuePort.java - L172](https://github.com/openjdk/jdk/blob/master/src/java.base/macosx/classes/sun/nio/ch/KQueuePort.java#L172)
> 
> Ran the test for 50 times and didn't observed any timeout error.
> Tier 1 testing successful with fastdebug VM
> 
> JBS Issue : [JDK-8211851](https://bugs.openjdk.org/browse/JDK-8211851)

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Wed Dec  4 11:35:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 11:35:43 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit
In-Reply-To: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
Message-ID: <jRYdbzs8UImW9bDAUZ2zaWXjXhiwBV0kiADKqIDmyo0=.d35c00e0-cb7c-44a7-b001-62d77b2c98b9@github.com>

On Tue, 3 Dec 2024 19:57:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

There are some stability issues since the change went in so maybe hold off on adding a test as it's possible the change may have be temporarily reverted.

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

PR Comment: https://git.openjdk.org/jdk/pull/22525#issuecomment-2517072720

From alanb at openjdk.org  Wed Dec  4 12:28:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 12:28:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
Message-ID: <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>

On Tue, 3 Dec 2024 23:42:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> @egahlin The updated PR proposes two duration events: jdk.SocketConnect for when a connection is established, and jdk.SocketConnectFailed for when a connection cannot be established. Naming aside, it seems that would allow the jfr views that you listed above.
>
> We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.
> 
> We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.

We need to help Tim on the question of whether there is one or two events. 

An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.

When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1869400913

From duke at openjdk.org  Wed Dec  4 13:24:41 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 4 Dec 2024 13:24:41 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v3]
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <NATqK2TbGCQrl0OsH4NkoiJGw9Hg9HVq3LA88wgV638=.c5305ce0-fe52-4f21-ac33-bc196671e625@github.com>

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

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

 - Merge branch 'openjdk:master' into 8331467
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider
 - Revert "8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider"
   
   This reverts commit 318888339bdc2ee6a632e4850a980d91bff79e79.
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21997/files
  - new: https://git.openjdk.org/jdk/pull/21997/files/10bae79b..4c93e0a2

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

  Stats: 537113 lines in 7066 files changed: 285405 ins; 207189 del; 44519 mod
  Patch: https://git.openjdk.org/jdk/pull/21997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21997/head:pull/21997

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

From bpb at openjdk.org  Wed Dec  4 16:39:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 16:39:57 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType
Message-ID: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>

Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

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

Commit messages:
 - 8345433: (fs) Use stream to load FileTypeDetectors in Files.probeContentType

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

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

From bpb at openjdk.org  Wed Dec  4 16:39:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 16:39:57 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType
In-Reply-To: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
Message-ID: <13KJVfpYuCkIgqFVMR978GT6bjHBNtdRjiWKdjebykM=.2754515d-26d0-4891-82db-fd11574c4001@github.com>

On Wed, 4 Dec 2024 16:34:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

This change was suggested [here](https://github.com/openjdk/jdk/pull/22132#discussion_r1844185396) by @RogerRiggs.

An unused variable in `AsynchronousChannelProvider` is incidentally removed as suggested [here](https://github.com/openjdk/jdk/pull/22132#discussion_r1847879204) by @turbanoff.

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

PR Comment: https://git.openjdk.org/jdk/pull/22552#issuecomment-2517975343

From aturbanov at openjdk.org  Wed Dec  4 17:00:41 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 4 Dec 2024 17:00:41 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType
In-Reply-To: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
Message-ID: <ZL-oMY6Yq_an39IDVLQbTfZL6a4PG3DT0xsK3HAfNPQ=.88cba9ad-f981-44ba-b82a-e29f8b67c407@github.com>

On Wed, 4 Dec 2024 16:34:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

src/java.base/share/classes/java/nio/file/Files.java line 1528:

> 1526:                                       ClassLoader.getSystemClassLoader())
> 1527:                 .stream()
> 1528:                 .map(p -> p.get()).toList();

Let's move `.toList();` to a separate line

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22552#discussion_r1869944864

From bpb at openjdk.org  Wed Dec  4 18:11:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:11:02 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v2]
In-Reply-To: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
Message-ID: <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>

> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

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

  8345433: Move toList() to separate line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22552/files
  - new: https://git.openjdk.org/jdk/pull/22552/files/984c2813..44401e78

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

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

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

From bpb at openjdk.org  Wed Dec  4 18:11:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:11:02 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v2]
In-Reply-To: <ZL-oMY6Yq_an39IDVLQbTfZL6a4PG3DT0xsK3HAfNPQ=.88cba9ad-f981-44ba-b82a-e29f8b67c407@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <ZL-oMY6Yq_an39IDVLQbTfZL6a4PG3DT0xsK3HAfNPQ=.88cba9ad-f981-44ba-b82a-e29f8b67c407@github.com>
Message-ID: <RiYlYywg5dTCnKR-_0HAAxJuZFJg0mvAPUCW_fE0DDQ=.805d9840-e82e-46d5-8b46-de6ba35d5c77@github.com>

On Wed, 4 Dec 2024 16:57:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345433: Move toList() to separate line
>
> src/java.base/share/classes/java/nio/file/Files.java line 1528:
> 
>> 1526:                                       ClassLoader.getSystemClassLoader())
>> 1527:                 .stream()
>> 1528:                 .map(p -> p.get()).toList();
> 
> Let's move `.toList();` to a separate line

So changed in [44401e7](https://github.com/openjdk/jdk/pull/22552/commits/44401e788d6cd9f3b67a0ba8a67874e8aca7ba6e).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22552#discussion_r1870043975

From rriggs at openjdk.org  Wed Dec  4 18:14:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Dec 2024 18:14:43 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v2]
In-Reply-To: <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>
Message-ID: <8JsAttZKi4EaQ6hqnG-46yRWOwgyOIsJkmINuYKNvS8=.99cb4a30-6b44-4a2f-ab1b-7c252323f84c@github.com>

On Wed, 4 Dec 2024 18:11:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345433: Move toList() to separate line

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22552#pullrequestreview-2479530238

From alanb at openjdk.org  Wed Dec  4 18:18:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 18:18:39 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v2]
In-Reply-To: <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>
Message-ID: <7GpoO41ZQhqzSBVQfPocYb1wrVPg_p-JHRGC56PwViw=.7f752ccc-b97a-4db9-bd88-d05d7e894c5f@github.com>

On Wed, 4 Dec 2024 18:11:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345433: Move toList() to separate line

src/java.base/share/classes/java/nio/file/Files.java line 1528:

> 1526:                                       ClassLoader.getSystemClassLoader())
> 1527:                 .stream()
> 1528:                 .map(p -> p.get())

This looks fine, the alternative is to use a method ref, as in map(ServiceLoader.Provider::get) if you want.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22552#discussion_r1870056976

From bpb at openjdk.org  Wed Dec  4 18:28:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:28:14 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v2]
In-Reply-To: <7GpoO41ZQhqzSBVQfPocYb1wrVPg_p-JHRGC56PwViw=.7f752ccc-b97a-4db9-bd88-d05d7e894c5f@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <qdmJcLbESAW1as8IWbTCNuB6fstBD4qF_xzO69VBCPw=.08dd6d8e-9e61-4749-b1f0-cf6d619ce501@github.com>
 <7GpoO41ZQhqzSBVQfPocYb1wrVPg_p-JHRGC56PwViw=.7f752ccc-b97a-4db9-bd88-d05d7e894c5f@github.com>
Message-ID: <i1nv8GBq-YZ4zDQBjOfr3z-ijWGaM9F8NV6AOyD1NsE=.4b76d98c-f3d3-4067-b7a2-f9d89f86da87@github.com>

On Wed, 4 Dec 2024 18:15:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345433: Move toList() to separate line
>
> src/java.base/share/classes/java/nio/file/Files.java line 1528:
> 
>> 1526:                                       ClassLoader.getSystemClassLoader())
>> 1527:                 .stream()
>> 1528:                 .map(p -> p.get())
> 
> This looks fine, the alternative is to use a method ref, as in map(ServiceLoader.Provider::get) if you want.

So changed in c6f997e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22552#discussion_r1870071747

From bpb at openjdk.org  Wed Dec  4 18:28:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:28:14 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v3]
In-Reply-To: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
Message-ID: <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>

> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

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

  8345433: Use method ref ServiceLoader.Provider::gget

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22552/files
  - new: https://git.openjdk.org/jdk/pull/22552/files/44401e78..c6f997e6

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

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

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

From alanb at openjdk.org  Wed Dec  4 18:33:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 18:33:39 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v3]
In-Reply-To: <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
Message-ID: <Qi2bliRz2XUurtkT7LVk2vjczdneZ6T7Wj9CnEsNcN4=.17ad99e4-3348-4491-90f6-efe7de85c691@github.com>

On Wed, 4 Dec 2024 18:28:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345433: Use method ref ServiceLoader.Provider::gget

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22552#pullrequestreview-2479572943

From rriggs at openjdk.org  Wed Dec  4 18:33:39 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 4 Dec 2024 18:33:39 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v3]
In-Reply-To: <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
Message-ID: <flAhZ7sgDwmUeaEn-JGHfUSzeQtQxytJ0NOdBhMtxrA=.d5ac6853-ed2a-4f01-8e1c-ec23656573bc@github.com>

On Wed, 4 Dec 2024 18:28:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345433: Use method ref ServiceLoader.Provider::gget

Marked as reviewed by rriggs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22552#pullrequestreview-2479579221

From bpb at openjdk.org  Wed Dec  4 18:41:57 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:41:57 GMT
Subject: RFR: 8345181: (ch) Windows asynchronous channels may return temporary
 direct buffers to the buffer cache twice (win)
Message-ID: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>

Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.

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

Commit messages:
 - 8345181: (ch) Windows asynchronous channels may return temporary direct buffers to the buffer cache twice (win)

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

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

From bpb at openjdk.org  Wed Dec  4 18:42:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 18:42:45 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v3]
In-Reply-To: <flAhZ7sgDwmUeaEn-JGHfUSzeQtQxytJ0NOdBhMtxrA=.d5ac6853-ed2a-4f01-8e1c-ec23656573bc@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
 <flAhZ7sgDwmUeaEn-JGHfUSzeQtQxytJ0NOdBhMtxrA=.d5ac6853-ed2a-4f01-8e1c-ec23656573bc@github.com>
Message-ID: <qRW_t-1O_DtA5kmZujpA6QHSKUdPn6S4c3UcaATmGEk=.b87f0a2e-9791-4691-9765-07d6724313d2@github.com>

On Wed, 4 Dec 2024 18:30:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345433: Use method ref ServiceLoader.Provider::gget
>
> Marked as reviewed by rriggs (Reviewer).

Thanks @RogerRiggs and @AlanBateman for the prompt approvals.

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

PR Comment: https://git.openjdk.org/jdk/pull/22552#issuecomment-2518250968

From bpb at openjdk.org  Wed Dec  4 19:28:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 19:28:41 GMT
Subject: RFR: 8345181: (ch) Windows asynchronous channels may return
 temporary direct buffers to the buffer cache twice (win)
In-Reply-To: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
References: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
Message-ID: <mw9a5EgLjXr_pdVzowFe2qTK5edF_sm0sbXMf1gNE3s=.c4b8c2c1-c4db-4e8b-971b-82d82ac5d1cd@github.com>

On Wed, 4 Dec 2024 18:36:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.

In further testing, with this change, CI test tiers 1-3 and 300 repeats of the subset of tests where the failure was observed passed on Windows.

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

PR Comment: https://git.openjdk.org/jdk/pull/22554#issuecomment-2518379243

From bpb at openjdk.org  Wed Dec  4 19:31:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 19:31:51 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <U2nMFjh-cY6MUcFc-ac6Xs_bt66b7vM6SSiHacsPb28=.16d3f436-9294-4eac-9562-01d297d187c7@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <5_SmMLL5jFo_dN_8CblOA5LJJzhsxoL0vqbxOQp-TXM=.4f5c3ac6-f5c8-4eeb-9989-5f5dfa7cd5e0@github.com>
 <U2nMFjh-cY6MUcFc-ac6Xs_bt66b7vM6SSiHacsPb28=.16d3f436-9294-4eac-9562-01d297d187c7@github.com>
Message-ID: <0-lGm14JDxMCh-Sx5EGfcuHiL7L5oDMsTMNIJayjoUs=.ed89718f-064d-4741-aef1-d9e14a346c31@github.com>

On Tue, 19 Nov 2024 08:23:23 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Remove one straggling toString()
>
> src/java.base/share/classes/java/nio/channels/spi/AsynchronousChannelProvider.java line 93:
> 
>> 91:                 ServiceLoader.load(AsynchronousChannelProvider.class,
>> 92:                                    ClassLoader.getSystemClassLoader());
>> 93:             Iterator<AsynchronousChannelProvider> i = sl.iterator();
> 
> iterator is now unused

Addressed in #22552.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1870167500

From bpb at openjdk.org  Wed Dec  4 19:31:52 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 19:31:52 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v5]
In-Reply-To: <B1W2eGE0Mk3oMsuNBGv3yduFsA5QmYziFi1Tevmpjek=.c998c164-38cd-4465-9213-eda6ec1c6cfb@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <cZJLp0_7r-Bx4FCBbitcTCTM0IlcNazvcSfyDswRipc=.3e07ebb8-7101-400d-8f4c-c4870516a8cc@github.com>
 <nhlH4UHDzXD3r637kqB77nATtGAj2ckKg0nbqXAy2B8=.1b109264-3938-483a-a221-b23ada8d6e67@github.com>
 <B1W2eGE0Mk3oMsuNBGv3yduFsA5QmYziFi1Tevmpjek=.c998c164-38cd-4465-9213-eda6ec1c6cfb@github.com>
Message-ID: <_-W8KBMmyDhmlhULYGiGyjFxnLxW9GsJkdWOAyjpg-A=.a1b93704-63c6-40a8-aa40-d218c0705cff@github.com>

On Fri, 15 Nov 2024 18:00:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Files.java line 1528:
>> 
>>> 1526:                 list.add(detector);
>>> 1527:             }
>>> 1528:             return list;
>> 
>> Possible refactor to use stream API:  (may be a bit too aggressive)
>> Suggestion:
>> 
>>              return ServiceLoader
>>                     .load(FileTypeDetector.class, ClassLoader.getSystemClassLoader())
>>                     .stream()
>>                     .map(p -> (FileTypeDetector)p).toList();
>
> Thanks for the suggestion. Perhaps in a later commit: I prefer to keep the initial changes close to the original.

Addressed in #22552.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1870167141

From bpb at openjdk.org  Wed Dec  4 19:31:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 19:31:53 GMT
Subject: RFR: 8344078: Remove security manager dependency in java.nio [v3]
In-Reply-To: <vUzMYmZn2xE6ZnFoz_IITXfZ5MbV3kg_ELDnECAIQQo=.c1229f3a-fa3b-46f2-8ca4-06e09cd34a50@github.com>
References: <Aq6WRD-UhqrFkDRhhKZRuYuViHctSZAwYs9CkY8K_ZA=.63dc930f-7283-45de-bf48-4f1c19c0468b@github.com>
 <L6ILMeTHi6xYJE1DaFxFClUU3Qu4kN-mzFq5atSCxoQ=.278d4864-f8ec-43ff-96c8-0d810453b62f@github.com>
 <vUzMYmZn2xE6ZnFoz_IITXfZ5MbV3kg_ELDnECAIQQo=.c1229f3a-fa3b-46f2-8ca4-06e09cd34a50@github.com>
Message-ID: <ZrflRNaVtM7HrbFuwjXh8ngJMn00zD2jKkByPMdIZeY=.f0693f47-50cc-4b13-b12f-6c7e883b9676@github.com>

On Sat, 16 Nov 2024 09:12:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344078: Address reviewer comments
>
> src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 76:
> 
>> 74:             t.setDaemon(true);
>> 75:             return t;
>> 76:         };
> 
> This is another case where we should move to InnocuousThread, not this PR of course.

Tracked by [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432).

> src/java.base/share/classes/sun/nio/fs/AbstractPoller.java line 62:
> 
>> 60:                                 false);
>> 61:         thr.setDaemon(true);
>> 62:         thr.start();
> 
> Not for this PR but we should replace this with an InnocuousThread at some point.

Tracked by [JDK-8345432](https://bugs.openjdk.org/browse/JDK-8345432).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1870168932
PR Review Comment: https://git.openjdk.org/jdk/pull/22132#discussion_r1870168649

From alanb at openjdk.org  Wed Dec  4 20:07:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 4 Dec 2024 20:07:40 GMT
Subject: RFR: 8345181: (ch) Windows asynchronous channels may return
 temporary direct buffers to the buffer cache twice (win)
In-Reply-To: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
References: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
Message-ID: <Ir0qt8k2BxHxkIRRw1cGWTg25q_-sv-VoeHWlMnH6uQ=.50cea3f8-20a2-4a19-abf3-29987ad60352@github.com>

On Wed, 4 Dec 2024 18:36:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.

I provided the change for this PR so I can't really be the reviewer too. So I've set reviewer to 2. @Michael-Mc-Mahon is going to help review too.

Just more context here. On Windows, when a file or socket handle is associated with an I/O completion port then the outcome may be handled on the initiating thread when the I/O op completes or fails immediately, or I/O completion status is queued. There are cases where it gets handled on the initiating thread but an I/O completion status is also queued. The buffer handled around this is tricky and it seems that since JDK 7, a substituted buffer can been returned to the TL buffer cache more than once. The changes in this PR will ensure can't handle. Future work could be done in this area to simplify several things but not now.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22554#pullrequestreview-2479791325
PR Comment: https://git.openjdk.org/jdk/pull/22554#issuecomment-2518448817

From aturbanov at openjdk.org  Wed Dec  4 20:07:41 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 4 Dec 2024 20:07:41 GMT
Subject: RFR: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType [v3]
In-Reply-To: <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
 <mebbgdUvTO-PuWFRfwDGT1X6XLXSnqcDAbj8pc1ZPwY=.7e7146b7-8da4-47e6-84c1-214f0041238e@github.com>
Message-ID: <efNWEWx20mlgIs_E623YJil1Qy2ef_08Z0trYAzq1RA=.89702f81-02e4-4d60-9699-e019059f0bb9@github.com>

On Wed, 4 Dec 2024 18:28:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345433: Use method ref ServiceLoader.Provider::gget

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/22552#pullrequestreview-2479791545

From bpb at openjdk.org  Wed Dec  4 20:30:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 20:30:43 GMT
Subject: Integrated: 8345433: (fs) Use stream to load FileTypeDetectors in
 Files.probeContentType
In-Reply-To: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
References: <al2IVdYDC5E1xPxP3-PpOAxwmDSWbjhQpKEx5fc9Tjw=.d8e234bf-069b-4797-aa42-44d5262f7be1@github.com>
Message-ID: <iY2QABOla1-eQXe9wJGWci40tXIwxZvPwSjvc-Goyqs=.c4337b53-9f8d-490d-b273-c3d597d9b040@github.com>

On Wed, 4 Dec 2024 16:34:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change `FileTypeDetector` list creation to use a stream rather than an iteration and adds.

This pull request has now been integrated.

Changeset: 1d3dcdf2
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d3dcdf2d635dd74a7de5284f5531d0cc8b6b09e
Stats:     9 lines in 2 files changed: 0 ins; 3 del; 6 mod

8345433: (fs) Use stream to load FileTypeDetectors in Files.probeContentType

Reviewed-by: rriggs, alanb, aturbanov

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

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

From michaelm at openjdk.org  Wed Dec  4 20:42:39 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 4 Dec 2024 20:42:39 GMT
Subject: RFR: 8345181: (ch) Windows asynchronous channels may return
 temporary direct buffers to the buffer cache twice (win)
In-Reply-To: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
References: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
Message-ID: <cO2nnW8Of-GsJzKkkjLurqN7Cdsd70zmSnpfPcdqp6A=.f18ad91a-7183-4fad-bbd9-b20d71afafd2@github.com>

On Wed, 4 Dec 2024 18:36:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.

Seems pretty straightforward. Looks fine.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22554#pullrequestreview-2479856443

From bpb at openjdk.org  Wed Dec  4 21:02:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 21:02:47 GMT
Subject: RFR: 8345181: (ch) Windows asynchronous channels may return
 temporary direct buffers to the buffer cache twice (win)
In-Reply-To: <Ir0qt8k2BxHxkIRRw1cGWTg25q_-sv-VoeHWlMnH6uQ=.50cea3f8-20a2-4a19-abf3-29987ad60352@github.com>
References: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
 <Ir0qt8k2BxHxkIRRw1cGWTg25q_-sv-VoeHWlMnH6uQ=.50cea3f8-20a2-4a19-abf3-29987ad60352@github.com>
Message-ID: <btr0fvRn20SUBMLIp4qrmzc8-3MDDdyrPDgDQyLTWzU=.a40f8447-6a4d-425a-bb7f-f2196ccb9674@github.com>

On Wed, 4 Dec 2024 20:02:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.
>
> Just more context here. On Windows, when a file or socket handle is associated with an I/O completion port then the outcome may be handled on the initiating thread when the I/O op completes or fails immediately, or I/O completion status is queued. There are cases where it gets handled on the initiating thread but an I/O completion status is also queued. The buffer handled around this is tricky and it seems that since JDK 7, a substituted buffer can been returned to the TL buffer cache more than once. The changes in this PR will ensure can't handle. Future work could be done in this area to simplify several things but not now.

Thanks @AlanBateman for the patch and @Michael-Mc-Mahon for the approval!

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

PR Comment: https://git.openjdk.org/jdk/pull/22554#issuecomment-2518548396

From bpb at openjdk.org  Wed Dec  4 21:02:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 4 Dec 2024 21:02:47 GMT
Subject: Integrated: 8345181: (ch) Windows asynchronous channels may return
 temporary direct buffers to the buffer cache twice (win)
In-Reply-To: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
References: <TTRVotwqorzYm-jur3EzvdElOIphZtl6WUfFYf075gk=.ceb1a8f4-bde3-49ac-98aa-6659183fd950@github.com>
Message-ID: <5W61gJORCWi7_R5u0uhYbExzoXpbDhX0kfJlyLExeV0=.38f3a669-0e2c-47fa-89f2-bfe37688fa33@github.com>

On Wed, 4 Dec 2024 18:36:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Due to operations on different threads, the Windows asynchronous channels might try to return the same buffer to the temporary direct buffer cache twice resulting in an attempt to free the same address more than once. This was not a problem before #22339 was integrated, as previously a cleaner had been used to free temporary buffers, and the cleaner did not permit duplicative freeing of the same memory. This change introduces checks in the Windows asynchronous channels to prevent duplicative returns of a buffer to the cache.

This pull request has now been integrated.

Changeset: ea73e058
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea73e058521dd3139b54aa4e2af474c87ecffa5b
Stats:     36 lines in 2 files changed: 26 ins; 2 del; 8 mod

8345181: (ch) Windows asynchronous channels may return temporary direct buffers to the buffer cache twice (win)

Reviewed-by: alanb, michaelm

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

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

From bpb at openjdk.org  Thu Dec  5 18:44:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Dec 2024 18:44:06 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v11]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <0Wfl1u5_aLuRYUaugkrqW-VOFwz8-r-RHmfG7ikXm_I=.fd8a5950-e155-47ba-847c-91e2397c6dd1@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 11 commits:

 - Merge
 - Merge
 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - ... and 1 more: https://git.openjdk.org/jdk/compare/bedb68ab...2cb82267

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=10
  Stats: 1547 lines in 93 files changed: 774 ins; 668 del; 105 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From duke at openjdk.org  Fri Dec  6 20:16:43 2024
From: duke at openjdk.org (jyxzwd)
Date: Fri, 6 Dec 2024 20:16:43 GMT
Subject: Withdrawn: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <naTSbcGBjKPSr_f3Bh_qDuzoFxr8Z8c1iOeAvN3y6_k=.ca60bd04-b7a2-40ed-9bd4-e3f0129f2b8d@github.com>

On Sat, 9 Nov 2024 02:18:22 GMT, jyxzwd <duke at openjdk.org> wrote:

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

This pull request has been closed without being integrated.

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

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

From duke at openjdk.org  Fri Dec  6 21:40:55 2024
From: duke at openjdk.org (duke)
Date: Fri, 6 Dec 2024 21:40:55 GMT
Subject: Withdrawn: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <DAVnmGCsxxmr-_WoYElRJFAcBuyMuOPzK1Ni-9yjogA=.4ef2a254-c1e8-4bc1-a95f-156db925e592@github.com>

On Fri, 23 Aug 2024 10:38:38 GMT, Pratiksha.Sawant <duke at openjdk.org> wrote:

> Mapping ISO-8859-8-I charset to ISO-8859-8.
> Below mentioned 2 aliases are added as part of this:-
> **ISO-8859-8-I**
> **ISO8859-8-I**
> 
> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686

This pull request has been closed without being integrated.

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

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

From jkern at openjdk.org  Mon Dec  9 09:58:46 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 9 Dec 2024 09:58:46 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
Message-ID: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>

Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.

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

Commit messages:
 - JDK-8211851

Changes: https://git.openjdk.org/jdk/pull/22633/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22633&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8211851
  Stats: 58 lines in 4 files changed: 45 ins; 10 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22633/head:pull/22633

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

From alanb at openjdk.org  Mon Dec  9 10:30:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Dec 2024 10:30:43 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
In-Reply-To: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
Message-ID: <mifweeLNye3-26ut4_cYDyWvqeCX0gFtFxkwBBmH2Tg=.5df8976d-9d14-4487-8bea-60c13a49500d@github.com>

On Mon, 9 Dec 2024 09:53:26 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.

src/java.base/aix/classes/sun/nio/ch/Pollset.java line 125:

> 123:     public static native void drain(int fd) throws IOException;
> 124:     public static native void close0(int fd);
> 125:     public static native void configureBlocking(int fd, boolean blocking) throws IOException;

I assume you don't need this, instead use IOUtil.configureBlocking(fd, blocking).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1875735200

From ihse at openjdk.org  Mon Dec  9 12:34:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 12:34:53 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed
Message-ID: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

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

Commit messages:
 - 8345799: Update copyright year to 2024 for core-libs in files where it was missed

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

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

From ihse at openjdk.org  Mon Dec  9 13:03:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:03:06 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Add more core-libs files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/e7cfe0f7..8e040c3a

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

  Stats: 9 lines in 9 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22640.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22640/head:pull/22640

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

From ihse at openjdk.org  Mon Dec  9 13:06:50 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 13:06:50 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where it
 was missed
Message-ID: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>

Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 

I have located these modified files using:

git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list

and then run a script to update the copyright year to 2024 on these files.

I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

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

Commit messages:
 - 8345805: Update copyright year to 2024 for other files where it was missed

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

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

From dfuchs at openjdk.org  Mon Dec  9 13:30:43 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 9 Dec 2024 13:30:43 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <vn5KixoVXSgvE9fcU5Pcd-y9NkYlVz86c8VG-g_P6OM=.3a4a66f2-9b24-49f8-9459-628ab9c8b229@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

changes to sun.net and java.naming/jdk.naming.* look ok

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2527957595

From kevinw at openjdk.org  Mon Dec  9 14:02:39 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 14:02:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <CZvJVQu03QkOiUM5mcdagcdfDvo6SMRhg-OVi9-O9RY=.a676e608-9fbf-4224-a417-2b1e063275af@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Looks good.
They all seem to follow the pattern, I looked at some and yes they have changes in 2024 but no year update.  One of them was mine I noticed!

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

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2488883450

From jkern at openjdk.org  Mon Dec  9 14:53:41 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 9 Dec 2024 14:53:41 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
In-Reply-To: <mifweeLNye3-26ut4_cYDyWvqeCX0gFtFxkwBBmH2Tg=.5df8976d-9d14-4487-8bea-60c13a49500d@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <mifweeLNye3-26ut4_cYDyWvqeCX0gFtFxkwBBmH2Tg=.5df8976d-9d14-4487-8bea-60c13a49500d@github.com>
Message-ID: <oygf8EFcfAcgdghOq0MaHLRR0rAJa-mxSIkgZ8xULjM=.8d1339a0-784e-4ab6-b08b-77f12af7399c@github.com>

On Mon, 9 Dec 2024 10:27:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>
> src/java.base/aix/classes/sun/nio/ch/Pollset.java line 125:
> 
>> 123:     public static native void drain(int fd) throws IOException;
>> 124:     public static native void close0(int fd);
>> 125:     public static native void configureBlocking(int fd, boolean blocking) throws IOException;
> 
> I assume you don't need this, instead use IOUtil.configureBlocking(fd, blocking).

I tried this first, but `IOUtil.configureBlocking(fd, blocking)` needs a `FileDescriptor` object instead of an `int`:
`public static native void configureBlocking(FileDescriptor fd, boolean blocking)`
And I did not find any public FileDescriptor constructor taking an `int`.
I would be happy for any hint to avoid this double implementation of configureBlocking

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1876117543

From rriggs at openjdk.org  Mon Dec  9 15:19:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 15:19:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

Copyright dates in third party files are not updated uniformly. See the previous comment.

That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

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

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489132284
PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528303669

From alanb at openjdk.org  Mon Dec  9 15:22:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Dec 2024 15:22:40 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix)
In-Reply-To: <oygf8EFcfAcgdghOq0MaHLRR0rAJa-mxSIkgZ8xULjM=.8d1339a0-784e-4ab6-b08b-77f12af7399c@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <mifweeLNye3-26ut4_cYDyWvqeCX0gFtFxkwBBmH2Tg=.5df8976d-9d14-4487-8bea-60c13a49500d@github.com>
 <oygf8EFcfAcgdghOq0MaHLRR0rAJa-mxSIkgZ8xULjM=.8d1339a0-784e-4ab6-b08b-77f12af7399c@github.com>
Message-ID: <7duDdYC7S8hkbBGMcABYjwx7ps7DFtapPptZJt0afbQ=.29d8b53a-f5e3-485a-a19e-e81c888c60ec@github.com>

On Mon, 9 Dec 2024 14:51:22 GMT, Joachim Kern <jkern at openjdk.org> wrote:

> I tried this first, but `IOUtil.configureBlocking(fd, blocking)` needs a `FileDescriptor` object instead of an `int`: `public static native void configureBlocking(FileDescriptor fd, boolean blocking)` And I did not find any public FileDescriptor constructor taking an `int`. I would be happy for any hint to avoid this double implementation of configureBlocking

IOUtil.newFD is there if you need it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1876179323

From kevinw at openjdk.org  Mon Dec  9 15:28:38 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 9 Dec 2024 15:28:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
Message-ID: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>

On Mon, 9 Dec 2024 13:03:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add more core-libs files

I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528357715

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert changes to binary files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22640/files
  - new: https://git.openjdk.org/jdk/pull/22640/files/8e040c3a..c8d541f9

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

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

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

From ihse at openjdk.org  Mon Dec  9 15:42:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:42:57 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <A1yQwWAFdf-orxwIzsYw-jG7xfJ16K_Ntxn_Oy-LN64=.9875868c-1441-4111-b031-dbfc99cda00e@github.com>
Message-ID: <QLNzClECNTKmLMG1OzFKoY6S9ZscAfwfF0BhnfJ6_PE=.6c75b36a-0b08-4c14-93b8-553deeb0dd48@github.com>

On Mon, 9 Dec 2024 15:26:00 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I also meant to note that there are updates to binaries, src/java.base/share/classes/jdk/internal/icu/impl/data/icudt76b/... which maybe isn't intentional, or I just don't understand?

That was certainly not intentional! I'm not sure how that happened, I need to look at my copyright update script again...

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528425161

From ihse at openjdk.org  Mon Dec  9 15:48:38 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 15:48:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
Message-ID: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>

On Mon, 9 Dec 2024 15:16:10 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.

I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?

The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528451279

From joehw at openjdk.org  Mon Dec  9 17:44:40 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 17:44:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <mu_rEJuYYxO7juUhV0qSjwkgt7XFhpnwddzS_bRgYcU=.fcc039a4-77c9-445a-9874-b934abeaefeb@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

The git query found all those java.xml properties files likely due to the jcheck change (JDK-8325558) you made. That patch correctly kept the copyright years as they were since we generally don't change copyright year unless the change is significant.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2528864312

From joehw at openjdk.org  Mon Dec  9 19:53:38 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 9 Dec 2024 19:53:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <xsjhXJx2YAuLVr-ryIB6HgQo5pFQbbT5gwORtR-PwrI=.fc98b8c8-a0a7-4bd4-ab1e-1e42eed6b17f@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by joehw (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2489899005

From mullan at openjdk.org  Mon Dec  9 20:22:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 9 Dec 2024 20:22:37 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <lXCn1OYDxgZvEIA8zkPNEwV271_hrS4AOtnWHYmAbWk=.fca579b0-1483-4157-8ff5-c7363f62cb86@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

The security related files look fine.

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

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2489994087

From eirbjo at openjdk.org  Mon Dec  9 20:40:37 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 9 Dec 2024 20:40:37 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/favicon.ico line 1:


This file should probably not be included?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22645#discussion_r1876722968

From ihse at openjdk.org  Mon Dec  9 21:02:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:02:03 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Revert mistaken changes to binary file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22645/files
  - new: https://git.openjdk.org/jdk/pull/22645/files/01702dae..edbc3fbb

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

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

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

From ihse at openjdk.org  Mon Dec  9 21:02:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 9 Dec 2024 21:02:03 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <XFdVBCbvENDsRKeUsEO5KeGz9wc_s3IKe9ljxibLTB8=.58247179-46c9-478c-8908-c4a800e4a4c4@github.com>
Message-ID: <QclRpS3TYbQDX84ps89kmFxTvOIDXdp-RrgAtPb3-9w=.5912b974-1011-41dd-9695-bc367b63cc81@github.com>

On Mon, 9 Dec 2024 20:38:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert mistaken changes to binary file
>
> src/jdk.httpserver/share/classes/sun/net/httpserver/simpleserver/resources/favicon.ico line 1:
> 
> 
> This file should probably not be included?

Correct, that is a mistake. Reverted the change now.

My script had a bug which made some binary files be "converted" from CRLF to LF format, making unintended changes. I've verified that there are no more such issues in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22645#discussion_r1876748379

From rriggs at openjdk.org  Mon Dec  9 21:11:40 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 9 Dec 2024 21:11:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v2]
In-Reply-To: <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <n_5G8dPJtj8IFqAZ_i15ly02uy9OxQP9o3dt5LRz4Ek=.e1f67354-ae69-473c-b3b2-3d67b459598d@github.com>
 <prU8FGqD7_3uykFpnLnsDUN5E6Wnd44EUJ3Z0h3WkNU=.c76b3ad2-1997-4dfe-8d46-9392410c99cb@github.com>
 <qXxWJxbNRvYCt4hfOj3NWzihP8_7DFZqwhryKvT1xCw=.6d661efe-ffcd-4b83-9559-e54a2a9a09d4@github.com>
Message-ID: <mDL9FucpxYnDugHN7ibpYO5qP5o1qwhidL0fzZiTuog=.b93210c4-6fed-4f1b-9f4f-46b2673e41bd@github.com>

On Mon, 9 Dec 2024 15:45:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
>
>> That git query isn't correct for all the files in the repo. In particular, the copyrights on third party files are NOT updated uniformly when new versions are applied. In particular, XML files are NOT updated.
> 
> I'm not sure I understand what you mean. Are you saying that I did not update files that should have been updated, or that I updated files that should not have been updated?
> 
> The only 3rd party XML files I know about are the ones in `make/data/cldr`. They have certainly been updated in 2024 from upstream, but they do not carry an Oracle copyright header, so there is nothing there to update.

@magicus My question was about third party (xml) code used from Apache.
Joe's review and approval resolved that question.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2529462025

From jlu at openjdk.org  Mon Dec  9 23:01:39 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 9 Dec 2024 23:01:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <GWjrBdyLJQ9FzJkSm8a68fiVZAVcVljFdJPmdRLTdrc=.3ef6fd4d-ead7-473f-8cf4-98f918711888@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Looked at the i18n changes (src, test, and 3rd party icu files w/ Oracle header) and they look correct to me.

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

Marked as reviewed by jlu (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2490302089

From psadhukhan at openjdk.org  Tue Dec 10 09:33:39 2024
From: psadhukhan at openjdk.org (Prasanta Sadhukhan)
Date: Tue, 10 Dec 2024 09:33:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

not sure why client label is added, no java.desktop/accessibility files are in there

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2530994967

From jkern at openjdk.org  Tue Dec 10 13:48:16 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 10 Dec 2024 13:48:16 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
Message-ID: <OjNWX8bfoQCr7vxPpwznlDgShG76VH1whnWw1tqC3Hg=.3ee88908-f4d3-4c5b-bd88-b437600e5438@github.com>

> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.

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

  use IOUtil.configureBlocking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22633/files
  - new: https://git.openjdk.org/jdk/pull/22633/files/083ad270..2bbca14f

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

  Stats: 16 lines in 3 files changed: 2 ins; 13 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22633/head:pull/22633

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

From jkern at openjdk.org  Tue Dec 10 13:48:16 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 10 Dec 2024 13:48:16 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <7duDdYC7S8hkbBGMcABYjwx7ps7DFtapPptZJt0afbQ=.29d8b53a-f5e3-485a-a19e-e81c888c60ec@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <mifweeLNye3-26ut4_cYDyWvqeCX0gFtFxkwBBmH2Tg=.5df8976d-9d14-4487-8bea-60c13a49500d@github.com>
 <oygf8EFcfAcgdghOq0MaHLRR0rAJa-mxSIkgZ8xULjM=.8d1339a0-784e-4ab6-b08b-77f12af7399c@github.com>
 <7duDdYC7S8hkbBGMcABYjwx7ps7DFtapPptZJt0afbQ=.29d8b53a-f5e3-485a-a19e-e81c888c60ec@github.com>
Message-ID: <zFbkI7BqvwcyrpMBspgCZl5YcYPCo31VeDhUVelUWhE=.86d89632-3c62-420b-a858-44647d51f2c2@github.com>

On Mon, 9 Dec 2024 15:20:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I tried this first, but `IOUtil.configureBlocking(fd, blocking)` needs a `FileDescriptor` object instead of an `int`:
>> `public static native void configureBlocking(FileDescriptor fd, boolean blocking)`
>> And I did not find any public FileDescriptor constructor taking an `int`.
>> I would be happy for any hint to avoid this double implementation of configureBlocking
>
>> I tried this first, but `IOUtil.configureBlocking(fd, blocking)` needs a `FileDescriptor` object instead of an `int`: `public static native void configureBlocking(FileDescriptor fd, boolean blocking)` And I did not find any public FileDescriptor constructor taking an `int`. I would be happy for any hint to avoid this double implementation of configureBlocking
> 
> IOUtil.newFD is there if you need it.

I followed your hint. Please refer to commit 'use IOUtil.configureBlocking'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1878122463

From bpb at openjdk.org  Tue Dec 10 18:06:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Dec 2024 18:06:29 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v2]
In-Reply-To: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
Message-ID: <_NBIIwu7pYyy8eikH-b-hhEmyENSexDDb58i1RR6hZs=.5e8077b0-d546-413e-be1e-b1a1ef9ae09c@github.com>

> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

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

  8345421: Add sub-test for newInputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22525/files
  - new: https://git.openjdk.org/jdk/pull/22525/files/36f872ae..c5f3f8c3

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

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

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

From alanb at openjdk.org  Tue Dec 10 19:53:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Dec 2024 19:53:40 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v2]
In-Reply-To: <_NBIIwu7pYyy8eikH-b-hhEmyENSexDDb58i1RR6hZs=.5e8077b0-d546-413e-be1e-b1a1ef9ae09c@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
 <_NBIIwu7pYyy8eikH-b-hhEmyENSexDDb58i1RR6hZs=.5e8077b0-d546-413e-be1e-b1a1ef9ae09c@github.com>
Message-ID: <uH0MvbFG0kHnIQCBsMNw9r7a2bOJ_WAofelPmirAXWs=.7428f001-e488-4e87-861b-f42c9043f99a@github.com>

On Tue, 10 Dec 2024 18:06:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345421: Add sub-test for newInputStream

test/jdk/java/nio/Buffer/UnmeteredTempBuffers.java line 55:

> 53:             }
> 54:         }  finally {
> 55:             Files.deleteIfExists(file);

I think this can be Files.delete as the file will exist.

test/jdk/java/nio/Buffer/UnmeteredTempBuffers.java line 66:

> 64:             byte[] bytes = new byte[cap];
> 65:             Files.write(file, bytes);
> 66:             InputStream in = Files.newInputStream(file);

I assume this should use try-with-resources.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22525#discussion_r1878738434
PR Review Comment: https://git.openjdk.org/jdk/pull/22525#discussion_r1878738731

From bpb at openjdk.org  Tue Dec 10 20:07:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Dec 2024 20:07:38 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v2]
In-Reply-To: <uH0MvbFG0kHnIQCBsMNw9r7a2bOJ_WAofelPmirAXWs=.7428f001-e488-4e87-861b-f42c9043f99a@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
 <_NBIIwu7pYyy8eikH-b-hhEmyENSexDDb58i1RR6hZs=.5e8077b0-d546-413e-be1e-b1a1ef9ae09c@github.com>
 <uH0MvbFG0kHnIQCBsMNw9r7a2bOJ_WAofelPmirAXWs=.7428f001-e488-4e87-861b-f42c9043f99a@github.com>
Message-ID: <S6YpVMXahqjpBkmBv-na32ZSweZCx9RJxBZvoyJju-I=.96106c49-3e44-494a-92e3-78c0288e3c66@github.com>

On Tue, 10 Dec 2024 19:50:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345421: Add sub-test for newInputStream
>
> test/jdk/java/nio/Buffer/UnmeteredTempBuffers.java line 55:
> 
>> 53:             }
>> 54:         }  finally {
>> 55:             Files.deleteIfExists(file);
> 
> I think this can be Files.delete as the file will exist.

As it's opened with `DELETE_ON_CLOSE` maybe the delete is not even needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22525#discussion_r1878757036

From prr at openjdk.org  Tue Dec 10 21:11:39 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 10 Dec 2024 21:11:39 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <y5MxVqW2c_JJCwWbHTaY6bsutW7nMDH_NjpmXzBCzr0=.c833f43b-6d46-4c90-9a2c-c14521114297@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

> not sure why client label is added, no java.desktop/accessibility files are in there

I was puzzling over that too.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2532895836

From tprinzing at openjdk.org  Tue Dec 10 21:41:18 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 10 Dec 2024 21:41:18 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

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

  requests fixes
  
  - Use IOException.toString() instead of getMessage() in case it's empty
  - Attempts to test connect exceptions may fail due to unexpected
    successful connect.  Tests quit with uncompleted status if the
    connect is successful and are retried a small number of times until
    the test can be performed properly.  If the retries are exceeded an
    exception is generated indicating the test can't be setup properly.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/a379609e..5e55ffc6

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

  Stats: 62 lines in 6 files changed: 43 ins; 3 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From bpb at openjdk.org  Tue Dec 10 22:14:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Dec 2024 22:14:10 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v3]
In-Reply-To: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
Message-ID: <RQZOaZkPahRofpIUoD6F4osJd5mRJCrsKWzp6gOHc3U=.9945a11d-ab40-451d-84fb-f5d51969ef62@github.com>

> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

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

  8345421: use try-with-resources; deleteIfExists -> delete

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22525/files
  - new: https://git.openjdk.org/jdk/pull/22525/files/c5f3f8c3..7a537639

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

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

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

From dholmes at openjdk.org  Wed Dec 11 05:03:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 11 Dec 2024 05:03:40 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
Message-ID: <ojoMiAhvTCH92wf77IgjQsbzdaO_V2zGk3hilJ04sUE=.32475376-0293-4b87-a967-4a92e786963b@github.com>

On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>> 
>> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary file

Looks fine. Thanks.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2494322540

From duke at openjdk.org  Wed Dec 11 05:24:43 2024
From: duke at openjdk.org (duke)
Date: Wed, 11 Dec 2024 05:24:43 GMT
Subject: Withdrawn: 8341944: The zlib library no longer requires dummy byte for
 raw inflate
In-Reply-To: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
References: <OzyvCSMdWDVzBlk5EpwMTNw0TSxcRbnX1s7fq5iQUOQ=.5501f390-3d33-4a40-b792-3eccbcf9ecdb@github.com>
Message-ID: <oIzOAV8exIwsg-QIDCg8N70hMAEWasyNgSxHAAa7uTA=.213d4929-7b77-4ac7-920c-e9a47a91c272@github.com>

On Fri, 11 Oct 2024 08:11:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this cleanup PR which removes overrides of `InflaterInputStream.fill` in `ZipFileInflaterInputStream` and `ZipFileSystem::getInputStream`. Associated boolean fields used to track `eof` are also removed.
> 
> These overrides exist to provide zlib with an extra dummy byte at the end of raw compressed streams (no wrapping):
> 
> 
> // Override fill() method to provide an extra "dummy" byte
> // at the end of the input stream. This is required when
> // using the "nowrap" Inflater option.
> protected void fill() throws IOException {
> 
> However, zlib has not required such an extra dummy byte since 2003. 
> 
> 
> Changes in 1.2.0 (9 March 2003)
> - New and improved inflate code
>     - Raw inflate no longer needs an extra dummy byte at end
> ``` 
> 
> The code in these overrides is effectively dead and removing it cleans up our code and reclaims weirdness dollars for our budget.
> 
> Risk: I cannot imagine anyone is building OpenJDK with a 21 year old ZLIB.  Please advise if this is the case or if any zlib fork in use still has this limitation.
> 
> Testing: ZIP and ZIPFS tests run green locally. GHA also green. No tests are added or modified, this is a cleanup-only PR. Manually verified that the code is dead by injecting AssertionErrors.

This pull request has been closed without being integrated.

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

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

From alanb at openjdk.org  Wed Dec 11 06:59:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Dec 2024 06:59:38 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v3]
In-Reply-To: <RQZOaZkPahRofpIUoD6F4osJd5mRJCrsKWzp6gOHc3U=.9945a11d-ab40-451d-84fb-f5d51969ef62@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
 <RQZOaZkPahRofpIUoD6F4osJd5mRJCrsKWzp6gOHc3U=.9945a11d-ab40-451d-84fb-f5d51969ef62@github.com>
Message-ID: <tSPtRULuTuboKAX60cGZ1JdEPNumGsNnGbNJ5EVen3o=.88cfa07b-e63b-4c7f-961b-91a325283c02@github.com>

On Tue, 10 Dec 2024 22:14:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345421: use try-with-resources; deleteIfExists -> delete

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22525#pullrequestreview-2494471215

From alanb at openjdk.org  Wed Dec 11 06:59:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 11 Dec 2024 06:59:39 GMT
Subject: RFR: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit [v2]
In-Reply-To: <S6YpVMXahqjpBkmBv-na32ZSweZCx9RJxBZvoyJju-I=.96106c49-3e44-494a-92e3-78c0288e3c66@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
 <_NBIIwu7pYyy8eikH-b-hhEmyENSexDDb58i1RR6hZs=.5e8077b0-d546-413e-be1e-b1a1ef9ae09c@github.com>
 <uH0MvbFG0kHnIQCBsMNw9r7a2bOJ_WAofelPmirAXWs=.7428f001-e488-4e87-861b-f42c9043f99a@github.com>
 <S6YpVMXahqjpBkmBv-na32ZSweZCx9RJxBZvoyJju-I=.96106c49-3e44-494a-92e3-78c0288e3c66@github.com>
Message-ID: <tTpFQCpcdW24qRF-xebiaQLkI-TPDpUYOVqQevKR-qY=.f4db8fa6-ad26-42d9-a048-8ef614cf9ebd@github.com>

On Tue, 10 Dec 2024 20:05:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/Buffer/UnmeteredTempBuffers.java line 55:
>> 
>>> 53:             }
>>> 54:         }  finally {
>>> 55:             Files.deleteIfExists(file);
>> 
>> I think this can be Files.delete as the file will exist.
>
> As it's opened with `DELETE_ON_CLOSE` maybe the delete is not even needed.

Just a bit surprising to see it in this test, but okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22525#discussion_r1879445767

From mli at openjdk.org  Wed Dec 11 09:34:39 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:34:39 GMT
Subject: RFR: 8345805: Update copyright year to 2024 for other files where
 it was missed [v2]
In-Reply-To: <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
 <ErfONEIQ04pTtIZ16WyUAYYjlVlwDX5SyrFK8938974=.b1d9c4a1-267b-47d3-9777-7b95043653ce@github.com>
Message-ID: <7Bia437IpuiRbqBsYiwM2WQIAAxn0bTbUuRNNw1LNTw=.d8ce64de-67ad-4f6c-ba28-81571b5b2f68@github.com>

On Mon, 9 Dec 2024 21:02:03 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>> 
>> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert mistaken changes to binary file

Nice batch cleanup!

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22645#pullrequestreview-2494911355

From mli at openjdk.org  Wed Dec 11 09:40:38 2024
From: mli at openjdk.org (Hamlin Li)
Date: Wed, 11 Dec 2024 09:40:38 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <tvt6RZcQwnigoiXNxV7oGeyYq0BSns6TkNEXDsBKiJw=.8e107751-d6c5-4630-8670-c832bc24b973@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Nice batch cleanup.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2494928848

From ihse at openjdk.org  Wed Dec 11 10:41:43 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 10:41:43 GMT
Subject: Integrated: 8345805: Update copyright year to 2024 for other files
 where it was missed
In-Reply-To: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
References: <Y1pHHQ_3rFthlMkdXld3sz9m-6erwIYm1mR3JPSg8xI=.68f59524-aa13-466c-ab84-4a9311f6dc3d@github.com>
Message-ID: <B1VOMT0QB3nHgSvFhmdcK6A-fMRTPmOsLW-eg-Wnz64=.e713db53-1cd1-481a-a882-afa18a97ec61@github.com>

On Mon, 9 Dec 2024 13:02:15 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
> 
> This is a "misc" bucket bug report, covering for all those files that has not been clearly assigned in some other issue. My strategy was to update the copyright year on all files in the JDK repo, and then try to the best of my ability to partition that huge chunk of files between groups. These are the remainder after I've done the large chunks. When you review, please state clearly what part of the code you are reviewing.

This pull request has now been integrated.

Changeset: 8e0f929e
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e0f929ecfc1d8de1c2a78e608bcabc45ff6b6af
Stats:     107 lines in 107 files changed: 0 ins; 0 del; 107 mod

8345805: Update copyright year to 2024 for other files where it was missed

Reviewed-by: dholmes, mli, mullan

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

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

From lancea at openjdk.org  Wed Dec 11 11:41:40 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 11 Dec 2024 11:41:40 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
Message-ID: <SnUMv7eXNRQU7c9T4Bi3BQkxaesNNYM1VxK3mY7ABJc=.102d4905-e86c-445e-8e31-e60a1a45249c@github.com>

On Mon, 9 Dec 2024 15:42:57 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
>> 
>> I have located these modified files using:
>> 
>> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
>> 
>> and then run a script to update the copyright year to 2024 on these files.
>> 
>> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert changes to binary files

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22640#pullrequestreview-2495330243

From bpb at openjdk.org  Wed Dec 11 18:02:18 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Dec 2024 18:02:18 GMT
Subject: Integrated: 8345421: (bf) Create specific test for temporary direct
 buffers and the buffer size limit
In-Reply-To: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
References: <dqQ08ySpGjAePhvZsuSL-Z4ag42VbtTn-PUdUvLQMz0=.9496a368-b321-4002-be5f-7096398d6cda@github.com>
Message-ID: <Oah-qVgDsLmPMEkQiiGEiDRvTHOgX9d_RHM_WxVLFhk=.340a2efa-785a-4c09-ae04-c10df46d224c@github.com>

On Tue, 3 Dec 2024 19:57:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a specific test for [JDK-8344882](https://bugs.openjdk.org/browse/JDK-8344882).

This pull request has now been integrated.

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

8345421: (bf) Create specific test for temporary direct buffers and the buffer size limit

Reviewed-by: alanb

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

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

From ihse at openjdk.org  Wed Dec 11 21:10:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:52 GMT
Subject: RFR: 8345799: Update copyright year to 2024 for core-libs in files
 where it was missed [v3]
In-Reply-To: <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
 <waZLxMZsHHF2vNEcHIEWemFnWeCIbHHYmW_lu8J3CAk=.0f2b5de6-b86d-4af8-a146-aeb5c83aabd1@github.com>
 <0IesHKVS6gy8WPLSFCevvtbtchywwafjo_iChBhuvds=.b02be63c-a28f-47a8-80d3-8293993d9c15@github.com>
Message-ID: <m7oETe1RAtaoT1NyVmjhpbwEWCluWGDzOMgGKjgE-FU=.d15b5616-c416-47aa-89f5-c816d893f45e@github.com>

On Tue, 10 Dec 2024 09:31:21 GMT, Prasanta Sadhukhan <psadhukhan at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert changes to binary files
>
> not sure why client label is added, no java.desktop/accessibility files are in there

@prsadhuk @prrace `src/java.base/share/classes/jdk/internal/access/JavaAWTFontAccess.java` matches the pattern `"src/java.base/share/classes/jdk/internal/access/\\w+AWT"` which is setup for `client` in the Skara `jdk.json` label configuration.

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

PR Comment: https://git.openjdk.org/jdk/pull/22640#issuecomment-2537183864

From ihse at openjdk.org  Wed Dec 11 21:10:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Dec 2024 21:10:53 GMT
Subject: Integrated: 8345799: Update copyright year to 2024 for core-libs in
 files where it was missed
In-Reply-To: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
References: <HIlrlxPCx9fqeFmSDa-Jr3OYZVyz281dcc9klaRPK-Y=.da636218-fb0e-40b8-956d-c9c68064eb16@github.com>
Message-ID: <kZZWqqQs4ZIlaEEhWti7W4jqwB76v78dWz7Tk-kTzHE=.8da2847d-ec74-4fe4-b28e-e7c9a7b308b8@github.com>

On Mon, 9 Dec 2024 12:30:19 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Some files have been modified in 2024, but the copyright year has not been properly updated. This should be fixed. 
> 
> I have located these modified files using:
> 
> git log --since="Jan 1" --name-only --pretty=format: | sort -u > file.list
> 
> and then run a script to update the copyright year to 2024 on these files.
> 
> I have made a manual sampling of files in the list to verify that they have indeed been modified in 2024.

This pull request has now been integrated.

Changeset: ddf04617
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ddf04617887dc389cd7667e820da7ac91eea9e8c
Stats:     441 lines in 441 files changed: 0 ins; 0 del; 441 mod

8345799: Update copyright year to 2024 for core-libs in files where it was missed

Reviewed-by: joehw, jlu, mli, lancea, kevinw

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

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

From bpb at openjdk.org  Thu Dec 12 02:38:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 02:38:14 GMT
Subject: RFR: 8345432: (ch, fs) Replace anonymous Thread with InnocuousThread
Message-ID: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>

Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

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

Commit messages:
 - 8345432: (ch, fs) Replace anonymous Thread with InnocuousThread

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

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

From bpb at openjdk.org  Thu Dec 12 02:38:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 02:38:14 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
Message-ID: <2x8FxiHKThy-p6qBN1-IklKVxl2-j6UrqpHB54dFgkk=.0b06a6e0-dbe0-4e2c-9278-5bebce6f751c@github.com>

On Thu, 12 Dec 2024 02:33:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

The loopback connector thread in the Windows version of `PipeImpl` still uses an anonymous thread as it overrides `interrupt()` to do nothing.

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

PR Comment: https://git.openjdk.org/jdk/pull/22697#issuecomment-2537661176

From egahlin at openjdk.org  Thu Dec 12 04:01:37 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 12 Dec 2024 04:01:37 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
 <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz
 5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
Message-ID: <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>

On Wed, 4 Dec 2024 12:26:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We could have two views with only one event. The query for the view could filter for exceptionMessage != null or a failure property. The advantage of having two events is that the failure event could have a threshold of 0 ms.
>> 
>> We are planning to add a throttling mechanism for exception events, perhaps per call site. The same mechanism could be used for a failed event. If you receive 500 events per second for a call site, there is little value in having additional events.
>
> We need to help Tim on the question of whether there is one or two events. 
> 
> An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.
> 
> When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?

I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881347326

From alanb at openjdk.org  Thu Dec 12 07:37:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Dec 2024 07:37:39 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
Message-ID: <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>

On Thu, 12 Dec 2024 02:33:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 73:

> 71:     static ThreadFactory defaultThreadFactory() {
> 72:         return (Runnable r) -> {
> 73:             Thread t = InnocuousThread.newThread(r);

This change is observable as the threads in this thread pool execute user code. I can't imagine anything really wanting to rely on the undocumented inheritance but it's possible so we'll need to create a CSR for this.

src/java.base/share/classes/sun/nio/fs/Cancellable.java line 121:

> 119:      */
> 120:     static void runInterruptibly(Cancellable task) throws ExecutionException {
> 121:         Thread t = InnocuousThread.newThread("NIO-Task", task);

"NIO-Task" doesn't make sense as the thread name here, something like "CancellableOp" is closer to what it really is.

As you are there, the javadoc link to runInterruptibly is missing the "#", maybe we can fix this while we are here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1881522808
PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1881520211

From dfuchs at openjdk.org  Thu Dec 12 09:51:46 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Dec 2024 09:51:46 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
Message-ID: <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>

On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requests fixes
>   
>   - Use IOException.toString() instead of getMessage() in case it's empty
>   - Attempts to test connect exceptions may fail due to unexpected
>     successful connect.  Tests quit with uncompleted status if the
>     connect is successful and are retried a small number of times until
>     the test can be performed properly.  If the retries are exceeded an
>     exception is generated indicating the test can't be setup properly.

test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 154:

> 152:                     s.connect(addr);
> 153:                     // unexpected, abandon the test
> 154:                     return false;

The main issue with using the ephemeral port range is that you might manage to connect to a server opened by another test, and that might cause the other test to fail if it's not expecting connections to get closed.

If instead you use ports in the IANA reserved port range - at least you know that you won't connect to other tests running on the same machine.

Have you tried to connect to port 225 for instance, and increase the port number up to 241 in case you still manage to connect?

Ports 225-241 are reserved by IANA - so there should be nobody listening there. I had some trouble on windows 2016 with port 47, but hopefully ports 225-241 will not have the same issue.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881736555

From dfuchs at openjdk.org  Thu Dec 12 10:04:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 12 Dec 2024 10:04:41 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
Message-ID: <9Ra2WGQHgeLba87NCCurerM96SaLNYZrCH_cM5ERI0w=.d966c2d0-5314-43de-b01c-bc4f7bf48c30@github.com>

On Tue, 10 Dec 2024 21:41:18 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   requests fixes
>   
>   - Use IOException.toString() instead of getMessage() in case it's empty
>   - Attempts to test connect exceptions may fail due to unexpected
>     successful connect.  Tests quit with uncompleted status if the
>     connect is successful and are retried a small number of times until
>     the test can be performed properly.  If the retries are exceeded an
>     exception is generated indicating the test can't be setup properly.

src/java.base/share/classes/jdk/internal/event/SocketConnectFailedEvent.java line 117:

> 115:         long duration = timestamp() - start;
> 116:         if (shouldCommit(duration)) {
> 117:             String msg = connectEx.toString();

Should the description for this field in the event be updated too?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1881757052

From bpb at openjdk.org  Thu Dec 12 16:33:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 16:33:36 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <2x8FxiHKThy-p6qBN1-IklKVxl2-j6UrqpHB54dFgkk=.0b06a6e0-dbe0-4e2c-9278-5bebce6f751c@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <2x8FxiHKThy-p6qBN1-IklKVxl2-j6UrqpHB54dFgkk=.0b06a6e0-dbe0-4e2c-9278-5bebce6f751c@github.com>
Message-ID: <Bl5zAZSRBJPfqS5L5hNWGuXjFpthbtkKpCyrGpBAM-4=.decd2cad-ff00-47db-9629-29aa3742c62f@github.com>

On Thu, 12 Dec 2024 02:34:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The loopback connector thread in the Windows version of `PipeImpl` still uses an anonymous thread as it overrides `interrupt()` to do nothing.

@AlanBateman , do you have any comment on this?

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

PR Comment: https://git.openjdk.org/jdk/pull/22697#issuecomment-2539440610

From bpb at openjdk.org  Thu Dec 12 16:33:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 16:33:38 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>
Message-ID: <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>

On Thu, 12 Dec 2024 07:35:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.
>
> src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 73:
> 
>> 71:     static ThreadFactory defaultThreadFactory() {
>> 72:         return (Runnable r) -> {
>> 73:             Thread t = InnocuousThread.newThread(r);
> 
> This change is observable as the threads in this thread pool execute user code. I can't imagine anything really wanting to rely on the undocumented inheritance but it's possible so we'll need to create a CSR for this.

Okay, I will create a CSR.

> src/java.base/share/classes/sun/nio/fs/Cancellable.java line 121:
> 
>> 119:      */
>> 120:     static void runInterruptibly(Cancellable task) throws ExecutionException {
>> 121:         Thread t = InnocuousThread.newThread("NIO-Task", task);
> 
> "NIO-Task" doesn't make sense as the thread name here, something like "CancellableOp" is closer to what it really is.
> 
> As you are there, the javadoc link to runInterruptibly is missing the "#", maybe we can fix this while we are here.

I just left the name as it was but will change it as suggested and fix the link.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1882486273
PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1882485695

From bpb at openjdk.org  Thu Dec 12 16:45:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 16:45:12 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v2]
In-Reply-To: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
Message-ID: <WZKmlnHSALA5meNRQum0Ys98ZQSIgT8CZnIgF97yPcg=.3a679a4c-a518-4bda-993a-3e4d2f78c03b@github.com>

> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

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

  8345432: Change thread name; fix broken doc link

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22697/files
  - new: https://git.openjdk.org/jdk/pull/22697/files/01dad84b..7a421c1d

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

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

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

From bpb at openjdk.org  Thu Dec 12 16:45:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 16:45:12 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v2]
In-Reply-To: <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>
 <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>
Message-ID: <ZTrQyeEhFd6mWPj1D0mx8qMNzquMA_-ZxJ9fxVMr5Ik=.2f2b7da9-ada0-41b8-a855-a344c1763279@github.com>

On Thu, 12 Dec 2024 16:29:42 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/fs/Cancellable.java line 121:
>> 
>>> 119:      */
>>> 120:     static void runInterruptibly(Cancellable task) throws ExecutionException {
>>> 121:         Thread t = InnocuousThread.newThread("NIO-Task", task);
>> 
>> "NIO-Task" doesn't make sense as the thread name here, something like "CancellableOp" is closer to what it really is.
>> 
>> As you are there, the javadoc link to runInterruptibly is missing the "#", maybe we can fix this while we are here.
>
> I just left the name as it was but will change it as suggested and fix the link.

Changed in 7a421c1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1882506841

From alanb at openjdk.org  Thu Dec 12 16:48:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Dec 2024 16:48:36 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <Bl5zAZSRBJPfqS5L5hNWGuXjFpthbtkKpCyrGpBAM-4=.decd2cad-ff00-47db-9629-29aa3742c62f@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <2x8FxiHKThy-p6qBN1-IklKVxl2-j6UrqpHB54dFgkk=.0b06a6e0-dbe0-4e2c-9278-5bebce6f751c@github.com>
 <Bl5zAZSRBJPfqS5L5hNWGuXjFpthbtkKpCyrGpBAM-4=.decd2cad-ff00-47db-9629-29aa3742c62f@github.com>
Message-ID: <FGQhtOEdNVPqMBIyNNeTGmr956j09vlTFcsUtfq7i4w=.03759d69-ed32-4507-b913-79ffd89ac635@github.com>

On Thu, 12 Dec 2024 16:31:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > The loopback connector thread in the Windows version of `PipeImpl` still uses an anonymous thread as it overrides `interrupt()` to do nothing.
> 
> @AlanBateman , do you have any comment on this?

It's short lived so any inheritance isn't going to cause memory to be retained. On balance, it's probably best to convert this one while you are in the area, avoids questions in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/22697#issuecomment-2539474753

From bpb at openjdk.org  Thu Dec 12 17:10:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 17:10:38 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread
In-Reply-To: <FGQhtOEdNVPqMBIyNNeTGmr956j09vlTFcsUtfq7i4w=.03759d69-ed32-4507-b913-79ffd89ac635@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <2x8FxiHKThy-p6qBN1-IklKVxl2-j6UrqpHB54dFgkk=.0b06a6e0-dbe0-4e2c-9278-5bebce6f751c@github.com>
 <Bl5zAZSRBJPfqS5L5hNWGuXjFpthbtkKpCyrGpBAM-4=.decd2cad-ff00-47db-9629-29aa3742c62f@github.com>
 <FGQhtOEdNVPqMBIyNNeTGmr956j09vlTFcsUtfq7i4w=.03759d69-ed32-4507-b913-79ffd89ac635@github.com>
Message-ID: <9AhpyKWdVXWQ_fRu334o0T9pJ7MUpmi9flZ_DUUmjHY=.47683b47-51a2-4388-a64b-02c09b548139@github.com>

On Thu, 12 Dec 2024 16:46:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On balance, it's probably best to convert this one while you are in the area, avoids questions in the future.

It is not clear how to deal with `interrupt()` here as `InnocuousThread` is final. Something like

private boolean isInterruptible;

public void interrupt() {
    if (isInterruptible)
        super.interrupt();
}

does not seem like a good idea.

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

PR Comment: https://git.openjdk.org/jdk/pull/22697#issuecomment-2539530967

From bpb at openjdk.org  Thu Dec 12 19:04:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Dec 2024 19:04:39 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v2]
In-Reply-To: <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>
 <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>
Message-ID: <C6fELoeI4iuw7gGg2vYpfovy17oD3uyANOGjnKK3V5o=.7888241c-fdce-44df-b42d-9ad688d34670@github.com>

On Thu, 12 Dec 2024 16:30:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/ThreadPool.java line 73:
>> 
>>> 71:     static ThreadFactory defaultThreadFactory() {
>>> 72:         return (Runnable r) -> {
>>> 73:             Thread t = InnocuousThread.newThread(r);
>> 
>> This change is observable as the threads in this thread pool execute user code. I can't imagine anything really wanting to rely on the undocumented inheritance but it's possible so we'll need to create a CSR for this.
>
> Okay, I will create a CSR.

[CSR](https://bugs.openjdk.org/browse/JDK-8346124) filed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1882731461

From mdoerr at openjdk.org  Mon Dec 16 14:24:39 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 16 Dec 2024 14:24:39 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <OjNWX8bfoQCr7vxPpwznlDgShG76VH1whnWw1tqC3Hg=.3ee88908-f4d3-4c5b-bd88-b437600e5438@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <OjNWX8bfoQCr7vxPpwznlDgShG76VH1whnWw1tqC3Hg=.3ee88908-f4d3-4c5b-bd88-b437600e5438@github.com>
Message-ID: <eJyWbsLkHqIo1theb9hcB50ncJG8joJKls_AMsYj_Ic=.d4368902-cf2c-4fb2-8f54-a715ce02f7ad@github.com>

On Tue, 10 Dec 2024 13:48:16 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>> 
>> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
>> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
>> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use IOUtil.configureBlocking

Looks reasonable. I have a couple of questions and suggestions.

src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 32:

> 30: import sun.nio.ch.Pollset;
> 31: import sun.nio.ch.IOUtil;
> 32: import java.io.FileDescriptor;

Imports are typically sorted alphabetically.

src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 310:

> 308:             try {
> 309:                 for (;;) {
> 310:                     int n, m;

I'd declare `m` in the `try` block. It's not used outside of it.

src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 322:

> 320:                             // the file descriptor here.
> 321:                             if (fd != sp[0] && fd != ctlSp[0]) {
> 322:                                 synchronized (controlQueue) {

Ok, the lock order `controlLock` before `controlQueue` seems to be consistent. Otherwise, we might get deadlocks. (Exception is `controlLock.tryLock()` which is ok.)
Shouldn't `synchronized (controlQueue)` better get removed from `processControlQueue()`? The lock has always been acquired before it is called. If it didn't, it would make the lock order inconsistent and possibly cause deadlocks.

src/java.base/aix/native/libnio/ch/Pollset.c line 170:

> 168: 
> 169:     for (;;) {
> 170:         int n = read(fd, buf, sizeof(buf));

Shouldn't we handle `errno == EINTR`? Other code uses `RESTARTABLE`.

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

PR Review: https://git.openjdk.org/jdk/pull/22633#pullrequestreview-2506278053
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1886871594
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1886872793
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1886887817
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1886896261

From alanb at openjdk.org  Mon Dec 16 16:05:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 16 Dec 2024 16:05:38 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v2]
In-Reply-To: <C6fELoeI4iuw7gGg2vYpfovy17oD3uyANOGjnKK3V5o=.7888241c-fdce-44df-b42d-9ad688d34670@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <i7nRoqPY37UC6Xh5gEJVtmu7Yb-G_-BqL4SxGj3oq4s=.857fa803-5045-4336-8a68-326a60ed69d0@github.com>
 <mvDfta-A5E07QdmNXN8tOazuZRXcfVqfr95RpRom7U0=.9ac61eca-3b94-4991-af30-88ee5efc8f0f@github.com>
 <C6fELoeI4iuw7gGg2vYpfovy17oD3uyANOGjnKK3V5o=.7888241c-fdce-44df-b42d-9ad688d34670@github.com>
Message-ID: <pBvPXNZ629WinzJkRf33_vuMyVzSUa4xCp7DGpwUr6s=.6ede39fa-a17e-49f9-80eb-b2c9713af87e@github.com>

On Thu, 12 Dec 2024 19:02:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Okay, I will create a CSR.
>
> [CSR](https://bugs.openjdk.org/browse/JDK-8346124) filed.

I tweaked the CSR wording to make it clear that this is about inheritance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1887086897

From tprinzing at openjdk.org  Mon Dec 16 20:24:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 16 Dec 2024 20:24:20 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v9]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

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

  Refactored connect exception tests to a single IOHelper method
  that takes a function argument that is excpected to produce the
  appropriate exception.  IANA reserved ports in the range 225 to
  241 are used to attempt to produce a connect exception.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/5e55ffc6..81cea489

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

  Stats: 206 lines in 4 files changed: 54 ins; 114 del; 38 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From tprinzing at openjdk.org  Mon Dec 16 20:24:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 16 Dec 2024 20:24:20 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v8]
In-Reply-To: <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <aKhpxrEDhRUpuaEk4rUGVleeFwJfQeaBYoUvpLJSEt0=.052613e3-4b20-4abb-9c50-a8565f7e3be1@github.com>
 <tkQNsDYyvNlxFm_7izZHDHa4PxBsUb4YIPqcEwlbJVw=.c6246c91-b32f-4b75-bb17-71c97ddcbde6@github.com>
Message-ID: <NvNkIKEUiGbSTDZJ_pqoSbMj3CxZBRQPhkwpKW8ozak=.326c8842-5fd1-464a-b544-11798baa2b1b@github.com>

On Thu, 12 Dec 2024 09:48:45 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   requests fixes
>>   
>>   - Use IOException.toString() instead of getMessage() in case it's empty
>>   - Attempts to test connect exceptions may fail due to unexpected
>>     successful connect.  Tests quit with uncompleted status if the
>>     connect is successful and are retried a small number of times until
>>     the test can be performed properly.  If the retries are exceeded an
>>     exception is generated indicating the test can't be setup properly.
>
> test/jdk/jdk/jfr/event/io/TestSocketAdapterEvents.java line 154:
> 
>> 152:                     s.connect(addr);
>> 153:                     // unexpected, abandon the test
>> 154:                     return false;
> 
> The main issue with using the ephemeral port range is that you might manage to connect to a server opened by another test, and that might cause the other test to fail if it's not expecting connections to get closed.
> 
> If instead you use ports in the IANA reserved port range - at least you know that you won't connect to other tests running on the same machine.
> 
> Have you tried to connect to port 225 for instance, and increase the port number up to 241 in case you still manage to connect?
> 
> Ports 225-241 are reserved by IANA - so there should be nobody listening there. I had some trouble on windows 2016 with port 47, but hopefully ports 225-241 will not have the same issue.

I've changed the exception tests to use the port range you suggested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1887538817

From bpb at openjdk.org  Tue Dec 17 00:57:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 00:57:22 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v3]
In-Reply-To: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
Message-ID: <SgPGEo3nXxu74-kS4iZk6Ib52qlWYe-xGRG2Az8eYh8=.478195a9-ba01-4e17-b1f8-a499bf89d665@github.com>

> Improve support for Windows directory junctions.

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

 - Merge
 - 8069345: Add os.family == windows to tests
 - 8069345: (fs) FileTreeWalker throws NotDirectoryException on file junction points

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21555/files
  - new: https://git.openjdk.org/jdk/pull/21555/files/7d9067f3..deca8f8e

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

  Stats: 586412 lines in 9415 files changed: 318885 ins; 214759 del; 52768 mod
  Patch: https://git.openjdk.org/jdk/pull/21555.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21555/head:pull/21555

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

From bpb at openjdk.org  Tue Dec 17 01:03:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 01:03:12 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v3]
In-Reply-To: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
Message-ID: <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>

> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

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

  8345432: Add uninterruptible InnocuousThread for Windows PipeImpl

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22697/files
  - new: https://git.openjdk.org/jdk/pull/22697/files/7a421c1d..aa5bb8a1

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

  Stats: 32 lines in 2 files changed: 22 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22697/head:pull/22697

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

From bpb at openjdk.org  Tue Dec 17 01:03:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 01:03:12 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v2]
In-Reply-To: <WZKmlnHSALA5meNRQum0Ys98ZQSIgT8CZnIgF97yPcg=.3a679a4c-a518-4bda-993a-3e4d2f78c03b@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <WZKmlnHSALA5meNRQum0Ys98ZQSIgT8CZnIgF97yPcg=.3a679a4c-a518-4bda-993a-3e4d2f78c03b@github.com>
Message-ID: <DfweQLPMCXiZbs11JvbZ8Kf8pOUip7F0gMf5grI78_g=.30273174-288c-43e7-985c-65ae73f909e3@github.com>

On Thu, 12 Dec 2024 16:45:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345432: Change thread name; fix broken doc link

It's unclear to me whether the number of changes in aa5bb8a is worthwhile for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22697#issuecomment-2547278751

From alanb at openjdk.org  Tue Dec 17 07:43:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Dec 2024 07:43:43 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v3]
In-Reply-To: <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>
Message-ID: <g9S5JSc-nLmW8Zad5CsSvd42GbvOK9FaodRiBvUeO-M=.7286d011-1993-435f-8de9-b1bcdca14bf8@github.com>

On Tue, 17 Dec 2024 01:03:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345432: Add uninterruptible InnocuousThread for Windows PipeImpl

src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 64:

> 62:         return createThread(newName(), target, 0L,
> 63:                 ClassLoader.getSystemClassLoader(), -1, true);
> 64:     }

I think this is just a bit weird to have this in InnocuousThread. I think we should look for alternatives for PipeImpl so leave it out of this PR as it's benign if it inherits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1888033316

From alanb at openjdk.org  Tue Dec 17 08:04:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Dec 2024 08:04:53 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v3]
In-Reply-To: <SgPGEo3nXxu74-kS4iZk6Ib52qlWYe-xGRG2Az8eYh8=.478195a9-ba01-4e17-b1f8-a499bf89d665@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <SgPGEo3nXxu74-kS4iZk6Ib52qlWYe-xGRG2Az8eYh8=.478195a9-ba01-4e17-b1f8-a499bf89d665@github.com>
Message-ID: <XVemsFPZ_G5dia9xcjU9Vu1v2PfA_byihdNGFvVSL-k=.69546285-3945-45b2-b086-57323dc5a4f3@github.com>

On Tue, 17 Dec 2024 00:57:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve support for Windows directory junctions.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge
>  - 8069345: Add os.family == windows to tests
>  - 8069345: (fs) FileTreeWalker throws NotDirectoryException on file junction points

I realize you've added a comment to continue to this PR but I think is going to require significant effort to audit just about every scenario to work through potential inconsistencies. It's not clear it's worth doing it at this time.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2547740132

From jkern at openjdk.org  Tue Dec 17 08:54:26 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 17 Dec 2024 08:54:26 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v3]
In-Reply-To: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
Message-ID: <P2eG96d_LqeNnzrmqc0HPOXOteU66iCTBuD4eX3J0Nw=.f41be35c-c8dd-45e7-b44e-a4edc3509b3b@github.com>

> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
> 
> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.

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

  following the suggestions of Martin

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22633/files
  - new: https://git.openjdk.org/jdk/pull/22633/files/2bbca14f..db44c94b

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

  Stats: 48 lines in 3 files changed: 7 ins; 26 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/22633.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22633/head:pull/22633

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

From jkern at openjdk.org  Tue Dec 17 08:54:27 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 17 Dec 2024 08:54:27 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v2]
In-Reply-To: <eJyWbsLkHqIo1theb9hcB50ncJG8joJKls_AMsYj_Ic=.d4368902-cf2c-4fb2-8f54-a715ce02f7ad@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <OjNWX8bfoQCr7vxPpwznlDgShG76VH1whnWw1tqC3Hg=.3ee88908-f4d3-4c5b-bd88-b437600e5438@github.com>
 <eJyWbsLkHqIo1theb9hcB50ncJG8joJKls_AMsYj_Ic=.d4368902-cf2c-4fb2-8f54-a715ce02f7ad@github.com>
Message-ID: <XRgSPzp3hTyyKTcJqZePFG_vIQD3fydSOrTm8XQsLQM=.51723775-06d6-41d1-ab81-c1ae8fc90a49@github.com>

On Mon, 16 Dec 2024 14:02:21 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

>> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use IOUtil.configureBlocking
>
> src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 32:
> 
>> 30: import sun.nio.ch.Pollset;
>> 31: import sun.nio.ch.IOUtil;
>> 32: import java.io.FileDescriptor;
> 
> Imports are typically sorted alphabetically.

Done

> src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 310:
> 
>> 308:             try {
>> 309:                 for (;;) {
>> 310:                     int n, m;
> 
> I'd declare `m` in the `try` block. It's not used outside of it.

Done

> src/java.base/aix/classes/sun/nio/ch/AixPollPort.java line 322:
> 
>> 320:                             // the file descriptor here.
>> 321:                             if (fd != sp[0] && fd != ctlSp[0]) {
>> 322:                                 synchronized (controlQueue) {
> 
> Ok, the lock order `controlLock` before `controlQueue` seems to be consistent. Otherwise, we might get deadlocks. (Exception is `controlLock.tryLock()` which is ok.)
> Shouldn't `synchronized (controlQueue)` better get removed from `processControlQueue()`? The lock has always been acquired before it is called. If it didn't, it would make the lock order inconsistent and possibly cause deadlocks.

Removed the additional` synchronized (controlQueue)` from `processControlQueue()`

> src/java.base/aix/native/libnio/ch/Pollset.c line 170:
> 
>> 168: 
>> 169:     for (;;) {
>> 170:         int n = read(fd, buf, sizeof(buf));
> 
> Shouldn't we handle `errno == EINTR`? Other code uses `RESTARTABLE`.

removed own implementation of `drain()` and use the IOUtil version instead.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1888122978
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1888123236
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1888124420
PR Review Comment: https://git.openjdk.org/jdk/pull/22633#discussion_r1888125816

From mdoerr at openjdk.org  Tue Dec 17 10:47:36 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 17 Dec 2024 10:47:36 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v3]
In-Reply-To: <P2eG96d_LqeNnzrmqc0HPOXOteU66iCTBuD4eX3J0Nw=.f41be35c-c8dd-45e7-b44e-a4edc3509b3b@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <P2eG96d_LqeNnzrmqc0HPOXOteU66iCTBuD4eX3J0Nw=.f41be35c-c8dd-45e7-b44e-a4edc3509b3b@github.com>
Message-ID: <UrRBy0UdnClOdg0OOfCn1EtyUf9HxlLDvzCbYzy6iGg=.c0222dbe-113b-44bf-8aa1-13ed8af9c5a9@github.com>

On Tue, 17 Dec 2024 08:54:26 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>> 
>> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
>> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
>> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   following the suggestions of Martin

LGTM. Thanks! Please update the Copyright header!

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

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22633#pullrequestreview-2508512459

From jkern at openjdk.org  Tue Dec 17 12:59:17 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 17 Dec 2024 12:59:17 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v4]
In-Reply-To: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
Message-ID: <5Uro3Q_MY7g0n5dtaNgZjOg8PUlTsDiW8yCOPey87Bo=.12b8f013-7fb7-4751-976d-f547cd61fb2a@github.com>

> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
> 
> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.

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

  copyright date

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22633/files
  - new: https://git.openjdk.org/jdk/pull/22633/files/db44c94b..44cd6b91

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

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

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

From jkern at openjdk.org  Tue Dec 17 14:57:14 2024
From: jkern at openjdk.org (Joachim Kern)
Date: Tue, 17 Dec 2024 14:57:14 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v5]
In-Reply-To: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
Message-ID: <Jmm7tq_omhbk_5ULbRPrvhCPgGrHELXm2UDeFOXShEg=.c7069c9e-3b7f-4d15-86eb-37746c16bc9b@github.com>

> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
> 
> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.

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

  copyrights again

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22633/files
  - new: https://git.openjdk.org/jdk/pull/22633/files/44cd6b91..b83b8124

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

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

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

From bpb at openjdk.org  Tue Dec 17 16:30:47 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 16:30:47 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v3]
In-Reply-To: <g9S5JSc-nLmW8Zad5CsSvd42GbvOK9FaodRiBvUeO-M=.7286d011-1993-435f-8de9-b1bcdca14bf8@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>
 <g9S5JSc-nLmW8Zad5CsSvd42GbvOK9FaodRiBvUeO-M=.7286d011-1993-435f-8de9-b1bcdca14bf8@github.com>
Message-ID: <0OSMYO3Eb2GBJeeq0O62iaDircc3yfdxNwbX7LxXCbw=.a800977b-01b4-4d4d-b646-5dfc7da0d5a8@github.com>

On Tue, 17 Dec 2024 07:40:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8345432: Add uninterruptible InnocuousThread for Windows PipeImpl
>
> src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 64:
> 
>> 62:         return createThread(newName(), target, 0L,
>> 63:                 ClassLoader.getSystemClassLoader(), -1, true);
>> 64:     }
> 
> I think this is just a bit weird to have this in InnocuousThread. I think we should look for alternatives for PipeImpl so leave it out of this PR as it's benign if it inherits.

I don't like it either. I will revert this commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1888838678

From bpb at openjdk.org  Tue Dec 17 16:52:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 16:52:37 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v3]
In-Reply-To: <0OSMYO3Eb2GBJeeq0O62iaDircc3yfdxNwbX7LxXCbw=.a800977b-01b4-4d4d-b646-5dfc7da0d5a8@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>
 <g9S5JSc-nLmW8Zad5CsSvd42GbvOK9FaodRiBvUeO-M=.7286d011-1993-435f-8de9-b1bcdca14bf8@github.com>
 <0OSMYO3Eb2GBJeeq0O62iaDircc3yfdxNwbX7LxXCbw=.a800977b-01b4-4d4d-b646-5dfc7da0d5a8@github.com>
Message-ID: <F43Ux9lWDKvJcjrKez_qa0Gwwuz27bEVSwTkpAnrhiM=.ef297132-8db8-4e92-9db2-00d894fe6b4c@github.com>

On Tue, 17 Dec 2024 16:27:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/misc/InnocuousThread.java line 64:
>> 
>>> 62:         return createThread(newName(), target, 0L,
>>> 63:                 ClassLoader.getSystemClassLoader(), -1, true);
>>> 64:     }
>> 
>> I think this is just a bit weird to have this in InnocuousThread. I think we should look for alternatives for PipeImpl so leave it out of this PR as it's benign if it inherits.
>
> I don't like it either. I will revert this commit.

Should the Thread in PipeImpl have a name? Currently it does not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1888875072

From alanb at openjdk.org  Tue Dec 17 17:00:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Dec 2024 17:00:40 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v3]
In-Reply-To: <F43Ux9lWDKvJcjrKez_qa0Gwwuz27bEVSwTkpAnrhiM=.ef297132-8db8-4e92-9db2-00d894fe6b4c@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <c7-GrHfAmzjze1d3jfa7n7DLuwZlipQjiS4S1raD7gw=.cb3f2e23-8c2c-40a0-b3f0-c458c45746c9@github.com>
 <g9S5JSc-nLmW8Zad5CsSvd42GbvOK9FaodRiBvUeO-M=.7286d011-1993-435f-8de9-b1bcdca14bf8@github.com>
 <0OSMYO3Eb2GBJeeq0O62iaDircc3yfdxNwbX7LxXCbw=.a800977b-01b4-4d4d-b646-5dfc7da0d5a8@github.com>
 <F43Ux9lWDKvJcjrKez_qa0Gwwuz27bEVSwTkpAnrhiM=.ef297132-8db8-4e92-9db2-00d894fe6b4c@github.com>
Message-ID: <OCSOSuzGqnHp-5Ajv0rMYKTDDfueys8p7T5KyrRwjN8=.8b54e6ad-be12-4cc4-873c-ff44a34e2b7b@github.com>

On Tue, 17 Dec 2024 16:49:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't like it either. I will revert this commit.
>
> Should the Thread in PipeImpl have a name? Currently it does not.

For troubleshooting purposes then it could be useful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22697#discussion_r1888891680

From bpb at openjdk.org  Tue Dec 17 17:11:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 17:11:48 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v3]
In-Reply-To: <XVemsFPZ_G5dia9xcjU9Vu1v2PfA_byihdNGFvVSL-k=.69546285-3945-45b2-b086-57323dc5a4f3@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <SgPGEo3nXxu74-kS4iZk6Ib52qlWYe-xGRG2Az8eYh8=.478195a9-ba01-4e17-b1f8-a499bf89d665@github.com>
 <XVemsFPZ_G5dia9xcjU9Vu1v2PfA_byihdNGFvVSL-k=.69546285-3945-45b2-b086-57323dc5a4f3@github.com>
Message-ID: <x6IN7gjLpaSEMwOfbTAaByMFSW6b8w1k7_XMr9dBOcc=.ad8c7d09-876a-411d-971d-5cee330fb87f@github.com>

On Tue, 17 Dec 2024 08:02:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I realize you've added a comment to continue to this PR

I only committed a merge from master.

> but I think is going to require significant effort to audit just about every scenario to work through potential inconsistencies. It's not clear it's worth doing it at this time.

I can move it to Draft for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2549064843

From bpb at openjdk.org  Tue Dec 17 18:32:17 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Dec 2024 18:32:17 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v4]
In-Reply-To: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
Message-ID: <2tz5mQ_aZRbRN-WRZiRe25XABF0QHRtsswypqiLtr3U=.579eef75-8066-4ca7-b186-b716863d7806@github.com>

> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.

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

  8345432: Revert commit aa5bb8a; give Windows PipeImpl LoopbackConnector thread a name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22697/files
  - new: https://git.openjdk.org/jdk/pull/22697/files/aa5bb8a1..c4196757

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

  Stats: 32 lines in 2 files changed: 3 ins; 22 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22697.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22697/head:pull/22697

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

From alanb at openjdk.org  Tue Dec 17 18:45:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Dec 2024 18:45:36 GMT
Subject: RFR: 8345432: (ch,
 fs) Replace anonymous Thread with InnocuousThread [v4]
In-Reply-To: <2tz5mQ_aZRbRN-WRZiRe25XABF0QHRtsswypqiLtr3U=.579eef75-8066-4ca7-b186-b716863d7806@github.com>
References: <dC9u_KLEOn7EyEExPR3SuQDnfef_Sadsaknd1WH4pK8=.fac24598-4846-4552-85b7-76d290dc7e10@github.com>
 <2tz5mQ_aZRbRN-WRZiRe25XABF0QHRtsswypqiLtr3U=.579eef75-8066-4ca7-b186-b716863d7806@github.com>
Message-ID: <H409q2wyuYTpzR7mPbeJn36G5nY_vTOCGkeN4YEmFxY=.f70ac03a-1f9c-45c8-bf6c-e0223c31e856@github.com>

On Tue, 17 Dec 2024 18:32:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Change internal instances of anonymous `Thread`s to instances of `InnocuousThread`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8345432: Revert commit aa5bb8a; give Windows PipeImpl LoopbackConnector thread a name

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22697#pullrequestreview-2509787552

From alanb at openjdk.org  Tue Dec 17 18:59:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Dec 2024 18:59:57 GMT
Subject: RFR: 8346463: Add test coverage for deploying the default provider as
 a module
Message-ID: <jqkA9NYxEwGWm98sJKn8ubWOlwvJF3dwgqs-Wfd0sgs=.8cb54132-9028-4e91-844b-314e3727fb73@github.com>

test/jdk/java/nio/file/spi/SetDefaultProvider.java tests deploying with a custom file system provider as the default provider. The test is moved to JUnit and is updated with new tests that deploy the custom default provider on the module path. To support the different deployments, TestProvider is moved into a named package and module.

In preparation for JDK-8331467, a test is added to create a run-time image that contains the custom default file system provider.

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

Commit messages:
 - Update UnixDomainSocketAddress/AddressTest.java
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22797/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22797&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8346463
  Stats: 224 lines in 8 files changed: 77 ins; 49 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/22797.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22797/head:pull/22797

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

From dfuchs at openjdk.org  Wed Dec 18 14:52:39 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 18 Dec 2024 14:52:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v9]
In-Reply-To: <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <754sEaQPoyPi9j7x1ltulFSIW1eS0PtzzfMYkFzHeaA=.5a037bc0-3867-4272-be89-3dc01da62ec3@github.com>
Message-ID: <3zb5xfTBTaX0fz635YTOpgpQZk0Iaco5A5m7vZWOoSU=.ac44adff-136f-4198-9692-2577949469a7@github.com>

On Mon, 16 Dec 2024 20:24:20 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Refactored connect exception tests to a single IOHelper method
>   that takes a function argument that is excpected to produce the
>   appropriate exception.  IANA reserved ports in the range 225 to
>   241 are used to attempt to produce a connect exception.

The test updates LGTM

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2551514817

From mdoerr at openjdk.org  Wed Dec 18 16:38:40 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 18 Dec 2024 16:38:40 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v5]
In-Reply-To: <Jmm7tq_omhbk_5ULbRPrvhCPgGrHELXm2UDeFOXShEg=.c7069c9e-3b7f-4d15-86eb-37746c16bc9b@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <Jmm7tq_omhbk_5ULbRPrvhCPgGrHELXm2UDeFOXShEg=.c7069c9e-3b7f-4d15-86eb-37746c16bc9b@github.com>
Message-ID: <4X2kfrasyr0pFqd23SFkF-o1YXCLvHkclBOakTqNHcw=.2d66e06e-3b74-4c74-84e9-ea4fa368567a@github.com>

On Tue, 17 Dec 2024 14:57:14 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>> 
>> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
>> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
>> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights again

Marked as reviewed by mdoerr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22633#pullrequestreview-2512342365

From bpb at openjdk.org  Wed Dec 18 17:32:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Dec 2024 17:32:06 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
Message-ID: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>

Remove from problem list test which should have been removed in #22339.

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

Commit messages:
 - 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from test/hotspot/jtreg/ProblemList.txt

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

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

From alanb at openjdk.org  Wed Dec 18 17:37:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Dec 2024 17:37:34 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <qagem0tbuo01AZoEyC4kqMPGQ0nuog2q903JWqjovBU=.e6df1311-e36f-4a95-b2e6-d95459046331@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2512471005

From bpb at openjdk.org  Thu Dec 19 00:25:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Dec 2024 00:25:45 GMT
Subject: RFR: 8346463: Add test coverage for deploying the default provider
 as a module
In-Reply-To: <jqkA9NYxEwGWm98sJKn8ubWOlwvJF3dwgqs-Wfd0sgs=.8cb54132-9028-4e91-844b-314e3727fb73@github.com>
References: <jqkA9NYxEwGWm98sJKn8ubWOlwvJF3dwgqs-Wfd0sgs=.8cb54132-9028-4e91-844b-314e3727fb73@github.com>
Message-ID: <slDS6K0hf_mqwqhAje2sjOr8B85D5n9hx40baKqaP1E=.31196773-6208-4a3e-adee-d52f65d0e79d@github.com>

On Tue, 17 Dec 2024 18:16:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> test/jdk/java/nio/file/spi/SetDefaultProvider.java tests deploying with a custom file system provider as the default provider. The test is moved to JUnit and is updated with new tests that deploy the custom default provider on the module path. To support the different deployments, TestProvider is moved into a named package and module.
> 
> In preparation for JDK-8331467, a test is added to create a run-time image that contains the custom default file system provider.

This looks all right to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22797#pullrequestreview-2513096411

From jpai at openjdk.org  Thu Dec 19 04:52:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 19 Dec 2024 04:52:34 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <YdQ_OkowwtUrTbh1dtbF0Was8d1zONn8uWrZENGKJH8=.bb3907fe-b566-4c3e-a5e5-e7f914b7bb0c@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Thank you for fixing this Brian. This looks good to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2513343986

From alanb at openjdk.org  Thu Dec 19 08:01:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Dec 2024 08:01:48 GMT
Subject: Integrated: 8346463: Add test coverage for deploying the default
 provider as a module
In-Reply-To: <jqkA9NYxEwGWm98sJKn8ubWOlwvJF3dwgqs-Wfd0sgs=.8cb54132-9028-4e91-844b-314e3727fb73@github.com>
References: <jqkA9NYxEwGWm98sJKn8ubWOlwvJF3dwgqs-Wfd0sgs=.8cb54132-9028-4e91-844b-314e3727fb73@github.com>
Message-ID: <z--41oCjhDu2pw4ijR7SkcNaycD_mh1DnKC6YhBfDLE=.22022605-d908-4283-bc98-68a56b6d0484@github.com>

On Tue, 17 Dec 2024 18:16:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> test/jdk/java/nio/file/spi/SetDefaultProvider.java tests deploying with a custom file system provider as the default provider. The test is moved to JUnit and is updated with new tests that deploy the custom default provider on the module path. To support the different deployments, TestProvider is moved into a named package and module.
> 
> In preparation for JDK-8331467, a test is added to create a run-time image that contains the custom default file system provider.

This pull request has now been integrated.

Changeset: 23d6f747
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23d6f747824ee3d750e2148a2be9d8e1dedbde40
Stats:     223 lines in 8 files changed: 75 ins; 48 del; 100 mod

8346463: Add test coverage for deploying the default provider as a module

Reviewed-by: bpb

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

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

From mli at openjdk.org  Thu Dec 19 10:41:35 2024
From: mli at openjdk.org (Hamlin Li)
Date: Thu, 19 Dec 2024 10:41:35 GMT
Subject: RFR: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <5FV6Rb6ZXXbkeFcQuXlBVKvtZ4bjHI_5bA9rDg7-6tU=.1e38a041-0d14-4cb4-b3dc-4e4a5e0a57a0@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

Looks good.

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

Marked as reviewed by mli (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22819#pullrequestreview-2514032898

From bpb at openjdk.org  Thu Dec 19 16:19:50 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Dec 2024 16:19:50 GMT
Subject: Integrated: 8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from
 test/hotspot/jtreg/ProblemList.txt
In-Reply-To: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
References: <r7Au-QK57oc611-zNYQ38Uml21JuLm5ULF_Y5S6E9rs=.9b00fc42-d489-49cc-8867-bc4d0d39a1ac@github.com>
Message-ID: <ls7q11o6XhtCn7fQ5nGJRhaQ3k3naRxAr4iWwGkPddc=.3a6c7ccd-61b0-42d1-822b-707ccab74b3a@github.com>

On Wed, 18 Dec 2024 17:24:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove from problem list test which should have been removed in #22339.

This pull request has now been integrated.

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

8346576: Remove vmTestbase/gc/memory/Nio/Nio.java from test/hotspot/jtreg/ProblemList.txt

Reviewed-by: alanb, jpai, mli

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

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

From egahlin at openjdk.org  Thu Dec 19 19:19:38 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 19 Dec 2024 19:19:38 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
 <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz
 5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
 <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>
Message-ID: <CVS-QWIDcmKgGRfcZKSAo2tsqbmsjAubV_1D4nxkemg=.4c1cebba-2473-4462-b503-a1b98d275c9c@github.com>

On Thu, 12 Dec 2024 03:58:29 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> We need to help Tim on the question of whether there is one or two events. 
>> 
>> An application that makes outbound network connections may run slowly for several reasons. A duration event may help to diagnose this, irrespective of whether the connection is established successfully or it fails, so one event is okay. Separately, another big source of latency is the name service / DNS lookup which happens before getting to the Socket connect. Maybe further work could add events to InetAddress for this.
>> 
>> When hunting misbehaving behavior then focusing on the cases where a connection cannot be established may be more interesting. So it's possible someone might want to run with threshold=0 to see all failed events. If there is throttling support, and since we control call site for both the successful and failed cases, could we live with one event?
>
> I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January.

Regarding, one or two events. I'm fine with integrating as-is and then revisit before FC, if needed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1893019773

From alanb at openjdk.org  Fri Dec 20 10:44:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Dec 2024 10:44:57 GMT
Subject: RFR: 8346573: Can't use custom default file system provider with
 custom system class loader
Message-ID: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>

If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.

The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.

The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.

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

Commit messages:
 - Initial commit

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

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

From mkartashev at openjdk.org  Fri Dec 20 14:14:36 2024
From: mkartashev at openjdk.org (Maxim Kartashev)
Date: Fri, 20 Dec 2024 14:14:36 GMT
Subject: RFR: 8346573: Can't use custom default file system provider with
 custom system class loader
In-Reply-To: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
References: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
Message-ID: <PCiXhCzNtnXVKzmjEPysV7RnBOTaJZs5yzWYzvZ70PE=.d8f165ec-d0e1-4859-be42-2ed94ce95202@github.com>

On Fri, 20 Dec 2024 09:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.
> 
> The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.
> 
> The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.

I'm not a reviewer, but this does solve the problem with the circular initialization that we had.

test/jdk/java/nio/file/spi/CustomSystemClassLoader.java line 38:

> 36:         // use default file system
> 37:         FileSystem fs = FileSystems.getDefault();
> 38:         var path = fs.getPath("foo");

Maybe print the path out so that the whole thing does not get optimized away as vacuous in accordance with the language rules?

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

Marked as reviewed by mkartashev (no project role).

PR Review: https://git.openjdk.org/jdk/pull/22842#pullrequestreview-2517640245
PR Review Comment: https://git.openjdk.org/jdk/pull/22842#discussion_r1893988101

From bpb at openjdk.org  Fri Dec 20 17:28:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 20 Dec 2024 17:28:37 GMT
Subject: RFR: 8346573: Can't use custom default file system provider with
 custom system class loader
In-Reply-To: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
References: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
Message-ID: <xKnIDm-D5EBBSW8JPoPzVNWwG79iiK5LpYXvYyyy8LQ=.f6ef7328-966b-40ff-938b-1684ddaae9b0@github.com>

On Fri, 20 Dec 2024 09:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.
> 
> The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.
> 
> The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.

Looks fine to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22842#pullrequestreview-2518009477

From duke at openjdk.org  Sat Dec 21 02:39:34 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 21 Dec 2024 02:39:34 GMT
Subject: RFR: 8346573: Can't use custom default file system provider with
 custom system class loader
In-Reply-To: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
References: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
Message-ID: <kR9WCvkWDVp15fsStr3pK6zQK8Yzj9dsjJCxatzDgu8=.f6697017-c77f-429f-92c0-cdd54722ba8f@github.com>

On Fri, 20 Dec 2024 09:47:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.
> 
> The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.
> 
> The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.

src/java.base/share/classes/java/nio/file/FileSystems.java line 116:

> 114:                 for (String cn: propValue.split(",")) {
> 115:                     try {
> 116:                         Class<?> c = Class.forName(cn, true, ClassLoaders.appClassLoader());

This?breaks the?case where?a?custom system?`ClassLoader` doesn?t?depend on?a?custom default `FileSystemProvider` but?the?latter depends on?the?custom system?`ClassLoader`, so?this?should call?`ClassLoaders?::appClassLoader()` only?when `VM.isBooted()` is?`false`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22842#discussion_r1894537920

From alanb at openjdk.org  Sat Dec 21 08:10:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Dec 2024 08:10:38 GMT
Subject: RFR: 8346573: Can't use custom default file system provider with
 custom system class loader
In-Reply-To: <kR9WCvkWDVp15fsStr3pK6zQK8Yzj9dsjJCxatzDgu8=.f6697017-c77f-429f-92c0-cdd54722ba8f@github.com>
References: <uoxSJyEdXT-nq_7kohsty0TwSWgWCPDJd1OJuH0IuK4=.65001480-6502-4898-b440-2fe89dd92ea5@github.com>
 <kR9WCvkWDVp15fsStr3pK6zQK8Yzj9dsjJCxatzDgu8=.f6697017-c77f-429f-92c0-cdd54722ba8f@github.com>
Message-ID: <oP2emabFtCUBCJwpHtRa2hHGaquj5ZDYwlcWdJBCif0=.7e6806b0-d9aa-45c6-a210-41e351f5af49@github.com>

On Sat, 21 Dec 2024 02:34:17 GMT, ExE Boss <duke at openjdk.org> wrote:

>> If an application is deployed to use a custom default file system provider, and a custom system class loader, and initialisation of the custom system class loader uses the file system APIs, then it leads to a recursive initialisation issue. This issue has always existed but has only recently been reported. Using both configuration knobs at the same time is probably very rare but it does require attention in advance of any proposals that re-implement the java.io file classes on java.nio.file.
>> 
>> The proposed change here is to re-specify FileSystems.getDefault to use the default system class loader when locating the custom default file system provider. In spec terms, this is changing "system class loader" to "default system class loader" with a link to its meaning in ClassLoader.getSystemClassLoader. As part of the change I've expanded the wording to specify that the custom default file system provider must be public in a package exported to at least java.base, and that the one-arg constructor also be public. This additional clarification specifies long standing behavior and does not change any implementation.
>> 
>> The SetDefaultProvider.java test is expanded to add a new test the runs with both a custom default file system provider and custom system class loader, and where where the custom system class loader uses the file APIs in its initialisation.
>
> src/java.base/share/classes/java/nio/file/FileSystems.java line 116:
> 
>> 114:                 for (String cn: propValue.split(",")) {
>> 115:                     try {
>> 116:                         Class<?> c = Class.forName(cn, true, ClassLoaders.appClassLoader());
> 
> Note?that this?might?break the?case where?a?custom system?`ClassLoader` doesn?t?depend on?a?custom default `FileSystemProvider` but?the?latter depends on?the?custom system?`ClassLoader`, so?this?should call?`ClassLoaders?::appClassLoader()` only?when `VM.isBooted()` is?`false`.

A custom default file system provider can't depend on a custom system ClassLoader. Think of access to the default file system as something that works at a much lower level that a class loader.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22842#discussion_r1894582246

From varadam at openjdk.org  Mon Dec 23 09:57:38 2024
From: varadam at openjdk.org (Varada M)
Date: Mon, 23 Dec 2024 09:57:38 GMT
Subject: RFR: 8211851: (ch)
 java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out
 (aix) [v5]
In-Reply-To: <Jmm7tq_omhbk_5ULbRPrvhCPgGrHELXm2UDeFOXShEg=.c7069c9e-3b7f-4d15-86eb-37746c16bc9b@github.com>
References: <vxdMaBRcahItHruopBAAkkgYLsv4xemDV5MicdNtk8k=.9f7f7497-f8f4-4136-b6b4-5e15cf75d218@github.com>
 <Jmm7tq_omhbk_5ULbRPrvhCPgGrHELXm2UDeFOXShEg=.c7069c9e-3b7f-4d15-86eb-37746c16bc9b@github.com>
Message-ID: <x0G2l4l1tGUkQH55spUBkIwufaCz8J-kb3d-F6PNIJ4=.b96019e8-9cc1-4e6d-b6f3-38f9c188f88e@github.com>

On Tue, 17 Dec 2024 14:57:14 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Test /jdk/java/nio/channels/AsynchronousSocketChannel/StressLoopback.java times out on aix.
>> 
>> The problem is that in queueControlEvent() for every event added to the controlQueue one byte is written to the ctlSP pipe to wakeup the poll thread running in poll(). The poll() function of the poll thread is just taking this one byte from the pipe but handling then all events in the controlQueue. Afterwards the controlQueue is empty, but the pipe is only 1 byte shorter. This is an asymmetric and therefore false behavior.  So I changed the drain1() to a drain() meaning drain_all() which heals this asymmetry.
>> The problem leading to the timeout was, that more and more (StressLoopback: nomen est omen) wakeup bytes were written to the pipe, but the poll thread runs in much lower frequency. So, at some time the pipe was full on OS side, resulting in a blocking Pollset.interrupt(ctlSp[1]) in queueControlEvent(). Unfortunately, at this moment the controlQueue sync object is in locked state, resulting that the poll thread cannot acquire this lock to read from the pipe. No reading from the pipe means the pipe remains full and the dead lock is there.
>> Additionally, I found a flaw in the emulator of the ?one shot? semantic. Here the original implantation was not save against deleting a just registered fd before the next poll. To fix this I separated the emulation of the ?one shot? from the rest of the poll() actions. Now, the ?one shot? emulation is encapsulated in the controlLock.lock()block, which guards the poll itself.
>
> Joachim Kern has updated the pull request incrementally with one additional commit since the last revision:
> 
>   copyrights again

LGTM! Thank you for the fix.

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

Marked as reviewed by varadam (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22633#pullrequestreview-2520280078

From duke at openjdk.org  Thu Dec 26 00:05:51 2024
From: duke at openjdk.org (Bruno Ploumhans)
Date: Thu, 26 Dec 2024 00:05:51 GMT
Subject: RFR: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS
Message-ID: <rkg0vDKsEg85HRr_F7fSTdOkOYJa4RrTbzb62I_Dc0Q=.e021cc94-c84d-4e09-b94b-1493f39d0a25@github.com>

Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882.

Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`.

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

Commit messages:
 - remove \r characters in test
 - 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS

Changes: https://git.openjdk.org/jdk/pull/22882/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22882&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316882
  Stats: 149 lines in 12 files changed: 107 ins; 14 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/22882.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22882/head:pull/22882

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

From alanb at openjdk.org  Thu Dec 26 07:08:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 26 Dec 2024 07:08:38 GMT
Subject: RFR: 8316882: Add NOT_INTERRUPTIBLE OpenOption and use it in ZipFS
In-Reply-To: <rkg0vDKsEg85HRr_F7fSTdOkOYJa4RrTbzb62I_Dc0Q=.e021cc94-c84d-4e09-b94b-1493f39d0a25@github.com>
References: <rkg0vDKsEg85HRr_F7fSTdOkOYJa4RrTbzb62I_Dc0Q=.e021cc94-c84d-4e09-b94b-1493f39d0a25@github.com>
Message-ID: <HFbda1Rzr1E9cNTFl8vPs63wUsJNYOfnj5p8hmgvtJI=.694bf6c0-5dce-42db-a1a5-7f1d04709091@github.com>

On Wed, 25 Dec 2024 23:55:18 GMT, Bruno Ploumhans <duke at openjdk.org> wrote:

> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882.
> 
> Following discussion in nio-dev a while ago, I have opted to add a new `NOT_INTERRUPTIBLE` open option, superseding `FileChannelImpl#setUninterruptible`.

The core issue is that FileChannel is an InterruptibleChannel. We've discussed several times on nio-dev about adding an open option to allow the channel be non-interruptible. None of these discussions concluded satisfactorily. If we do it then most of the work will be implications and FileChannel's specification. It looks like you've missed that part and focused on implementation changes. So I think this PR should be closed, please restart the discussion on nio-dev.

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

PR Comment: https://git.openjdk.org/jdk/pull/22882#issuecomment-2562233527

From bruno.ploumhans at gmail.com  Thu Dec 26 10:15:18 2024
From: bruno.ploumhans at gmail.com (Bruno Ploumhans)
Date: Thu, 26 Dec 2024 11:15:18 +0100
Subject: NOT_INTERRUPTIBLE OpenOption and how that should fit with
 InterruptibleChannel
Message-ID: <CAH225Xg0yDYxPd7L2YDsKAsaw2YdfxUvx1ZWD5QqO4fCiwafEA@mail.gmail.com>

Hi,

I opened a PR that adds StandardOpenOptions.NOT_INTERRUPTIBLE to
expose and supersede FileChannelImpl#setUninterruptible. However, this
needs more discussion because FileChannel implements
InterruptibleChannel.

Here are some thoughts to kick-start the discussion:
- The documentation of InterruptibleChannel does not currently account
for implementations that might not be interruptible. Same for the
documentation of Thread.interrupt(). That needs changing.
- Alan suggested in previous discussion (2018) a new `boolean
isInterruptible()` method.
- I wonder if the ability to pass a `boolean uninterruptible` flag
should be exposed in AbstractUninterruptibleChannel, or if that should
be kept an implementation detail of FileChannelImpl.

In any case, I am happy to experiment with various solutions.

Best,
Bruno

my PR: https://github.com/openjdk/jdk/pull/22882
previous discussion (2018):
https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html

From duke at openjdk.org  Sun Dec 29 08:46:45 2024
From: duke at openjdk.org (Markus KARG)
Date: Sun, 29 Dec 2024 08:46:45 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
 [v2]
In-Reply-To: <Xlul5m5LH7lFRGZCbvguVCz7beaLc0SRMkbtgGHLnyc=.ce24f0ec-38ed-4e6a-8f6b-081c05f6819e@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <Xlul5m5LH7lFRGZCbvguVCz7beaLc0SRMkbtgGHLnyc=.ce24f0ec-38ed-4e6a-8f6b-081c05f6819e@github.com>
Message-ID: <ZUUqvhrk3p6Ss8e_Jb17UATR0t0GhCaNvyqNdMUyHDc=.87c58472-f583-497e-8a4c-009dbff3f49f@github.com>

On Sun, 27 Oct 2024 14:25:07 GMT, Markus KARG <duke at openjdk.org> wrote:

>> # Targets
>> 
>> The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
>> 
>> A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.
>> 
>> An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.
>> 
>> 
>> # Non-Targets
>> 
>> It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
>> 
>> It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.
>> 
>> It is not a target to improve other source types besides pipes and sockets.
>> 
>> 
>> # Description
>> 
>> What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.
>> 
>> For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.
>> 
>> Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.
>> 
>> 
>> # Implementation
>> 
>> The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.
>> 
>> Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
>> 1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
>> 2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferr...
>
> Markus KARG has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Socket.getInputStream()'s JavaDocs explain behavior of skip for timeout, non-blocking, interrupt

Kindly asking to resume this suspended review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2564654972