From bpb at openjdk.java.net  Wed Jun  1 00:35:27 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 00:35:27 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
Message-ID: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>

Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

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

Commit messages:
 - 8287097: (fs) Files::copy requires an undocumented permission when copying from the default file system to a non-default file system

Changes: https://git.openjdk.java.net/jdk/pull/8963/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8963&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287097
  Stats: 76 lines in 3 files changed: 69 ins; 0 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8963.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8963/head:pull/8963

PR: https://git.openjdk.java.net/jdk/pull/8963

From jpai at openjdk.java.net  Wed Jun  1 00:46:37 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Jun 2022 00:46:37 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v4]
In-Reply-To: <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
Message-ID: <ZwW6fvFoor7ReYrAvUMkanXeACi3gtbCfl0O61AOPGk=.0fae8da2-9a66-44f6-8f52-50baeee6b97c@github.com>

On Tue, 31 May 2022 18:29:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287237: Simplify code a bit

Thank you for the changes, Brian. The current PR looks fine to me.

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

Marked as reviewed by jpai (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Wed Jun  1 04:00:32 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Jun 2022 04:00:32 GMT
Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in
 MimeTypesFileTypeDetector.putIfAbsent
In-Reply-To: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
References: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
Message-ID: <vkDARptcCwJRRuJ7AJyVOCQKdA_ZWAeJ1Lx71f5Njdg=.59c318ed-08e6-4302-875b-4aa1c2d9bbef@github.com>

On Sun, 29 May 2022 20:41:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Only non-null values are put into `Map<String,String> mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster.
> 
> https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8941

From alanb at openjdk.java.net  Wed Jun  1 05:01:31 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Jun 2022 05:01:31 GMT
Subject: RFR: 8287602: (fs) Avoid redundant HashMap.containsKey call in
 MimeTypesFileTypeDetector.putIfAbsent
In-Reply-To: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
References: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
Message-ID: <BcLM1HgGRzTTF34-mmRCE_-Fe2L_JqRcFSHRq_S0fzA=.2ab03697-c986-4cda-b00a-f208a352d86e@github.com>

On Sun, 29 May 2022 20:41:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Only non-null values are put into `Map<String,String> mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster.
> 
> https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/8941

From alanb at openjdk.java.net  Wed Jun  1 06:44:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 1 Jun 2022 06:44:43 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <oEdwdi6TqMweXAjWnbdax3Sfk2jJiIY7vigTC3Lq1lU=.0ce71ceb-7fb2-44ff-bf47-66c8a42c08e1@github.com>

On Wed, 1 Jun 2022 00:27:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 119:

> 117:                                                    PosixFileAttributes.class,
> 118:                                                    linkOptions);
> 119:             } catch (SecurityException ignored) {

Ignoring SecurityException looks right here but you need to do the same with targetPosixView.setPermissions(...) for the case that you are copying from a custom file system that supports permissions to the default file system.

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From vtewari at openjdk.java.net  Wed Jun  1 07:31:33 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Wed, 1 Jun 2022 07:31:33 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v4]
In-Reply-To: <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
Message-ID: <_8pFvZSyw9B_zQ8KsQEVh69AOy--KyLxB6JvuF1kFjo=.be365ad7-7e23-4b4f-98fc-d49ad3ca1cce@github.com>

On Tue, 31 May 2022 18:29:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287237: Simplify code a bit

Looks ok, i tested on centos 7 and it is working as expected.

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

Marked as reviewed by vtewari (Committer).

PR: https://git.openjdk.java.net/jdk/pull/8909

From duke at openjdk.java.net  Wed Jun  1 07:50:58 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 07:50:58 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

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

  8282662: Revert wrong copyright year change

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/7729/files
  - new: https://git.openjdk.java.net/jdk/pull/7729/files/b20c2703..7bb28667

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=08
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=7729&range=07-08

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From jpai at openjdk.java.net  Wed Jun  1 10:40:34 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Jun 2022 10:40:34 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <vJRIkmzPQzGuVbEGtvR28KTnFxrcJN8L0Ih8tbTSo2Y=.97d6a601-6aff-45c8-a61c-f5c48a94694f@github.com>

On Wed, 1 Jun 2022 00:27:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

test/jdk/java/nio/file/Files/copy.policy line 1:

> 1: grant {

Hello Brian, the copyright header is missing on this new file.

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From rriggs at openjdk.java.net  Wed Jun  1 13:32:47 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 1 Jun 2022 13:32:47 GMT
Subject: RFR: 8282662: Use List.of() factory method to reduce memory
 consumption [v9]
In-Reply-To: <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
 <pitf6I-ioejxwT2sXuSo6igIFjL-oZS-iPrBvzSif8g=.39b8154f-42d2-4b8c-ad47-35372026a9de@github.com>
Message-ID: <LhfwNIF-X5d-rCxD6zfVXINWKrcDS3JMYc9l2yEJKFQ=.72e66580-4a2c-4c7f-abdb-34898a9f333f@github.com>

On Wed, 1 Jun 2022 07:50:58 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

>> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
>> 
>> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
>> - `MethodHandles.longestParameterList()` never returns null
>> - parameter types are never null
>> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
>> - exceptions types of method signature are never null
>
> ?????? ??????? has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8282662: Revert wrong copyright year change

Marked as reviewed by rriggs (Reviewer).

Thanks for the improvements.

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From duke at openjdk.java.net  Wed Jun  1 13:35:13 2022
From: duke at openjdk.java.net (=?UTF-8?B?0KHQtdGA0LPQtdC5?= =?UTF-8?B?IA==?= =?UTF-8?B?0KbRi9C/0LDQvdC+0LI=?=)
Date: Wed, 1 Jun 2022 13:35:13 GMT
Subject: Integrated: 8282662: Use List.of() factory method to reduce memory
 consumption
In-Reply-To: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
References: <Rh4ZPUZE7VpJikhMUbjlwv--Fc_HvspNleq6_z_F_TA=.4b2171cf-f63e-4009-abd0-61d8f7fecf82@github.com>
Message-ID: <aaJhGv-fyhi3UXKlfnYJbIhFULcZvse_BWu00DkPwHg=.fc7bc5de-4323-47ab-93ec-d955a967525d@github.com>

On Mon, 7 Mar 2022 15:11:50 GMT, ?????? ??????? <duke at openjdk.java.net> wrote:

> `List.of()` along with `Set.of()` create unmodifiable `List/Set` but with smaller footprint comparing to `Arrays.asList()` / `new HashSet()` when called with vararg of size 0, 1, 2.
> 
> In general replacement of `Arrays.asList()` with `List.of()` is dubious as the latter is null-hostile, however in some cases we are sure that arguments are non-null. Into this PR I've included the following cases (in addition to those where the argument is proved to be non-null at compile-time):
> - `MethodHandles.longestParameterList()` never returns null
> - parameter types are never null
> - interfaces used for proxy construction and returned from `Class.getInterfaces()` are never null
> - exceptions types of method signature are never null

This pull request has now been integrated.

Changeset: 168b226b
Author:    Sergey Tsypanov <sergei.tsypanov at yandex.ru>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/168b226b0f7a3b067bf11616e5a92908f63be450
Stats:     12 lines in 4 files changed: 1 ins; 2 del; 9 mod

8282662: Use List.of() factory method to reduce memory consumption

Reviewed-by: redestad, rriggs

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

PR: https://git.openjdk.java.net/jdk/pull/7729

From chegar at openjdk.java.net  Wed Jun  1 15:13:31 2022
From: chegar at openjdk.java.net (Chris Hegarty)
Date: Wed, 1 Jun 2022 15:13:31 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <Kv3GpWtoIo6dnfYE0N6CEb80Whux3OqHCjeS8v98tOA=.0b984774-1679-4dcc-87d2-628ac7ade6e4@github.com>

On Wed, 1 Jun 2022 00:27:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

LGTM.

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

Marked as reviewed by chegar (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Wed Jun  1 15:18:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 15:18:35 GMT
Subject: Integrated: 8287237: (fs) Files.probeContentType returns null if
 filename contains hash mark on Linux
In-Reply-To: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
Message-ID: <3vkPn1oDg0RJxzfadYWvsTWulsDkX7OzY0mdHyZflNQ=.2c4e43c0-252e-4abc-9868-abe6635330a0@github.com>

On Thu, 26 May 2022 23:03:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `sun.net.www.MimeTable.findByFileName(String)` to attempt to find the file extension in the entire file name if it is not found in the portion of the name preceding the optional fragment beginning with a hash (`#`).

This pull request has now been integrated.

Changeset: 8071b231
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/8071b2311caaacd714d74f12aee6cb7c2fe700fa
Stats:     79 lines in 2 files changed: 53 ins; 15 del; 11 mod

8287237: (fs) Files.probeContentType returns null if filename contains hash mark on Linux

Reviewed-by: rriggs, jpai, vtewari

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From bpb at openjdk.java.net  Wed Jun  1 15:23:38 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 15:23:38 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
In-Reply-To: <vJRIkmzPQzGuVbEGtvR28KTnFxrcJN8L0Ih8tbTSo2Y=.97d6a601-6aff-45c8-a61c-f5c48a94694f@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
 <vJRIkmzPQzGuVbEGtvR28KTnFxrcJN8L0Ih8tbTSo2Y=.97d6a601-6aff-45c8-a61c-f5c48a94694f@github.com>
Message-ID: <wCOwbcRPBt5qhSDlDi_nyHqHBF4_0r6CjfOiSi9TGeI=.bbb2af03-6ca1-4022-a9b1-0e741b6871d6@github.com>

On Wed, 1 Jun 2022 10:36:42 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.
>
> test/jdk/java/nio/file/Files/copy.policy line 1:
> 
>> 1: grant {
> 
> Hello Brian, the copyright header is missing on this new file.

@jaikiran None of the extant policy files under `test/jdk/java/nio` contain a copyright header.

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Wed Jun  1 15:32:41 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 15:32:41 GMT
Subject: RFR: 8287237: (fs) Files.probeContentType returns null if filename
 contains hash mark on Linux [v4]
In-Reply-To: <_8pFvZSyw9B_zQ8KsQEVh69AOy--KyLxB6JvuF1kFjo=.be365ad7-7e23-4b4f-98fc-d49ad3ca1cce@github.com>
References: <cgfAl82ReuokbYLifEZyEvBGKoL10QBZ2k4g-04rfpk=.51eaecd5-c83f-4613-aa10-96571fd2b3a3@github.com>
 <CXl8IxhY6vb7lkJti2L3q_SbwETC2XoDBTpCVuQi6jE=.46027e4d-a878-4e0e-8aff-6f4e891fc6dc@github.com>
 <_8pFvZSyw9B_zQ8KsQEVh69AOy--KyLxB6JvuF1kFjo=.be365ad7-7e23-4b4f-98fc-d49ad3ca1cce@github.com>
Message-ID: <Rxj_qDLG60FKWQYVCoc8aSuIHPhX1HGGK4NMVhiasYs=.6ddc5ee9-9702-4985-8688-95a387994814@github.com>

On Wed, 1 Jun 2022 07:28:11 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Looks ok, i tested on centos 7 and it is working as expected.

To really verify it you would have to suppress `~/.mime.types` and `/etc/mime.types` before running the test.

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

PR: https://git.openjdk.java.net/jdk/pull/8909

From jpai at openjdk.java.net  Wed Jun  1 15:33:36 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Wed, 1 Jun 2022 15:33:36 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system
In-Reply-To: <wCOwbcRPBt5qhSDlDi_nyHqHBF4_0r6CjfOiSi9TGeI=.bbb2af03-6ca1-4022-a9b1-0e741b6871d6@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
 <vJRIkmzPQzGuVbEGtvR28KTnFxrcJN8L0Ih8tbTSo2Y=.97d6a601-6aff-45c8-a61c-f5c48a94694f@github.com>
 <wCOwbcRPBt5qhSDlDi_nyHqHBF4_0r6CjfOiSi9TGeI=.bbb2af03-6ca1-4022-a9b1-0e741b6871d6@github.com>
Message-ID: <45oSYqWCR_LBqJmtFIWCcZE9EwaFpOkuP3XbaExmAVs=.625c8160-f371-40ed-8d97-de4636236fa1@github.com>

On Wed, 1 Jun 2022 15:20:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/file/Files/copy.policy line 1:
>> 
>>> 1: grant {
>> 
>> Hello Brian, the copyright header is missing on this new file.
>
> @jaikiran None of the extant policy files under `test/jdk/java/nio` contain a copyright header.

You are right, I hadn't noticed that. The ones I had referred to were all in `test/jdk/java/net/httpclient/security/` and they have the copyright headers.

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Wed Jun  1 16:13:40 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 16:13:40 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system [v2]
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <jrvTwG23xVaqHeXUoQ-3hBZWSSYIHKdurIFsu3KvdeU=.e4d09a92-169a-4266-8651-848b143ed1d5@github.com>

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

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

  8287097: Ignore SecurityException when attemping to write POSIX permissions

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8963/files
  - new: https://git.openjdk.java.net/jdk/pull/8963/files/384d8e30..80961915

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8963&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8963&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Wed Jun  1 16:13:42 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 16:13:42 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system [v2]
In-Reply-To: <oEdwdi6TqMweXAjWnbdax3Sfk2jJiIY7vigTC3Lq1lU=.0ce71ceb-7fb2-44ff-bf47-66c8a42c08e1@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
 <oEdwdi6TqMweXAjWnbdax3Sfk2jJiIY7vigTC3Lq1lU=.0ce71ceb-7fb2-44ff-bf47-66c8a42c08e1@github.com>
Message-ID: <sYPow7qZ30HwPgen-jnDQpxVxQojLjFcRfL0yENMOX4=.238ca4bf-da33-4328-bbde-afefc7f11bff@github.com>

On Wed, 1 Jun 2022 06:40:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8287097: Ignore SecurityException when attemping to write POSIX permissions
>
> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 119:
> 
>> 117:                                                    PosixFileAttributes.class,
>> 118:                                                    linkOptions);
>> 119:             } catch (SecurityException ignored) {
> 
> Ignoring SecurityException looks right here but you need to do the same with targetPosixView.setPermissions(...) for the case that you are copying from a custom file system that supports permissions to the default file system.

Fixed by 80961915b339fb3bf39acf120e25c363aff16afc.

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From smarks at openjdk.java.net  Wed Jun  1 17:44:24 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 1 Jun 2022 17:44:24 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <IhiEBcMA2Zj0IWKO4jNpbCdAYbNvKP-GlA2bcbU7Yo0=.670eea02-4f1a-48db-996b-1cec9c1438e0@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewers for i18n, net, nio, and security, please review call site changes in your areas. Thanks.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From aturbanov at openjdk.java.net  Wed Jun  1 18:19:33 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Wed, 1 Jun 2022 18:19:33 GMT
Subject: Integrated: 8287602: (fs) Avoid redundant HashMap.containsKey call in
 MimeTypesFileTypeDetector.putIfAbsent
In-Reply-To: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
References: <VWpMdLBRlg5LRxPRdiOA3eXxdSp65S9OgB8UoUYbFsE=.5ed1d8d4-4d74-421a-a331-236ddc4c74a1@github.com>
Message-ID: <1Dhmm_d-JIQ4ifgmwjx3l9oA21p4U7oVp08uqIW3akU=.e1843ce9-d888-41e9-be33-69b103b77ca1@github.com>

On Sun, 29 May 2022 20:41:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Only non-null values are put into `Map<String,String> mimeTypeMap`. It means, we can replace `containsKey`+`put` calls with single `putIfAbsent` call. It makes code a bit cleaner and faster.
> 
> https://github.com/openjdk/jdk/blob/3d2d039538b906cedd9188ed94b7ba55c275ff7f/src/java.base/unix/classes/sun/nio/fs/MimeTypesFileTypeDetector.java#L189-L196

This pull request has now been integrated.

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

8287602: (fs) Avoid redundant HashMap.containsKey call in MimeTypesFileTypeDetector.putIfAbsent

Reviewed-by: bpb, jpai, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8941

From naoto at openjdk.java.net  Wed Jun  1 18:31:34 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 1 Jun 2022 18:31:34 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Reviewed i18n-related changes and they look good. One minor suggestion in `Calendar`, but that can be applied later.

src/java.base/share/classes/java/util/Calendar.java line 2648:

> 2646:             set.add("gregory");
> 2647:             set.add("buddhist");
> 2648:             set.add("japanese");

This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

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

Marked as reviewed by naoto (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Wed Jun  1 18:39:08 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 18:39:08 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel registration
Message-ID: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>

Ignore `CancelledKeyException` during registration.

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

Commit messages:
 - 8287580: (se) CancelledKeyException during channel registration

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Wed Jun  1 18:42:36 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 1 Jun 2022 18:42:36 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <dh6Twe_QhgR3NgCROm40Rj2oJfp5V0EseBOq_y5IFUE=.4179a789-9937-4779-83fc-6ba845c17667@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

`java.io` and `java.nio` look all right.

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

Marked as reviewed by bpb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Thu Jun  2 03:00:00 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 03:00:00 GMT
Subject: RFR: 8287168: (fs) WatchService leaves thread running if not closed
Message-ID: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>

Add a `Cleaner` to each `WatchService` implementation.

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

Commit messages:
 - 8287168: (fs) WatchService leaves thread running if not closed

Changes: https://git.openjdk.java.net/jdk/pull/8986/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8986&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287168
  Stats: 124 lines in 3 files changed: 102 ins; 18 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8986.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8986/head:pull/8986

PR: https://git.openjdk.java.net/jdk/pull/8986

From alanb at openjdk.java.net  Thu Jun  2 04:42:27 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 04:42:27 GMT
Subject: RFR: 8287168: (fs) WatchService leaves thread running if not
 closed
In-Reply-To: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
References: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
Message-ID: <0lQrZeMc8eY-uFIsnD4x6J-fabwpdvYmujOylwTfIas=.555c9138-0295-47fd-ad55-1ddc240e8907@github.com>

On Thu, 2 Jun 2022 02:52:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a `Cleaner` to each `WatchService` implementation.

I thin for this bug report that we first need to decide if it should be closed or closed as WNF. If we do change it then it will require significant review. So please don't rush this one into JDK 19.

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

PR: https://git.openjdk.java.net/jdk/pull/8986

From alanb at openjdk.java.net  Thu Jun  2 04:55:26 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 04:55:26 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>

On Wed, 1 Jun 2022 18:32:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore `CancelledKeyException` during registration.

src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 230:

> 228:             throw e;
> 229:         } catch (CancelledKeyException ignored) {
> 230:             keys.remove(k);

I don't think keys.remove(k) should be here. If the key has been cancelled then it will be removed from the key set when the dereg queue is processed. Did you run into a test failure that lead to adding this?

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Thu Jun  2 04:59:32 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 04:59:32 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <mkrhGDEXLyY4V0ISBHUCRjYCqY_68w6D8DsLQGzKRBQ=.6cd513fe-2b95-4447-99d8-6b90672f7c8a@github.com>

On Wed, 1 Jun 2022 18:32:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore `CancelledKeyException` during registration.

test/jdk/java/nio/channels/Selector/KeyCancelled.java line 67:

> 65:                     c.register(s, SelectionKey.OP_READ);
> 66:                     // c.isRegistered() is false here after the exceptional case
> 67:                 }

This tries to create 10k SocketChannels. I would be concerned with the robustness of this test. I suspect it should be possible to create the conditions for the bug with just one socket channel where the registration key is flushed from the Selector in the loop, the next registration will create a new key that can be cancelled asynchronously by the other thread.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Thu Jun  2 05:02:42 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 05:02:42 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system [v2]
In-Reply-To: <sYPow7qZ30HwPgen-jnDQpxVxQojLjFcRfL0yENMOX4=.238ca4bf-da33-4328-bbde-afefc7f11bff@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
 <oEdwdi6TqMweXAjWnbdax3Sfk2jJiIY7vigTC3Lq1lU=.0ce71ceb-7fb2-44ff-bf47-66c8a42c08e1@github.com>
 <sYPow7qZ30HwPgen-jnDQpxVxQojLjFcRfL0yENMOX4=.238ca4bf-da33-4328-bbde-afefc7f11bff@github.com>
Message-ID: <whHllc0CPphOGZHjmdF8_L6dhOaV5zX-MJ4Z0ZcSgvg=.44465178-b558-4a4a-b128-4e81fb8a83a8@github.com>

On Wed, 1 Jun 2022 16:10:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/CopyMoveHelper.java line 119:
>> 
>>> 117:                                                    PosixFileAttributes.class,
>>> 118:                                                    linkOptions);
>>> 119:             } catch (SecurityException ignored) {
>> 
>> Ignoring SecurityException looks right here but you need to do the same with targetPosixView.setPermissions(...) for the case that you are copying from a custom file system that supports permissions to the default file system.
>
> Fixed by 80961915b339fb3bf39acf120e25c363aff16afc.

Would it be possible to add the comment

// okay to continue if RuntimePermission("accessUserInformation") not granted

in the catch block of both places so that it's clear to readers why it is okay to ignore the SE?

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From vtewari at openjdk.java.net  Thu Jun  2 09:51:35 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Thu, 2 Jun 2022 09:51:35 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <YUfHQsvfO6e2FYfg0RnJFdXdjdPeCzlB-e1mkqghWlw=.6d65ddeb-45db-4494-9945-ec957cda0c26@github.com>

On Wed, 1 Jun 2022 18:32:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore `CancelledKeyException` during registration.

src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 229:

> 227:             k.cancel();
> 228:             throw e;
> 229:         } catch (CancelledKeyException ignored) {

Hi Brian, what about adding the selection key to ?keys?  after we set the interesOps ? I do not see any side effect of doing this.

         // it may be observed by a thread iterating over the selector's key set.
-        keys.add(k);
         try {
             k.interestOps(ops);
+            keys.add(k);
         } catch (ClosedSelectorException e) {

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Thu Jun  2 10:01:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 10:01:38 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <YUfHQsvfO6e2FYfg0RnJFdXdjdPeCzlB-e1mkqghWlw=.6d65ddeb-45db-4494-9945-ec957cda0c26@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <YUfHQsvfO6e2FYfg0RnJFdXdjdPeCzlB-e1mkqghWlw=.6d65ddeb-45db-4494-9945-ec957cda0c26@github.com>
Message-ID: <fR2jlcglSaD3x4HEbXPBbOBpcNy64Z2t_-hxBeRSrdc=.e9c6645b-ce9a-456b-bb60-d15a9efddb4b@github.com>

On Thu, 2 Jun 2022 09:47:40 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> Hi Brian, what about adding the selection key to ?keys? after we set the interesOps ? I do not see any side effect of doing this.

That would mean a selection key could be selected before it added to the selector's key. So I don't think it is feasible, at least not without working through the spec implications.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From dfuchs at openjdk.java.net  Thu Jun  2 10:33:19 2022
From: dfuchs at openjdk.java.net (Daniel Fuchs)
Date: Thu, 2 Jun 2022 10:33:19 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
Message-ID: <pBk0szIsy279wF9Amofquc9RB4SyYy1LkvBmdUdwFNU=.9c320114-bff4-4d0c-91ff-c56827cbf4d1@github.com>

On Fri, 27 May 2022 18:40:32 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do it as naotoj said

Changes to `net` and `http` look good.

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

Marked as reviewed by dfuchs (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From vtewari at openjdk.java.net  Thu Jun  2 12:37:42 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Thu, 2 Jun 2022 12:37:42 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <fR2jlcglSaD3x4HEbXPBbOBpcNy64Z2t_-hxBeRSrdc=.e9c6645b-ce9a-456b-bb60-d15a9efddb4b@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <YUfHQsvfO6e2FYfg0RnJFdXdjdPeCzlB-e1mkqghWlw=.6d65ddeb-45db-4494-9945-ec957cda0c26@github.com>
 <fR2jlcglSaD3x4HEbXPBbOBpcNy64Z2t_-hxBeRSrdc=.e9c6645b-ce9a-456b-bb60-d15a9efddb4b@github.com>
Message-ID: <lYdsadU-Rxh9flBLgn6WYuMLPfkN7nwNboD7WmKFoDs=.b9a15972-2738-4fe9-a26e-c43bdb395caa@github.com>

On Thu, 2 Jun 2022 09:57:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 229:
>> 
>>> 227:             k.cancel();
>>> 228:             throw e;
>>> 229:         } catch (CancelledKeyException ignored) {
>> 
>> Hi Brian, what about adding the selection key to ?keys?  after we set the interesOps ? I do not see any side effect of doing this.
>> 
>>          // it may be observed by a thread iterating over the selector's key set.
>> -        keys.add(k);
>>          try {
>>              k.interestOps(ops);
>> +            keys.add(k);
>>          } catch (ClosedSelectorException e) {
>
>> Hi Brian, what about adding the selection key to ?keys? after we set the interesOps ? I do not see any side effect of doing this.
> 
> That would mean a selection key could be selected before it added to the selector's key set. So I don't think it is feasible, at least not without working through the spec implications.

agreed,as soon as we set the  interestOps on key, native  system call can select the particular fd which is not yet added to the selector key set.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From djelinski at openjdk.java.net  Thu Jun  2 14:10:33 2022
From: djelinski at openjdk.java.net (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 2 Jun 2022 14:10:33 GMT
Subject: RFR: 8287168: (fs) WatchService leaves thread running if not
 closed
In-Reply-To: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
References: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
Message-ID: <uwPloKlESIMd7YNkfPAe0LBtWAZsv5x7nmU40MXc23U=.907294e2-2fa8-48ba-8916-1e6bb1099e74@github.com>

On Thu, 2 Jun 2022 02:52:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a `Cleaner` to each `WatchService` implementation.

The cleaners will never be invoked.

`Poller` class is kept alive by a thread, and while the class is static, it holds a hard reference to the enclosing WatchService. See [Windows](https://github.com/openjdk/jdk/blob/8323d9a8e0fa99947bb2a34b6b76bfecb0861b67/src/java.base/windows/classes/sun/nio/fs/WindowsWatchService.java#L320) / [Linux](https://github.com/openjdk/jdk/blob/8323d9a8e0fa99947bb2a34b6b76bfecb0861b67/src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java#L207)

A test checking if `WeakReference`s to `WatchService`s are cleared during GC would probably catch that.

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

PR: https://git.openjdk.java.net/jdk/pull/8986

From bpb at openjdk.java.net  Thu Jun  2 14:54:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 14:54:35 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>
Message-ID: <3xGoiGQ7Yyt2aPOP9FoOwl5UzWSHRex6O3wwFGQOiOA=.1d012232-0590-45f6-8fce-255b6ad850b2@github.com>

On Thu, 2 Jun 2022 04:51:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> src/java.base/share/classes/sun/nio/ch/SelectorImpl.java line 230:
> 
>> 228:             throw e;
>> 229:         } catch (CancelledKeyException ignored) {
>> 230:             keys.remove(k);
> 
> I don't think keys.remove(k) should be here. If the key has been cancelled then it will be removed from the key set when the dereg queue is processed. Did you run into a test failure that lead to adding this?

No failure, it was for symmetry with the other catch block; will remove.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 14:56:31 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 14:56:31 GMT
Subject: RFR: 8287168: (fs) WatchService leaves thread running if not
 closed
In-Reply-To: <0lQrZeMc8eY-uFIsnD4x6J-fabwpdvYmujOylwTfIas=.555c9138-0295-47fd-ad55-1ddc240e8907@github.com>
References: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
 <0lQrZeMc8eY-uFIsnD4x6J-fabwpdvYmujOylwTfIas=.555c9138-0295-47fd-ad55-1ddc240e8907@github.com>
Message-ID: <a_9vWaOeTgF0M6Xd5q-DtW2lVaE8ojdVWh-4dCtkhF0=.1b1a805e-3be7-46b9-9aec-3fdc78178771@github.com>

On Thu, 2 Jun 2022 04:38:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think for this bug report that we first need to decide if it should be changed or closed as WNF. If we do change it then it will require significant review. So let's not rush this one into JDK 19.

Sure, no rush.

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

PR: https://git.openjdk.java.net/jdk/pull/8986

From bpb at openjdk.java.net  Thu Jun  2 14:56:34 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 14:56:34 GMT
Subject: RFR: 8287168: (fs) WatchService leaves thread running if not
 closed
In-Reply-To: <uwPloKlESIMd7YNkfPAe0LBtWAZsv5x7nmU40MXc23U=.907294e2-2fa8-48ba-8916-1e6bb1099e74@github.com>
References: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
 <uwPloKlESIMd7YNkfPAe0LBtWAZsv5x7nmU40MXc23U=.907294e2-2fa8-48ba-8916-1e6bb1099e74@github.com>
Message-ID: <iQgvuGqs344l8OWzVvZVZDbXeR2fbiOw4AWbDg-0BiI=.ce837733-55b3-4b6c-9ff4-8b7112a4aba3@github.com>

On Thu, 2 Jun 2022 14:08:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> The cleaners will never be invoked.
> 
> `Poller` class is kept alive by a thread, and while the class is static, it holds a hard reference to the enclosing WatchService. See [Windows](https://github.com/openjdk/jdk/blob/8323d9a8e0fa99947bb2a34b6b76bfecb0861b67/src/java.base/windows/classes/sun/nio/fs/WindowsWatchService.java#L320) / [Linux](https://github.com/openjdk/jdk/blob/8323d9a8e0fa99947bb2a34b6b76bfecb0861b67/src/java.base/linux/classes/sun/nio/fs/LinuxWatchService.java#L207)
> 
> A test checking if `WeakReference`s to `WatchService`s are cleared during GC would probably catch that.

Indeed I did not see them invoked unless an explicit `System.gc()` call was made.

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

PR: https://git.openjdk.java.net/jdk/pull/8986

From alanb at openjdk.java.net  Thu Jun  2 15:15:34 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 15:15:34 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <3xGoiGQ7Yyt2aPOP9FoOwl5UzWSHRex6O3wwFGQOiOA=.1d012232-0590-45f6-8fce-255b6ad850b2@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>
 <3xGoiGQ7Yyt2aPOP9FoOwl5UzWSHRex6O3wwFGQOiOA=.1d012232-0590-45f6-8fce-255b6ad850b2@github.com>
Message-ID: <u7VAN_LpA5SFTo7kv37_RLKTNiUz6HiBdMEubKdzfmw=.cb5135d5-55f9-47d3-8f10-26ae522b2623@github.com>

On Thu, 2 Jun 2022 14:50:48 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> No failure, it was for symmetry with the other catch block; will remove.

Thanks. The other catch is the closed Selector case. The caller has to remove the key from the key set as otherwise it might get left there. We don't have that issue with the cancelled key case.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 15:15:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 15:15:35 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <u7VAN_LpA5SFTo7kv37_RLKTNiUz6HiBdMEubKdzfmw=.cb5135d5-55f9-47d3-8f10-26ae522b2623@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>
 <3xGoiGQ7Yyt2aPOP9FoOwl5UzWSHRex6O3wwFGQOiOA=.1d012232-0590-45f6-8fce-255b6ad850b2@github.com>
 <u7VAN_LpA5SFTo7kv37_RLKTNiUz6HiBdMEubKdzfmw=.cb5135d5-55f9-47d3-8f10-26ae522b2623@github.com>
Message-ID: <uTU1BsA8q6s3CaXUFSZ7MSR63Up-R_viQw0Xdzohel4=.0b2da815-289b-4305-8ab6-9e49b3b0a6c3@github.com>

On Thu, 2 Jun 2022 15:10:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks

I will remove the `remove()` in the next commit.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 15:16:43 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 15:16:43 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system [v3]
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <bmjnNzXWheZ0sCnwbDevBnfqT-sdCChsBrYpCyv0B9A=.3697f4f3-af35-4b73-bf1e-7e3ad43c78bc@github.com>

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

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

  8287097: Add comment to catch blocks which ignore SecurityException due to accessUserInformation being denied

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8963/files
  - new: https://git.openjdk.java.net/jdk/pull/8963/files/80961915..f19effb5

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8963&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8963&range=01-02

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From alanb at openjdk.java.net  Thu Jun  2 15:16:44 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 15:16:44 GMT
Subject: RFR: 8287097: (fs) Files::copy requires an undocumented permission
 when copying from the default file system to a non-default file system [v3]
In-Reply-To: <bmjnNzXWheZ0sCnwbDevBnfqT-sdCChsBrYpCyv0B9A=.3697f4f3-af35-4b73-bf1e-7e3ad43c78bc@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
 <bmjnNzXWheZ0sCnwbDevBnfqT-sdCChsBrYpCyv0B9A=.3697f4f3-af35-4b73-bf1e-7e3ad43c78bc@github.com>
Message-ID: <9jc0wSUeyzZ8V_xUPREc5_X-yrLPbF8XwgXFmiOix4E=.907116de-2ca2-455c-a30f-b95a868012b8@github.com>

On Thu, 2 Jun 2022 15:13:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287097: Add comment to catch blocks which ignore SecurityException due to accessUserInformation being denied

Implementation changes looks good.

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Thu Jun  2 17:40:34 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 17:40:34 GMT
Subject: Integrated: 8287097: (fs) Files::copy requires an undocumented
 permission when copying from the default file system to a non-default file
 system
In-Reply-To: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
References: <oGAu0WK0HKMq6YSiZL_rsrT4a7Xjblmv_6ryEPGmoQw=.d6afc438-6759-4711-ab93-042b50038c60@github.com>
Message-ID: <xwi1BgbZCAADFZSQA2yIanRXFjICe4yTMp_r57QcBdY=.9eb8e029-c533-41f2-9b47-4cf1283fc97b@github.com>

On Wed, 1 Jun 2022 00:27:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore the `SecurityException` thrown while trying to retrieve the POSIX attributes when a `SecurityManager` is set.

This pull request has now been integrated.

Changeset: 13596cdf
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/13596cdf695e67819aadcc08c6d9f05b1eb18442
Stats:     82 lines in 3 files changed: 74 ins; 0 del; 8 mod

8287097: (fs) Files::copy requires an undocumented permission when copying from the default file system to a non-default file system

Reviewed-by: chegar, alanb

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

PR: https://git.openjdk.java.net/jdk/pull/8963

From bpb at openjdk.java.net  Thu Jun  2 18:28:20 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 18:28:20 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v2]
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <Id_-JB7VPKlTQY-r2sjqpdh-_raopyFMcdvYmhYuEcw=.32f84760-91e5-421f-b0c5-5bd586706ca4@github.com>

> Ignore `CancelledKeyException` during registration.

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

  8287580: Add catch to AbstractSelectableChannel, remove remove() from SelectorImpl, open only one SocketChannel in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8978/files
  - new: https://git.openjdk.java.net/jdk/pull/8978/files/a379cdd2..92533644

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8978&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8978&range=00-01

  Stats: 7 lines in 3 files changed: 3 ins; 1 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8978.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8978/head:pull/8978

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 18:28:21 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 18:28:21 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v2]
In-Reply-To: <uTU1BsA8q6s3CaXUFSZ7MSR63Up-R_viQw0Xdzohel4=.0b2da815-289b-4305-8ab6-9e49b3b0a6c3@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <nRb6pZTs6hhoqPOmORESU_dXYPTSqOEYIY7o4MjEQbI=.ed4fce30-1663-4f8b-b1ef-f621e486c29d@github.com>
 <3xGoiGQ7Yyt2aPOP9FoOwl5UzWSHRex6O3wwFGQOiOA=.1d012232-0590-45f6-8fce-255b6ad850b2@github.com>
 <u7VAN_LpA5SFTo7kv37_RLKTNiUz6HiBdMEubKdzfmw=.cb5135d5-55f9-47d3-8f10-26ae522b2623@github.com>
 <uTU1BsA8q6s3CaXUFSZ7MSR63Up-R_viQw0Xdzohel4=.0b2da815-289b-4305-8ab6-9e49b3b0a6c3@github.com>
Message-ID: <JJZxusgfBaT4Tox4Vl3v32EQFDfSetDNYKKh20MoZmQ=.4e465fbd-a70e-422d-bd5d-4ceca69890b1@github.com>

On Thu, 2 Jun 2022 15:13:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> No failure, it was for symmetry with the other catch block; will remove.
>> 
>> Thanks. The other catch is the closed Selector case. The caller has to remove the key from the key set as otherwise it might get left there. We don't have that issue with the cancelled key case.
>
>> Thanks
> 
> I will remove the `remove()` in the next commit.

Removed in 925336449bfda90791b7e289d0008da4a9bc87a6.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 18:28:21 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 18:28:21 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v2]
In-Reply-To: <mkrhGDEXLyY4V0ISBHUCRjYCqY_68w6D8DsLQGzKRBQ=.6cd513fe-2b95-4447-99d8-6b90672f7c8a@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <mkrhGDEXLyY4V0ISBHUCRjYCqY_68w6D8DsLQGzKRBQ=.6cd513fe-2b95-4447-99d8-6b90672f7c8a@github.com>
Message-ID: <J3W6YaeDkOC_9aYtuwRzBrO9H-_hxhKeXur5cKLv2cs=.b7448528-42bb-49ed-9183-816e2834e3e8@github.com>

On Thu, 2 Jun 2022 04:55: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:
>> 
>>   8287580: Add catch to AbstractSelectableChannel, remove remove() from SelectorImpl, open only one SocketChannel in test
>
> test/jdk/java/nio/channels/Selector/KeyCancelled.java line 67:
> 
>> 65:                     c.register(s, SelectionKey.OP_READ);
>> 66:                     // c.isRegistered() is false here after the exceptional case
>> 67:                 }
> 
> This tries to create 10k SocketChannels. I would be concerned with the robustness of this test. I suspect it should be possible to create the conditions for the bug with just one socket channel where the registration key is flushed from the Selector in the loop, the next registration will create a new key that can be cancelled asynchronously by the other thread.

Commit 925336449bfda90791b7e289d0008da4a9bc87a6 changes the test to use a single `SocketChannel`.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Thu Jun  2 18:42:37 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 2 Jun 2022 18:42:37 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v2]
In-Reply-To: <Id_-JB7VPKlTQY-r2sjqpdh-_raopyFMcdvYmhYuEcw=.32f84760-91e5-421f-b0c5-5bd586706ca4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <Id_-JB7VPKlTQY-r2sjqpdh-_raopyFMcdvYmhYuEcw=.32f84760-91e5-421f-b0c5-5bd586706ca4@github.com>
Message-ID: <gTRDcA-NWVpnYKXAeRJLp4hJcHv87ffjVI0wyW6u18U=.dd9d0f56-2081-41c0-a7e5-2d7d7a2281fb@github.com>

On Thu, 2 Jun 2022 18:28:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Add catch to AbstractSelectableChannel, remove remove() from SelectorImpl, open only one SocketChannel in test

src/java.base/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java line 236:

> 234:                         k.interestOps(ops);
> 235:                     } catch (CancelledKeyException ignored) {
> 236:                     }

The register method is specified to throw CKE "If this channel is currently registered with the given selector but the corresponding key has already been cancelled". So we shouldn't be changing anything in this class.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 22:14:27 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 22:14:27 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>

> Ignore `CancelledKeyException` during registration.

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

  8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8978/files
  - new: https://git.openjdk.java.net/jdk/pull/8978/files/92533644..98bcd22e

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8978&range=02
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8978&range=01-02

  Stats: 7 lines in 2 files changed: 1 ins; 3 del; 3 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8978.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8978/head:pull/8978

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 22:14:30 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 22:14:30 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v2]
In-Reply-To: <gTRDcA-NWVpnYKXAeRJLp4hJcHv87ffjVI0wyW6u18U=.dd9d0f56-2081-41c0-a7e5-2d7d7a2281fb@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <Id_-JB7VPKlTQY-r2sjqpdh-_raopyFMcdvYmhYuEcw=.32f84760-91e5-421f-b0c5-5bd586706ca4@github.com>
 <gTRDcA-NWVpnYKXAeRJLp4hJcHv87ffjVI0wyW6u18U=.dd9d0f56-2081-41c0-a7e5-2d7d7a2281fb@github.com>
Message-ID: <-7hq3acheN6t6T_riXCTtQQtY3S4C1LWS5QYrOY8_fw=.c2ceb0ce-ac52-4c86-aa8c-3e4b7bb6212a@github.com>

On Thu, 2 Jun 2022 18:39: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:
>> 
>>   8287580: Add catch to AbstractSelectableChannel, remove remove() from SelectorImpl, open only one SocketChannel in test
>
> src/java.base/share/classes/java/nio/channels/spi/AbstractSelectableChannel.java line 236:
> 
>> 234:                         k.interestOps(ops);
>> 235:                     } catch (CancelledKeyException ignored) {
>> 236:                     }
> 
> The register method is specified to throw CKE "If this channel is currently registered with the given selector but the corresponding key has already been cancelled". So we shouldn't be changing anything in this class.

Reverted in 98bcd22e8ba60c7499fab332f943616bb88b03f5.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From bpb at openjdk.java.net  Thu Jun  2 22:14:33 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 2 Jun 2022 22:14:33 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <J3W6YaeDkOC_9aYtuwRzBrO9H-_hxhKeXur5cKLv2cs=.b7448528-42bb-49ed-9183-816e2834e3e8@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <mkrhGDEXLyY4V0ISBHUCRjYCqY_68w6D8DsLQGzKRBQ=.6cd513fe-2b95-4447-99d8-6b90672f7c8a@github.com>
 <J3W6YaeDkOC_9aYtuwRzBrO9H-_hxhKeXur5cKLv2cs=.b7448528-42bb-49ed-9183-816e2834e3e8@github.com>
Message-ID: <1SvEd5mP5kw4bxtaSgjKsIstmMODHszuMH6i0Alf20c=.6ad1cbbf-9761-4d09-9338-ab557e41bef5@github.com>

On Thu, 2 Jun 2022 18:23:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Selector/KeyCancelled.java line 67:
>> 
>>> 65:                     c.register(s, SelectionKey.OP_READ);
>>> 66:                     // c.isRegistered() is false here after the exceptional case
>>> 67:                 }
>> 
>> This tries to create 10k SocketChannels. I would be concerned with the robustness of this test. I suspect it should be possible to create the conditions for the bug with just one socket channel where the registration key is flushed from the Selector in the loop, the next registration will create a new key that can be cancelled asynchronously by the other thread.
>
> Commit 925336449bfda90791b7e289d0008da4a9bc87a6 changes the test to use a single `SocketChannel`.

Commit 98bcd22e8ba60c7499fab332f943616bb88b03f5 reduces the number of `SocketChannels` created per invocation of `test()` to 5. With this change, a run of 5 test repeats in the test harness had these failure rates:

5/5 failures linux-aarch64
4/5 failures linux-x64
4/5 failures macosx-x64
3/4 failures windows-x64

This looks sufficient to detect a failure but with a much lower number of open sockets.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Fri Jun  3 07:04:35 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 07:04:35 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <lYdsadU-Rxh9flBLgn6WYuMLPfkN7nwNboD7WmKFoDs=.b9a15972-2738-4fe9-a26e-c43bdb395caa@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <YUfHQsvfO6e2FYfg0RnJFdXdjdPeCzlB-e1mkqghWlw=.6d65ddeb-45db-4494-9945-ec957cda0c26@github.com>
 <fR2jlcglSaD3x4HEbXPBbOBpcNy64Z2t_-hxBeRSrdc=.e9c6645b-ce9a-456b-bb60-d15a9efddb4b@github.com>
 <lYdsadU-Rxh9flBLgn6WYuMLPfkN7nwNboD7WmKFoDs=.b9a15972-2738-4fe9-a26e-c43bdb395caa@github.com>
Message-ID: <ElPyyxHDusV0ZyAu48NpnX9fLwAVriB7QOSrcnnxuXo=.e669f80c-07b0-4b9c-8a1d-623322e0ee0a@github.com>

On Thu, 2 Jun 2022 12:34:17 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

>>> Hi Brian, what about adding the selection key to ?keys? after we set the interesOps ? I do not see any side effect of doing this.
>> 
>> That would mean a selection key could be selected before it added to the selector's key set. So I don't think it is feasible, at least not without working through the spec implications.
>
> agreed,as soon as we set the  interestOps on key, native  system call can select the particular fd which is not yet added to the selector key set.

One suggestion is to a comment into the empty block, maybe something like "// cancelled by someone iterating over the selector's key set"

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Fri Jun  3 07:04:38 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 07:04:38 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <TMwqJ5s-5U0CyfqSjYEPDMvp6XyKPw3MrqJBGVrWDG4=.9640967c-eb17-4c9c-85af-2c4369f5428b@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

test/jdk/java/nio/channels/Selector/KeyCancelled.java line 36:

> 34: import java.util.concurrent.CountDownLatch;
> 35: 
> 36: public class KeyCancelled {

Maybe rename to "CancelDuringRegister" so it's a bit more obvious from the test name what the test is for.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From vtewari at openjdk.java.net  Fri Jun  3 07:04:38 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 3 Jun 2022 07:04:38 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <1SvEd5mP5kw4bxtaSgjKsIstmMODHszuMH6i0Alf20c=.6ad1cbbf-9761-4d09-9338-ab557e41bef5@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <mkrhGDEXLyY4V0ISBHUCRjYCqY_68w6D8DsLQGzKRBQ=.6cd513fe-2b95-4447-99d8-6b90672f7c8a@github.com>
 <J3W6YaeDkOC_9aYtuwRzBrO9H-_hxhKeXur5cKLv2cs=.b7448528-42bb-49ed-9183-816e2834e3e8@github.com>
 <1SvEd5mP5kw4bxtaSgjKsIstmMODHszuMH6i0Alf20c=.6ad1cbbf-9761-4d09-9338-ab557e41bef5@github.com>
Message-ID: <hv8Q88bogqCrUyFsWVBaV6TnnRRadlMX-xfVRQ36Pvg=.9342c3b2-2cc8-4a6e-99a1-50fcec841fca@github.com>

On Thu, 2 Jun 2022 22:10:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Commit 925336449bfda90791b7e289d0008da4a9bc87a6 changes the test to use a single `SocketChannel`.
>
> Commit 98bcd22e8ba60c7499fab332f943616bb88b03f5 reduces the number of `SocketChannels` created per invocation of `test()` to 5. With this change, a run of 5 test repeats in the test harness had these failure rates without the source change applied:
> 
> 5/5 failures linux-aarch64
> 4/5 failures linux-x64
> 4/5 failures macosx-x64
> 3/4 failures windows-x64
> 
> This looks sufficient to detect a failure but with a much lower number of open sockets.

When i ran you test code(without the fix) on my mac , i am getting sometime NPE as below. Please have look, your test may fail intermittently in future with below NPE.

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Fri Jun  3 07:22:25 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 07:22:25 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <7aUzKwNyyoYcGysoZ5jH_cio5_h2rtf-zKzjnNzoiqo=.3c939e4c-9002-4d42-b244-940d0666b5dd@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

Here's a suggestion for a test that is closer to what I suggested in one of the early messages. The main difference is that there is a loop calling selectNow so that the cancelled key is flushed and subsequent calls to register work as a new registration. 


import java.nio.channels.*;

public class CancelDuringRegister {

    private static volatile boolean done;

    public static void main(String[] args) throws Exception {
        try (Selector sel = Selector.open()) {

            // create thread to cancel all keys in the selector's key set
            var thread = new Thread(() -> {
                while (!done) {
                    sel.keys().forEach(SelectionKey::cancel);
                }
            });
            thread.start();

            try (SocketChannel sc = SocketChannel.open()) {
                sc.configureBlocking(false);
                for (int i = 0; i <100_000; i++) {
                    sc.register(sel, SelectionKey.OP_READ);
                    sel.selectNow();
                }
            } finally {
                done = true;
                thread.join();
            }
        }
    }
}

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From vtewari at openjdk.java.net  Fri Jun  3 07:47:39 2022
From: vtewari at openjdk.java.net (Vyom Tewari)
Date: Fri, 3 Jun 2022 07:47:39 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <5pEHwzhlZ07PilLI_D_XvZ6MDc5P0jY0U9nghgMhKyc=.5df3a3bd-e898-4f52-82fc-ac2170dc668b@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

> 
It is  failing with different code path as below.

$ /home/worker/source/jdk/jdk/build/linux-x86_64-server-release/images/jdk/bin/java CancelDuringRegister
Exception in thread "main" java.nio.channels.CancelledKeyException
	at java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:75)
	at java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:104)
	at java.base/java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:233)
	at java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260)
	at CancelDuringRegister.main(CancelDuringRegister.java:21)

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From rriggs at openjdk.java.net  Fri Jun  3 15:09:39 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Fri, 3 Jun 2022 15:09:39 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v9]
In-Reply-To: <KmSrf0IcFTPtAe8aHHAsuys6bzrRn3ukLDAXKur3Q-4=.7f1fec1d-f1df-4334-a027-d798acd3d38c@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
 <KmSrf0IcFTPtAe8aHHAsuys6bzrRn3ukLDAXKur3Q-4=.7f1fec1d-f1df-4334-a027-d798acd3d38c@github.com>
Message-ID: <8IhMHiAyQOk8OexqBz97jpucJdXbdSTlfb4WvMvrJ6M=.dc51c1e2-8702-4ec4-8fd8-2585a3ef58c6@github.com>

On Wed, 4 May 2022 21:07:14 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 superfluous new Object[] statements from test

This is still a good idea.

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

PR: https://git.openjdk.java.net/jdk/pull/8066

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>

This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).

I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).

`MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

Commit messages:
 - Add null check on Buffer::checkState
 - Add docs
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - Add @ForceInline in hot path from var handle access
 - ... and 3 more: https://git.openjdk.java.net/jdk/compare/d5b6c7bd...68028fa4

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287809
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From mcimadamore at openjdk.java.net  Fri Jun  3 15:55:13 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Fri, 3 Jun 2022 15:55:13 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <AgqwxT-Tw5SRrC3fkr33yz5v709cCPjTuPTDYsdxpfQ=.68b76852-db8f-4aea-a185-abf8f460ece7@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Note: other cleanups are possible - such as flattening `ResourceList` into `MemorySession.State`. While that is possible, that's a tricky step, given that the session state can be registered against a cleaner. One option, which I explored, would be to use `MemorySessionImpl` for reachability - which then has an impact on `ScopedMemoryAccess`, as we would have to add reachability fences on the session, as well as on the session state. In any case, I'd like to proceed by steps, since this cleanup was already getting big enough.

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

PR: https://git.openjdk.java.net/jdk/pull/9017

From bpb at openjdk.java.net  Fri Jun  3 16:06:31 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 3 Jun 2022 16:06:31 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <x2ULcvFzwx5fqxBthSrOlgXffdgpNzr3aRrCQy_MTCQ=.0d8c07d3-be25-42b6-872a-02ff59dffee2@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

> > 
> 
> It is failing with different code path as below.
> [...]
> at java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260) at CancelDuringRegister.main(CancelDuringRegister.java:21)

I see the same (linux-aarch64, windows-x64):


----------System.err:(14/895)----------
java.nio.channels.CancelledKeyException
	at java.base/sun.nio.ch.SelectionKeyImpl.ensureValid(SelectionKeyImpl.java:75)
	at java.base/sun.nio.ch.SelectionKeyImpl.interestOps(SelectionKeyImpl.java:104)
	at java.base/java.nio.channels.spi.AbstractSelectableChannel.register(AbstractSelectableChannel.java:233)
	at java.base/java.nio.channels.SelectableChannel.register(SelectableChannel.java:260)
	at CancelDuringRegister.main(CancelDuringRegister.java:51)```

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From naoto at openjdk.java.net  Fri Jun  3 16:58:07 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Fri, 3 Jun 2022 16:58:07 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for charset
 "windows-1252"
Message-ID: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>

The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

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

Commit messages:
 - 8287541: Files.writeString fails to throw IOException for charset "windows-1252"

Changes: https://git.openjdk.java.net/jdk/pull/9019/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9019&range=00
  Issue: https://bugs.openjdk.java.net/browse/JDK-8287541
  Stats: 22 lines in 2 files changed: 4 ins; 11 del; 7 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9019.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9019/head:pull/9019

PR: https://git.openjdk.java.net/jdk/pull/9019

From iris at openjdk.java.net  Fri Jun  3 17:24:34 2022
From: iris at openjdk.java.net (Iris Clark)
Date: Fri, 3 Jun 2022 17:24:34 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <6Yy8ZhSU6dPNfyfUAbjO2gYLy7R4moFZaX1fwbA9K98=.1e16f29b-4541-4af7-a9f3-8510ccdcedf5@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by iris (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From bpb at openjdk.java.net  Fri Jun  3 18:15:32 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Fri, 3 Jun 2022 18:15:32 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <j4NejE-TvPMjkn9pRPrWyT-vl3EBHDJ2tQA4sz1xBAU=.25df0968-23f7-4643-8a00-c3695b94706b@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by bpb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From alanb at openjdk.java.net  Fri Jun  3 20:14:22 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Fri, 3 Jun 2022 20:14:22 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <-3KWDzj6Iv4PU_dBq8eT-9dOZX3i0CDQ8pUlGWeD2-M=.dfc0c643-49e7-4578-9aeb-11810d20cedf@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From aturbanov at openjdk.java.net  Sat Jun  4 11:30:16 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Sat, 4 Jun 2022 11:30:16 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

src/java.base/share/classes/java/lang/String.java line 849:

> 847:         int en = scale(len, ce.maxBytesPerChar());
> 848:         // fastpath with ArrayEncoder implies `doReplace`.
> 849:         if (ce instanceof ArrayEncoder ae && doReplace) {

Wouldn't it be more readable (and perphaps faster) if we do check boolean flag first?

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From jpai at openjdk.java.net  Mon Jun  6 13:19:57 2022
From: jpai at openjdk.java.net (Jaikiran Pai)
Date: Mon, 6 Jun 2022 13:19:57 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <xZUKGdJD4aQf8b-5HcP5e8o0yoFtJx8U5Odk2RNKlV8=.ea2599da-ce1b-4c23-9521-a0fb375f376b@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by jpai (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From lancea at openjdk.java.net  Mon Jun  6 15:15:44 2022
From: lancea at openjdk.java.net (Lance Andersen)
Date: Mon, 6 Jun 2022 15:15:44 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <PIUXlHL_c4nBilt6NRtOkjiwQILSo6UP-qsdQGWcukE=.75873fa5-6034-49b9-96b3-6ab4ccc14732@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

Marked as reviewed by lancea (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From naoto at openjdk.java.net  Mon Jun  6 15:50:39 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 15:50:39 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

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

  Changed per suggestion

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9019/files
  - new: https://git.openjdk.java.net/jdk/pull/9019/files/72d27809..51ce3615

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9019&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9019&range=00-01

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From naoto at openjdk.java.net  Mon Jun  6 15:50:42 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Mon, 6 Jun 2022 15:50:42 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
 <tP13YR4kuRlnwDNmLarYlJOxC5uJzgndoDUNQy8bu4E=.73908ccb-b81f-40ab-8981-e1854c462562@github.com>
Message-ID: <ypNlEHC_fV9UQINB_f6N9wPpPiEHzCwVU74ivIjtIbU=.e023d50b-f51c-48ae-98fa-8a14fa37df03@github.com>

On Sat, 4 Jun 2022 11:27:00 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Changed per suggestion
>
> src/java.base/share/classes/java/lang/String.java line 849:
> 
>> 847:         int en = scale(len, ce.maxBytesPerChar());
>> 848:         // fastpath with ArrayEncoder implies `doReplace`.
>> 849:         if (ce instanceof ArrayEncoder ae && doReplace) {
> 
> Wouldn't it be more readable (and perphaps faster) if we do check boolean flag first?

Fixed.

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From bpb at openjdk.java.net  Mon Jun  6 22:38:40 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Mon, 6 Jun 2022 22:38:40 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
Message-ID: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>

If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.

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

Commit messages:
 - 8286160: (fs) Files.exists returns unexpected results with C:\pagefile.sys because it's not readable

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From alanb at openjdk.java.net  Tue Jun  7 09:32:53 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Jun 2022 09:32:53 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
In-Reply-To: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
Message-ID: <ZmTfKbzzp6zSPiTNnr2LHDdL1-I2GwODwfW1zvonFTI=.1546e6f8-59b3-42f6-8e3e-1bdc7abeb49d@github.com>

On Mon, 6 Jun 2022 22:28:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.

src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 395:

> 393:                 }
> 394:                 throw ioe;
> 395:             }

Testing the existence of a file is performance issue in some usages and would be interesting to see if this would be a bit better.


        // check file exists only
        if (!r && !w && !x) {
            file.checkRead();
            try {
                WindowsFileAttributes.get(file, true);
                return;
            } catch (WindowsException e) {
                exc.rethrowAsIOException(file);
            }
        }

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From mcimadamore at openjdk.java.net  Tue Jun  7 13:00:37 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Tue, 7 Jun 2022 13:00:37 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
 - Simplify readOnly check
 - ... and 4 more: https://git.openjdk.java.net/jdk/compare/8d28734e...5b8f7246

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

Changes: https://git.openjdk.java.net/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=9017&range=01
  Stats: 1752 lines in 39 files changed: 407 ins; 525 del; 820 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9017/head:pull/9017

PR: https://git.openjdk.java.net/jdk/pull/9017

From aturbanov at openjdk.java.net  Tue Jun  7 14:50:38 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 7 Jun 2022 14:50:38 GMT
Subject: RFR: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252" [v2]
In-Reply-To: <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
 <2nrJW64dS7XJIqFiHzSVQ6lrZqwTF5yi6JxUWQyQPFc=.d5acfba0-a78a-4b59-8429-f7698ecb80c1@github.com>
Message-ID: <vkH0gFP7mEmqnf3w4qrn7wQ9zEOGDVQUoif57jdtScg=.dc476ea6-fb67-44ff-88cb-0b271bb1a320@github.com>

On Mon, 6 Jun 2022 15:50:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Changed per suggestion

Marked as reviewed by aturbanov (Committer).

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From bpb at openjdk.java.net  Tue Jun  7 15:54:59 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 7 Jun 2022 15:54:59 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
In-Reply-To: <ZmTfKbzzp6zSPiTNnr2LHDdL1-I2GwODwfW1zvonFTI=.1546e6f8-59b3-42f6-8e3e-1bdc7abeb49d@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <ZmTfKbzzp6zSPiTNnr2LHDdL1-I2GwODwfW1zvonFTI=.1546e6f8-59b3-42f6-8e3e-1bdc7abeb49d@github.com>
Message-ID: <RUHVCfzBCZ6cswzj7d1CKrKXGECvOxO25X8DmedqakY=.b41d66f7-b3a4-4be7-b1e6-2699b1cfe259@github.com>

On Tue, 7 Jun 2022 09:29:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 395:
> 
>> 393:                 }
>> 394:                 throw ioe;
>> 395:             }
> 
> Testing the existence of a file is performance issue in some usages and would be interesting to see if this would be a bit better.
> 
> 
>         // check file exists only
>         if (!r && !w && !x) {
>             file.checkRead();
>             try {
>                 WindowsFileAttributes.get(file, true);
>                 return;
>             } catch (WindowsException e) {
>                 exc.rethrowAsIOException(file);
>             }
>         }

That was actually my first draft version. What happened to `checkReadAccess()` here?

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From alanb at openjdk.java.net  Tue Jun  7 15:54:59 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 7 Jun 2022 15:54:59 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
In-Reply-To: <RUHVCfzBCZ6cswzj7d1CKrKXGECvOxO25X8DmedqakY=.b41d66f7-b3a4-4be7-b1e6-2699b1cfe259@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <ZmTfKbzzp6zSPiTNnr2LHDdL1-I2GwODwfW1zvonFTI=.1546e6f8-59b3-42f6-8e3e-1bdc7abeb49d@github.com>
 <RUHVCfzBCZ6cswzj7d1CKrKXGECvOxO25X8DmedqakY=.b41d66f7-b3a4-4be7-b1e6-2699b1cfe259@github.com>
Message-ID: <zn6VmWxTfpR6gwnx8e5JUxzWYHZQMfwm14VH49yDBaM=.8a2a6481-6425-4abb-a841-143c14501dbc@github.com>

On Tue, 7 Jun 2022 15:48:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsFileSystemProvider.java line 395:
>> 
>>> 393:                 }
>>> 394:                 throw ioe;
>>> 395:             }
>> 
>> Testing the existence of a file is performance issue in some usages and would be interesting to see if this would be a bit better.
>> 
>> 
>>         // check file exists only
>>         if (!r && !w && !x) {
>>             file.checkRead();
>>             try {
>>                 WindowsFileAttributes.get(file, true);
>>                 return;
>>             } catch (WindowsException e) {
>>                 exc.rethrowAsIOException(file);
>>             }
>>         }
>
> That was actually my first draft version. What happened to `checkReadAccess()` here?

checkReadAccess comes later, when !w & !x.

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From bpb at openjdk.java.net  Tue Jun  7 15:58:14 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 7 Jun 2022 15:58:14 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
In-Reply-To: <zn6VmWxTfpR6gwnx8e5JUxzWYHZQMfwm14VH49yDBaM=.8a2a6481-6425-4abb-a841-143c14501dbc@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <ZmTfKbzzp6zSPiTNnr2LHDdL1-I2GwODwfW1zvonFTI=.1546e6f8-59b3-42f6-8e3e-1bdc7abeb49d@github.com>
 <RUHVCfzBCZ6cswzj7d1CKrKXGECvOxO25X8DmedqakY=.b41d66f7-b3a4-4be7-b1e6-2699b1cfe259@github.com>
 <zn6VmWxTfpR6gwnx8e5JUxzWYHZQMfwm14VH49yDBaM=.8a2a6481-6425-4abb-a841-143c14501dbc@github.com>
Message-ID: <zHmt8g_U13TDXJTeTe4YypXphmrh2QR5XyrWS1XoXO0=.076739b8-9d9c-4e4e-862a-5305f064382b@github.com>

On Tue, 7 Jun 2022 15:51:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> That was actually my first draft version. What happened to `checkReadAccess()` here?
>
> checkReadAccess comes later, when !w & !x.

I misread that. I'll give it a try.

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From bpb at openjdk.java.net  Wed Jun  8 00:21:21 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 00:21:21 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable [v2]
In-Reply-To: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
Message-ID: <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>

> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.

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

  8286160: Move check for existence with no modes specifieds

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/9045/files
  - new: https://git.openjdk.java.net/jdk/pull/9045/files/5082b94d..c39b6ede

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9045&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9045&range=00-01

  Stats: 25 lines in 1 file changed: 9 ins; 12 del; 4 mod
  Patch: https://git.openjdk.java.net/jdk/pull/9045.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/9045/head:pull/9045

PR: https://git.openjdk.java.net/jdk/pull/9045

From alanb at openjdk.java.net  Wed Jun  8 06:54:21 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 8 Jun 2022 06:54:21 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable [v2]
In-Reply-To: <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
Message-ID: <9B5nZ_4rmIzcGb4u84_8K6jN7MZl5lSX3yNpPhc00QQ=.0e1ca4b1-5508-411d-9c30-3c7f88f502e5@github.com>

On Wed, 8 Jun 2022 00:21:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286160: Move check for existence with no modes specifieds

Updated version looks good, did you do any performance checking compared to the existing code?

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

Marked as reviewed by alanb (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/9045

From bpb at openjdk.java.net  Wed Jun  8 15:15:31 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 15:15:31 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable [v2]
In-Reply-To: <9B5nZ_4rmIzcGb4u84_8K6jN7MZl5lSX3yNpPhc00QQ=.0e1ca4b1-5508-411d-9c30-3c7f88f502e5@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
 <9B5nZ_4rmIzcGb4u84_8K6jN7MZl5lSX3yNpPhc00QQ=.0e1ca4b1-5508-411d-9c30-3c7f88f502e5@github.com>
Message-ID: <22xU8tHxFN7yU0U0ec21QrVftH9PPdy4kZS9uQ48EmU=.ef9e8256-9d8e-4ff4-9abf-88324e568e28@github.com>

On Wed, 8 Jun 2022 06:50:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Updated version looks good, did you do any performance checking compared to the existing code?

No I did not, at least not yet.

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From naoto at openjdk.java.net  Wed Jun  8 15:53:03 2022
From: naoto at openjdk.java.net (Naoto Sato)
Date: Wed, 8 Jun 2022 15:53:03 GMT
Subject: Integrated: 8287541: Files.writeString fails to throw IOException for
 charset "windows-1252"
In-Reply-To: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
References: <Jt8iwdZ47TGbOCTxoIG_sWr1VqvUxfSEljbMkg5zXyY=.c458451e-fb06-49e2-8e22-b292e3466a1c@github.com>
Message-ID: <0cxpGIiWWnfKQRH3enCmtvwFlb6VMhxi2OMJkBcCmWQ=.2ffae29b-30a7-4170-a6ea-54f5bbe713e6@github.com>

On Fri, 3 Jun 2022 16:48:46 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> The code path calls `String.getBytesNoRepl()`, but it blindly replaces unmappable characters with replacements if the encoder is an `ArrayEncoder`. Changed only to do so if `doReplace` is `true` in `String.encodeWithEncoder()`.

This pull request has now been integrated.

Changeset: 6fb84e2c
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/6fb84e2c9119bdb9c66dd49422bcab637bbd4008
Stats:     22 lines in 2 files changed: 4 ins; 11 del; 7 mod

8287541: Files.writeString fails to throw IOException for charset "windows-1252"

Reviewed-by: iris, bpb, alanb, jpai, lancea, aturbanov

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

PR: https://git.openjdk.java.net/jdk/pull/9019

From duke at openjdk.java.net  Wed Jun  8 17:40:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v18]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <1xVR4-ZIHnyfeei_7RmrCV8g8aVvzI3aGgUHIP8fZx4=.d4206519-b280-4021-8fbd-a2f46180e8d1@github.com>

> as title.

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

 - remove null check for Capacitiable in WhiteBoxResizeTest
 - Rename type variable per CSR request; minor spec wording change.

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/98bfb0e1..bacc9ca8

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=16-17

  Stats: 19 lines in 3 files changed: 0 ins; 13 del; 6 mod
  Patch: https://git.openjdk.java.net/jdk/pull/8302.diff
  Fetch: git fetch https://git.openjdk.java.net/jdk pull/8302/head:pull/8302

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:40:43 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:40:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <VKRNghK623T-nMkiS7j_8DfYfdjPBu6tCIhs1x7FaqU=.61db834f-12be-446c-a7d6-8523727ba920@github.com>
Message-ID: <vl6R4iBqQ81oJiQqySRtRgivszdAVIbjkraflV3FgvA=.c18bd636-d10d-4acc-a273-f1aef8624f53@github.com>

On Wed, 1 Jun 2022 17:34:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> test/jdk/java/util/HashMap/WhiteBoxResizeTest.java line 441:
> 
>> 439:         }
>> 440:     }
>> 441: 
> 
> This unifies the test cases between the Set and Map factories, which accomplishes the primary goal. Good.
> 
> The unification is achieved through classic object-oriented polymorphism, which works fine, though which is rather verbose. This could probably be reduced with some tinkering on the model, but it's probably reaching the point where additional tinkering on the model isn't worth it. I'm ok with sticking with this approach for now. Maybe we can clean it up later, or maybe not -- it's at least fairly straightforward.
> 
> One issue that contributes to the verbosity is the repeated null checking. The null checking enables the test code to proceed and end up with -1 as the capacity if there's a null in there somewhere. This will cause the assertion to fail. This is good in that it will call attention to itself (as opposed to silently passing or something). However, if the test cases are set up properly, they should never run into null. If the null checking weren't done, an unexpected null will throw NPE, which will be caught be the framework and reported as an error.
> 
> That seems perfectly fine to me, so I'd suggest simply removing the null checking. That would also reduce the bulkiness of infrastructure.

@stuart-marks done.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:49:38 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:38 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>

> as title.

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

  clean up Calendar

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

Changes:
  - all: https://git.openjdk.java.net/jdk/pull/8302/files
  - new: https://git.openjdk.java.net/jdk/pull/8302/files/bacc9ca8..95d59b97

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=18
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8302&range=17-18

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From duke at openjdk.java.net  Wed Jun  8 17:49:40 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Wed, 8 Jun 2022 17:49:40 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v17]
In-Reply-To: <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <3HLgyTYVXiS7XiCcKzfRVjLyLhSNJvNGU2vnODthxY8=.bc332111-759b-4136-a6c8-2aaca5931618@github.com>
 <GzGV0h85Y42FHpMoF3XKFDxW4kQoBBoifCeysyUvCMM=.3f536a2a-ccf4-47b1-ad7c-9feffe2965d8@github.com>
Message-ID: <EahYlBb628e0d_B3qOx1YbXqBmU0s5LKut12Z0nM_Qk=.39bbbf60-b42c-40ef-af52-3984487e176c@github.com>

On Wed, 1 Jun 2022 18:26:17 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   do it as naotoj said
>
> src/java.base/share/classes/java/util/Calendar.java line 2648:
> 
>> 2646:             set.add("gregory");
>> 2647:             set.add("buddhist");
>> 2648:             set.add("japanese");
> 
> This can be replaced with `SET = Set.of("gregory", "buddhist", "japanese");`.

@naotoj Yes it can. I did a further clean up to it, please have a look.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From smarks at openjdk.java.net  Wed Jun  8 20:16:33 2022
From: smarks at openjdk.java.net (Stuart Marks)
Date: Wed, 8 Jun 2022 20:16:33 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <66QMts98pQNLZzxi4BlX-aj13JkeVQeB8v8MNKVrpDY=.9b8680cc-f54e-4d7f-9b25-806b367d835b@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

Running tests and awaiting review from security team. Our internal test system is backlogged and tests might not complete in time to get into JDK 19.

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From ascarpino at openjdk.java.net  Wed Jun  8 20:31:43 2022
From: ascarpino at openjdk.java.net (Anthony Scarpino)
Date: Wed, 8 Jun 2022 20:31:43 GMT
Subject: RFR: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet [v19]
In-Reply-To: <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
 <XPlxiH1CfY0IJXRG1GjtmJ3LBfyteSyH0GOcHry_BZw=.cfe04cc6-3029-4b70-8791-969ed0fa1f9c@github.com>
Message-ID: <kqydNmdnzsVvm6ITkeY9avGcwLvwp9C4T8HeILLC12U=.6d177140-6176-44b5-9b4b-bd78570a078d@github.com>

On Wed, 8 Jun 2022 17:49:38 GMT, XenoAmess <duke at openjdk.java.net> wrote:

>> as title.
>
> XenoAmess has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clean up Calendar

I gave a quick look at the security files touched and seems straightforward. I didn't see any problems

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

Marked as reviewed by ascarpino (Reviewer).

PR: https://git.openjdk.java.net/jdk/pull/8302

From bpb at openjdk.java.net  Wed Jun  8 22:40:35 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 22:40:35 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable [v2]
In-Reply-To: <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
Message-ID: <37RwoJmM7hFKtUzOY7XWCIDqhNJd4wSWsiqxICAs6q8=.7d55fcb5-c552-40b2-919e-d2dfd6e20393@github.com>

On Wed, 8 Jun 2022 00:21:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8286160: Move check for existence with no modes specifieds

> > [D]id you do any performance checking compared to the existing code?
> 
> No I did not, at least not yet.

Performance measurements for the before and after are as follows:

**Existing Code**

Benchmark                        (name)   Mode  Cnt      Score      Error  Units

CheckAccess.exists      C:\pagefile.sys  thrpt   10  10525.872 ?  247.734  ops/s
CheckAccess.exists                   C:  thrpt   10  11489.428 ?   69.678  ops/s
CheckAccess.exists                 junk  thrpt   10  15368.786 ? 2322.512  ops/s

CheckAccess.isReadable  C:\pagefile.sys  thrpt   10   9674.403 ?  271.966  ops/s
CheckAccess.isReadable               C:  thrpt   10  10578.904 ?  201.453  ops/s
CheckAccess.isReadable             junk  thrpt   10  16072.720 ?  117.358  ops/s

CheckAccess.isWritable  C:\pagefile.sys  thrpt   10   7211.853 ?   62.367  ops/s
CheckAccess.isWritable               C:  thrpt   10    919.860 ?   13.846  ops/s
CheckAccess.isWritable             junk  thrpt   10    832.815 ?   49.616  ops/s

 **Modified Code**

Benchmark                        (name)   Mode  Cnt      Score     Error  Units
CheckAccess.exists      C:\pagefile.sys  thrpt   10  11412.256 ? 710.767  ops/s
CheckAccess.exists                   C:  thrpt   10  28780.641 ? 345.568  ops/s
CheckAccess.exists                 junk  thrpt   10  28277.019 ? 219.792  ops/s

CheckAccess.isReadable  C:\pagefile.sys  thrpt   10  10465.858 ? 176.803  ops/s
CheckAccess.isReadable               C:  thrpt   10  11343.234 ? 200.306  ops/s
CheckAccess.isReadable             junk  thrpt   10  17053.404 ?  96.515  ops/s

CheckAccess.isWritable  C:\pagefile.sys  thrpt   10   7713.395 ?  89.954  ops/s
CheckAccess.isWritable               C:  thrpt   10    989.610 ?   5.155  ops/s
CheckAccess.isWritable             junk  thrpt   10    873.649 ?   6.802  ops/s

The updated code shows higher throughput for all tests, and substantially higher for a couple of the `exists()` test.

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From bpb at openjdk.java.net  Wed Jun  8 23:40:11 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 23:40:11 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should state it
 always throws UOE
Message-ID: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>

Add an `@implSpec` annotation to the `java.nio.channels.FileChannel::map` method for mapped memory segments indicating that it always throws an `UnsupportedOperationException`.

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

Commit messages:
 - 8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE

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

PR: https://git.openjdk.java.net/jdk/pull/9095

From bpb at openjdk.java.net  Wed Jun  8 23:42:54 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 23:42:54 GMT
Subject: RFR: 8286735: (fc) FileChannel#map should document behavior when
 using custom file systems
In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com>
References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com>
Message-ID: <f8Z-TSlzq1s7QxLywfd9PCGpgl58QLPGmzIxr_onthU=.f5cdc1f7-0f0c-4e99-a090-0d387e670091@github.com>

On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`.

Withdrawing this request in favor of https://github.com/openjdk/jdk/pull/9095.

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

PR: https://git.openjdk.java.net/jdk/pull/8739

From bpb at openjdk.java.net  Wed Jun  8 23:42:55 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 8 Jun 2022 23:42:55 GMT
Subject: Withdrawn: 8286735: (fc) FileChannel#map should document behavior when
 using custom file systems
In-Reply-To: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com>
References: <0ng0prLT9_jR0Ka2Dh19BIIUsYe7uF4P8EE6SV_pq04=.7205ff8f-8267-4b0f-9f81-380053720c4c@github.com>
Message-ID: <stqpy2xibOH3ozJQk7ZSGU2JZqYSNyXQZzlXNy0eSiE=.d29600fd-bc54-43e8-99bd-da1ea0ff7276@github.com>

On Tue, 17 May 2022 01:12:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify when the `map()` methods of `java.nio.channels.FileChannel` throw an `UnsupportedOperationException`.

This pull request has been closed without being integrated.

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

PR: https://git.openjdk.java.net/jdk/pull/8739

From duke at openjdk.java.net  Thu Jun  9 01:54:37 2022
From: duke at openjdk.java.net (XenoAmess)
Date: Thu, 9 Jun 2022 01:54:37 GMT
Subject: Integrated: 8284780: Need methods to create pre-sized HashSet and
 LinkedHashSet
In-Reply-To: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
References: <lyaOpJx011DsX8WnI3tW8iCz30-Fb21-0YPDA6rrz4A=.ddb90d67-5644-485a-a436-bb1abaac90d1@github.com>
Message-ID: <uBGmXlQd9TXwXKbiDcrVcLUktKK4rTenr6JRZx7MBjA=.9a961a01-5109-4e38-8594-c3413bdf0c8c@github.com>

On Tue, 19 Apr 2022 18:00:19 GMT, XenoAmess <duke at openjdk.java.net> wrote:

> as title.

This pull request has now been integrated.

Changeset: e01cd7c3
Author:    XenoAmess <xenoamess at gmail.com>
Committer: Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.java.net/jdk/commit/e01cd7c3ed923cd19509fc972ba6e4aa2991289f
Stats:     154 lines in 29 files changed: 107 ins; 7 del; 40 mod

8284780: Need methods to create pre-sized HashSet and LinkedHashSet

Reviewed-by: naoto, bpb, dfuchs, ascarpino

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

PR: https://git.openjdk.java.net/jdk/pull/8302

From alanb at openjdk.java.net  Thu Jun  9 08:14:43 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 9 Jun 2022 08:14:43 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <aSBaXEjfQkfZVA6c9fBrJF4WbMpHq_FoXKXiy1_QcII=.6b526e36-5b63-442a-83c8-f0e0164d7a5a@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

So should we just ignore this PR for now until the test is stable?

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

PR: https://git.openjdk.java.net/jdk/pull/8978

From alanb at openjdk.java.net  Thu Jun  9 08:14:45 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 9 Jun 2022 08:14:45 GMT
Subject: RFR: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable [v2]
In-Reply-To: <37RwoJmM7hFKtUzOY7XWCIDqhNJd4wSWsiqxICAs6q8=.7d55fcb5-c552-40b2-919e-d2dfd6e20393@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
 <5XWgIMfxuYqS6MnuGw1TnsuaSPcZrzhYOwDAYpP3FWk=.6622a460-f6dd-4902-8b71-6316090cbd2c@github.com>
 <37RwoJmM7hFKtUzOY7XWCIDqhNJd4wSWsiqxICAs6q8=.7d55fcb5-c552-40b2-919e-d2dfd6e20393@github.com>
Message-ID: <hi2FIbXRuh6eb0e5MxMmw178b4jfZbYp5Pv__SkIer0=.cd0efa43-f70f-4c1b-8cd7-ba2a99be449a@github.com>

On Wed, 8 Jun 2022 22:36:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The updated code shows higher throughput for all tests, and substantially higher for a couple of the `exists()` tests.

The change should have no impact on isReadable/isWritable, only exists, and it's good to see that this has improved. I think you are good to go on this one.

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

PR: https://git.openjdk.java.net/jdk/pull/9045

From alanb at openjdk.java.net  Thu Jun  9 08:22:26 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 9 Jun 2022 08:22:26 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should
 state it always throws UOE
In-Reply-To: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
References: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
Message-ID: <iPH-R4Vb3dilf7QtyYSfmJvxNy7MHHETisZyMPrNKfM=.92f30f4d-8f21-41d1-afce-eb21c692424f@github.com>

On Wed, 8 Jun 2022 23:33:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an `@implSpec` annotation to the `java.nio.channels.FileChannel::map` method for mapped memory segments indicating that it always throws an `UnsupportedOperationException`.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.java.net/jdk/pull/9095

From uschindler at openjdk.java.net  Thu Jun  9 08:43:33 2022
From: uschindler at openjdk.java.net (Uwe Schindler)
Date: Thu, 9 Jun 2022 08:43:33 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should
 state it always throws UOE
In-Reply-To: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
References: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
Message-ID: <N0Z_0YEyulwKdjjN0EXKUnbO65RfMGN7ClGpaKKwyBg=.dd587a34-2c90-4cd1-8a5f-1280275abcb8@github.com>

On Wed, 8 Jun 2022 23:33:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add an `@implSpec` annotation to the `java.nio.channels.FileChannel::map` method for mapped memory segments indicating that it always throws an `UnsupportedOperationException`.

src/java.base/share/classes/java/nio/channels/FileChannel.java line 1000:

> 998:      *           segment is unspecified and should not be relied upon.
> 999:      *
> 1000:      * @implSpec The {@code map(MapMode, long, long, MemorySession)} method of

This looks a bit strange to me, because for the reader it looks like the default file channels in Java also does this. I'd add some other sentence part explaining this.

Alternative: "The default implementation of `map(MapMode, long, long, MemorySession)` method in abstract `FileChannel` always throws an `UnsupportedOperationException`. Subclasses should override it."

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

PR: https://git.openjdk.java.net/jdk/pull/9095

From bpb at openjdk.java.net  Thu Jun  9 15:15:15 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 15:15:15 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <aSBaXEjfQkfZVA6c9fBrJF4WbMpHq_FoXKXiy1_QcII=.6b526e36-5b63-442a-83c8-f0e0164d7a5a@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
 <aSBaXEjfQkfZVA6c9fBrJF4WbMpHq_FoXKXiy1_QcII=.6b526e36-5b63-442a-83c8-f0e0164d7a5a@github.com>
Message-ID: <cOWEXny5ngr0_P6Mwi1YHc5exVe2ho3XoDYkZyl7Vpk=.09bbf5d3-fd6e-4fdb-9986-73b3ed09ece0@github.com>

On Thu, 9 Jun 2022 08:12:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So should we just ignore this PR for now until the test is stable?

Either that or go with the `KeyCancelled` test for now and file a separate issue to fix / replace that.

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

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

From bpb at openjdk.java.net  Thu Jun  9 15:37:11 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 15:37:11 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should
 state it always throws UOE [v2]
In-Reply-To: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
References: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
Message-ID: <LSbu54BjJHIEW8KqICNgnRftkOtBAc-U0nc8XUAGr0E=.73cc4128-d964-4c23-b2c0-05e31ed1f37e@github.com>

> Add an `@implSpec` annotation to the `java.nio.channels.FileChannel::map` method for mapped memory segments indicating that it always throws an `UnsupportedOperationException`.

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

  8288080: Simplify @implSpec verbiage

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9095/files
  - new: https://git.openjdk.org/jdk/pull/9095/files/2b93620e..e7119ce2

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=9095&range=01
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=9095&range=00-01

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

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

From bpb at openjdk.java.net  Thu Jun  9 15:45:39 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 15:45:39 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should
 state it always throws UOE [v2]
In-Reply-To: <N0Z_0YEyulwKdjjN0EXKUnbO65RfMGN7ClGpaKKwyBg=.dd587a34-2c90-4cd1-8a5f-1280275abcb8@github.com>
References: <r9dTcEvZOQJHN-1bFsaQ2kBRFFC6-VzH9z7KeJMQ2kg=.c163f696-5c37-44d3-a89d-e79f0b013ad1@github.com>
 <N0Z_0YEyulwKdjjN0EXKUnbO65RfMGN7ClGpaKKwyBg=.dd587a34-2c90-4cd1-8a5f-1280275abcb8@github.com>
Message-ID: <pI1V_9WgfoVAaMiOjenTpBdm31mXThDSip_Qrsh8k1A=.8ebde54d-a6b5-4a99-82de-c31f4c1ca8ed@github.com>

On Thu, 9 Jun 2022 08:39:05 GMT, Uwe Schindler <uschindler at openjdk.org> wrote:

>> Alternative: "The default implementation of `map(MapMode, long, long, MemorySession)` method in abstract `FileChannel` always throws an `UnsupportedOperationException`. Subclasses should override it."

I simplified it to match similar statements in `Selector` and `SelectorProvider`, for example. I don't think that the second sentence about overriding is needed.

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

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

From bpb at openjdk.java.net  Thu Jun  9 16:34:15 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 16:34:15 GMT
Subject: Integrated: 8286160: (fs) Files.exists returns unexpected results with
 C:\pagefile.sys because it's not readable
In-Reply-To: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
References: <q3q7JC7EDc3nDDbGjL_QmVIVdux7u8Hd2f_HeopVJjI=.44abe6c1-7ff8-421e-a0b5-f3a71dc76df1@github.com>
Message-ID: <mCAHoIfRHmee1nsjn7zHd2D8lVCikvk-Mm6auu1aW2c=.ca5fa605-61a3-4ada-b7e9-b2221914938c@github.com>

On Mon, 6 Jun 2022 22:28:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> If in `WindosFileSystemProvider.checkAccess(Path obj, AccessMode... modes)` the sub-test `checkReadAccess(WindowsPath)` fails and no modes are specified, then try to determine file existence by reading the file's attributes.

This pull request has now been integrated.

Changeset: d482d7f5
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d482d7f5b99e89185471c05cde797f13405c32f2
Stats:     47 lines in 2 files changed: 33 ins; 3 del; 11 mod

8286160: (fs) Files.exists returns unexpected results with C:\pagefile.sys because it's not readable

Reviewed-by: alanb

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

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

From bpb at openjdk.java.net  Thu Jun  9 18:39:24 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 9 Jun 2022 18:39:24 GMT
Subject: RFR: 8057113: (fs) Path should have a method to obtain the
 filename extension [v10]
In-Reply-To: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
References: <eUzeYmLj2vR9vIngM_7CkaXzKz8wDWOLulON6HSgmuw=.c5efe658-f6a5-4f5e-a2c2-ebb7dab086d4@github.com>
Message-ID: <96oNktc6mlKwMu2X7TU3mzVlcg9vifqyQhQEsmjINP8=.8a9bf8f6-fa75-4ce5-8450-a2ac48c0b1ef@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 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 12 additional commits since the last revision:

 - 8057113: Change @since annotation to 20
 - Merge
 - 8057113: Remove superfluous new Object[] statements from test
 - 8057113: Fix getExtension() commcents; improve hasExtension() implementation
 - 8057113: trailing dot yields empty string extension; add test
 - Merge
 - 8057113: String getExtension(String defaultExtension) to Optional<String> getExtension() and other changes
 - 8057113: Clean up trailing whitespace
 - 8057113: Implement reviewer suggestions for replaceExtension()
 - 8057113: Add hasExtension() and replaceExtension()
 - ... and 2 more: https://git.openjdk.org/jdk/compare/a64cfe82...4b5166ba

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8066/files
  - new: https://git.openjdk.org/jdk/pull/8066/files/629d9916..4b5166ba

Webrevs:
 - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=09
 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8066&range=08-09

  Stats: 345647 lines in 4437 files changed: 228280 ins; 91553 del; 25814 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 duke at openjdk.java.net  Sat Jun 11 13:05:52 2022
From: duke at openjdk.java.net (Markus KARG)
Date: Sat, 11 Jun 2022 13:05:52 GMT
Subject: RFR: 8278268 - (ch) InputStream returned by
 Channels.newInputStream should have fast path for FileChannel targets [v16]
In-Reply-To: <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
References: <evmSINpKEijmwqz34wHubnVnBJe-c9kl48bJzQRWgxU=.193aa5c9-ea9b-4afb-8327-6010e157b259@github.com>
 <OXd_pMr-eW6PviQpZSnYZgts-cZYyAZGr5sb77_041Y=.f32d9b10-ac08-42f2-8195-871ac895d9ff@github.com>
Message-ID: <G8qp23qkovVJvCVZ_R81PzCSYTBbutzG5b8rLJtVIR8=.26a3d4a8-8ed1-4781-a81b-7af7a64999fe@github.com>

On Sat, 25 Dec 2021 16:10:37 GMT, Markus KARG <duke at openjdk.java.net> wrote:

>> This sub-issue defines the work to be done to implement JDK-8265891 solely for the particular case of FileChannel.transferFrom(ReadableByteChannel), including special treatment of SelectableByteChannel.
>
> Markus KARG has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - separate test class for each large file test
>  - Base class only contains utilities and helpers
>  - Renamed AbstractTransferTo to TransferToBase as it is not abstract

Please keep this PR open; I will continune work on it soon.

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

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

From aturbanov at openjdk.java.net  Mon Jun 13 09:24:49 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Mon, 13 Jun 2022 09:24:49 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
 <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
Message-ID: <7Jco1zBSxc2k6TxyqfkiPNACk12zryXZdSIX03kXHmQ=.27c2fda4-7f40-47b2-8698-e5dfbee378e1@github.com>

On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>> <details>
>> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
>> 
>> 
>> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Fork(1)
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class TimeUnitBench {
>> 
>>     static final int SIZE = TimeUnit.values().length * 10;
>> 
>>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>>     int bias;
>> 
>>     TimeUnit[] mod;
>> 
>>     @Setup
>>     public void setup() {
>>         mod = new TimeUnit[SIZE];
>> 
>>         TimeUnit[] vals = TimeUnit.values();
>>         for (int c = 0; c < SIZE; c++) {
>>             if (bias == -1) {
>>                 // megamorphic
>>                 mod[c] = vals[c % vals.length];
>>             } else {
>>                 mod[c] = vals[bias];
>>             }
>>         }
>> 
>>         Random r = new Random();
>>         for (int c = 0; c < 10000; c++) {
>>             int i = r.nextInt();
>>             for (int o = 0; o < vals.length; o++) {
>>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>>                     throw new IllegalStateException("switch " + o);
>>             }
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu, 1L));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu, 1L));
>>         }
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu) {
>>         return tu.toNanos(1L);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu, long value) {
>>         return tu.toNanos(value);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu) {
>>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu, long value) {
>>         return TimeUnit.NANOSECONDS.convert(value, tu);
>>     }
>> }
>> 
>> Results:
>> 
>> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
>> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
>> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
>> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
>> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
>> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
>> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
>> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
>> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
>> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
>> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
>> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
>> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
>> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
>> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
>> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
>> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
>> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
>> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
>> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
>> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
>> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
>> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
>> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
>> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
>> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
>> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
>> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
>> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
>> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
>> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
>> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
>> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
>> 
>> 
>> </details>
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
>    
>    # Conflicts:
>    #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
>    #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
>  - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

Still hope to merge it :)

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

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

From alanb at openjdk.java.net  Tue Jun 14 06:45:47 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 06:45:47 GMT
Subject: RFR: 8287889: (fs) Files.copy description of REPLACE_EXISTING is
 hard to read
In-Reply-To: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
References: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
Message-ID: <FC3ZAKq8DtNqqtUSdwctJwcOB6WyyVRTvR_jqrDRLZU=.ebf4ee92-b2fe-4c7c-b649-ad4a1f705107@github.com>

On Mon, 13 Jun 2022 18:40:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`.

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.java.net  Tue Jun 14 17:57:04 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 14 Jun 2022 17:57:04 GMT
Subject: RFR: 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard
 to read
Message-ID: <QYQWBvWF6JWWDhNT2O_ROLzjgD1PpN6uB9KCjJIKfLk=.57d036f7-a795-491b-b9fd-6569af2f8a1e@github.com>

Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`. This supersedes https://github.com/openjdk/jdk/pull/9142.

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

Commit messages:
 - 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read

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

PR: https://git.openjdk.org/jdk19/pull/16

From alanb at openjdk.java.net  Tue Jun 14 17:57:09 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Tue, 14 Jun 2022 17:57:09 GMT
Subject: RFR: 8287889: (fs) Files.copy description of REPLACE_EXISTING is
 hard to read
In-Reply-To: <QYQWBvWF6JWWDhNT2O_ROLzjgD1PpN6uB9KCjJIKfLk=.57d036f7-a795-491b-b9fd-6569af2f8a1e@github.com>
References: <QYQWBvWF6JWWDhNT2O_ROLzjgD1PpN6uB9KCjJIKfLk=.57d036f7-a795-491b-b9fd-6569af2f8a1e@github.com>
Message-ID: <CPxrDOf1xIlctNMYwk1rx7yE463rwDASQ0R3zfZ5mvg=.a66de54a-84a4-4075-b573-31baf7e678d2@github.com>

On Tue, 14 Jun 2022 17:44:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`. This supersedes https://github.com/openjdk/jdk/pull/9142.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/16

From bpb at openjdk.java.net  Tue Jun 14 17:57:29 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 14 Jun 2022 17:57:29 GMT
Subject: RFR: 8287889: (fs) Files.copy description of REPLACE_EXISTING is
 hard to read
In-Reply-To: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
References: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
Message-ID: <24HZnD_jOalrrpN4Bypf7TLOSMT9ScfazoUg3nRiUr8=.daa40625-f8da-49e9-934f-af5ab774fe3b@github.com>

On Mon, 13 Jun 2022 18:40:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`.

This PR is superseded by https://github.com/openjdk/jdk19/pull/16.

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

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

From bpb at openjdk.java.net  Tue Jun 14 17:57:31 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 14 Jun 2022 17:57:31 GMT
Subject: Withdrawn: 8287889: (fs) Files.copy description of REPLACE_EXISTING is
 hard to read
In-Reply-To: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
References: <VA2XrmjoH9D7l5GTD9lpO46inPBNUJ4YK0YNZu4PqmA=.88d21543-ffa5-4526-8c54-a90c4e31b3bb@github.com>
Message-ID: <w177eR8hyHnwjB02lmPaic_sNtxAwwGHA72db7bYBoM=.379fac37-2856-49c3-a9bd-263178695836@github.com>

On Mon, 13 Jun 2022 18:40:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.java.net  Tue Jun 14 18:04:57 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Tue, 14 Jun 2022 18:04:57 GMT
Subject: Integrated: 8287889: (fs) Files.copy description of REPLACE_EXISTING
 is hard to read
In-Reply-To: <QYQWBvWF6JWWDhNT2O_ROLzjgD1PpN6uB9KCjJIKfLk=.57d036f7-a795-491b-b9fd-6569af2f8a1e@github.com>
References: <QYQWBvWF6JWWDhNT2O_ROLzjgD1PpN6uB9KCjJIKfLk=.57d036f7-a795-491b-b9fd-6569af2f8a1e@github.com>
Message-ID: <0MkO1XdFrTLHxQylwkcFQlHSANkYVGQHjb9a1tnWO9o=.2d260468-f78b-4f44-a214-e0c86eff0082@github.com>

On Tue, 14 Jun 2022 17:44:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Clarify the descriptions of the use of `java.nio.file.StandardCopyOption.REPLACE_EXISTING` in the `copy(Path,Path)` and `move(Path,Path)` methods of `java.nio.file.Files`. This supersedes https://github.com/openjdk/jdk/pull/9142.

This pull request has now been integrated.

Changeset: 5a8e1e43
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/5a8e1e43a4436e6537fc96cfea4ea47d4a958c35
Stats:     8 lines in 1 file changed: 0 ins; 2 del; 6 mod

8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read

Reviewed-by: alanb

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

PR: https://git.openjdk.org/jdk19/pull/16

From aturbanov at openjdk.java.net  Tue Jun 14 19:25:57 2022
From: aturbanov at openjdk.java.net (Andrey Turbanov)
Date: Tue, 14 Jun 2022 19:25:57 GMT
Subject: RFR: 8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX
 [v2]
In-Reply-To: <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
 <-HXGIdvip8kNCtVfJk4nceMYxRjst0UkmuVkvWXEtr8=.9e0636d1-8ade-4052-8f05-a42def897bed@github.com>
Message-ID: <DyX_SjE0GlnNOFk7sZJYVn75SF-BZXxUrY5vGJ8EukM=.d0672f32-a1ba-4f69-92bc-088856da0948@github.com>

On Sun, 15 May 2022 10:31:20 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
>> Compared via JMH benchmark: 150ns -> 125ns/op
>> <details>
>> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
>> 
>> 
>> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
>> @Fork(1)
>> @State(Scope.Thread)
>> @BenchmarkMode(Mode.AverageTime)
>> @OutputTimeUnit(TimeUnit.NANOSECONDS)
>> public class TimeUnitBench {
>> 
>>     static final int SIZE = TimeUnit.values().length * 10;
>> 
>>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>>     int bias;
>> 
>>     TimeUnit[] mod;
>> 
>>     @Setup
>>     public void setup() {
>>         mod = new TimeUnit[SIZE];
>> 
>>         TimeUnit[] vals = TimeUnit.values();
>>         for (int c = 0; c < SIZE; c++) {
>>             if (bias == -1) {
>>                 // megamorphic
>>                 mod[c] = vals[c % vals.length];
>>             } else {
>>                 mod[c] = vals[bias];
>>             }
>>         }
>> 
>>         Random r = new Random();
>>         for (int c = 0; c < 10000; c++) {
>>             int i = r.nextInt();
>>             for (int o = 0; o < vals.length; o++) {
>>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>>                     throw new IllegalStateException("switch " + o);
>>             }
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_convert(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_convert(tu, 1L));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void const_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu));
>>         }
>>     }
>> 
>>     @Benchmark
>>     public void value_toNanos(Blackhole bh) {
>>         for (TimeUnit tu : mod) {
>>             bh.consume(do_toNanos(tu, 1L));
>>         }
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu) {
>>         return tu.toNanos(1L);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_toNanos(TimeUnit tu, long value) {
>>         return tu.toNanos(value);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu) {
>>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>>     }
>> 
>>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>>     private long do_convert(TimeUnit tu, long value) {
>>         return TimeUnit.NANOSECONDS.convert(value, tu);
>>     }
>> }
>> 
>> Results:
>> 
>> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
>> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
>> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
>> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
>> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
>> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
>> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
>> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
>> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
>> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
>> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
>> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
>> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
>> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
>> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
>> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
>> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
>> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
>> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
>> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
>> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
>> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
>> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
>> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
>> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
>> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
>> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
>> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
>> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
>> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
>> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
>> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
>> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
>> 
>> 
>> </details>
>
> Andrey Turbanov has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains two commits:
> 
>  - Merge remote-tracking branch 'origin/master' into Use_direct_TimeUnit.toSome_instead_of_TimeUnit.convert
>    
>    # Conflicts:
>    #	src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java
>    #	src/java.base/unix/classes/sun/nio/ch/PollSelectorImpl.java
>  - [PATCH] Simplify TimeUnit.convert calls to TimeUnit.toSomething instead

src/jdk.jfr/share/classes/jdk/jfr/internal/Utils.java line 328:

> 326:         }
> 327:         if (s.endsWith("h")) {
> 328:             return HOURS.toNanos(Long.parseLong(s.substring(0, s.length() - 1).trim()));

May be some JFR experts know, why there was manual multiplication before?

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

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

From bpb at openjdk.java.net  Wed Jun 15 00:30:19 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 00:30:19 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned
Message-ID: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>

Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

Commit messages:
 - 6980847: (fs) Files.copy needs to be tuned

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

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

From bpb at openjdk.java.net  Wed Jun 15 00:30:19 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 00:30:19 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <CoJ8FHibH8-KeNedSQsI2USvhpkHMUEieG7Z0NH1zls=.16d2176e-4d64-4f54-80e2-159880f8d8fe@github.com>

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

The value of the threshold used to determine whether `COPY_FILE_NO_BUFFERING` is added to the `copyFlags` parameter of `CopyFileEx()` was determined empirically. An alternative to having a fixed threshold would be to set the threshold dynamically as some fraction of the file system cache [maximum size](https://docs.microsoft.com/en-us/windows/win32/api/memoryapi/nf-memoryapi-getsystemfilecachesize), if set, or of the system [total memory](https://download.java.net/java/early_access/jdk19/docs/api/jdk.management/com/sun/management/OperatingSystemMXBean.html#getTotalMemorySize()).

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

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

From alanb at openjdk.java.net  Wed Jun 15 12:27:13 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Wed, 15 Jun 2022 12:27:13 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <0qmEjp8da4LfC0VAn-9WclN0pVq1iBmaeZLQlRI0h7A=.0dee2ceb-28c0-4bc6-8676-9d13f4ec54bc@github.com>

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

> 274:                     long bss = Files.getFileStore(source).getBlockSize();
> 275:                     long bst = Files.getFileStore(target).getBlockSize();
> 276:                     if (bss > 0 && bst > 0) {

This should be UnixFileStoreAttributes.get(source).blockSize() to avoid calling from the provider to the API or needing to create a FileStore.

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

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I think this looks good overall, but please try to limit the accessibility of  the methods in `State`.

src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:

> 38:  * operations triggered by threads other than the owner thread, which we support.
> 39:  */
> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {

Same here. I don't see why this is made public now.

src/java.base/share/classes/jdk/internal/foreign/SharedSessionState.java line 46:

> 44:  * checking the liveness bit upon access can be performed in plain mode, as in the confined case.
> 45:  */
> 46: public class SharedSessionState extends MemorySessionImpl.State {

Unclear to me why this is now public. It still seems to be only accessed from with the `jdk.internal.foreign` package?

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

Marked as reviewed by jvernee (Reviewer).

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

From jvernee at openjdk.java.net  Wed Jun 15 14:58:25 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 14:58:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <NNFbp2rnfsp4-twI5e8a6s9kxqklOnUaInu5fAEUr0o=.a87e3023-0dd0-4b29-86b0-38ed8efd4883@github.com>

On Wed, 15 Jun 2022 14:41:17 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'master' into cleanup_memory_session_impl_state
>>  - Add null check on Buffer::checkState
>>  - Add docs
>>    Simplify liveness check in Buffer
>>    Drop redundant import in DirectBuffer
>>  - Simplify checkValidState
>>  - Add fastpath for implicit session state
>>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>>  - Fix asNonCloseable to return self
>>    Improve direct buffer code with isImplicit predicate
>>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>>  - Simplify readOnly check
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246
>
> src/java.base/share/classes/jdk/internal/foreign/ConfinedSessionState.java line 40:
> 
>> 38:  * operations triggered by threads other than the owner thread, which we support.
>> 39:  */
>> 40: public final class ConfinedSessionState extends MemorySessionImpl.State {
> 
> Same here. I don't see why this is made public now.

Same for `justClose` and `ConfinedList::add` in this file. They still seem only accessed in the same package.

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

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

From rriggs at openjdk.java.net  Wed Jun 15 15:36:59 2022
From: rriggs at openjdk.java.net (Roger Riggs)
Date: Wed, 15 Jun 2022 15:36:59 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <8KySoXHwysCMgL1rwRzRrwMAVohgYQw-hNvkYk8kvHM=.6b96259d-01e2-43b6-863e-3555a8a41fea@github.com>

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

> 230: 
> 231:         while (u != v) {
> 232:             if (u < v)

It might be worth a comment about the expected inputs so it is known to converge quickly.
In the general case it might wrap around and go unstable.

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

> 662:     // -- native methods --
> 663: 
> 664:     static native long transferSize0();

If the `transferSize` is fixed, there seems to be little reason to call native to retrieve it.
(Perhaps hoping for the OS to provide it.)

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

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

From bpb at openjdk.java.net  Wed Jun 15 16:00:16 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 16:00:16 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v2]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <TueHtrtYCK3YuMYzLIiLVaebw-tpEAyUh3PwT1PVAn4=.fbd2c13a-4d6a-4b1b-80e3-dd94c7a90d6c@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: 1) use UnixFileStoreAttributes.get(file).blockSize(); 2) use @Native instead of transferSize0()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/ce276522..f151dc4c

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

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

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

From bpb at openjdk.java.net  Wed Jun 15 16:00:26 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 16:00:26 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v2]
In-Reply-To: <8KySoXHwysCMgL1rwRzRrwMAVohgYQw-hNvkYk8kvHM=.6b96259d-01e2-43b6-863e-3555a8a41fea@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <8KySoXHwysCMgL1rwRzRrwMAVohgYQw-hNvkYk8kvHM=.6b96259d-01e2-43b6-863e-3555a8a41fea@github.com>
Message-ID: <AovXJm0ekS01rMy4BdJn-vhoTC3zzwYQU3Cp92wkhG4=.f23337e2-c468-494e-9acb-4ca56559698a@github.com>

On Wed, 15 Jun 2022 15:26:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: 1) use UnixFileStoreAttributes.get(file).blockSize(); 2) use @Native instead of transferSize0()
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 232:
> 
>> 230: 
>> 231:         while (u != v) {
>> 232:             if (u < v)
> 
> It might be worth a comment about the expected inputs so it is known to converge quickly.
> In the general case it might wrap around and go unstable.

Comment added in f151dc4cf6f4e59fff2d2a0f486929940cafb1ae.

> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 664:
> 
>> 662:     // -- native methods --
>> 663: 
>> 664:     static native long transferSize0();
> 
> If the `transferSize` is fixed, there seems to be little reason to call native to retrieve it.
> (Perhaps hoping for the OS to provide it.)

I realized that myself and was already changing it when this comment appeared. Fixed in f151dc4cf6f4e59fff2d2a0f486929940cafb1ae.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 16:55:06 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 16:55:06 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
 <VCF65iVOSZ7WaKWkInmRlB3Iu6GdxGe3hM0g3wBW0Vc=.c56d3f27-73a0-4d10-bfa3-76de0ab719fc@github.com>
Message-ID: <lTNs91mKp3yK6ux1HoGYYanROrJMGgwBs_ykF-Us-8Q=.d7350e59-cfa0-4cbe-8d33-fd97e24a4a47@github.com>

On Wed, 15 Jun 2022 14:55:56 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> I think this looks good overall, but please try to limit the accessibility of the methods in `State`.

Thanks, I'll take another look

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

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

From bpb at openjdk.java.net  Wed Jun 15 17:52:13 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 17:52:13 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v3]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <wZI-VUjYD_GHnx2Yc-eC-2eTWyguUYT362tZP6uFcjs=.55669d21-eee0-49fa-8976-581c56da39c2@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Remove unnecessary catch of SecurityException and UnsupportedOperationException which are not thrown by blockSize()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/f151dc4c..bc4096c6

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

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

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

From bpb at openjdk.java.net  Wed Jun 15 17:52:15 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Wed, 15 Jun 2022 17:52:15 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v3]
In-Reply-To: <0qmEjp8da4LfC0VAn-9WclN0pVq1iBmaeZLQlRI0h7A=.0dee2ceb-28c0-4bc6-8676-9d13f4ec54bc@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <0qmEjp8da4LfC0VAn-9WclN0pVq1iBmaeZLQlRI0h7A=.0dee2ceb-28c0-4bc6-8676-9d13f4ec54bc@github.com>
Message-ID: <GEX1Mqvc6N9FDRQhgv0ztFBLtygh-caeMeV0_5humwo=.84d624bb-fd66-40c8-a128-260a0cd87978@github.com>

On Wed, 15 Jun 2022 12:17:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: Remove unnecessary catch of SecurityException and UnsupportedOperationException which are not thrown by blockSize()
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 276:
> 
>> 274:                     long bss = Files.getFileStore(source).getBlockSize();
>> 275:                     long bst = Files.getFileStore(target).getBlockSize();
>> 276:                     if (bss > 0 && bst > 0) {
> 
> This should be UnixFileStoreAttributes.get(source).blockSize() to avoid calling from the provider to the API or needing to create a FileStore.

Fixed in bc4096c6cd4f1a060a8cacb154ac090c98f94aa3.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:31 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:31 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <N43DTnhrT-MpOW5fxbWyn5r2x7Fbn0MEZGYREvuCKAQ=.67761ec2-83ef-46c9-a54e-d0487fc233c5@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

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

  Address review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9017/files
  - new: https://git.openjdk.org/jdk/pull/9017/files/5b8f7246..67710665

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

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:52:34 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:52:34 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
 <onkwP5d4aPF60FdRsDPY_Bs7414DFE60QKob192eRBU=.c98b1354-fe71-491e-b6c9-bcef0dfacc7d@github.com>
Message-ID: <WOeSkpiMEWFdfq24NPuKr1MkRsC-2KyWl7-xBTVhinY=.cedef75d-3936-4ef1-ba65-a24f579ac63e@github.com>

On Tue, 7 Jun 2022 13:00:37 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
>> 
>> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
>> 
>> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'master' into cleanup_memory_session_impl_state
>  - Add null check on Buffer::checkState
>  - Add docs
>    Simplify liveness check in Buffer
>    Drop redundant import in DirectBuffer
>  - Simplify checkValidState
>  - Add fastpath for implicit session state
>  - Merge branch 'master' into cleanup_memory_session_impl_keep_list
>  - Fix asNonCloseable to return self
>    Improve direct buffer code with isImplicit predicate
>  - Drop MemorySession interface type from AbstractMemorySessionImpl
>  - Simplify code by removing intermediate getUnsafeBase/getUnsafeOffset methods
>  - Simplify readOnly check
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/8d28734e...5b8f7246

I'm going to close this PR and re-open another against the 19 repo.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 17:54:39 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 17:54:39 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <45yAEXwPWvEqPT03oBHaJgH9HANer_iQ1uDSNGELoiA=.a1e6ee75-275e-407c-a8ce-355f54fab41f@github.com>

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Address review comments
 - Merge branch 'master' into cleanup_memory_session_impl_state
 - Add null check on Buffer::checkState
 - Add docs
   Simplify liveness check in Buffer
   Drop redundant import in DirectBuffer
 - Simplify checkValidState
 - Add fastpath for implicit session state
 - Merge branch 'master' into cleanup_memory_session_impl_keep_list
 - Fix asNonCloseable to return self
   Improve direct buffer code with isImplicit predicate
 - Drop MemorySession interface type from AbstractMemorySessionImpl
 - ... and 6 more: https://git.openjdk.org/jdk/compare/13d4ddc3...b1a494e4

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

Changes: https://git.openjdk.org/jdk/pull/9017/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9017&range=03
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk/pull/9017.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9017/head:pull/9017

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:01:08 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:01:08 GMT
Subject: Withdrawn: 8287809: Revisit implementation of memory session
In-Reply-To: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
References: <JU9OhpZ7_uUTPf5Uamk1mgyFu--64jKuNeGFmnkZeqQ=.d480f245-695b-482d-b007-c33b6f035714@github.com>
Message-ID: <68QEAhgjPyyQCGZ7bKIm4b_sNlrxfpUWblsB5miSHy8=.22c49980-caba-4fd0-87a9-851ee63dadfd@github.com>

On Fri, 3 Jun 2022 15:47:21 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a cleanup of the memory session implementation. The main new concept is that `MemorySessionImpl` is split into two parts: there is an implementation of memory session and then there is a state abstraction (`MemorySessionImpl.State`). This allows to share the state across multiple session views, in a more clean way. The big consequence of this change is that the routines on `ScopedMemoryAccess` now have to be defined in terms of the state abstraction (but the changes are mostly mechanical).
> 
> I have consolidated the implementation quite a bit, by removing all the duplicated logic for issuing similar-looking exceptions. I have also addressed an issue with `checkValidState` throwing a _new_ `WrongThreadException` instead of using a singleton (which is what the logic for closing down shared session requires, to avoid stack walks that are too deep).
> 
> `MemorySession.State::checkValidState` is now fully monomorphic; when looking at benchmarks, this seems to be the best solution in order to make things fast. Specializing implmentations to remove few plain checks does not buy enough, and always has the risk of adding profile pollution.

This pull request has been closed without being integrated.

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

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

From mcimadamore at openjdk.java.net  Wed Jun 15 18:16:21 2022
From: mcimadamore at openjdk.java.net (Maurizio Cimadamore)
Date: Wed, 15 Jun 2022 18:16:21 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
Message-ID: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>

This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

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

Commit messages:
 - Add missing files
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287809
  Stats: 1751 lines in 39 files changed: 407 ins; 525 del; 819 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From ecki at zusammenkunft.net  Wed Jun 15 20:46:37 2022
From: ecki at zusammenkunft.net (Bernd Eckenfels)
Date: Wed, 15 Jun 2022 20:46:37 +0000
Subject: RFR: .: (fs) Files.copy needs to be tuned
In-Reply-To: <0qmEjp8da4LfC0VAn-9WclN0pVq1iBmaeZLQlRI0h7A=.0dee2ceb-28c0-4bc6-8676-9d13f4ec54bc@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <0qmEjp8da4LfC0VAn-9WclN0pVq1iBmaeZLQlRI0h7A=.0dee2ceb-28c0-4bc6-8676-9d13f4ec54bc@github.com>
Message-ID: <AM9P193MB1142B44C32224CABAF9D0400FFAD9@AM9P193MB1142.EURP193.PROD.OUTLOOK.COM>

Hello,

Normally using static bigger buffers like 16k or 64k reduce the syscall and pagefault overhead (and it?s a pretty sure multiple of all important block sizes without any math or without much loss). It also helps the IO scheduler to asume a streaming read for read ahead detecting if the read req quests are multiple of the blocksize. By limiting it to a single block that might actually be a disadvantage on some combinations.

Lcm, For 12k and 16k it turns out to be 48k, but for 8k->4k it would still read with 8k. Maybe add a step of the result is < 16 then trippel it?

Since windows disables page cache for larger files, on Linux we could also work with posix_fadvice(POSIX_FADV_SEQUENTIAL|WIlLNEED(|DONTREUSE)) or using readahead() to request multiple blocks (but we mentioned just using a larger read buffer usually does the trick portably).

The bug talks about NFS in particular, what will the unix attribute return for nfs servers, is it the buffer size? Can you share numbers? (And does the benchmark compare it about blocking io?)

Gruss
Bernd
--
http://bernd.eckenfels.net
________________________________
Von: nio-dev <nio-dev-retn at mail.openjdk.org> im Auftrag von Alan Bateman <alanb at openjdk.java.net>
Gesendet: Wednesday, June 15, 2022 2:27:13 PM
An: nio-dev at openjdk.java.net <nio-dev at openjdk.java.net>
Betreff: Re: RFR: 6980847: (fs) Files.copy needs to be tuned

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

> 274:                     long bss = Files.getFileStore(source).getBlockSize();
> 275:                     long bst = Files.getFileStore(target).getBlockSize();
> 276:                     if (bss > 0 && bst > 0) {

This should be UnixFileStoreAttributes.get(source).blockSize() to avoid calling from the provider to the API or needing to create a FileStore.

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

PR: https://git.openjdk.org/jdk/pull/9161
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220615/b67563e4/attachment.htm>

From jvernee at openjdk.java.net  Wed Jun 15 22:30:09 2022
From: jvernee at openjdk.java.net (Jorn Vernee)
Date: Wed, 15 Jun 2022 22:30:09 GMT
Subject: RFR: 8287809: Revisit implementation of memory session
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <U4NNFOHiB-6BybfOYNa3eluBB_n05D2jZlLgjcx9G-4=.f929fc9d-2990-474d-81c4-ebdad836bb5a@github.com>

On Wed, 15 Jun 2022 18:06:44 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a JDK 19 clone of: https://github.com/openjdk/jdk/pull/9017

Already reviewed in the mainline repo.

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

Marked as reviewed by jvernee (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/22

From bpb at openjdk.java.net  Thu Jun 16 01:40:03 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 16 Jun 2022 01:40:03 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v3]
In-Reply-To: <wZI-VUjYD_GHnx2Yc-eC-2eTWyguUYT362tZP6uFcjs=.55669d21-eee0-49fa-8976-581c56da39c2@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <wZI-VUjYD_GHnx2Yc-eC-2eTWyguUYT362tZP6uFcjs=.55669d21-eee0-49fa-8976-581c56da39c2@github.com>
Message-ID: <5-dgQ0fGurOlJxJn9jj0ysQigHQ-RpcNk-dKvZVuIrg=.5b9dd836-f90e-426e-90d3-650333f792ae@github.com>

On Wed, 15 Jun 2022 17:52:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Remove unnecessary catch of SecurityException and UnsupportedOperationException which are not thrown by blockSize()

Responding to [Bernd's comments](https://mail.openjdk.org/pipermail/nio-dev/2022-June/011466.html).

It has been observed before that a larger buffer can increase throughput so increasing the minimum transfer size here seems reasonable. I don?t think it would be bad to increase it to 16K. Perhaps do something like the following where `TRANSFER_SIZE` is 16384 instead of 8192

if (transferSize < TRANSFER_SIZE) {
    int factor = (int)((TRANSFER_SIZE + transferSize - 1)/transferSize);
    transferSize *= factor;
}

which will probably always compute 16384.

I think that

int advice = POSIX_FADV_SEQUENTIAL | POSIX_FADV_NOREUSE | POSIX_FADV_WILLNEED;
posix_fadvise(src, 0, 0, advice);

is a good idea.

Several mentions online state that `st_blksize` for an NFS server is the page size, but local testing shows it to be the block size of the mounted disk.

Not much benchmark work was done on this topic except on Windows which was to determine the no-buffering threshold. I went back and generated some numbers today. `patch1` is as of the third commit, `patch2` as of the fourth which I will push shortly.

==> ../master.txt <==
Benchmark      (length)   Mode  Cnt      Score      Error  Units
CopyFile.copy     10000  thrpt   10  32685.396 ? 1623.472  ops/s
CopyFile.copy    100000  thrpt   10  11660.298 ?  156.204  ops/s
CopyFile.copy   1000000  thrpt   10   1504.661 ?   15.264  ops/s
CopyFile.copy  10000000  thrpt   10    118.880 ?    5.999  ops/s

==> ../patch1.txt <==
Benchmark      (length)   Mode  Cnt      Score     Error  Units
CopyFile.copy     10000  thrpt   10  30343.618 ? 955.469  ops/s
CopyFile.copy    100000  thrpt   10  11295.039 ? 102.986  ops/s
CopyFile.copy   1000000  thrpt   10   1490.852 ?  19.018  ops/s
CopyFile.copy  10000000  thrpt   10    111.626 ?   2.392  ops/s

==> ../patch2-no-fadvise.txt <==
Benchmark      (length)   Mode  Cnt      Score     Error  Units
CopyFile.copy     10000  thrpt   10  31743.019 ? 974.794  ops/s
CopyFile.copy    100000  thrpt   10  12295.192 ? 187.331  ops/s
CopyFile.copy   1000000  thrpt   10   1656.561 ?  23.102  ops/s
CopyFile.copy  10000000  thrpt   10    122.700 ?   1.783  ops/s

==> ../patch2.txt <==
Benchmark      (length)   Mode  Cnt      Score     Error  Units
CopyFile.copy     10000  thrpt   10  31735.385 ? 374.000  ops/s
CopyFile.copy    100000  thrpt   10  12049.334 ? 112.960  ops/s
CopyFile.copy   1000000  thrpt   10   1664.070 ?  33.637  ops/s
CopyFile.copy  10000000  thrpt   10    121.623 ?   1.258  ops/s

It looks like having the minimum transfer size be 16384 is helpful; `fadvise()` does not do much here.

Please note that the transfer by read-write loop is rather an edge case: it is never used on macOS, and on Linux only if sendfile() fails. It is however the only code path on other Unix variants.

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

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

From bpb at openjdk.java.net  Thu Jun 16 01:44:02 2022
From: bpb at openjdk.java.net (Brian Burkhalter)
Date: Thu, 16 Jun 2022 01:44:02 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v4]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <7o-0JCKW0moX-wjB6xNi6WJL6wV_X4ceLHgaW8F_1_A=.a0abe65d-a03b-4673-838b-3480aa5b2e08@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Impose minimum transfer size of 16384; add posix_fadvise() on Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/bc4096c6..0a77bd26

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

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

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

From alanb at openjdk.java.net  Thu Jun 16 06:27:06 2022
From: alanb at openjdk.java.net (Alan Bateman)
Date: Thu, 16 Jun 2022 06:27:06 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v3]
In-Reply-To: <5-dgQ0fGurOlJxJn9jj0ysQigHQ-RpcNk-dKvZVuIrg=.5b9dd836-f90e-426e-90d3-650333f792ae@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <wZI-VUjYD_GHnx2Yc-eC-2eTWyguUYT362tZP6uFcjs=.55669d21-eee0-49fa-8976-581c56da39c2@github.com>
 <5-dgQ0fGurOlJxJn9jj0ysQigHQ-RpcNk-dKvZVuIrg=.5b9dd836-f90e-426e-90d3-650333f792ae@github.com>
Message-ID: <YQEaKGxEh0In83kwr--O04F37L_kdE1yvnAhPUxxPpw=.c7bad0f0-4204-4c19-b02a-7680e36e5baa@github.com>

On Thu, 16 Jun 2022 01:36:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It has been observed before that a larger buffer can increase throughput so increasing the minimum transfer size here seems reasonable. I don?t think it would be bad to increase it to 16K. Perhaps do something like the following where `TRANSFER_SIZE` is 16384 instead of 8192

Changing this code to use 16k of stack could have wider impact. I think we should prototype changing UnixCopyFile to use TL buffer cache rather than increasing stack usage or using malloc.

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

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

From jwilhelm at openjdk.java.net  Thu Jun 16 07:09:00 2022
From: jwilhelm at openjdk.java.net (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 07:09:00 GMT
Subject: RFR: Merge jdk19
Message-ID: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge
 - 8288533: Missing @param tags in com.sun.source classes
 - 8288526: ProblemList gc/stress/TestStressG1Humongous.java on windows-x64
 - 8288414: Long::compress/expand samples are not correct
 - 8288289: Preview APIs in jdk.jdi, jdk.management, and jdk.jfr should be reflective preview APIs
 - 8288324: Loom: Uninitialized JvmtiEnvs in VM_Virtual* ops
 - 8288360: CI: ciInstanceKlass::implementor() is not consistent for well-known classes
 - 8287889: (fs) Files.copy description of REPLACE_EXISTING is hard to read
 - 8288303: C1: Miscompilation due to broken Class.getModifiers intrinsic
 - 8288214: serviceability/jvmti/vthread/VThreadNotifyFramePopTest/VThreadNotifyFramePopTest.java test failed
 - ... and 1 more: https://git.openjdk.org/jdk/compare/39526e28...8b43a607

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9179&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9179/files
  Stats: 254 lines in 17 files changed: 193 ins; 13 del; 48 mod
  Patch: https://git.openjdk.org/jdk/pull/9179.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9179/head:pull/9179

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

From redestad at openjdk.org  Thu Jun 16 09:38:07 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 16 Jun 2022 09:38:07 GMT
Subject: RFR: 8287904: Reduce runtime of java.net microbenchmarks
Message-ID: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>

- Remove a couple of benchmarks with very high, environment-dependent variance (not improved by increasing warmup)
- Reduce number of parameters, forks, iterations to improve runtime without sacrificing much data quality 
- Fix one broken microbenchmark (`NetworkInterfaceLookup`) that reflects into encapsulated internals without explicitly opening the package.

Estimated runtime reduced from 10h38m to 1h35m

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

Commit messages:
 - Merge branch 'master' into micro_runtime_jnet
 - Reduce configurations, remove very noisy benchmarks
 - Reduce runtime of java.net microbenchmarks

Changes: https://git.openjdk.org/jdk/pull/9182/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9182&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8287904
  Stats: 432 lines in 13 files changed: 53 ins; 374 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/9182.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9182/head:pull/9182

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

From redestad at openjdk.org  Thu Jun 16 10:04:03 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 16 Jun 2022 10:04:03 GMT
Subject: RFR: 8287905: Reduce runtime of java.nio microbenchmarks
Message-ID: <lBGP4buzupKGqVB-pRWaOZPoGdAGjvamnRfGly7aBS4=.c3ff9b7f-6c39-4903-b37d-46cec8582227@github.com>

Reduce runtime by reducing number of forks, iterations..

Most benchmarks in the java.nio packages already had sensible configuration, so this reduces estimated runtime by a small amount (~5h42m -> ~5s03m)

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

Commit messages:
 - Reduce runtime java.nio

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

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

From jwilhelm at openjdk.org  Thu Jun 16 12:05:20 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Thu, 16 Jun 2022 12:05:20 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
References: <3ke8kqVmpxVV01b8rL7MU8DWpDvHrqBHC7Oj4O83c5g=.dafbc6b1-9798-4182-bbbb-cbb5f035586d@github.com>
Message-ID: <jE5ZH0NidXVkm_bPpXtl0UPI_FXUl9NK5fQyfDq6Cvg=.57654ad5-3d0b-4019-a178-2777c19d9611@github.com>

On Thu, 16 Jun 2022 07:00:53 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 3d12c022
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3d12c0225b31bb359bec70aac6befd879cd0c934
Stats:     254 lines in 17 files changed: 193 ins; 13 del; 48 mod

Merge

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

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

From jvernee at openjdk.org  Thu Jun 16 13:54:14 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Jun 2022 13:54:14 GMT
Subject: RFR: 8287905: Reduce runtime of java.nio microbenchmarks
In-Reply-To: <lBGP4buzupKGqVB-pRWaOZPoGdAGjvamnRfGly7aBS4=.c3ff9b7f-6c39-4903-b37d-46cec8582227@github.com>
References: <lBGP4buzupKGqVB-pRWaOZPoGdAGjvamnRfGly7aBS4=.c3ff9b7f-6c39-4903-b37d-46cec8582227@github.com>
Message-ID: <KY60sduwtFhqblXbCkEL2GPkOz7PrD0RhFEYFw33Ynw=.8afa2f9d-0181-40f1-bf87-7710245daa2b@github.com>

On Thu, 16 Jun 2022 09:56:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Reduce runtime by reducing number of forks, iterations..
> 
> Most benchmarks in the java.nio packages already had sensible configuration, so this reduces estimated runtime by a small amount (~5h42m -> ~5s03m)

Marked as reviewed by jvernee (Reviewer).

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

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

From jvernee at openjdk.org  Thu Jun 16 13:55:18 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Jun 2022 13:55:18 GMT
Subject: RFR: 8287904: Reduce runtime of java.net microbenchmarks
In-Reply-To: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
References: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
Message-ID: <LCvepDpy8Mqdcf-u_BKjL6Wu1xVTL1rWvkHoAjptgnw=.162b9ee5-bd6d-499f-931e-339c2fb3c650@github.com>

On Thu, 16 Jun 2022 09:31:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Remove a couple of benchmarks with very high, environment-dependent variance (not improved by increasing warmup)
> - Reduce number of parameters, forks, iterations to improve runtime without sacrificing much data quality 
> - Fix one broken microbenchmark (`NetworkInterfaceLookup`) that reflects into encapsulated internals without explicitly opening the package.
> 
> Estimated runtime reduced from 10h38m to 1h35m

Why the deleted ones?

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

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

From redestad at openjdk.org  Thu Jun 16 15:04:01 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 16 Jun 2022 15:04:01 GMT
Subject: RFR: 8287904: Reduce runtime of java.net microbenchmarks
In-Reply-To: <LCvepDpy8Mqdcf-u_BKjL6Wu1xVTL1rWvkHoAjptgnw=.162b9ee5-bd6d-499f-931e-339c2fb3c650@github.com>
References: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
 <LCvepDpy8Mqdcf-u_BKjL6Wu1xVTL1rWvkHoAjptgnw=.162b9ee5-bd6d-499f-931e-339c2fb3c650@github.com>
Message-ID: <RhhAH-DoZjbo6GKzlG_vgPCFPgfQXmfVrnjWZk0ZPR8=.ca12b9fc-2c34-428b-bebe-59229335e97e@github.com>

On Thu, 16 Jun 2022 13:51:34 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Why the deleted ones?

When I evaluated those they appear to have excessively high run-to-run variance. Sometimes varying integer multiples within the same fork, and more warmup doesn't do much to improve it. There's also some overlap with other benchmarks. Removing reduces coverage marginally, but a benchmark that just produces noise is less than useful.

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

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

From redestad at openjdk.org  Thu Jun 16 15:09:48 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Thu, 16 Jun 2022 15:09:48 GMT
Subject: Integrated: 8287905: Reduce runtime of java.nio microbenchmarks
In-Reply-To: <lBGP4buzupKGqVB-pRWaOZPoGdAGjvamnRfGly7aBS4=.c3ff9b7f-6c39-4903-b37d-46cec8582227@github.com>
References: <lBGP4buzupKGqVB-pRWaOZPoGdAGjvamnRfGly7aBS4=.c3ff9b7f-6c39-4903-b37d-46cec8582227@github.com>
Message-ID: <cEHvO7TVh129PDrpj_HAeXMLr_hUPEf3Kj0gQiReuN4=.1f606a9e-803a-4879-9774-7f447b821162@github.com>

On Thu, 16 Jun 2022 09:56:08 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> Reduce runtime by reducing number of forks, iterations..
> 
> Most benchmarks in the java.nio packages already had sensible configuration, so this reduces estimated runtime by a small amount (~5h42m -> ~5s03m)

This pull request has now been integrated.

Changeset: 8fc8fdca
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8fc8fdca96138df20226972be8e8326237b07788
Stats:     12 lines in 2 files changed: 12 ins; 0 del; 0 mod

8287905: Reduce runtime of java.nio microbenchmarks

Reviewed-by: jvernee

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

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

From jvernee at openjdk.org  Thu Jun 16 15:28:52 2022
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 16 Jun 2022 15:28:52 GMT
Subject: RFR: 8287904: Reduce runtime of java.net microbenchmarks
In-Reply-To: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
References: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
Message-ID: <7rzYOHLza_FKVr3orPVMEWmtS9tDfKQRBosbWI_G0jc=.42f17187-f9e3-4834-92a2-231712b90282@github.com>

On Thu, 16 Jun 2022 09:31:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Remove a couple of benchmarks with very high, environment-dependent variance (not improved by increasing warmup)
> - Reduce number of parameters, forks, iterations to improve runtime without sacrificing much data quality 
> - Fix one broken microbenchmark (`NetworkInterfaceLookup`) that reflects into encapsulated internals without explicitly opening the package.
> 
> Estimated runtime reduced from 10h38m to 1h35m

Marked as reviewed by jvernee (Reviewer).

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

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

From aturbanov at openjdk.org  Thu Jun 16 17:33:48 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 16 Jun 2022 17:33:48 GMT
Subject: Integrated: 8285519: Change usages of TimeUnit.convert to
 TimeUnit.toXXX
In-Reply-To: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
References: <FlO4bNdKn-onqZABzBMX1zWW2Gy-mh3xW5TJ1zzghjk=.910c3ad1-4adf-472d-9c3a-63333008a4cd@github.com>
Message-ID: <G4kUylmuwgF-aleWY5MnVvtcras8GXGv2RVAVyZYKzU=.712f527f-a7d2-4fab-a9a9-11ee32ef539b@github.com>

On Sat, 23 Apr 2022 21:02:50 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> TimeUnit.toMillis/toNanos/toMicros/toSeconds is shorter and a bit faster.
> Compared via JMH benchmark: 150ns -> 125ns/op
> <details>
> <summary>Benchamark adapted from http://cr.openjdk.java.net/~shade/8152083/TimeUnitBench.java</summary>
> 
> 
> @Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)
> @Fork(1)
> @State(Scope.Thread)
> @BenchmarkMode(Mode.AverageTime)
> @OutputTimeUnit(TimeUnit.NANOSECONDS)
> public class TimeUnitBench {
> 
>     static final int SIZE = TimeUnit.values().length * 10;
> 
>     @Param({"0", "1", "2", "3", "4", "5", "6", "-1"})
>     int bias;
> 
>     TimeUnit[] mod;
> 
>     @Setup
>     public void setup() {
>         mod = new TimeUnit[SIZE];
> 
>         TimeUnit[] vals = TimeUnit.values();
>         for (int c = 0; c < SIZE; c++) {
>             if (bias == -1) {
>                 // megamorphic
>                 mod[c] = vals[c % vals.length];
>             } else {
>                 mod[c] = vals[bias];
>             }
>         }
> 
>         Random r = new Random();
>         for (int c = 0; c < 10000; c++) {
>             int i = r.nextInt();
>             for (int o = 0; o < vals.length; o++) {
>                 if (vals[o].toNanos(i) != TimeUnit.NANOSECONDS.convert(i, vals[o]))
>                     throw new IllegalStateException("switch " + o);
>             }
>         }
>     }
> 
>     @Benchmark
>     public void const_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_convert(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_convert(tu, 1L));
>         }
>     }
> 
>     @Benchmark
>     public void const_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu));
>         }
>     }
> 
>     @Benchmark
>     public void value_toNanos(Blackhole bh) {
>         for (TimeUnit tu : mod) {
>             bh.consume(do_toNanos(tu, 1L));
>         }
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu) {
>         return tu.toNanos(1L);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_toNanos(TimeUnit tu, long value) {
>         return tu.toNanos(value);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu) {
>         return TimeUnit.NANOSECONDS.convert(1L, tu);
>     }
> 
>     @CompilerControl(CompilerControl.Mode.DONT_INLINE)
>     private long do_convert(TimeUnit tu, long value) {
>         return TimeUnit.NANOSECONDS.convert(value, tu);
>     }
> }
> 
> Results:
> 
> Benchmark                    (bias)  Mode  Cnt    Score    Error  Units
> TimeUnitBench.const_convert       0  avgt    5  151,856 ? 28,595  ns/op
> TimeUnitBench.const_convert       1  avgt    5  150,720 ? 23,863  ns/op
> TimeUnitBench.const_convert       2  avgt    5  151,432 ? 23,184  ns/op
> TimeUnitBench.const_convert       3  avgt    5  150,959 ? 24,726  ns/op
> TimeUnitBench.const_convert       4  avgt    5  150,966 ? 25,280  ns/op
> TimeUnitBench.const_convert       5  avgt    5  150,976 ? 25,542  ns/op
> TimeUnitBench.const_convert       6  avgt    5  151,118 ? 25,254  ns/op
> TimeUnitBench.const_convert      -1  avgt    5  152,673 ? 29,861  ns/op
> TimeUnitBench.const_toNanos       0  avgt    5  121,296 ? 25,236  ns/op
> TimeUnitBench.const_toNanos       1  avgt    5  121,707 ? 25,364  ns/op
> TimeUnitBench.const_toNanos       2  avgt    5  121,736 ? 25,726  ns/op
> TimeUnitBench.const_toNanos       3  avgt    5  121,822 ? 25,491  ns/op
> TimeUnitBench.const_toNanos       4  avgt    5  121,867 ? 26,090  ns/op
> TimeUnitBench.const_toNanos       5  avgt    5  121,927 ? 25,611  ns/op
> TimeUnitBench.const_toNanos       6  avgt    5  121,821 ? 25,843  ns/op
> TimeUnitBench.const_toNanos      -1  avgt    5  121,923 ? 25,206  ns/op
> TimeUnitBench.value_convert       0  avgt    5  150,525 ? 25,439  ns/op
> TimeUnitBench.value_convert       1  avgt    5  151,098 ? 24,024  ns/op
> TimeUnitBench.value_convert       2  avgt    5  151,259 ? 25,381  ns/op
> TimeUnitBench.value_convert       3  avgt    5  151,030 ? 25,548  ns/op
> TimeUnitBench.value_convert       4  avgt    5  151,290 ? 25,998  ns/op
> TimeUnitBench.value_convert       5  avgt    5  151,006 ? 25,448  ns/op
> TimeUnitBench.value_convert       6  avgt    5  150,945 ? 25,314  ns/op
> TimeUnitBench.value_convert      -1  avgt    5  151,186 ? 25,814  ns/op
> TimeUnitBench.value_toNanos       0  avgt    5  121,556 ? 25,745  ns/op
> TimeUnitBench.value_toNanos       1  avgt    5  123,410 ? 22,323  ns/op
> TimeUnitBench.value_toNanos       2  avgt    5  125,452 ? 26,575  ns/op
> TimeUnitBench.value_toNanos       3  avgt    5  125,297 ? 26,204  ns/op
> TimeUnitBench.value_toNanos       4  avgt    5  125,357 ? 26,085  ns/op
> TimeUnitBench.value_toNanos       5  avgt    5  125,165 ? 26,185  ns/op
> TimeUnitBench.value_toNanos       6  avgt    5  125,536 ? 25,487  ns/op
> TimeUnitBench.value_toNanos      -1  avgt    5  125,460 ? 25,063  ns/op
> 
> 
> </details>

This pull request has now been integrated.

Changeset: e833c1d1
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e833c1d179f926edabb2d40c6c357ab20bba726e
Stats:     24 lines in 4 files changed: 2 ins; 0 del; 22 mod

8285519: Change usages of TimeUnit.convert to TimeUnit.toXXX

Reviewed-by: rriggs

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

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

From bpb at openjdk.org  Thu Jun 16 23:36:34 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Jun 2022 23:36:34 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Use temporary direct buffer for user-space copy

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/0a77bd26..c30a6f0b

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

  Stats: 79 lines in 3 files changed: 37 ins; 13 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/9161.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9161/head:pull/9161

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

From bpb at openjdk.org  Thu Jun 16 23:38:53 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 16 Jun 2022 23:38:53 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <q70iSoOboaM3NJBOhSNlgNxFObmWNraBuNx-PvI5q7k=.a1f5263f-3569-45f5-8850-9708715d2103@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

Benchmark numbers for temporary direct buffers (commit c30a6f0be3f45e30c32fbaf7cbd48ea96ca0e450):

Benchmark      (length)   Mode  Cnt      Score     Error  Units
CopyFile.copy     10000  thrpt   10  31927.639 ? 349.679  ops/s
CopyFile.copy    100000  thrpt   10  12155.232 ? 118.164  ops/s
CopyFile.copy   1000000  thrpt   10   1680.935 ?  36.228  ops/s
CopyFile.copy  10000000  thrpt   10    119.173 ?   1.992  ops/s

These are similar to the measurement of the previous version (commit 0a77bd26e2542f98b42bb65b716738e75f6979bc) but have neither stack nor malloc'ed memory.

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

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

From alanb at openjdk.org  Fri Jun 17 10:58:44 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 10:58:44 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <OVwPBfF2De34TvTJorO2k4tiCDOHUD-fDM9vmCoh1OY=.2aed36b4-207a-4c6d-ad69-6f2d19d1face@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 186:

> 184:             }
> 185:             final int flags = ((!followLinks) ? COPY_FILE_COPY_SYMLINK : 0) |
> 186:                 ((size > UNBUFFERED_IO_THRESHOLD) ? COPY_FILE_NO_BUFFERING : 0);

The size of the source file is already in sourceAttrs.size(), no need to call back into the API to access the file again.

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

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

From alanb at openjdk.org  Fri Jun 17 11:57:10 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 11:57:10 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <YHHkbaBvf4PHlVURFFTn-tFaWjewKhzaqw-kFNBI1IM=.b35fca34-e462-46d7-a6fb-5471ed5aaea2@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 158:

> 156:             if (errno == EINVAL || errno == ENOSYS) {
> 157:                 // Fall back to copying via user-space buffers
> 158:                 char buf[MIN_TRANSFER_SIZE];

We can't have the fallback path using 16k of stack here.

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

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

From alanb at openjdk.org  Fri Jun 17 12:00:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 12:00:59 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <yXXExFfmajDsFbkPAkV9sma24Ixpzp0HDBY-1xyRO4Q=.601dae64-3392-4783-ada9-055ac9376e8a@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

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

> 295:                     } catch (IllegalArgumentException | UnixException ignored) {
> 296:                     }
> 297:                     transferSize = ts;

This code needs to move to a separate method, something like transferSize(source, target).

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

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

From alanb at openjdk.org  Fri Jun 17 12:06:57 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 17 Jun 2022 12:06:57 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <G7AGzonEg8n7oOHdQu2EPonNTOasHQ--d5_4MNygE4E=.7d443371-286a-48d5-ba5a-bcded53fd43f@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

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

> 313:                         if (buf != null) {
> 314:                             Util.releaseTemporaryDirectBuffer(buf);
> 315:                         }

I don't think this is maintainable as is, instead I think the two cases need to moved to supporting methods so you can have something like:


if (transferRequiresBuffer) {
    transferWithTemporyBuffer(...);
} else {
    transferDirect(...)
}

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

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

From redestad at openjdk.org  Fri Jun 17 12:28:59 2022
From: redestad at openjdk.org (Claes Redestad)
Date: Fri, 17 Jun 2022 12:28:59 GMT
Subject: Integrated: 8287904: Reduce runtime of java.net microbenchmarks
In-Reply-To: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
References: <i0ORnvVl-zQ64pGWBs_BAcgBr4z-S5KAcicZxnFblhY=.5e450e1d-6b48-4372-88e1-64f0dc955fb5@github.com>
Message-ID: <ONs3pJ_YcHKIr_2n-fMuNSYQuq4YOrMiVFjf9A_R6MM=.5d8ae5f6-219b-40b4-a56c-de316b108975@github.com>

On Thu, 16 Jun 2022 09:31:01 GMT, Claes Redestad <redestad at openjdk.org> wrote:

> - Remove a couple of benchmarks with very high, environment-dependent variance (not improved by increasing warmup)
> - Reduce number of parameters, forks, iterations to improve runtime without sacrificing much data quality 
> - Fix one broken microbenchmark (`NetworkInterfaceLookup`) that reflects into encapsulated internals without explicitly opening the package.
> 
> Estimated runtime reduced from 10h38m to 1h35m

This pull request has now been integrated.

Changeset: cc445926
Author:    Claes Redestad <redestad at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc445926cfe41ee7803791fb223504b0d9fd8100
Stats:     432 lines in 13 files changed: 53 ins; 374 del; 5 mod

8287904: Reduce runtime of java.net microbenchmarks

Reviewed-by: jvernee

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

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

From bpb at openjdk.org  Fri Jun 17 15:30:00 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 15:30:00 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <G7AGzonEg8n7oOHdQu2EPonNTOasHQ--d5_4MNygE4E=.7d443371-286a-48d5-ba5a-bcded53fd43f@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
 <G7AGzonEg8n7oOHdQu2EPonNTOasHQ--d5_4MNygE4E=.7d443371-286a-48d5-ba5a-bcded53fd43f@github.com>
Message-ID: <rOtiUO95LrGPPO6uu2EO-SRjrG3wyFxn_a_nCVOy-rY=.6c81e924-3097-407d-970f-c066609fd984@github.com>

On Fri, 17 Jun 2022 12:03:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: Use temporary direct buffer for user-space copy
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 315:
> 
>> 313:                         if (buf != null) {
>> 314:                             Util.releaseTemporaryDirectBuffer(buf);
>> 315:                         }
> 
> I don't think this is maintainable as is, instead I think the two cases need to moved to supporting methods so you can have something like:
> 
> 
> if (transferRequiresBuffer) {
>     transferWithTemporyBuffer(...);
> } else {
>     transferDirect(...)
> }

I wrote something like that before publishing this version and did not like it but now I think it might be better.

> src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 158:
> 
>> 156:             if (errno == EINVAL || errno == ENOSYS) {
>> 157:                 // Fall back to copying via user-space buffers
>> 158:                 char buf[MIN_TRANSFER_SIZE];
> 
> We can't have the fallback path using 16k of stack here.

That code is likely never called.

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

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

From bpb at openjdk.org  Fri Jun 17 15:37:53 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 15:37:53 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

 - 6980847: Convert to fallback to copy0() method
 - 6980847: work in progress

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/c30a6f0b..a6575484

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

  Stats: 122 lines in 4 files changed: 49 ins; 30 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/9161.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9161/head:pull/9161

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

From bpb at openjdk.org  Fri Jun 17 15:37:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 15:37:55 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
Message-ID: <MXqV_559LYGC9rA88omOz2N_cqv4roZjeyRFiwL6HjA=.ce0f9bb5-7256-4d06-b5d0-06bfeba98b32@github.com>

On Thu, 16 Jun 2022 23:36:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Use temporary direct buffer for user-space copy

Commit a657548422ef0be5edabe5a28c074204b59b8981 takes an approach closer to `FileChannelImpl`.

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

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

From bpb at openjdk.org  Fri Jun 17 15:55:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 15:55:55 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
Message-ID: <wFRywOcPmV06WkjQZgyqC60cR-C_yWCYBNaASqGA4U0=.86876d73-e146-4629-9bb5-591a0efff4cf@github.com>

On Fri, 17 Jun 2022 15:37:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6980847: Convert to fallback to copy0() method
>  - 6980847: work in progress

Commit a53b54fed5ead638ebcbc12535117e2329b2fc30 is spurious and should be ignored.

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

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

From duke at openjdk.org  Fri Jun 17 16:00:53 2022
From: duke at openjdk.org (kristylee88)
Date: Fri, 17 Jun 2022 16:00:53 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
Message-ID: <fS_8TQIL4vRK1DcU9FXTMvG_VnRfp_3wdsDgOwBNTis=.66d29484-2935-4667-bc3a-6ca851396b65@github.com>

On Fri, 17 Jun 2022 15:37:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6980847: Convert to fallback to copy0() method
>  - 6980847: work in progress

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

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

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

From bpb at openjdk.org  Fri Jun 17 16:09:10 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 16:09:10 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
Message-ID: <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>

On Fri, 17 Jun 2022 15:37:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6980847: Convert to fallback to copy0() method
>  - 6980847: work in progress

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

> 312:                                 Blocker.end(comp);
> 313:                             }
> 314:                         } while (res == IOStatus.INTERRUPTED);

As `RESTARTABLE` is used in `transfer0()` this loop could go away.

src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 141:

> 139:         RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
> 140:         if (bytes_sent < 0) {
> 141:             if (errno == EINTR) {

As the `RESTARTABLE` macro is used, checking for `errno == EINTR` can go away.

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

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

From bpb at openjdk.org  Fri Jun 17 16:36:17 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 17 Jun 2022 16:36:17 GMT
Subject: RFR: 8288687: (fc) Unix version ofFileChannelImpl.transferTo0() should
 should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
Message-ID: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>

Return `IOS_UNSUPPORTED` from the `#else` conditional compilation branch of `Java_sun_nio_ch_FileChannelImpl_transferTo0`.

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

Commit messages:
 - 8288687: (fc) Unix version ofFileChannelImpl.transferTo0() should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX

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

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

From mcimadamore at openjdk.org  Fri Jun 17 18:19:22 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:19:22 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!LRi6H5B7NKml21MYCTD-BHm7o_FL_4zxsarqzjV53S5o0TXOkBq047zL_yOl8Va6wrIgOBZOkK7SWiZ1kFYAmlc-$ 

Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into memory_session_cleanup
 - Fix issue in Direct-X-Buffer template
 - Simplify and drop the state class
 - Add missing files
 - Initial push

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

Changes: https://git.openjdk.org/jdk19/pull/22/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=22&range=01
  Stats: 543 lines in 28 files changed: 48 ins; 110 del; 385 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:24 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:24 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v3]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <5qDmnUurtGSqPny2rf0qUp3wafWfpRRvpMJyI_r0VkM=.20cd2a71-bed0-4ef7-80ca-fd6e9efc2528@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!Nx6uev9jqFBaDs7q_OeJXbWghrsubLZHs5Mv1jLQj7YvCdvtOxF-TkiHN3CrX8gLvS_LVs6w-ZbVNj4pYOHtRCO6$ 

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

  Unify heap vs. implicit scopes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/be81918f..b605aeab

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

  Stats: 12 lines in 3 files changed: 3 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:25:25 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:25:25 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v2]
In-Reply-To: <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <waAHwHIaYMcMmUNBAkEeAF6GmqG1R8-daKgLMthMaP8=.d48fe7b5-fd96-4e14-8fb6-97f1c70e3b07@github.com>
Message-ID: <cCTCVBbOOKw_cFTiqNt4rYCnWYWAGKo5S3kiapdTGxI=.663dbdb4-b47c-4b00-909d-156ea8b42ecf@github.com>

On Fri, 17 Jun 2022 18:19:22 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!OmdtQEfdKMafEBUgymSRCDXfhAsuwY1Ki6tboob-mRI5NSuopPha5T2W2tDmvITgJB0ar8_ZghafH6dpnDabsnm6$ 
>
> Maurizio Cimadamore has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into memory_session_cleanup
>  - Fix issue in Direct-X-Buffer template
>  - Simplify and drop the state class
>  - Add missing files
>  - Initial push

I ended up simplifying this PR, by selecting some of the improvement from the previous patch:
* simplify handling of "readOnly" for memory segments
* Remove duplication between `sessionImpl` and `session` accessors, by making non-closeable views also be subclasses of `MemorySessionImpl`
* use better naming for the `checkValidState` methods - now the plain method is the method that should be used by all clients, while `checkValidStateRaw` is the method that should only be used in ScopedMemoryAccess
* unify exception handling, and fix issues around WrongThreadException not being handled correctly in ScopedMemoryAccess

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 18:39:03 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 18:39:03 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
Message-ID: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>

> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!O0RMiXCfvvDMuk4o6Mu6hube9mx5i9_u0CYjkqbgv6KQ6WfACrLIw7CQsGxgsQ7a_mtUrB9g1kswTncfr3dCb614$ 

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

  Revert implicit vs. heap session changes

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

Changes:
  - all: https://git.openjdk.org/jdk19/pull/22/files
  - new: https://git.openjdk.org/jdk19/pull/22/files/b605aeab..a6841b24

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

  Stats: 14 lines in 5 files changed: 4 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk19/pull/22.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/22/head:pull/22

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 20:42:59 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 20:42:59 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
Message-ID: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>

On Fri, 17 Jun 2022 18:39:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> This is a JDK 19 clone of: https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9017__;!!ACWV5N9M2RV99hQ!KIECGDP6-u__4Dx3mcedq36QxKN5d4_vPnX2PE5NASYTR6Bw9jQuG0qOUF95Y7pHX0YZ2tMQlbkPdlHljKNRgLK7$ 
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert implicit vs. heap session changes

src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:

> 528:             bufferSession = bufferSegment.session;
> 529:         } else {
> 530:             bufferSession = MemorySessionImpl.heapSession(bb);

I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

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

PR: https://git.openjdk.org/jdk19/pull/22

From duke at openjdk.org  Fri Jun 17 21:21:53 2022
From: duke at openjdk.org (kristylee88)
Date: Fri, 17 Jun 2022 21:21:53 GMT
Subject: RFR: 8288687: (fc) Unix version ofFileChannelImpl.transferTo0()
 should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
In-Reply-To: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
References: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
Message-ID: <PNhE7C541Y71uTEfkKe6cEUpY5MdZMdRpD0GqAG0D60=.6e6099e3-1400-4332-abc1-947230296fee@github.com>

On Fri, 17 Jun 2022 16:26:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Return `IOS_UNSUPPORTED` from the `#else` conditional compilation branch of `Java_sun_nio_ch_FileChannelImpl_transferTo0`.

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

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

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

From mcimadamore at openjdk.org  Fri Jun 17 21:50:05 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:50:05 GMT
Subject: RFR: 8287809: Revisit implementation of memory session [v4]
In-Reply-To: <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
References: <tamT7yX4ijy5von8lh_Gc-0iiKd4oxrsynQkZ5iWsBQ=.317b7149-7477-4d64-9189-ba53b9d3719b@github.com>
 <hZrORsCyL-X6TdxTEI6X3jnfSQkUWOXEVPAKclNpQoA=.7b16aefa-0d58-431e-b7c7-51ffa3a6444c@github.com>
 <EedD2CoEogjsZx3EA01Oh4uBRjMulPg8KhteHJx5J-k=.25f6a733-9186-47d8-b561-28c1ad74d8b6@github.com>
Message-ID: <cw0qgrS7-SFUAkNN-b0fUDZRZJaqTUO8YTAeqohDimk=.1e6ee1ad-4499-4578-b2c8-4087b68fdaae@github.com>

On Fri, 17 Jun 2022 20:39:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert implicit vs. heap session changes
>
> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 530:
> 
>> 528:             bufferSession = bufferSegment.session;
>> 529:         } else {
>> 530:             bufferSession = MemorySessionImpl.heapSession(bb);
> 
> I think this should be tweaked (as part of another patch). Buffer segments should have same lifecycle of array segments - and array segments have the global session. This is because an array segment always keeps the underlying array alive. I think we should enhance memory segment implementation (esp. that of native segments), so that it can be used to keep other objects alive. This would be useful also in the `loaderLookup` where we create another of those odd sessions - in that case we should just say that the segments returned by loader lookup have global scope, and keep the loader alive.

I've filed a dependent PR for this: https://urldefense.com/v3/__https://github.com/openjdk/jdk19/pull/39__;!!ACWV5N9M2RV99hQ!JxGnnCc13s6BAA8IDzyWY-9rpqwrYZMgNTcczbZYVS5z6MjvJS-OLBzNsAt9whM_bRruwondGzeMtRRSOPkY6o9W$ 

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

PR: https://git.openjdk.org/jdk19/pull/22

From mcimadamore at openjdk.org  Fri Jun 17 21:53:29 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 21:53:29 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader lookup
Message-ID: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>

This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:

* when a buffer segment is created, to keep the original buffer instance reachable
* when a loader symbol lookup is created, to keep the classloader instance reachable

Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.

This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.

This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

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

Depends on: https://git.openjdk.org/jdk19/pull/22

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk19/pull/39/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=39&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288697
  Stats: 47 lines in 8 files changed: 5 ins; 15 del; 27 mod
  Patch: https://git.openjdk.org/jdk19/pull/39.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/39/head:pull/39

PR: https://git.openjdk.org/jdk19/pull/39

From mcimadamore at openjdk.org  Fri Jun 17 22:12:54 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 17 Jun 2022 22:12:54 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
Message-ID: <9BbVhkYmwTPt9m69BEx-CVPGARA2Iv6t2pvRVljif5Q=.15c9ab45-7f2b-46ce-8fa3-a66984f17fab@github.com>

On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
> 
> * when a buffer segment is created, to keep the original buffer instance reachable
> * when a loader symbol lookup is created, to keep the classloader instance reachable
> 
> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
> 
> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
> 
> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

After thinking some more, I realized that going down this path might cause reachability issues when said segments are dereferenced (from ScopedMemoryAccess) or when they are passed to native function (using linker). Both system keep the session reachable, not the segment. Moving back to draft for now.

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

PR: https://git.openjdk.org/jdk19/pull/39

From alanb at openjdk.org  Sun Jun 19 16:02:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Jun 2022 16:02:53 GMT
Subject: RFR: 8288687: (fc) Unix version ofFileChannelImpl.transferTo0()
 should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
In-Reply-To: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
References: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
Message-ID: <3RyDqtHCk6LRQsT_6md_SGlMpZzZtiZj6yc2PciU4sk=.d3812530-7ac5-481b-8585-a69a319168ef@github.com>

On Fri, 17 Jun 2022 16:26:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Return `IOS_UNSUPPORTED` from the `#else` conditional compilation branch of `Java_sun_nio_ch_FileChannelImpl_transferTo0`.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Sun Jun 19 16:52:49 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 19 Jun 2022 16:52:49 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <cOWEXny5ngr0_P6Mwi1YHc5exVe2ho3XoDYkZyl7Vpk=.09bbf5d3-fd6e-4fdb-9986-73b3ed09ece0@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
 <aSBaXEjfQkfZVA6c9fBrJF4WbMpHq_FoXKXiy1_QcII=.6b526e36-5b63-442a-83c8-f0e0164d7a5a@github.com>
 <cOWEXny5ngr0_P6Mwi1YHc5exVe2ho3XoDYkZyl7Vpk=.09bbf5d3-fd6e-4fdb-9986-73b3ed09ece0@github.com>
Message-ID: <vm875wmX80F_ZKAWMeh-oZWGZBomJae1VRYlcpGLpNM=.4030c7c6-5a56-4d4b-b1b2-9a4da696a259@github.com>

On Thu, 9 Jun 2022 15:11:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Either that or go with the `KeyCancelled` test for now and file a separate issue to fix / replace that.

I looked at the CancelDuringRegister test again. Two threads are racing toe cancel the key. The winner queues the cancelled key to be flushed from the Selector at the next selection operation. If the winner is the background thread spinning on `sel.keys().forEach(SelectionKey::cancel);` then there is no guarantee that the cancelled key has been removed from the Selector's key set before the next register. So that is why it register fails intermittently with CancelledKeyException. The test can be fixed by changing it to call selectNow until the key is removed.

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

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

From alanb at openjdk.org  Tue Jun 21 09:21:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 09:21:05 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
 <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>
Message-ID: <_ONv8hZQqeRDSbIPyHf6Dl2mfBIWkpc1Y-jF7TSlgtk=.4dfcadf3-6846-48d5-9716-aacd96ff6797@github.com>

On Fri, 17 Jun 2022 16:06:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> As `RESTARTABLE` is used in `transfer0()` this loop could go away.

Does the check for EINTR in transfer0 also go away? It maps it to IOS_INTERRUPTED but the use of RESTARTABLE means this code will never execute.

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

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

From alanb at openjdk.org  Tue Jun 21 09:27:41 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 09:27:41 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
Message-ID: <EEW14DPWeS_fr80GmmVc1L2iEEqJD4qFQ3JT3eLoOxM=.db622e47-f644-4cbc-b732-0d005ea8131c@github.com>

On Fri, 17 Jun 2022 15:37:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 6980847: Convert to fallback to copy0() method
>  - 6980847: work in progress

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

> 721: 
> 722:     static native void copy0(int dst, int src, long address, int transferSize,
> 723:                              long addressToPollForCancel)

The naming is a bit unfortunate here. transferTo0 is copy with buffers in user-space. copy0 is with kernel support such as sendfile64 or fcopyfile. I think we need clearer names and improve the comments on the declarations here so that it's clear what they do. I think that's the first step before we split up the high-level copyFile method to make it easier to read and maintain.

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

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

From bpb at openjdk.org  Tue Jun 21 15:31:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 21 Jun 2022 15:31:59 GMT
Subject: Integrated: 8288687: (fc) Unix version ofFileChannelImpl.transferTo0()
 should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX
In-Reply-To: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
References: <HvCDcrYkKKdLg8lq0ImhA1LxogP5yb0YZDhMNoY2nE4=.c0a44ba5-203c-4a84-9b51-40688d499540@github.com>
Message-ID: <f8tDdWfkP40s08AObQUMOsEtdK4zTH-VHKZYb__SNvY=.10f0bc16-a680-478a-b41b-6a17c6bdad57@github.com>

On Fri, 17 Jun 2022 16:26:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Return `IOS_UNSUPPORTED` from the `#else` conditional compilation branch of `Java_sun_nio_ch_FileChannelImpl_transferTo0`.

This pull request has now been integrated.

Changeset: 535fba8b
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/535fba8bfcd1bec6400b7be7d7c95e1310ac2b4b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288687: (fc) Unix version ofFileChannelImpl.transferTo0() should should return IOS_UNSUPPORTED if not Linux, macOS, nor AIX

Reviewed-by: alanb

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

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

From alanb at openjdk.org  Tue Jun 21 16:12:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 21 Jun 2022 16:12:52 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
Message-ID: <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>

On Fri, 17 Jun 2022 21:39:16 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
> 
> * when a buffer segment is created, to keep the original buffer instance reachable
> * when a loader symbol lookup is created, to keep the classloader instance reachable
> 
> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
> 
> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
> 
> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.

src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 148:

> 146:      * <p>
> 147:      * The symbols obtained from the returned loader lookup are backed by the {@linkplain MemorySession#global() global session}.
> 148:      * <p>

Does the spec update mean this should have a CSR?

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

PR: https://git.openjdk.org/jdk19/pull/39

From mcimadamore at openjdk.org  Tue Jun 21 16:16:39 2022
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 21 Jun 2022 16:16:39 GMT
Subject: RFR: 8288697: Clarify lifecycle of buffer segments and loader
 lookup
In-Reply-To: <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>
References: <TNbdm8cJpYux0qkqShWnpD0hJ4ZHi-en7jompm3LtKc=.12f0c5e8-802d-43af-8552-77595b872ea8@github.com>
 <mMZ3aaH1ZZxs0b5ygD50YxFUSKKe1Oo0Cjpqfx1NZ5E=.7b595690-74e9-45fb-bf73-3e4cddecb0ef@github.com>
Message-ID: <Gx12ilNsAnx1g8Bo_SOqNVHvio3OBeSfMR0Eloib7Jk=.118ba099-83dd-45ee-8b7d-35b8ce536d33@github.com>

On Tue, 21 Jun 2022 16:10:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This is a dependent PR containing a cleanup of the so called *heap sessions*. Heap sessions are used in two cases:
>> 
>> * when a buffer segment is created, to keep the original buffer instance reachable
>> * when a loader symbol lookup is created, to keep the classloader instance reachable
>> 
>> Spinning new sessions in these cases seems unnecessary, and inconsistent with what we do for segments backed by on-heap arrays, whose session is set to the global session. In that case, it's up to the segment to keep the underlying array reachable. I think that's a better model.
>> 
>> This patch adds the ability to attach Object references to native and mapped memory segments, so that we can attach loader/byte buffer instances to these segments, keeping them alive. This means that, in these cases we can go back to just use the global memory session, like we do for array segments.
>> 
>> This simplifies the implementation, makes the documentation more consistent, and also simplifies the user model, as it removes a concept (of heap session) that is not really documented anywhere. In fact, the javadoc for MemorySegment::ofBuffer claims, (wrongly!) that the session of the resulting segment is the global session - but that's not the case.
>
> src/java.base/share/classes/java/lang/foreign/SymbolLookup.java line 148:
> 
>> 146:      * <p>
>> 147:      * The symbols obtained from the returned loader lookup are backed by the {@linkplain MemorySession#global() global session}.
>> 148:      * <p>
> 
> Does the spec update mean this should have a CSR?

Yep - note that PR is in draft mode as we need to think through what changes we actually want to pursue.

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

PR: https://git.openjdk.org/jdk19/pull/39

From bpb at openjdk.org  Wed Jun 22 00:20:39 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 00:20:39 GMT
Subject: Withdrawn: 8287168: (fs) WatchService leaves thread running if not
 closed
In-Reply-To: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
References: <NJL-BwdhpxodDlzH_KbEoGq4tmNgADRB0iVhSuGKU6w=.9162d35b-5324-4bd4-be3d-b6edb55fa1e0@github.com>
Message-ID: <efckMt700vyKErQmBIqx1fc5_FN1fB2eGlnQ7pZ9Ysk=.ed0bb00b-20a4-4a4c-8d73-393ff6aa9940@github.com>

On Thu, 2 Jun 2022 02:52:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add a `Cleaner` to each `WatchService` implementation.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Wed Jun 22 00:23:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 00:23:14 GMT
Subject: RFR: 8288515: (ch) Unnecessary use of Math.addExact() in
 java.nio.channels.FileLock.overlaps()
Message-ID: <HhpqQ-ga3gLF5LSmRtet4DpCq8bHCq2nWqZ7ZdB8dw4=.e7b9d754-e099-4791-9c18-9c87294740cc@github.com>

`FileLock` checks the immutable `position` and `size` parameters in its constructor hence using `Math.addExact()` on these instance variables in `overlaps()` is needless.

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

Commit messages:
 - 8288515: (ch) Unnecessary use of Math.addExact() in java.nio.channels.FileLock.overlaps()

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

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

From bpb at openjdk.org  Wed Jun 22 01:12:47 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:12:47 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v4]
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <OUzrOoA-e9DCvIXqHGPlnXcuj86yiZI32Ja2QfLAlUs=.0bf642ae-e232-4a32-a940-6a22db764136@github.com>

> Ignore `CancelledKeyException` during registration.

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

  8287580: Add CancelDuringRegister test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8978/files
  - new: https://git.openjdk.org/jdk/pull/8978/files/98bcd22e..85ebbbb6

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

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

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

From bpb at openjdk.org  Wed Jun 22 01:12:51 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:12:51 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v3]
In-Reply-To: <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <RgLwnVpIG58x0ndBLjS2cfo1vQbd_VMHGpHo--Ve0uQ=.99da499e-4df6-4230-9f74-89299769eac4@github.com>
Message-ID: <kyDoDAdVG9qXF8dfsktKidoPXNy512qoB1JVuqLZ6no=.1f5aa1c4-c12b-4ffb-9c1d-3730d85f5c47@github.com>

On Thu, 2 Jun 2022 22:14:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Revert change to AbstractSelectableChannel; reduce iterations in test

The version of `CancelDuringRegister` added in commit 85ebbbb648114165bc1ebfd1badd2882eb4aab51 failed 5/5 repeats on four platforms when run against the build `jdk-19-2107` but succeeded in 5/5 repeats on four platforms when run with the suggested fix of this PR in place.

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

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

From bpb at openjdk.org  Wed Jun 22 01:15:19 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:19 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/a6575484..04d75022

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

  Stats: 103 lines in 3 files changed: 36 ins; 21 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/9161.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9161/head:pull/9161

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

From bpb at openjdk.org  Wed Jun 22 01:15:22 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:22 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <yXXExFfmajDsFbkPAkV9sma24Ixpzp0HDBY-1xyRO4Q=.601dae64-3392-4783-ada9-055ac9376e8a@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
 <yXXExFfmajDsFbkPAkV9sma24Ixpzp0HDBY-1xyRO4Q=.601dae64-3392-4783-ada9-055ac9376e8a@github.com>
Message-ID: <6XT7sNmv4K6Uyb7iAjCUvm_W_4Gf6MpcO94nB2jgprU=.83436e09-0567-436f-ae22-9df25f1a02b3@github.com>

On Fri, 17 Jun 2022 11:57:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: Use temporary direct buffer for user-space copy
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 297:
> 
>> 295:                     } catch (IllegalArgumentException | UnixException ignored) {
>> 296:                     }
>> 297:                     transferSize = ts;
> 
> This code needs to move to a separate method, something like transferSize(source, target).

Fixed.

> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 186:
> 
>> 184:             }
>> 185:             final int flags = ((!followLinks) ? COPY_FILE_COPY_SYMLINK : 0) |
>> 186:                 ((size > UNBUFFERED_IO_THRESHOLD) ? COPY_FILE_NO_BUFFERING : 0);
> 
> The size of the source file is already in sourceAttrs.size(), no need to call back into the API to access the file again.

Fixed.

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

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

From bpb at openjdk.org  Wed Jun 22 01:15:22 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:22 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <_ONv8hZQqeRDSbIPyHf6Dl2mfBIWkpc1Y-jF7TSlgtk=.4dfcadf3-6846-48d5-9716-aacd96ff6797@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
 <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>
 <_ONv8hZQqeRDSbIPyHf6Dl2mfBIWkpc1Y-jF7TSlgtk=.4dfcadf3-6846-48d5-9716-aacd96ff6797@github.com>
Message-ID: <d_pt3JEMNxgUN_60JOsB_PIHpbCRme_Rg54_57ljlmA=.8575a26c-a468-4997-ba97-f5a5fd5a6764@github.com>

On Tue, 21 Jun 2022 09:19:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 314:
>> 
>>> 312:                                 Blocker.end(comp);
>>> 313:                             }
>>> 314:                         } while (res == IOStatus.INTERRUPTED);
>> 
>> As `RESTARTABLE` is used in `transfer0()` this loop could go away.
>
>> As `RESTARTABLE` is used in `transfer0()` this loop could go away.
> 
> Does the check for EINTR in transfer0 also go away? It maps it to IOS_INTERRUPTED but the use of RESTARTABLE means this code will never execute.

Yes, as noted [here](https://urldefense.com/v3/__https://github.com/openjdk/jdk/pull/9161*discussion_r900290005__;Iw!!ACWV5N9M2RV99hQ!I_WBavoEHDJAriztsfxp67t4rqz-RftVkKPXaF_vW9U5SEL82_JwnfYQ6AEKnFAzMlGMO8iroE_tyA$ ).

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

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

From bpb at openjdk.org  Wed Jun 22 01:15:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:24 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <EEW14DPWeS_fr80GmmVc1L2iEEqJD4qFQ3JT3eLoOxM=.db622e47-f644-4cbc-b732-0d005ea8131c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
 <EEW14DPWeS_fr80GmmVc1L2iEEqJD4qFQ3JT3eLoOxM=.db622e47-f644-4cbc-b732-0d005ea8131c@github.com>
Message-ID: <o-fePARUVxPi3Iwx5onpUoih22em2Zyb1BSvxVdGLNA=.9b8f4ced-247e-4fea-8821-250c37bdc265@github.com>

On Tue, 21 Jun 2022 09:23:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 6980847: Convert to fallback to copy0() method
>>  - 6980847: work in progress
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 723:
> 
>> 721: 
>> 722:     static native void copy0(int dst, int src, long address, int transferSize,
>> 723:                              long addressToPollForCancel)
> 
> The naming is a bit unfortunate here. transferTo0 is copy with buffers in user-space. copy0 is with kernel support such as sendfile64 or fcopyfile. I think we need clearer names and improve the comments on the declarations here so that it's clear what they do. I think that's the first step before we split up the high-level copyFile method to make it easier to read and maintain.

Refactored in 04d7502280df1dd0c2dccf34cc93450d86458e81.

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

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

From bpb at openjdk.org  Wed Jun 22 01:15:24 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:24 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v6]
In-Reply-To: <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <tHZLtx11HKV9g_cJV-bRpAyLXMTJ8mGJcfO4joNIS8s=.8fc61111-ea5d-403d-9048-0e92e8f7439c@github.com>
 <5upBZyY2depltlz1y6WIATO1YdXalP8glX9MAJvVrQ4=.bac1c865-6870-473e-ac0f-e9cd430e7a37@github.com>
Message-ID: <a9wvVoRTloqEAeuyElUSnXkDOZD766JoXsftmo4qzbU=.6939bff2-ee03-4b7a-accb-3f549be09f96@github.com>

On Fri, 17 Jun 2022 16:05:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 6980847: Convert to fallback to copy0() method
>>  - 6980847: work in progress
>
> src/java.base/unix/native/libnio/fs/UnixCopyFile.c line 141:
> 
>> 139:         RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>> 140:         if (bytes_sent < 0) {
>> 141:             if (errno == EINTR) {
> 
> As the `RESTARTABLE` macro is used, checking for `errno == EINTR` can go away.

Fixed in 04d7502280df1dd0c2dccf34cc93450d86458e81.

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

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

From bpb at openjdk.org  Wed Jun 22 01:15:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 01:15:23 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v5]
In-Reply-To: <rOtiUO95LrGPPO6uu2EO-SRjrG3wyFxn_a_nCVOy-rY=.6c81e924-3097-407d-970f-c066609fd984@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <fUhx8AxZA5Up_7L4XsgeJ_u4MtAU7V6fYHQQMKWJoIM=.1c222363-2880-4af6-8218-069d95b197bb@github.com>
 <G7AGzonEg8n7oOHdQu2EPonNTOasHQ--d5_4MNygE4E=.7d443371-286a-48d5-ba5a-bcded53fd43f@github.com>
 <rOtiUO95LrGPPO6uu2EO-SRjrG3wyFxn_a_nCVOy-rY=.6c81e924-3097-407d-970f-c066609fd984@github.com>
Message-ID: <ZOi0X_Sl6fDzw0lfC5myL9BhFqCreIi1PvwBPlRydhU=.f5e184be-77b2-4345-b027-70e808ce0548@github.com>

On Fri, 17 Jun 2022 15:26:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 315:
>> 
>>> 313:                         if (buf != null) {
>>> 314:                             Util.releaseTemporaryDirectBuffer(buf);
>>> 315:                         }
>> 
>> I don't think this is maintainable as is, instead I think the two cases need to moved to supporting methods so you can have something like:
>> 
>> 
>> if (transferRequiresBuffer) {
>>     transferWithTemporyBuffer(...);
>> } else {
>>     transferDirect(...)
>> }
>
> I wrote something like that before publishing this version and did not like it but now I think it might be better.

Refactored in commit 04d7502280df1dd0c2dccf34cc93450d86458e81.

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

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

From alanb at openjdk.org  Wed Jun 22 06:45:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 06:45:55 GMT
Subject: RFR: 8288515: (ch) Unnecessary use of Math.addExact() in
 java.nio.channels.FileLock.overlaps()
In-Reply-To: <HhpqQ-ga3gLF5LSmRtet4DpCq8bHCq2nWqZ7ZdB8dw4=.e7b9d754-e099-4791-9c18-9c87294740cc@github.com>
References: <HhpqQ-ga3gLF5LSmRtet4DpCq8bHCq2nWqZ7ZdB8dw4=.e7b9d754-e099-4791-9c18-9c87294740cc@github.com>
Message-ID: <7aof5t0RNw0Wed4M_oqDpvoIrvGKRzVFQBPudJAQa3E=.6c8c2b54-d9d8-45c7-9cd1-7b90e0c1dbf4@github.com>

On Wed, 22 Jun 2022 00:13:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `FileLock` checks the immutable `position` and `size` parameters in its constructor hence using `Math.addExact()` on these instance variables in `overlaps()` is needless.

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Wed Jun 22 06:47:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 06:47:55 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v4]
In-Reply-To: <OUzrOoA-e9DCvIXqHGPlnXcuj86yiZI32Ja2QfLAlUs=.0bf642ae-e232-4a32-a940-6a22db764136@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <OUzrOoA-e9DCvIXqHGPlnXcuj86yiZI32Ja2QfLAlUs=.0bf642ae-e232-4a32-a940-6a22db764136@github.com>
Message-ID: <tSFn03M1vkzgKPb8raR3axPag_hPCotEootsA-J90Kg=.b1de0695-1d3e-426e-a816-f75332135324@github.com>

On Wed, 22 Jun 2022 01:12:47 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Add CancelDuringRegister test

The latest patch has both tests, are you proposing to include both or did you mean to just include one?

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

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

From alanb at openjdk.org  Wed Jun 22 06:49:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 06:49:38 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
Message-ID: <_jcFi4Q8ftih9zshBWbP087gLUzIF8q_O10ZBz_JVZ4=.6747b9ba-65cd-4671-b4f0-84118e2f96f7@github.com>

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

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Cleanup

src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 182:

> 180:             long size = 0;
> 181:             try {
> 182:                 size = Files.size(source);

Are you going to change this to use sourceAttrs.size() ?

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

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

From alanb at openjdk.org  Wed Jun 22 14:41:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 14:41:53 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
Message-ID: <1XGDRKp-X2u2wEM8IbGnJ2gU-uJA2soQXZ85rlCi3PI=.cf835f65-ff43-4604-9eff-53b8cf851df4@github.com>

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

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Cleanup

04d75022 is a big improvement, I think the overall approach is good now.

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

> 231:     private static long lcm(long x, long y) {
> 232:         if (x <= 0 || y <= 0)
> 233:             throw new IllegalArgumentException("Non-positive parameter");

If lcm were to be used more widely then throwing IAE would make sense. However, the usage here is private to the copy method and it only calls lcm when x and y are positive. It also catches IAE. It might be simpler to just put an assert x > 0 && y > 0 and remove the catch of IAE. That would catch any bugs in this code.

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

> 328:                     } finally {
> 329:                         Util.releaseTemporaryDirectBuffer(buf);
> 330:                         Blocker.end(comp);

It might be better to use a nested try-finally to ensure that the buffer get/release and blocker begin/end are symmetric.

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

> 731:      *        (a non-zero value written to this address indicates cancel)
> 732:      */
> 733:     private static native void bufferCopy0(int dst, int src, long address,

It might be clearer if the name were bufferedCopy rather than bufferCopy.

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

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

From bpb at openjdk.org  Wed Jun 22 14:54:59 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 14:54:59 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v5]
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <1eVE2OcrGyRX_VR9-MjZOlp4nYujbytx2M_R-o0iL0E=.79b784a4-ca33-48f4-b00c-cee856a1cc84@github.com>

> Ignore `CancelledKeyException` during registration.

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

  8287580: Remove Selector/KeyCancelled.java test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/8978/files
  - new: https://git.openjdk.org/jdk/pull/8978/files/85ebbbb6..49fc5f5e

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

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

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

From bpb at openjdk.org  Wed Jun 22 14:55:01 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 14:55:01 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v4]
In-Reply-To: <tSFn03M1vkzgKPb8raR3axPag_hPCotEootsA-J90Kg=.b1de0695-1d3e-426e-a816-f75332135324@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <OUzrOoA-e9DCvIXqHGPlnXcuj86yiZI32Ja2QfLAlUs=.0bf642ae-e232-4a32-a940-6a22db764136@github.com>
 <tSFn03M1vkzgKPb8raR3axPag_hPCotEootsA-J90Kg=.b1de0695-1d3e-426e-a816-f75332135324@github.com>
Message-ID: <c6ET-SaTjVueu8I9Iq484QcfauiYEMIILWmftYZ5Lnc=.a3ecf621-4a36-4553-9497-9bb86a169f46@github.com>

On Wed, 22 Jun 2022 06:44:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The latest patch has both tests, are you proposing to include both or did you mean to just include one?

Just one. I simply had not removed it yet.

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

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

From bpb at openjdk.org  Wed Jun 22 14:56:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 14:56:43 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <_jcFi4Q8ftih9zshBWbP087gLUzIF8q_O10ZBz_JVZ4=.6747b9ba-65cd-4671-b4f0-84118e2f96f7@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
 <_jcFi4Q8ftih9zshBWbP087gLUzIF8q_O10ZBz_JVZ4=.6747b9ba-65cd-4671-b4f0-84118e2f96f7@github.com>
Message-ID: <LeeHVZso5H5G-a4w-RUChBWP3DChNiupDdnkJb7qVnE=.c9025f41-00d4-403a-af9d-a68f520c5428@github.com>

On Wed, 22 Jun 2022 06:46: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:
>> 
>>   6980847: Cleanup
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 182:
> 
>> 180:             long size = 0;
>> 181:             try {
>> 182:                 size = Files.size(source);
> 
> Are you going to change this to use sourceAttrs.size() ?

I did previously but this code crept back in as it was in a different patch  version.

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

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

From alanb at openjdk.org  Wed Jun 22 15:01:54 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 15:01:54 GMT
Subject: RFR: 8287580: (se) CancelledKeyException during channel
 registration [v5]
In-Reply-To: <1eVE2OcrGyRX_VR9-MjZOlp4nYujbytx2M_R-o0iL0E=.79b784a4-ca33-48f4-b00c-cee856a1cc84@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
 <1eVE2OcrGyRX_VR9-MjZOlp4nYujbytx2M_R-o0iL0E=.79b784a4-ca33-48f4-b00c-cee856a1cc84@github.com>
Message-ID: <Oag5xz6t1pkK1teRFkJHRKfE-gWv4nHpaE4pWYY-O0I=.26f0cd42-2da7-430a-931f-20e56fdd43fa@github.com>

On Wed, 22 Jun 2022 14:54:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Ignore `CancelledKeyException` during registration.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8287580: Remove Selector/KeyCancelled.java test

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Wed Jun 22 15:32:54 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 15:32:54 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v8]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <ONnPCKOMvQ4tH8EAPYjtg0hIHG9-wGwiIjdChMgjQZs=.460b7f8e-354e-46ef-9a7d-9ed056520e0a@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: lcm IAE -> assert; nested try-with-resources; bufferCopy0 -> bufferedCopy0

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/04d75022..6c7ac10c

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

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

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

From bpb at openjdk.org  Wed Jun 22 15:39:03 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 15:39:03 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <1XGDRKp-X2u2wEM8IbGnJ2gU-uJA2soQXZ85rlCi3PI=.cf835f65-ff43-4604-9eff-53b8cf851df4@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
 <1XGDRKp-X2u2wEM8IbGnJ2gU-uJA2soQXZ85rlCi3PI=.cf835f65-ff43-4604-9eff-53b8cf851df4@github.com>
Message-ID: <6CkU4YEudShGlgPwxbsivP2tgXuWOAW8X51B5QE80Y4=.fb69af21-986b-4161-9dcc-fe4f473c9ced@github.com>

On Wed, 22 Jun 2022 14:34:40 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: Cleanup
>
> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 233:
> 
>> 231:     private static long lcm(long x, long y) {
>> 232:         if (x <= 0 || y <= 0)
>> 233:             throw new IllegalArgumentException("Non-positive parameter");
> 
> If lcm were to be used more widely then throwing IAE would make sense. However, the usage here is private to the copy method and it only calls lcm when x and y are positive. It also catches IAE. It might be simpler to just put an assert x > 0 && y > 0 and remove the catch of IAE. That would catch any bugs in this code.

So changed in 6c7ac10c4a98e0d11cb487dfe816f460f7381002.

> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 330:
> 
>> 328:                     } finally {
>> 329:                         Util.releaseTemporaryDirectBuffer(buf);
>> 330:                         Blocker.end(comp);
> 
> It might be better to use a nested try-finally to ensure that the buffer get/release and blocker begin/end are symmetric.

So changed in 6c7ac10c4a98e0d11cb487dfe816f460f7381002.

> src/java.base/unix/classes/sun/nio/fs/UnixCopyFile.java line 733:
> 
>> 731:      *        (a non-zero value written to this address indicates cancel)
>> 732:      */
>> 733:     private static native void bufferCopy0(int dst, int src, long address,
> 
> It might be clearer if the name were bufferedCopy rather than bufferCopy.

So changed in 6c7ac10c4a98e0d11cb487dfe816f460f7381002.

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

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

From bpb at openjdk.org  Wed Jun 22 16:00:45 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 16:00:45 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v7]
In-Reply-To: <LeeHVZso5H5G-a4w-RUChBWP3DChNiupDdnkJb7qVnE=.c9025f41-00d4-403a-af9d-a68f520c5428@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <Lv_3fIvjObfJxLfqjdmjfL1nTCRgIBDp0uMwh2b5XK0=.3e86af0b-82d6-4bac-a99f-e1b143fba8b7@github.com>
 <_jcFi4Q8ftih9zshBWbP087gLUzIF8q_O10ZBz_JVZ4=.6747b9ba-65cd-4671-b4f0-84118e2f96f7@github.com>
 <LeeHVZso5H5G-a4w-RUChBWP3DChNiupDdnkJb7qVnE=.c9025f41-00d4-403a-af9d-a68f520c5428@github.com>
Message-ID: <WtansJAvX-hNtT0b_JpS1q4X2pMbVpYP3mvqLR9S_U4=.1484d005-74bb-4d36-8f72-c14f7cd65d60@github.com>

On Wed, 22 Jun 2022 14:53:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 182:
>> 
>>> 180:             long size = 0;
>>> 181:             try {
>>> 182:                 size = Files.size(source);
>> 
>> Are you going to change this to use sourceAttrs.size() ?
>
> I did previously but this code crept back in as it was in a different patch  version.

Fixed in 406656e254004113f80bb36351db6662ad01a8f9.

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

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

From bpb at openjdk.org  Wed Jun 22 16:00:45 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 16:00:45 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Remove use of Files.size()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/6c7ac10c..406656e2

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

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

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

From alanb at openjdk.org  Wed Jun 22 16:50:58 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 16:50:58 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
Message-ID: <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>

On Wed, 22 Jun 2022 16:00:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Remove use of Files.size()

src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 188:

> 186:             final int flags = ((!followLinks) ? COPY_FILE_COPY_SYMLINK : 0) |
> 187:                               ((sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) ?
> 188:                                   COPY_FILE_NO_BUFFERING : 0);

Would this be easier to read:


        int flags = (followLinks) ? 0 : COPY_FILE_COPY_SYMLINK;
        if (sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) {
            flags |= COPY_FILE_NO_BUFFERING;
        }

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

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

From bpb at openjdk.org  Wed Jun 22 16:54:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 16:54:55 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
 <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>
Message-ID: <mBEl523TaTCIph2PZcZCyJeGrMQFKKQW2fJMgZDhj5g=.46712963-b4c9-4dad-9108-0c188b0392de@github.com>

On Wed, 22 Jun 2022 16:48:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   6980847: Remove use of Files.size()
>
> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 188:
> 
>> 186:             final int flags = ((!followLinks) ? COPY_FILE_COPY_SYMLINK : 0) |
>> 187:                               ((sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) ?
>> 188:                                   COPY_FILE_NO_BUFFERING : 0);
> 
> Would this be easier to read:
> 
> 
>         int flags = (followLinks) ? 0 : COPY_FILE_COPY_SYMLINK;
>         if (sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) {
>             flags |= COPY_FILE_NO_BUFFERING;
>         }

I did not do that because `flags` is final but I guess it need not be.

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

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

From bpb at openjdk.org  Wed Jun 22 17:23:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 17:23:43 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <mBEl523TaTCIph2PZcZCyJeGrMQFKKQW2fJMgZDhj5g=.46712963-b4c9-4dad-9108-0c188b0392de@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
 <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>
 <mBEl523TaTCIph2PZcZCyJeGrMQFKKQW2fJMgZDhj5g=.46712963-b4c9-4dad-9108-0c188b0392de@github.com>
Message-ID: <ZL0V1tBVZdaoFetd1LZztIjoZVvuQSTw5S0FE2XVE1E=.725f2bee-bf20-48b8-b4cd-bd8e1812ea39@github.com>

On Wed, 22 Jun 2022 16:51:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsFileCopy.java line 188:
>> 
>>> 186:             final int flags = ((!followLinks) ? COPY_FILE_COPY_SYMLINK : 0) |
>>> 187:                               ((sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) ?
>>> 188:                                   COPY_FILE_NO_BUFFERING : 0);
>> 
>> Would this be easier to read:
>> 
>> 
>>         int flags = (followLinks) ? 0 : COPY_FILE_COPY_SYMLINK;
>>         if (sourceAttrs.size() > UNBUFFERED_IO_THRESHOLD) {
>>             flags |= COPY_FILE_NO_BUFFERING;
>>         }
>
> I did not do that because `flags` is final but I guess it need not be.

Actually `flags` must be final as it is referenced from an inner class.

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

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

From bpb at openjdk.org  Wed Jun 22 17:36:49 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 17:36:49 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v10]
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <1B2vhjRE1Kxuh4emqvmNgxuEHaMOPYMWQgbSP9lODKE=.6e330c12-e8d2-463d-b2e9-c751445491d8@github.com>

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

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

  6980847: Clean up initialization of CopyFileEx() flags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9161/files
  - new: https://git.openjdk.org/jdk/pull/9161/files/406656e2..82bbc8b7

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

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

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

From bpb at openjdk.org  Wed Jun 22 17:36:52 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 17:36:52 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <ZL0V1tBVZdaoFetd1LZztIjoZVvuQSTw5S0FE2XVE1E=.725f2bee-bf20-48b8-b4cd-bd8e1812ea39@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
 <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>
 <mBEl523TaTCIph2PZcZCyJeGrMQFKKQW2fJMgZDhj5g=.46712963-b4c9-4dad-9108-0c188b0392de@github.com>
 <ZL0V1tBVZdaoFetd1LZztIjoZVvuQSTw5S0FE2XVE1E=.725f2bee-bf20-48b8-b4cd-bd8e1812ea39@github.com>
Message-ID: <nYQtN6b4uaSB0o-TICLwMxprLEExds_yyAwUl8y7Qfs=.8802f880-8532-4551-b1c6-0605af95ff96@github.com>

On Wed, 22 Jun 2022 17:19:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I did not do that because `flags` is final but I guess it need not be.
>
> Actually `flags` must be final as it is referenced from an inner class.

Addressed in 82bbc8b779befc254093239897e25e5db85e4e0b.

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

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

From alanb at openjdk.org  Wed Jun 22 18:00:03 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 18:00:03 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v10]
In-Reply-To: <1B2vhjRE1Kxuh4emqvmNgxuEHaMOPYMWQgbSP9lODKE=.6e330c12-e8d2-463d-b2e9-c751445491d8@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <1B2vhjRE1Kxuh4emqvmNgxuEHaMOPYMWQgbSP9lODKE=.6e330c12-e8d2-463d-b2e9-c751445491d8@github.com>
Message-ID: <3Pnb1pTaANFpqKf9D_Kca2biU0V8JC7ikTuCu8CD6k4=.768978be-e5ee-4c0b-82f0-f4f493a3350b@github.com>

On Wed, 22 Jun 2022 17:36:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   6980847: Clean up initialization of CopyFileEx() flags

Marked as reviewed by alanb (Reviewer).

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

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

From alanb at openjdk.org  Wed Jun 22 18:00:05 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 22 Jun 2022 18:00:05 GMT
Subject: RFR: 6980847: (fs) Files.copy needs to be tuned [v9]
In-Reply-To: <nYQtN6b4uaSB0o-TICLwMxprLEExds_yyAwUl8y7Qfs=.8802f880-8532-4551-b1c6-0605af95ff96@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
 <rJljjVLRa1jkKKdScrwgbdTOnmEktIddbZbwd0XpVWM=.a8ce7b70-cb6e-4c6a-8b41-34308f75ea40@github.com>
 <RDXR2Q1LpIUTnQ3iGmytF0WMlnjitCyw2FatdrlwfMY=.c7c71710-b6c4-4200-8b71-d950af0cf283@github.com>
 <mBEl523TaTCIph2PZcZCyJeGrMQFKKQW2fJMgZDhj5g=.46712963-b4c9-4dad-9108-0c188b0392de@github.com>
 <ZL0V1tBVZdaoFetd1LZztIjoZVvuQSTw5S0FE2XVE1E=.725f2bee-bf20-48b8-b4cd-bd8e1812ea39@github.com>
 <nYQtN6b4uaSB0o-TICLwMxprLEExds_yyAwUl8y7Qfs=.8802f880-8532-4551-b1c6-0605af95ff96@github.com>
Message-ID: <lPRHggfLMsCapOYJ6qodliC_qR4vlpcFueUPTWxqymw=.df511d96-7dbc-47ed-95eb-d876632316b0@github.com>

On Wed, 22 Jun 2022 17:32:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Actually `flags` must be final as it is referenced from an inner class.
>
> Addressed in 82bbc8b779befc254093239897e25e5db85e4e0b.

I think this update is much more readable - thanks.

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

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

From lancea at openjdk.org  Wed Jun 22 19:12:16 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 22 Jun 2022 19:12:16 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
Message-ID: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>

Hi,

Please review the following patch which will:

- Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods

  - public boolean exists(Path path, LinkOption... options)
  - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)


This change allows for providers to provide optimizations when the file's attributes are not needed.

Mach5 tiers 1 - 3  run clean with this change

The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)


Best,
Lance

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

Commit messages:
 - Add exists and readAttributesIfExists methods to FileSystemProvider

Changes: https://git.openjdk.org/jdk/pull/9249/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9249&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8283335
  Stats: 342 lines in 10 files changed: 177 ins; 129 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

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

From bpb at openjdk.org  Wed Jun 22 19:26:44 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 19:26:44 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1184:

> 1182:      * is present then symbolic links are not followed and the method
> 1183:      *  {@link #readAttributes(Path, Class, LinkOption...)} is called
> 1184:      *  to determine whether a file exists.

Indentation is off at lines 1183-1184.

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:

> 1216: 
> 1217:     /**
> 1218:      * Reads a file's attributes as a bulk operation if it exists.

Maybe instead "it" put "the file"?

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

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

From lancea at openjdk.org  Wed Jun 22 19:58:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 22 Jun 2022 19:58:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
Message-ID: <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>

On Wed, 22 Jun 2022 19:22:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1184:
> 
>> 1182:      * is present then symbolic links are not followed and the method
>> 1183:      *  {@link #readAttributes(Path, Class, LinkOption...)} is called
>> 1184:      *  to determine whether a file exists.
> 
> Indentation is off at lines 1183-1184.

Thanks for catching that.  Will be addressed in the next push

> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:
> 
>> 1216: 
>> 1217:     /**
>> 1218:      * Reads a file's attributes as a bulk operation if it exists.
> 
> Maybe instead "it" put "the file"?

I can if you think that is better.  I followed the wording for `FileSystemProvider::deleteIfExists` trying to be consistent

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

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

From bpb at openjdk.org  Wed Jun 22 20:02:55 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 20:02:55 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <IPv0YFxeV14-LaD8Q4d8Dm8jM7Vix9KwBC58OX-GKIo=.2b614d9f-042f-4a04-b4a1-0524adc24acb@github.com>
 <ei9bYlBnShTRSHKymfi6vP1ktLmdmPAzuMOmIUTCBJE=.5036ae8e-d029-429f-84b6-356dbde3103d@github.com>
Message-ID: <chEKN30cx3l8CKB4OvSIq5TUkKpEBlB-RrqgYh_75x8=.b564b407-93de-4c0e-b117-ab740e596d37@github.com>

On Wed, 22 Jun 2022 19:54:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1218:
>> 
>>> 1216: 
>>> 1217:     /**
>>> 1218:      * Reads a file's attributes as a bulk operation if it exists.
>> 
>> Maybe instead "it" put "the file"?
>
> I can if you think that is better.  I followed the wording for `FileSystemProvider::deleteIfExists` trying to be consistent

Then leave is as is.

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

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

From bpb at openjdk.org  Wed Jun 22 22:21:42 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 22:21:42 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 80:

> 78:     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
> 79:         UnixFileAttributes attrs = new UnixFileAttributes();
> 80:         int errno = UnixNativeDispatcher.stat2(path, attrs);

I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:


    static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
        UnixFileAttributes attrs = new UnixFileAttributes();
        try {
            UnixNativeDispatcher.stat(path, attrs);
            return attrs;
        } catch (UnixException e) {
            if (e.errno() == UnixConstants.ENOENT) {
                return null;
            }
            throw e;
        }
    }

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

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

From bpb at openjdk.org  Wed Jun 22 22:29:38 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 22 Jun 2022 22:29:38 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1236:

> 1234:      * atomic operation with respect to other file system operations.
> 1235:      *
> 1236:      *  @implSpec

One more bad indentation.

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

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

From alanb at openjdk.org  Thu Jun 23 07:21:59 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 07:21:59 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
Message-ID: <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>

On Wed, 22 Jun 2022 22:18:05 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:

The purpose of these additions to the SPI is to improve the performance of user facing methods that don't throw an exception when the file doesn't exist. It needs a stat/equivalent that doesn't throw so this is the reason for stat2. The equivalent on Windows will need to added too.

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

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

From chegar at openjdk.org  Thu Jun 23 08:08:38 2022
From: chegar at openjdk.org (Chris Hegarty)
Date: Thu, 23 Jun 2022 08:08:38 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1202:

> 1200:      */
> 1201:     public boolean exists(Path path, LinkOption... options) {
> 1202:         try {

Overall, I think that this is a great change (avoiding the need for various parts of the system to communicate through exceptions).

Trivially, and easily, I often find it useful to add mock-like tests for these specified implementations (implSpec), i.e. just subclass FSP mocking out the abstract methods to ensure that the default implementations invoke the appropriate ones.

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

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

From alanb at openjdk.org  Thu Jun 23 10:59:53 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 10:59:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

This should be performance neutral for the default provider and positive for the zip provider. Do we have any micros that could be added?

The end date in the copyright header will need updated a few files, I assume you'll do that before this change is integrated.

src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 306:

> 304:                     case WRITE -> w = true;
> 305:                     case EXECUTE -> x = true;
> 306:                     default -> throw new AssertionError("Should not get here");

The switch should be exhaustive so I assume the default case is not required here.

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

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

From alanb at openjdk.org  Thu Jun 23 11:05:43 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 11:05:43 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <_OsO1pbyNGFQJTu5nk16w-Y-c0VIW7T3qrrsZgz32-0=.f31987e8-1eab-4de0-a4da-7f9897981767@github.com>

On Wed, 22 Jun 2022 19:05:41 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

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

> 300:         throws IOException
> 301:     {
> 302:         return exists(path) ? readAttributes(path, type, options) : null;

If you add the following to ZipPath then it would allow you to implement it in one step rather than two:


ZipFileAttributes readAttributesIfExits() throws IOException {
    return zfs.getFileAttributes(getResolvedPath());
 }

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

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

From bpb at openjdk.org  Thu Jun 23 15:39:00 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 15:39:00 GMT
Subject: Integrated: 6980847: (fs) Files.copy needs to be "tuned"
In-Reply-To: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
References: <M3y8gUnePdLeU0LZo6blKVNoI54ti8e-anYAtC7jtXs=.1aebfa41-978e-4b81-aa57-ba11a9699b9c@github.com>
Message-ID: <nEYft9sjVR7_qMkPVlIO1VsFksPbaM6rL0Xg3imExwg=.73d0a200-c3af-4750-b079-676c5546d48e@github.com>

On Wed, 15 Jun 2022 00:20:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify `UnixCopyFile.copyFile()` to set the transfer size to the least common multiple of the source and destination file block sizes if the block sizes are not equal. Modify `WindowsFileCopy.copy()` to set `COPY_FILE_NO_BUFFERING` in the flags passed to `CopyFileEx()` if the size of the transfer is greater than a threshold.

This pull request has now been integrated.

Changeset: b8db0c38
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b8db0c383b6ebd741f6981c89a0cafdfd9751315
Stats:     180 lines in 4 files changed: 148 ins; 4 del; 28 mod

6980847: (fs) Files.copy needs to be "tuned"

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Jun 23 15:42:09 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 15:42:09 GMT
Subject: Integrated: 8287580: (se) CancelledKeyException during channel
 registration
In-Reply-To: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
References: <kfZLzXWBL-pZv5EG7nt9dR4xmex0Npi6M2RrPQi4QAo=.e72652f2-0360-4a10-a36f-5738aec6f9fd@github.com>
Message-ID: <GdRWE_ogqmuyF5ZNZcrWCQDlbkB4A74XkIwuC-c1jU8=.88c00689-46d1-4172-8399-6e32205e5e0b@github.com>

On Wed, 1 Jun 2022 18:32:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Ignore `CancelledKeyException` during registration.

This pull request has now been integrated.

Changeset: 72f286a9
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/72f286a9baecd914b77e3436b999ae432025e992
Stats:     70 lines in 2 files changed: 70 ins; 0 del; 0 mod

8287580: (se) CancelledKeyException during channel registration

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Jun 23 15:43:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 15:43:43 GMT
Subject: Integrated: 8288515: (ch) Unnecessary use of Math.addExact() in
 java.nio.channels.FileLock.overlaps()
In-Reply-To: <HhpqQ-ga3gLF5LSmRtet4DpCq8bHCq2nWqZ7ZdB8dw4=.e7b9d754-e099-4791-9c18-9c87294740cc@github.com>
References: <HhpqQ-ga3gLF5LSmRtet4DpCq8bHCq2nWqZ7ZdB8dw4=.e7b9d754-e099-4791-9c18-9c87294740cc@github.com>
Message-ID: <aJrzuBI-eutpIzGaT8oSbpfYD0vsLUqpGxIoz5Wnzgc=.ea14658d-72c4-4987-bffb-31260eb4799b@github.com>

On Wed, 22 Jun 2022 00:13:35 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `FileLock` checks the immutable `position` and `size` parameters in its constructor hence using `Math.addExact()` on these instance variables in `overlaps()` is needless.

This pull request has now been integrated.

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

8288515: (ch) Unnecessary use of Math.addExact() in java.nio.channels.FileLock.overlaps()

Reviewed-by: alanb

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

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

From naoto at openjdk.org  Thu Jun 23 16:23:12 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 16:23:12 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
Message-ID: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>

Hi all,

This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!LxU5jnW07FHhumoZhrJp9Ww7W_nhfrCqsrJJIqFJC7q7T5O-NavncmReh9uDXIbsPRcmoo3hrylntsCN$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.

Thanks!

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

Commit messages:
 - Backport 2728770e3d73bb11c4d6e54b5aff91588a1a780b

Changes: https://git.openjdk.org/jdk19/pull/61/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=61&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8288589
  Stats: 231 lines in 4 files changed: 143 ins; 68 del; 20 mod
  Patch: https://git.openjdk.org/jdk19/pull/61.diff
  Fetch: git fetch https://git.openjdk.org/jdk19 pull/61/head:pull/61

PR: https://git.openjdk.org/jdk19/pull/61

From iris at openjdk.org  Thu Jun 23 17:13:00 2022
From: iris at openjdk.org (Iris Clark)
Date: Thu, 23 Jun 2022 17:13:00 GMT
Subject: RFR: 8288589: Files.readString ignores encoding errors for UTF-16
In-Reply-To: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
References: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
Message-ID: <o8-Lv2IY3q2qmTDScyIcp7tmlH644X0Y92nKO0ImJ40=.eedb7dc4-1857-4c14-b1c3-4f81143e85cc@github.com>

On Thu, 23 Jun 2022 16:12:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!IAjwXZuHdCNMx12TjwRydl7U60vqneuhSWGP8gHwRZSd-bOE1JeXbyvZCyYHZVGGDFGn-pSUe4SLb34$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.
> 
> Thanks!

Looks like a clean backport of the change in main-line.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/61

From naoto at openjdk.org  Thu Jun 23 17:13:01 2022
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 23 Jun 2022 17:13:01 GMT
Subject: Integrated: 8288589: Files.readString ignores encoding errors for
 UTF-16
In-Reply-To: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
References: <TO2Ons07E64ZZnsdK-2CnXrTazDTgIMTUQkxhHzliTU=.13a35610-a463-4377-b0d2-f26200c3a6fc@github.com>
Message-ID: <0mMV1oEIvmVrhVeuGIkdn8IME358T5r5y2ZdKMSjNgg=.bec849b8-2c0d-4966-b00c-32f7dd71dc8a@github.com>

On Thu, 23 Jun 2022 16:12:31 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [2728770e](https://urldefense.com/v3/__https://github.com/openjdk/jdk/commit/2728770e3d73bb11c4d6e54b5aff91588a1a780b__;!!ACWV5N9M2RV99hQ!I7bS7g_wLZwmbglP__yrBLFdocpANIqRGeDuht7t2YvWW3d8eUzmzHtAPjIux5OadqVtK-6adh6VMZmr$ ) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Naoto Sato on 23 Jun 2022 and was reviewed by Roger Riggs, Iris Clark and Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: a716f793
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/a716f7934b2ce8078c27df4c87e8c1e9cceed000
Stats:     231 lines in 4 files changed: 143 ins; 68 del; 20 mod

8288589: Files.readString ignores encoding errors for UTF-16

Backport-of: 2728770e3d73bb11c4d6e54b5aff91588a1a780b

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

PR: https://git.openjdk.org/jdk19/pull/61

From bpb at openjdk.org  Thu Jun 23 17:43:14 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 17:43:14 GMT
Subject: RFR: 8289073: (fs) UnsatisfiedLinkError for
 sun.nio.fs.UnixCopyFile.bufferedCopy0()
Message-ID: <SMKJehelPdN2SPJEHBBQ4_7Ot9Bw3nNuryUQMHwXWzE=.d9034e59-4463-4c96-8ba5-13e41c150d57@github.com>

Change C function from `Java_sun_nio_fs_UnixCopyFile_bufferCopy0` to `Java_sun_nio_fs_UnixCopyFile_bufferedCopy0`.

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

Commit messages:
 - 8289073: (fs) UnsatisfiedLinkError for sun.nio.fs.UnixCopyFile.bufferedCopy0()

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

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

From alanb at openjdk.org  Thu Jun 23 17:47:51 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Jun 2022 17:47:51 GMT
Subject: RFR: 8289073: (fs) UnsatisfiedLinkError for
 sun.nio.fs.UnixCopyFile.bufferedCopy0()
In-Reply-To: <SMKJehelPdN2SPJEHBBQ4_7Ot9Bw3nNuryUQMHwXWzE=.d9034e59-4463-4c96-8ba5-13e41c150d57@github.com>
References: <SMKJehelPdN2SPJEHBBQ4_7Ot9Bw3nNuryUQMHwXWzE=.d9034e59-4463-4c96-8ba5-13e41c150d57@github.com>
Message-ID: <aaBiFQBNOF7TaWh605XVzyjM6Bj7cPdgK31NZUJxNCA=.67fc00c5-a8af-4714-ba1d-e57090c4acb3@github.com>

On Thu, 23 Jun 2022 17:36:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change C function from `Java_sun_nio_fs_UnixCopyFile_bufferCopy0` to `Java_sun_nio_fs_UnixCopyFile_bufferedCopy0`.

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Thu Jun 23 17:51:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 17:51:15 GMT
Subject: Integrated: 8289073: (fs) UnsatisfiedLinkError for
 sun.nio.fs.UnixCopyFile.bufferedCopy0()
In-Reply-To: <SMKJehelPdN2SPJEHBBQ4_7Ot9Bw3nNuryUQMHwXWzE=.d9034e59-4463-4c96-8ba5-13e41c150d57@github.com>
References: <SMKJehelPdN2SPJEHBBQ4_7Ot9Bw3nNuryUQMHwXWzE=.d9034e59-4463-4c96-8ba5-13e41c150d57@github.com>
Message-ID: <HoWHuixBhCl8D5XtLwjVl23QRxioFOROzvDRriD3vIM=.db4918c6-fa53-4a85-859f-d784a01a7102@github.com>

On Thu, 23 Jun 2022 17:36:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change C function from `Java_sun_nio_fs_UnixCopyFile_bufferCopy0` to `Java_sun_nio_fs_UnixCopyFile_bufferedCopy0`.

This pull request has now been integrated.

Changeset: 13cbb3a4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/13cbb3a4169fdbf882da70beaa1b88faca2bc9c8
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8289073: (fs) UnsatisfiedLinkError for sun.nio.fs.UnixCopyFile.bufferedCopy0()

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Jun 23 21:53:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 21:53:05 GMT
Subject: RFR: 8289095: (fs) UnixCopyFile build error on linux-x86
Message-ID: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>

Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

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

Commit messages:
 - 8289095: (fs) UnixCopyFile build error on linux-x86

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

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

From bpb at openjdk.org  Thu Jun 23 21:53:05 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 21:53:05 GMT
Subject: RFR: 8289095: (fs) UnixCopyFile build error on linux-x86
In-Reply-To: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
References: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
Message-ID: <T1lrwRv0FcR0qQATTacMeh_aWgHtsby6RjmLReZbNUo=.b4969484-8dce-4426-889c-319879a78f42@github.com>

On Thu, 23 Jun 2022 21:46:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

The linux-x86 build still fails for other reasons, but as it reports `Creating support/native/java.base/libnio/static/libnio.a from 22 file(s)` with no errors observed, this particular change appears correct.

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

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

From bpb at openjdk.org  Thu Jun 23 22:59:25 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 22:59:25 GMT
Subject: RFR: 8288080: (fc) FileChannel::map for MemorySegments should state it
 always throws UOE
Message-ID: <ld_znNkre_6v9jZSQwYAKv2mXMYXz67LvMHJ6Q6EGiM=.7cd46130-db88-4fb9-8a78-d971de690fd9@github.com>

`FileChannel::map` for `MemorySegment`s should state it always throws UOE.

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

Commit messages:
 - Backport a9c2ab67c44872ce0247aef6bf972bf4246b44be

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

PR: https://git.openjdk.org/jdk19/pull/63

From bpb at openjdk.org  Thu Jun 23 23:00:23 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 23 Jun 2022 23:00:23 GMT
Subject: Integrated: 8288080: (fc) FileChannel::map for MemorySegments should
 state it always throws UOE
In-Reply-To: <ld_znNkre_6v9jZSQwYAKv2mXMYXz67LvMHJ6Q6EGiM=.7cd46130-db88-4fb9-8a78-d971de690fd9@github.com>
References: <ld_znNkre_6v9jZSQwYAKv2mXMYXz67LvMHJ6Q6EGiM=.7cd46130-db88-4fb9-8a78-d971de690fd9@github.com>
Message-ID: <nimKZRdhO6tuoooOWFEiUHQIrq6PjQkXXnzcrTgvMPk=.ab381d94-4cc4-484b-a1a8-eb72fd760eb5@github.com>

On Thu, 23 Jun 2022 22:43:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `FileChannel::map` for `MemorySegment`s should state it always throws UOE.

This pull request has now been integrated.

Changeset: 651cbebb
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/651cbebb96fc60e5db48ea68d38cbeb76b007550
Stats:     3 lines in 1 file changed: 3 ins; 0 del; 0 mod

8288080: (fc) FileChannel::map for MemorySegments should state it always throws UOE

Backport-of: a9c2ab67c44872ce0247aef6bf972bf4246b44be

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

PR: https://git.openjdk.org/jdk19/pull/63

From alanb at openjdk.org  Fri Jun 24 06:59:55 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Jun 2022 06:59:55 GMT
Subject: RFR: 8289095: (fs) UnixCopyFile build error on linux-x86
In-Reply-To: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
References: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
Message-ID: <YsmY75YgNsfRtvsgWBjQQ4BGuogpdXFbpruFise_b6E=.d82e3fd4-7640-40c9-a429-bea5ac4c8000@github.com>

On Thu, 23 Jun 2022 21:46:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

Marked as reviewed by alanb (Reviewer).

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

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

From shade at openjdk.org  Fri Jun 24 09:32:04 2022
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 24 Jun 2022 09:32:04 GMT
Subject: RFR: 8289095: (fs) UnixCopyFile build error on linux-x86
In-Reply-To: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
References: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
Message-ID: <vJkU_LgzIVDr2I66FfUBU6qTJm34L2kJV841o7pOKpk=.5dc65b5f-dd8d-41bf-b209-e6ef8dd94be1@github.com>

On Thu, 23 Jun 2022 21:46:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

Looks fine and trivial.

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

Marked as reviewed by shade (Reviewer).

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

From lancea at openjdk.org  Fri Jun 24 10:44:02 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:02 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <1ckyd2CtHpn1rHvV7b914_tXO5TGyEyisQ5zhEeogZ8=.ce9d6888-5597-4bd7-9c57-409d00d39cfa@github.com>
Message-ID: <rD6jcDzF0NmgyR3TwEhpurDXWwrDst9SSbdBFm3otI4=.bac25390-eb44-4339-9eb3-a0c8a77e51d8@github.com>

On Thu, 23 Jun 2022 08:05:42 GMT, Chris Hegarty <chegar at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1202:
> 
>> 1200:      */
>> 1201:     public boolean exists(Path path, LinkOption... options) {
>> 1202:         try {
> 
> Overall, I think that this is a great change (avoiding the need for various parts of the system to communicate through exceptions).
> 
> Trivially, and easily, I often find it useful to add mock-like tests for these specified implementations (implSpec), i.e. just subclass FSP mocking out the abstract methods to ensure that the default implementations invoke the appropriate ones.

Thank you for the suggestion Chris

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

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

From lancea at openjdk.org  Fri Jun 24 10:44:05 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:05 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <I-ppIZSAK4brd84-OgItZPnleOjCRlcl2SgHMOmDc9I=.ecc9fea8-35e9-40b0-99da-0d93a3e9e01d@github.com>
Message-ID: <SRuEjy1ZbnFOmhQL9bXvTK1i0kXWfkdYbq6b0GmWIw8=.37d9fe4c-ecf5-4f55-9fe8-e82c98b79d59@github.com>

On Wed, 22 Jun 2022 22:26:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/share/classes/java/nio/file/spi/FileSystemProvider.java line 1236:
> 
>> 1234:      * atomic operation with respect to other file system operations.
>> 1235:      *
>> 1236:      *  @implSpec
> 
> One more bad indentation.

fixed in next push

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

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

From lancea at openjdk.org  Fri Jun 24 10:44:08 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 24 Jun 2022 10:44:08 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <taLnH5D0kcjcyoCbgSdY6DC5S2IOli1noHXIRU7u91o=.d8d04a00-74c2-4b49-88e6-e3d97886a220@github.com>
Message-ID: <rR1rRsQwWAJWs2t1nAjYkL_IKoZovw-Exiej5_FJq-Q=.3dc26b1d-032c-4af2-bee4-b9a0e009b505@github.com>

On Thu, 23 Jun 2022 10:55:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java line 306:
> 
>> 304:                     case WRITE -> w = true;
>> 305:                     case EXECUTE -> x = true;
>> 306:                     default -> throw new AssertionError("Should not get here");
> 
> The switch should be exhaustive so I assume the default case is not required here.

Addressed in next push

> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 302:
> 
>> 300:         throws IOException
>> 301:     {
>> 302:         return exists(path) ? readAttributes(path, type, options) : null;
> 
> If you add the following to ZipPath then it would allow you to implement it in one step rather than two:
> 
> 
> ZipFileAttributes readAttributesIfExits() throws IOException {
>     return zfs.getFileAttributes(getResolvedPath());
>  }

Added the proposed change above, Mach5 tiers 1-3 continue to be clean

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

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

From stuefe at openjdk.org  Fri Jun 24 13:22:14 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Jun 2022 13:22:14 GMT
Subject: RFR: JDK-8289143: JDK-6980847 broke 32-bit builds
Message-ID: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>

Trivial fix to get 32-bit to build again.

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

Commit messages:
 - use jlong_to_ptr

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

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

From rriggs at openjdk.org  Fri Jun 24 13:35:41 2022
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 24 Jun 2022 13:35:41 GMT
Subject: RFR: JDK-8289143: JDK-6980847 broke 32-bit builds
In-Reply-To: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
References: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
Message-ID: <70_YOeLQlS8GwKr6V_fN7Rdq5qYPZoAt8XEFKlQNmx8=.d82360fe-7bff-4bc5-b7d7-3bea1303cf7d@github.com>

On Fri, 24 Jun 2022 13:14:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to get 32-bit to build again.

LGTM

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

Marked as reviewed by rriggs (Reviewer).

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

From alanb at openjdk.org  Fri Jun 24 13:44:42 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Jun 2022 13:44:42 GMT
Subject: RFR: JDK-8289143: JDK-6980847 broke 32-bit builds
In-Reply-To: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
References: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
Message-ID: <GOywmBocfSBYTtATUDY1K6XvMEcDQLyWonQRhDE8_28=.8f5734d6-d8cf-48be-88b6-a9c4397648eb@github.com>

On Fri, 24 Jun 2022 13:14:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to get 32-bit to build again.

Oh, I closed this JBS issue as a dup of JDK-8289095 before seeing there is a PR. The PR for JDK-8289095 is PR9265.

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

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

From stuefe at openjdk.org  Fri Jun 24 13:52:04 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Jun 2022 13:52:04 GMT
Subject: RFR: 8289095: (fs) UnixCopyFile build error on linux-x86
In-Reply-To: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
References: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
Message-ID: <W-i3Lk5WiVrwTsmUcvrBkA_bLtCFh_0TJrt9mSaEIAo=.a2b328f6-da82-4d6e-8938-68fb11fd82c6@github.com>

On Thu, 23 Jun 2022 21:46:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

Marked as reviewed by stuefe (Reviewer).

Looks good. I will close the duplicate I opened accidentally (https://bugs.openjdk.org/browse/JDK-8289143).

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

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

From stuefe at openjdk.org  Fri Jun 24 13:54:59 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Jun 2022 13:54:59 GMT
Subject: RFR: JDK-8289143: JDK-6980847 broke 32-bit builds
In-Reply-To: <GOywmBocfSBYTtATUDY1K6XvMEcDQLyWonQRhDE8_28=.8f5734d6-d8cf-48be-88b6-a9c4397648eb@github.com>
References: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
 <GOywmBocfSBYTtATUDY1K6XvMEcDQLyWonQRhDE8_28=.8f5734d6-d8cf-48be-88b6-a9c4397648eb@github.com>
Message-ID: <XyfxtWASNSoUlA312soSvyyLoz6m4uxfvRPpJLQ6uT4=.0879fa3d-e749-4bc9-93c0-be6041328602@github.com>

On Fri, 24 Jun 2022 13:41:28 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Oh, I closed this JBS issue as a dup of JDK-8289095 before seeing there is a PR. The PR for JDK-8289095 is PR9265.

No problem, I close this PR then.

Cheers, Thomas

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

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

From stuefe at openjdk.org  Fri Jun 24 13:55:01 2022
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 24 Jun 2022 13:55:01 GMT
Subject: Withdrawn: JDK-8289143: JDK-6980847 broke 32-bit builds
In-Reply-To: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
References: <XTv-Dy12OhO9LlpMFfYrN_QMIsCiZZDKGBSdG8Z98N0=.ec14eebd-3e43-4922-a8bc-41cf5ae3c298@github.com>
Message-ID: <p5u5cmx2EY2MJCMlFGRHtnGhFRoC4jxBFboLPi4jVI8=.b5a6bfd6-bf36-400e-895f-15e9f271ba72@github.com>

On Fri, 24 Jun 2022 13:14:07 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Trivial fix to get 32-bit to build again.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Fri Jun 24 14:27:16 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 14:27:16 GMT
Subject: Integrated: 8289095: (fs) UnixCopyFile build error on linux-x86
In-Reply-To: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
References: <VkFzDXyJjQ8QSgZDKA3ZHCYVUu82ffeb0AusBwIuy2U=.5911a443-49c3-46a3-8938-2d266814a924@github.com>
Message-ID: <LtmYET_I7fk9z6i8-kcHSOKI1UXNgCkJ4UriQYphYuk=.4dcb9e9b-e659-4a00-85e4-bac5cdfe3064@github.com>

On Thu, 23 Jun 2022 21:46:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Use `(char*)jlong_to_ptr(address)` instead of the straight cast `(char*)address`.

This pull request has now been integrated.

Changeset: 239b4bb0
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/239b4bb0201fda8c40daf2f3e733dab0086d356c
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8289095: (fs) UnixCopyFile build error on linux-x86

Reviewed-by: alanb, shade, stuefe

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

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

From bpb at openjdk.org  Fri Jun 24 19:14:41 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 24 Jun 2022 19:14:41 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider
In-Reply-To: <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <Dho3DWC5sQTgYpk2EhWDIMz6cm19GdQS5Z3gjiLR05E=.578cdb7b-9e2b-4d2d-8773-5ebf63d3372e@github.com>
 <1qiIHaDvqIOqcxO0EybhwUiHd7dp0ujZUxTw1JHEhOQ=.56b7421b-f95a-4702-ace4-b36128811445@github.com>
Message-ID: <9wcML2Y3kBIA79rKn1H2Tf3gDpeugH90j-Wh02aXd2M=.8e86d8e4-0061-4709-94ee-1fe2c5bae2ec@github.com>

On Thu, 23 Jun 2022 07:18:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileAttributes.java line 80:
>> 
>>> 78:     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
>>> 79:         UnixFileAttributes attrs = new UnixFileAttributes();
>>> 80:         int errno = UnixNativeDispatcher.stat2(path, attrs);
>> 
>> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:
>> 
>> 
>>     static UnixFileAttributes getIfExists(UnixPath path) throws UnixException {
>>         UnixFileAttributes attrs = new UnixFileAttributes();
>>         try {
>>             UnixNativeDispatcher.stat(path, attrs);
>>             return attrs;
>>         } catch (UnixException e) {
>>             if (e.errno() == UnixConstants.ENOENT) {
>>                 return null;
>>             }
>>             throw e;
>>         }
>>     }
>
>> I think that this is the only use of `stat2()`. It could be deleted if this method were replaced with this:
> 
> The purpose of these additions to the SPI is to improve the performance of user facing methods that don't throw an exception when the file doesn't exist. It needs a stat/equivalent that doesn't throw so this is the reason for stat2. The equivalent on Windows will need to added too.

Understood.

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

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

From lancea at openjdk.org  Sun Jun 26 11:13:58 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 11:13:58 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

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

  Updates based on review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/d2bd45c4..37b7462f

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

  Stats: 612 lines in 8 files changed: 603 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

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

From alanb at openjdk.org  Sun Jun 26 13:16:52 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Jun 2022 13:16:52 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
Message-ID: <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>

On Sun, 26 Jun 2022 11:13:58 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Hi,
>> 
>> Please review the following patch which will:
>> 
>> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
>> 
>>   - public boolean exists(Path path, LinkOption... options)
>>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
>> 
>> 
>> This change allows for providers to provide optimizations when the file's attributes are not needed.
>> 
>> Mach5 tiers 1 - 3  run clean with this change
>> 
>> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
>> 
>> 
>> Best,
>> Lance
>
> Lance Andersen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updates based on review feedback

The implementation changes in latest version address my previous points, thanks!  I don't the test as it duplicates most of the existing of the TestProvider in this directory and the naming is inconsistent with the existing tests. I expect you should be able to just extent TestProvider and override the two methods to record that they can been called.

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

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

From lancea at openjdk.org  Sun Jun 26 13:36:34 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 13:36:34 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
 <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
Message-ID: <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>

On Sun, 26 Jun 2022 13:13:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The implementation changes in latest version address my previous points, thanks! I don't the test as it duplicates most of the existing of the TestProvider in this directory and the naming is inconsistent with the existing tests. I expect you should be able to just extent TestProvider and override the two methods to record that they can been called.

I thought about using TestProvider and then talked myself out of it.  So yes, I can do that.  If you have a preferred name other than `TestOverRideFSPMethods` please let me know

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

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

From lancea at openjdk.org  Sun Jun 26 13:51:53 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 26 Jun 2022 13:51:53 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v3]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <_WsFCTuVK9k_tTIbnbxtDE6fOtUuLnxEOT21AxFVZ9E=.fb149471-1241-4595-933c-a547ee7dc468@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

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

  Switched Test to use TestProvideer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/37b7462f..6ef8bc1f

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

  Stats: 596 lines in 3 files changed: 57 ins; 529 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

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

From alanb at openjdk.org  Mon Jun 27 09:30:45 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 09:30:45 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v2]
In-Reply-To: <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
 <-CnmkklyHzh9iBfqTvy89YUiG35zb5OkC6NTxGSb1lM=.b34bc9d7-3728-43ac-8cf9-610489cf041e@github.com>
 <lBYfnG9zAaQ_dYYChCqpVuXwuChFY917ApF-z2m2GNA=.2a42bf65-3d5d-4190-90fc-e095d1542e4f@github.com>
 <lYQFAewhb7no6q9Cj1QEdGvsVRWNBFrZegQtHXDFyCg=.b5e705a1-df46-4993-a963-f490de1e87f3@github.com>
Message-ID: <qL6dAmvAXIWS4DKBKwQSliLIjHr3oV-ajHSo5dPxH9I=.685c6d8d-f7ce-4f83-b6ee-68c09a4282d8@github.com>

On Sun, 26 Jun 2022 13:33:40 GMT, Lance Andersen <lancea at openjdk.org> wrote:

> I thought about using TestProvider and then talked myself out of it. So yes, I can do that. If you have a preferred name other than `TestOverRideFSPMethods` please let me know

The only change that should be needed to TestProvider is to implement the checkAccess method with:


        Path delegate = theFileSystem.unwrap(file);
        defaultProvider.checkAccess(delegate, modes);


With that change it should be easy to extend and override exists/readAttributesIfExists to record that they are called. The need to run with the test with -Djava.nio.file.spi.DefaultFileSystemProvider=TestProvider goes away too and and should be much simpler to test that the expected delegation.

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

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

From lancea at openjdk.org  Mon Jun 27 16:43:55 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Jun 2022 16:43:55 GMT
Subject: RFR: 8283335 : Add exists and readAttributesIfExists methods to
 FileSystemProvider [v4]
In-Reply-To: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
References: <TXkckUReYCvgJBjMIHll2D6RR-wwatdTtiyH6orFv3o=.ed71c74e-6647-485d-9bed-e86f41e1e99f@github.com>
Message-ID: <aV6q_IIiScb9nwEkL56yfTHFHOOSKhh70qQ9ZRiQmAY=.614fc7b1-599d-47e9-9c7f-71e79370ae11@github.com>

> Hi,
> 
> Please review the following patch which will:
> 
> - Enhance the java.nio.file.spi.FileSystemProvider abstract class to include the methods
> 
>   - public boolean exists(Path path, LinkOption... options)
>   - public <A extends BasicFileAttributes> A readAttributesIfExists(Path path, Class<A> type, LinkOption... options)
> 
> 
> This change allows for providers to provide optimizations when the file's attributes are not needed.
> 
> Mach5 tiers 1 - 3  run clean with this change
> 
> The CSR may be viewed at [JDK-8283336](https://bugs.openjdk.org/browse/JDK-8283336)
> 
> 
> Best,
> Lance

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

  Updated tests based on feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9249/files
  - new: https://git.openjdk.org/jdk/pull/9249/files/6ef8bc1f..63b97ce3

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

  Stats: 293 lines in 3 files changed: 156 ins; 133 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/9249.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9249/head:pull/9249

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

From bpb at openjdk.org  Mon Jun 27 19:33:15 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Jun 2022 19:33:15 GMT
Subject: [jdk19] RFR: 8288836: (fs) Files.writeString spec for IOException has
 "specified charset" when no charset is provided
Message-ID: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>

Change "specified charset" to "UTF-8" in specification of `IOException` thrown by `Files.writeString(Path path, CharSequence csq, OpenOption... options)`.

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

Commit messages:
 - 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided

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

PR: https://git.openjdk.org/jdk19/pull/79

From alanb at openjdk.org  Mon Jun 27 19:48:38 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 27 Jun 2022 19:48:38 GMT
Subject: [jdk19] RFR: 8288836: (fs) Files.writeString spec for IOException
 has "specified charset" when no charset is provided
In-Reply-To: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
References: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
Message-ID: <1hHZk3lE7VnguYUBoLsEumHUJojEvkBs4qvV5NOvZOY=.0383f3a2-0d70-43fa-8f05-04392f9cc98c@github.com>

On Mon, 27 Jun 2022 19:23:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change "specified charset" to "UTF-8" in specification of `IOException` thrown by `Files.writeString(Path path, CharSequence csq, OpenOption... options)`.

Marked as reviewed by alanb (Reviewer).

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

PR: https://git.openjdk.org/jdk19/pull/79

From lancea at openjdk.org  Mon Jun 27 19:48:39 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 27 Jun 2022 19:48:39 GMT
Subject: [jdk19] RFR: 8288836: (fs) Files.writeString spec for IOException
 has "specified charset" when no charset is provided
In-Reply-To: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
References: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
Message-ID: <U0hIJgP9AQ6ZDSTygEmhkGCEg2UJjIItA88pYcu_qXU=.5e8f7573-21ba-4c5d-948d-6cd3f070bdad@github.com>

On Mon, 27 Jun 2022 19:23:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change "specified charset" to "UTF-8" in specification of `IOException` thrown by `Files.writeString(Path path, CharSequence csq, OpenOption... options)`.

Looks OK to me B.

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

Marked as reviewed by lancea (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/79

From iris at openjdk.org  Mon Jun 27 21:24:39 2022
From: iris at openjdk.org (Iris Clark)
Date: Mon, 27 Jun 2022 21:24:39 GMT
Subject: [jdk19] RFR: 8288836: (fs) Files.writeString spec for IOException
 has "specified charset" when no charset is provided
In-Reply-To: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
References: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
Message-ID: <eQCCadK5-lIEpJB-vkVmVVw3tF1sIXqNxqbkEJ11WGU=.7c4f685e-706b-4c2a-a766-888ba314a4e4@github.com>

On Mon, 27 Jun 2022 19:23:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change "specified charset" to "UTF-8" in specification of `IOException` thrown by `Files.writeString(Path path, CharSequence csq, OpenOption... options)`.

Associated CSR also Reviewed.

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

Marked as reviewed by iris (Reviewer).

PR: https://git.openjdk.org/jdk19/pull/79

From bpb at openjdk.org  Mon Jun 27 21:29:43 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 27 Jun 2022 21:29:43 GMT
Subject: [jdk19] RFR: 8288836: (fs) Files.writeString spec for IOException
 has "specified charset" when no charset is provided
In-Reply-To: <eQCCadK5-lIEpJB-vkVmVVw3tF1sIXqNxqbkEJ11WGU=.7c4f685e-706b-4c2a-a766-888ba314a4e4@github.com>
References: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
 <eQCCadK5-lIEpJB-vkVmVVw3tF1sIXqNxqbkEJ11WGU=.7c4f685e-706b-4c2a-a766-888ba314a4e4@github.com>
Message-ID: <Tkeco4GhbOT-W5BYpWstF_eYrRjddynI-IuTUT1IcSs=.4c46cca5-3a6d-45ec-8021-fc3959a19827@github.com>

On Mon, 27 Jun 2022 21:22:36 GMT, Iris Clark <iris at openjdk.org> wrote:

> Associated CSR also Reviewed.

Thanks, @irisclark !

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

PR: https://git.openjdk.org/jdk19/pull/79

From tsteele at openjdk.org  Tue Jun 28 13:18:25 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Tue, 28 Jun 2022 13:18:25 GMT
Subject: RFR: 8288627: [AIX] Implement WatchService using system library
Message-ID: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>

This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java.

I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon.

### Testing
I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`:

- Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation.
- DeleteInterference.java fails for the same reason as above.
- UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so.

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

Commit messages:
 - Revert changes to WatchService/Basic.java
 - Implement AixWatchService, AixWatchKey, & AhafsPoller on AIX.

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

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

From alanb at openjdk.org  Tue Jun 28 13:18:26 2022
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Jun 2022 13:18:26 GMT
Subject: RFR: 8288627: [AIX] Implement WatchService using system library
In-Reply-To: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>
References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>
Message-ID: <rsSzt_1kROnVyui3oywKylAtxH9wDs6heiMj_f5Z_UE=.7754a4a8-1381-4e94-a519-1d620f6c37d6@github.com>

On Fri, 24 Jun 2022 15:17:47 GMT, Tyler Steele <tsteele at openjdk.org> wrote:

> This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java.
> 
> I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon.
> 
> ### Testing
> I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`:
> 
> - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation.
> - DeleteInterference.java fails for the same reason as above.
> - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so.

test/jdk/java/nio/file/WatchService/Basic.java line 77:

> 75:         if (!expectedContext.equals(event.context())) {
> 76:             System.out.format("context: %s (%s) | expected: %s (%s)", event.context(), event.context().getClass(), expectedContext, expectedContext.getClass());
> 77:             throw new RuntimeException("unexpected context: " + event.context() +

If you are changing the test then please try to keep it consistent with the existing code if possible. In this case, adding a 150+ line is a bit annoying as it will mess up all future side-by-side diffs.

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

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

From tsteele at openjdk.org  Tue Jun 28 13:18:26 2022
From: tsteele at openjdk.org (Tyler Steele)
Date: Tue, 28 Jun 2022 13:18:26 GMT
Subject: RFR: 8288627: [AIX] Implement WatchService using system library
In-Reply-To: <rsSzt_1kROnVyui3oywKylAtxH9wDs6heiMj_f5Z_UE=.7754a4a8-1381-4e94-a519-1d620f6c37d6@github.com>
References: <3Vr3_Xpkj94Gq6-WqZPwGOWhRMApWqh0TMEFjGRavl4=.4344fb2d-7ca6-4021-9088-34e8ff376dfd@github.com>
 <rsSzt_1kROnVyui3oywKylAtxH9wDs6heiMj_f5Z_UE=.7754a4a8-1381-4e94-a519-1d620f6c37d6@github.com>
Message-ID: <7XyfSIsdRUWP4VwpJgu--2UtyFjDKyyy_iy8LK96SvM=.4173d266-3e46-4526-82cb-09817bc458de@github.com>

On Fri, 24 Jun 2022 17:36:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This PR begins an effort to re-implement the WatchService API on AIX using 'AIX Event Infrastructure' (AHAFS). The initial motivation for doing so was to address errors found by some internal testing in the implementation based on PollingWatchService.java.
>> 
>> I am submitting these changes before they are fully complete because (1) it represents a fairly large change that mostly works well, and could easily be improved upon in the future; (2) to get some early feedback on the changes so the final review process is quicker. My expected plan is to merge these changes after review, add any remaining test failures to a problem list, and return to them soon.
>> 
>> ### Testing
>> I am waiting for confirmation that this re-implementation passes the internal tests we saw failing. Initial results look promising. In addition, I see the following failing tests from `test/jdk/java/nio/file/WatchService`:
>> 
>> - Basic.java fails at testTwoWatchers. Having two WatchService instances registered with the same file, will require some additional work to be supported with AHAFS. This is currently a limitation of this implementation.
>> - DeleteInterference.java fails for the same reason as above.
>> - UpdateInterference.java fails for no good reason that I can deduce. Logging the test's progress shows that it doesn't seem to leave [the main loop](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/WatchService/UpdateInterference.java#L97-L111), but that it makes is to within 1ms of doing so.
>
> test/jdk/java/nio/file/WatchService/Basic.java line 77:
> 
>> 75:         if (!expectedContext.equals(event.context())) {
>> 76:             System.out.format("context: %s (%s) | expected: %s (%s)", event.context(), event.context().getClass(), expectedContext, expectedContext.getClass());
>> 77:             throw new RuntimeException("unexpected context: " + event.context() +
> 
> If you are changing the test then please try to keep it consistent with the existing code if possible. In this case, adding a 150+ line is a bit annoying as it will mess up all future side-by-side diffs.

Fair comment. Though, I actually wasn't looking to change the test, I just overlooked this when I removed some changes I had made to help me debug an issue. I have now reverted this change to the test as well.

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

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

From bpb at openjdk.org  Tue Jun 28 15:10:47 2022
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 28 Jun 2022 15:10:47 GMT
Subject: [jdk19] Integrated: 8288836: (fs) Files.writeString spec for
 IOException has "specified charset" when no charset is provided
In-Reply-To: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
References: <7EYZhzRZIC2TVImIl8C7Ly_NF97DmdV-d2xzH7ovdSk=.d32867ef-ff40-4486-8aa3-e1e87feec08a@github.com>
Message-ID: <unkcaK8i9zxPgHN5oXCnL0Bx5dHoZ0juhmWKHfDk2iU=.23bef338-2120-45eb-bdec-4f02528f2004@github.com>

On Mon, 27 Jun 2022 19:23:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Change "specified charset" to "UTF-8" in specification of `IOException` thrown by `Files.writeString(Path path, CharSequence csq, OpenOption... options)`.

This pull request has now been integrated.

Changeset: 6f9717b4
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk19/commit/6f9717b46b0e4461100a27276a3ea1186e8c628b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided

Reviewed-by: alanb, lancea, iris

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

PR: https://git.openjdk.org/jdk19/pull/79

From jwilhelm at openjdk.org  Tue Jun 28 21:21:12 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 21:21:12 GMT
Subject: RFR: Merge jdk19
Message-ID: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>

Forwardport JDK 19 -> JDK 20

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

Commit messages:
 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8289398: ProblemList jdk/jfr/api/consumer/recordingstream/TestOnEvent.java on linux-x64 again
 - 8289069: Very slow C1 arraycopy jcstress tests after JDK-8279886
 - 8288058: Broken links on constant-values page
 - 8275784: Bogus warning generated for record with compact constructor
 - 8288836: (fs) Files.writeString spec for IOException has "specified charset" when no charset is provided
 - 8288425: Footprint regression due MH creation when initializing StringConcatFactory
 - 8289228: SegmentAllocator::allocateArray null handling is too lax
 - 8288445: AArch64: C2 compilation fails with guarantee(!true || (true && (shift != 0))) failed: impossible encoding
 - 8289251: ProblemList java/lang/ref/OOMEInReferenceHandler.java
 - ... and 7 more: https://git.openjdk.org/jdk/compare/af008807...d57b485f

The webrevs contain the adjustments done while merging with regards to each parent branch:
 - master: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.0
 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=00.1

Changes: https://git.openjdk.org/jdk/pull/9315/files
  Stats: 821 lines in 29 files changed: 612 ins; 71 del; 138 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

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

From jwilhelm at openjdk.org  Tue Jun 28 22:17:08 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:08 GMT
Subject: RFR: Merge jdk19 [v2]
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <cubHA4OFa8jwOIA-LZWGABo7MOx2vWK4HxANnyER4kM=.ebc33bd9-ee29-4dc6-8d77-98203c0ffcc4@github.com>

> Forwardport JDK 19 -> JDK 20

Jesper Wilhelmsson has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 166 commits:

 - Merge remote-tracking branch 'jdk19/master' into Merge_jdk19
 - 8284640: CollectorImpl class could be a record class
   
   Reviewed-by: phh, rriggs
 - 8288961: jpackage: test MSI installation fix
   
   Reviewed-by: asemenyuk, almatvee
 - 8288013: jpackage: test utility Windows registry enhancement
   
   Reviewed-by: asemenyuk, almatvee
 - 8289071: Compute allocation sizes of stubs and nmethods outside of lock protection
   
   Reviewed-by: thartmann, phh
 - 8271252: os::reserve_memory should not use mtOther as default NMT flag
   
   Reviewed-by: zgu
 - 8287818: Shenandoah: adapt nmethod arming from Loom
   
   Reviewed-by: shade
 - 8289138: G1: Remove redundant is-marking-active checks in C1 barrier
   
   Reviewed-by: tschatzl, ehelin
 - 8288396: Always create reproducible builds
   
   Reviewed-by: amenkov, ehelin
 - 8289258: ProblemList some failing custom loader tests with ZGC
   
   Reviewed-by: dholmes
 - ... and 156 more: https://git.openjdk.org/jdk/compare/15048048...d57b485f

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

Changes: https://git.openjdk.org/jdk/pull/9315/files
 Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9315&range=01
  Stats: 68839 lines in 1210 files changed: 43242 ins; 13434 del; 12163 mod
  Patch: https://git.openjdk.org/jdk/pull/9315.diff
  Fetch: git fetch https://git.openjdk.org/jdk pull/9315/head:pull/9315

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

From jwilhelm at openjdk.org  Tue Jun 28 22:17:09 2022
From: jwilhelm at openjdk.org (Jesper Wilhelmsson)
Date: Tue, 28 Jun 2022 22:17:09 GMT
Subject: Integrated: Merge jdk19
In-Reply-To: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
References: <CFjFOTQoL8kRzRts0qu8LcNNP38xZofxarK-ODBzx5w=.9eb563b1-d00b-44b3-891f-98ce00664378@github.com>
Message-ID: <gtYlusBVnnkYR36SyDWKK3AhTK2FpOpGi5Wx7ZqufwI=.dcb880bf-bbbe-48c1-9985-75d302d4cf45@github.com>

On Tue, 28 Jun 2022 21:13:05 GMT, Jesper Wilhelmsson <jwilhelm at openjdk.org> wrote:

> Forwardport JDK 19 -> JDK 20

This pull request has now been integrated.

Changeset: 86dc760f
Author:    Jesper Wilhelmsson <jwilhelm at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/86dc760f9ec0f403109bef7b06db82b9ed0739dd
Stats:     821 lines in 29 files changed: 612 ins; 71 del; 138 mod

Merge

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

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

From aturbanov at openjdk.org  Wed Jun 29 07:47:00 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Jun 2022 07:47:00 GMT
Subject: RFR: 8289431: Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem
Message-ID: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>

There is overload method HashMap.remove(key,value) which also checks value equality.
It's shorter and faster than pair get+remove.

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

Commit messages:
 - [PATCH] Remove redundant HashMap.get call before HashMap.remove

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

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

From aturbanov at openjdk.org  Wed Jun 29 08:20:31 2022
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 29 Jun 2022 08:20:31 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
Message-ID: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>

> There is overload method HashMap.remove(key,value) which also checks value equality.
> It's shorter and faster than pair get+remove.

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

  8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
  update copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/9314/files
  - new: https://git.openjdk.org/jdk/pull/9314/files/5a83b10c..d9eeaebe

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

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

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

From lancea at openjdk.org  Wed Jun 29 09:59:40 2022
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 29 Jun 2022 09:59:40 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
 <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
Message-ID: <82cMs13RmsxAmmPAAo2ZwZtJNjxtL_0S-umJ5VbB0ss=.b58bf96c-4025-4e38-b2f6-1e815e3dcadd@github.com>

On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> There is overload method HashMap.remove(key,value) which also checks value equality.
>> It's shorter and faster than pair get+remove.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
>   update copyright year

The change seems OK.  Note  that the `removeFileSystem` method is only called when zipfs is closed

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

Marked as reviewed by lancea (Reviewer).

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

From jpai at openjdk.org  Thu Jun 30 06:03:43 2022
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 30 Jun 2022 06:03:43 GMT
Subject: RFR: 8289431: (zipfs) Avoid redundant HashMap.get in
 ZipFileSystemProvider.removeFileSystem [v2]
In-Reply-To: <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
References: <CratF6zP6rFMRJypBoQUD260pgZBURQ4C9pqohF8ceU=.de26f697-9f0a-492c-b39b-82928220e842@github.com>
 <PRsTaimtZUePYj4seRb5FhoemLAMqTROSGZhsakF1Eo=.b4ad0cdf-570b-479d-b205-a875393b6271@github.com>
Message-ID: <uLujEmOemCQX_ZZC0unstjTk4BbDIBPZ-JncCh1_nMg=.ce7a1543-a23a-496f-a5ce-9280eed6db57@github.com>

On Wed, 29 Jun 2022 08:20:31 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> There is overload method HashMap.remove(key,value) which also checks value equality.
>> It's shorter and faster than pair get+remove.
>
> Andrey Turbanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8289431: (zipfs) Avoid redundant HashMap.get in ZipFileSystemProvider.removeFileSystem
>   update copyright year

Hello Andrey,

The `HashMap.remove(k, v)` uses `equals()` call to do a equality check on the passed value unlike the if condition here. Right now, the `ZipFileSystem` (the value type) doesn't have an `equals()` implementation of its own and instead the `Object.equals()` gets used, which does the instance identity check. So this change should be fine.

I personally prefer the previous/existing version because it's  bit more intuitive to understand that the specific instance of filesystem is being removed.

No objections to this change if others prefer this new version.

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

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

From rizeli2777 at gmail.com  Tue Jun 28 19:40:39 2022
From: rizeli2777 at gmail.com (=?UTF-8?Q?Kerem_Saliho=C4=9Flu?=)
Date: Tue, 28 Jun 2022 19:40:39 -0000
Subject: Wrong information in the java.nio.ByteBuffer document
Message-ID: <CAL4ytoawOs4cwa6oHxaoYDTfzsLkhjSEby_XEVaJaXn524EEQg@mail.gmail.com>

In the java.nio.ByteBuffer document, there is an example about floats

 float  getFloat()
 float  getFloat(int index)
  void  putFloat(float f)
  void  putFloat(int index, float f)

which says putFloat methods are void but this is wrong, they
return ByteBuffer itself.

The oldest document I found as archive
https://www.oracle.com/java/technologies/java-archive-142docs-downloads.html,
the oldest document I found online
https://docs.oracle.com/javase/1.5.0/docs/api/java/nio/ByteBuffer.html, and
the early access document for Java 19
https://download.java.net/java/early_access/loom/docs/api/java.base/java/nio/ByteBuffer.html
have the same example.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20220628/825c598c/attachment-0001.htm>