From alanb at openjdk.org  Mon Aug  1 06:09:39 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 06:09:39 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
Message-ID: <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>

On Fri, 29 Jul 2022 16:02:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Is there anything else to be done in this PR? Thanks.

It looks like this issue has changed from the original bug report and now rejects the empty pattern with IAE. This is a behavior change (and probably the right behavior) but I think will require a small update to the javadoc to make it clear that both an empty syntax and empty pattern are illegal.

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

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

From djelinski at openjdk.org  Mon Aug  1 07:16:49 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Aug 2022 07:16:49 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v2]
In-Reply-To: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
Message-ID: <IBccnCd7NTeEQmNex5zcdEUgDc2VRlsstz6ZG1k_6KA=.935f531c-f2b0-4f95-81e2-55354a3635a0@github.com>

> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
> 
> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
> 
> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
> 
> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
> 
> Testing performed (with IP_DONTFRAGMENT flag):
> Windows 10:
> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
> 
> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
> If a packet is sent to a non-routable address, send succeeds, no error is reported.
> 
> Linux:
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
> 
> Mac OS X 12:
> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Add comment about dontfragment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9575/files
  - new: https://git.openjdk.org/jdk/pull/9575/files/e89c87be..7af4473c

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

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

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

From alanb at openjdk.org  Mon Aug  1 07:33:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:33:25 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v2]
In-Reply-To: <IBccnCd7NTeEQmNex5zcdEUgDc2VRlsstz6ZG1k_6KA=.935f531c-f2b0-4f95-81e2-55354a3635a0@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <IBccnCd7NTeEQmNex5zcdEUgDc2VRlsstz6ZG1k_6KA=.935f531c-f2b0-4f95-81e2-55354a3635a0@github.com>
Message-ID: <azs20p-kb5s5W674Hxz21eSd5mTqEpnPDOkUXMnQmyg=.1d3e05ce-19fd-446d-9673-c1dd1af87847@github.com>

On Mon, 1 Aug 2022 07:16:49 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
>> 
>> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
>> 
>> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
>> 
>> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
>> 
>> Testing performed (with IP_DONTFRAGMENT flag):
>> Windows 10:
>> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
>> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
>> 
>> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
>> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
>> If a packet is sent to a non-routable address, send succeeds, no error is reported.
>> 
>> Linux:
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
>> 
>> Mac OS X 12:
>> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add comment about dontfragment

Have you considered changing ExtendedSocketOptions.xxxOption to take a family parameter rather than a boolean as that would be more general and maybe useful in the future?

The change to the comments in src/java.base/unix/native/libnio/ch/Net.c and src/java.base/windows/native/libnio/ch/Net.c are a bit ugl and maybe confusing as there is no support for "dontfragment" in java.base. If you really need to change the comments then use the same style as the existing comments and use "IP_DONTFRAGMENT" instead.

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

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

From djelinski at openjdk.org  Mon Aug  1 07:33:25 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Aug 2022 07:33:25 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v2]
In-Reply-To: <YRX1ZW-bsZHmDWFj7-yEtmJEoU1ARqLOrdQb8gwElBI=.aebbd251-996c-4290-bdfb-398183b0503b@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <3no302rlOTE2mXILPU297bKZCbSgwgDK5I5mGDp9Cis=.b7c9e3ca-5971-4e54-8526-01fe2ca7a5f8@github.com>
 <euSv6kS2ijLSPqrk_-5F8G5WO_YL0j4XkU9Y8wAKwgA=.f4c0003a-beb4-4b1a-9e61-503734a592b9@github.com>
 <YRX1ZW-bsZHmDWFj7-yEtmJEoU1ARqLOrdQb8gwElBI=.aebbd251-996c-4290-bdfb-398183b0503b@github.com>
Message-ID: <4fUuruEvB5Xdk6KNCGNUCJMKuutRpEcni4qvqyqedZo=.6af7765c-81a5-4d6a-a0c2-d4cbd72f46b7@github.com>

On Mon, 25 Jul 2022 10:51:14 GMT, Michael McMahon <michaelm at openjdk.org> wrote:

>> Hi Jaikiran, the point of this change was to better support systems where either IPv4 or IPv6 was disabled. I'm not sure if that can even happen on Mac. 
>> The change here is that if we can't create one socket, we don't immediately return false, but instead return the result for the other socket. For example, if creating IPv4 socket fails, we only check if DF is supported on IPv6 socket, and return that as a result. If both `socket` calls fail, we don't know if the DF flag is supported, and return true (before the patch we would return false in that case). I can modify the patch to return false in that case, or roll back this change entirely if you think it makes no sense.
>
> I think this change makes sense so long as we are sure that if IPv4 or IPv6 is disabled then the right call happens for the other option.

The method will return true if the process is at the limit of open file descriptors. Before this patch the code returned false in that case.
As soon as Mac OS 10 (Catalina) goes out of support, we can remove this code entirely - AFAICT all newer versions support DF.

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

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

From shade at openjdk.org  Mon Aug  1 07:38:46 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 07:38:46 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <LlVLLSKlSWxzuVO-rsJrBWDWZyKHfw6pbG4UgWOHiHQ=.c330edd3-1fd9-4dfe-b869-5e3b9cc1dcb7@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

Hey @AlanBateman, welcome back? Please see if you agree with network tests change?

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

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

From alanb at openjdk.org  Mon Aug  1 07:47:37 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:47:37 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

No objection to changing these tests. We should probably do test/jdk/java/net/vthread/BlockingSocketOps.java at the same time as it also runs the sockets tests with the Poller in both configurations.

For the test ids then I'd prefer not use two styles (id=useDirectRegister and id=no-continuations). Can you change these to `indirect-register` and `no-vmcontinuations`?

I'd prefer if the `@bug` tag is not copied, only because we add to the bug list when extending tests.

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

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

From alanb at openjdk.org  Mon Aug  1 07:56:36 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 07:56:36 GMT
Subject: RFR: 8291061: Improve thread safety of FileTime.toString and
 toInstant
In-Reply-To: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com>
References: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com>
Message-ID: <4rr6wKybgCcTo88LYyT9D3PgOZN4wjOli8U4SW2ZcZ0=.e1aab3a0-15f9-4624-9b0f-915da8d4b116@github.com>

On Fri, 22 Jul 2022 07:34:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We need to read fields `instant`/`valueAsString` once, as to dodge/resolve the data race on reading lazily-initialized fields.

Marked as reviewed by alanb (Reviewer).

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

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

From shade at openjdk.org  Mon Aug  1 08:37:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 08:37:11 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

Aleksey Shipilev 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:

 - Review comments
 - Merge branch 'master' into JDK-8290531-loom-tests-parallel
 - More fixes
 - Fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9554/files
  - new: https://git.openjdk.org/jdk/pull/9554/files/3f9bf337..e87544f2

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

  Stats: 16874 lines in 645 files changed: 10175 ins; 4817 del; 1882 mod
  Patch: https://git.openjdk.org/jdk/pull/9554.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9554/head:pull/9554

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

From shade at openjdk.org  Mon Aug  1 08:37:11 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 08:37:11 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <nLpvsNQ1aY78k0WhCC3FrmejtwQ8kxCrcg7Mi-LJRfQ=.54f37155-b8de-48de-a130-b0481e6a12bb@github.com>
Message-ID: <3PVri60xrVtIlINItS63CO_6IXUoP1EAn4gGPicrnVY=.4c531ba1-17bd-4a30-a8a6-7c7099c0a15e@github.com>

On Mon, 1 Aug 2022 07:43:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No objection to changing these tests.

Did the changes in new commit.

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

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

From djelinski at openjdk.org  Mon Aug  1 08:43:45 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Aug 2022 08:43:45 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v2]
In-Reply-To: <azs20p-kb5s5W674Hxz21eSd5mTqEpnPDOkUXMnQmyg=.1d3e05ce-19fd-446d-9673-c1dd1af87847@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <IBccnCd7NTeEQmNex5zcdEUgDc2VRlsstz6ZG1k_6KA=.935f531c-f2b0-4f95-81e2-55354a3635a0@github.com>
 <azs20p-kb5s5W674Hxz21eSd5mTqEpnPDOkUXMnQmyg=.1d3e05ce-19fd-446d-9673-c1dd1af87847@github.com>
Message-ID: <o_pvBNGySroqgjLU05aZuUt39vsOG_QGBjWwT7U3uEo=.d47109e4-e14e-4fb0-b6a7-dda38eea5b2f@github.com>

On Mon, 1 Aug 2022 07:28:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Have you considered changing ExtendedSocketOptions.xxxOption to take a family parameter rather than a boolean as that would be more general and maybe useful in the future?

Passing a boolean matches what we're doing in `setIntOption0` and gets the job done. At this moment I don't see where passing `family` would be useful. Can we make that change when it's actually needed?

> The change to the comments [...] are a bit ugly

Agree. How about a more specific comment? Something like:

/* Mac OS does not support setting IPv4 options on IPv6 sockets. As a result, some/all IP_* options
 are not applied to IPv4 datagrams sent from IPv6 sockets. */

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

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

From djelinski at openjdk.org  Mon Aug  1 09:00:37 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 1 Aug 2022 09:00:37 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v3]
In-Reply-To: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
Message-ID: <q8bgX3BbamXDaVpv4Scs-WSWmZSDxLIbK7jcSA0mS-s=.cbf500a9-e3de-465a-9057-ab6edceda279@github.com>

> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
> 
> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
> 
> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
> 
> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
> 
> Testing performed (with IP_DONTFRAGMENT flag):
> Windows 10:
> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
> 
> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
> If a packet is sent to a non-routable address, send succeeds, no error is reported.
> 
> Linux:
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
> 
> Mac OS X 12:
> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Update option description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9575/files
  - new: https://git.openjdk.org/jdk/pull/9575/files/7af4473c..07892867

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

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

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

From alanb at openjdk.org  Mon Aug  1 12:44:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 12:44:33 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
Message-ID: <S-e8f6wYKjg01So4HDbC5tyFIYZY8cbcHiBp8ypQmVQ=.dc8a6287-987c-4bb3-b7b9-0359e5d82f42@github.com>

On Mon, 1 Aug 2022 08:37:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
>> 
>> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
>> 
>> 
>> # release before
>> real 4m41.424s
>> user 24m18.064s
>> sys 1m16.440s
>> 
>> # release after
>> real 2m47.769s   ; -40%
>> user 23m44.622s
>> sys 1m15.240s
>> 
>> 
>> # fastdebug before
>> real 5m38.078s
>> user 67m23.516s
>> sys 1m56.446s
>> 
>> # fastdebug after
>> real 4m9.249s    ; -26%
>> user 67m21.940s
>> sys 1m57.625s
>
> Aleksey Shipilev 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:
> 
>  - Review comments
>  - Merge branch 'master' into JDK-8290531-loom-tests-parallel
>  - More fixes
>  - Fix

Marked as reviewed by alanb (Reviewer).

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

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

From shade at openjdk.org  Mon Aug  1 14:20:55 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 14:20:55 GMT
Subject: RFR: 8290531: Loom: Parallelize a few tests more deeply [v2]
In-Reply-To: <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
 <5MMhfw0fYAgq330Ur9wDYbn4Red8OTFp98A8XAZmk3o=.1fe933c3-e568-438d-b079-ff9ed119d2f8@github.com>
Message-ID: <vgBGKmXcKP2Hjb3kWT6oS39B-WcNuIMWwNMZBZmATVE=.9a3da547-b957-44fc-b536-7dbc27043127@github.com>

On Mon, 1 Aug 2022 08:37:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
>> 
>> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
>> 
>> 
>> # release before
>> real 4m41.424s
>> user 24m18.064s
>> sys 1m16.440s
>> 
>> # release after
>> real 2m47.769s   ; -40%
>> user 23m44.622s
>> sys 1m15.240s
>> 
>> 
>> # fastdebug before
>> real 5m38.078s
>> user 67m23.516s
>> sys 1m56.446s
>> 
>> # fastdebug after
>> real 4m9.249s    ; -26%
>> user 67m21.940s
>> sys 1m57.625s
>
> Aleksey Shipilev 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:
> 
>  - Review comments
>  - Merge branch 'master' into JDK-8290531-loom-tests-parallel
>  - More fixes
>  - Fix

Thank you!

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

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

From shade at openjdk.org  Mon Aug  1 14:24:47 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 1 Aug 2022 14:24:47 GMT
Subject: Integrated: 8290531: Loom: Parallelize a few tests more deeply
In-Reply-To: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
References: <NQ9WWR6F4LuzlmcIVDy4VnR5W_i0CYKNaU7DxMBcm5E=.2f1a562f-f243-4ce8-a7c7-86c596471fcd@github.com>
Message-ID: <aywnpNsqfo_BDGclxNWitNCOiJRHljWhT_FGo1RS0Xo=.8545a854-ad24-4ac9-9773-e03ef50ca823@github.com>

On Tue, 19 Jul 2022 12:52:11 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Some of the newly added Loom tests are long-running, and thus they delay the completion of otherwise very parallel tier1/jdk_loom. We can parallelize them a bit better to avoid these testing stalls. 
> 
> Improvements on Linux x86_64, TR 3970X, `jdk_loom hotspot_loom`:
> 
> 
> # release before
> real 4m41.424s
> user 24m18.064s
> sys 1m16.440s
> 
> # release after
> real 2m47.769s   ; -40%
> user 23m44.622s
> sys 1m15.240s
> 
> 
> # fastdebug before
> real 5m38.078s
> user 67m23.516s
> sys 1m56.446s
> 
> # fastdebug after
> real 4m9.249s    ; -26%
> user 67m21.940s
> sys 1m57.625s

This pull request has now been integrated.

Changeset: fcc11953
Author:    Aleksey Shipilev <shade at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fcc119531a3badaa5f7b5602b3d74c2ac5bf7b81
Stats:     42 lines in 3 files changed: 25 ins; 3 del; 14 mod

8290531: Loom: Parallelize a few tests more deeply

Reviewed-by: rpressler, jpai, alanb

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

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

From bpb at openjdk.org  Mon Aug  1 16:15:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 16:15:59 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
 <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
Message-ID: <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>

On Mon, 1 Aug 2022 06:07:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I think will require a small update to the javadoc to make it clear that both an empty syntax and empty pattern are illegal.

I read the existing specification

     * @throws  IllegalArgumentException
     *          If the parameter does not take the form: {@code syntax:pattern}

as covering both cases, but I suppose one could explicitly state that "neither syntax nor pattern may be empty."

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

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

From alanb at openjdk.org  Mon Aug  1 17:19:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 1 Aug 2022 17:19:06 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <-lg6t6PJmaP1UV63NoMMf8h_4LqLi81OMOEAuOWWT8I=.2be336be-1fbd-4234-acc5-28df85eaf98a@github.com>
 <mVUBW9LqMml_-y02gBEoXmHsTWsLknpr5-OwJ3Mg83E=.9ff587f3-f39e-42d4-81f6-6eccf6b4787f@github.com>
 <-7XdJeIgbOPuDPIlRt3WAzR9vJvy-94wnd7SKVF1r7s=.45aecf04-56ba-4d1a-a994-bea1065b39ec@github.com>
Message-ID: <knV-uC-ViKYQajHJGjzlE9DRNNADoLAUOi9vnx1ftlY=.6613c70c-25ba-4c70-86a8-7f60dc73ca66@github.com>

On Mon, 1 Aug 2022 16:13:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I read the existing specification
> 
> ```
>      * @throws  IllegalArgumentException
>      *          If the parameter does not take the form: {@code syntax:pattern}
> ```
> 
> as covering both cases, but I suppose one could explicitly state that "neither syntax nor pattern may be empty."

Alternatively, change "where ':' stands for itself" to "where syntax and pattern components are non-empty strings and ':' stands for itself" sot that it's up front when the input string is described.

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

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

From bpb at openjdk.org  Mon Aug  1 17:19:09 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 17:19:09 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
Message-ID: <8Mo9GDD-j9gFIOBv5hP7X1vkofvh5AztqHGi6_2ljpQ=.10937ed6-9668-4678-be9d-626f02108678@github.com>

On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove IAE message in JrtFileSystem.getPathMatcher()

> Alternatively, change "where ':' stands for itself" to "where syntax and pattern components are non-empty strings and ':' stands for itself" so that it's up front when the input string is described.

I think that reads better; will change accordingly.

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

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

From rriggs at openjdk.org  Mon Aug  1 17:35:51 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Aug 2022 17:35:51 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
Message-ID: <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>

On Thu, 21 Jul 2022 19:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove IAE message in JrtFileSystem.getPathMatcher()

> 

The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string.
If I read it correctly, it will now throw an exception instead of not matching.  It might be safer to not change that behavior.

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

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

From bpb at openjdk.org  Mon Aug  1 20:03:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 20:03:14 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
Message-ID: <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>

On Mon, 1 Aug 2022 17:32:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string. If I read it correctly, it will now throw an exception instead of not matching. It might be safer to not change that behavior.

Indeed for this code

        FileSystem fs = ...;
        PathMatcher pm = fs.getPathMatcher("glob:");
        System.out.println(pm.matches(Path.of("")));

without the proposed change `true` is printed but with the change an `IllegalArgumentException` is thrown so it would be safer to change

        if (pos <= 0 || pos == syntaxAndInput.length())

to

        if (pos <= 0)

as originally suggested.

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

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

From bpb at openjdk.org  Mon Aug  1 21:54:22 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 21:54:22 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
Message-ID: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>

> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).

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

  8057113: Remove API note

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8066/files
  - new: https://git.openjdk.org/jdk/pull/8066/files/d8df5141..198ab9a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=8066&range=16-17

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

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

From bpb at openjdk.org  Mon Aug  1 21:56:19 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 1 Aug 2022 21:56:19 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v14]
In-Reply-To: <GxNdEX0pSsoJNPweTYwMvdbql7Dz3RkqBsHYPtCl1yk=.224fec36-e196-416e-8cef-ec4353b674bc@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <5u-f4aM8qe3DiteaCYddUD9gI9A1HUeAfggTzYk9Sy8=.d87029e2-bf84-465e-afb1-3b4b631c6d42@github.com>
 <j9ji8eP3KzWoLig-hlzzVsu_iSobjfDEh3xreoklNNk=.587253ff-a8b8-4f22-9643-1db5227673f9@github.com>
 <GxNdEX0pSsoJNPweTYwMvdbql7Dz3RkqBsHYPtCl1yk=.224fec36-e196-416e-8cef-ec4353b674bc@github.com>
Message-ID: <1DfH4-RgU4Bz0Q79K0k2kzNKhdZOXrpKINGqmE4h2gA=.b102ad01-9a57-4718-9dd9-4a05dedbf4b5@github.com>

On Thu, 28 Jul 2022 18:10:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/Path.java line 102:
>> 
>>> 100:  * Otherwise stated, the internal representation might not be recoverable
>>> 101:  * from the derived path string. This applies to the {@code Path} as a whole
>>> 102:  * as well as to its components.
>> 
>> This comment doesn't seem specific to the enhancement proposed.
>> And its a bit vague, if/when included it might benefit from an example or mentioning the character set encoding of file names, if that's the context.
>
> I am wondering now whether this note would just add unnecessary confusion.

Removed confusing, vague API note in 198ab9a8ca1c05514abec932cd55d0b8597121d8.

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

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

From alanb at openjdk.org  Tue Aug  2 11:58:06 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 11:58:06 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
 <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
Message-ID: <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>

On Mon, 1 Aug 2022 19:59:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The existing code downstream of the check handles an empty glob or regex pattern as matching the empty string.
> If I read it correctly, it will now throw an exception instead of not matching. It might be safer to not change that behavior.

I'm 99% sure the original intention was for the empty pattern to be rejected with IAE. It was an implementation but that it checked if the index is length rather than length-1. That was JDK 7 and changing is now without be behavior change. I can't imagine the impact would be significant but I agree it's not worth it and maybe we just drop the check as per the JBS issue and update the spec to document the long standing behavior.

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

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

From bpb at openjdk.org  Tue Aug  2 15:34:46 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 15:34:46 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v3]
In-Reply-To: <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <r09g1pH5EWPWVRsxEf9AbRz5sxbxhfQ-YoInHprMpf0=.94cade1b-dbf4-44bf-bd3c-4f1dbda4e21c@github.com>
 <GHCy8nE9mmtwMJmnVPjSD-ujDIQ5qGevROhkJFQhJjk=.8d3fb35a-8fe0-42bc-8ce7-c3398d9af0e5@github.com>
 <v93hBhi1u5UbvtM46Fj2IzxQlelt4TAtq-Vy6v8_Sdc=.8d30e6c0-3245-4599-8255-a233b99191e9@github.com>
 <4WN1LiYc9WNrYnZA0TSPHm2UHdZuiWXAN5wDPk5t1lQ=.a2006a93-8ac0-4146-aae5-96579a5c66ae@github.com>
Message-ID: <iii9cIIFvvnw582FXPTPvMVEz1F2jTD96KYrxSnrKt4=.be54e202-ee9a-486a-a754-4eb38072b9f9@github.com>

On Tue, 2 Aug 2022 11:56:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I agree it's not worth it and maybe we just drop the check as per the JBS issue and update the spec to document the long standing behavior.

Agreed.

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

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

From bpb at openjdk.org  Tue Aug  2 16:18:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 16:18:16 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

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

  8290047: Remove check for ':' at last position

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/ff404d4b..1af2a4b4

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

  Stats: 26 lines in 6 files changed: 6 ins; 12 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9595.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9595/head:pull/9595

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

From alanb at openjdk.org  Tue Aug  2 16:47:13 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 16:47:13 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
Message-ID: <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>

On Tue, 2 Aug 2022 16:18:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Remove check for ':' at last position

src/java.base/share/classes/java/nio/file/FileSystem.java line 307:

> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
> 306:      * </pre></blockquote>
> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.

We could flesh this out a bit more with something like:

"where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."

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

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

From alanb at openjdk.org  Tue Aug  2 17:03:11 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:03:11 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v3]
In-Reply-To: <q8bgX3BbamXDaVpv4Scs-WSWmZSDxLIbK7jcSA0mS-s=.cbf500a9-e3de-465a-9057-ab6edceda279@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <q8bgX3BbamXDaVpv4Scs-WSWmZSDxLIbK7jcSA0mS-s=.cbf500a9-e3de-465a-9057-ab6edceda279@github.com>
Message-ID: <SSI9e3UqzERUQdW2U14eXLn0bnYEpwcFKPmoVmgL9AI=.0b2790ae-703f-4c35-a28a-ccbac10fb302@github.com>

On Mon, 1 Aug 2022 09:00:37 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
>> 
>> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
>> 
>> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
>> 
>> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
>> 
>> Testing performed (with IP_DONTFRAGMENT flag):
>> Windows 10:
>> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
>> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
>> 
>> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
>> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
>> If a packet is sent to a non-routable address, send succeeds, no error is reported.
>> 
>> Linux:
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
>> 
>> Mac OS X 12:
>> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update option description

src/jdk.net/windows/native/libextnet/WindowsSocketOptions.c line 83:

> 81:     int optval, rv, sz = sizeof(optval);
> 82: 
> 83:     if (!isIPv6) {

In passing, it might be easier to read if we change this code to use `if (isIPv6) { ... } then { ...}`. Not important here to do as part of this PR, just an observation.

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:05 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

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

  8290047: Improve description of syntaxAndPattern

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/1af2a4b4..b9de2604

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

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:08 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
 <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
Message-ID: <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>

On Tue, 2 Aug 2022 16:44:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8290047: Remove check for ':' at last position
>
> src/java.base/share/classes/java/nio/file/FileSystem.java line 307:
> 
>> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
>> 306:      * </pre></blockquote>
>> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.
> 
> We could flesh this out a bit more with something like:
> 
> "where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."

That is better.

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

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

From bpb at openjdk.org  Tue Aug  2 17:08:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 17:08:08 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v4]
In-Reply-To: <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <SCfarastS6h1-P6QDqtkm2Wer1u8j3whdFoaAeI_044=.c51ea972-ef12-4a2f-860b-9a84e7e02129@github.com>
 <up4cRR5tLs1lIgl4NXF4Tj_aUheEA_hIllRvNayk6cg=.917d1be8-beb4-4a75-b709-e47ffd325d55@github.com>
 <iH04OQwqxdGcmG29RugHAKzt3qphVm1y745Ny3uQDbg=.dc1d3874-cbc0-4ae4-8964-3c7867ac401f@github.com>
Message-ID: <G3LmbI7dcKsKZwYsKI-as-9j46sSvicxQrXG6rG95N8=.13c2f876-fc5d-494e-b776-1ffecd6a23b9@github.com>

On Tue, 2 Aug 2022 17:01:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/FileSystem.java line 307:
>> 
>>> 305:      * <i>syntax</i><b>:</b><i>pattern</i>
>>> 306:      * </pre></blockquote>
>>> 307:      * where <i>syntax</i> must not be empty and {@code ':'} stands for itself.
>> 
>> We could flesh this out a bit more with something like:
>> 
>> "where <i>syntax</i> is the non-empty name of the syntax,  <i>pattern</i> is a possibly-empty pattern string, and {@code ':'} stands for itself."
>
> That is better.

So changed in b9de2604b74c1082c6b0fa10435405120b971e93.

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

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

From alanb at openjdk.org  Tue Aug  2 17:15:50 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:15:50 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v2]
In-Reply-To: <o_pvBNGySroqgjLU05aZuUt39vsOG_QGBjWwT7U3uEo=.d47109e4-e14e-4fb0-b6a7-dda38eea5b2f@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <IBccnCd7NTeEQmNex5zcdEUgDc2VRlsstz6ZG1k_6KA=.935f531c-f2b0-4f95-81e2-55354a3635a0@github.com>
 <azs20p-kb5s5W674Hxz21eSd5mTqEpnPDOkUXMnQmyg=.1d3e05ce-19fd-446d-9673-c1dd1af87847@github.com>
 <o_pvBNGySroqgjLU05aZuUt39vsOG_QGBjWwT7U3uEo=.d47109e4-e14e-4fb0-b6a7-dda38eea5b2f@github.com>
Message-ID: <zeyVn_DH8eTUfIF3-R855kwWpEbOqmu8Qs5wB2iAV8U=.76b65316-f5fc-4121-93fc-36030372420d@github.com>

On Mon, 1 Aug 2022 08:40:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Passing a boolean matches what we're doing in `setIntOption0` and gets the job done. At this moment I don't see where passing `family` would be useful. Can we make that change when it's actually needed?

Okay, we can change it when we need it.


> 
> > The change to the comments [...] are a bit ugly
> 
> Agree. How about a more specific comment? Something like:
> 
> ```
> /* Mac OS does not support setting IPv4 options on IPv6 sockets. As a result, some/all IP_* options
>  are not applied to IPv4 datagrams sent from IPv6 sockets. */
> ```

The first part isn't quite right because socket level options do work, it's just IP level that are problematic. Maybe just drop the changes to Net.c rather than trying to document the macOS bugs.

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

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

From alanb at openjdk.org  Tue Aug  2 17:21:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Aug 2022 17:21:09 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <YSK9Ubc_oUPGd1q3e_nc9RuWWU7YqEJMXv7z7Pzev8E=.61ee1feb-5ad2-4d09-9143-101af8c6616a@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by alanb (Reviewer).

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

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

From rriggs at openjdk.org  Tue Aug  2 18:08:48 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 2 Aug 2022 18:08:48 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <UtXT1lzRoFIqjuRAUq2X-PvljUN9sjXpXnjKlknFYrI=.d353144c-fdb8-420c-aeb9-0393110bf843@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by rriggs (Reviewer).

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

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

From lancea at openjdk.org  Tue Aug  2 18:29:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Aug 2022 18:29:53 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v5]
In-Reply-To: <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
 <n1dzOBT0weAtChp919wT2H6QMviZzLzRHWtRt28Kk04=.0d2a1e38-ac56-46ae-9b0a-c2e46ef94b73@github.com>
Message-ID: <sL7mFC_V64KEGUpCIZZeBo-j9LXHE1TcSrPULilQECA=.b075c0cb-76e1-4662-9227-37a63604cf22@github.com>

On Tue, 2 Aug 2022 17:08:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
>> 
>>         int pos = syntaxAndInput.indexOf(':');
>>         if (pos <= 0 || pos == syntaxAndInput.length())
>> 
>> to
>> 
>>         if (pos <= 0)
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290047: Improve description of syntaxAndPattern

Marked as reviewed by lancea (Reviewer).

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

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

From mr at openjdk.org  Tue Aug  2 19:00:19 2022
From: mr at openjdk.org (Mark Reinhold)
Date: Tue, 2 Aug 2022 19:00:19 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
Message-ID: <hCcrjRQwf_1_lQ_PH9_NB4vcO9W5o3aCjtNcwm9W8sg=.41300a4b-0fef-4ce6-9d77-9a420dc1134f@github.com>

On Mon, 1 Aug 2022 21:54:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Remove API note

Marked as reviewed by mr (Lead).

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

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

From bpb at openjdk.org  Tue Aug  2 21:53:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 21:53:01 GMT
Subject: RFR: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index [v6]
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <VpmBBjA_3jVUnwPkwTEQmME-ulsJHcCWofeIFlzrjZ4=.3cb8a88a-494c-4548-8140-adf65007b397@github.com>

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

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

  8290047: Update overlooked jtrfs and zipfs tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9595/files
  - new: https://git.openjdk.org/jdk/pull/9595/files/b9de2604..b0eab55f

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

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

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

From bpb at openjdk.org  Tue Aug  2 23:49:52 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Aug 2022 23:49:52 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v4]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <cMhB14g5l8t0RO9OEZMa0XaxBLkOo6tp7zZ5_gJ3uqA=.4aa8186d-5b91-49fd-8816-743b89a0ed67@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

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 five additional commits since the last revision:

 - 8264744: Refactor into UnixCopyFile hierarchy
 - Merge
 - 8264744: Address review comments aside from refactoring
 - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
 - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9486/files
  - new: https://git.openjdk.org/jdk/pull/9486/files/6f3e4517..079dda1b

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

  Stats: 21968 lines in 777 files changed: 13834 ins; 5618 del; 2516 mod
  Patch: https://git.openjdk.org/jdk/pull/9486.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486

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

From aturbanov at openjdk.org  Wed Aug  3 06:23:45 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 3 Aug 2022 06:23:45 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v4]
In-Reply-To: <cMhB14g5l8t0RO9OEZMa0XaxBLkOo6tp7zZ5_gJ3uqA=.4aa8186d-5b91-49fd-8816-743b89a0ed67@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <cMhB14g5l8t0RO9OEZMa0XaxBLkOo6tp7zZ5_gJ3uqA=.4aa8186d-5b91-49fd-8816-743b89a0ed67@github.com>
Message-ID: <2leIcknr0h64UWWTuv8ZGLTZ7TvBKu9LIB1__LX9oso=.cc564e36-885c-4c9d-8c58-4727ef575c4e@github.com>

On Tue, 2 Aug 2022 23:49:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> 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 five additional commits since the last revision:
> 
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - 8264744: Address review comments aside from refactoring
>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

src/java.base/aix/classes/sun/nio/fs/CloneFile.java line 46:

> 44:      *
> 45:      * @param src the path of the source file
> 46:      * @param dst the path of the desintation file (clone)

typo `desintation`. It seems it was copied in all CloneFile.java files.

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

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

From djelinski at openjdk.org  Wed Aug  3 09:43:44 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 3 Aug 2022 09:43:44 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v4]
In-Reply-To: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
Message-ID: <ZLuJbtNGN-mSliLjzCvoMrXgUYMG87W9n_fp-DqYOpU=.f7009f02-9cd8-4cc6-8eb0-ab459d142fa3@github.com>

> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
> 
> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
> 
> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
> 
> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
> 
> Testing performed (with IP_DONTFRAGMENT flag):
> Windows 10:
> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
> 
> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
> If a packet is sent to a non-routable address, send succeeds, no error is reported.
> 
> Linux:
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
> 
> Mac OS X 12:
> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.

Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:

  Revert Net.c comment changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9575/files
  - new: https://git.openjdk.org/jdk/pull/9575/files/07892867..339d6bec

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

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

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

From dfuchs at openjdk.org  Wed Aug  3 11:03:40 2022
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 3 Aug 2022 11:03:40 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <CflYKTgGuEth9cBpvx-_nme9-IyesWKwtVvPN7mcTvI=.9e217399-8639-4bcc-bfb0-a8eb59531176@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Changes to HttpURLConnection look good to me

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

Marked as reviewed by dfuchs (Reviewer).

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

From alanb at openjdk.org  Wed Aug  3 12:49:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 12:49:40 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v4]
In-Reply-To: <ZLuJbtNGN-mSliLjzCvoMrXgUYMG87W9n_fp-DqYOpU=.f7009f02-9cd8-4cc6-8eb0-ab459d142fa3@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <ZLuJbtNGN-mSliLjzCvoMrXgUYMG87W9n_fp-DqYOpU=.f7009f02-9cd8-4cc6-8eb0-ab459d142fa3@github.com>
Message-ID: <-SeWHkjgUfEWLhQc47bOvAmPdZgTJz-SWDgCNNpImnI=.2d1845ae-81a7-44de-aacd-74c02d018f04@github.com>

On Wed, 3 Aug 2022 09:43:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
>> 
>> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
>> 
>> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
>> 
>> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
>> 
>> Testing performed (with IP_DONTFRAGMENT flag):
>> Windows 10:
>> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
>> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
>> 
>> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
>> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
>> If a packet is sent to a non-routable address, send succeeds, no error is reported.
>> 
>> Linux:
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
>> 
>> Mac OS X 12:
>> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Net.c comment changes

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Wed Aug  3 15:18:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 15:18:10 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v4]
In-Reply-To: <2leIcknr0h64UWWTuv8ZGLTZ7TvBKu9LIB1__LX9oso=.cc564e36-885c-4c9d-8c58-4727ef575c4e@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <cMhB14g5l8t0RO9OEZMa0XaxBLkOo6tp7zZ5_gJ3uqA=.4aa8186d-5b91-49fd-8816-743b89a0ed67@github.com>
 <2leIcknr0h64UWWTuv8ZGLTZ7TvBKu9LIB1__LX9oso=.cc564e36-885c-4c9d-8c58-4727ef575c4e@github.com>
Message-ID: <xiyxioca5SPfWIieuCapwVqMAzffB90FjvQN3D_55Pk=.0ba35b99-dff8-48a3-9888-d8e63e3835ee@github.com>

On Wed, 3 Aug 2022 06:19:49 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> typo `desintation`. It seems it was copied in all CloneFile.java files.

Thanks, I think I need a spell checker.

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

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

From bpb at openjdk.org  Wed Aug  3 15:22:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 15:22:01 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v5]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <Cfg8f-71HtlUxVRsOFcWPhU-bTUzJFawGE57RvLKRWM=.06b0f21c-f462-48e9-8b6f-eb5288ced4b6@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

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

  8264744: Fix typo desintation -> destination

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9486/files
  - new: https://git.openjdk.org/jdk/pull/9486/files/079dda1b..9810352d

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

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

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

From bpb at openjdk.org  Wed Aug  3 15:22:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 15:22:03 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v4]
In-Reply-To: <xiyxioca5SPfWIieuCapwVqMAzffB90FjvQN3D_55Pk=.0ba35b99-dff8-48a3-9888-d8e63e3835ee@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <cMhB14g5l8t0RO9OEZMa0XaxBLkOo6tp7zZ5_gJ3uqA=.4aa8186d-5b91-49fd-8816-743b89a0ed67@github.com>
 <2leIcknr0h64UWWTuv8ZGLTZ7TvBKu9LIB1__LX9oso=.cc564e36-885c-4c9d-8c58-4727ef575c4e@github.com>
 <xiyxioca5SPfWIieuCapwVqMAzffB90FjvQN3D_55Pk=.0ba35b99-dff8-48a3-9888-d8e63e3835ee@github.com>
Message-ID: <rfvC7HI-Duwt4uS-Boiekf4HVOl7gsmYih316jR4qgc=.32aa38ae-56ef-4c3e-b300-770806eda957@github.com>

On Wed, 3 Aug 2022 15:14:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/aix/classes/sun/nio/fs/CloneFile.java line 46:
>> 
>>> 44:      *
>>> 45:      * @param src the path of the source file
>>> 46:      * @param dst the path of the desintation file (clone)
>> 
>> typo `desintation`. It seems it was copied in all CloneFile.java files.
>
>> typo `desintation`. It seems it was copied in all CloneFile.java files.
> 
> Thanks, I think I need a spell checker.

Fixed in 9810352d8ba77fd0de56ac24540c3714400a455e.

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

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

From alanb at openjdk.org  Wed Aug  3 15:42:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 15:42:51 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
Message-ID: <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>

On Mon, 1 Aug 2022 21:54:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Remove API note

Thank you for persisting with this one, the original Path::getExtension method was prototyped more 12 years ago, the main issue at the being being trying to get to a saner definition of an extension. You've got this to a good place.

src/java.base/share/classes/java/nio/file/Path.java line 256:

> 254:      * extension is the portion of the {@linkplain #getFileName file name}
> 255:      * string after the last period character ('.', U+002E FULL STOP). Leading
> 256:      * period characters in the string are ignored. If there is no  extension,

Minor nit, you've got a double space in "no  extension"

src/java.base/share/classes/java/nio/file/Path.java line 258:

> 256:      * period characters in the string are ignored. If there is no  extension,
> 257:      * then {@code null} is returned. This will occur if the path has zero
> 258:      * elements ({@link #getFileName()} returns {@code null}), the file name

The path has zero elements is correct but it might be clearer to say "The path doesn't have a file contain".

src/java.base/share/classes/java/nio/file/Path.java line 272:

> 270:      * return lastPeriod == fileName.length() - 1 ?
> 271:      *     "" :
> 272:      *     fileName.substring(lastPeriod + 1);

Can L270-272 in the implSpec be cleaned up? It's okay to use the ternary operator but would be easier to read if there is parenthesis around the condition and the ? and : weren't at the end of the lines.

src/java.base/share/classes/java/nio/file/Path.java line 297:

> 295:                 if (lastPeriodIndex == length - 1) {
> 296:                     // null if all period characters, otherwise empty
> 297:                     return fileNameString.matches("\\.{" + length + "}") ?

Using a regular expression here is probably okay or the initial PR but I could imagine this show up in profiles and needing to be re-implemented.

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

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

From bpb at openjdk.org  Wed Aug  3 17:12:56 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 3 Aug 2022 17:12:56 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
 <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
Message-ID: <MjZRAxr-YpqD006oKNUvUy1NCPew3jn_UoH_HjFR7SQ=.0331abea-dce8-4f74-a225-b4f8e8e96509@github.com>

On Wed, 3 Aug 2022 15:33:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The path has zero elements is correct but it might be clearer to say "The path doesn't have a file contain".

Do you intend "the path does not have a file name"?

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

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

From alanb at openjdk.org  Wed Aug  3 17:12:56 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 3 Aug 2022 17:12:56 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <MjZRAxr-YpqD006oKNUvUy1NCPew3jn_UoH_HjFR7SQ=.0331abea-dce8-4f74-a225-b4f8e8e96509@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
 <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
 <MjZRAxr-YpqD006oKNUvUy1NCPew3jn_UoH_HjFR7SQ=.0331abea-dce8-4f74-a225-b4f8e8e96509@github.com>
Message-ID: <DjnsaL6TboPPKNq6p0a0-6m_GWCeUL_Le29UPETFaUY=.fb55f4ef-4ca8-4cb0-96c7-0b98a592e7c7@github.com>

On Wed, 3 Aug 2022 16:38:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Do you intend "the path does not have a file name"?

Yes, I think that would be better than "has zero elements".

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

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

From smarks at openjdk.org  Wed Aug  3 22:26:21 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 22:26:21 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
Message-ID: <rTlxP3DSTm3vHa-5YYEMQMTVa6P8QlA05VoMRpeWSsg=.feffabc3-6429-470c-aa48-1057909a6adc@github.com>

On Mon, 1 Aug 2022 21:54:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Remove API note

src/java.base/share/classes/java/nio/file/Path.java line 256:

> 254:      * extension is the portion of the {@linkplain #getFileName file name}
> 255:      * string after the last period character ('.', U+002E FULL STOP). Leading
> 256:      * period characters in the string are ignored. If there is no  extension,

The definition of the extension is in two sentences, first this:

> The extension is the portion of the file name string after the last period character.

Followed by this:

> Leading period characters in the string are ignored.

This is confusing, since the first sentence reads like a complete definition. But the second sentence modifies it, forcing the reader to go back and reinterpret.

I'd suggest putting the definition into a single sentence, something like this:

> The extension is the portion of the _file name_ string
> after the last period character (...) that is not a leading
> period character in the string.

(I've omitted the link and the Unicode callout here for ease of reading, but I think they should be
included in the actual markup, as before.)

(Also, to my ear "dot" reads better than "period" since conventionally a filename like `abc.txt` would be read aloud as "aye bee see dot tee ex tee". But it's ok if you want to stick with period consistently.)

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

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

From smarks at openjdk.org  Wed Aug  3 22:26:24 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 22:26:24 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
 <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
Message-ID: <D40FbzDAN8nyejZGX_kl3sGDKv0-vUh3iW6mZMeWsLE=.8aad0e3e-e86a-449f-abcf-b2a5d850ec0e@github.com>

On Wed, 3 Aug 2022 15:35:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8057113: Remove API note
>
> src/java.base/share/classes/java/nio/file/Path.java line 272:
> 
>> 270:      * return lastPeriod == fileName.length() - 1 ?
>> 271:      *     "" :
>> 272:      *     fileName.substring(lastPeriod + 1);
> 
> Can L270-272 in the implSpec be cleaned up? It's okay to use the ternary operator but would be easier to read if there is parenthesis around the condition and the ? and : weren't at the end of the lines.

I would suggest that the code in the implSpec be removed. It doesn't add anything and it potentially confuses things. There needs to be an implSpec though since this is a default method. The essential thing to have in implSpec is self-calls on `this`. The only self-call is to `getFileName`, so I'd include in the implSpec some prose to say that `getFileName` is called and (if non-null) is converted to a String, upon which further processing is done.

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

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

From smarks at openjdk.org  Wed Aug  3 22:30:46 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 22:30:46 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
Message-ID: <xCET-h0u3SbEJGl0aypgSdFO-Eohf7L2c89rKnA3GVQ=.1fdbea9d-af9c-4c1f-981f-0204f96d092c@github.com>

On Mon, 1 Aug 2022 21:54:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Remove API note

src/java.base/share/classes/java/nio/file/Path.java line 262:

> 260:      * is a period character. If the last character is a period character but
> 261:      * some other character is not, then the extension is the
> 262:      * {@linkplain String#isEmpty() empty} string.

> ... or only the first character is a period character.

This needs to be updated to be consistent with the "all leading periods" rule, something like

> ... or all the period characters are leading periods.

Also:

> If the last character is a period character but some other character is not, then the extension is the
> empty string.

I'm not sure what this is trying to say. Is it saying, if the last character is a period, and it is not a leading period, then the extension is empty? If so, then maybe it could say just that; or possibly the statement could be removed since it's a consequence of the definition given earlier.

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

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

From smarks at openjdk.org  Wed Aug  3 22:36:33 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 22:36:33 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
 <b3xQriFG3x4SVb65qbWlL1nozHpDC6tg9iGEqO_-jA8=.12842a1d-2d69-4d8b-8b94-f1fb2dd49d74@github.com>
Message-ID: <QmVd4k1hrUVhFGDE8jmoaFaAiLkVYeWDKq_jxuEgduA=.7053c749-543a-456f-9e50-8bc8671a76ee@github.com>

On Wed, 3 Aug 2022 15:37:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8057113: Remove API note
>
> src/java.base/share/classes/java/nio/file/Path.java line 297:
> 
>> 295:                 if (lastPeriodIndex == length - 1) {
>> 296:                     // null if all period characters, otherwise empty
>> 297:                     return fileNameString.matches("\\.{" + length + "}") ?
> 
> Using a regular expression here is probably okay or the initial PR but I could imagine this show up in profiles and needing to be re-implemented.

Yeah I don't think we want to use regex here. I'd suggest something like this:

    int lastDot = fileNameString.lastIndexOf('.');
    for (int j = lastDot - 1; j >= 0; j--) {
        if (fileNameString.charAt(j) != '.') {
            return fileNameString.substring(lastDot + 1);
        }
    }
    return null;

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

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

From smarks at openjdk.org  Wed Aug  3 22:36:35 2022
From: smarks at openjdk.org (Stuart Marks)
Date: Wed, 3 Aug 2022 22:36:35 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v18]
In-Reply-To: <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <qmgVJRTNwU0WczCXxeiQLffqX64OpavJPAymyNGckyI=.d7c7d2ed-3066-4c18-b86e-4b8ce506ffb5@github.com>
Message-ID: <qaIDBqFqbIBFaCrqLkY7NHn2G8atp2csmD8WpLrIKVc=.ffa2daea-161f-4ae4-92b9-3b52a2cec282@github.com>

On Mon, 1 Aug 2022 21:54:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Resurrection of the proposal to add a method to obtain the filename extension originated in PR [2319](https://github.com/openjdk/jdk/pull/2319).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8057113: Remove API note

test/jdk/java/nio/file/Path/Extensions.java line 57:

> 55:             {"..a",            "a"},
> 56:             {"...a",           "a"},
> 57:             {"....a",          "a"},

The test cases on the above few lines need to be updated to conform to the "all leading dots" rule; they should all return null instead of "a".

test/jdk/java/nio/file/Path/Extensions.java line 61:

> 59:             {"...a.b",         "b"},
> 60:             {"...a.b.",        ""},
> 61:             {"..foo",          "foo"},

Also returns null to conform to "all leading dots ignored" rule.

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

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

From michaelm at openjdk.org  Thu Aug  4 10:51:47 2022
From: michaelm at openjdk.org (Michael McMahon)
Date: Thu, 4 Aug 2022 10:51:47 GMT
Subject: RFR: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
 [v4]
In-Reply-To: <ZLuJbtNGN-mSliLjzCvoMrXgUYMG87W9n_fp-DqYOpU=.f7009f02-9cd8-4cc6-8eb0-ab459d142fa3@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
 <ZLuJbtNGN-mSliLjzCvoMrXgUYMG87W9n_fp-DqYOpU=.f7009f02-9cd8-4cc6-8eb0-ab459d142fa3@github.com>
Message-ID: <y97yHwPDOo1nqQUcOY85k7BasKnusWdpYmGxULWvSuY=.1e7e2481-72a5-4cab-a5ab-2d96b2828ec3@github.com>

On Wed, 3 Aug 2022 09:43:44 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
>> 
>> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
>> 
>> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
>> 
>> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
>> 
>> Testing performed (with IP_DONTFRAGMENT flag):
>> Windows 10:
>> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
>> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
>> 
>> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
>> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
>> If a packet is sent to a non-routable address, send succeeds, no error is reported.
>> 
>> Linux:
>> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
>> 
>> Mac OS X 12:
>> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.
>
> Daniel Jeli?ski has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert Net.c comment changes

The change is fine. The Net.c comment is not worth arguing over.

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

Marked as reviewed by michaelm (Reviewer).

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

From djelinski at openjdk.org  Thu Aug  4 10:55:36 2022
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 4 Aug 2022 10:55:36 GMT
Subject: Integrated: 8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header
In-Reply-To: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
References: <M7lwFa8MXjoFP4iV9qSUjmqgtWa8RkdUqpR1ZdE2Iog=.7ed37d11-bbcf-4b5c-b99a-279b1c3692aa@github.com>
Message-ID: <EWRpvYs7lcsM10JLQYDr6-iVKK6W3SX_5aTc60FgQtQ=.16fc6ccf-ed09-4b1d-9435-b4709e8c3dbe@github.com>

On Wed, 20 Jul 2022 17:19:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> This patch partially fixes the issue where IPv6 sockets were fragmenting outgoing IPv4 datagrams even when IP_DONTFRAGMENT flag was set. Specifically, it fixes the issue on Linux and Windows. As far as I could tell, the issue is unfixable on Mac OS X.
> 
> All systems have a separate DONTFRAGMENT flag for IPv4 and IPv6. Each flag only affects packets from its address family; if we want to disable fragmentation of both IPv4 and IPv6 packets sent by an IPv6 socket, we need to set both IPv4 and IPv6 flags. This is similar to other already existing options like IP_TOS or IP_MULTICAST_*.
> 
> On Mac OS X it's impossible to set an IPv4 socket option on an IPv6 socket; attempting to do so results in an error. This is a known issue with Mac OS X; on that system we return false from [Net#shouldSetBothIPv4AndIPv6Options](https://github.com/openjdk/jdk/blob/2342684f2cd91a2e5f43dd271e95836aa78e7d0a/src/java.base/unix/native/libnio/ch/Net.c#L159) to avoid setting IPv4 options.
> 
> As far as I can tell, non-privileged users have no way to check if the DF flag was set or if the packet was fragmented. I implemented a test that attempted to send a large packet over a physical interface and expected SocketException / EMSGSIZE; the test frequently failed for unrelated reasons, so I decided against including it. Loopback interface has infinite MTU on some systems, so can not be used for this test.
> 
> Testing performed (with IP_DONTFRAGMENT flag):
> Windows 10:
> With this patch, IPv4 packets sent from IPv6 socket have the DF flag; sending an IPv4 packet larger than the interface MTU results in EMSGSIZE and no packet is sent. Without this patch, the packet is fragmented and sent without DF flag.
> Sending IPv6 packets larger than the interface MTU usually results in EMSGSIZE. It may succeed if the destination address is non-routable.
> 
> For other systems I could not capture packets, so I can only report the observed behavior of sending packets.
> Windows 2012 and 2016 (IP_MTU_DISCOVER not supported):
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch sending a large IPv6 packet succeeds.
> If a packet is sent to a non-routable address, send succeeds, no error is reported.
> 
> Linux:
> With this patch, sending any packet exceeding MTU size fails with EMSGSIZE. Without this patch, sending large IPv4 packets from IPv6 sockets succeeds.
> 
> Mac OS X 12:
> Sending an IPv6 packet exceeding MTU size fails with EMSGSIZE. Sending large IPv4 packets from IPv4 sockets also fails with EMSGSIZE. Sending large IPv4 packets from IPv6 sockets succeeds. The patch does not change the observed behavior.

This pull request has now been integrated.

Changeset: ce61eb6f
Author:    Daniel Jeli?ski <djelinski at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ce61eb6ff99eaaece463091b8481e27f84f80684
Stats:     140 lines in 9 files changed: 6 ins; 66 del; 68 mod

8290349: IP_DONTFRAGMENT doesn't set DF bit in IPv4 header

Reviewed-by: michaelm, alanb

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

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

From plevart at openjdk.org  Thu Aug  4 11:06:40 2022
From: plevart at openjdk.org (Peter Levart)
Date: Thu, 4 Aug 2022 11:06:40 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from virtual
 thread(s)
Message-ID: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>

This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

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

Commit messages:
 - new internal CarrierThreadLocal as a base for TerminatingThreadLocal

Changes: https://git.openjdk.org/jdk/pull/9743/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9743&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8291897
  Stats: 255 lines in 9 files changed: 193 ins; 9 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/9743.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9743/head:pull/9743

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

From alanb at openjdk.org  Thu Aug  4 19:40:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Aug 2022 19:40:34 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>

On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

I did a quick pass over this and it looks good. Adding CarrierThreadLocal is a good idea and as it allows the use-sites to be revert/cleaned up. Just a few minor comments so far.

src/java.base/share/classes/sun/nio/ch/Util.java line 233:

> 231:         }
> 232: 
> 233:         BufferCache cache = bufferCache.get();

I assume JLA is no longer needed.

test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40:

> 38:  * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java
> 39:  * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal
> 40:  */

If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. 

You might want to add the bugId to the `@bug` list too.

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

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

From bpb at openjdk.org  Fri Aug  5 03:11:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 03:11:24 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X
Message-ID: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>

Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

Commit messages:
 - 8151430: (fs) BasicFileAttributeView.setTimes should support setting file create time on OS X

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

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

From aturbanov at openjdk.org  Fri Aug  5 06:58:58 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 5 Aug 2022 06:58:58 GMT
Subject: Integrated: 8291061: Improve thread safety of FileTime.toString and
 toInstant
In-Reply-To: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com>
References: <0oo5z-zo-nq2EbxR5u97CQRkTYBR6fAaMuEo23OqUH4=.abd872b5-4515-409b-b262-26310003c154@github.com>
Message-ID: <gHHPyQMtx7Xhc-G31_mnReryCdOAGslbGadRPT3fiDw=.8e498725-3f4b-4a40-9f03-a676d9ab3f11@github.com>

On Fri, 22 Jul 2022 07:34:19 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> We need to read fields `instant`/`valueAsString` once, as to dodge/resolve the data race on reading lazily-initialized fields.

This pull request has now been integrated.

Changeset: 6e7cd762
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6e7cd7627d7e5c885b34afb1cb9458221a279e08
Stats:     6 lines in 1 file changed: 5 ins; 0 del; 1 mod

8291061: Improve thread safety of FileTime.toString and toInstant

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Fri Aug  5 08:31:47 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 08:31:47 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <SpLkxRFlRLtWdCBi2-LWYAY76gML-iPNDqm23PZNr7I=.b591e0c4-1ad4-4750-92ef-fda8639788e7@github.com>

On Fri, 5 Aug 2022 03:03:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

Have you tried adding setattrlist to BsdNativeDispatcher instead of UnixNativeDispatcher?

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

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

From plevart at openjdk.org  Fri Aug  5 09:43:46 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:43:46 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
Message-ID: <Blmz01MMivZFrWFKuOa-SJpqnNUHhaQJCLXe5T7E2NQ=.1a49b007-1d30-4a09-8688-df7335c4e123@github.com>

On Thu, 4 Aug 2022 15:54:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
>> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
>> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
>> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.
>
> src/java.base/share/classes/sun/nio/ch/Util.java line 233:
> 
>> 231:         }
>> 232: 
>> 233:         BufferCache cache = bufferCache.get();
> 
> I assume JLA is no longer needed.

Right, I forgot to remove this one.

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

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

From plevart at openjdk.org  Fri Aug  5 09:54:36 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:54:36 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

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

  Removed unused JLA, SharedSecrets, added @enablePreview test annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9743/files
  - new: https://git.openjdk.org/jdk/pull/9743/files/fa2078e4..2339b87f

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

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

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

From plevart at openjdk.org  Fri Aug  5 09:54:39 2022
From: plevart at openjdk.org (Peter Levart)
Date: Fri, 5 Aug 2022 09:54:39 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <svmVckjkmhVmRA_TGajjgX1RhBuKymqLyzE3aYH4_RI=.04b25582-ff5b-482e-8e3a-56cf1be0c026@github.com>
Message-ID: <v3DTLd_meQGpJeXYY0wJ5-ACAamQvL4KAwpuKX0WAwE=.a16afa01-639d-4cd2-8093-04032d1ef16b@github.com>

On Thu, 4 Aug 2022 15:55:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Removed unused JLA, SharedSecrets, added @enablePreview test annotation
>
> test/jdk/jdk/internal/misc/TerminatingThreadLocal/TestTerminatingThreadLocal.java line 40:
> 
>> 38:  * @compile --enable-preview -source ${jdk.version} TestTerminatingThreadLocal.java
>> 39:  * @run main/othervm --enable-preview -Djdk.virtualThreadScheduler.parallelism=1 -Djdk.virtualThreadScheduler.maxPoolSize=2 TestTerminatingThreadLocal
>> 40:  */
> 
> If you add `@enablePreview` then it will allow you to drop the `@compile` line and drop `--enable-preview from the `@run` tag. 
> 
> You might want to add the bugId to the `@bug` list too.

Done in next commit.

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

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

From bpb at openjdk.org  Fri Aug  5 16:12:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 16:12:51 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v2]
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <79yWCwoyX3XnRMQ77mTXAjnhoaZy3u0S8rbl6iMrPdM=.a6c2b191-7872-4897-bb5e-b1a4323507f8@github.com>

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

  8151430: Move setattrlist to BsdNativeDispatcher

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9762/files
  - new: https://git.openjdk.org/jdk/pull/9762/files/3339e32f..46a7e949

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

  Stats: 263 lines in 8 files changed: 156 ins; 104 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/9762.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9762/head:pull/9762

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

From bpb at openjdk.org  Fri Aug  5 16:12:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 16:12:51 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X
In-Reply-To: <SpLkxRFlRLtWdCBi2-LWYAY76gML-iPNDqm23PZNr7I=.b591e0c4-1ad4-4750-92ef-fda8639788e7@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <SpLkxRFlRLtWdCBi2-LWYAY76gML-iPNDqm23PZNr7I=.b591e0c4-1ad4-4750-92ef-fda8639788e7@github.com>
Message-ID: <02zsqoy-CibnzakflcRaDTxJXUNk1D6ApTQUjghm4-8=.882ad6b2-75e2-40ce-afeb-7dd4fb58477d@github.com>

On Fri, 5 Aug 2022 08:28:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Have you tried adding setattrlist to BsdNativeDispatcher instead of UnixNativeDispatcher?

Sadly, no, as that's where it clearly belongs. So changed in 46a7e94956654f154143ac1c1c59480e85792122. Thanks for the suggestion.

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

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

From bpb at openjdk.org  Fri Aug  5 16:38:20 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 16:38:20 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v3]
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <8uSHkfUfSDexpESm59qJI6KR7wF6B5FSILsiYm1x0cA=.3ac485c2-8281-4524-919e-1cbff2c6cd1a@github.com>

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

  8151430: Minor format cleanup in BsdBasicFileAttributeView; remove extraneous file

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9762/files
  - new: https://git.openjdk.org/jdk/pull/9762/files/46a7e949..fa4452c3

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

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

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

From alanb at openjdk.org  Fri Aug  5 17:08:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 5 Aug 2022 17:08:09 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v3]
In-Reply-To: <8uSHkfUfSDexpESm59qJI6KR7wF6B5FSILsiYm1x0cA=.3ac485c2-8281-4524-919e-1cbff2c6cd1a@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <8uSHkfUfSDexpESm59qJI6KR7wF6B5FSILsiYm1x0cA=.3ac485c2-8281-4524-919e-1cbff2c6cd1a@github.com>
Message-ID: <f_jGLD1cfA15UmPEIfCXoouW1TDl9aKcIjIkgkPPZdg=.bd7f4553-a938-41c0-90c2-5872a59c5ef4@github.com>

On Fri, 5 Aug 2022 16:38:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8151430: Minor format cleanup in BsdBasicFileAttributeView; remove extraneous file

src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java line 81:

> 79:             UnixPath file = UnixPath.toUnixPath(obj);
> 80:             boolean followLinks = Util.followLinks(options);
> 81:             return new BsdBasicFileAttributeView(file, followLinks);

PosixFileAttributeView extends BasicFileAttributeView so it's possible to obtain the former and invoke setTimes too. I need to think more on how to make that work.

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

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

From bpb at openjdk.org  Fri Aug  5 17:27:06 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 17:27:06 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v3]
In-Reply-To: <f_jGLD1cfA15UmPEIfCXoouW1TDl9aKcIjIkgkPPZdg=.bd7f4553-a938-41c0-90c2-5872a59c5ef4@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <8uSHkfUfSDexpESm59qJI6KR7wF6B5FSILsiYm1x0cA=.3ac485c2-8281-4524-919e-1cbff2c6cd1a@github.com>
 <f_jGLD1cfA15UmPEIfCXoouW1TDl9aKcIjIkgkPPZdg=.bd7f4553-a938-41c0-90c2-5872a59c5ef4@github.com>
Message-ID: <eN23pE2yBM5DF36U3sy2-AMLzLWrlkvNSLe9TWVOD08=.f89f4b04-4feb-4a41-89ad-1da4a13c11d9@github.com>

On Fri, 5 Aug 2022 17:04:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8151430: Minor format cleanup in BsdBasicFileAttributeView; remove extraneous file
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java line 81:
> 
>> 79:             UnixPath file = UnixPath.toUnixPath(obj);
>> 80:             boolean followLinks = Util.followLinks(options);
>> 81:             return new BsdBasicFileAttributeView(file, followLinks);
> 
> PosixFileAttributeView extends BasicFileAttributeView so it's possible to obtain the former and invoke setTimes too. I need to think more on how to make that work.

Perhaps `setTimes()` could be moved to a static method invoked by both `BsdBasicFileAttributeView` and a new `BsdPosixFileAttributeView`?

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

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

From bpb at openjdk.org  Fri Aug  5 17:54:28 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 5 Aug 2022 17:54:28 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v4]
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <NC388ypZu9vjcxTorn0q0Ti1zAx5EhrXL6vB36NCC1Y=.ed904d3b-ad5a-49a2-8b51-8db11c1b3eea@github.com>

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

  8151430: Override setTimes() in the new BsdPosixFileAttributeView class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9762/files
  - new: https://git.openjdk.org/jdk/pull/9762/files/fa4452c3..5b48fe09

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

  Stats: 81 lines in 4 files changed: 69 ins; 5 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/9762.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9762/head:pull/9762

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

From chegar999 at gmail.com  Fri Aug  5 19:43:58 2022
From: chegar999 at gmail.com (Chris Hegarty)
Date: Fri, 5 Aug 2022 20:43:58 +0100
Subject: Extended socket options and module layers
Message-ID: <7c432893-681f-b20b-fc3a-97c4bbab08d6@gmail.com>

Hi,

Just dropping a note here about a recent issue that I ran into, that
could help others. (I should have known better, but several different
conditions conspired which lead to the bug [1]).

Elasticsearch starts with all code on the module path (the class path
is empty). The org.elasticsearch.server module is the root, and contains
the main entry point. We load extensions to the server in their own
module layer. One of these extensions is a network extension which,
among other things, uses Netty and NIO socket channels. This network
extension sets the TCP_KEEPXXX extended socket options. The code
involved here is a little old, and used reflection so as to compile on
older JDKs, hence the code tolerated the absence of the extended
socket options type (from the jdk.net module). This lead to the bug,
where the TCP_KEEPXXX were not set, but there was no failure or log of
such. But why did this happen?

Our code in the boot layer does not directly use anything from the
jdk.net module, so does not `require jdk.net`. We defined the code in
our network extension to a module layer, l, that is a child of the boot
layer. The network extension code in layer, l, `requires jdk.net`, but
that is too late - the socket channel implementation in java.base is not
in a position to provide support for the extended options, since jdk.net
is not resolved in the boot configuration/layer. The solution is
trivial, `--add-modules jdk.net` [2].

I'm not sure that there is anything that should (or could) be done about
this - an SPI for extended options is not really viable or suitable. Our
use of reflection really obfuscated the bug, but equally code that
deals with the extended socket options is often conditional so as to
tolerate running on different platforms. Anyway, I thought it worth
sharing, since it's both interesting (to me) and informative (in case
someone else encounters similar).

-Chris.

[1] https://github.com/elastic/elasticsearch/issues/88897
[2] https://github.com/elastic/elasticsearch/pull/88935


From Alan.Bateman at oracle.com  Sat Aug  6 07:43:39 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 6 Aug 2022 08:43:39 +0100
Subject: Extended socket options and module layers
In-Reply-To: <7c432893-681f-b20b-fc3a-97c4bbab08d6@gmail.com>
References: <7c432893-681f-b20b-fc3a-97c4bbab08d6@gmail.com>
Message-ID: <256c5662-a1a1-da3f-d71c-0c90e2bbe5aa@oracle.com>

On 05/08/2022 20:43, Chris Hegarty wrote:
> :
>
> I'm not sure that there is anything that should (or could) be done about
> this - an SPI for extended options is not really viable or suitable. Our
> use of reflection really obfuscated the bug, but equally code that
> deals with the extended socket options is often conditional so as to
> tolerate running on different platforms. Anyway, I thought it worth
> sharing, since it's both interesting (to me) and informative (in case
> someone else encounters similar).
Run-time argumentation of JDK modules was on the list of the 
requirements for Project Jigsaw at one point but it bring a significant 
number of surprises and may not be worth it. Right now it is limited to 
support tooling, e.g. loading the JMX agent at run-time, where it is 
mostly transparent that the augmentation is done by via a child layer.

I think there is merit is re-examining the integration of the jdk.net 
module. Not high priority but I think the "triggered registration" 
should be removed and the implemented of extended socket options should 
move to java.base, the jdk.net module should just expose the API. That 
would align with how extended open/copy options work in the 
jdk.unsupported module and the extended map mode in the jdk.nio.mapmode 
module. It would have internal mirrors for complex socket options but 
that isn't too hard to do.

Introducing a service interface and having jdk.net provide an 
implementation may be worth thinking about too. The type for many socket 
options is a boolean or integer so they could be used without needing a 
static reference to the extended socket option. I'm not saying this 
would be the best way to set/get socket options but it would allow code 
to find the socket option in the supported set and make use of it 
without a static reference, something that would help the scenario you 
outline where a library is supported across a range of releases and 
doesn't want to make use of MR JARs.

-Alan

From alanb at openjdk.org  Sat Aug  6 08:46:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 6 Aug 2022 08:46:05 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v4]
In-Reply-To: <NC388ypZu9vjcxTorn0q0Ti1zAx5EhrXL6vB36NCC1Y=.ed904d3b-ad5a-49a2-8b51-8db11c1b3eea@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <NC388ypZu9vjcxTorn0q0Ti1zAx5EhrXL6vB36NCC1Y=.ed904d3b-ad5a-49a2-8b51-8db11c1b3eea@github.com>
Message-ID: <STqwLDY4v8vbVGYOCLwHDwg3GUwOx9eZWjSy7SiFpyk=.3b661b57-d2b9-4e29-83bd-2ae7c834399f@github.com>

On Fri, 5 Aug 2022 17:54:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8151430: Override setTimes() in the new BsdPosixFileAttributeView class

The updated approach looks maintainable but it misses the "Unix" view so setTimes won't work. In terms of organization then maybe just use the same approach as UnixFileAttributeViews to encapsulate the implementation, e.g.


class BsdFileAttributeViews {
    static class Basic extends UnixFileAttributeViews.Basic {
        Basic(UnixPath file, boolean followLinks) {
            super(file, followLinks);
        }
    }

    static class Posix extends UnixFileAttributeViews.Posix {
        Posix(UnixPath file, boolean followLinks) {
            super(file, followLinks);
        }
    }

    static class Unix extends UnixFileAttributeViews.Basic {
        Unix(UnixPath file, boolean followLinks) {
            super(file, followLinks);
        }
    }
}

src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 73:

> 71:     static void setattrlist(UnixPath path, int commonattr, long modTime,
> 72:                             long accTime, long createTime, long options)
> 73:         throws UnixException {

minor nit but the "{" at the end of line looks a bit odd here.

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

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

From alanb at openjdk.org  Mon Aug  8 08:38:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Aug 2022 08:38:03 GMT
Subject: RFR: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s) [v2]
In-Reply-To: <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
 <t__6POCHjgUelaO1gk0reT0spJLAHpUzN3pCY7uBNsE=.3a60c4c8-0023-4f2f-bb5e-a61073746c53@github.com>
Message-ID: <quHZr6SN6QmzQsNpBS9_5jlXplwxE2GodozrUFs-XKs=.8a446f53-21a4-403a-80ce-c4f6bd3bb2e1@github.com>

On Fri, 5 Aug 2022 09:54:36 GMT, Peter Levart <plevart at openjdk.org> wrote:

>> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
>> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
>> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
>> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.
>
> Peter Levart has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unused JLA, SharedSecrets, added @enablePreview test annotation

Marked as reviewed by alanb (Reviewer).

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

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

From plevart at openjdk.org  Mon Aug  8 12:41:51 2022
From: plevart at openjdk.org (Peter Levart)
Date: Mon, 8 Aug 2022 12:41:51 GMT
Subject: Integrated: 8291897: TerminatingThreadLocal(s) not registered from
 virtual thread(s)
In-Reply-To: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
References: <uKo4N2PW-F9T3dp4aqV5TnP0mMsBuVXTUaNZ3D8QQUo=.31f5b3b6-8ec5-4caa-9222-635ec536df24@github.com>
Message-ID: <fADsMdszkdzOld6umODmseDURQCJwfiRQc7obfvyLJI=.c09d0bf9-a8e7-45b0-aa68-4a27d33cfc51@github.com>

On Thu, 4 Aug 2022 10:57:53 GMT, Peter Levart <plevart at openjdk.org> wrote:

> This is an attempt to fix inconsistent behavior of TerminatingThreadLocal(s) when used internally in JDK for per-carrier-thread caches of native ByteBuffer(s) and NativeBuffer(s). If used from virtual thread, such TerminatingThreadLocal(s) are not registered with the carrier thread for the cleanup.
> The fix introduces an internal CarrierThreadLocal subclass of ThreadLocal which rewires its API methods to use current thread's carrier thread as the source of ThreadLocalMap instead of current thread itself (if it is a VirtualThread for example). TerminatingThreadLocal is now a subclass of CarrierThreadLocal. It seems only per-carrier-thread caching is a usecase for it. The uses of JavaLangAccess in various places to access a carrier-thread value of given ThreadLocal has been replaced by public API calls and the use of CarrierThreadLocal instead of plain ThreadLocal. JavaLangAccess is still used to dispatch the CarrierThreadLocal API methods, but only for that. Would someone be tempted to use JavaLangAccess methods directly, they now require CarrierThreadLocal argument to guard against missuses.
> The REGISTRY of TerminatingThreadLocal(s) that tracks which of them have values bound to a particular carrier thread is now implemented conveniently  with a CarrierThreadLocal.
> The test is expanded with a case that demonstrates a situation where a carrier thread is terminated. Since it must wait for 30 seconds for that to happen, only one of the test cases is performed in this mode. The correct logic of TerminatingThreadLocal is still verified with all test-cases using platform threads that can be terminated more rapidly.

This pull request has now been integrated.

Changeset: 861cc671
Author:    Peter Levart <plevart at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/861cc671e2e4904d94f50710be99a511e2f9bb68
Stats:     262 lines in 9 files changed: 196 ins; 12 del; 54 mod

8291897: TerminatingThreadLocal(s) not registered from virtual thread(s)

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Mon Aug  8 13:03:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Aug 2022 13:03:09 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v5]
In-Reply-To: <Cfg8f-71HtlUxVRsOFcWPhU-bTUzJFawGE57RvLKRWM=.06b0f21c-f462-48e9-8b6f-eb5288ced4b6@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Cfg8f-71HtlUxVRsOFcWPhU-bTUzJFawGE57RvLKRWM=.06b0f21c-f462-48e9-8b6f-eb5288ced4b6@github.com>
Message-ID: <vAtNbaOntNxFs8ab_wSbOrp282jdEYNgYvmmuOiIoP0=.d684aaff-d883-43b6-b343-94aec20f102f@github.com>

On Wed, 3 Aug 2022 15:22:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264744: Fix typo desintation -> destination

I skimmed the latest patch and I think the main thing that still needs to be worked out is how to integtrate "clonefile". Right now the current prototype adds sun.nio.fs.CloneFile but that doesn't fit into the provider architecture. I think we are getting close to the point with these changes where UnixNativeDispatcher will need to be changed to define instance methods rather than static methods. I'll add comments soon with suggestions for how this could be integrated.

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

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

From bpb at openjdk.org  Mon Aug  8 16:28:20 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 8 Aug 2022 16:28:20 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v5]
In-Reply-To: <vAtNbaOntNxFs8ab_wSbOrp282jdEYNgYvmmuOiIoP0=.d684aaff-d883-43b6-b343-94aec20f102f@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Cfg8f-71HtlUxVRsOFcWPhU-bTUzJFawGE57RvLKRWM=.06b0f21c-f462-48e9-8b6f-eb5288ced4b6@github.com>
 <vAtNbaOntNxFs8ab_wSbOrp282jdEYNgYvmmuOiIoP0=.d684aaff-d883-43b6-b343-94aec20f102f@github.com>
Message-ID: <XKhB-DjuemEj1NVy2I4OreBLrLg__VwYEwQ5zXtPhAQ=.f1cc019e-aeb3-4127-bcff-ea4d7c96ae0f@github.com>

On Mon, 8 Aug 2022 12:59:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I skimmed the latest patch and I think the main thing that still needs to be worked out is how to integtrate "clonefile". Right now the current prototype adds sun.nio.fs.CloneFile but that doesn't fit into the provider architecture. [...]

I don't like this approach that much either but is better than two prior versions I did not publish which respectively used a singleton version of `UnixCopyFile` and a `FunctionalInterface` for `clonefile`.

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

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

From bpb at openjdk.org  Mon Aug  8 22:26:04 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 8 Aug 2022 22:26:04 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v5]
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <uhmXBV_xusy68PCt392ORipSoTFUyTdaV_LAjm86460=.2e8e8953-1bbc-486b-b70c-56eff0cb159e@github.com>

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

  8151430: Refactor for better encapsulation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9762/files
  - new: https://git.openjdk.org/jdk/pull/9762/files/5b48fe09..10deb03d

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

  Stats: 280 lines in 6 files changed: 142 ins; 132 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/9762.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9762/head:pull/9762

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

From bpb at openjdk.org  Mon Aug  8 22:26:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 8 Aug 2022 22:26:05 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v4]
In-Reply-To: <STqwLDY4v8vbVGYOCLwHDwg3GUwOx9eZWjSy7SiFpyk=.3b661b57-d2b9-4e29-83bd-2ae7c834399f@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <NC388ypZu9vjcxTorn0q0Ti1zAx5EhrXL6vB36NCC1Y=.ed904d3b-ad5a-49a2-8b51-8db11c1b3eea@github.com>
 <STqwLDY4v8vbVGYOCLwHDwg3GUwOx9eZWjSy7SiFpyk=.3b661b57-d2b9-4e29-83bd-2ae7c834399f@github.com>
Message-ID: <4GKQxz7jM6JYKWbbVkQUK2rxAX4-GGWUwNe50y5kCLg=.5a62bdb5-bf7c-415d-bd93-4ce6df8c1776@github.com>

On Sat, 6 Aug 2022 08:42: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:
>> 
>>   8151430: Override setTimes() in the new BsdPosixFileAttributeView class
>
> src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 73:
> 
>> 71:     static void setattrlist(UnixPath path, int commonattr, long modTime,
>> 72:                             long accTime, long createTime, long options)
>> 73:         throws UnixException {
> 
> minor nit but the "{" at the end of line looks a bit odd here.

Fixed in 10deb03d62b15eb0c5130db3e251838787a82e00.

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

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

From alanb at openjdk.org  Tue Aug  9 07:20:20 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 07:20:20 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v5]
In-Reply-To: <uhmXBV_xusy68PCt392ORipSoTFUyTdaV_LAjm86460=.2e8e8953-1bbc-486b-b70c-56eff0cb159e@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <uhmXBV_xusy68PCt392ORipSoTFUyTdaV_LAjm86460=.2e8e8953-1bbc-486b-b70c-56eff0cb159e@github.com>
Message-ID: <f_1M0ApMfMEkqAmBAgveDDaTewtZP5b6aFJe-6fpFak=.48dad463-808e-4359-a2a3-75bfa701eba0@github.com>

On Mon, 8 Aug 2022 22:26:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8151430: Refactor for better encapsulation

src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java line 70:

> 68:             boolean followLinks = Util.followLinks(options);
> 69:             return (V) BsdFileAttributeViews.createPosixView(file, followLinks);
> 70:         }

The update that is 10deb03d looks quite good. I just wonder about the duplicate in BsdFileSystemProvider. Maybe it could test for UserDefiendFileAttributeFIleView, BasicFileAttrinuteView or PosixFileAttributeView so that the parameters are only processed in one place rather than 3.

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

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

From chegar999 at gmail.com  Tue Aug  9 08:22:27 2022
From: chegar999 at gmail.com (Chris)
Date: Tue, 9 Aug 2022 09:22:27 +0100
Subject: Extended socket options and module layers
In-Reply-To: <256c5662-a1a1-da3f-d71c-0c90e2bbe5aa@oracle.com>
References: <256c5662-a1a1-da3f-d71c-0c90e2bbe5aa@oracle.com>
Message-ID: <F805F534-F018-4171-A6C9-78E05C54E8D7@gmail.com>

Thanks for your reply Alan

> On 6 Aug 2022, at 08:43, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 
> ?On 05/08/2022 20:43, Chris Hegarty wrote:
> ?
> I think there is merit is re-examining the integration of the jdk.net module. Not high priority but I think the "triggered registration" should be removed and the implemented of extended socket options should move to java.base, the jdk.net module should just expose the API. That would align with how extended open/copy options work in the jdk.unsupported module and the extended map mode in the jdk.nio.mapmode module. It would have internal mirrors for complex socket options but that isn't too hard to do.

That sounds very reasonable.

> Introducing a service interface and having jdk.net provide an implementation may be worth thinking about too. The type for many socket options is a boolean or integer so they could be used without needing a static reference to the extended socket option. I'm not saying this would be the best way to set/get socket options but it would allow code to find the socket option in the supported set and make use of it without a static reference,

+1

> something that would help the scenario you outline where a library is supported across a range of releases and doesn't want to make use of MR JARs.

Thankfully we?re past that now, and have rewritten our code to remove the use of reflection.

-Chris

From bpb at openjdk.org  Tue Aug  9 15:04:26 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 15:04:26 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v5]
In-Reply-To: <f_1M0ApMfMEkqAmBAgveDDaTewtZP5b6aFJe-6fpFak=.48dad463-808e-4359-a2a3-75bfa701eba0@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <uhmXBV_xusy68PCt392ORipSoTFUyTdaV_LAjm86460=.2e8e8953-1bbc-486b-b70c-56eff0cb159e@github.com>
 <f_1M0ApMfMEkqAmBAgveDDaTewtZP5b6aFJe-6fpFak=.48dad463-808e-4359-a2a3-75bfa701eba0@github.com>
Message-ID: <vYq3EDlyrtn61xQ9qquVweTXdVuIMpT3VlFva5FpaGs=.c3c65f72-ab17-4e74-8f1e-69134531613b@github.com>

On Tue, 9 Aug 2022 07:16:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8151430: Refactor for better encapsulation
>
> src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java line 70:
> 
>> 68:             boolean followLinks = Util.followLinks(options);
>> 69:             return (V) BsdFileAttributeViews.createPosixView(file, followLinks);
>> 70:         }
> 
> The update that is 10deb03d looks quite good. I just wonder about the duplicate code in BsdFileSystemProvider. Maybe it could test for UserDefiendFileAttributeFIleView, BasicFileAttrinuteView or PosixFileAttributeView so that the parameters are only processed in one place rather than 3.

Agreed, I don't like that either.

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

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

From bpb at openjdk.org  Tue Aug  9 16:46:34 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 16:46:34 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v6]
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <kASBVyXW8_EbVQAPx7-ICrh0cjlDk6-REkMgEeIdzyI=.0a72b02c-715d-4e97-b818-2fe054843bfd@github.com>

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

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

  8151430: Convert params in only one place in each modified BsdFileSystemProvider method

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9762/files
  - new: https://git.openjdk.org/jdk/pull/9762/files/10deb03d..0274bc55

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

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

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

From bpb at openjdk.org  Tue Aug  9 16:46:35 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 16:46:35 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v5]
In-Reply-To: <vYq3EDlyrtn61xQ9qquVweTXdVuIMpT3VlFva5FpaGs=.c3c65f72-ab17-4e74-8f1e-69134531613b@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <uhmXBV_xusy68PCt392ORipSoTFUyTdaV_LAjm86460=.2e8e8953-1bbc-486b-b70c-56eff0cb159e@github.com>
 <f_1M0ApMfMEkqAmBAgveDDaTewtZP5b6aFJe-6fpFak=.48dad463-808e-4359-a2a3-75bfa701eba0@github.com>
 <vYq3EDlyrtn61xQ9qquVweTXdVuIMpT3VlFva5FpaGs=.c3c65f72-ab17-4e74-8f1e-69134531613b@github.com>
Message-ID: <AQubPtNQyhDnz-7fwGWL9CmqcV2UV289HebxeDpztIg=.55c59c99-babd-460e-b325-b94afdbfb34d@github.com>

On Tue, 9 Aug 2022 15:02:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/macosx/classes/sun/nio/fs/BsdFileSystemProvider.java line 70:
>> 
>>> 68:             boolean followLinks = Util.followLinks(options);
>>> 69:             return (V) BsdFileAttributeViews.createPosixView(file, followLinks);
>>> 70:         }
>> 
>> The update that is 10deb03d looks quite good. I just wonder about the duplicate code in BsdFileSystemProvider. Maybe it could test for UserDefiendFileAttributeFIleView, BasicFileAttrinuteView or PosixFileAttributeView so that the parameters are only processed in one place rather than 3.
>
> Agreed, I don't like that either.

Revised in 0274bc5523310e0b8580be4f63acec51f0436c49.

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

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

From bpb at openjdk.org  Tue Aug  9 17:09:37 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 17:09:37 GMT
Subject: Integrated: 8290047: (fs) FileSystem.getPathMatcher does not check for
 ":" at last index
In-Reply-To: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
References: <vkXVbiJMFFEQ4AVa9qp3-iw5aVineFSHIkUBNcErKJg=.18593a7e-dc58-4795-bfd6-dcb9c0fa2ea5@github.com>
Message-ID: <jscnD5JoiY33aPu7Zw6xgKE6ZcCyD8g1EQdWo1vLW48=.881f0109-7a92-4500-85f6-77122b6a04f7@github.com>

On Thu, 21 Jul 2022 15:29:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For a `String` ?s?, `s.indexOf(int)` can never return a value `>= s.length()` so change the check
> 
>         int pos = syntaxAndInput.indexOf(':');
>         if (pos <= 0 || pos == syntaxAndInput.length())
> 
> to
> 
>         if (pos <= 0)

This pull request has now been integrated.

Changeset: 4040927d
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4040927d1750dd00611cc6465507dd0bc694a18f
Stats:     52 lines in 8 files changed: 37 ins; 0 del; 15 mod

8290047: (fs) FileSystem.getPathMatcher does not check for ":" at last index

Reviewed-by: naoto, rriggs, alanb, lancea

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

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

From alanb at openjdk.org  Tue Aug  9 19:10:31 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 19:10:31 GMT
Subject: RFR: 8151430: (fs) BasicFileAttributeView.setTimes should support
 setting file create time on OS X [v6]
In-Reply-To: <kASBVyXW8_EbVQAPx7-ICrh0cjlDk6-REkMgEeIdzyI=.0a72b02c-715d-4e97-b818-2fe054843bfd@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
 <kASBVyXW8_EbVQAPx7-ICrh0cjlDk6-REkMgEeIdzyI=.0a72b02c-715d-4e97-b818-2fe054843bfd@github.com>
Message-ID: <JafkNmWl96miyl_BtKLwrXyZclJRsOHbzD5IzrAuqe4=.adb02b5a-e7a0-4078-a51d-183dc6b18a92@github.com>

On Tue, 9 Aug 2022 16:46:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8151430: Convert params in only one place in each modified BsdFileSystemProvider method

Marked as reviewed by alanb (Reviewer).

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

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

From aturbanov at openjdk.org  Tue Aug  9 20:58:12 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 9 Aug 2022 20:58:12 GMT
Subject: RFR: 8292140: (fs) Confusing instanceof check in
 RegistryFileTypeDetector
Message-ID: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>

Type of `file` parameter is known to be `Path`. And `instanceof` only checks if it's `null` or not.
https://github.com/openjdk/jdk/blob/2712bc3f79990f27fe9a624a7a818ba1c2c74b67/src/java.base/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java#L43-L46
Before `implProbeContentType` method  is called, parameter is checked for null in `sun.nio.fs.AbstractFileTypeDetector#probeContentType`. It means null check is redundant too.

https://github.com/openjdk/jdk/blob/eb8b789015c98cb5fe7ba788e71f3f6166884739/src/java.base/share/classes/sun/nio/fs/AbstractFileTypeDetector.java#L72-L75

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

Commit messages:
 - [PATCH] Confusing instanceof check in RegistryFileTypeDetector

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

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

From alanb at openjdk.org  Tue Aug  9 20:58:12 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Aug 2022 20:58:12 GMT
Subject: RFR: 8292140: (fs) Confusing instanceof check in
 RegistryFileTypeDetector
In-Reply-To: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
References: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
Message-ID: <es9Oe6wBq7dYhRzBsoqCEn7_DxtJIK86pWqkDQO8-og=.daf1f12e-546c-4726-a512-130f6e4c6f55@github.com>

On Mon, 8 Aug 2022 19:51:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Type of `file` parameter is known to be `Path`. And `instanceof` only checks if it's `null` or not.
> https://github.com/openjdk/jdk/blob/2712bc3f79990f27fe9a624a7a818ba1c2c74b67/src/java.base/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java#L43-L46
> Before `implProbeContentType` method  is called, parameter is checked for null in `sun.nio.fs.AbstractFileTypeDetector#probeContentType`. It means null check is redundant too.
> 
> https://github.com/openjdk/jdk/blob/eb8b789015c98cb5fe7ba788e71f3f6166884739/src/java.base/share/classes/sun/nio/fs/AbstractFileTypeDetector.java#L72-L75

I think this is a left over from when the parameter was of type FileRef.

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

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

From bpb at openjdk.org  Tue Aug  9 22:32:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 9 Aug 2022 22:32:10 GMT
Subject: Integrated: 8151430: (fs) BasicFileAttributeView.setTimes should
 support setting file create time on OS X
In-Reply-To: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
References: <b1_4_sgVIEPX4Muaw_2Tu36C21oKfjG6eSe2XtdAuUg=.2196cdd0-8652-4ebe-ac6f-35f6615c5925@github.com>
Message-ID: <jWUXD4nVDL9bJQdFJ5kDQqiduvhYGFYafe7MCaVWVlU=.7db23b7c-6ecd-495c-9601-7bd97432fddd@github.com>

On Fri, 5 Aug 2022 03:03:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use the BSD system call `setattrlist(2)` to set file modification, access, and creation time attributes on macOS.

This pull request has now been integrated.

Changeset: 6397d564
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6397d564a5dab07f81bf4c69b116ebfabb2446ba
Stats:     272 lines in 7 files changed: 254 ins; 0 del; 18 mod

8151430: (fs) BasicFileAttributeView.setTimes should support setting file create time on OS X

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Wed Aug 10 01:05:06 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Aug 2022 01:05:06 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v6]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

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 eight additional commits since the last revision:

 - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
 - Merge
 - 8264744: Fix typo desintation -> destination
 - 8264744: Refactor into UnixCopyFile hierarchy
 - Merge
 - 8264744: Address review comments aside from refactoring
 - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
 - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9486/files
  - new: https://git.openjdk.org/jdk/pull/9486/files/9810352d..bd6e49ce

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

  Stats: 7449 lines in 382 files changed: 4571 ins; 1892 del; 986 mod
  Patch: https://git.openjdk.org/jdk/pull/9486.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486

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

From alanb at openjdk.org  Wed Aug 10 05:52:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Aug 2022 05:52:34 GMT
Subject: RFR: 8292140: (fs) Confusing instanceof check in
 RegistryFileTypeDetector
In-Reply-To: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
References: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
Message-ID: <IVEkkC1zkObQw_KGgGoKvv7J6cuxFGgmaq21pPnSH9U=.d616bea5-1367-48aa-baf7-69a79edfb497@github.com>

On Mon, 8 Aug 2022 19:51:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Type of `file` parameter is known to be `Path`. And `instanceof` only checks if it's `null` or not.
> https://github.com/openjdk/jdk/blob/2712bc3f79990f27fe9a624a7a818ba1c2c74b67/src/java.base/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java#L43-L46
> Before `implProbeContentType` method  is called, parameter is checked for null in `sun.nio.fs.AbstractFileTypeDetector#probeContentType`. It means null check is redundant too.
> 
> https://github.com/openjdk/jdk/blob/eb8b789015c98cb5fe7ba788e71f3f6166884739/src/java.base/share/classes/sun/nio/fs/AbstractFileTypeDetector.java#L72-L75

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Wed Aug 10 15:44:07 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Aug 2022 15:44:07 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v6]
In-Reply-To: <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>
Message-ID: <nvWOtMyvxS311NAJTd0SSdhg8nJY_Vq0JwljBr3CWhE=.35eef5ed-483d-461d-8881-1e1f129e8d7b@github.com>

On Wed, 10 Aug 2022 01:05:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> 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 eight additional commits since the last revision:
> 
>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>  - Merge
>  - 8264744: Fix typo desintation -> destination
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - 8264744: Address review comments aside from refactoring
>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

Thanks for the update. One thing that I should have pointed out in previous comments is UnixFileSystem.copyNonPosixAttributes. This is overridden in LinuxFileSystem and others and I think gives you an example of how to add the clone method without needing fileCopier. Would you be able to try that? I suspect the patch will reduce if that is used as the template.

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

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

From bpb at openjdk.org  Wed Aug 10 15:44:07 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Aug 2022 15:44:07 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v6]
In-Reply-To: <nvWOtMyvxS311NAJTd0SSdhg8nJY_Vq0JwljBr3CWhE=.35eef5ed-483d-461d-8881-1e1f129e8d7b@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>
 <nvWOtMyvxS311NAJTd0SSdhg8nJY_Vq0JwljBr3CWhE=.35eef5ed-483d-461d-8881-1e1f129e8d7b@github.com>
Message-ID: <l6l5oA_-Bcid-PoLcXypfNQV925JJNOA6xWgeWO_ob0=.894653b7-40f3-4353-9a71-38d44580b1ca@github.com>

On Wed, 10 Aug 2022 15:39:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] I think gives you an example of how to add the clone method without needing fileCopier. Would you be able to try that? I suspect the patch will reduce if that is used as the template.

I'll take a look. If it improves things, then so much the better.

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

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

From bpb at openjdk.org  Wed Aug 10 17:31:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Aug 2022 17:31:16 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
 - Merge
 - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
 - Merge
 - 8264744: Fix typo desintation -> destination
 - 8264744: Refactor into UnixCopyFile hierarchy
 - Merge
 - 8264744: Address review comments aside from refactoring
 - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
 - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

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

Changes: https://git.openjdk.org/jdk/pull/9486/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=06
  Stats: 436 lines in 12 files changed: 417 ins; 4 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/9486.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486

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

From bpb at openjdk.org  Wed Aug 10 17:31:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Aug 2022 17:31:16 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v6]
In-Reply-To: <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <R-C96rmpNznXORfQGzOq0_SLMIJls9DFho8ZgI4aNM4=.6cb3ae42-6c0d-48a5-8ff9-c11adffab944@github.com>
Message-ID: <PqpGGI-X-3O2VrxFchVueoz13Hsptjwx1BKstchxa-c=.fd9b4cdd-2995-417f-b4e3-951a66d75c82@github.com>

On Wed, 10 Aug 2022 01:05:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>  - Merge
>  - 8264744: Fix typo desintation -> destination
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - 8264744: Address review comments aside from refactoring
>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

`clone()` moved to `{Bsd,Linux,Unix}FileSystem`; `{Bsd,Linux}CopyFile` removed.

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

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

From aturbanov at openjdk.org  Thu Aug 11 06:28:40 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 11 Aug 2022 06:28:40 GMT
Subject: Integrated: 8292140: (fs) Needless instanceof check in
 RegistryFileTypeDetector
In-Reply-To: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
References: <EM1AAFLPSubTXcureSj0I2UuFdxNgPDAOpYlHe9kGgw=.73603217-f885-4179-a9f7-3e6d222c4625@github.com>
Message-ID: <GSpGdcCYQcj7nZXleknMH4aj2LWPZmrAYPtCtBBz5IY=.c13d3e72-2dcc-45b3-ad66-835f05033069@github.com>

On Mon, 8 Aug 2022 19:51:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Type of `file` parameter is known to be `Path`. And `instanceof` only checks if it's `null` or not.
> https://github.com/openjdk/jdk/blob/2712bc3f79990f27fe9a624a7a818ba1c2c74b67/src/java.base/windows/classes/sun/nio/fs/RegistryFileTypeDetector.java#L43-L46
> Before `implProbeContentType` method  is called, parameter is checked for null in `sun.nio.fs.AbstractFileTypeDetector#probeContentType`. It means null check is redundant too.
> 
> https://github.com/openjdk/jdk/blob/eb8b789015c98cb5fe7ba788e71f3f6166884739/src/java.base/share/classes/sun/nio/fs/AbstractFileTypeDetector.java#L72-L75

This pull request has now been integrated.

Changeset: ad5f628c
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad5f628c58c46438f2f542d5255e5fd1fa4d0c6b
Stats:     5 lines in 1 file changed: 0 ins; 3 del; 2 mod

8292140: (fs) Needless instanceof check in RegistryFileTypeDetector

Reviewed-by: alanb

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

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

From aturbanov at openjdk.org  Fri Aug 12 08:54:52 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 12 Aug 2022 08:54:52 GMT
Subject: RFR: 8292279: (fs) Use try-with-resources to release NativeBuffer
Message-ID: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>

Since [JDK-8260966](https://bugs.openjdk.org/browse/JDK-8260966), NativeBuffer implements AutoCloseable interface.
Now we can use try-with-resources statements to simplify code.

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

Commit messages:
 - [PATCH] Use try-with-resources to release NativeBuffer

Changes: https://git.openjdk.org/jdk/pull/9794/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9794&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8292279
  Stats: 176 lines in 13 files changed: 6 ins; 112 del; 58 mod
  Patch: https://git.openjdk.org/jdk/pull/9794.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9794/head:pull/9794

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

From alanb at openjdk.org  Fri Aug 12 09:00:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 09:00:32 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
Message-ID: <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>

On Wed, 10 Aug 2022 17:31:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>  - Merge
>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>  - Merge
>  - 8264744: Fix typo desintation -> destination
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - 8264744: Address review comments aside from refactoring
>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods

src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 74:

> 72:     }
> 73: 
> 74:     private static UnixException catEx(UnixException x, UnixException y) {

What is the purpose of add a suppressed exception to a UnixException? A UnixException will get re-mapped to a File SystemException so I assume the suppressed exception will be ignored.

src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 100:

> 98:      */
> 99:     protected int clone(UnixPath src, UnixPath dst, boolean followLinks)
> 100:         throws IOException {

Formatting nit here too.

src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 111:

> 109:         int dstFD = 0;
> 110:         try {
> 111:             dstFD = open(dst, O_CREAT | O_WRONLY, 0666);

The mode should be attrs.mode() rather than 0666, which means the clone method need an additional parameter.

src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c line 42:

> 40: 
> 41: #ifndef FICLONE
> 42: #define FICLONE      1074041865

Are we sure this value is the same on all architectures?

src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java line 88:

> 86:     protected int clone(UnixPath src, UnixPath dst, boolean followLinks)
> 87:         throws IOException {
> 88:         int flags = followLinks ? 0 : CLONE_NOFOLLOW;

Can you put the "{" onto its own line so that it's a bit easier to distinguish the method declaration from the body.

src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 72:

> 70:     static int clonefile(UnixPath src, UnixPath dst, int flags)
> 71:         throws UnixException {
> 72:         if (src.getFileSystem() == dst.getFileSystem()) {

Why does this check if getFileSystem() returns the same file system? There is only one instance of UnixFileSystem so this will always be true.

Will the "throws UnixException {" fit on the previous line to fixing the odd formatting.

src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c line 232:

> 230: JNIEXPORT jint JNICALL
> 231: Java_sun_nio_fs_BsdNativeDispatcher_clonefile0(JNIEnv* env, jclass this,
> 232:     jlong srcAddress, jlong dstAddress, int flags)

flags should be a "jint" (not int).

src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c line 283:

> 281: 
> 282:     if (setattrlist(path, &attrList, (void*)buf,
> 283:         count*attrsize, options) != 0) {

I assume this is an accidental edit.

src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 279:

> 277:         throws IOException
> 278:     {
> 279:         boolean copied = false;

The "copied" flag is a sign that the copyFile method needs to be refactor to split it into the copy of the contents and the file attributes. Also on first glance, re-opening both the source and destination files after a clone is a bug. We should (where possible) only open the source file for reading and the destination file for writing once.

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

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

From alanb at openjdk.org  Fri Aug 12 09:27:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 09:27:15 GMT
Subject: RFR: 8292279: (fs) Use try-with-resources to release NativeBuffer
In-Reply-To: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
References: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
Message-ID: <-lHtsMG7DPLD-beL3IPE8JuCh_1-LD6gtCDazJ-kMkw=.87b3173f-8751-4de7-865b-cae13d791fcf@github.com>

On Mon, 8 Aug 2022 07:35:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Since [JDK-8260966](https://bugs.openjdk.org/browse/JDK-8260966), NativeBuffer implements AutoCloseable interface.
> Now we can use try-with-resources statements to simplify code.

This is a good cleanup. Many of the usages (esp. in UnixNativeDispatcher) has been converted to try-with-resources by way of other changes and it's good to go over the remaining and convert them too.

src/java.base/windows/classes/sun/nio/fs/WindowsFileAttributes.java line 267:

> 265:     {
> 266:         try (NativeBuffer buffer = NativeBuffers
> 267:             .getNativeBuffer(SIZEOF_FILE_INFORMATION)) {

I think you can remove the line break to make this a bit more readable.

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

Marked as reviewed by alanb (Reviewer).

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

From bpb at openjdk.org  Fri Aug 12 14:53:21 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 14:53:21 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
Message-ID: <k_qDA5wDOYq_fWgLeBQnYUv02AOP_ZMNHgFpXCKFq4I=.57200006-c24f-4601-9f97-4c8b0a0a06fd@github.com>

On Fri, 12 Aug 2022 08:55:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>>  - Merge
>>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>>  - Merge
>>  - 8264744: Fix typo desintation -> destination
>>  - 8264744: Refactor into UnixCopyFile hierarchy
>>  - Merge
>>  - 8264744: Address review comments aside from refactoring
>>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 279:
> 
>> 277:         throws IOException
>> 278:     {
>> 279:         boolean copied = false;
> 
> The "copied" flag is a sign that the copyFile method needs to be refactored to split it into the copy of the contents and the file attributes. Also on first glance, re-opening both the source and destination files after a clone is a bug. We should (where possible) only open the source file for reading and the destination file for writing once.

On macOS it's not possible to clone using file descriptors; paths are required.

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

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

From alanb at openjdk.org  Fri Aug 12 15:00:18 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Aug 2022 15:00:18 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <k_qDA5wDOYq_fWgLeBQnYUv02AOP_ZMNHgFpXCKFq4I=.57200006-c24f-4601-9f97-4c8b0a0a06fd@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
 <k_qDA5wDOYq_fWgLeBQnYUv02AOP_ZMNHgFpXCKFq4I=.57200006-c24f-4601-9f97-4c8b0a0a06fd@github.com>
Message-ID: <-M192RurFvcFyQTiG2tVJIX7m7ocGhHN53mkGtbGAI8=.de44923c-0cfd-4e10-82b7-fea60d887aa8@github.com>

On Fri, 12 Aug 2022 14:49:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> On macOS it's not possible to clone using file descriptors; paths are required.

I understand that but what isn't clear is if the attributes are cloned too.  It might be that we only use it when not copying attributes.

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

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

From bpb at openjdk.org  Fri Aug 12 15:05:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 15:05:23 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <-M192RurFvcFyQTiG2tVJIX7m7ocGhHN53mkGtbGAI8=.de44923c-0cfd-4e10-82b7-fea60d887aa8@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
 <k_qDA5wDOYq_fWgLeBQnYUv02AOP_ZMNHgFpXCKFq4I=.57200006-c24f-4601-9f97-4c8b0a0a06fd@github.com>
 <-M192RurFvcFyQTiG2tVJIX7m7ocGhHN53mkGtbGAI8=.de44923c-0cfd-4e10-82b7-fea60d887aa8@github.com>
Message-ID: <SNKPNjEtDYhllF8J-OcjoGF35GftUg00b8BUBGCtjfc=.2394785c-22cf-43f3-9174-ac6bac52ea74@github.com>

On Fri, 12 Aug 2022 14:56:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> On macOS it's not possible to clone using file descriptors; paths are required.
>
>> On macOS it's not possible to clone using file descriptors; paths are required.
> 
> I understand that but what isn't clear is if the attributes are cloned too.  It might be that we only use it when not copying attributes.

Right, I have some more investigation to perform here.

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

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

From bpb at openjdk.org  Fri Aug 12 15:35:18 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Aug 2022 15:35:18 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
Message-ID: <pn3_MFR8f8cqVVSnWrv-XHbVxQx6luYuQRsfNDDGKGY=.e55c440d-074f-47a3-b80c-5abfb32a7cca@github.com>

On Fri, 12 Aug 2022 08:26:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>>  - Merge
>>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>>  - Merge
>>  - 8264744: Fix typo desintation -> destination
>>  - 8264744: Refactor into UnixCopyFile hierarchy
>>  - Merge
>>  - 8264744: Address review comments aside from refactoring
>>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods
>
> src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c line 42:
> 
>> 40: 
>> 41: #ifndef FICLONE
>> 42: #define FICLONE      1074041865
> 
> Are we sure this value is the same on all architectures?

Testing succeeded on all platforms I've tried. It's been around since [Linux 4.5](https://man7.org/linux/man-pages/man2/ioctl_ficlone.2.html#VERSIONS) which was released [13 March 2016](https://en.wikipedia.org/wiki/Linux_kernel_version_history#Releases_4.x.y) and I verified that it has the same numerical value as `BTRFS_IOC_CLONE` which it supersedes.

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

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

From aturbanov at openjdk.org  Mon Aug 15 08:18:38 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 15 Aug 2022 08:18:38 GMT
Subject: RFR: 8292279: (fs) Use try-with-resources to release NativeBuffer
 [v2]
In-Reply-To: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
References: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
Message-ID: <bu15W07V9zM1sTnXpPgU4hpHkFE9ktQ8ldaQlXI_r40=.2856a014-cefa-4951-a35e-478483192d60@github.com>

> Since [JDK-8260966](https://bugs.openjdk.org/browse/JDK-8260966), NativeBuffer implements AutoCloseable interface.
> Now we can use try-with-resources statements to simplify code.

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

  8292279: (fs) Use try-with-resources to release NativeBuffer
  
  apply Alan's suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9794/files
  - new: https://git.openjdk.org/jdk/pull/9794/files/37b6d13e..1784e4ee

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

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

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

From alanb at openjdk.org  Mon Aug 15 08:23:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 15 Aug 2022 08:23:28 GMT
Subject: RFR: 8292279: (fs) Use try-with-resources to release NativeBuffer
 [v2]
In-Reply-To: <bu15W07V9zM1sTnXpPgU4hpHkFE9ktQ8ldaQlXI_r40=.2856a014-cefa-4951-a35e-478483192d60@github.com>
References: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
 <bu15W07V9zM1sTnXpPgU4hpHkFE9ktQ8ldaQlXI_r40=.2856a014-cefa-4951-a35e-478483192d60@github.com>
Message-ID: <1zligTgnx6QJ9zN4bHFlqArAKqv86ZMgZJf5ingzvdI=.69f9bc26-59d4-4e05-866c-5ab5350564a8@github.com>

On Mon, 15 Aug 2022 08:18:38 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Since [JDK-8260966](https://bugs.openjdk.org/browse/JDK-8260966), NativeBuffer implements AutoCloseable interface.
>> Now we can use try-with-resources statements to simplify code.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292279: (fs) Use try-with-resources to release NativeBuffer
>   
>   apply Alan's suggestion

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Mon Aug 15 18:35:13 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Aug 2022 18:35:13 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v8]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <dcNLe3dCe2xSbs3MEXMLK1-jYegqDnWkYf8XFIEAKFc=.59f0625b-e2a2-4f06-8fde-3a73b7b29f50@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

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

  8264744: Add mode to clone() and other requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9486/files
  - new: https://git.openjdk.org/jdk/pull/9486/files/7618c1d9..2157a148

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

  Stats: 108 lines in 6 files changed: 35 ins; 40 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/9486.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486

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

From bpb at openjdk.org  Mon Aug 15 18:35:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Aug 2022 18:35:23 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
Message-ID: <CXT--B-Rm0FHn3S8OHzJ4uP9BwPFhjIbrk8kEBV5VmA=.3e771397-00a9-48bb-bb82-08479a93b37c@github.com>

On Fri, 12 Aug 2022 08:42:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>>  - Merge
>>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>>  - Merge
>>  - 8264744: Fix typo desintation -> destination
>>  - 8264744: Refactor into UnixCopyFile hierarchy
>>  - Merge
>>  - 8264744: Address review comments aside from refactoring
>>  - 8264744: Refactor into provider+dispatcher to reduce amount of JNI code
>>  - 8264744: (fc, fs) Support file cloning in Unix versions of FileChannel transfer and Files copy methods
>
> src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 74:
> 
>> 72:     }
>> 73: 
>> 74:     private static UnixException catEx(UnixException x, UnixException y) {
> 
> What is the purpose of adding a suppressed exception to a UnixException? A UnixException will get re-mapped to a File SystemException so I assume the suppressed exception will be ignored.

It was a mistake; fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 100:
> 
>> 98:      */
>> 99:     protected int clone(UnixPath src, UnixPath dst, boolean followLinks)
>> 100:         throws IOException {
> 
> Formatting nit here too.

Fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/linux/classes/sun/nio/fs/LinuxFileSystem.java line 111:
> 
>> 109:         int dstFD = 0;
>> 110:         try {
>> 111:             dstFD = open(dst, O_CREAT | O_WRONLY, 0666);
> 
> The mode should be attrs.mode() rather than 0666, which means the clone method need an additional parameter.

Fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/macosx/classes/sun/nio/fs/BsdFileSystem.java line 88:
> 
>> 86:     protected int clone(UnixPath src, UnixPath dst, boolean followLinks)
>> 87:         throws IOException {
>> 88:         int flags = followLinks ? 0 : CLONE_NOFOLLOW;
> 
> Can you put the "{" onto its own line so that it's a bit easier to distinguish the method declaration from the body.

Fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/macosx/classes/sun/nio/fs/BsdNativeDispatcher.java line 72:
> 
>> 70:     static int clonefile(UnixPath src, UnixPath dst, int flags)
>> 71:         throws UnixException {
>> 72:         if (src.getFileSystem() == dst.getFileSystem()) {
> 
> Why does this check if getFileSystem() returns the same file system? There is only one instance of UnixFileSystem so this will always be true.
> 
> Will the "throws UnixException {" fit on the previous line to fixing the odd formatting.

Fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c line 232:
> 
>> 230: JNIEXPORT jint JNICALL
>> 231: Java_sun_nio_fs_BsdNativeDispatcher_clonefile0(JNIEnv* env, jclass this,
>> 232:     jlong srcAddress, jlong dstAddress, int flags)
> 
> flags should be a "jint" (not int).

Fixed in 2157a1480229fa697c824ae814f11a309627d768.

> src/java.base/macosx/native/libnio/fs/BsdNativeDispatcher.c line 283:
> 
>> 281: 
>> 282:     if (setattrlist(path, &attrList, (void*)buf,
>> 283:         count*attrsize, options) != 0) {
> 
> I assume this is an accidental edit.

Right; fixed in 2157a1480229fa697c824ae814f11a309627d768.

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

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

From bpb at openjdk.org  Mon Aug 15 18:35:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Aug 2022 18:35:23 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v7]
In-Reply-To: <SNKPNjEtDYhllF8J-OcjoGF35GftUg00b8BUBGCtjfc=.2394785c-22cf-43f3-9174-ac6bac52ea74@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <0QnrFIJ9Qg1u4nAOGEsKP0GI12G8ZVvxNvMYx1XL1jc=.76e6a0bb-d2cb-4f2a-9438-1d9c179689bc@github.com>
 <KtjMSFMxPkpS0B9TPjvlZFWhEL7D2ycBjJbOpBg1KGk=.cfb91d75-bd24-471b-9091-c917b558da1e@github.com>
 <k_qDA5wDOYq_fWgLeBQnYUv02AOP_ZMNHgFpXCKFq4I=.57200006-c24f-4601-9f97-4c8b0a0a06fd@github.com>
 <-M192RurFvcFyQTiG2tVJIX7m7ocGhHN53mkGtbGAI8=.de44923c-0cfd-4e10-82b7-fea60d887aa8@github.com>
 <SNKPNjEtDYhllF8J-OcjoGF35GftUg00b8BUBGCtjfc=.2394785c-22cf-43f3-9174-ac6bac52ea74@github.com>
Message-ID: <WnF2Xgfe8CvEx2-88QnWHDAn-FRJ0qszDigivf2tcXQ=.e563db84-d1b6-4e8d-bf25-778c866c36fa@github.com>

On Fri, 12 Aug 2022 15:01:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> On macOS it's not possible to clone using file descriptors; paths are required.
>> 
>> I understand that but what isn't clear is if the attributes are cloned too.  It might be that we only use it when not copying attributes.
>
> Right, I have some more investigation to perform here.

Based on my testing, attributes appear to be cloned by default except for the permission on linux-aarch64 and the (group) ownership on macosx-x64. If we want to suppress that behavior, then using clone would have to be made conditional.

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

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

From aturbanov at openjdk.org  Wed Aug 17 07:22:20 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 17 Aug 2022 07:22:20 GMT
Subject: Integrated: 8292279: (fs) Use try-with-resources to release
 NativeBuffer
In-Reply-To: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
References: <ylRbwUj8uGQsWWN7q3lS2L5i16mSzaVcuC4oMLTT33U=.0c02cac6-ce2c-48a2-8d8b-6406273732ae@github.com>
Message-ID: <RqhvLyHCJZZmCPWcTf20UNoCluwWmj8YIh6G2t8Qs7s=.a9c6b955-b3de-4d55-bb55-91935526eb50@github.com>

On Mon, 8 Aug 2022 07:35:44 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Since [JDK-8260966](https://bugs.openjdk.org/browse/JDK-8260966), NativeBuffer implements AutoCloseable interface.
> Now we can use try-with-resources statements to simplify code.

This pull request has now been integrated.

Changeset: 1d9c2f7a
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d9c2f7a6e3e897721ef99af8f383a07148b7c4e
Stats:     174 lines in 13 files changed: 6 ins; 113 del; 55 mod

8292279: (fs) Use try-with-resources to release NativeBuffer

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Wed Aug 17 13:52:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Aug 2022 13:52:28 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v8]
In-Reply-To: <dcNLe3dCe2xSbs3MEXMLK1-jYegqDnWkYf8XFIEAKFc=.59f0625b-e2a2-4f06-8fde-3a73b7b29f50@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <dcNLe3dCe2xSbs3MEXMLK1-jYegqDnWkYf8XFIEAKFc=.59f0625b-e2a2-4f06-8fde-3a73b7b29f50@github.com>
Message-ID: <JCgFxkVWelBw85iJiL4oV8YFCJhG4piDk-xQhEFAmdA=.dc14bbd9-d468-4746-ae2d-ec5f3fa9f8d7@github.com>

On Mon, 15 Aug 2022 18:35:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8264744: Add mode to clone() and other requested changes

I took another pass over the current patch. It has improved significantly but I think we will need to restructure UnixCopyFile very significantly to allow for both clone implementations. The main issue is that the macOS clonefile is forcing the patch to clone with file paths and this breaks the architecture where the source and target files are opened once.

One thing we could do is separate the update to FileChannelImpl.c to use copy_file_range to a separate issue. It doesn't need to be in this PR.

Another thing we could do is separate out the use of ioctl(FICLONE) on Linux. That is essentially an alternative transfer implementation so if we move the transfer to UnixFileSystem then the Linux implementation can use ioctl(FICLONE) or sendfile64, the macOS implementation can use fcopyfile, and the "portable" Unix implementation can use the user-space transfer loop. The implementation specific can fallback to the Unix transfer if needed.  If we do this then it gives us more time to think about the troublesome macOS clonefile.

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

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

From bpb at openjdk.org  Wed Aug 17 14:45:37 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Aug 2022 14:45:37 GMT
Subject: RFR: 8264744: (fs) Use file cloning in Linux and macOS versions of
 FileChannel transfer and Files copy methods [v8]
In-Reply-To: <JCgFxkVWelBw85iJiL4oV8YFCJhG4piDk-xQhEFAmdA=.dc14bbd9-d468-4746-ae2d-ec5f3fa9f8d7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <dcNLe3dCe2xSbs3MEXMLK1-jYegqDnWkYf8XFIEAKFc=.59f0625b-e2a2-4f06-8fde-3a73b7b29f50@github.com>
 <JCgFxkVWelBw85iJiL4oV8YFCJhG4piDk-xQhEFAmdA=.dc14bbd9-d468-4746-ae2d-ec5f3fa9f8d7@github.com>
Message-ID: <gs_cuAdUBFt89LFhjHCNV4PzIy_SYE2VUAn-U3Fc-8M=.042f53bf-7c8b-405b-b621-6782aabba169@github.com>

On Wed, 17 Aug 2022 13:46:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The main issue is that the macOS clonefile is forcing the patch to clone with file paths and this breaks the architecture where the source and target files are opened once.

Yes, this is annoying.

> One thing we could do is separate the update to FileChannelImpl.c to use copy_file_range to a separate issue. It doesn't need to be in this PR.

I agree with that.

> Another thing we could do is separate out the use of ioctl(FICLONE) on Linux. [...]

This will require more thought.

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

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

From bpb at openjdk.org  Wed Aug 17 20:39:45 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Aug 2022 20:39:45 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in java.nio
 package documentation
Message-ID: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>

Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

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

Commit messages:
 - 8292566: Add reference to the java.nio.file package in java.nio package documentation

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

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

From iris at openjdk.org  Wed Aug 17 21:15:28 2022
From: iris at openjdk.org (Iris Clark)
Date: Wed, 17 Aug 2022 21:15:28 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <ndHkN7Tg0ZAcZ_wYVHXcYPGdTlBNj8izho53WiFSFmw=.3d75ee5a-0cce-4f2a-8846-3639573a1260@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

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

From jpai at openjdk.org  Thu Aug 18 02:00:13 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Aug 2022 02:00:13 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <-wJU8vcZrHqyFhfbJNYppEaoj2xdN5pcfTipdmXGsKM=.2e3ef880-5697-48ed-98fc-9cf70b6a9b26@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

Hello Brian, the change looks fine to me. The copyright year on this file will need an update.

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

Marked as reviewed by jpai (Reviewer).

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

From jpai at openjdk.org  Thu Aug 18 02:04:15 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Aug 2022 02:04:15 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <iPGB_ZEmQVEK4IT6Oe3M3dfcRA5zzwtYQN0j91-w2hI=.9367201a-097a-4551-b2e8-9a7b8cec1271@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

After reading the text again, I had a question which I added to the CSR issue.

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

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

From alanb at openjdk.org  Thu Aug 18 06:18:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Aug 2022 06:18:15 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <LGPSs57VcRrV8QRPaDgsxs1_L2XSN3jSmUKSbDpTxCk=.6b97701c-fbbc-4209-a4aa-bb7cb926dc94@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

src/java.base/share/classes/java/nio/package-info.java line 60:

> 58:  * in the {@link java.nio.channels} package, and the file, file attribute,
> 59:  * and file system APIs in the {@link java.nio.file} package.  Each of
> 60:  * these subpackages has its own service-provider interface (SPI) subpackage,

If this package description is updated then it will mean expanding the list  in "The central abstractions..." first. That names the abstractions before the above text lists the packages that are they are in.

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

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

From bpb at openjdk.org  Thu Aug 18 21:33:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:33:17 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo on
 Linux
Message-ID: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>

Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

Commit messages:
 - 8292562: (fc) Use copy_file_range in FileChannel::transferTo on Linux

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

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

From bpb at openjdk.org  Thu Aug 18 21:55:34 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:55:34 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v2]
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <Ei9gBlXEmfg4ZI2KxFN2s20ms2KuwS-K5xSCbbmPsYk=.4883872c-21b1-4eed-a7e6-e50a72477479@github.com>

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

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

  8292566: Expand list of central abstractions; refine previous addition; update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9910/files
  - new: https://git.openjdk.org/jdk/pull/9910/files/b7279eb9..53cdc086

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

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

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

From bpb at openjdk.org  Thu Aug 18 21:55:35 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:55:35 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v2]
In-Reply-To: <-wJU8vcZrHqyFhfbJNYppEaoj2xdN5pcfTipdmXGsKM=.2e3ef880-5697-48ed-98fc-9cf70b6a9b26@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <-wJU8vcZrHqyFhfbJNYppEaoj2xdN5pcfTipdmXGsKM=.2e3ef880-5697-48ed-98fc-9cf70b6a9b26@github.com>
Message-ID: <0LWayvjFijcTXEh4G9E4KWmC9VosRnEAl5XVWtQsS5I=.dd9795ed-8c30-435e-b03c-5d3ec94c7f51@github.com>

On Thu, 18 Aug 2022 01:56:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> The copyright year on this file will need an update.

Year updated in 53cdc0869aca7237a8703b05c1dd8f3c3db98796.

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

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

From bpb at openjdk.org  Thu Aug 18 21:55:36 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:55:36 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <iPGB_ZEmQVEK4IT6Oe3M3dfcRA5zzwtYQN0j91-w2hI=.9367201a-097a-4551-b2e8-9a7b8cec1271@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <iPGB_ZEmQVEK4IT6Oe3M3dfcRA5zzwtYQN0j91-w2hI=.9367201a-097a-4551-b2e8-9a7b8cec1271@github.com>
Message-ID: <T7jpGINIjgnWdbvIrQOA4zQFZndEp39P6dzOOgphL9s=.17739f27-ef36-4cca-8738-3f5a50cb6ff7@github.com>

On Thu, 18 Aug 2022 02:02:08 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> [...] I had a question which I added to the CSR issue.

Mostly addressed in 53cdc0869aca7237a8703b05c1dd8f3c3db98796.

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

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

From bpb at openjdk.org  Thu Aug 18 21:55:38 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:55:38 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <COHFPM94TBS8cjGsNAe4vIBgr_OI2VaPID6gVedaDTo=.ce7821d7-d40d-4f03-b92b-c788ce5b9abd@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

Note: I am not updating the CSR until there is consensus in this PR.

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

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

From bpb at openjdk.org  Thu Aug 18 21:55:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Aug 2022 21:55:41 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v2]
In-Reply-To: <LGPSs57VcRrV8QRPaDgsxs1_L2XSN3jSmUKSbDpTxCk=.6b97701c-fbbc-4209-a4aa-bb7cb926dc94@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <LGPSs57VcRrV8QRPaDgsxs1_L2XSN3jSmUKSbDpTxCk=.6b97701c-fbbc-4209-a4aa-bb7cb926dc94@github.com>
Message-ID: <oHL9aJW90hKWgH6AJFqvUjeP6s_nw_ljzHyxBQcjELc=.4eb13e52-c139-48b8-b747-f975100743ab@github.com>

On Thu, 18 Aug 2022 06:14:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292566: Expand list of central abstractions; refine previous addition; update copyright year
>
> src/java.base/share/classes/java/nio/package-info.java line 60:
> 
>> 58:  * in the {@link java.nio.channels} package, and the file, file attribute,
>> 59:  * and file system APIs in the {@link java.nio.file} package.  Each of
>> 60:  * these subpackages has its own service-provider interface (SPI) subpackage,
> 
> If this package description is updated then it will probably mean expanding the list under  "The central abstractions..." first. That names the abstractions before the above text lists the packages that are they are in.

Done in 53cdc0869aca7237a8703b05c1dd8f3c3db98796.

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

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

From bpb at openjdk.org  Fri Aug 19 01:00:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 01:00:16 GMT
Subject: RFR: 8292636: (dc) Problem listing of
 java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID
Message-ID: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>

Change problem listing to use the correct issue ID.

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

Commit messages:
 - 8292636: (dc) Problem listing of java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID

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

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

From jpai at openjdk.org  Fri Aug 19 01:53:29 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Aug 2022 01:53:29 GMT
Subject: RFR: 8292636: (dc) Problem listing of
 java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID
In-Reply-To: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>
References: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>
Message-ID: <2FSMEZ16MKsu-NMbW4NRaMJmU3JKLc_bjSovtLpsz1Y=.9129dedd-05e6-48f2-80ca-d9419dce9ddc@github.com>

On Thu, 18 Aug 2022 20:41:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change problem listing to use the correct issue ID.

Marked as reviewed by jpai (Reviewer).

I've now added a `problemlist` label to JDK-8233437 as suggested in the ProblemListing section of the manual https://openjdk.org/guide/.

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

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

From alanb at openjdk.org  Fri Aug 19 06:47:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 06:47:44 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>

On Thu, 18 Aug 2022 18:50:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 182:

> 180:     jlong n;
> 181:     if (my_copy_file_range_func != NULL) {
> 182:         n = my_copy_file_range_func(srcFD, &offset, dstFD, NULL, count, 0);

I assume count will need to be cast to size_t for this to compile on all architectures.

src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 186:

> 184:             switch (errno) {
> 185:                 case EINTR:
> 186:                 case EINVAL:

For EINVAL we could return IOS_INTERRUPTED if you want.

src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 192:

> 190:                 default:
> 191:                     JNU_ThrowIOExceptionWithLastError(env, "Copy failed");
> 192:                     return IOS_THROWN;

Would you mind checking if we have tests that exercise transferTo when the target WritableByteChannel is to a file opened in append mode? Asking because copy_file_range will fall and I'm wondering what the existing behavior is.

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

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

From alanb at openjdk.org  Fri Aug 19 11:38:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 11:38:34 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v2]
In-Reply-To: <Ei9gBlXEmfg4ZI2KxFN2s20ms2KuwS-K5xSCbbmPsYk=.4883872c-21b1-4eed-a7e6-e50a72477479@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <Ei9gBlXEmfg4ZI2KxFN2s20ms2KuwS-K5xSCbbmPsYk=.4883872c-21b1-4eed-a7e6-e50a72477479@github.com>
Message-ID: <8oD2PWUNhqBRo5s58eQhjyrhT1vnKE6OMuJ_0t30jKo=.e475b643-33a1-4f35-b81c-b75c1936dd9d@github.com>

On Thu, 18 Aug 2022 21:55:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292566: Expand list of central abstractions; refine previous addition; update copyright year

src/java.base/share/classes/java/nio/package-info.java line 67:

> 65:  *   href="file/attribute/package-summary.html"><i>Attributes</i></a>,
> 66:  *   which represent <i>metadata</i> associated with <br> objects in a
> 67:  *   file system.  </p></li>

What would you think about reducing this down to "Path, which together with the Files class provide access to files.". The reason is that "FileSystem" isn't something that most developers will use directly and I don't think the attributes package is listed later and I don't think needs to be in the introducing to the abstractions.

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

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

From bpb at openjdk.org  Fri Aug 19 15:05:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 15:05:41 GMT
Subject: Integrated: 8292636: (dc) Problem listing of
 java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID
In-Reply-To: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>
References: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>
Message-ID: <J7d8368pGA-kNi34mmRUqnJHbKNB9iNuffLfdioXiOU=.3dc18cc1-39b2-4ed2-9640-31237c5cf789@github.com>

On Thu, 18 Aug 2022 20:41:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change problem listing to use the correct issue ID.

This pull request has now been integrated.

Changeset: 5ca268ca
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ca268ca65f3619139abeddd1070306db406ccc1
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8292636: (dc) Problem listing of java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID

Reviewed-by: jpai

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

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

From bpb at openjdk.org  Fri Aug 19 15:19:00 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 15:19:00 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v3]
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <pvNvcOrnQTP0ej-AbhWZ3VdoNsoBox0jmmqZ4Jw4APs=.7e67c79a-a42e-4495-95a0-fc860024d84e@github.com>

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

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

  8292566: Reduce central abstractions to Path and Files

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9910/files
  - new: https://git.openjdk.org/jdk/pull/9910/files/53cdc086..e7243777

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

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

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

From bpb at openjdk.org  Fri Aug 19 15:19:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 15:19:01 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v2]
In-Reply-To: <8oD2PWUNhqBRo5s58eQhjyrhT1vnKE6OMuJ_0t30jKo=.e475b643-33a1-4f35-b81c-b75c1936dd9d@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <Ei9gBlXEmfg4ZI2KxFN2s20ms2KuwS-K5xSCbbmPsYk=.4883872c-21b1-4eed-a7e6-e50a72477479@github.com>
 <8oD2PWUNhqBRo5s58eQhjyrhT1vnKE6OMuJ_0t30jKo=.e475b643-33a1-4f35-b81c-b75c1936dd9d@github.com>
Message-ID: <eIx_BxGueCKjBFyz8Xnt5PND59ocmth_hgR2RALcjJ8=.fdcc2e38-7d40-49f8-95a8-ca14bc3bb29d@github.com>

On Fri, 19 Aug 2022 11:34:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292566: Expand list of central abstractions; refine previous addition; update copyright year
>
> src/java.base/share/classes/java/nio/package-info.java line 67:
> 
>> 65:  *   href="file/attribute/package-summary.html"><i>Attributes</i></a>,
>> 66:  *   which represent <i>metadata</i> associated with <br> objects in a
>> 67:  *   file system.  </p></li>
> 
> What would you think about reducing this down to "Path, which together with the Files class provide access to files.". The reason is that "FileSystem" isn't something that most developers will use directly and I don't think the attributes package is listed later and I don't think needs to be in the introducing to the abstractions.

I agree that the list was too long. Fixed in e72437776a0625f526934294d2df4cab1d848056.

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

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

From bpb at openjdk.org  Fri Aug 19 15:27:49 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 15:27:49 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
Message-ID: <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>

On Fri, 19 Aug 2022 06:42:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 186:
> 
>> 184:             switch (errno) {
>> 185:                 case EINTR:
>> 186:                 case EINVAL:
> 
> For EINVAL we could return IOS_INTERRUPTED if you want.

Did you intend `EINTR`?

> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 192:
> 
>> 190:                 default:
>> 191:                     JNU_ThrowIOExceptionWithLastError(env, "Copy failed");
>> 192:                     return IOS_THROWN;
> 
> Would you mind checking if we have tests that exercise transferTo when the target WritableByteChannel is to a file opened in append mode? Asking because copy_file_range will fall and I'm wondering what the existing behavior is.

Given https://bugs.openjdk.org/browse/JDK-4950302 I suppose the existing code(`sendfile`) will fail as well but I'll check.

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

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

From naoto at openjdk.org  Fri Aug 19 16:40:08 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Aug 2022 16:40:08 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders like
 UTF-16
Message-ID: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>

Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

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

Commit messages:
 - 8292043: Incorrect decoding near EOF for stateful decoders like UTF-16

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

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

From alanb at openjdk.org  Fri Aug 19 17:11:33 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 17:11:33 GMT
Subject: RFR: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation [v3]
In-Reply-To: <pvNvcOrnQTP0ej-AbhWZ3VdoNsoBox0jmmqZ4Jw4APs=.7e67c79a-a42e-4495-95a0-fc860024d84e@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
 <pvNvcOrnQTP0ej-AbhWZ3VdoNsoBox0jmmqZ4Jw4APs=.7e67c79a-a42e-4495-95a0-fc860024d84e@github.com>
Message-ID: <Yb9xRRH7X_XBZa04t38509xmrkR47vCuUZLxflfE6Gs=.d520c39f-136e-48e6-a8c4-e744a68c7e3c@github.com>

On Fri, 19 Aug 2022 15:19:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292566: Reduce central abstractions to Path and Files

Update looks good.

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

Marked as reviewed by alanb (Reviewer).

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

From alanb at openjdk.org  Fri Aug 19 17:21:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Aug 2022 17:21:32 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
 <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
Message-ID: <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>

On Fri, 19 Aug 2022 15:25:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Given https://bugs.openjdk.org/browse/JDK-4950302 I suppose the existing code(`sendfile`) will fail as well but I'll check.

I'm pretty sure that sendfile64 will succeed but copy_file_range will fail. It may be that we have to add test for this scenario.

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

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

From joehw at openjdk.org  Fri Aug 19 20:13:49 2022
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 19 Aug 2022 20:13:49 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <qcV4LWGcM9IzQYaLWcBlB2zwzcqZyfMUYXALGrajyV8=.f49a5838-44e1-4c6c-b969-98d2b44a58c6@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

Marked as reviewed by joehw (Reviewer).

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

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

From bpb at openjdk.org  Fri Aug 19 20:21:57 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 20:21:57 GMT
Subject: RFR: 8292636: (dc) Problem listing of
 java/nio/channels/DatagramChannel/Unref.java has incorrect issue ID
In-Reply-To: <2FSMEZ16MKsu-NMbW4NRaMJmU3JKLc_bjSovtLpsz1Y=.9129dedd-05e6-48f2-80ca-d9419dce9ddc@github.com>
References: <E64tXmh7Pnh59-b1uGpuL5pZ8q83VKshcB_6DXwOxCs=.00ddf6ef-9e89-4c05-84ec-ee395883ca79@github.com>
 <2FSMEZ16MKsu-NMbW4NRaMJmU3JKLc_bjSovtLpsz1Y=.9129dedd-05e6-48f2-80ca-d9419dce9ddc@github.com>
Message-ID: <tQm54qShQad3tI4umIjpcYDBkDsaJF_CYK0MSHHbJXk=.d163295d-fb98-4657-8d79-5be6d38be8f3@github.com>

On Fri, 19 Aug 2022 01:49:58 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I've now added a `problemlist` label to JDK-8233437 as suggested in the ProblemListing section of the manual https://openjdk.org/guide/.

Thanks, I missed that.

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

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

From bpb at openjdk.org  Fri Aug 19 20:25:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 20:25:59 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
 <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
 <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>
Message-ID: <szek0RDbTPoyL07Syr0_Mq-f6b2CsGzX5yCfDS4iMdw=.fd91c79a-8326-413e-a3e5-2b246bd0e33e@github.com>

On Fri, 19 Aug 2022 17:17:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm pretty sure that sendfile64 will succeed but copy_file_range will fail. It may be that we have to add test for this scenario.

I will check both cases and probably add testing as there appears not to be any at present.

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

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

From bpb at openjdk.org  Fri Aug 19 22:09:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 22:09:10 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
Message-ID: <CIUyKbYS2HVACcyFTQDZXJggcW-aUR3W3b2bbVAV4IM=.19d5ab9d-05e3-48d2-b4fb-058c4dbc9161@github.com>

On Fri, 19 Aug 2022 06:41:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 182:
> 
>> 180:     jlong n;
>> 181:     if (my_copy_file_range_func != NULL) {
>> 182:         n = my_copy_file_range_func(srcFD, &offset, dstFD, NULL, count, 0);
> 
> I assume count will need to be cast to size_t for this to compile on all architectures.

Fixed in ee29211e7ebdfc6d9127bcf093de2a475f9c1a3a.

> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 186:
> 
>> 184:             switch (errno) {
>> 185:                 case EINTR:
>> 186:                 case EINVAL:
> 
> For EINTR we could return IOS_INTERRUPTED if you want.

So changed in ee29211e7ebdfc6d9127bcf093de2a475f9c1a3a.

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

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

From bpb at openjdk.org  Fri Aug 19 22:09:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 22:09:10 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux
In-Reply-To: <szek0RDbTPoyL07Syr0_Mq-f6b2CsGzX5yCfDS4iMdw=.fd91c79a-8326-413e-a3e5-2b246bd0e33e@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
 <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
 <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>
 <szek0RDbTPoyL07Syr0_Mq-f6b2CsGzX5yCfDS4iMdw=.fd91c79a-8326-413e-a3e5-2b246bd0e33e@github.com>
Message-ID: <WFe6tbk73WAbGkUr7ViYLJaynlMJukLrkk00XGn0VBw=.1ba8ee93-fde5-4fd0-bf58-b15b2a430c9a@github.com>

On Fri, 19 Aug 2022 20:22:31 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Given https://bugs.openjdk.org/browse/JDK-4950302 I suppose the existing code(`sendfile`) will fail as well but I'll check.
>> 
>> I'm pretty sure that sendfile64 will succeed but copy_file_range will fail. It may be that we have to add test for this scenario.
>
>> I'm pretty sure that sendfile64 will succeed but copy_file_range will fail. It may be that we have to add test for this scenario.
> 
> I will check both cases and probably add testing as there appears not to be any at present.

You are correct: `sendfile` succeeds but `copy_file_range` fails with `EBADF` when the destination is appending. I put in a fix for this in the source not to use `copy_file_range` if the target is open for appending. An alternative would be to just ignore `EBADF` if it occurred.

I will add a test next week.

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

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

From bpb at openjdk.org  Fri Aug 19 22:11:38 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Aug 2022 22:11:38 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v2]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <aM-b34f81J4zXA9KAdbnteF3lM4KkkkNdCERR67Ltq8=.cb2b1a26-d7c2-48a7-8c3a-c79c45147ad9@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Do not use copy_file_range() when appending

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/7c251bd8..ee29211e

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

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

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

From alanb at openjdk.org  Sat Aug 20 08:07:30 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Aug 2022 08:07:30 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

test/jdk/java/io/InputStreamReader/StatefulDecoderNearEOF.java line 53:

> 51:                     StandardCharsets.UTF_16.newDecoder().onMalformedInput(CodingErrorAction.REPORT))) {
> 52:                 System.out.printf("%04x%n", r.read()); // \u00d8 (wrong, uses UTF-16BE)
> 53:                 System.out.printf("%04x%n", r.read()); // EOF

This will pass if either read fails, I think the test should be checking that the first call to read throws MalformedInputException.

Would it be feasible to add a second test where there are characters between the BOM and the truncated high surrogate? It would be possible to decode those characters before it fails at the end of the stream.

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

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

From alanb at openjdk.org  Sat Aug 20 15:54:40 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Aug 2022 15:54:40 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v2]
In-Reply-To: <WFe6tbk73WAbGkUr7ViYLJaynlMJukLrkk00XGn0VBw=.1ba8ee93-fde5-4fd0-bf58-b15b2a430c9a@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
 <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
 <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>
 <szek0RDbTPoyL07Syr0_Mq-f6b2CsGzX5yCfDS4iMdw=.fd91c79a-8326-413e-a3e5-2b246bd0e33e@github.com>
 <WFe6tbk73WAbGkUr7ViYLJaynlMJukLrkk00XGn0VBw=.1ba8ee93-fde5-4fd0-bf58-b15b2a430c9a@github.com>
Message-ID: <47htLM7VdRvu-0iSou7k5fST3yKFUt7tPDMeCUxiRGw=.f322986f-98f7-4f3f-86e2-19fe6e7d2f30@github.com>

On Fri, 19 Aug 2022 22:06:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> You are correct: `sendfile` succeeds but `copy_file_range` fails with `EBADF` when the destination is appending. I put in a fix for this in the source not to use `copy_file_range` if the target is open for appending. An alternative would be to just ignore `EBADF` if it occurred.
> 
> I will add a test next week.

Thanks. The current patch looks okay and I think we can wrap this up once there is a test that exercises transferTo with the destination opened for append.

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

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

From duke at openjdk.org  Sun Aug 21 15:13:12 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 15:13:12 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <_s3sF9jqz1Y0MQgdRZhGtR-tw5SWD31kE9qc0VLVPu4=.b7288078-0987-422d-8dbf-08b3231c60b4@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Anyone to sponsor?

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

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

From duke at openjdk.org  Sun Aug 21 17:26:25 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 17:26:25 GMT
Subject: Integrated: 8290300: Use standard String-joining tools where
 applicable
In-Reply-To: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
Message-ID: <svnuj6nwuqYSwv8UKIS1dmTsPaOiLVcc3Bq496Iwb1k=.0a3c92b1-ee46-47ea-932b-71407fd5096f@github.com>

On Fri, 15 Jul 2022 12:03:13 GMT, ?????? ??????? <duke at openjdk.org> wrote:

> Simplify code with `String.join()`

This pull request has now been integrated.

Changeset: 9a65524e
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9a65524e2f98c1b4e253dcb637a708cec7b591bc
Stats:     18 lines in 4 files changed: 0 ins; 12 del; 6 mod

8290300: Use standard String-joining tools where applicable

Reviewed-by: naoto, rriggs, dfuchs

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

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

From duke at openjdk.org  Sun Aug 21 18:48:29 2022
From: duke at openjdk.org (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Sun, 21 Aug 2022 18:48:29 GMT
Subject: RFR: 8290300: Use standard String-joining tools where applicable
 [v5]
In-Reply-To: <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
References: <5c4PYJsqdf1zpWRJLUa1jR8iKF9qJP8fNTFQaTKi69w=.74b138d5-06dd-454c-b0da-8e2438edb7dc@github.com>
 <4IwUDJ0NtqbJl_KAgDMlb1ewkBtZtOHdPvz87aLASO8=.925ebd8a-2f8f-4150-b5ce-9feb6abec8c7@github.com>
Message-ID: <BCU12FIOG4jTD6ccnV1_RxyBvCcQAdqjq_CsekHDvr8=.8500dbee-3869-4ca6-bae4-274f7a658763@github.com>

On Mon, 18 Jul 2022 18:40:51 GMT, ?????? ??????? <duke at openjdk.org> wrote:

>> Simplify code with `String.join()`
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8290300: Revert erroneous changes

Thanks!

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

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

From naoto at openjdk.org  Sun Aug 21 23:19:16 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sun, 21 Aug 2022 23:19:16 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

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

  Modified the test per review suggestion

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9945/files
  - new: https://git.openjdk.org/jdk/pull/9945/files/24977db2..09846f00

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

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

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

From naoto at openjdk.org  Sun Aug 21 23:19:19 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Sun, 21 Aug 2022 23:19:19 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <AgSgKAVtu-gXoyPEGrQws5FRmlCIMNrufGGiyeJFcVk=.e089e642-f65e-4d1e-a8a1-335a48885f4b@github.com>
Message-ID: <A1CPW8JBx-qkDWILTFRcd52ZeBeenr98enjWGAwrwTo=.e700247b-4588-46fe-add6-e40ff7a79ccc@github.com>

On Sat, 20 Aug 2022 08:03:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Modified the test per review suggestion
>
> test/jdk/java/io/InputStreamReader/StatefulDecoderNearEOF.java line 53:
> 
>> 51:                     StandardCharsets.UTF_16.newDecoder().onMalformedInput(CodingErrorAction.REPORT))) {
>> 52:                 System.out.printf("%04x%n", r.read()); // \u00d8 (wrong, uses UTF-16BE)
>> 53:                 System.out.printf("%04x%n", r.read()); // EOF
> 
> This will pass if either read fails, I think the test should be checking that the first call to read throws MalformedInputException.
> 
> Would it be feasible to add a second test where there are characters between the BOM and the truncated high surrogate? It would be possible to decode those characters before it fails at the end of the stream.

Addressed both points.

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

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

From alanb at openjdk.org  Mon Aug 22 06:43:25 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Aug 2022 06:43:25 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
Message-ID: <-TSDa6wxWKjU4NIdKueApRv16V3IeRSpEFKaoWSlPDY=.00334da1-e546-4371-a469-3b58fc0a8124@github.com>

On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the test per review suggestion

Thanks for the update, I think the test is much better now.

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

Marked as reviewed by alanb (Reviewer).

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

From lancea at openjdk.org  Mon Aug 22 10:30:28 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 22 Aug 2022 10:30:28 GMT
Subject: RFR: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16 [v2]
In-Reply-To: <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
 <j0ZMW9bT_b5TLYpV375e_6m6mbpdam-y4NBoOEd_rgo=.1f52e9e0-4bad-4835-a45b-4141e65fb024@github.com>
Message-ID: <WiCraSqHGYa7lJ9SMxP2QFYPYuay_HOuQg99CZFZ3rQ=.a43dd658-9342-4ac2-bdbb-1ca78eeceef1@github.com>

On Sun, 21 Aug 2022 23:19:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Modified the test per review suggestion

Marked as reviewed by lancea (Reviewer).

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

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

From bpb at openjdk.org  Mon Aug 22 15:57:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Aug 2022 15:57:41 GMT
Subject: Integrated: 8292566: Add reference to the java.nio.file package in
 java.nio package documentation
In-Reply-To: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
References: <HBhQc7G75B1JrnsFLVHkDHCKrE9jSrGHPfwi6kjkipo=.41a15fdc-710e-4a34-a850-87b40c2c84c6@github.com>
Message-ID: <_crO9d-dzEFCjjN-nAc0xAQu5gZvd8TAbhYvmnM7SJQ=.f3cd0938-780f-42ad-9a95-14be6a678231@github.com>

On Wed, 17 Aug 2022 20:29:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a phrase about `java.nio.file` to the sentence in the `java.nio` package documentation describing its subpackages.

This pull request has now been integrated.

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

8292566: Add reference to the java.nio.file package in java.nio package documentation

Reviewed-by: iris, jpai, alanb

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

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

From naoto at openjdk.org  Mon Aug 22 16:31:39 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 22 Aug 2022 16:31:39 GMT
Subject: Integrated: 8292043: Incorrect decoding near EOF for stateful decoders
 like UTF-16
In-Reply-To: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
References: <R3eYC_8DTay21YAliVb9Eu7IBY4DXh6fNNsN1Dc__aM=.4bbbbae2-c96b-4330-b642-0fe5ecfe397a@github.com>
Message-ID: <-hDH22W2z2dk5_dOkW2kyaxffPe7LVeCVsg_ZXXsD6s=.d59f068d-0bf6-480b-9d83-f13053640b83@github.com>

On Fri, 19 Aug 2022 16:32:02 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Fixing incorrect state handling with EOF in `StreamDecoder`. There's a `reset()` call to the decoder seeing the EOF before the last `decode()` operation to handle the state correctly. Removing the call should not affect other cases because `reset()` is issued down the execution.

This pull request has now been integrated.

Changeset: aa9b8f04
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/aa9b8f04bf74d5fa00f2b27895e7369abea3a930
Stats:     80 lines in 2 files changed: 79 ins; 1 del; 0 mod

8292043: Incorrect decoding near EOF for stateful decoders like UTF-16

Reviewed-by: joehw, alanb, lancea

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

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

From bpb at openjdk.org  Mon Aug 22 16:56:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Aug 2022 16:56:15 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v3]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <mXwgP-BmXwJta0fY8Je8k432yzAnV28f-die3M6I3aE=.5f5095ad-a13a-406c-a9c6-0ddf627d60e8@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Also exclude sendfile when appending

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/ee29211e..88750dc5

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

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

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

From bpb at openjdk.org  Mon Aug 22 16:56:18 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Aug 2022 16:56:18 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v3]
In-Reply-To: <47htLM7VdRvu-0iSou7k5fST3yKFUt7tPDMeCUxiRGw=.f322986f-98f7-4f3f-86e2-19fe6e7d2f30@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <WRH8iiUswohL6XsT-ptho1JJF_taWEtyD_lfKhrssUE=.f79cc6b6-a6a2-49f4-a8d3-9b537bf044d9@github.com>
 <_tRcuw4Eb8Ksfu2rmgBD0ZrhqzO0l-nBkFwsCNp4ZZg=.c049cf07-4f34-4420-b2ba-058cbc27d5ca@github.com>
 <rFfxYwVNM8OiDFiik4jk6ZU0Nzs7Ed5SUUAYF23FoYc=.cae71e4b-8bab-4d80-a528-9ac66ab279c3@github.com>
 <szek0RDbTPoyL07Syr0_Mq-f6b2CsGzX5yCfDS4iMdw=.fd91c79a-8326-413e-a3e5-2b246bd0e33e@github.com>
 <WFe6tbk73WAbGkUr7ViYLJaynlMJukLrkk00XGn0VBw=.1ba8ee93-fde5-4fd0-bf58-b15b2a430c9a@github.com>
 <47htLM7VdRvu-0iSou7k5fST3yKFUt7tPDMeCUxiRGw=.f322986f-98f7-4f3f-86e2-19fe6e7d2f30@github.com>
Message-ID: <6CvlN8OSINP-ckVv8yX5gmsXyRB8SqJBnDBz7QwNKjo=.0fe32c50-c168-489a-bece-a06d712f658b@github.com>

On Sat, 20 Aug 2022 15:50:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> You are correct: `sendfile` succeeds but `copy_file_range` fails with `EBADF` when the destination is appending. I put in a fix for this in the source not to use `copy_file_range` if the target is open for appending. An alternative would be to just ignore `EBADF` if it occurred.
>> 
>> I will add a test next week.
>
>> You are correct: `sendfile` succeeds but `copy_file_range` fails with `EBADF` when the destination is appending. I put in a fix for this in the source not to use `copy_file_range` if the target is open for appending. An alternative would be to just ignore `EBADF` if it occurred.
>> 
>> I will add a test next week.
> 
> Thanks. The current patch looks okay and I think we can wrap this up once there is a test that exercises transferTo with the destination opened for append.

Actually I was mistaken: `sendfile` fails with `EINVAL` when the destination is appending. I updated the code and will next create a test.

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

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

From bpb at openjdk.org  Mon Aug 22 18:20:40 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Aug 2022 18:20:40 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Add test of transferTo while target is appending

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/88750dc5..c3c36f1d

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

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

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

From alanb at openjdk.org  Tue Aug 23 10:49:32 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Aug 2022 10:49:32 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
Message-ID: <M1tW876wv40t3Gn5cdwdfu-v7zqCWoU9LRRKGL-YmwE=.1d0c0052-ca02-4227-aa91-8d04eca32db1@github.com>

On Mon, 22 Aug 2022 18:20:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Add test of transferTo while target is appending

src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 190:

> 188:     off64_t offset = (off64_t)position;
> 189:     jlong n;
> 190:     if (my_copy_file_range_func) {

I assume this should check if my_copy_file_range_func is NULL.

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

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

From alanb at openjdk.org  Tue Aug 23 10:55:21 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Aug 2022 10:55:21 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
Message-ID: <rAbEjuDNJkWIcojVsfsjipMqR8wZ-0pSXovzTsJ77mc=.f1ebbaab-d14c-4ec5-8d2a-0047210695cf@github.com>

On Mon, 22 Aug 2022 18:20:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Add test of transferTo while target is appending

Marked as reviewed by alanb (Reviewer).

Aside from the check if copy_file_range is supported then I think the change to the transferTo implementation in c3c36f1d looks good. At some point I would expect we will pass the append flag from the java code. Have you looked at transferFrom for the append case? I suspect it is masked by the check for EBADF and now may be the time to re-examine that (okay to be a separate PR but hopefully you see the issue there).

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

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

From bpb at openjdk.org  Tue Aug 23 15:32:27 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Aug 2022 15:32:27 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <M1tW876wv40t3Gn5cdwdfu-v7zqCWoU9LRRKGL-YmwE=.1d0c0052-ca02-4227-aa91-8d04eca32db1@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
 <M1tW876wv40t3Gn5cdwdfu-v7zqCWoU9LRRKGL-YmwE=.1d0c0052-ca02-4227-aa91-8d04eca32db1@github.com>
Message-ID: <CV26vYF3_mnkRr97Fst9YdvcYtuRUvDVf3avozFnklM=.57778104-6434-40ac-9547-04d98cb8e1bb@github.com>

On Tue, 23 Aug 2022 10:45: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:
>> 
>>   8292562: Add test of transferTo while target is appending
>
> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 190:
> 
>> 188:     off64_t offset = (off64_t)position;
>> 189:     jlong n;
>> 190:     if (my_copy_file_range_func) {
> 
> I assume this should check if my_copy_file_range_func is NULL.

Yes, it should.

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

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

From bpb at openjdk.org  Tue Aug 23 15:36:20 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Aug 2022 15:36:20 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <rAbEjuDNJkWIcojVsfsjipMqR8wZ-0pSXovzTsJ77mc=.f1ebbaab-d14c-4ec5-8d2a-0047210695cf@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
 <rAbEjuDNJkWIcojVsfsjipMqR8wZ-0pSXovzTsJ77mc=.f1ebbaab-d14c-4ec5-8d2a-0047210695cf@github.com>
Message-ID: <iy-90dwprcEnzdde1LHRKMANLwIt0Zxo_ZGgKIMNkvQ=.e0fcfe51-0dec-4ca6-b9d4-42679c911990@github.com>

On Tue, 23 Aug 2022 10:51:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> At some point I would expect we will pass the append flag from the java code.

Agreed.

> Have you looked at transferFrom for the append case? I suspect it is masked by the check for EBADF

Yep, same problem.

> and now may be the time to re-examine that (okay to be a separate PR but hopefully you see the issue there).

Might as well go ahead and fix this in another rev of this PR.

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

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

From bpb at openjdk.org  Tue Aug 23 17:54:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Aug 2022 17:54:17 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v5]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <1KrBmf8zRhjHz4X6I8HvmBYyYJ7p_nYVoS5dab5DMxI=.29592ad7-47a8-4d3e-872d-ece2c8acabfc@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Add append parameter; add transferFrom to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/c3c36f1d..34e03520

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

  Stats: 70 lines in 4 files changed: 18 ins; 10 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/9925.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9925/head:pull/9925

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

From bpb at openjdk.org  Tue Aug 23 17:54:20 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Aug 2022 17:54:20 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v4]
In-Reply-To: <CV26vYF3_mnkRr97Fst9YdvcYtuRUvDVf3avozFnklM=.57778104-6434-40ac-9547-04d98cb8e1bb@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <W8Rko7LwY5dJTe6i6AMCj18WN0vy2JLCmfy6H5D4mUM=.ebafd690-796e-41c6-a244-abb73505fe97@github.com>
 <M1tW876wv40t3Gn5cdwdfu-v7zqCWoU9LRRKGL-YmwE=.1d0c0052-ca02-4227-aa91-8d04eca32db1@github.com>
 <CV26vYF3_mnkRr97Fst9YdvcYtuRUvDVf3avozFnklM=.57778104-6434-40ac-9547-04d98cb8e1bb@github.com>
Message-ID: <NzSeVxnzBF5ex932LQhorMJwxWZh4R85QlATOur-6Dg=.1b540179-479a-4465-ab37-c028bdaf37b3@github.com>

On Tue, 23 Aug 2022 15:30:19 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/ch/FileChannelImpl.c line 190:
>> 
>>> 188:     off64_t offset = (off64_t)position;
>>> 189:     jlong n;
>>> 190:     if (my_copy_file_range_func) {
>> 
>> I assume this should check if my_copy_file_range_func is NULL.
>
> Yes, it should.

Fixed in 34e035206b5498ee9048afb6fe0702ba59971480.

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

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

From alanb at openjdk.org  Wed Aug 24 07:07:34 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Aug 2022 07:07:34 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v5]
In-Reply-To: <1KrBmf8zRhjHz4X6I8HvmBYyYJ7p_nYVoS5dab5DMxI=.29592ad7-47a8-4d3e-872d-ece2c8acabfc@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <1KrBmf8zRhjHz4X6I8HvmBYyYJ7p_nYVoS5dab5DMxI=.29592ad7-47a8-4d3e-872d-ece2c8acabfc@github.com>
Message-ID: <LBCIkQPJtk3g4tcaOaSYN692o_993oEvxg6s_UjbqXo=.b8e8f257-54e9-43f8-a9d1-80f873ddf462@github.com>

On Tue, 23 Aug 2022 17:54:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Add append parameter; add transferFrom to test

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 576:

> 574:                 long comp = Blocker.begin();
> 575:                 try {
> 576:                     boolean append = fdAccess.getAppend(targetFD);

Can you move this to before the do-while as it does not need to be in the loop or in the Blocker.begin/end.

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

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

From bpb at openjdk.org  Wed Aug 24 14:44:37 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Aug 2022 14:44:37 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v6]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <ATXyIlbPHUcNiQR3jQtvpiJj285s1gFBi5t36CtzZCM=.4ccf9d6e-aa81-470c-8be6-98add8ba969a@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Move getAppend out of while loop and Blocker begin / end

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/34e03520..e10abedd

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

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

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

From bpb at openjdk.org  Wed Aug 24 14:44:40 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Aug 2022 14:44:40 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v5]
In-Reply-To: <LBCIkQPJtk3g4tcaOaSYN692o_993oEvxg6s_UjbqXo=.b8e8f257-54e9-43f8-a9d1-80f873ddf462@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <1KrBmf8zRhjHz4X6I8HvmBYyYJ7p_nYVoS5dab5DMxI=.29592ad7-47a8-4d3e-872d-ece2c8acabfc@github.com>
 <LBCIkQPJtk3g4tcaOaSYN692o_993oEvxg6s_UjbqXo=.b8e8f257-54e9-43f8-a9d1-80f873ddf462@github.com>
Message-ID: <GCs8fAGdj7FUK-GpLpzIpd4MUnEDAJXqX8N75ZiHS6M=.0fda305a-d8e6-4568-aa36-1caf92eb94e3@github.com>

On Wed, 24 Aug 2022 07:05:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8292562: Add append parameter; add transferFrom to test
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 576:
> 
>> 574:                 long comp = Blocker.begin();
>> 575:                 try {
>> 576:                     boolean append = fdAccess.getAppend(targetFD);
> 
> Can you move this to before the do-while as it does not need to be in the loop or in the Blocker.begin/end.

Fixed in e10abeddf7bad5c7ab80c200f78aa3bd5df8916c.

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

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

From alanb at openjdk.org  Wed Aug 24 14:54:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Aug 2022 14:54:28 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v6]
In-Reply-To: <ATXyIlbPHUcNiQR3jQtvpiJj285s1gFBi5t36CtzZCM=.4ccf9d6e-aa81-470c-8be6-98add8ba969a@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <ATXyIlbPHUcNiQR3jQtvpiJj285s1gFBi5t36CtzZCM=.4ccf9d6e-aa81-470c-8be6-98add8ba969a@github.com>
Message-ID: <B2woV2f9EGeYahKS0OVDKnkdwA8ib-8fSLBiIHp_uLE=.0f7f9582-01b3-4cab-8aa3-3bea6b6596d4@github.com>

On Wed, 24 Aug 2022 14:44:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Move getAppend out of while loop and Blocker begin / end

I think this one is done.

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

Marked as reviewed by alanb (Reviewer).

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

From bpb at openjdk.org  Thu Aug 25 02:56:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 02:56:01 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v7]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <yxBozmxRDk0GwuzdvVHxRKDMbWY24BzxVyorQ3yyTHo=.b03da548-b1b7-4e79-a3f4-c35b72282fb8@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Fix test on macOS and Windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/e10abedd..ec2ad5d5

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

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

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

From bpb at openjdk.org  Thu Aug 25 02:56:02 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 02:56:02 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v6]
In-Reply-To: <B2woV2f9EGeYahKS0OVDKnkdwA8ib-8fSLBiIHp_uLE=.0f7f9582-01b3-4cab-8aa3-3bea6b6596d4@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <ATXyIlbPHUcNiQR3jQtvpiJj285s1gFBi5t36CtzZCM=.4ccf9d6e-aa81-470c-8be6-98add8ba969a@github.com>
 <B2woV2f9EGeYahKS0OVDKnkdwA8ib-8fSLBiIHp_uLE=.0f7f9582-01b3-4cab-8aa3-3bea6b6596d4@github.com>
Message-ID: <Jp9FPwwSKH6yv075QKdvCFpq9zeaY5In7ch_EuXGRzg=.afd67a2f-6c18-47df-af34-7ec3250f4b9f@github.com>

On Wed, 24 Aug 2022 14:50:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this one is done.

Well, maybe it is _now_: the new test failed on macOS and Windows which do not have the problem reported in [JDK-4950302](https://bugs.openjdk.org/browse/JDK-4950302). Fixed in commit ec2ad5d554acd7bcb7ee38e8de11625ac1ea20d7.

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

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

From alanb at openjdk.org  Thu Aug 25 08:30:28 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Aug 2022 08:30:28 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v6]
In-Reply-To: <Jp9FPwwSKH6yv075QKdvCFpq9zeaY5In7ch_EuXGRzg=.afd67a2f-6c18-47df-af34-7ec3250f4b9f@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <ATXyIlbPHUcNiQR3jQtvpiJj285s1gFBi5t36CtzZCM=.4ccf9d6e-aa81-470c-8be6-98add8ba969a@github.com>
 <B2woV2f9EGeYahKS0OVDKnkdwA8ib-8fSLBiIHp_uLE=.0f7f9582-01b3-4cab-8aa3-3bea6b6596d4@github.com>
 <Jp9FPwwSKH6yv075QKdvCFpq9zeaY5In7ch_EuXGRzg=.afd67a2f-6c18-47df-af34-7ec3250f4b9f@github.com>
Message-ID: <BHQoKRbzbCGrPhQaLjxeJx01frnmhvtZ1uXveTiJyzQ=.fd751054-cfa3-4b39-9d94-9a7ad0b28cef@github.com>

On Thu, 25 Aug 2022 02:52:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I think this one is done.
> 
> Well, maybe it is _now_: the new test failed on macOS and Windows which do not have the problem reported in ...

A long standing issue is that FileChannel needs to specify how methods that take a position behave when a file is opened for append. This includes the transferXXX methods. It may be that transferFrom needs to be allowed to throw an exception when called on a FileChannel to a file opened for append. So maybe the simplest thing for now is to revert the test back to testing transferTo when the target is opened for append. That will be a simpler test to maintain.

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

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

From bpb at openjdk.org  Thu Aug 25 15:44:32 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 15:44:32 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v7]
In-Reply-To: <yxBozmxRDk0GwuzdvVHxRKDMbWY24BzxVyorQ3yyTHo=.b03da548-b1b7-4e79-a3f4-c35b72282fb8@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <yxBozmxRDk0GwuzdvVHxRKDMbWY24BzxVyorQ3yyTHo=.b03da548-b1b7-4e79-a3f4-c35b72282fb8@github.com>
Message-ID: <kEhSDQOaDsG1ravKSz0FtJDP7DwPbvw0cMgEY5COblU=.71b06cb6-9d22-41fe-8cb9-ce29c62f5ac7@github.com>

On Thu, 25 Aug 2022 02:56:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Fix test on macOS and Windows

> [M]aybe the simplest thing for now is to revert the test back to testing transferTo when the target is opened for append.

So changed in 6351c8d26b30cd92b6d4a1facbc25fb304d28bc0 and limited to run on Linux only.

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

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

From bpb at openjdk.org  Thu Aug 25 15:44:29 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 15:44:29 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v8]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <47v1pPKsuOhSIqMVLV67gDlKALU6z4-Qj2_rZACtGa0=.c3dff45c-b629-4521-b61f-43f1d4c66202@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Revert to test transferTo only and constrain to Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/ec2ad5d5..6351c8d2

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

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

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

From bpb at openjdk.org  Thu Aug 25 18:37:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Aug 2022 18:37:43 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v9]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <CPy9wXtmCxNaxWM6BBiseS-sxN8JfyEPklU0fHaKrpY=.25dce8e2-42e1-4a59-bf4e-ea76d09a611d@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: "Really" remove transferFrom test; remove @requires Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/6351c8d2..e8c4d4bb

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

  Stats: 44 lines in 1 file changed: 5 ins; 8 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/9925.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9925/head:pull/9925

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

From alanb at openjdk.org  Fri Aug 26 08:30:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 08:30:55 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v9]
In-Reply-To: <CPy9wXtmCxNaxWM6BBiseS-sxN8JfyEPklU0fHaKrpY=.25dce8e2-42e1-4a59-bf4e-ea76d09a611d@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <CPy9wXtmCxNaxWM6BBiseS-sxN8JfyEPklU0fHaKrpY=.25dce8e2-42e1-4a59-bf4e-ea76d09a611d@github.com>
Message-ID: <lqZpYVuDbSUG3ZolS31wwm-YRt9yv3qbngzf4Vos6D8=.7eab4c91-3b3a-4d69-a4d6-92f37bd739cf@github.com>

On Thu, 25 Aug 2022 18:37:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: "Really" remove transferFrom test; remove @requires Linux

The test no longer needs to build jdk.test.lib.Platform, otherwise the update looks okay.

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

Marked as reviewed by alanb (Reviewer).

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

From bpb at openjdk.org  Fri Aug 26 15:09:06 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 15:09:06 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v10]
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <Rvggv9dol3wp-LUy4vM845zN-siaYxShMcx-GZmhQEI=.04fbb630-1af1-4641-bd37-10dd2c50e49f@github.com>

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

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

  8292562: Remove building Platform

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9925/files
  - new: https://git.openjdk.org/jdk/pull/9925/files/e8c4d4bb..6182d3b0

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

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

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

From bpb at openjdk.org  Fri Aug 26 15:09:07 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 15:09:07 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v9]
In-Reply-To: <lqZpYVuDbSUG3ZolS31wwm-YRt9yv3qbngzf4Vos6D8=.7eab4c91-3b3a-4d69-a4d6-92f37bd739cf@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <CPy9wXtmCxNaxWM6BBiseS-sxN8JfyEPklU0fHaKrpY=.25dce8e2-42e1-4a59-bf4e-ea76d09a611d@github.com>
 <lqZpYVuDbSUG3ZolS31wwm-YRt9yv3qbngzf4Vos6D8=.7eab4c91-3b3a-4d69-a4d6-92f37bd739cf@github.com>
Message-ID: <v4sSBwzkN3_Yemgv-hY4Amnxu029zWUsVfI1qSwBCkU=.9b4c448e-4966-485e-86d6-98eb1157892c@github.com>

On Fri, 26 Aug 2022 08:27:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test no longer needs to build jdk.test.lib.Platform, otherwise the update looks okay.

Ack. I had to forget something. Fixed in 6182d3b01f441e0f4ff1d6b7ffbd3561790d3943.

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

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

From alanb at openjdk.org  Fri Aug 26 16:13:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Aug 2022 16:13:58 GMT
Subject: RFR: 8292562: (fc) Use copy_file_range in FileChannel::transferTo
 on Linux [v10]
In-Reply-To: <Rvggv9dol3wp-LUy4vM845zN-siaYxShMcx-GZmhQEI=.04fbb630-1af1-4641-bd37-10dd2c50e49f@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
 <Rvggv9dol3wp-LUy4vM845zN-siaYxShMcx-GZmhQEI=.04fbb630-1af1-4641-bd37-10dd2c50e49f@github.com>
Message-ID: <mc4LctovhbE0Ov_ltVwOjFshRehvRqGzQBUl-0odWAM=.a90857ce-74b7-44c5-9c4d-1a56be8c6347@github.com>

On Fri, 26 Aug 2022 15:09:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8292562: Remove building Platform

Marked as reviewed by alanb (Reviewer).

> > The test no longer needs to build jdk.test.lib.Platform, otherwise the update looks okay.
> 
> Ack. I had to forget something. Fixed in [6182d3b](https://github.com/openjdk/jdk/commit/6182d3b01f441e0f4ff1d6b7ffbd3561790d3943).

Thanks. MIN_SIZE is a left-over too, we can get that the next time.

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

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

From bpb at openjdk.org  Fri Aug 26 16:17:06 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Aug 2022 16:17:06 GMT
Subject: Integrated: 8292562: (fc) Use copy_file_range in
 FileChannel::transferTo on Linux
In-Reply-To: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
References: <A5O0ItGB67WbzAxiZJw7enLB1oN3pcf-314dU6jreqk=.264d1517-c7ae-4bc1-8455-0b297b9cdffd@github.com>
Message-ID: <8n997fc1tzMzSl_FW-hQTE7P_YSfP0RHBN4Pgh3N9k4=.a9479cde-7123-4bde-98a0-029db7f83668@github.com>

On Thu, 18 Aug 2022 18:50:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add `copy_file_range(2)` to the native Linux implementation of `FileChannel::transferTo`.

This pull request has now been integrated.

Changeset: c74b6d45
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c74b6d4552da55fea8f64a1e4c1a5675037a7124
Stats:     151 lines in 4 files changed: 141 ins; 0 del; 10 mod

8292562: (fc) Use copy_file_range in FileChannel::transferTo on Linux

Reviewed-by: alanb

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

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

From fweimer at openjdk.org  Sat Aug 27 10:20:18 2022
From: fweimer at openjdk.org (Florian Weimer)
Date: Sat, 27 Aug 2022 10:20:18 GMT
Subject: RFR: 8293004: (fs) copy_file_range needs fallback handling for ENOSYS
Message-ID: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>

Now that the userspace emulation is not leveraged anymore, it would be possible to issue the system call directly for all glibc versions, but it's probably best not to start using `copy_file_range` where it hasn't been used before (the el7 kernel has a strange backport, if I recall correctly).

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

Commit messages:
 - 8293004: (fs) copy_file_range needs fallback handling for ENOSYS

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

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

From thomas.stuefe at gmail.com  Sat Aug 27 10:50:56 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sat, 27 Aug 2022 12:50:56 +0200
Subject: RFR: 8293004: (fs) copy_file_range needs fallback handling for
 ENOSYS
In-Reply-To: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
Message-ID: <CAA-vtUwgtcgT6j+AqnOC07SPsBXGLAsmJSuEDpt6zVY3W4CrNA@mail.gmail.com>

Hi Florian,

do I understand this correctly: by backporting the user-space emulation for
copy_file_range, glibc 2.27 broke compatibility with kernels < 4.5?

If yes, why did glibc not retain the emulation for the ENOSYS case?

Cheers, Thomas

On Sat, Aug 27, 2022 at 12:20 PM Florian Weimer <fweimer at openjdk.org> wrote:

> Now that the userspace emulation is not leveraged anymore, it would be
> possible to issue the system call directly for all glibc versions, but it's
> probably best not to start using `copy_file_range` where it hasn't been
> used before (the el7 kernel has a strange backport, if I recall correctly).
>
> -------------
>
> Commit messages:
>  - 8293004: (fs) copy_file_range needs fallback handling for ENOSYS
>
> Changes: https://git.openjdk.org/jdk/pull/10055/files
>  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10055&range=00
>   Issue: https://bugs.openjdk.org/browse/JDK-8293004
>   Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
>   Patch: https://git.openjdk.org/jdk/pull/10055.diff
>   Fetch: git fetch https://git.openjdk.org/jdk pull/10055/head:pull/10055
>
> PR: https://git.openjdk.org/jdk/pull/10055
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220827/9a16fc4e/attachment.htm>

From stuefe at openjdk.org  Sat Aug 27 11:50:31 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 27 Aug 2022 11:50:31 GMT
Subject: RFR: 8293004: (fs) FileChannel.transferXXX use of copy_file_range
 needs fallback handling for ENOSYS
In-Reply-To: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
Message-ID: <GGkPmskT3AJ4I_v-3z9wXVjMUUEt_hEUhvBoLy82wwY=.0aac50b7-a135-40e2-b3e9-a3f70538fe06@github.com>

On Sat, 27 Aug 2022 10:12:08 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Now that the userspace emulation is not leveraged anymore, it would be possible to issue the system call directly for all glibc versions, but it's probably best not to start using `copy_file_range` where it hasn't been used before (the el7 kernel has a strange backport, if I recall correctly).

This makes sense.

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

Marked as reviewed by stuefe (Reviewer).

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

From alanb at openjdk.org  Sat Aug 27 16:11:22 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 27 Aug 2022 16:11:22 GMT
Subject: RFR: 8293004: (fs) FileChannel.transferXXX use of copy_file_range
 needs fallback handling for ENOSYS
In-Reply-To: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
Message-ID: <9WPI5SUCZ_dEeuKrKVuoELl6KO5eOV_6mkqUhZ6Fl3Q=.0384ed28-18ec-46ae-b522-310c499efe77@github.com>

On Sat, 27 Aug 2022 10:12:08 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Now that the userspace emulation is not leveraged anymore, it would be possible to issue the system call directly for all glibc versions, but it's probably best not to start using `copy_file_range` where it hasn't been used before (the el7 kernel has a strange backport, if I recall correctly).

This looks okay.

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

Marked as reviewed by alanb (Reviewer).

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

From fweimer at redhat.com  Sat Aug 27 12:45:07 2022
From: fweimer at redhat.com (Florian Weimer)
Date: Sat, 27 Aug 2022 14:45:07 +0200
Subject: RFR: 8293004: (fs) copy_file_range needs fallback handling for
 ENOSYS
In-Reply-To: <CAA-vtUwgtcgT6j+AqnOC07SPsBXGLAsmJSuEDpt6zVY3W4CrNA@mail.gmail.com>
 ("Thomas =?utf-8?Q?St=C3=BCfe=22's?= message of "Sat, 27 Aug 2022 12:50:56
 +0200")
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
 <CAA-vtUwgtcgT6j+AqnOC07SPsBXGLAsmJSuEDpt6zVY3W4CrNA@mail.gmail.com>
Message-ID: <87ilmdonxo.fsf@oldenburg.str.redhat.com>

* Thomas St?fe:

> do I understand this correctly: by backporting the user-space
> emulation for copy_file_range, glibc 2.27 broke compatibility with
> kernels < 4.5?
>
> If yes, why did glibc not retain the emulation for the ENOSYS case?

The emulation was buggy in corner cases, and the kernel kept changing
behavior, too.  With the current implementation, an application can
decide whether they want to roll their own slightly dodgy copying loop
if there is no kernel support.  With the emulation present, that wasn't
possible.

(Not sure if the <fweimer at openjdk.org> address works.)

Thanks,
Florian


From thomas.stuefe at gmail.com  Sun Aug 28 06:53:13 2022
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Sun, 28 Aug 2022 08:53:13 +0200
Subject: RFR: 8293004: (fs) copy_file_range needs fallback handling for
 ENOSYS
In-Reply-To: <87ilmdonxo.fsf@oldenburg.str.redhat.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
 <CAA-vtUwgtcgT6j+AqnOC07SPsBXGLAsmJSuEDpt6zVY3W4CrNA@mail.gmail.com>
 <87ilmdonxo.fsf@oldenburg.str.redhat.com>
Message-ID: <CAA-vtUwpL5X+10HZJJTvQOA5Tx=k_d0i042JoJ+O0PUBfgJzAQ@mail.gmail.com>

Thanks for the clarification, Florian!

..Thomas

On Sat, Aug 27, 2022 at 2:45 PM Florian Weimer <fweimer at redhat.com> wrote:

> * Thomas St?fe:
>
> > do I understand this correctly: by backporting the user-space
> > emulation for copy_file_range, glibc 2.27 broke compatibility with
> > kernels < 4.5?
> >
> > If yes, why did glibc not retain the emulation for the ENOSYS case?
>
> The emulation was buggy in corner cases, and the kernel kept changing
> behavior, too.  With the current implementation, an application can
> decide whether they want to roll their own slightly dodgy copying loop
> if there is no kernel support.  With the emulation present, that wasn't
> possible.
>
> (Not sure if the <fweimer at openjdk.org> address works.)
>
> Thanks,
> Florian
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220828/67dfa5a8/attachment-0001.htm>

From bpb at openjdk.org  Mon Aug 29 16:06:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 29 Aug 2022 16:06:10 GMT
Subject: RFR: 8293004: (fs) FileChannel.transferXXX use of copy_file_range
 needs fallback handling for ENOSYS
In-Reply-To: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
Message-ID: <j368iIKfjxjHI0AVzXf5Afvsk8K1ZEnQt728ClOMciM=.65494cb3-585f-47f9-b570-a330d1fa344c@github.com>

On Sat, 27 Aug 2022 10:12:08 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Now that the userspace emulation is not leveraged anymore, it would be possible to issue the system call directly for all glibc versions, but it's probably best not to start using `copy_file_range` where it hasn't been used before (the el7 kernel has a strange backport, if I recall correctly).

Marked as reviewed by bpb (Reviewer).

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

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

From bpb at openjdk.org  Tue Aug 30 00:23:46 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Aug 2022 00:23:46 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
Message-ID: <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>

> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - 8264744: Refactor UnixCopyFile::copyFile into UnixFileSystem; refactor OS-specific code to {Bsd,Linux}FileSystem
 - Merge
 - 8264744: Add mode to clone() and other requested changes
 - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
 - Merge
 - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
 - Merge
 - 8264744: Fix typo desintation -> destination
 - 8264744: Refactor into UnixCopyFile hierarchy
 - Merge
 - ... and 3 more: https://git.openjdk.org/jdk/compare/c74b6d45...ecce2093

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

Changes: https://git.openjdk.org/jdk/pull/9486/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9486&range=08
  Stats: 1326 lines in 16 files changed: 919 ins; 393 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/9486.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9486/head:pull/9486

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

From maxim.kartashev at jetbrains.com  Tue Aug 30 06:50:22 2022
From: maxim.kartashev at jetbrains.com (Maxim Kartashev)
Date: Tue, 30 Aug 2022 09:50:22 +0300
Subject: Any interest in WatchService based on MacOS FSEvents?
Message-ID: <CAG0Tb0iSUqxHfT22b4x3Vp71rwzG94yNyZLzo6gMMJEZEx+e-g@mail.gmail.com>

WatchService on MacOS is still implemented by the generic
PollingWatchService, which continuously re-scans the directory consuming
CPU, introduces large latencies to the generated WatchEvent's, and misses
changes that occur faster than the re-scan interval. At the same time,
there are two technologies available on the platform to receive the
necessary information from the OS similar to what is available on Windows
and Linux: Kernel Queues and File System Events, the latter being more
suitable for implementing the WatchServie functionality.

There are several stand-alone implementations out there that utilize one or
the other (or even both), which suggests that demand exists for
WatchService on MacOS to be more responsive and less resource-hungry.

If the community is interested in getting this functionality in OpenJDK
proper, I'd be happy to contribute code that was developed, tested, and
used at JetBrains for around half a year. It is based on FSEvents, supports
the FILE_TREE modifier (recursive directory watch), and does not do any
excessive I/O except the necessary minimum.

References
* WatchService interface
  -
https://docs.oracle.com/en/java/javase/18/docs/api/java.base/java/nio/file/WatchService.html
* PollingWatchService source code
  -
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java
* File System Events
  -
https://developer.apple.com/documentation/coreservices/file_system_events?language=objc
* Kernel Queues
  -
https://developer.apple.com/library/archive/documentation/Darwin/Conceptual/FSEvents_ProgGuide/KernelQueues/KernelQueues.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220830/05598437/attachment.htm>

From Alan.Bateman at oracle.com  Tue Aug 30 07:02:33 2022
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Tue, 30 Aug 2022 08:02:33 +0100
Subject: Any interest in WatchService based on MacOS FSEvents?
In-Reply-To: <CAG0Tb0iSUqxHfT22b4x3Vp71rwzG94yNyZLzo6gMMJEZEx+e-g@mail.gmail.com>
References: <CAG0Tb0iSUqxHfT22b4x3Vp71rwzG94yNyZLzo6gMMJEZEx+e-g@mail.gmail.com>
Message-ID: <696b3ce6-eb39-c9ed-3681-0ed68a18fc37@oracle.com>

On 30/08/2022 07:50, Maxim Kartashev wrote:
> WatchService on MacOS is still implemented by the generic 
> PollingWatchService, which continuously re-scans the directory 
> consuming CPU, introduces large latencies to the generated 
> WatchEvent's, and misses changes that occur faster than the re-scan 
> interval. At the same time, there are two technologies available on 
> the platform to receive the necessary information from the OS similar 
> to what is available on Windows and Linux: Kernel Queues and File 
> System Events, the latter being more suitable for implementing the 
> WatchServie functionality.
>
> There are several stand-alone implementations out there that utilize 
> one or the other (or even both), which suggests that demand exists for 
> WatchService on MacOS to be more responsive and less resource-hungry.
>
> If the community is interested in getting this functionality in 
> OpenJDK proper, I'd be happy to contribute code that was developed, 
> tested, and used at JetBrains for around half a year. It is based on 
> FSEvents, supports the FILE_TREE modifier (recursive directory watch), 
> and does not do any excessive I/O except the necessary minimum.
>
There were been a number of prototypes a few years ago but they didn't 
get to the point of being proposed for the main line. It's always been 
on the list "to do".

So if you can develop an implementation that fits into the current 
framework (AbstractWatchService etc.) and passes the tests then feel 
free to propose. It would help the review if the native code is just 
simple wrappers about the FSEvents as we'll likely replace a lot of the 
JNI code in this area in time. In general, keeping it as consistent as 
possible with the other code in this area would help too.

-Alan

From alanb at openjdk.org  Tue Aug 30 11:06:15 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Aug 2022 11:06:15 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
Message-ID: <mC-Uqe5KhKO83oH_BZz6_OVtVt9f9s5pcCOCByAsgAI=.dbb47da6-b1c1-46f6-a45d-5de0878bd320@github.com>

On Tue, 30 Aug 2022 00:23:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - 8264744: Refactor UnixCopyFile::copyFile into UnixFileSystem; refactor OS-specific code to {Bsd,Linux}FileSystem
>  - Merge
>  - 8264744: Add mode to clone() and other requested changes
>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>  - Merge
>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>  - Merge
>  - 8264744: Fix typo desintation -> destination
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c74b6d45...ecce2093

I've skimmed through ecce2093. There is a lot of refactoring (which is good) and it also introduces the use of clone on macOS. What would you think about separating this two? Let's get the Linux and BSD/macOS separation out of the way and that would allow us to discuss the semantics issue and agree when it is safe to use clone.

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

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

From bpb at openjdk.org  Tue Aug 30 14:59:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Aug 2022 14:59:01 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <mC-Uqe5KhKO83oH_BZz6_OVtVt9f9s5pcCOCByAsgAI=.dbb47da6-b1c1-46f6-a45d-5de0878bd320@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
 <mC-Uqe5KhKO83oH_BZz6_OVtVt9f9s5pcCOCByAsgAI=.dbb47da6-b1c1-46f6-a45d-5de0878bd320@github.com>
Message-ID: <-fQqXePvh1a8R4HzivMPrPPI2x8iZzWh_FOGEnJ8KZ8=.4acd6efc-8039-45e8-a558-af885f04da74@github.com>

On Tue, 30 Aug 2022 11:03:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> What would you think about separating this two?

That would be fine with me, but I think the BSD / Linux separation should be done under a different issue with the `clonefile` work remaining under this one. The addition of `copy_file_range` function is also more pertinent to this issue than to refactoring however so I don't know under which that should go.

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

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

From alanb at openjdk.org  Tue Aug 30 15:10:00 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Aug 2022 15:10:00 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <-fQqXePvh1a8R4HzivMPrPPI2x8iZzWh_FOGEnJ8KZ8=.4acd6efc-8039-45e8-a558-af885f04da74@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
 <mC-Uqe5KhKO83oH_BZz6_OVtVt9f9s5pcCOCByAsgAI=.dbb47da6-b1c1-46f6-a45d-5de0878bd320@github.com>
 <-fQqXePvh1a8R4HzivMPrPPI2x8iZzWh_FOGEnJ8KZ8=.4acd6efc-8039-45e8-a558-af885f04da74@github.com>
Message-ID: <pCT5pXIcrDVQ-P1NAcLqcVnHeAuTeXgxPZtJHeQZ2AU=.ecfe3d4f-b23c-442e-9b4e-b16f3dd3d10e@github.com>

On Tue, 30 Aug 2022 14:56:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> That would be fine with me, but I think the BSD / Linux separation should be done under a different issue with the `clonefile` work remaining under this one. 

That's okay, I think the main important point is that the refactoring is worthy on its own and if we get that queued up before the clonefile then it will make it easier to discuss clonefile.

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

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

From bpb at openjdk.org  Tue Aug 30 15:24:28 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Aug 2022 15:24:28 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <pCT5pXIcrDVQ-P1NAcLqcVnHeAuTeXgxPZtJHeQZ2AU=.ecfe3d4f-b23c-442e-9b4e-b16f3dd3d10e@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
 <mC-Uqe5KhKO83oH_BZz6_OVtVt9f9s5pcCOCByAsgAI=.dbb47da6-b1c1-46f6-a45d-5de0878bd320@github.com>
 <-fQqXePvh1a8R4HzivMPrPPI2x8iZzWh_FOGEnJ8KZ8=.4acd6efc-8039-45e8-a558-af885f04da74@github.com>
 <pCT5pXIcrDVQ-P1NAcLqcVnHeAuTeXgxPZtJHeQZ2AU=.ecfe3d4f-b23c-442e-9b4e-b16f3dd3d10e@github.com>
Message-ID: <k4xBt8WpJQiPIE2DZL726EMOP6YUHtuVdFNwaneA6eg=.df775d11-0fcd-4835-b48a-4307c9720c0d@github.com>

On Tue, 30 Aug 2022 15:06:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > That would be fine with me, but I think the BSD / Linux separation should be done under a different issue with the `clonefile` work remaining under this one.
> 
> That's okay, I think the main important point is that the refactoring is worthy on its own [...].

Probably then I'll file two new issues: one for the refactoring and a sub-task for `copy_file_range` and change the topic of the current sub-task to `clonefile`. The sub-tasks will both be blocked by the refactoring.

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

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

From fweimer at openjdk.org  Tue Aug 30 15:26:16 2022
From: fweimer at openjdk.org (Florian Weimer)
Date: Tue, 30 Aug 2022 15:26:16 GMT
Subject: Integrated: 8293004: (fs) FileChannel.transferXXX use of
 copy_file_range needs fallback handling for ENOSYS
In-Reply-To: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
References: <3D0-n0GTbCR_sZR8BQpHYXr55Yxga_WykMqz7s9A7IM=.ff33c263-48ca-497e-b2bb-37a784111943@github.com>
Message-ID: <nf6ObtO6jFrRBPf_QtE3Qofuu7UO21W5Jak7SVGmUns=.f66ca156-8254-4ad0-852c-33c4d7fe29f2@github.com>

On Sat, 27 Aug 2022 10:12:08 GMT, Florian Weimer <fweimer at openjdk.org> wrote:

> Now that the userspace emulation is not leveraged anymore, it would be possible to issue the system call directly for all glibc versions, but it's probably best not to start using `copy_file_range` where it hasn't been used before (the el7 kernel has a strange backport, if I recall correctly).

This pull request has now been integrated.

Changeset: 343333ab
Author:    Florian Weimer <fweimer at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/343333abcf2a3af1d6dbf48e406cb3efc73b9bf6
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8293004: (fs) FileChannel.transferXXX use of copy_file_range needs fallback handling for ENOSYS

Reviewed-by: stuefe, alanb, bpb

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

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

From bpb at openjdk.org  Tue Aug 30 16:38:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Aug 2022 16:38:15 GMT
Subject: RFR: 8292562: (fs) Use file cloning in Linux and macOS versions of
 Files::copy method [v9]
In-Reply-To: <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
References: <uIh4sMZaXfowNpVqGmEhMuuXxtKVr9isbSZ9pL5qp4Q=.edbbd4db-e227-46f1-b6d5-fd81bf245ae7@github.com>
 <Fs4qMSDrtX5_Q7Xy3LRMu-8EGi8juQ16CEL7NHTrbzY=.40844b89-e3c4-491c-9b5b-4b0f28f6fbfd@github.com>
Message-ID: <gmtuMHv-NFtSMmRBYODhdnTwgTY75ugz9PcIoBEUGfg=.11b33836-f1eb-44d7-a318-91e97464123c@github.com>

On Tue, 30 Aug 2022 00:23:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add file cloning to `java.nio.channels.FileChannel::transferTo` and `java.nio.file.Files.copy(Path,Path)`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - 8264744: Refactor UnixCopyFile::copyFile into UnixFileSystem; refactor OS-specific code to {Bsd,Linux}FileSystem
>  - Merge
>  - 8264744: Add mode to clone() and other requested changes
>  - 8264744: Refactor {Bsd,Linux}CopyFile::clone into {Bsd,Linux}FileSystem::clone
>  - Merge
>  - 8264744: Remove CloneFile classes; refactor to use {Bsd,Linux}CopyFile
>  - Merge
>  - 8264744: Fix typo desintation -> destination
>  - 8264744: Refactor into UnixCopyFile hierarchy
>  - Merge
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c74b6d45...ecce2093

src/java.base/linux/native/libnio/fs/LinuxFileSystem.c line 96:

> 94:                     case EINVAL:
> 95:                     case EXDEV:
> 96:                         // ignore and try sendfile()

`ENOSYS` will need to be handled as done [here](https://github.com/openjdk/jdk/pull/10055/files#diff-4fdc393c9569db35d35d0b5698849aa939ba395ec5a685befadbb2bacbaddb3e).

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

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

From bpb at openjdk.org  Wed Aug 31 02:38:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Aug 2022 02:38:03 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic Unix, 
 Linux, and BSD implementations
Message-ID: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>

Refactor `UnixFileSystem` and related classes to move implementations specific to Linux and BSD (macOS) into OS-specific classes and native code. Generic Unix implementations remain in existing `Unix*` files.

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

Commit messages:
 - 8293121: (fs) Refactor UnixFileSystem copying into generic Unix, Linux, and BSD implementations

Changes: https://git.openjdk.org/jdk/pull/10093/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=10093&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293121
  Stats: 789 lines in 14 files changed: 551 ins; 148 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/10093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10093/head:pull/10093

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

From alanb at openjdk.org  Wed Aug 31 13:38:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Aug 2022 13:38:10 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic
 Unix, Linux, and BSD implementations
In-Reply-To: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
References: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
Message-ID: <55ANX_MDjgbwazSl5q6b1YE4WNGHp0L77QGVyuf2twY=.b285ccf7-d71b-482d-9cb8-0efa46bf16dc@github.com>

On Wed, 31 Aug 2022 02:28:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Refactor `UnixFileSystem` and related classes to move implementations specific to Linux and BSD (macOS) into OS-specific classes and native code. Generic Unix implementations remain in existing `Unix*` files.

The refactoring means there is a 1-1 relationship between UnixFileSystem and a state-less UnixFileCopy.  If you just move the methods to UnixFileSystem then it will give you the framework to add Linux overrides to LinuxFileSystem and macOS/BSD overrides to  BsdFileSystem. That would avoid needing to create a parallel hierarchy of classes just to support copy/move.

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

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

From bpb at openjdk.org  Wed Aug 31 14:57:08 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Aug 2022 14:57:08 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic
 Unix, Linux, and BSD implementations
In-Reply-To: <55ANX_MDjgbwazSl5q6b1YE4WNGHp0L77QGVyuf2twY=.b285ccf7-d71b-482d-9cb8-0efa46bf16dc@github.com>
References: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
 <55ANX_MDjgbwazSl5q6b1YE4WNGHp0L77QGVyuf2twY=.b285ccf7-d71b-482d-9cb8-0efa46bf16dc@github.com>
Message-ID: <Lz87Fk_yc0trWnUAnFt5Ija5h78cHFKSEMY6KVBW_kQ=.a502448d-cf62-4e38-90c3-eccd428503bb@github.com>

On Wed, 31 Aug 2022 13:34:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If you just move the methods to UnixFileSystem then it will give you the framework to add Linux overrides to LinuxFileSystem and macOS/BSD overrides to BsdFileSystem.

I was hesitant to add so much code to `UnixFileSystem` but it does seem logical.

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

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

From bpb at openjdk.org  Wed Aug 31 15:41:25 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Aug 2022 15:41:25 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic
 Unix, Linux, and BSD implementations [v2]
In-Reply-To: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
References: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
Message-ID: <6M0LT8l3BxI6nN_EWrwb3yL95HQ3FTDz2lXbusKwpaE=.ce2c1a83-d0d0-4f0e-9793-71ef4159698e@github.com>

> Refactor `UnixFileSystem` and related classes to move implementations specific to Linux and BSD (macOS) into OS-specific classes and native code. Generic Unix implementations remain in existing `Unix*` files.

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

  8293121: Absorb UnixCopyFile into UnixFileSystem; remove UnixCopyFile hierarchy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10093/files
  - new: https://git.openjdk.org/jdk/pull/10093/files/dd1f7bcb..84a84ba0

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

  Stats: 1687 lines in 8 files changed: 770 ins; 909 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/10093.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/10093/head:pull/10093

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

From bpb at openjdk.org  Wed Aug 31 16:21:25 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Aug 2022 16:21:25 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic
 Unix, Linux, and BSD implementations [v3]
In-Reply-To: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
References: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
Message-ID: <BSjrFwNrBaC84hAFwEz2vj4u-qTgHWIjfPJE1lnAoEQ=.4c54cf2c-05a1-47ad-93c2-549e60725bc8@github.com>

> Refactor `UnixFileSystem` and related classes to move implementations specific to Linux and BSD (macOS) into OS-specific classes and native code. Generic Unix implementations remain in existing `Unix*` files.

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

  8293121: Forgot to move UnixCopyFile.c to UnixFileSystem.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/10093/files
  - new: https://git.openjdk.org/jdk/pull/10093/files/84a84ba0..be36c5a6

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

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

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

From alanb at openjdk.org  Wed Aug 31 17:03:09 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Aug 2022 17:03:09 GMT
Subject: RFR: 8293121: (fs) Refactor UnixFileSystem copying into generic
 Unix, Linux, and BSD implementations [v3]
In-Reply-To: <BSjrFwNrBaC84hAFwEz2vj4u-qTgHWIjfPJE1lnAoEQ=.4c54cf2c-05a1-47ad-93c2-549e60725bc8@github.com>
References: <4sMmGghqBMpTXTI5cK9rCKG1Rdt8IDdumWN0_x4QeYU=.27c2230d-8775-4a5a-b04e-c1fcad494841@github.com>
 <BSjrFwNrBaC84hAFwEz2vj4u-qTgHWIjfPJE1lnAoEQ=.4c54cf2c-05a1-47ad-93c2-549e60725bc8@github.com>
Message-ID: <nUf1zIvDAFzl23G4Heo5ydRWNyGHfcxWL6Uu2ptiurg=.0dd1777b-ca1f-4748-a01d-f4225765623b@github.com>

On Wed, 31 Aug 2022 16:21:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Refactor `UnixFileSystem` and related classes to move implementations specific to Linux and BSD (macOS) into OS-specific classes and native code. Generic Unix implementations remain in existing `Unix*` files.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8293121: Forgot to move UnixCopyFile.c to UnixFileSystem.c

I skimmed through the changes in be36c5a6 and this is a good refactor. I don't have time to do a detailed walk through right now but I'll get to that soon.

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

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