From syan at openjdk.org  Tue Sep  3 02:06:57 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 02:06:57 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> Test fix only, the change has been verified, no risk.

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

  use stat -c linux command line to determise support create time or not

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/4dcdf247..fe3fbc16

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

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

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

From syan at openjdk.org  Tue Sep  3 02:17:19 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 02:17:19 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
Message-ID: <SN0v2tFnmSCtQe-7SEi1ezXOLsczoJxFgp1MeYGYqR0=.81c0b3d1-658c-476b-853f-73b6c382df19@github.com>

On Tue, 3 Sep 2024 02:06:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use stat -c linux command line to determise support create time or not

On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2325477129

From alanb at openjdk.org  Tue Sep  3 07:30:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 3 Sep 2024 07:30:21 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
Message-ID: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>

On Tue, 3 Sep 2024 02:06:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use stat -c linux command line to determise support create time or not

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164:

> 162:             String l = b.readLine();
> 163:             if (l != null && l.equals("-")) { return false; }
> 164:         } catch(Exception e) {

There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741563725

From syan at openjdk.org  Tue Sep  3 07:38:21 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 07:38:21 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
 <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
Message-ID: <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>

On Tue, 3 Sep 2024 07:27:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use stat -c linux command line to determise support create time or not
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164:
> 
>> 162:             String l = b.readLine();
>> 163:             if (l != null && l.equals("-")) { return false; }
>> 164:         } catch(Exception e) {
> 
> There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure.

It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back.
Thanks for the advice, I will use `ProcessTools infrastructure` later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741575123

From sgehwolf at openjdk.org  Tue Sep  3 08:18:20 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Sep 2024 08:18:20 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
 <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
 <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>
Message-ID: <OlSsiWfzxaNy9rpo5bxt2Nd_UUPDFHU4FogfS_bInu4=.196df767-e1b1-4a11-baca-9e5000ae3e0b@github.com>

On Tue, 3 Sep 2024 07:35:55 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 164:
>> 
>>> 162:             String l = b.readLine();
>>> 163:             if (l != null && l.equals("-")) { return false; }
>>> 164:         } catch(Exception e) {
>> 
>> There are several bugs/issues with this method, did you mean to bring it back? If we are launching subprocesses in this test then it can use ProcessTools infrastructure.
>
> It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back.
> Thanks for the advice, I will use `ProcessTools infrastructure` later.

An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741630915

From syan at openjdk.org  Tue Sep  3 08:53:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 08:53:23 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <OlSsiWfzxaNy9rpo5bxt2Nd_UUPDFHU4FogfS_bInu4=.196df767-e1b1-4a11-baca-9e5000ae3e0b@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
 <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
 <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>
 <OlSsiWfzxaNy9rpo5bxt2Nd_UUPDFHU4FogfS_bInu4=.196df767-e1b1-4a11-baca-9e5000ae3e0b@github.com>
Message-ID: <ClG5YTTY8-xNTSE6-5s-QoNn6Z1khlS3pvDqPxFbWo8=.8af42d2c-bfb4-47de-96b2-6711c6372d3a@github.com>

On Tue, 3 Sep 2024 08:16:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not, So I want to bring it back.
>> Thanks for the advice, I will use `ProcessTools infrastructure` later.
>
> An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does.

I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741682815

From syan at openjdk.org  Tue Sep  3 09:02:20 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 09:02:20 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <ClG5YTTY8-xNTSE6-5s-QoNn6Z1khlS3pvDqPxFbWo8=.8af42d2c-bfb4-47de-96b2-6711c6372d3a@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
 <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
 <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>
 <OlSsiWfzxaNy9rpo5bxt2Nd_UUPDFHU4FogfS_bInu4=.196df767-e1b1-4a11-baca-9e5000ae3e0b@github.com>
 <ClG5YTTY8-xNTSE6-5s-QoNn6Z1khlS3pvDqPxFbWo8=.8af42d2c-bfb4-47de-96b2-6711c6372d3a@github.com>
Message-ID: <M3ybcS69CrqeaAhHzv2JudQSTC4_axx6xlCCh4Gp_7c=.c295eb27-f812-4562-9e77-48a5538e72ee@github.com>

On Tue, 3 Sep 2024 08:50:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does.
>
> I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`?

Maybe we can use this solution https://github.com/openjdk/jdk21u/pull/282

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1741695955

From syan at openjdk.org  Tue Sep  3 13:05:08 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 13:05:08 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
> 
> Test fix only, the change has been verified, no risk.

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

  use jni to determine the tested file support birth time or not

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/fe3fbc16..78fbf834

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

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

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

From sgehwolf at openjdk.org  Tue Sep  3 15:23:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 3 Sep 2024 15:23:25 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
Message-ID: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com>

On Tue, 3 Sep 2024 13:05:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use jni to determine the tested file support birth time or not

Changes requested by sgehwolf (Reviewer).

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35:

> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
> 34:     return statx_func != NULL ? JNI_TRUE : JNI_FALSE;
> 35: #else

This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in.

See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00

Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet.

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

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2277769847
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1742258338

From syan at openjdk.org  Tue Sep  3 16:11:42 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 16:11:42 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
 <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com>
Message-ID: <IV0aivSf7DVUXC3xEjjSM384B9OQA1BWMSeA2B1DR4c=.5743a4cb-1918-47e3-afaf-ba9e646b1b0a@github.com>

On Tue, 3 Sep 2024 15:20:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   use jni to determine the tested file support birth time or not
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35:
> 
>> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
>> 34:     return statx_func != NULL ? JNI_TRUE : JNI_FALSE;
>> 35: #else
> 
> This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in.
> 
> See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00
> 
> Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet.

Sorry, I already realized that the current solution is incomplete, so I do not click the previous `Resolve conversation`. I will finish the solution according your advice these days, Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1742328650

From syan at openjdk.org  Tue Sep  3 16:28:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 3 Sep 2024 16:28:22 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
Message-ID: <plswpHTeXI106UylSWQv9aWwJCX7l3z9tXl0eyUeg3k=.3fa079d6-03e2-4023-863f-acf952574ef7@github.com>

On Tue, 3 Sep 2024 13:05:08 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the output from `stat -c` linux command, to determine the testd file support birth ot not.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use jni to determine the tested file support birth time or not

I think this PR should be set as draft status, sorry for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2326949662

From mcimadamore at openjdk.org  Wed Sep  4 20:35:47 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 4 Sep 2024 20:35:47 GMT
Subject: RFR: 8339285: test fails with assert(depth < max_critical_stack_depth)
 failed: can't have more than 10 critical frames
Message-ID: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>

Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).

To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.

A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).

This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.

To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.

Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

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

Commit messages:
 - Use registerNatives on MappedMemoryUtils native methods
 - Merge branch 'master' into mapped_test_handshake
 - Add test

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

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

From syan at openjdk.org  Thu Sep  5 08:44:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 08:44:29 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v7]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

 - split too long lines to short lines
 - use "Foreign Function & Memory API" instead of JNI
 - fix compile error: libCreationTimeHelper.c:24:10: fatal error: 'linux/fcntl.h' file not found on windows and macos
 - upload JNI solution temporary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/78fbf834..2ed8cb68

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

  Stats: 138 lines in 3 files changed: 118 ins; 2 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/20687.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20687/head:pull/20687

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

From syan at openjdk.org  Thu Sep  5 08:44:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 08:44:29 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <plswpHTeXI106UylSWQv9aWwJCX7l3z9tXl0eyUeg3k=.3fa079d6-03e2-4023-863f-acf952574ef7@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
 <plswpHTeXI106UylSWQv9aWwJCX7l3z9tXl0eyUeg3k=.3fa079d6-03e2-4023-863f-acf952574ef7@github.com>
Message-ID: <PUXyuYPthClybBWh3dDxRAj50fQ-YaRz0-Cg612_b1w=.41654ede-2689-4b54-ab1e-e67d4f097f04@github.com>

On Tue, 3 Sep 2024 16:26:10 GMT, SendaoYan <syan at openjdk.org> wrote:

> I think this PR should be set as draft status, sorry for that.

The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2330940218

From syan at openjdk.org  Thu Sep  5 08:44:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 08:44:29 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v5]
In-Reply-To: <ClG5YTTY8-xNTSE6-5s-QoNn6Z1khlS3pvDqPxFbWo8=.8af42d2c-bfb4-47de-96b2-6711c6372d3a@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <vqUSURSMiR2tMj_1rKkEdHSyq3jk4riWZ30kNGhikVY=.196eaf26-d3a4-4914-8228-f33a319e3e35@github.com>
 <1WTMMt8zCr6OFFTBOAG_V0LTzCvW5NIk8BE4MAq3z0U=.f40c2943-c422-4384-9c5f-41af8521efaa@github.com>
 <IATWukwmNSQiylP4VfcIi5Iq9KQKoznbsP_6oT25fKI=.c3f9cf9f-951f-4b2d-b154-b633e21dc4cf@github.com>
 <OlSsiWfzxaNy9rpo5bxt2Nd_UUPDFHU4FogfS_bInu4=.196df767-e1b1-4a11-baca-9e5000ae3e0b@github.com>
 <ClG5YTTY8-xNTSE6-5s-QoNn6Z1khlS3pvDqPxFbWo8=.8af42d2c-bfb4-47de-96b2-6711c6372d3a@github.com>
Message-ID: <Ptw9L6aMyyr2vYefADOvCkLEO7sTpawsUpVvAR2ss0E=.7dc056e5-6e00-417b-bff2-3c5273ee2c35@github.com>

On Tue, 3 Sep 2024 08:50:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> An alternative could be to use FFM API to query the statx bufs mask the kernel returns testing for the birth time bit like the actual code does.
>
> I think this PR needed to backport to jdk21u and jdk17u in future. Maybe in jdk17u can't use`FFM API`?

The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1745049813

From syan at openjdk.org  Thu Sep  5 08:44:29 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 08:44:29 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v6]
In-Reply-To: <IV0aivSf7DVUXC3xEjjSM384B9OQA1BWMSeA2B1DR4c=.5743a4cb-1918-47e3-afaf-ba9e646b1b0a@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wBKGm4f7HUd7LB6sTtehPJI92QmHsoZIwRH9bltuDPg=.68a9b9a1-5c86-4213-95af-4c8306bc3d23@github.com>
 <6fsXARAJ9o32I_uy9CUHtfe-POqIPkp1NugNDdRogyk=.1cebe64e-870b-46e3-b10d-1e9387aa372e@github.com>
 <IV0aivSf7DVUXC3xEjjSM384B9OQA1BWMSeA2B1DR4c=.5743a4cb-1918-47e3-afaf-ba9e646b1b0a@github.com>
Message-ID: <eHuBQsseRBI18ze3NNZC0M8Kr_Xms02i5GDK4vloMDQ=.d2d14fa7-398f-4c0d-b415-d2a10627d258@github.com>

On Tue, 3 Sep 2024 16:08:36 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 35:
>> 
>>> 33:     void* statx_func = dlsym(RTLD_DEFAULT, "statx");
>>> 34:     return statx_func != NULL ? JNI_TRUE : JNI_FALSE;
>>> 35: #else
>> 
>> This is equivalent to the previous `Linker.nativeLinker().defaultLookup().find("statx").isPresent();` so isn't enough. You'd have to pass in the path and do an actual `statx` call, look at the returned statx buffer, get the mask and look whether birth time has been filled in.
>> 
>> See: https://github.com/openjdk/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00
>> 
>> Only then it makes sense to go the jni route. Having said all that, for JDK head using FFM is preferred. Let's not consider backports just yet.
>
> Sorry, I already realized that the current solution is incomplete, so I do not click the previous `Resolve conversation`. I will finish the solution according your advice these days, Thanks.

The solution has been change to, get the result from `statx` linux syscall througt `FFM API`, to determine the testd file support birth time or not.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1745050319

From alanb at openjdk.org  Thu Sep  5 09:58:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 09:58:50 GMT
Subject: RFR: 8339285: test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>

On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

src/java.base/aix/native/libnio/MappedMemoryUtils.c line 229:

> 227:     {"unload0",   "(JJ)V",              (void *)&MMU_unload0},
> 228:     {"force0",    "(" FD "JJ)V",        (void *)&MMU_force0},
> 229: };

I did a pass over this and I think it looks okay.

Do the MMU_* functions still need to be jni-exported? In any case, probably better to rename them to MemoryMemoryUtils_* to avoid anything looking at symbols and thinking they are something to do with the memory management unit :-)

It looks most of the signatures for this functions are misaligned with edits.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745168389

From mcimadamore at openjdk.org  Thu Sep  5 11:17:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:17:34 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

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/20854/files
  - new: https://git.openjdk.org/jdk/pull/20854/files/5a4cd150..f02b51c1

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

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

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

From mcimadamore at openjdk.org  Thu Sep  5 11:17:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:17:34 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <1-PtXXBPRmvpq0jvWyEFJvOCGAiH24nSI1xqywKG2VA=.cc21539d-e6f1-4600-8b0f-909cb04f49e6@github.com>
Message-ID: <DWCxj9weg2ms0pq94MeXV5-zYYlZ5Pw819StJWKF9sc=.9f13de85-6dc3-4489-bcf9-3946c419266c@github.com>

On Thu, 5 Sep 2024 09:55:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Do the MMU_* functions still need to be jni-exported?

I've now dropped JNIEXPORT, but kept JNICALL, as that is used to set `__stdcall` (at least on Windows).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745274541

From alanb at openjdk.org  Thu Sep  5 11:31:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 11:31:52 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
Message-ID: <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>

On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
>> 
>> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
>> 
>> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
>> 
>> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
>> 
>> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
>> 
>> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

test/jdk/java/foreign/TestMappedHandshake.java line 90:

> 88: 
> 89:             accessExecutor.shutdown();
> 90:             assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS));

ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745294794

From mcimadamore at openjdk.org  Thu Sep  5 11:42:51 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 11:42:51 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
 <CV0k685d0YmB5Jd-xaDED_2Qsv8Azp2x3AXONISsnFM=.ebb7be59-0915-411e-8f86-415c9d101fff@github.com>
Message-ID: <Q0F3cuLbknmoYbD-TjjtrGVYO9LYEfdLrMEzPSEsw-o=.36286a3b-680b-45e2-818d-750f9acab829@github.com>

On Thu, 5 Sep 2024 11:29:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> test/jdk/java/foreign/TestMappedHandshake.java line 90:
> 
>> 88: 
>> 89:             accessExecutor.shutdown();
>> 90:             assertTrue(accessExecutor.awaitTermination(MAX_EXECUTOR_WAIT_SECONDS, TimeUnit.SECONDS));
> 
> ExecutorService is an AutoCloseable to you should be able to use try-with-resources and get rid of the the shutdown+awaitTermination.

The test (like also its sibling `TestHandshake`) is deliberately using `shutdown`/`awaitTermination` to make sure the test finished in a reasonable amount of time (and generate correct assertion failures if it doesn't). This was mostly added to have better debugging at a time when `TestHandshake` was failing spuriously, so I'd prefer to leave it as is.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20854#discussion_r1745307197

From syan at openjdk.org  Thu Sep  5 12:16:52 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 12:16:52 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v7]
In-Reply-To: <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <4MITwe77P1YMHk1RM_fmKUqBkegiwbFPf7T325pQpD4=.a34dab17-cd55-4fab-8dc1-5d2df05859f0@github.com>
Message-ID: <m2v904GVKPiQpWfADZRY8SIRgMFPX8IE3S0zdbGy5FM=.6cf910cb-b0e6-4725-9f87-acea2bf93453@github.com>

On Thu, 5 Sep 2024 08:44:29 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - split too long lines to short lines
>  - use "Foreign Function & Memory API" instead of JNI
>  - fix compile error: libCreationTimeHelper.c:24:10: fatal error: 'linux/fcntl.h' file not found on windows and macos
>  - upload JNI solution temporary

Sorry, build fails on macos and windows, I will fix it right now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2331365259

From syan at openjdk.org  Thu Sep  5 12:28:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 12:28:37 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v8]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <zM5MMjNJ50HvBUvVGYARsxWvzE4CiLMv1fOlz6IWH5U=.ab33a1dd-9435-41a0-af69-94c435f1330e@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  fix compile error: libCreationTimeHelper.c:96:8: error: unknown type name bool

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/2ed8cb68..35290e8c

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

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

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

From alanb at openjdk.org  Thu Sep  5 14:25:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 5 Sep 2024 14:25:54 GMT
Subject: RFR: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames [v2]
In-Reply-To: <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
 <ApVDJD9aKy8wnxZmUdulojapat3IaKSZ0RqaFbXdsG0=.5a36ea65-9b84-4520-a7d8-c51bd8fa4420@github.com>
Message-ID: <idiDi_KpXcn4OjrHe7OzxHf25luZWVbasOEJVRRb6T4=.5279c9df-4ee9-4245-abb3-7688439e4505@github.com>

On Thu, 5 Sep 2024 11:17:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
>> 
>> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
>> 
>> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
>> 
>> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
>> 
>> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
>> 
>> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20854#pullrequestreview-2283229031

From syan at openjdk.org  Thu Sep  5 15:24:28 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 5 Sep 2024 15:24:28 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v9]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <wd2SqGZPLXX_YfH_Qs-sdeDDK7NlePQFBzSjCwdX6Nw=.ca21b0da-885e-4f53-b789-3d44d95617a9@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  fix compile error: libCreationTimeHelper.c:125:12: error: use of undeclared identifier JNI_FALSE

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/35290e8c..c364944c

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

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

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

From mcimadamore at openjdk.org  Thu Sep  5 18:14:00 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 5 Sep 2024 18:14:00 GMT
Subject: Integrated: 8339285: Test fails with assert(depth <
 max_critical_stack_depth) failed: can't have more than 10 critical frames
In-Reply-To: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
References: <gRfkOOT-EIhlTIk88IbrtOLddSu53U1rFqpQ7fLxKDM=.538be6fc-1f69-4611-999c-ae8a8849efa4@github.com>
Message-ID: <JdKe7fXuFFyFL2dy5gpSZ9PEUox1GOMzL9joA8hxvNk=.b1e4fd54-6bb0-4450-beda-fb0fbe54e2a3@github.com>

On Wed, 4 Sep 2024 15:23:51 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Scoped methods are critical methods in the FFM API where memory is accessed in a potentially unsafe way. When closing shared arenas, we look at threads in the middle of a scoped operation involving that arena, and if we find one, we make it fail (by installing an async handshake on that thread).
> 
> To find whether a thread is in a scoped method or not, we need a stack walk. For performance reasons, it is preferrable to have the stack walk to be bounded in size.
> 
> A test started picking up a JVM assertion where the stack of a scoped method (namely `ScopedMemoryAccess::isLoaded`) is too big. This is caused by the scoped method stack walk finding the thread using the scoped method in the middle of some JNI lookup (which is required as `isLoaded` eventually ends up in a native method). This condition seems to have been made easier by the fact that these [changes](https://git.openjdk.org/jdk/pull/19213).
> 
> This PR reverts the stack trace associated with JNI lookup to what it was before, by eliminating the extra frame with a bit of refactoring/cleanup. But this is not enough: the stress test introduced in this PR still fails, even when the stack associated with `ClassLoader::findNative` is restored.
> 
> To address this problem in full, I have resorted to `registerNatives` - that is, the native `isLoaded0`, `load0`, `unload0` and `force0` are pre-registered, when the static initializer of `MappedMemoryUtils` is ran. This means that we no longer need to run a JNI lookup in the middle of a scoped method call. This brings the stack back under control, and passes the stress test.
> 
> Of course there's more to do in this area - we should have a more direct test to check the stack associated with scoped methods (for instance, vector load/store operations are also potential suspects), in order to catch "suspicious refactoring" earlier in the process. For this reason I also filed a follow up i[ssue](https://bugs.openjdk.org/browse/JDK-8339551).

This pull request has now been integrated.

Changeset: 9e1af8cc
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e1af8cc7cc9f63453097bd35eb3cf29f945d765
Stats:     253 lines in 9 files changed: 212 ins; 12 del; 29 mod

8339285: Test fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Thu Sep  5 23:18:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 5 Sep 2024 23:18:51 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v9]
In-Reply-To: <wd2SqGZPLXX_YfH_Qs-sdeDDK7NlePQFBzSjCwdX6Nw=.ca21b0da-885e-4f53-b789-3d44d95617a9@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wd2SqGZPLXX_YfH_Qs-sdeDDK7NlePQFBzSjCwdX6Nw=.ca21b0da-885e-4f53-b789-3d44d95617a9@github.com>
Message-ID: <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com>

On Thu, 5 Sep 2024 15:24:28 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix compile error: libCreationTimeHelper.c:125:12: error: use of undeclared identifier JNI_FALSE

Line 84 of the test: "birth time not support for: " should be changed to "birth time not supported for: ".

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2332861463

From syan at openjdk.org  Fri Sep  6 01:11:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Sep 2024 01:11:31 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  fix typo support to supported

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/c364944c..a805b6fd

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

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

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

From syan at openjdk.org  Fri Sep  6 01:11:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Sep 2024 01:11:31 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v9]
In-Reply-To: <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <wd2SqGZPLXX_YfH_Qs-sdeDDK7NlePQFBzSjCwdX6Nw=.ca21b0da-885e-4f53-b789-3d44d95617a9@github.com>
 <-VOeZppxUJ5yR19WQrDDwn9aIc4jIe-Qkhx6EgHz3q4=.c5b46358-21f5-4016-920a-088908dbb3e5@github.com>
Message-ID: <FS8SAbWBqwLYPC244MQUkbObJZTSdMkoneHwP1xUFkk=.40f78b23-89bc-4575-8262-9e11b3006383@github.com>

On Thu, 5 Sep 2024 23:16:17 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> birth time not supported for:

The typo issue has been fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2332987684

From sgehwolf at openjdk.org  Fri Sep  6 09:22:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 6 Sep 2024 09:22:54 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
Message-ID: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>

On Fri, 6 Sep 2024 01:11:31 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix typo support to supported

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 83:

> 81:             System.out.println("creationTime.toMillis() == " + creationTime.toMillis());
> 82:             // If the file system doesn't support birth time, then skip this test
> 83:             if (creationTime.toMillis() == 0) {

Is this still useful? After https://bugs.openjdk.org/browse/JDK-8338696 we'd never get the epoch (`0`). If birth time is not supported, the last modified time is being returned. I think this can go and the `SkippedException` branch removed as well.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 51:

> 49:             return (boolean)methodHandle.invokeExact(s);
> 50:         }
> 51:     }

We should only do the downcall if we know `statx` is available. I.e. return `false` early when `!abi.defaultLookup().find("statx").isPresent()`

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30:

> 28:   #define true 1
> 29:   #define false 0
> 30: #endif

Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 46:

> 44: #ifndef _GNU_SOURCE
> 45: #define _GNU_SOURCE
> 46: #endif

Why is this needed?

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 121:

> 119:         return false;
> 120:     }
> 121:     if (stx.stx_mask & STATX_BTIME)

`if (stx.stx_mask & STAX_BTIME) != 0)` please. Also, please add a comment mentioning that "on some systems where `statx` is available birth time might still not be supported as it's file system specific. The only reliable way to check for support is looking at the filled in STATX_BTIME bit in the returned statx buffer mask."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746798514
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746745709
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746761279
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746779743
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746775412

From syan at openjdk.org  Fri Sep  6 09:55:53 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Sep 2024 09:55:53 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
Message-ID: <61e88pfjoOykSL-DKVlNToSbQoEsck7gHbudZxusgwY=.2155b751-434b-4754-81c1-157075bbb90e@github.com>

On Fri, 6 Sep 2024 09:03:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo support to supported
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30:
> 
>> 28:   #define true 1
>> 29:   #define false 0
>> 30: #endif
> 
> Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`.

I am not quite sure, I copied these codes from `src/java.base/unix/native/libjsig/jsig.c`. I will check it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1746859383

From syan at openjdk.org  Fri Sep  6 13:16:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Sep 2024 13:16:09 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v11]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <-5ZwEEoOHmM2A-MSoYizy4z9OIZdNXFEv3UIbOe2AJ0=.ac0e104e-3106-4f85-aa7b-70ccf54ff8e4@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  delete "#define _GNU_SOURCE"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/a805b6fd..c8e22c10

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=09-10

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

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

From syan at openjdk.org  Fri Sep  6 13:16:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 6 Sep 2024 13:16:10 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
Message-ID: <eTyX-aOSg2V_wSxYpIGPt0_BJGAd97zBbDjrJU3onnQ=.360cd857-69b0-4e7a-8288-b54e6dc7cc2e@github.com>

On Fri, 6 Sep 2024 09:08:09 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo support to supported
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 46:
> 
>> 44: #ifndef _GNU_SOURCE
>> 45: #define _GNU_SOURCE
>> 46: #endif
> 
> Why is this needed?

That seems not needed indeed. I will delete that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747106294

From syan at openjdk.org  Sat Sep  7 02:34:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 02:34:45 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v12]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <AGp0co1XBOndcHNZvg1ehZfugtt5pSkMyLiyU5g69HQ=.6581b23c-be2c-42b5-b519-7a5cc6d21a67@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  return false early if statx syscall is not available

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/c8e22c10..be64c32a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=10-11

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

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

From syan at openjdk.org  Sat Sep  7 02:34:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 02:34:45 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
Message-ID: <KKRblwacD9jM8--UScPFQ_aSWZI52-UMRLAup81MM1I=.a9fb1ea3-9905-4498-aeea-69c03ad0243b@github.com>

On Fri, 6 Sep 2024 08:56:00 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo support to supported
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 51:
> 
>> 49:             return (boolean)methodHandle.invokeExact(s);
>> 50:         }
>> 51:     }
> 
> We should only do the downcall if we know `statx` is available. I.e. return `false` early when `!abi.defaultLookup().find("statx").isPresent()`

Okey, code `return false early if statx syscall is not available` has been added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747872673

From syan at openjdk.org  Sat Sep  7 02:53:50 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 02:53:50 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v13]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <9IHLho18KfdtXpQwjFBA-xUvDeFaLLnsqdrqIGpatvA=.805c8739-609d-4f1f-90c2-520dcb0e0ca1@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  STATX_BTIME return statx buffer mask convert to boolean explicitly, and add comment to explain why get STATX_BTIME bit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/be64c32a..1ca8dd02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=11-12

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

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

From syan at openjdk.org  Sat Sep  7 02:53:50 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 02:53:50 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
Message-ID: <COfnCb6HG1e09LHnwFKF0Eq1lP2Mrf4h0f7kJ52oTLk=.07dee619-7a61-4478-88d2-8eefdb77ce44@github.com>

On Fri, 6 Sep 2024 09:07:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo support to supported
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 121:
> 
>> 119:         return false;
>> 120:     }
>> 121:     if (stx.stx_mask & STATX_BTIME)
> 
> `if (stx.stx_mask & STAX_BTIME) != 0)` please. Also, please add a comment mentioning that "on some systems where `statx` is available birth time might still not be supported as it's file system specific. The only reliable way to check for support is looking at the filled in STATX_BTIME bit in the returned statx buffer mask."

Thanks for your patient code review.
`STATX_BTIME` return statx buffer mask convert to boolean explicitly, and add comment to explain why get `STATX_BTIME` bit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747877454

From syan at openjdk.org  Sat Sep  7 03:08:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 03:08:39 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v14]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <sc_8_cf_W0ri3xpEi5Ln-lty_v09A2jokIhh7Ax4_rQ=.9110a087-236e-4925-ba60-9bf4c1e72d01@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  After JDK-JDK-8338696, the file birth time never get the epoch (0), so delete the SkippedException for epoch (0)

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/1ca8dd02..a931938a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=12-13

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

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

From syan at openjdk.org  Sat Sep  7 03:08:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 7 Sep 2024 03:08:39 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
Message-ID: <iGhbSIK_xfVAgSBDbei0Bt4ECmDZXCdgv-kAqxgJqu0=.9670c286-4b21-4a4b-9b48-159bd99f55ee@github.com>

On Fri, 6 Sep 2024 09:19:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix typo support to supported
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 83:
> 
>> 81:             System.out.println("creationTime.toMillis() == " + creationTime.toMillis());
>> 82:             // If the file system doesn't support birth time, then skip this test
>> 83:             if (creationTime.toMillis() == 0) {
> 
> Is this still useful? After https://bugs.openjdk.org/browse/JDK-8338696 we'd never get the epoch (`0`). If birth time is not supported, the last modified time is being returned. I think this can go and the `SkippedException` branch removed as well.

Thanks for your correction, the `SkippedException` for epoch (0) has been deleted.

> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30:
> 
>> 28:   #define true 1
>> 29:   #define false 0
>> 30: #endif
> 
> Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`.

I think I need some time to study that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747880627
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1747881022

From syan at openjdk.org  Mon Sep  9 02:30:09 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 02:30:09 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v10]
In-Reply-To: <iGhbSIK_xfVAgSBDbei0Bt4ECmDZXCdgv-kAqxgJqu0=.9670c286-4b21-4a4b-9b48-159bd99f55ee@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <gENOOTMIOKxpsv2uACqjaB39ZvF9STE3sBme62jW9n4=.b6c42059-f396-41a9-8e8e-c99cbd5aea66@github.com>
 <u_0ckxjqzqEqdan5LblZKjjftWE5o64rCpZMN8M-Kss=.1e66edbe-b86d-4c2c-ba95-1b0907cb3339@github.com>
 <iGhbSIK_xfVAgSBDbei0Bt4ECmDZXCdgv-kAqxgJqu0=.9670c286-4b21-4a4b-9b48-159bd99f55ee@github.com>
Message-ID: <Zo91LaXbTDENfH7mU9iWPNGTtH1G1ywIyUxslfReFA4=.31df6606-84ea-431c-953b-6425f45c462d@github.com>

On Sat, 7 Sep 2024 03:04:46 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 30:
>> 
>>> 28:   #define true 1
>>> 29:   #define false 0
>>> 30: #endif
>> 
>> Do we really need this? Since https://openjdk.org/jeps/347 test libraries should be compiled with `--std=c11`.
>
> I think I need some time to study that.

I found other tests such as `test/jdk/java/foreign/libIntrinsics.c` only `#include <stdbool.h>` to use bool type. So I think these codes can change to only `#include <stdbool.h>`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749476268

From syan at openjdk.org  Mon Sep  9 02:35:38 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 02:35:38 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v15]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <jmRYmKaOc7i2YEaHwWAbltK-N-Qru6qooSN7j_NdDDo=.f54703e6-7757-49bf-a78b-c0c4385bcb1c@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  After JEP 347, we can use bool type only "#include <stdbool.h>"

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/a931938a..66da6f72

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=13-14

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

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

From sgehwolf at openjdk.org  Mon Sep  9 08:36:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Sep 2024 08:36:14 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v15]
In-Reply-To: <jmRYmKaOc7i2YEaHwWAbltK-N-Qru6qooSN7j_NdDDo=.f54703e6-7757-49bf-a78b-c0c4385bcb1c@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <jmRYmKaOc7i2YEaHwWAbltK-N-Qru6qooSN7j_NdDDo=.f54703e6-7757-49bf-a78b-c0c4385bcb1c@github.com>
Message-ID: <ig7k5787PIC-O_O9DSKigNG-3k8fAnmxf3iipkuy60Y=.4e593769-7409-4efa-b8ee-dbd04c493dcc@github.com>

On Mon, 9 Sep 2024 02:35:38 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   After JEP 347, we can use bool type only "#include <stdbool.h>"

Seems mostly fine now.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 45:

> 43: 
> 44:     // Helper so as to determine 'statx' support on the runtime system
> 45:     // static boolean linuxIsCreationTimeSupported(String file);

This comment is a bit misleading.

Suggestion:

    // Helper so as to determine birth time support on Linux.
    // Support is determined in a two-step process:
    // 1. Determine if `statx` system call is available. If available proceed, otherwise
    //    return false.
    // 2. Perform an actual `statx` call on the given file and check for birth time support
    //    in the mask returned from the call. This is needed, since some file systems, like
    //    nfs, don't support birth time even though the `statx` system call is available.

test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 48:

> 46:     static boolean linuxIsCreationTimeSupported(String file) throws Throwable {
> 47:         if (!abi.defaultLookup().find("statx").isPresent())
> 48:             return false;

I personally prefer using `if (...) { /* do something */ }` (add curly brackets).

test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 91:

> 89:     struct my_statx stx;
> 90:     int ret, atflag = AT_SYMLINK_NOFOLLOW;
> 91:     memset(&stx, 0xbf, sizeof(stx));

Why `0xbf`?

How about `struct my_statx stx = {0}`?

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

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2289152795
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749783056
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749785765
PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1749813293

From alanb at openjdk.org  Mon Sep  9 09:27:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Sep 2024 09:27:05 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
Message-ID: <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com>

On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). 
> 
> This PR aims to replace these undocumented APIs with documented synchronization APIs. 
> 
> Test Performed:
> 1. All 12 tests in wepoll repo passed 
>            test-auto-drop-on-close PASS
>            test-connect-fail-events PASS
>            test-connect-success-events PASS
>            test-ctl-fuzz PASS
>            test-error PASS
>            test-leak-1 PASS
>            test-mixed-socket-types PASS
>            test-multi-poll PASS
>            test-oneshot-and-hangup PASS
>            test-reflock PASS
>            test-tree PASS
>            test-udp-pings PASS
>         DONE - 12 PASSED, 0 FAILED
> 
> 2. No new failure in JTreg test
> 3. Micro bench results: similar performance score before and after the changes
> 
> without change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c)
> 
> With the change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e)

Can you confirm that you've run jdk tier2 with these changes?

@djelinski Would you have cycles to look at this? Ideally the changes would go upstream and/or Microsoft would contribute resources to that project. From a quick scan, the changes aren't too bad although there are some needless fixes to comment typos.

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

PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2337589854
PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2337595430

From syan at openjdk.org  Mon Sep  9 12:02:25 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:02:25 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v16]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <lCNT6v_7K_TxY5vZK5BieA-ebVRDrMf5jYJXioqxw4w=.69b6f994-063e-4ba2-9243-ddf99ecb1208@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  1. add curly brackets in function linuxIsCreationTimeSupported; 2. complement comment for function linuxIsCreationTimeSupported

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/66da6f72..2db0988d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=14-15

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

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

From syan at openjdk.org  Mon Sep  9 12:02:26 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:02:26 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v15]
In-Reply-To: <ig7k5787PIC-O_O9DSKigNG-3k8fAnmxf3iipkuy60Y=.4e593769-7409-4efa-b8ee-dbd04c493dcc@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <jmRYmKaOc7i2YEaHwWAbltK-N-Qru6qooSN7j_NdDDo=.f54703e6-7757-49bf-a78b-c0c4385bcb1c@github.com>
 <ig7k5787PIC-O_O9DSKigNG-3k8fAnmxf3iipkuy60Y=.4e593769-7409-4efa-b8ee-dbd04c493dcc@github.com>
Message-ID: <jTOKHUjjMxhICKnCH8n8uagyp6M8PefIBK_HMAntYhM=.a1377386-12b7-4a82-8ead-a9694532282c@github.com>

On Mon, 9 Sep 2024 08:13:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After JEP 347, we can use bool type only "#include <stdbool.h>"
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTimeHelper.java line 48:
> 
>> 46:     static boolean linuxIsCreationTimeSupported(String file) throws Throwable {
>> 47:         if (!abi.defaultLookup().find("statx").isPresent())
>> 48:             return false;
> 
> I personally prefer using `if (...) { /* do something */ }` (add curly brackets).

Thanks for your patient code review again.
1. curly brackets in function linuxIsCreationTimeSupported has been added; 2. comment for function linuxIsCreationTimeSupported has been complemented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1750127468

From syan at openjdk.org  Mon Sep  9 12:42:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:42:23 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
Message-ID: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>

> Hi all,
> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
> 
> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
> 
> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
> 
> Test fix only, the change has been verified, risk is low.
> 
> Additional test:
> 
> - [x] Alinux3 glibc:2.32
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == true
> - [x] CentOS7 docker container glibc:2.17
> 1.  /tmp/file supportsCreationTimeRead == false
> 2. ./file supportsCreationTimeRead == false

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

  initail struct stx var to zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/2db0988d..7a7916f4

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

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

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

From syan at openjdk.org  Mon Sep  9 12:42:23 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:42:23 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v16]
In-Reply-To: <lCNT6v_7K_TxY5vZK5BieA-ebVRDrMf5jYJXioqxw4w=.69b6f994-063e-4ba2-9243-ddf99ecb1208@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <lCNT6v_7K_TxY5vZK5BieA-ebVRDrMf5jYJXioqxw4w=.69b6f994-063e-4ba2-9243-ddf99ecb1208@github.com>
Message-ID: <h2ifDw7jLGZMHU2P0kvYl-CLPKRh0ttT6oykTbFvgQk=.fe1ab4aa-b966-43cd-9708-a91c6a23fab9@github.com>

On Mon, 9 Sep 2024 12:02:25 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   1. add curly brackets in function linuxIsCreationTimeSupported; 2. complement comment for function linuxIsCreationTimeSupported

Because this test invoke native libary, so mark this test as `/native`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2338015273

From syan at openjdk.org  Mon Sep  9 12:42:24 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 9 Sep 2024 12:42:24 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v15]
In-Reply-To: <ig7k5787PIC-O_O9DSKigNG-3k8fAnmxf3iipkuy60Y=.4e593769-7409-4efa-b8ee-dbd04c493dcc@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <jmRYmKaOc7i2YEaHwWAbltK-N-Qru6qooSN7j_NdDDo=.f54703e6-7757-49bf-a78b-c0c4385bcb1c@github.com>
 <ig7k5787PIC-O_O9DSKigNG-3k8fAnmxf3iipkuy60Y=.4e593769-7409-4efa-b8ee-dbd04c493dcc@github.com>
Message-ID: <ySiQLKAIbnvdLfWXgUS__RFuKV4d6SrxKUZgX9qhzBo=.0fffe64b-bcfe-4701-83fd-d93624f2f58c@github.com>

On Mon, 9 Sep 2024 08:30:28 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   After JEP 347, we can use bool type only "#include <stdbool.h>"
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/libCreationTimeHelper.c line 91:
> 
>> 89:     struct my_statx stx;
>> 90:     int ret, atflag = AT_SYMLINK_NOFOLLOW;
>> 91:     memset(&stx, 0xbf, sizeof(stx));
> 
> Why `0xbf`?
> 
> How about `struct my_statx stx = {0}`?

I implement this code imitate from [test-statx.c](https://github.com/torvalds/linux/blob/master/samples/vfs/test-statx.c#L251), and I'm not quite sure why the testcase initial struct var stx to `0xbf`. I think initial to zero will be Okey also.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20687#discussion_r1750177644

From mcimadamore at openjdk.org  Mon Sep  9 13:02:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:02:15 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
Message-ID: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>

The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.

To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.

Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

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

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/20914/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20914&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339686
  Stats: 104 lines in 7 files changed: 48 ins; 30 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/20914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20914/head:pull/20914

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

From mcimadamore at openjdk.org  Mon Sep  9 13:02:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:02:15 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9:

> 7:  * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods.
> 8:  */
> 9: public interface MappedMemoryUtilsProxy {

We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750215021

From mcimadamore at openjdk.org  Mon Sep  9 13:28:12 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 13:28:12 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <L8bW6WHUtMpYyz-Ni_E3ixk8uBCwXdTOlndX8cG6j0E=.cd377fbf-f420-4921-841a-1a0014d5a723@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

src/java.base/share/classes/jdk/internal/misc/X-ScopedMemoryAccess.java.template line 255:

> 253:                 session.checkValidStateRaw();
> 254:             }
> 255:             return mappedUtils.isLoaded(address, isSync, size);

this method (and other related methods) now only performs a straight call into `MappedMemoryUtilsProxy`. Static initializers and JNI resolution has already run, so we should no longer use too much stack.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750259314

From jvernee at openjdk.org  Mon Sep  9 13:35:08 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 9 Sep 2024 13:35:08 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <hX8tjxSP3pY1q3MRisN4iqWtSQOcuV6oaK4t5jXBRuI=.9aa25ba0-42f3-48db-b8c9-16e5da353d97@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2289932524

From sgehwolf at openjdk.org  Mon Sep  9 13:47:09 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 9 Sep 2024 13:47:09 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <hedEFBqun3RSLv2R5qNvt1SxqgpBG3CwHgLJc6oEeZE=.5a9ad16b-6a0d-4c0f-be8c-26a143d09604@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

This looks good to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20687#pullrequestreview-2289970806

From mdoerr at openjdk.org  Mon Sep  9 14:26:04 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 9 Sep 2024 14:26:04 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <V3qRV7mjtDBEK6YN42PwhxKdKTR7hS9PtH4pcJBId7s=.fb81e077-a87d-4132-918e-583b2a2d0694@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

This resolves one of the issues on AIX, but [JDK-8339780](https://bugs.openjdk.org/browse/JDK-8339780) is still a problem.

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

PR Comment: https://git.openjdk.org/jdk/pull/20914#issuecomment-2338269170

From mcimadamore at openjdk.org  Mon Sep  9 15:33:45 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 15:33:45 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
Message-ID: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>

On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
>> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
>> 
>> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
>> 
>> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop spurious change

src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128:

> 126:     static {
> 127:         registerNatives();
> 128:         isLoaded0(0, 0, 0);

This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750481339

From mcimadamore at openjdk.org  Mon Sep  9 15:33:44 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 15:33:44 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

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

  Drop spurious change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20914/files
  - new: https://git.openjdk.org/jdk/pull/20914/files/32389c43..4053014e

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

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

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

From mdoerr at openjdk.org  Mon Sep  9 15:41:06 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 9 Sep 2024 15:41:06 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <6jJRy882YNhS03ZnE9_avTwRwYmPCO5qgLmHd2TyG-E=.38e1e20c-d97f-46c9-9f1e-96da13a045e7@github.com>
 <2AyUfXadm-G7KHrhes_F_kIvYd6lu8lDH-mtPokog7c=.f4559d51-8ae7-4077-a1b1-8f48202fc6db@github.com>
Message-ID: <sB7Lv4H0LNWAwT92PlWtXBPAY9o3g9jrXdtHnfnOBFI=.0b26da6d-2be1-4f4b-ab83-f18ee1e605a2@github.com>

On Mon, 9 Sep 2024 15:30:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop spurious change
>
> src/java.base/share/classes/java/nio/MappedMemoryUtils.java line 128:
> 
>> 126:     static {
>> 127:         registerNatives();
>> 128:         isLoaded0(0, 0, 0);
> 
> This spurious line was added for debugging reasons in a previous PR - it should have been removed. Doing it now. This is probably the cause of https://bugs.openjdk.org/browse/JDK-8339780

Yes. Thanks for fixing it! Maybe you can add that issue to this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750492934

From djelinski at openjdk.org  Mon Sep  9 16:39:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 9 Sep 2024 16:39:05 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
Message-ID: <Ba1_QehFmQt7fkgDB1CuVIqH-okCT_ODhRXuGoYCMxA=.d173891f-8313-46af-bd74-cf1d33fb938e@github.com>

On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). 
> 
> This PR aims to replace these undocumented APIs with documented synchronization APIs. 
> 
> Test Performed:
> 1. All 12 tests in wepoll repo passed 
>            test-auto-drop-on-close PASS
>            test-connect-fail-events PASS
>            test-connect-success-events PASS
>            test-ctl-fuzz PASS
>            test-error PASS
>            test-leak-1 PASS
>            test-mixed-socket-types PASS
>            test-multi-poll PASS
>            test-oneshot-and-hangup PASS
>            test-reflock PASS
>            test-tree PASS
>            test-udp-pings PASS
>         DONE - 12 PASSED, 0 FAILED
> 
> 2. No new failure in JTreg test
> 3. Micro bench results: similar performance score before and after the changes
> 
> without change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c)
> 
> With the change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e)

I understand that this is a like-for-like replacement, where `reflock__signal_event` waits for another thread to call `reflock__await_event`, because that's what `NtReleaseKeyedEvent` did, even if that is not necessary from the perspective of the calling code. It looks OK, but it doesn't make the code easier to follow.

I think if we're going to touch this code, we should make it more readable than the original. We could replace the whole reflock structure with SRW locks; `reflock_ref` is semantically equivalent to `AcquireSRWLockShared`, `reflock_unref` is equivalent to `ReleaseSRWLockShared`, and `reflock_unref_and_destroy` is equivalent to `ReleaseSRWLockShared` followed by `AcquireSRWLockExclusive`.

Also, I'd very much like to avoid forking wepoll here. We keep our own copy to simplify the build system, but we don't want to maintain our own fork. @dhanalla if the https://github.com/piscisaureus/wepoll/pull/37 request is not accepted, do you plan to maintain a fork of wepoll? Or is wepoll officially dead?

Finally, this PR claims to replace the undocumented APIs, but does nothing about the usage of AFD. Is there a plan to remove the AFD too?

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

PR Review: https://git.openjdk.org/jdk/pull/20682#pullrequestreview-2290417466

From alanb at openjdk.org  Mon Sep  9 18:52:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 9 Sep 2024 18:52:05 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v2]
In-Reply-To: <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <HZIkgWxq3qbji5g5CcwUcrOrGyMycwv2R2JdD5Usvxc=.916fb76b-626e-4bbf-bccd-6b86a752ac15@github.com>
Message-ID: <QyOLsjqccBZKhXbU8mLxAhJESoXooDSGsXzUikFBGF4=.06845b05-2447-4531-9b1b-e613c3b9bc81@github.com>

On Mon, 9 Sep 2024 12:59:15 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop spurious change
>
> src/java.base/share/classes/jdk/internal/access/foreign/MappedMemoryUtilsProxy.java line 9:
> 
>> 7:  * This allows to avoid pesky initialization issues in the middle of memory mapped scoped methods.
>> 8:  */
>> 9: public interface MappedMemoryUtilsProxy {
> 
> We should probably try to consolidate this and `UmapperProxy` - I think it can be done, but it requires deeper surgery than I was willing to do in this PR.

Although this proxy class may be temporarily, I'll think you'll need to put a copyright header on it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20914#discussion_r1750760987

From mcimadamore at openjdk.org  Mon Sep  9 21:11:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 9 Sep 2024 21:11:32 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v3]
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

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

  Add copyright

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20914/files
  - new: https://git.openjdk.org/jdk/pull/20914/files/4053014e..80b61d15

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

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

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

From bpb at openjdk.org  Mon Sep  9 21:37:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 9 Sep 2024 21:37:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <U2yUCoL3e_DLuzGOLguyVKh5wXbRiCjBkV2KC8NQgfY=.203e73ce-cb4d-40e6-ac69-ad2359667086@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2339193692

From dhanalla at openjdk.org  Mon Sep  9 21:45:07 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Mon, 9 Sep 2024 21:45:07 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
 <-1OB44IWKlMG05Zn4-VTtqbbOhxKGilDbNaAui8qrbc=.aa679d75-fce6-4006-8c23-ba973d893225@github.com>
Message-ID: <Kgl3rGl_h9RFd-q7MLjmEpMiQABw68Bt6372X3oCjP8=.fe024ea1-4409-490c-8c91-86b8e1c945e1@github.com>

On Mon, 9 Sep 2024 09:21:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you confirm that you've run jdk tier2 with these changes?

@AlanBateman, I have run both Tier 1 and Tier 2 tests and can confirm that there are no new failures related to this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2339206609

From jpai at openjdk.org  Tue Sep 10 09:51:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 09:51:29 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests
Message-ID: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>

Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?

As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.

There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

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

Commit messages:
 - 8339834: Replace usages of -mx and -ms in some tests

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

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

From jpai at openjdk.org  Tue Sep 10 11:10:38 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 10 Sep 2024 11:10:38 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

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

  update JImageToolTest too

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20930/files
  - new: https://git.openjdk.org/jdk/pull/20930/files/51d15461..8214fdb5

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

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

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

From dholmes at openjdk.org  Tue Sep 10 11:10:38 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 11:10:38 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <kft-wWmR2KaY2rgRRBAFQVrSQT1Dl6ggsLupQblUWjM=.1318f1d6-f971-4921-9d4c-6a7acb247663@github.com>

On Tue, 10 Sep 2024 11:07:30 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

LGTM!

Thanks for cleaning this up.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2292111663

From djelinski at openjdk.org  Tue Sep 10 11:36:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 11:36:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
Message-ID: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>

On Fri, 9 Aug 2024 17:59:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

make/modules/java.base/Lib.gmk line 48:

> 46:     OPTIMIZATION := LOW, \
> 47:     EXTRA_HEADER_DIRS := \
> 48:         libjava/nio/ch, \

This appears to be unneeded

make/modules/java.base/Lib.gmk line 81:

> 79:         libjava/nio/ch \
> 80:         libnio/ch \
> 81:         libnio/fs \

libnio/fs is gone on all platforms other than aix; is this still necessary?

make/modules/java.base/lib/CoreLibraries.gmk line 71:

> 69:         -framework Foundation \
> 70:         -framework SystemConfiguration, \
> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \

Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.

src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:

> 573:      * Used to trigger loading of native libraries
> 574:      */
> 575:     public static void load() { }

do we still need this method?

src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2:

> 1: /*
> 2:  * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.

No changes in this file

src/java.base/unix/native/libnio/ch/NIOUtil.c line 34:

> 32: #include "jvm.h"
> 33: #include "jlong.h"
> 34: #include "sun_nio_ch_IOUtil.h"

should this be NIOUtil?

src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:

> 1095: 
> 1096:     static {
> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");

...do we still need net here?

src/java.base/windows/native/libnio/ch/NIOUtil.c line 41:

> 39: 
> 40: JNIEXPORT jboolean JNICALL
> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed

unused

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751645238
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751648219
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751651925
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751744295
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751746774
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751766398
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751770939
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751774903

From ihse at openjdk.org  Tue Sep 10 13:33:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Sep 2024 13:33:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>

On Tue, 10 Sep 2024 09:56:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> make/modules/java.base/Lib.gmk line 81:
> 
>> 79:         libjava/nio/ch \
>> 80:         libnio/ch \
>> 81:         libnio/fs \
> 
> libnio/fs is gone on all platforms other than aix; is this still necessary?

We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I <dir>` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course.

> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
> 
> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.

I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751967809
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1751975461

From djelinski at openjdk.org  Tue Sep 10 15:18:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 10 Sep 2024 15:18:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
Message-ID: <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>

On Tue, 10 Sep 2024 13:30:05 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib mswsock.lib ole32.lib shell32.lib version.lib ws2_32.lib, \
>> 
>> Can the libs added here be removed from libnio dependencies now? mswsock.lib appears to be unused by libnio, not sure about other platforms.
>
> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).

well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752181579

From alanb at openjdk.org  Tue Sep 10 17:40:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 10 Sep 2024 17:40:06 GMT
Subject: RFR: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than 10
 critical frames [v3]
In-Reply-To: <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
 <AdHWmMpeoEX2Unu8lDHj_bvR_5Gsuj_qA-cL8gIP65I=.114a8101-cd97-4473-b3ce-bb27a4c21c8c@github.com>
Message-ID: <yZgsELqGCVoLDtZi7hZN6E1dlyJ9hAqzYWpyMi5Ebgc=.d84920b6-2e39-419a-990b-a7f07abd8d96@github.com>

On Mon, 9 Sep 2024 21:11:32 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
>> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
>> 
>> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
>> 
>> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.
>
> Maurizio Cimadamore has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add copyright

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20914#pullrequestreview-2293235930

From bpb at openjdk.org  Tue Sep 10 19:58:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 19:58:48 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v6]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <YXA6_pJQmctqbCGtuy_bZntXf5TnqCRWbwwFC7jXZbs=.cfaeca45-e480-448e-a7aa-c7eb1f196cb0@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

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

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=05
  Stats: 1561 lines in 90 files changed: 771 ins; 674 del; 116 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Tue Sep 10 20:01:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 20:01:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>

On Tue, 10 Sep 2024 11:06:28 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:
> 
>> 573:      * Used to trigger loading of native libraries
>> 574:      */
>> 575:     public static void load() { }
> 
> do we still need this method?

Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752651246

From dholmes at openjdk.org  Tue Sep 10 21:34:04 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 10 Sep 2024 21:34:04 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <w_PBxIPDDrg4AUHHwHl79ygG4Fz80aywxLvYBxaNx9U=.5dd55890-3546-40c7-9da0-91b3dc27c6c1@github.com>

On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2293814493

From ihse at openjdk.org  Tue Sep 10 21:45:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 10 Sep 2024 21:45:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
Message-ID: <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>

On Tue, 10 Sep 2024 15:15:26 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> I believe this question has already been answered [here](https://github.com/openjdk/jdk/pull/20317/files#r1707599113).
>
> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.

And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1752762279

From duke at openjdk.org  Tue Sep 10 21:52:16 2024
From: duke at openjdk.org (duke)
Date: Tue, 10 Sep 2024 21:52:16 GMT
Subject: Withdrawn: 8298318: (fs) APIs for handling filename extensions
In-Reply-To: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
Message-ID: <dSYHT-qEhOz8XumNkor3kZ53AnixZmITdjs20mZgLzo=.1c4ec017-e660-4047-8b07-0690c469c44e@github.com>

On Tue, 17 Oct 2023 19:52:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Tue Sep 10 21:56:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 10 Sep 2024 21:56:11 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <O04SYND3kvHxt7qBQxYwhEMaO0qLKoxhyqqSUGI8LQ4=.308d7539-bc25-4204-83a9-3c3d5c4853b1@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2342073489

From djelinski at openjdk.org  Wed Sep 11 06:03:08 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 06:03:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
Message-ID: <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>

On Tue, 10 Sep 2024 21:42:08 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> well I'm not satisfied with the answers :) I removed mswsock.lib from libnio dependencies [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89) and the build still passed.
>
> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?

Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1753167982

From aivanov at openjdk.org  Wed Sep 11 09:10:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Sep 2024 09:10:12 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
Message-ID: <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>

On Tue, 10 Sep 2024 11:10:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   update JImageToolTest too

Looks good to me.

It could be good to remove `@author` tags from all the modified tests.

test/jdk/java/beans/Introspector/Test5102804.java line 28:

> 26:  * @bug 5102804
> 27:  * @summary Tests memory leak
> 28:  * @author Sergey Malenkov

Could you also remove the `@author` tag?

test/jdk/java/beans/Introspector/Test8027905.java line 30:

> 28:  * @bug 8027905
> 29:  * @summary Tests that GC does not affect a property type
> 30:  * @author Sergey Malenkov

Could you also remove the `@author` tag?

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296140348
PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753703304
PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753707545

From jpai at openjdk.org  Wed Sep 11 09:19:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 09:19:21 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

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

  Alexey's suggestion - remove @author tags

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20930/files
  - new: https://git.openjdk.org/jdk/pull/20930/files/8214fdb5..1596c34c

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

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

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

From jpai at openjdk.org  Wed Sep 11 09:19:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 11 Sep 2024 09:19:21 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v2]
In-Reply-To: <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <1uJqLZoqXPFfm00tj-7WbnQIF7L5JcTQCGG2IfAHCHQ=.2f0b3899-965d-45e4-9e87-807fe66a791c@github.com>
 <D8eCKs-aPhKABEBkipCVp3R9_1-rYJvQDTAt4nUov2U=.33e32331-3e44-4aed-8b27-d5c78d160d2d@github.com>
Message-ID: <9qOt-WPO0yYRk9G1dd8W2B3i_dIpNdNpoXl7PNb1Jrk=.e1b334d5-3bfa-4549-8dbc-78abf93f17ab@github.com>

On Wed, 11 Sep 2024 09:03:58 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   update JImageToolTest too
>
> test/jdk/java/beans/Introspector/Test5102804.java line 28:
> 
>> 26:  * @bug 5102804
>> 27:  * @summary Tests memory leak
>> 28:  * @author Sergey Malenkov
> 
> Could you also remove the `@author` tag?

Done - I've now updated the PR to remove these author tags. Tests continue to pass.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20930#discussion_r1753742813

From aivanov at openjdk.org  Wed Sep 11 09:31:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Wed, 11 Sep 2024 09:31:07 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <eXLvVTzpi-3Qvs9p38KECFBAYzggTKe0UoDzhp-ASSA=.3ea127f1-f2b9-443d-a893-91e1b3d48fdd@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2296196596

From mcimadamore at openjdk.org  Wed Sep 11 11:21:15 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 11 Sep 2024 11:21:15 GMT
Subject: Integrated: 8339686: java/foreign/TestMappedHandshake.java fails with
 assert(depth < max_critical_stack_depth) failed: can't have more than
 10 critical frames
In-Reply-To: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
References: <sBidB9-yT8IhDWq3Lmxbst5anPsLDTPh6fgkH52s9Rg=.7352b232-ac63-4b59-b625-da50160b5de9@github.com>
Message-ID: <7RjB5Ch6MRlUYvHgnbBM4no5grO25j8oYgpIr3OP4pk=.56d50bdb-3769-4239-ae08-4f45ba35bb66@github.com>

On Mon, 9 Sep 2024 12:57:17 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> The new test added by https://github.com/openjdk/jdk/pull/20854 fails spuriously.
> While JNI lookup is now moved into the static initializer of the `MappedMemoryUtils` class, this class might only get initialized while in the middle of a scoped context.
> 
> To address this, I created a new proxy interface, namely `MappedMemoryUtilsProxy`. This interface is used by `ScopedMemoryAccess` to call the various `force`/`load`/`isLoaded`/`unload` methods, and a singleton instance is provided inside `MappedMemoryUtils` itself, and then exposed via the `SharedSecrets` mechanism.
> 
> Crucially, `MappedMemorySegmentImpl` will now _first_ obtain a `MappedMemoryUtilsProxy` and _then_ call `ScopedMemoryAccess`. This should move all class initializer side-effects out of the scoped method context.

This pull request has now been integrated.

Changeset: 59778885
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/597788850042e7272a23714c05ba546ee6080856
Stats:     130 lines in 7 files changed: 73 ins; 31 del; 26 mod

8339686: java/foreign/TestMappedHandshake.java fails with assert(depth < max_critical_stack_depth) failed: can't have more than 10 critical frames
8339780: TestByteBuffer fails on AIX after 8339285

Reviewed-by: alanb, jvernee

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

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

From djelinski at openjdk.org  Wed Sep 11 11:23:15 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 11:23:15 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <yR9V-2ipFr-wTZefNu14ygrsJwHAKHu6VRdBdB_3HpI=.44d8f042-5654-4457-b3a2-39db1d03e1af@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

I don't think we want to do this.
On Windows, symbolic links to directories are almost identical to directories: you can have a symbolic link on the path to the working directory, and entering and exiting a symbolic link takes you back to the directory you were originally in. This behavior is observed in many Windows applications. If we change the handling of `..` in paths containing symlinks, Java's interpretation of these paths will be inconsistent with other applications.

I think we should relax the ToRealPath test; instead of making assumptions on what toRealPath should return, the test could verify that a file created using a path containing `symlink....\file` can be opened using the path returned by toRealPath. As long as toRealPath points to the same file, the exact path shouldn't matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2343358526

From ascarpino at openjdk.org  Wed Sep 11 16:11:09 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Wed, 11 Sep 2024 16:11:09 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <dc5D7ucI9MTKMW74YYMEW3OSd8gFQWJCpC_JHYnJER0=.c9c4f334-261b-4cdc-915c-59c6451f0bd9@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

The Cache.java change, and the others, look good to me.

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

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297774755

From bpb at openjdk.org  Wed Sep 11 16:36:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 16:36:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
Message-ID: <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>

On Wed, 11 Sep 2024 06:00:23 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> And you did not get `mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile`?
>
> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.

>From a clean build in the CI with `mswsock.lib` removed:


[2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755143206

From prr at openjdk.org  Wed Sep 11 16:39:05 2024
From: prr at openjdk.org (Phil Race)
Date: Wed, 11 Sep 2024 16:39:05 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <ubESMuJjjv36Eyku3WfS0LHwxIQy4uzrbAH0g4ZK2Po=.b029f131-1f37-4106-8c9c-ae6c335cafb6@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Marked as reviewed by prr (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20930#pullrequestreview-2297881944

From djelinski at openjdk.org  Wed Sep 11 16:51:08 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 16:51:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
Message-ID: <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>

On Wed, 11 Sep 2024 16:33:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Right. This PR moves FileDispatcherImpl.c to libjava, so FileDispatcherImpl.obj is no longer there. I'm guessing that our makefiles don't detect source files that were removed, and Brian didn't run `make clean`.
>
> From a clean build in the CI with `mswsock.lib` removed:
> 
> 
> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0

did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
There's no FileDispatcherImpl.obj in libnio.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755161852

From djelinski at openjdk.org  Wed Sep 11 16:54:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 11 Sep 2024 16:54:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
Message-ID: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>

On Tue, 10 Sep 2024 19:58:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/ch/IOUtil.java line 575:
>> 
>>> 573:      * Used to trigger loading of native libraries
>>> 574:      */
>>> 575:     public static void load() { }
>> 
>> do we still need this method?
>
> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.

that's a good point. The comment might need to be updated to reflect that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755166228

From bpb at openjdk.org  Wed Sep 11 19:21:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:21:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
Message-ID: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>

On Wed, 11 Sep 2024 16:48:24 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> From a clean build in the CI with `mswsock.lib` removed:
>> 
>> 
>> [2024-09-11T16:00:17,816Z] FileDispatcherImpl.obj : error LNK2019: unresolved external symbol
>> TransmitFile referenced in function Java_sun_nio_ch_FileDispatcherImpl_transferTo0
>
> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
> There's no FileDispatcherImpl.obj in libnio.

Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755434973

From bpb at openjdk.org  Wed Sep 11 19:25:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:25:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>

On Tue, 10 Sep 2024 11:27:05 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:
> 
>> 1095: 
>> 1096:     static {
>> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");
> 
> ...do we still need net here?

We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755440401

From ihse at openjdk.org  Wed Sep 11 19:34:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 11 Sep 2024 19:34:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
Message-ID: <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6NvhSVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>

On Wed, 11 Sep 2024 19:18:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> did you remove mswsock from libjava or from libnio? Libnio libraries are listed [here](https://github.com/openjdk/jdk/blob/f57b6f13e9f375bfd2e8a05afd2b900a4d42285e/make/modules/java.base/Lib.gmk#L89).
>> There's no FileDispatcherImpl.obj in libnio.
>
> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.

Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.

Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755463756

From bpb at openjdk.org  Wed Sep 11 19:34:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 19:34:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6NvhSVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
 <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6Nvh
 SVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
Message-ID: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>

On Wed, 11 Sep 2024 19:28:39 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Apparently I did remove it from libjava and not libnio. It will be fixed in the next commit. Thanks for being persistent.
>
> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.
> 
> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?

I've re-checked it and am running a CI job and will check it again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755467953

From bpb at openjdk.org  Wed Sep 11 23:52:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 11 Sep 2024 23:52:14 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <GSw1z6sxkgOPzt2knvOZILzHt_STBN2Yf1m9ML22-SI=.98add943-65e9-43dd-bd49-0d74a5e753ca@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Consider this case:

CWD = C:\Users\bpb\dev\bugs:

1. Create these directories, file, and link in the CWD:

file
dir\subdir
link -> dir\subdir
path = link....\file

2. Invoke path.toRealPath:
2.1 mainline results

follow links     C:\Users\bpb\dev\file
no follow links  C:\Users\bpb\dev\file

2.2 PR results

follow links      C:\Users\bpb\dev\bugs\file
no follow links   C:\Users\bpb\dev\bugs\link....\file

The results of the current mainline are incorrect as they locate a non-existent file. The results of the PR version both correctly locate the file.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2344985712

From jpai at openjdk.org  Thu Sep 12 02:05:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 02:05:09 GMT
Subject: RFR: 8339834: Replace usages of -mx and -ms in some tests [v3]
In-Reply-To: <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
 <ykywER5aLgblbA3dRjpha4gD0mCe2PvDFeA6RLCjjRE=.394ea566-5680-4c3e-b3b4-386a50caf3c4@github.com>
Message-ID: <hqBwPMCdFXVg5ABQG9TuVcJvghRUvnvOZCdrng9iAEI=.31f53203-637b-4d1c-8a44-4235a0a5fbec@github.com>

On Wed, 11 Sep 2024 09:19:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
>> 
>> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
>> 
>> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alexey's suggestion - remove @author tags

Thank you everyone for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/20930#issuecomment-2345106667

From jpai at openjdk.org  Thu Sep 12 02:05:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 12 Sep 2024 02:05:10 GMT
Subject: Integrated: 8339834: Replace usages of -mx and -ms in some tests
In-Reply-To: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
References: <Oqm5R6EoqEtsYJcXlCLazu7gB9iAV0g0nJ1jIzViAvI=.dd5bc096-f4b0-4ed0-a29c-8f23324e8347@github.com>
Message-ID: <xtv6kN1gsVAwNkjA2DLMx4vIra8LI3pxnZfd9f5k1JE=.090b792a-2532-4bc7-ab40-85026b57d443@github.com>

On Tue, 10 Sep 2024 09:46:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this trivial change which replaces the usages of `-mx` and `-ms` to `-Xmx` and `-Xms` in tests and in one code comment?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8339834, these options are outdated and support for them will soon be deprecated and removed as part of https://bugs.openjdk.org/browse/JDK-8286851.
> 
> There are some more tests remaining in client-libs area which too require a similar change. I'll be creating a separate JBS issue and PR for that.

This pull request has now been integrated.

Changeset: 1d392492
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d392492311daceeae12769cb9494eae63289853
Stats:     22 lines in 9 files changed: 0 ins; 5 del; 17 mod

8339834: Replace usages of -mx and -ms in some tests

Reviewed-by: aivanov, ascarpino, prr, dholmes

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

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

From bpb at openjdk.org  Thu Sep 12 02:10:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:00 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

  8337143: Clean up to address reviewer comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/4f47d5a6..853d3491

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

  Stats: 20 lines in 9 files changed: 4 ins; 11 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

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

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
Message-ID: <GEoGSCqrJf90QYMcfFb8lE1Ebo-zidvIRtPsSkgBRd8=.cb63db12-612f-4d62-9859-98c3c2f8dd59@github.com>

On Tue, 10 Sep 2024 09:54:56 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
>
> make/modules/java.base/Lib.gmk line 48:
> 
>> 46:     OPTIMIZATION := LOW, \
>> 47:     EXTRA_HEADER_DIRS := \
>> 48:         libjava/nio/ch, \
> 
> This appears to be unneeded

Agreed. See 853d349.

> src/java.base/unix/classes/sun/nio/ch/NativeThread.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2002, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> No changes in this file

There is one now. 853d349

> src/java.base/unix/native/libnio/ch/NIOUtil.c line 34:
> 
>> 32: #include "jvm.h"
>> 33: #include "jlong.h"
>> 34: #include "sun_nio_ch_IOUtil.h"
> 
> should this be NIOUtil?

Yes. See 853d349.

> src/java.base/windows/native/libnio/ch/NIOUtil.c line 41:
> 
>> 39: 
>> 40: JNIEXPORT jboolean JNICALL
>> 41: Java_sun_security_provider_NativeSeedGenerator_nativeGenerateSeed
> 
> unused

Removed. 853d349

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983126
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984164
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984274
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755985066

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
Message-ID: <KWTkjBSr9ogLMEl2ii9baLUMiNy6H6v8GO3kjjx40t4=.d9340502-77e5-4087-92af-c7a5bcbc9c93@github.com>

On Tue, 10 Sep 2024 13:26:58 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/modules/java.base/Lib.gmk line 81:
>> 
>>> 79:         libjava/nio/ch \
>>> 80:         libnio/ch \
>>> 81:         libnio/fs \
>> 
>> libnio/fs is gone on all platforms other than aix; is this still necessary?
>
> We can't add extra header dirs on a per-platform basis, so if it is needed for AIX it will need to remain here. Otoh, the only "cost" is an additional `-I <dir>` argument to the compiler, so it's not too bad. But if we can remove it, we should, of course.

Not changed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983319

From bpb at openjdk.org  Thu Sep 12 02:10:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:02 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <D5PT00rWY0s_98ztmkgICy-Hf5BJYu1SI_LyqAIVinA=.777ec576-231c-40e6-ad68-f7b76ddd119b@github.com>
 <o-gelN5GD36IB--YG4cDxHufsFWxQa2RAMSYpfGZw8U=.d698d60d-f757-4e54-90fd-ae3c4198c808@github.com>
 <z-XojHBYvMdTMouVXoxJhrS0ubI4v7WfHkrVmK5MnS8=.04785cd7-975b-492b-b099-bea06fdb8fb2@github.com>
 <bJQ-lz8NZjbPwvio0NW5ZjYTdKhneglf9iXvrTPlhRs=.ced3c873-0b15-47fc-82c1-cd0797cb8c84@github.com>
 <r84UYpxsnFSaOoUIaV3JN93bOStDa4tq0qalZsfbZNI=.ac5f4176-a7e1-4718-8206-36c06e3b7152@github.com>
 <G6S54WsqsLXh0TYJXzbqIGJpp8KBml4CY5TlXY4kNkA=.2b062e96-57a2-41a2-a5f8-40fd388824ff@github.com>
 <7-VnpoSGJvHO_08bYAUmddxMLb3SSRk2B-ngYijYIHk=.4ee37163-afbc-440d-83bb-998cb87228be@github.com>
 <UgSA3P4DxCmCrSkr0x5EWMCyNdYSy6J6Nvh
 SVd-_yLs=.db45e37f-36e4-4043-90fc-55af0e373862@github.com>
 <7rdmAwTCll7s_Utlbm32HNtQ13-rvwINI18qdkRb93Y=.9bbe2671-a7af-450c-b7bd-c0193cab6217@github.com>
Message-ID: <8iOw1S8wQQ6G7-laGTbkZI5rnQjOZrbqv0iZ9BmThTY=.4baaded4-c285-45a2-83c1-d0fd7f3e7ef3@github.com>

On Wed, 11 Sep 2024 19:31:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Just to be absolutely clear: All my other comments about removing unneeded libraries were about libnio, not libjava. I realize I made the comment in the PR next to libjava, but my intention was to ask if the list of libraries for libnio could be trimmed down.
>> 
>> Can you confirm that you really checked this for libnio, and not libjava, or -- better yet -- recheck these and making sure that you check it for libnio?
>
> I've re-checked it and am running a CI job and will check it again.

Re-tests passed. See 853d349.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983781

From bpb at openjdk.org  Thu Sep 12 02:10:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:03 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <HunVx5ZaUG4ckBirhMWKb-NCbotRl1eoxG9zdDptt_E=.80834c9e-dcea-490c-92a2-c1a6d4c1e805@github.com>
 <_iJSRSBsqynoSxSAHtwAaaM6YG3mhrhyoeyNl83dFNc=.c8b3ddf0-dea3-46d1-986f-0882fc739fd0@github.com>
Message-ID: <ZwzJfVdGexSdlhmip5DQS-vPZD8Ss3dwJtP8JNxMMbo=.aadd867f-67c4-4c95-82d5-211a15159416@github.com>

On Wed, 11 Sep 2024 16:51:43 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Yes, it still needs to be called in a few places, e.g., for classes whose native component needs the `fdval()` and `handleval()` functions.
>
> that's a good point. The comment might need to be updated to reflect that.

Comments added in 853d349.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755983974

From bpb at openjdk.org  Thu Sep 12 02:10:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 02:10:03 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
Message-ID: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>

On Wed, 11 Sep 2024 19:22:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsNativeDispatcher.java line 1097:
>> 
>>> 1095: 
>>> 1096:     static {
>>> 1097:         jdk.internal.loader.BootLoader.loadLibrary("net");
>> 
>> ...do we still need net here?
>
> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.

Moved to `NTLMAuthentication` static initializer. 853d349

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1755984949

From djelinski at openjdk.org  Thu Sep 12 06:27:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 12 Sep 2024 06:27:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
Message-ID: <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>

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

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Clean up to address reviewer comments

Thanks for making the changes. LGTM, assuming that tests still pass.

One question in line.

src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221:

> 219: static futimesat_func* my_futimesat_func = NULL;
> 220: static futimens_func* my_futimens_func = NULL;
> 221: #ifndef _ALLBSD_SOURCE

This change looks unrelated. Was it intentional?

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

Marked as reviewed by djelinski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2299319884
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1756202839

From djelinski at openjdk.org  Thu Sep 12 08:01:13 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Thu, 12 Sep 2024 08:01:13 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <OWtAPfBUtS2t3NQWWwB8xizqesH2qUP73_zCpKHQgA4=.1a6a656c-c3e5-4e96-ba73-838f5532069b@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Well let me show you a counterexample:
Setup:

C:\>mkdir tmp\cwd\dir\subdir

C:\>cd tmp\cwd

C:\tmp\cwd>mklink /d link dir\subdir
symbolic link created for link <<===>> dir\subdir

C:\tmp\cwd>jshell.exe

Before your changes:

jshell> Path.of("link/../../file")
$1 ==> link....\file

jshell> Files.createFile($1)
$2 ==> link....\file

jshell> Files.exists($1)
$3 ==> true

jshell> Files.exists($1.toRealPath())
$4 ==> true

After your changes:

jshell> Path.of("link/../../file")
$1 ==> link....\file

jshell> Files.createFile($1)
$2 ==> link....\file

jshell> Files.exists($1)
$3 ==> true

jshell> Files.exists($1.toRealPath())
|  Exception java.nio.file.NoSuchFileException: C:\tmp\cwd\file
|        at WindowsException.translateToIOException (WindowsException.java:85)
|        at WindowsException.rethrowAsIOException (WindowsException.java:103)
|        at WindowsException.rethrowAsIOException (WindowsException.java:108)
|        at WindowsLinkSupport.collapseDots (WindowsLinkSupport.java:238)
|        at WindowsLinkSupport.getRealPath (WindowsLinkSupport.java:285)
|        at WindowsPath.toRealPath (WindowsPath.java:944)
|        at WindowsPath.toRealPath (WindowsPath.java:42)
|        at (#4:1)

`path` and `path.toRealPath()` are supposed to point to the same file, but as you can see, this does not happen here.

I guess you could adjust all the methods in `Files` class to be consistent with the new `toRealPath` implementation, but this would break consistency with other Windows apps, see for example:

C:\tmp\cwd>type file
The system cannot find the file specified.

C:\tmp\cwd>type link....\file

C:\tmp\cwd>

Based on the above, I think the current `toRealPath` implementation on Windows is doing just fine, only the `ToRealPath` test needs to be fixed.

As far as I could tell, `Path.toRealPath` does not make any promises about what the resulting path should be. The only requirement is that the path should refer to the same file, so the current implementation does not violate the spec.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2345533160

From bpb at openjdk.org  Thu Sep 12 15:43:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:43:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
Message-ID: <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>

On Thu, 12 Sep 2024 06:24:50 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Thanks for making the changes. LGTM, assuming that tests still pass.

The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating.

> src/java.base/unix/native/libjava/nio/fs/UnixNativeDispatcher.c line 221:
> 
>> 219: static futimesat_func* my_futimesat_func = NULL;
>> 220: static futimens_func* my_futimens_func = NULL;
>> 221: #ifndef _ALLBSD_SOURCE
> 
> This change looks unrelated. Was it intentional?

Yes. The variable on the next line `my_lutimes_func` caused an unused variable error in the macOS build.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346633671
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757123250

From bpb at openjdk.org  Thu Sep 12 15:43:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:43:13 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
Message-ID: <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>

On Thu, 12 Sep 2024 02:05:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> We don't need it in `libjava`, but `NTLMAuthentication` was (perhaps unwittingly) relying on it to load `net.dll` during boot phase 2. I'll move the load to a more appropriate location in the next commit.
>
> Moved to `NTLMAuthentication` static initializer. 853d349

@dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1757130549

From alanb at openjdk.org  Thu Sep 12 15:46:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 12 Sep 2024 15:46:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
 <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
Message-ID: <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>

On Thu, 12 Sep 2024 15:38:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> The tests passed the JDK tiers 1-3 tests on Linux, macOS, and Windows. In any case, I will run another round of tests before integrating.

Can you hold off integrating, I plan to go over the changes soon.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346644977

From bpb at openjdk.org  Thu Sep 12 15:51:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 15:51:10 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <mkzOm6vmqdUFtzlffvNBkFlIrKhO0eP27EsibnN1y48=.23654451-5dee-4d85-b5e4-3d1e33fcb900@github.com>
 <Vv_nbI5x_oUvdM2YPIc-d9eXfWo9R08FzaQRdoyniVE=.8f1eeff4-fa9f-4578-a370-8a00a834eebd@github.com>
 <bR_LAEbbJNy6uwRvxYcyM3Q_yF8nPyAOd76OPZPb-EE=.068b1001-f855-4a6c-bf32-51a28088dc29@github.com>
Message-ID: <i2i7oyoiicpHXF16NDxjZ5utlPCc3IZSzXv8BeUZ5bs=.dec7a08c-48de-4d35-ba37-7847901a6964@github.com>

On Thu, 12 Sep 2024 15:43:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Can you hold off integrating, I plan to go over the changes soon.

I don't plan to integrate until you have reviewed it. I set the minimum reviewer count to 3 to avoid doing so accidentally.

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2346655197

From pminborg at openjdk.org  Thu Sep 12 18:22:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 12 Sep 2024 18:22:42 GMT
Subject: RFR: 8325949: Create an internal utility method for creating VarHandle
 instances
Message-ID: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>

This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.

While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:

| Class File                                      | Base [Bytes] | Patch [Byte] |
| --------------------------------| ------------- | ------------ |
| FutureTask.class                          |             10255 |           10154 |
| AtomicBoolean.class                   |              5364 |             5161 |
|AtomicMarkableReference.class |              3890 |            3687 |

![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)

The new `MethodHandlesInternal.class` file is of size 2012 bytes.

In total for `java.base` we have:

| Build map "jdk"  | Size [Bytes] |
| ---------------| ------------- |
| Base                 |        5963657 |
| Patch                |        5962751 |
| Delta                 |                906|

For 60 billion instances, this represents 54 TB.

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

Commit messages:
 - Fix copyright headers
 - Introduce MethodHandlesInternal

Changes: https://git.openjdk.org/jdk/pull/20972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8325949
  Stats: 423 lines in 31 files changed: 109 ins; 202 del; 112 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

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

From rriggs at openjdk.org  Thu Sep 12 19:26:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 12 Sep 2024 19:26:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <C3F9JHtUf3BMCvqDA9SxJiBAXCbH0X3du21nBYUAm6A=.74cc321d-8ac9-4b12-88e0-79d2570831cb@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 47:

> 45:     private MethodHandlesInternal() {}
> 46: 
> 47:     public static VarHandle findVarHandleOrThrow(MethodHandles.Lookup lookup, Class<?> recv, String name, Class<?> type) {

The method naming might benefit from being clear that failure is fatal; never call it with arguments that might fail.
Perhaps even throw java.lang.InternalError. ExceptionInInitializerError might be misconstrued as a some kind of race or being called too early.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757467476

From liach at openjdk.org  Thu Sep 12 19:33:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 12 Sep 2024 19:33:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders)

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1:

> 1: /*

I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2347081526
PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1757474972

From bpb at openjdk.org  Thu Sep 12 20:43:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 20:43:21 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
Message-ID: <ysd1kyQbOaZH2e1HP4tSAlazmjgj0octWdlN0qqW7x0=.85d42e5a-5451-435e-9f8a-2ba6a76d7c26@github.com>

On Fri, 1 Mar 2024 21:48:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:
> 
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

This does not address your example above with respect to `toRealPath`, but the behavior it shows seems inconsistent. 

The setup is the same:

`/tmp/cwd/dir/subdir` or `C:\tmp\cwd\dir\subdir` where `link` is a symbolic link in `cwd` with the relatve target `dir/subdir`.

Then running jshell in `cwd`, the call

`Files.createFile(Path.of("link/../../file")`

creates `/tmp/cwd/file` on macOS whereas on Windows it creates `C:\tmp\file`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347200176

From bpb at openjdk.org  Thu Sep 12 20:55:11 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 20:55:11 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2347219212

From bpb at openjdk.org  Thu Sep 12 21:53:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 12 Sep 2024 21:53:09 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v5]
In-Reply-To: <OWtAPfBUtS2t3NQWWwB8xizqesH2qUP73_zCpKHQgA4=.1a6a656c-c3e5-4e96-ba73-838f5532069b@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <xH3qM4vRkX6O_ikJ2W62U6uE3a5EQTosjNplaM_rVxU=.d39542c1-744f-4ed8-b097-844f3669f64d@github.com>
 <OWtAPfBUtS2t3NQWWwB8xizqesH2qUP73_zCpKHQgA4=.1a6a656c-c3e5-4e96-ba73-838f5532069b@github.com>
Message-ID: <myYk5UnS-6-T5HoIPq5MyM-KqL_isyUcpXYLCqxHe04=.3c72528b-1bdc-4a80-bf4c-07c12014eb2b@github.com>

On Thu, 12 Sep 2024 07:58:21 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

> Based on the above, I think the current `toRealPath` implementation on Windows is doing just fine, only the `ToRealPath` test needs to be fixed.

Based on these comments in [WindowsPath](https://github.com/openjdk/jdk/blob/81ff91ef27a6a856ae2c453a9a9b8333b91da3ab/src/java.base/windows/classes/sun/nio/fs/WindowsPath.java#L202)

        // Long paths need to have "." and ".." removed and be prefixed with
        // "\?". Note that it is okay to remove ".." even when it follows
        // a link - for example, it is okay for foo/link/../bar to be changed
        // to foo/bar. The reason is that Win32 APIs to access foo/link/../bar
        // will access foo/bar anyway (which differs to Unix systems)

it seems safe to say that the current `toRealPath()` implementation is, as you say, all right as is. If these comments are correct, then it appears that on Unix the `link` in `foo/link/../bar` would first be resolved and then the `..` would be removed along with the element preceding it, but on Windows, `link` is just treated as a name element without resolution and is summarily removed along with `..`. This is consistent with the `Files.createFile(Path.of("link/../../file"))` example I posted above.

> [...] only the `ToRealPath` test needs to be fixed.
> 
> As far as I could tell, `Path.toRealPath` does not make any promises about what the resulting path should be. The only requirement is that the path should refer to the same file, so the current implementation does not violate the spec.

At this point, I tend to agree.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347307267
PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2347308341

From darcy at openjdk.org  Fri Sep 13 02:52:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 02:52:37 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
Message-ID: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>

Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

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

Commit messages:
 - JDK-8340082: Use inline return tag in java.base

Changes: https://git.openjdk.org/jdk/pull/20981/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20981&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8340082
  Stats: 59 lines in 21 files changed: 0 ins; 27 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/20981.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20981/head:pull/20981

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

From duke at openjdk.org  Fri Sep 13 03:15:05 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 13 Sep 2024 03:15:05 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kB-VZf1Utvcw8idcMTCqRjxS_E9upkH7stjwJlpEeV8=.21577be3-bcbb-4218-b804-d42c8f7bfcdb@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <kB-VZf1Utvcw8idcMTCqRjxS_E9upkH7stjwJlpEeV8=.21577be3-bcbb-4218-b804-d42c8f7bfcdb@github.com>
Message-ID: <rSsMDE9m1Ah9bl8u0ODoBDW60nMctazrfTFQRTjFnDQ=.18ed13e6-80e7-45db-9b0f-3f1fa4199f9b@github.com>

On Tue, 27 Aug 2024 17:01:19 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> I looked at this issue a bit more. Looking at the IANA Charset registry (https://www.iana.org/assignments/character-sets/character-sets.xhtml) which `Charset` class is based on, `ISO-8859-8-I` is not an alias to `ISO-8859-8`, but it is defined as a distinct `Preferred MIME name`. So I don't think current proposed solution is correct. (It would return ISO-8859-8-I as an alias to ISO-8859-8). Also, looking at the RFC-1556, in which this ISO-8859-8-I encoding is defined, there are other encodings, i.e., ISO-8859-6-I, ISO-8859-6-E, and ISO-8859-8-E. Why are they not relevant, but ISO-8859-8-I is?
> Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018), unless Arabic/Hebrew speaking communities jumped in and provide rationale to support them.

@naotoj does the mapping need to be removed from:

https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770

I ask because JakartaMail /Angus Mail is a similar usecase to this code.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2347953621

From iris at openjdk.org  Fri Sep 13 03:51:03 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 13 Sep 2024 03:51:03 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <wAV473zyPDFQd-ZCIA3dO0mshZj-zXquNxuiswcwvZQ=.e92bc619-7d27-4ede-aa47-a25b5c2cc68a@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302073195

From duke at openjdk.org  Fri Sep 13 07:05:14 2024
From: duke at openjdk.org (xpbob)
Date: Fri, 13 Sep 2024 07:05:14 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed message
 for NoSuchFileException
Message-ID: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>

(fs) Files.copy include symbolic link detailed message for NoSuchFileException

Description
Simulation case:

touch testfile
ln -s testfile testlink
mv testfile testfile1


code:

    public static void main(String[] args) throws IOException {
        Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx"));
    }


Program current information?
Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink


Devops check file exists with ll

After additional information?
Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile

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

Commit messages:
 - 8340087: (fs) Files.copy include symbolic link detailed message for NoSuchFileException

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

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

From alanb at openjdk.org  Fri Sep 13 07:22:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Sep 2024 07:22:05 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException
In-Reply-To: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
Message-ID: <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>

On Fri, 13 Sep 2024 07:00:24 GMT, xpbob <duke at openjdk.org> wrote:

> (fs) Files.copy include symbolic link detailed message for NoSuchFileException
> 
> Description
> Simulation case:
> 
> touch testfile
> ln -s testfile testlink
> mv testfile testfile1
> 
> 
> code:
> 
>     public static void main(String[] args) throws IOException {
>         Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx"));
>     }
> 
> 
> Program current information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink
> 
> 
> Devops check file exists with ll
> 
> After additional information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile

src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013:

> 1011:                     if (symbolicLink != null) {
> 1012:                         throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink);
> 1013:                     }

The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage.

In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1758314375

From duke at openjdk.org  Fri Sep 13 07:32:14 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 13 Sep 2024 07:32:14 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence:

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1221:

> 1219: 
> 1220:             /**
> 1221:              * {@return the pattern used to create this filter}

Suggestion:

             * {@return the pattern used to create this filter}.

src/java.base/share/classes/java/io/ObjectInputStream.java line 3862:

> 3860: 
> 3861:         /**
> 3862:          * {@return the number of bytes read from the input stream}

Suggestion:

         * {@return the number of bytes read from the input stream}.

src/java.base/share/classes/java/lang/annotation/Retention.java line 48:

> 46: public @interface Retention {
> 47:     /**
> 48:      * {@return the retention policy}

Suggestion:

     * {@return the retention policy}.

src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 59:

> 57: 
> 58:     /**
> 59:      * {@return the length of the input}

Suggestion:

     * {@return the length of the input}.

src/java.base/share/classes/java/nio/charset/MalformedInputException.java line 66:

> 64: 
> 65:     /**
> 66:      * {@return the message}

Suggestion:

     * {@return the message}.

src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 59:

> 57: 
> 58:     /**
> 59:      * {@return the length of the input}

Suggestion:

     * {@return the length of the input}.

src/java.base/share/classes/java/nio/charset/UnmappableCharacterException.java line 66:

> 64: 
> 65:     /**
> 66:      * {@return the message}

Suggestion:

     * {@return the message}.

src/java.base/share/classes/java/time/format/TextStyle.java line 140:

> 138: 
> 139:     /**
> 140:      * {@return the stand-alone style with the same size}

Suggestion:

     * {@return the stand-alone style with the same size}.

src/java.base/share/classes/java/util/concurrent/SynchronousQueue.java line 480:

> 478: 
> 479:     /**
> 480:      * {@return a zero-length array}

Suggestion:

     * {@return a zero-length array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicBoolean.java line 179:

> 177: 
> 178:     /**
> 179:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicInteger.java line 343:

> 341: 
> 342:     /**
> 343:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerArray.java line 369:

> 367: 
> 368:     /**
> 369:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicLong.java line 344:

> 342: 
> 343:     /**
> 344:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicLongArray.java line 369:

> 367: 
> 368:     /**
> 369:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReference.java line 272:

> 270: 
> 271:     /**
> 272:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicReferenceArray.java line 300:

> 298: 
> 299:     /**
> 300:      * {@return the String representation of the current values of array}

Suggestion:

     * {@return the String representation of the current values of array}.

src/java.base/share/classes/java/util/concurrent/atomic/DoubleAccumulator.java line 192:

> 190: 
> 191:     /**
> 192:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/concurrent/atomic/LongAccumulator.java line 186:

> 184: 
> 185:     /**
> 186:      * {@return the String representation of the current value}

Suggestion:

     * {@return the String representation of the current value}.

src/java.base/share/classes/java/util/jar/Manifest.java line 122:

> 120: 
> 121:     /**
> 122:      * {@return the main Attributes for the Manifest}

Suggestion:

     * {@return the main Attributes for the Manifest}.

src/java.base/share/classes/java/util/zip/Deflater.java line 785:

> 783: 
> 784:     /**
> 785:      * {@return the ADLER-32 value of the uncompressed data}

Suggestion:

     * {@return the ADLER-32 value of the uncompressed data}.

src/java.base/share/classes/java/util/zip/Inflater.java line 285:

> 283: 
> 284:     /**
> 285:      * {@return true if a preset dictionary is needed for decompression}

Suggestion:

     * {@return true if a preset dictionary is needed for decompression}.

src/java.base/share/classes/java/util/zip/Inflater.java line 296:

> 294:     /**
> 295:      * {@return true if the end of the compressed data stream has been
> 296:      * reached}

Suggestion:

     * {@return true if the end of the compressed data stream has been
     * reached}.

src/java.base/share/classes/java/util/zip/Inflater.java line 602:

> 600: 
> 601:     /**
> 602:      * {@return the ADLER-32 value of the uncompressed data}

Suggestion:

     * {@return the ADLER-32 value of the uncompressed data}.

src/java.base/share/classes/java/util/zip/ZipEntry.java line 141:

> 139: 
> 140:     /**
> 141:      * {@return the name of the entry}

Suggestion:

     * {@return the name of the entry}.

src/java.base/share/classes/java/util/zip/ZipFile.java line 501:

> 499: 
> 500:     /**
> 501:      * {@return the path name of the ZIP file}

Suggestion:

     * {@return the path name of the ZIP file}.

src/java.base/share/classes/java/util/zip/ZipFile.java line 562:

> 560: 
> 561:     /**
> 562:      * {@return an enumeration of the ZIP file entries}

Suggestion:

     * {@return an enumeration of the ZIP file entries}.

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

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302321414
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326174
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326396
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758326761
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327147
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327483
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327766
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758327939
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328188
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328373
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328561
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328660
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328760
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328833
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758328935
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329031
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329171
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329268
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329376
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329468
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329520
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329601
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329771
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758329873
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330051
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330157
PR Review Comment: https://git.openjdk.org/jdk/pull/20981#discussion_r1758330290

From pminborg at openjdk.org  Fri Sep 13 07:42:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:42:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
Message-ID: <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>

On Thu, 12 Sep 2024 19:29:47 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think we can elide the `Lookup` argument to perform a always-full-permission lookup operation to simplify call sequence; or, to elide the `recv` receiver argument as it is almost always `lookup.lookupClass()` (except for a few lazy holders)

If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way?

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348250197

From pminborg at openjdk.org  Fri Sep 13 07:50:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 07:50:49 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |             10255 |           10154 |
> | AtomicBoolean.class                   |              5364 |             5161 |
> |AtomicMarkableReference.class |              3890 |            3687 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |        5963657 |
> | Patch                |        5962751 |
> | Delta                 |                906|
> 
> For 60 billion instances, this represents 54 TB.

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

  Rename and reformat

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/87d7a477..1dee24ab

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

  Stats: 98 lines in 31 files changed: 32 ins; 3 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

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

From alanb at openjdk.org  Fri Sep 13 07:50:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 13 Sep 2024 07:50:49 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
 <B1uEx0TTADwiXuEDS6SbS5_t0fYnd8u_lhUkmKWYiSU=.e9c8ff40-9cd3-45b3-8483-8a87efd33c4e@github.com>
Message-ID: <VhyXXaahqZbPl04iYbJLo-4VpRisviFkhhqklPTxVWk=.b6d4a9cb-a2f5-4fe4-ad57-9b39c2e0440b@github.com>

On Fri, 13 Sep 2024 07:39:40 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> If we could access `MethodHandles.Lookup.IMPL_LOOKUP `, we could use this as a lookup and elide the lookup arg. Any ideas to do this in a "polite" way?

Lookup.IMPL_LOOKUP should be guarded closely, I don't think we should remove the need to provide a Lookup with the appropriate access.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2348266276

From duke at openjdk.org  Fri Sep 13 08:54:19 2024
From: duke at openjdk.org (xpbob)
Date: Fri, 13 Sep 2024 08:54:19 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException [v2]
In-Reply-To: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
Message-ID: <1HCAbXIVJfinjn69DXgqFLCou6dZypPfJ95W2kOT1Ng=.341c8626-709b-4ee8-b8c3-527f9d390c89@github.com>

> (fs) Files.copy include symbolic link detailed message for NoSuchFileException
> 
> Description
> Simulation case:
> 
> touch testfile
> ln -s testfile testlink
> mv testfile testfile1
> 
> 
> code:
> 
>     public static void main(String[] args) throws IOException {
>         Files.copy(Paths.get("/data/testfiles/testlink"), Paths.get("/data/testfiles/xx"));
>     }
> 
> 
> Program current information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink
> 
> 
> Devops check file exists with ll
> 
> After additional information?
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile

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

  Reimport package

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20984/files
  - new: https://git.openjdk.org/jdk/pull/20984/files/0a205908..c19142e1

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

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

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

From duke at openjdk.org  Fri Sep 13 08:54:20 2024
From: duke at openjdk.org (xpbob)
Date: Fri, 13 Sep 2024 08:54:20 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException [v2]
In-Reply-To: <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
 <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>
Message-ID: <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com>

On Fri, 13 Sep 2024 07:19:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reimport package
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013:
> 
>> 1011:                     if (symbolicLink != null) {
>> 1012:                         throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink);
>> 1013:                     }
> 
> The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage.
> 
> In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong.

Thanks for review
@AlanBateman 
The NoSuchFileException in this case is correct,The code is to add contextual information for NoSuchFileException.


In this  case, the symlinked file does not exist, the symlink exist.

NoSuchFileException info is symlink.

`ls path to symlink`   The detection file exists.This is supposed to detect the  symlinked file.Expect to add symbolic link information in the NoSuchFileException

before

Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink

after

Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile





The condition for throwing a NoSuchFileException has not changed


    private IOException translateToIOException(String file, String other) {
??
        if (errno() == UnixConstants.ENOENT)
            return new NoSuchFileException(file, other, null);
??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1758459486

From prappo at openjdk.org  Fri Sep 13 09:16:05 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 09:16:05 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <iJXmbY-RQ-jmbO73tOzXhykq8zxAaOrSK9-K4v0cl3k=.8b50d943-7071-47ba-92da-b5f322d214ce@github.com>
Message-ID: <WIBkJB7ZD3VqCBawUTXrDKGxEaG2A-x8N62Rc_YiW4g=.21341179-4f81-490d-b898-4ed6ad63a7f9@github.com>

On Fri, 13 Sep 2024 07:29:00 GMT, ExE Boss <duke at openjdk.org> wrote:

> The?old?version of?the?doc?comments had?a?`.` at?the?end of?the?first?sentence:

The new version has it too, but in the final, generated form: https://docs.oracle.com/en/java/javase/22/docs/specs/javadoc/doc-comment-spec.html#return

`{@return blah}` expands to `Returns blah.`

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

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348446043

From sgehwolf at openjdk.org  Fri Sep 13 09:32:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Sep 2024 09:32:12 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>
Message-ID: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com>

On Thu, 12 Sep 2024 20:52:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.

@bplb Do you mean the updated one in this PR or the old one without this patch?

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2348481147

From duke at openjdk.org  Fri Sep 13 09:48:05 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 13 Sep 2024 09:48:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <qRIqf5CYg9O9Em3Du7Ld-yH6-6vDVDBxQEgjkQ0BRTU=.24838eb3-2821-41c9-8273-01362678cf2a@github.com>
Message-ID: <tlQB7aJJWcsBwvCCgbjAqMCU8HMzO4-rVby3KkB9DnE=.0ea5b060-9d7b-4615-b17d-37ae32353527@github.com>

On Thu, 12 Sep 2024 19:30:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 1:
> 
>> 1: /*
> 
> I would argue this is closer to invoke than reflect, so can consider moving to `sun.invoke` or even create a new `jdk.internal.invoke` package.

I?m?in?favour of?introducing `jdk.internal.invoke`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758550297

From prappo at openjdk.org  Fri Sep 13 10:24:04 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 10:24:04 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <63jr3o7GvnCQc-Fftek57SoIO58BsAblgKia69hF5fo=.733822a2-8ba0-42fd-a6bb-eb7bcb641bbc@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Thanks, Joe. This looks good, especially considering that the change was produced with the help of a quick-and-dirty, regex-based script. This change is certainly enough to spread awareness of this relatively new javadoc feature.

I remember I had a more involved script that used `javax.lang.model` and string similarity metrics. That script captured a lot more candidates for `{@return}`. But on the other hand, once you start considering non-exact matches, it requires human judgement and increases review effort.

---

Separately, this PR has helped me put a finger on what I __don't__ like about `{@return}`. What I don't like is the generated HTML. `{@return}` saves mental effort when reading raw javadoc in source, but it provides no similar service to the reader of the final, HTML form. Maybe it's just me, but it looks needlessly bloated and silly:

<img width="201" alt="browser screenshot of javax.lang.model.element.AnnotationValue#getValue" src="https://github.com/user-attachments/assets/1a7ee92f-7006-4b09-bc50-e23d9148c3ad">

Maybe if a method's main description consisted only of `{@return}`, we could skip the first sentence in the "Method Details" section and just output `Returns:`? Any further discussion should happen on the javadoc-dev mailing list.

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

Marked as reviewed by prappo (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302744094

From lancea at openjdk.org  Fri Sep 13 12:18:04 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 13 Sep 2024 12:18:04 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <YByg4js_VhMFPvLfzkDn76B_lWK8Iz85WjG-dCaGIKM=.841a4999-de88-4bca-b224-d36f4513f605@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

I went through the changes and they look fine.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2302964654

From liach at openjdk.org  Fri Sep 13 12:43:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 12:43:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
Message-ID: <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>

On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |             10255 |           10154 |
>> | AtomicBoolean.class                   |              5364 |             5161 |
>> |AtomicMarkableReference.class |              3890 |            3687 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |        5963657 |
>> | Patch                |        5962751 |
>> | Delta                 |                906|
>> 
>> For 60 billion instances, this represents 54 TB.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename and reformat

src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50:

> 48:     private MethodHandlesInternal() {}
> 49: 
> 50:     public static VarHandle findVarHandle(MethodHandles.Lookup lookup,

Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class<?> type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758795681

From liach at openjdk.org  Fri Sep 13 13:10:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 13:10:06 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`? https://github.com/openjdk/jdk/blob/f7cb6e23194c8e08a699eca84ae9b424c0283588/src/java.base/share/classes/java/lang/reflect/ParameterizedType.java#L50-L58

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

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348921651

From prappo at openjdk.org  Fri Sep 13 13:17:03 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 13 Sep 2024 13:17:03 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
Message-ID: <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>

On Fri, 13 Sep 2024 13:07:03 GMT, Chen Liang <liach at openjdk.org> wrote:

> This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`?

Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little.

If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools.

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

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2348937038

From djelinski at openjdk.org  Fri Sep 13 13:26:05 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 13 Sep 2024 13:26:05 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <tlTjaZss1wHQl-SWSqFiODYdOg03NitVvUnQ6HNaFQk=.7d3d0434-3634-42fd-b7fc-3ba8704a7e7c@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303131739

From pminborg at openjdk.org  Fri Sep 13 14:46:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 13 Sep 2024 14:46:09 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <n-SerjbIumSRZ58QnRyJtCXviqFOlHl7ROlK4iLGTrw=.fb21b7b0-6a09-4605-aa53-e5f51725fac1@github.com>
Message-ID: <DqvZlK_w6Iovei0l49jJf6ezEfJuc2KfxCiXrmtKd9k=.98850292-1214-45b8-a075-44244cdccc7d@github.com>

On Fri, 13 Sep 2024 12:40:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename and reformat
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandlesInternal.java line 50:
> 
>> 48:     private MethodHandlesInternal() {}
>> 49: 
>> 50:     public static VarHandle findVarHandle(MethodHandles.Lookup lookup,
> 
> Do you think we should create a 3-arg overload like `Lookup lookup, String name, Class<?> type` that calls `findVarHandle(lookup, lookup.lookupClass(), name, type);` for ease of use at many call sites?

The pro: Simpler code at the call site. The con: it is a bit magic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1758999490

From bpb at openjdk.org  Fri Sep 13 15:45:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 15:45:10 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>
 <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com>
Message-ID: <Z_xGWRNPB2bcfkasXdhLMQhEuA7wA8hroFRAxNijE0Q=.b6d118fe-d14f-439a-aa2a-9a33565af4a2@github.com>

On Fri, 13 Sep 2024 09:29:05 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.
> 
> @bplb Do you mean the updated one in this PR or the old one without this patch?

@jerboaa The latest version in this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2349252518

From dfuchs at openjdk.org  Fri Sep 13 16:11:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
Message-ID: <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>

On Thu, 12 Sep 2024 15:40:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Moved to `NTLMAuthentication` static initializer. 853d349
>
> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?

hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759124071

From sgehwolf at openjdk.org  Fri Sep 13 16:11:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 13 Sep 2024 16:11:14 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <Z_xGWRNPB2bcfkasXdhLMQhEuA7wA8hroFRAxNijE0Q=.b6d118fe-d14f-439a-aa2a-9a33565af4a2@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
 <YudESecYtLcrautVzJftw_zRLJgS0YxYA1I5M_ou6Z4=.97d70565-863f-4cb6-9576-7821b2b70ed9@github.com>
 <_9KiXoXklJePuiscdaV9D9RiM_dvq4oPtmGqgBQ0TW0=.a41f4787-ed84-4a5a-81fb-3438c0dd9db5@github.com>
 <Z_xGWRNPB2bcfkasXdhLMQhEuA7wA8hroFRAxNijE0Q=.b6d118fe-d14f-439a-aa2a-9a33565af4a2@github.com>
Message-ID: <8N4EQ5QRKomSaNrHYN1Vo-K_S35rRw042SNe8Oom5us=.6a4bac69-eea5-4c96-b858-36bbe7bd4458@github.com>

On Fri, 13 Sep 2024 15:42:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.
> > 
> > 
> > @bplb Do you mean the updated one in this PR or the old one without this patch?
> 
> @jerboaa The latest version in this PR.

OK, thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2349301991

From dfuchs at openjdk.org  Fri Sep 13 16:11:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
Message-ID: <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>

On Fri, 13 Sep 2024 16:05:37 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> @dfuch Would you please check whether the change at line 71 in the updated version of `NTLMAuthentication` is the correct place for this load?
>
> hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

I wonder - do you see any failure if you don't load libnet from there?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759125047

From bpb at openjdk.org  Fri Sep 13 16:11:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:11:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
Message-ID: <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>

On Fri, 13 Sep 2024 16:06:26 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> hmm...  I don't see any issue in adding the load call to `NTLMAuthentication` but I'm surprised that it's even needed: I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
>
> I wonder - do you see any failure if you don't load libnet from there?

Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759128167

From bpb at openjdk.org  Fri Sep 13 16:15:16 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:15:16 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
Message-ID: <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>

On Fri, 13 Sep 2024 16:08:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I wonder - do you see any failure if you don't load libnet from there?
>
> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.

> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.

In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759132986

From bpb at openjdk.org  Fri Sep 13 16:19:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:19:06 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException [v2]
In-Reply-To: <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
 <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>
 <3hQD-SREYfMb0rBGLvRd-wlNp9iUibrRhiUIFLHqS4c=.947022c4-56dd-4ff0-8473-fa2700f1597d@github.com>
Message-ID: <_MswEWenPCynJ2_FdOi7wq00ICbn_Fc2RHVcbHURQfw=.02fb4365-1959-4f4c-a5be-bbbf3cd95c23@github.com>

On Fri, 13 Sep 2024 08:49:22 GMT, xpbob <duke at openjdk.org> wrote:

>> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013:
>> 
>>> 1011:                     if (symbolicLink != null) {
>>> 1012:                         throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink);
>>> 1013:                     }
>> 
>> The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage.
>> 
>> In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong.
>
> Thanks for review
> @AlanBateman 
> The NoSuchFileException in this case is correct,The code is to add contextual information for NoSuchFileException.
> 
> 
> In this  case, the symlinked file does not exist, the symlink exist.
> 
> NoSuchFileException info is symlink.
> 
> `ls path to symlink`   The detection file exists.This is supposed to detect the  symlinked file.Expect to add symbolic link information in the NoSuchFileException
> 
> before
> 
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink
> 
> after
> 
> Exception in thread "main" java.nio.file.NoSuchFileException: /data/testfiles/testlink: due to testfile
> 
> 
> 
> 
> 
> The condition for throwing a NoSuchFileException has not changed
> 
> 
>     private IOException translateToIOException(String file, String other) {
> ??
>         if (errno() == UnixConstants.ENOENT)
>             return new NoSuchFileException(file, other, null);
> ??

> The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage.

`UnixFileSystemProvider` is what I think ought to be used instead.

> In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong.

Please see [2. Socialize your change](https://openjdk.org/guide/#socialize-your-change).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1759138049

From dfuchs at openjdk.org  Fri Sep 13 16:34:08 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:34:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
Message-ID: <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF6285gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>

On Fri, 13 Sep 2024 16:12:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes, there was an `UnsatisfiedLinkError` in the native method `isTrustedSiteAvailable()` in `NTLMAuthentication`.
>
>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
> 
> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.

Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759158214

From naoto at openjdk.org  Fri Sep 13 16:34:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Sep 2024 16:34:09 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <rSsMDE9m1Ah9bl8u0ODoBDW60nMctazrfTFQRTjFnDQ=.18ed13e6-80e7-45db-9b0f-3f1fa4199f9b@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <kB-VZf1Utvcw8idcMTCqRjxS_E9upkH7stjwJlpEeV8=.21577be3-bcbb-4218-b804-d42c8f7bfcdb@github.com>
 <rSsMDE9m1Ah9bl8u0ODoBDW60nMctazrfTFQRTjFnDQ=.18ed13e6-80e7-45db-9b0f-3f1fa4199f9b@github.com>
Message-ID: <BanJtl50aTVorLvaYNL8mOgxELAvAe3B4qT8cM2uRGg=.54bce470-e836-4a38-80d5-604fe3e0f90e@github.com>

On Fri, 13 Sep 2024 03:12:39 GMT, Jason Mehrens <duke at openjdk.org> wrote:

>> I looked at this issue a bit more. Looking at the IANA Charset registry (https://www.iana.org/assignments/character-sets/character-sets.xhtml) which `Charset` class is based on, `ISO-8859-8-I` is not an alias to `ISO-8859-8`, but it is defined as a distinct `Preferred MIME name`. So I don't think current proposed solution is correct. (It would return ISO-8859-8-I as an alias to ISO-8859-8). Also, looking at the RFC-1556, in which this ISO-8859-8-I encoding is defined, there are other encodings, i.e., ISO-8859-6-I, ISO-8859-6-E, and ISO-8859-8-E. Why are they not relevant, but ISO-8859-8-I is?
>> Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018), unless Arabic/Hebrew speaking communities jumped in and provide rationale to support them.
>
> @naotoj does the mapping need to be removed from:
> 
> https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770
> 
> I ask because JakartaMail /Angus Mail is a similar usecase to this code.

@jmehrens I would like to, but I don't know the possible issues that would be caused by the removal. So my take is no.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2349349814

From bpb at openjdk.org  Fri Sep 13 16:38:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 16:38:09 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF6285gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
Message-ID: <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>

On Fri, 13 Sep 2024 16:31:36 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> [...] I'd expect that libnet would have been loaded before we reach NTLMAuthentication.
>> 
>> In the (as of now) penultimate webrev 4f47d5a (Merge), `WindowsNativeDispatcher` loaded it during boot phase 2. I think that without these changes it is likely loaded by `IOUtil`.
>
> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.

I would have to check. The failure I observed occurred in both of these tests

test/jdk/sun/net/www/protocol/http/NoNTLM.java
test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java

and nowhere else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759166801

From darcy at openjdk.org  Fri Sep 13 16:38:10 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 16:38:10 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
 <INZLdglPcgv_9mhynW3tJ8Sj94u8ooXisgSNhjH7PCI=.6f9bfa0d-af66-4fed-94d1-3bbe04ec0d87@github.com>
 <k0_4bgwbhHAmOFyF128khqv5zgWdtcBdPrAQ7gYKfuw=.34dff2db-b46c-4b14-9d52-60707a014ba1@github.com>
Message-ID: <Np2yuYhE4jr_QNisqtxC3fG6UPpCMu_a_N3MXAY18RQ=.65f78625-2365-4f7d-8d9a-b15f6a24d310@github.com>

On Fri, 13 Sep 2024 13:13:58 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> > This patch only captures one-line returns without extra sentences. Is it possible for us to handle slightly more complex documentations like `ParameterizedType::getActualTypeArguments`?
> 
> Sure, it is possible. However, there's a tradeoff between comprehensiveness and the effort required. Joe's script provides a lot for a little.
> 
> If there's interest in it, we could file follow-up bugs to fix more cases with more powerful tools.

Yes, the quick and dirty program is only a "minimum viable product" level of functionality. It is not complete and doesn't catch all cases. Future improvements welcome!

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

PR Comment: https://git.openjdk.org/jdk/pull/20981#issuecomment-2349358796

From naoto at openjdk.org  Fri Sep 13 16:38:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 13 Sep 2024 16:38:09 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <0fjq3uhnar6RlEAQ2heD004puGip3pLT9_0_t2Pb2hY=.c53994c7-c392-432b-8352-b9c808622d13@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

`java.nio.charset` and `java.time.format` changes look good

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303567979

From dfuchs at openjdk.org  Fri Sep 13 16:48:12 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 13 Sep 2024 16:48:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
 <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
Message-ID: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>

On Fri, 13 Sep 2024 16:35:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Do we know what code loaded NTLMAuthentication? I'd expect it to be loaded by HttpURLConnection, which should have triggered the loading of libnet long before it cares about NTLM.
>
> I would have to check. The failure I observed occurred in both of these tests
> 
> test/jdk/sun/net/www/protocol/http/NoNTLM.java
> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
> 
> and nowhere else.

I see. The test does:

            Class<?> ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader());

so that explains it.

In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly.

What you have is good to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759183851

From liach at openjdk.org  Fri Sep 13 16:52:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 13 Sep 2024 16:52:08 GMT
Subject: RFR: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <3pXE4pv6hyvGSEe1JBp2R6CchhZvSKzjKol3UVdPkRI=.983e0a29-3ac0-4682-a4a5-e5fb17a0ed85@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

Looks good. It might be feasible to run a more complex tool that analyzes the tokenized javadoc AST from javac as later work.

Annotation changes look good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20981#pullrequestreview-2303605703

From darcy at openjdk.org  Fri Sep 13 16:52:09 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 13 Sep 2024 16:52:09 GMT
Subject: Integrated: 8340082: Use inline return tag in java.base
In-Reply-To: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
References: <rxWa8pIi5QSJ8mh8QgaeBCQqrasvs9Gsp5uGXztdPUs=.4e8929bd-492d-4e12-9726-7dd9026a411a@github.com>
Message-ID: <J8BfJJeKKhzF2epyfIx0mPVlrNhMBe9dtJvRcfgHbjo=.5796e5bd-88db-4421-b542-8a251394c8cf@github.com>

On Fri, 13 Sep 2024 02:47:18 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Candidates for this refactoring were found programmatically; the program to find candidates is in a comment on the bug.

This pull request has now been integrated.

Changeset: 89c172ac
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/89c172ac47a9cc238739338417015bf912ad5424
Stats:     59 lines in 21 files changed: 0 ins; 27 del; 32 mod

8340082: Use inline return tag in java.base

Reviewed-by: iris, prappo, lancea, djelinski, naoto, liach

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

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

From bpb at openjdk.org  Fri Sep 13 17:06:08 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 17:06:08 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <oYayPqn75hzsHDUfHzbzJQfBBUI3nI2FgMg_SrNdavQ=.2e02fad9-ca30-42d9-8a99-e26a5ee85e72@github.com>
 <1qlHj2opY99rrQbUoBQwEFwgju_i6V5iOJMaBOLjnHM=.4da74113-6589-4063-ab22-efc39cae3c67@github.com>
 <4qpX4hNz_hDrbhDj1Yp7urYeIEYhNVMwjrCBoUH-wx4=.77ff50dc-c50a-4489-9e3d-924a1c9be26a@github.com>
 <qIvYtUn5vrL_6Px7_TgNJKDv9oxC7OINvLmw5ixLADo=.2799afb5-cf25-4498-adc6-fdaeb8a1a157@github.com>
 <L2ikc9wRdxsXmVnLD_HBNraQDBdDKc9Bw-zq_BFpkZ8=.cbab5c34-ae84-4a20-8fb9-593f095c0880@github.com>
 <wji6sOErBz7lDoZuI6piW9M1ztRNIY58fZfD1FjL1pE=.78104530-f948-4ab8-8d14-bdc1262c7924@github.com>
 <uVIus4ebYt_R5X7O6Z1_BaEpr8v8EltGXI9IAEOV5fI=.a06293df-e99f-47ec-ae91-7b5af0b8d556@github.com>
 <JkyKX8xUd8muPY8nLNRDSaoCRmGhy68pPZ1FyeeuVRo=.883db85d-d706-4f43-8d6a-b6e7ae1f0cd1@github.com>
 <CfrEmtI1om5yWTOnMRJW_tXTT8u6kCyF628
 5gGOWtLc=.dd57a4fd-931c-446d-8eff-41f940b7aa84@github.com>
 <EKx5HjBgAhYsg3i5gWsKjbV_voZKlhzPHeXhpW0ZvMA=.c7ecff9a-c843-49c7-b397-4d2da175ca59@github.com>
 <3NTgeF40oZXDw3L0o3TimCX-1NOs7YrGwaXgTVWWtzk=.0deb385e-57b7-4d73-b354-18622c5c7153@github.com>
Message-ID: <0IMOcZubegYzX-gY4eVUoKl6dSj4FUUkLVO6zYwhTxU=.e0d23617-85fb-4075-be9a-b245205497df@github.com>

On Fri, 13 Sep 2024 16:45:22 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I would have to check. The failure I observed occurred in both of these tests
>> 
>> test/jdk/sun/net/www/protocol/http/NoNTLM.java
>> test/jdk/sun/net/www/protocol/http/TestTransparentNTLM.java
>> 
>> and nowhere else.
>
> I see. The test does:
> 
>             Class<?> ntlmProxyClass = Class.forName("sun.net.www.protocol.http.NTLMAuthenticationProxy", true, NoNTLM.class.getClassLoader());
> 
> so that explains it.
> 
> In this case I believe it's fair enough to have NTLMAuthentication trigger the loading of libnet if not loaded already -since we need that library to perform the class initialization properly.
> 
> What you have is good to me.

Good! Thanks for the assistance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759204325

From ihse at openjdk.org  Fri Sep 13 19:33:18 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 13 Sep 2024 19:33:18 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
Message-ID: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>

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

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Clean up to address reviewer comments

make/modules/java.base/lib/CoreLibraries.gmk line 68:

> 66:     JDK_LIBS := libjvm, \
> 67:     LIBS_linux := $(LIBDL) -lpthread, \
> 68:     LIBS_aix := $(LIBDL) $(LIBM),\

Suggestion:

    LIBS_aix := $(LIBDL) $(LIBM), \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759390367

From bpb at openjdk.org  Fri Sep 13 19:42:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 19:42:27 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v6]
In-Reply-To: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
Message-ID: <YCglrL5cQU5DDgQt3AaBeCLybz1BLpGlZ_z00yNyxTs=.f3ca725d-1663-4a0c-a048-61c107912efa@github.com>

> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.

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

 - 8315273: Revert source changes; update test to match reality; correct a small type in Files
 - Merge
 - 8315273: Re-remove ToRealPath test
 - Merge
 - 8315273: Revert ProblemList
 - Merge
 - Merge
 - 8315273: Add bug ID to test
 - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

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

Changes: https://git.openjdk.org/jdk/pull/15525/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15525&range=05
  Stats: 26 lines in 3 files changed: 20 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/15525.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15525/head:pull/15525

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

From bpb at openjdk.org  Fri Sep 13 20:41:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 20:41:27 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

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

  8337143: Minor makefile tweak

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/853d3491..b54b1683

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

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

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

From bpb at openjdk.org  Fri Sep 13 20:41:28 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 13 Sep 2024 20:41:28 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v7]
In-Reply-To: <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1UT8TbjP6frWkE-NRX1jv14uRfOy2RtrBHufgh6TCfg=.b2711a71-7935-46a9-8f39-b22ce95ef901@github.com>
 <8KsTZE9DSPce8kHFMlIT3nn2F63ERL_h7AUI6NShUHc=.a5f20097-fdd3-4f98-9c01-3effc9c34b9f@github.com>
Message-ID: <8y7e4b_Phw8ehQRM0kbQom0w3WD91u7B5ujYIiGl6P4=.eab2e1ad-3a81-4c7e-8e14-cc6b51a377d0@github.com>

On Fri, 13 Sep 2024 19:30:42 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337143: Clean up to address reviewer comments
>
> make/modules/java.base/lib/CoreLibraries.gmk line 68:
> 
>> 66:     JDK_LIBS := libjvm, \
>> 67:     LIBS_linux := $(LIBDL) -lpthread, \
>> 68:     LIBS_aix := $(LIBDL) $(LIBM),\
> 
> Suggestion:
> 
>     LIBS_aix := $(LIBDL) $(LIBM), \

So changed in b54b168.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1759474420

From duke at openjdk.org  Fri Sep 13 23:55:08 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Fri, 13 Sep 2024 23:55:08 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <BanJtl50aTVorLvaYNL8mOgxELAvAe3B4qT8cM2uRGg=.54bce470-e836-4a38-80d5-604fe3e0f90e@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <kB-VZf1Utvcw8idcMTCqRjxS_E9upkH7stjwJlpEeV8=.21577be3-bcbb-4218-b804-d42c8f7bfcdb@github.com>
 <rSsMDE9m1Ah9bl8u0ODoBDW60nMctazrfTFQRTjFnDQ=.18ed13e6-80e7-45db-9b0f-3f1fa4199f9b@github.com>
 <BanJtl50aTVorLvaYNL8mOgxELAvAe3B4qT8cM2uRGg=.54bce470-e836-4a38-80d5-604fe3e0f90e@github.com>
Message-ID: <jDqeXqg0TrumY6Zmf2o-1Rx10QhrI5aAmcC5U6C5RQk=.bcd7980f-972c-4ede-95ed-1102c5ba3faf@github.com>

On Fri, 13 Sep 2024 16:31:21 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> @naotoj does the mapping need to be removed from:
>> 
>> https://github.com/openjdk/jdk/blob/5e5942a282e14846404b68c65d43594d6b9226d9/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770
>> 
>> I ask because JakartaMail /Angus Mail is a similar usecase to this code.
>
> @jmehrens I would like to, but I don't know the possible issues that would be caused by the removal. So my take is no.

@naotoj Makes sense. I did find a few links:

https://blog.netbsd.org/tnf/entry/handling_non_utf_8_hebrew

https://support.oracle.com/knowledge/Oracle%20Cloud/2991085_1.html

Any advice on adding the alias to JakartaMail?  I see web search results of libraries using what is done in xerces so I'm trying to balance your advice with that.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2350716557

From syan at openjdk.org  Sat Sep 14 01:47:10 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 14 Sep 2024 01:47:10 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v17]
In-Reply-To: <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <TKh0Y8MvWXfIBLFaqrY-ClMAvqT8-WZ7qxZ9Q-_3aUE=.3a56fca3-6ccc-4207-b627-33140d0a39d3@github.com>
Message-ID: <nh2VQVvd7aTfdfvQFeB5Bse1BKRSc7Wdc88rluZ6LyE=.34c7d011-6a8b-499c-97d7-addb4c405a46@github.com>

On Mon, 9 Sep 2024 12:42:23 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi all,
>> On alinux3(alibaba cloud linux version 3) system, the `/tmp` disk partition is mounted as tmpfs filesystem type, this filesystem type doesn't support create time(birth time).
>> 
>> Before this PR, this test [check](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L110) if there is `statx` system call present or not to determise the test environment support birth time or not. I think it's not enough when the tested filesystem type is `tmpfs`. When the tested filesystem type is `tmpfs`, then the tested file doesn't support birth time.
>> 
>> On RHEL 8 tmpfs doesn't seem to support birth time, but on F39 tmpfs does seem to support birth time. Looks like this might be related to the kernel version. It's difficult to enumerate all the combination of file system type and linux kernel version to determine the testd file support birth time or not. So in this PR, I get the result from `statx` linux syscall, to determine the testd file support birth time or not.
>> 
>> Test fix only, the change has been verified, risk is low.
>> 
>> Additional test:
>> 
>> - [x] Alinux3 glibc:2.32
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == true
>> - [x] CentOS7 docker container glibc:2.17
>> 1.  /tmp/file supportsCreationTimeRead == false
>> 2. ./file supportsCreationTimeRead == false
>
> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   initail struct stx var to zero

> > > For whatever it shows, the test passed on Linux, macOS, and Windows in our CI.
> @jerboaa The latest version in this PR.

Thanks for the test.

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

PR Comment: https://git.openjdk.org/jdk/pull/20687#issuecomment-2350773023

From djelinski at openjdk.org  Mon Sep 16 09:48:10 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Mon, 16 Sep 2024 09:48:10 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v6]
In-Reply-To: <YCglrL5cQU5DDgQt3AaBeCLybz1BLpGlZ_z00yNyxTs=.f3ca725d-1663-4a0c-a048-61c107912efa@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <YCglrL5cQU5DDgQt3AaBeCLybz1BLpGlZ_z00yNyxTs=.f3ca725d-1663-4a0c-a048-61c107912efa@github.com>
Message-ID: <e9qBWYZgbzPC7AeTVo8WgCqLzyhBSG72WZ-NddCKxdE=.44cd67e6-2c30-4a1c-933d-eb884e034cb9@github.com>

On Fri, 13 Sep 2024 19:42:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - 8315273: Revert source changes; update test to match reality; correct a small type in Files
>  - Merge
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/15525#pullrequestreview-2306177970

From duke at openjdk.org  Mon Sep 16 10:22:05 2024
From: duke at openjdk.org (Kasper Nielsen)
Date: Mon, 16 Sep 2024 10:22:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
Message-ID: <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>

On Fri, 13 Sep 2024 07:50:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |             10255 |           10154 |
>> | AtomicBoolean.class                   |              5364 |             5161 |
>> |AtomicMarkableReference.class |              3890 |            3687 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 2012 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |        5963657 |
>> | Patch                |        5962751 |
>> | Delta                 |                906|
>> 
>> For 60 billion instances, this represents 54 TB.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename and reformat

This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2352521927

From ihse at openjdk.org  Mon Sep 16 10:22:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 16 Sep 2024 10:22:11 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <ysPh_tERSmx4F3ZI7mBwohjrHZe9QMUIlU5SNzAtcII=.dec773cc-5b3c-4670-b31b-d86397d7fa71@github.com>

On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

Make changes look fine now.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2306245227

From pminborg at openjdk.org  Mon Sep 16 12:01:26 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 16 Sep 2024 12:01:26 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.

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

 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - Introduce MethodHandlesInternal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/1dee24ab..e2e935b2

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

  Stats: 9768 lines in 215 files changed: 6742 ins; 1600 del; 1426 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

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

From naoto at openjdk.org  Mon Sep 16 17:43:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 16 Sep 2024 17:43:08 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>

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

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

Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2353528689

From duke at openjdk.org  Mon Sep 16 22:03:09 2024
From: duke at openjdk.org (duke)
Date: Mon, 16 Sep 2024 22:03:09 GMT
Subject: Withdrawn: 8316882: Do not close ZipFileSystem on interrupt
In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
Message-ID: <HUXhgZooeUMq0K_CCp-U9vdqXNLzEUYtLxCi6g-oxg4=.25d5bbb8-e4d3-4eb0-aab4-21f136a74cb6@github.com>

On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n <duke at openjdk.org> wrote:

> Hi,
> 
> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example.
> 
> There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2]
> 
> [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
> [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Mon Sep 16 23:52:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 16 Sep 2024 23:52:13 GMT
Subject: RFR: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win) [v6]
In-Reply-To: <YCglrL5cQU5DDgQt3AaBeCLybz1BLpGlZ_z00yNyxTs=.f3ca725d-1663-4a0c-a048-61c107912efa@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
 <YCglrL5cQU5DDgQt3AaBeCLybz1BLpGlZ_z00yNyxTs=.f3ca725d-1663-4a0c-a048-61c107912efa@github.com>
Message-ID: <ESNkCEqYfX-mkx52Usa034vuY5wD3ObRxfwaPCiorQY=.2e97958b-3ca3-4c84-ac6d-ea5f190f5074@github.com>

On Fri, 13 Sep 2024 19:42:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
> 
>  - 8315273: Revert source changes; update test to match reality; correct a small type in Files
>  - Merge
>  - 8315273: Re-remove ToRealPath test
>  - Merge
>  - 8315273: Revert ProblemList
>  - Merge
>  - Merge
>  - 8315273: Add bug ID to test
>  - 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

In `C:\Users\bpb\dev\bugs`, create `dir`, `dir\subdir`, and `link -> dir\subdir`. Then running a simple native test using `CreateFileW` to create a new file `C:\Users\bpb\dev\bugs\link..\file.txt` actually creates `C:\Users\bpb\dev\bugs\file.txt`, which corroborates the conclusion of this PR. The initial version of this PR incorrectly expected that `file.txt` would be `C:\Users\bpb\dev\bugs\dir\file.txt`.

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

PR Comment: https://git.openjdk.org/jdk/pull/15525#issuecomment-2354225541

From duke at openjdk.org  Tue Sep 17 03:04:11 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Tue, 17 Sep 2024 03:04:11 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <NjYwgWL3nKIFyybwng5_z518-6yW9aaF59pCMb3VsOc=.ff28e725-d2d7-4962-b232-53f72a8cf9bb@github.com>
Message-ID: <mrfY3iHJSEM-vyK7O5b73Jijz6qyNZG5ibJ9LfNpqlQ=.87223b7a-30b8-4c60-9d81-6d160be86c35@github.com>

On Mon, 16 Sep 2024 17:40:38 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Mapping ISO-8859-8-I charset to ISO-8859-8.
>> Below mentioned 2 aliases are added as part of this:-
>> **ISO-8859-8-I**
>> **ISO8859-8-I**
>> 
>> The bug report for the same:- https://bugs.openjdk.org/browse/JDK-8195686
>
> Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

@naotoj 

>Sorry, but I cannot speak for Jakarta Mail. If they see ISO-8859-8-I encoding important, they may introduce it as a new charset (again it is not an alias to ISO-8859-8)

Understood.  I'll close out those tickets then with alternatives.

>...Considering these, I am still not sure to introduce these new encodings now, also because there has not been any request from the time Bill Shannon worked (circa 2018)

Well that is not exactly true.  The following are all the same ticket from 2018 as a request from JavaMail/JakartaMail:

- https://bugs.openjdk.org/browse/JDK-8195686 (Ticket created by JavaMail user against OpenJDK by @jmiserez)
- https://github.com/jakartaee/mail-api/issues/302 (migrated ticket from JavaMail to JakartaMail)
- https://github.com/javaee/javamail/issues/302  (referenced in JDK-8195686 by @jmiserez)

The OpenJDK ticket JDK-8195686 has not had a proper evaluation since 2018.  However, looks like this PR has that covered and I'm grateful for that.

Then in May of 2024 the following was created:

https://github.com/eclipse-ee4j/angus-mail/issues/147 by @davecrighton on the Angus Mail project.  Then in June @psawant19 commented on that ticket and later created this PR in OpenJDK.  So 3 unique users and all related to JavaMail/JakartaMail/Angus Mail on this very topic.

It seems pretty clear that we would have to contribute the new Charset implementation to move this forward.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2354412752

From duke at openjdk.org  Tue Sep 17 05:34:05 2024
From: duke at openjdk.org (Jeremie Miserez)
Date: Tue, 17 Sep 2024 05:34:05 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <vxDJ6YWYmBNshPxt00aSy_y8vTl4fzTu9U2OmsYQAQs=.9ade3e74-73a0-4746-a466-2b150a9f8f6d@github.com>

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

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

As the original bug submitter I might add that adding a mapping from ISO-8859-8-i to ISO-8859-8 is almost certainly correct and makes sense in the real world.

The character encodings for ISO-8859-8 and ISO-8859-8-i charsets are exactly the same, and the distinction is only due to historical reasons.

Email clients in the past did not "know about" right-to-left languages, instead the text was sent as regular ISO-8859-8 mail but sent line-by-line but with each line reversed. The reversed lines are displayed LTR (left-to-right) as-is. This is what's known as "visual ordering", and is required for old email clients.

Newer email clients can do right-to-left, i.e. their text display engines started to support RTL display. So it was no longer necessary to send emails in "visual order" with reversed lines. But now there's a problem: how does the email client know whether the text is in "visual order" (displayed as-is LTR) or in "logical order" (displayed as RTL text).

Thus ISO-8859-8-i was introduced. The charset decoding is exactly the same as ISO-8859-8, the only difference is in instructing the email client to display the lines not as-is LTR, but RTL.

Old email clients cannot show these mails, as they do not know about ISO-8859-8-i and do not support RTL display anyways.

The only drawback to adding the alias from ISO-8859-8-i to ISO-8859-8 is if you have a very old application (email client) that cannot do RTL display but used the newest JDK. Instead of showing an "unsupported charset" error it would then show the email but as LTR with each line reversed. I think that would be acceptable for almost everyone.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2354559575

From djelinski at openjdk.org  Tue Sep 17 06:09:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Tue, 17 Sep 2024 06:09:07 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <MXCMOQcjdczxKA4rLdbgdCojzfrJ08vAA4Pze4xOfWs=.dae3de6d-cba0-4568-99df-02faeed74a47@github.com>

On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2308420140

From pminborg at openjdk.org  Tue Sep 17 07:27:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 07:27:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
Message-ID: <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>

On Mon, 16 Sep 2024 10:19:26 GMT, Kasper Nielsen <duke at openjdk.org> wrote:

> This would actually be super useful in a public API. I use the same "trick" in some of my projects. Not because I care too much about the classfile size. But it is just a lot easier on the eye.

While I understand it would be convenient, there is a reason we have checked exceptions in the public APIs. Users can create similar utility methods in their projects if they want to "hide" the exceptions as you say. If you wish to add public methods anyhow, I think we should consider this under a separate issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2354746829

From liach at openjdk.org  Tue Sep 17 12:20:10 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 12:20:10 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
Message-ID: <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>

On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

I think the original poster means to find a VH in the lookup class.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355564774

From duke at openjdk.org  Tue Sep 17 12:37:05 2024
From: duke at openjdk.org (Kasper Nielsen)
Date: Tue, 17 Sep 2024 12:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
 <a0b51xPBrzb9yp-MkatoyNF4k6IgPq8XSiiw7hWRMPE=.1a17ec9c-e7b6-4968-aed8-d5b5fa324e18@github.com>
Message-ID: <HKg-Ow0UJCJ_I_31yB6qRVYbZ0puyJwCJzBdBJ6BIms=.1ec9cc1a-74de-40cb-998b-8c64a648824f@github.com>

On Tue, 17 Sep 2024 12:17:06 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think the original poster means to find a VH in the lookup class.

I actually meant what Per is hinting at. Defining static MethodHandle/VarHandle in a class at class initialization time, without the ceremony of handling ReflectiveOperationException and throwing ExceptionInInitializerError. 

I could be mistaken but I think this is probably how most MethodHandle/VarHandles are defined.
But I understand reason not to add these methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355614436

From alanb at openjdk.org  Tue Sep 17 12:37:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 17 Sep 2024 12:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
 <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
Message-ID: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>

On Tue, 17 Sep 2024 07:24:29 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>  If you wish to add public methods anyhow, I think we should consider this under a separate issue.

I think it's a request for 10+ find methods to sit along the existing methods so it might be confusing too.

I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355617297

From pminborg at openjdk.org  Tue Sep 17 12:59:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 12:59:13 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v3]
In-Reply-To: <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <Fm0giu7zM549Z9x6jnnCNF4lMUbY8qjrj88darbdadk=.515d9b47-89ad-4177-9781-80bc56d118af@github.com>
Message-ID: <Jg6ji-eSBCMgCv8d5AbCmrTMX1BDtnoSeMWql_nWFgk=.1e617f45-595e-415a-be77-6b43dd540ead@github.com>

On Mon, 16 Sep 2024 12:01:26 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

It is possible to create a project-specific utility method that can unwrap several methods like this:


    @FunctionalInterface
    public interface LookupFunction<R> {
        R apply(MethodHandles.Lookup lookup,
                Class<?> refc,
                String name,
                MethodType type) throws NoSuchMethodException, IllegalAccessException;
    }

    public static <R> R unwrap(LookupFunction<R> lookupFunction,
                               MethodHandles.Lookup lookup,
                               Class<?> refc,
                               String name,
                               MethodType type) {
        try {
            return lookupFunction.apply(lookup, refc, name, type);
        } catch (ReflectiveOperationException e) {
            throw new InternalError(e);
        }
    }

    static final MethodHandle MH_SCALE = MethodHandlesUtil.unwrap(MethodHandles.Lookup::findVirtual,
            MethodHandles.lookup(), MemoryLayout.class, "scale", MethodType.methodType(long.class, long.class, long.class));

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355690263

From pminborg at openjdk.org  Tue Sep 17 13:05:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 13:05:24 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

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

 - Update javadoc
 - Rename utility class

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/e2e935b2..7f140322

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

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

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

From eirbjo at openjdk.org  Tue Sep 17 13:37:05 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 17 Sep 2024 13:37:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v2]
In-Reply-To: <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <uyBeVgNiNIXmrVg2PWjj7n0-R97yFf-TBZpd-6JPTSg=.b9cc62d5-6e65-44b6-95e9-6f8b6cb48005@github.com>
 <s351oPnExRmqrFwXL9nV0JJMNtBf3hmttGCX-kTtLuw=.80ea08a5-a015-46eb-857e-1d370a2e3508@github.com>
 <YFAaoLwMRZmgaej35BWeDQqzj3ZagxNol7UVwUeejcc=.acdb9d02-390e-40fb-ad13-c86c4ab231ff@github.com>
 <01ag0stjBVkfVciVp6EmsaprHkV2hyC67r1o5u6XHIY=.c519c314-5dd6-4768-9881-c2af7413abfc@github.com>
Message-ID: <idoSt8VsBJ1PYIoiy0zHD89E2OOTDfRPRI8pyKaFIM8=.2e4307e5-8bd0-416a-a1f6-2b79998ffad7@github.com>

On Tue, 17 Sep 2024 12:33:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think your proposal looks generally okay, not sure about naming it "MethodHandlesInternal" with "internal" in the package name as it's more like a class of utility methods.

Perhaps `MethodHandlesSupport`, like `jdk.internal.util.ArraysSupport`?

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355825352

From liach at openjdk.org  Tue Sep 17 13:40:07 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 17 Sep 2024 13:40:07 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
Message-ID: <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>

On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update javadoc
>  - Rename utility class

I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2355833854

From rriggs at openjdk.org  Tue Sep 17 14:07:05 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 17 Sep 2024 14:07:05 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
Message-ID: <3-8Pao_PVgev-cXH5tS4knP3CGHAgYbBsFf3hNc5ttY=.32535d56-044d-481d-8342-c44ed0811b91@github.com>

On Tue, 17 Sep 2024 13:05:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Update javadoc
>  - Rename utility class

Overall looks good. Having a concise source construct representing these factories will enable jlink or similar pre-processing steps to optimize.

The new class will be lonesome in its own package.
I'd shorten the classname to "MHUtil" making the source lines more readable.

src/java.base/share/classes/jdk/internal/invoke/MethodHandlesUtil.java line 35:

> 33: /**
> 34:  * This class contains a number of static factories for certain
> 35:  * VarHandle/MethodHandle variants.

I'd write this as a more concise 1st line comment.  "This class contains a number of" is noise.
"Utility static factories of method handles for fields and methods."
or similar.

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

PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2309856171
PR Review Comment: https://git.openjdk.org/jdk/pull/20972#discussion_r1763305393

From pminborg at openjdk.org  Tue Sep 17 14:25:42 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 17 Sep 2024 14:25:42 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v5]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

Per Minborg 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 nine additional commits since the last revision:

 - Merge branch 'master' into internal-mh-util
 - Rename class and shorten JavaDoc
 - Update javadoc
 - Rename utility class
 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - Introduce MethodHandlesInternal

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/7f140322..a1444c28

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

  Stats: 121988 lines in 261 files changed: 121641 ins; 172 del; 175 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

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

From duke at openjdk.org  Tue Sep 17 15:10:07 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 17 Sep 2024 15:10:07 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v4]
In-Reply-To: <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <GBybsIFsnt_bNgTbDR8JEwXp8Zrt47IZtnwx81Q3KC8=.a06612bc-8ae1-40ff-9424-6a0d483e6fbb@github.com>
 <eLXp4P8opgrW7KQCOT3hHpeQlfE7qbI9Y_iXhhdyD5c=.2b7585df-769d-4884-a232-f28959da4bb8@github.com>
Message-ID: <7988GQeBo-xYw7i-H9i6fTkQein298GVmZPJSgt1BIw=.773c89ab-ea3a-4c8c-9ae4-7817fb5bf744@github.com>

On Tue, 17 Sep 2024 13:37:19 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Update javadoc
>>  - Rename utility class
>
> I think a better approach to this problem might be converting these static final MethodHandle/VarHandle to class-file constants (Constant_MethodHandle for MH, Constant_Dynamic for VH), see JEP 303.

In my projects I usually just use the `ConstantBootstraps` method directly, which avoids the try/catch (but does not avoid needing a lookup). In my mind I imagine eventually writing a tool which post-processes my classes and replaces all `private static final Xxx xxx = ConstantBootstraps.xxx()` with dynamic constants (similarly, I guess, to what @liach suggested). But maybe just using the existing `ConstantBootstraps` methods is a good stepping stone towards a JEP-303 kind of solution.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2356168738

From bpb at openjdk.org  Tue Sep 17 15:53:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Sep 2024 15:53:14 GMT
Subject: Integrated: 8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS)
 fails when "../../" follows a link (win)
In-Reply-To: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
References: <9TrqNiqFM-WUzVO2G_pQVtAeI06TwRt1dR1cO2zNemk=.580d210b-e5a2-4b5d-956f-ca5d286844e1@github.com>
Message-ID: <gTJCIEfHcWBBgNxfV2H_wobWO8VPZByAHaSu7azo0qs=.89dc381e-6941-4c6f-ba6c-5a35ab3a7c7b@github.com>

On Thu, 31 Aug 2023 22:45:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Windows implementation of integrated pull request #15397. The test java/nio/file/Path/ToRealPath.java is also removed from the problem list.

This pull request has now been integrated.

Changeset: f8770163
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f87701635f82895fc10586e588f25e9c508e6979
Stats:     26 lines in 3 files changed: 20 ins; 2 del; 4 mod

8315273: (fs) Path.toRealPath(LinkOption.NOFOLLOW_LINKS) fails when "../../" follows a link (win)

Reviewed-by: djelinski

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

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

From jlu at openjdk.org  Tue Sep 17 23:20:35 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 17 Sep 2024 23:20:35 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security APIs
Message-ID: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>

Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.

Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
This change does not include removal of usages in a historical sense. For example, something such as 


 * @apiNote
 * Thread groups provided a way in early Java releases to group threads and provide
 * a form of <i>job control</i> for threads. Thread groups supported the isolation
 * of applets and defined methods intended for diagnostic purposes. It should be
 * rare for new applications to create ThreadGroups and interact with this API.


in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

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

Commit messages:
 - init

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

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

From bpb at openjdk.org  Tue Sep 17 23:42:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Sep 2024 23:42:31 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win)
Message-ID: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>

Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.

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

Commit messages:
 - 8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win)

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

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

From naoto at openjdk.org  Tue Sep 17 23:50:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 17 Sep 2024 23:50:06 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:

> 72: <code>volatile</code> (or access to the variable must be
> 73: synchronized).</p>
> 74: <p>For example, suppose your application contains the following

The example below is still applet specific (e.g., `repaint()`). May need to be more generic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764214361

From bpb at openjdk.org  Tue Sep 17 23:55:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 17 Sep 2024 23:55:04 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win)
In-Reply-To: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
Message-ID: <THBG-f8JbMEnhl16yyAnQm6C_N6nhgkNgmbYVWMXhZk=.73972253-253b-474e-8fdb-6f0299d7a4f5@github.com>

On Tue, 17 Sep 2024 23:37:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.

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

> 306:                 String filename = null;
> 307:                 try {
> 308:                     filename = GetFinalPathNameByHandle(handle);

One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form.

test/jdk/java/nio/file/Files/Links.java line 135:

> 133:         }
> 134: 
> 135:         // Check message of NotLinkException

It might be that checking the message for just one single non-link, instead of both a file and a directory, is sufficient.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764221658
PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764222496

From alanb at openjdk.org  Wed Sep 18 06:20:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 06:20:05 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win)
In-Reply-To: <THBG-f8JbMEnhl16yyAnQm6C_N6nhgkNgmbYVWMXhZk=.73972253-253b-474e-8fdb-6f0299d7a4f5@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
 <THBG-f8JbMEnhl16yyAnQm6C_N6nhgkNgmbYVWMXhZk=.73972253-253b-474e-8fdb-6f0299d7a4f5@github.com>
Message-ID: <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com>

On Tue, 17 Sep 2024 23:50:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.
>
> src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 308:
> 
>> 306:                 String filename = null;
>> 307:                 try {
>> 308:                     filename = GetFinalPathNameByHandle(handle);
> 
> One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form.

I think you just need to use the path that is passed to the readLink method, just pass it readLinkImpl.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1764461660

From coffeys at openjdk.org  Wed Sep 18 06:28:05 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Sep 2024 06:28:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
Message-ID: <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>

On Tue, 17 Sep 2024 23:36:16 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:
> 
>> 72: <code>volatile</code> (or access to the variable must be
>> 73: synchronized).</p>
>> 74: <p>For example, suppose your application contains the following
> 
> The example below is still applet specific (e.g., `repaint()`). May need to be more generic.

`repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.

given the thread name `blink`, perhaps we could just use `blink()` in this example.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764469513

From alanb at openjdk.org  Wed Sep 18 06:56:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 06:56:06 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
 <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
Message-ID: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>

On Wed, 18 Sep 2024 06:25:57 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/doc-files/threadPrimitiveDeprecation.html line 74:
>> 
>>> 72: <code>volatile</code> (or access to the variable must be
>>> 73: synchronized).</p>
>>> 74: <p>For example, suppose your application contains the following
>> 
>> The example below is still applet specific (e.g., `repaint()`). May need to be more generic.
>
> `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.
> 
> given the thread name `blink`, perhaps we could just use `blink()` in this example.

Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764497660

From alanb at openjdk.org  Wed Sep 18 06:56:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 06:56:07 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39:

> 37:  * implementation classes.  Charset providers may be installed in an instance
> 38:  * of the Java platform as extensions.  Providers may also be made available by
> 39:  * adding them to the application class path or by some other

They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1764498846

From duke at openjdk.org  Wed Sep 18 08:01:18 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Wed, 18 Sep 2024 08:01:18 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
Message-ID: <QCMAhAAHNipDVwZUmNB0N8IocJtCHISp4V3bPdr86Ow=.9c022c35-f9dd-4777-9a36-bb4fac4b199f@github.com>

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

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

Based on our analysis, we've identified that the file ?EncodingMap.java? includes an entry where "ISO-8859-8-I" is defined as an alias for "ISO8859_8." This entry is found in the headstream repository, and we believe it makes sense to include this in the charsets file as well. You can reference the relevant section here: [EncodingMap.java](https://github.com/openjdk/jdk/blob/5381f553ad61ddaa44d49c3039a05511cc68bdd0/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java#L770).

Moreover, the original bug submitter has expressed agreement with our proposed solution, as noted in the discussion [here](https://github.com/openjdk/jdk/pull/20690#issuecomment-2354559575).

If we decide to create a new charset mapping for "ISO-8859-8-I," it would essentially mirror "ISO-8859-8," differing only in the naming convention. This would function similarly to creating an alias in the charsets file.

Therefore, we propose that this approach is valid and appropriate for implementation.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2357768469

From mullan at openjdk.org  Wed Sep 18 13:02:05 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 18 Sep 2024 13:02:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <SVsgyTKcBu5UFJmi2-KqNLxMMNI01ufn3wrK-v6RYv0=.9fedc211-7ecf-41b3-ac93-849461329cc1@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

src/java.base/share/classes/javax/net/SocketFactory.java line 63:

> 61:  * <P> Factory classes are specified by environment-specific configuration
> 62:  * mechanisms.  For example, the <em>getDefault</em> method could return
> 63:  * a factory that was appropriate for a particular user, and a

Suggest changing this to "particular application" instead of "particular user" as it seems a bit odd to be talking about users here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765011733

From bpb at openjdk.org  Wed Sep 18 15:54:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Sep 2024 15:54:07 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win)
In-Reply-To: <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
 <THBG-f8JbMEnhl16yyAnQm6C_N6nhgkNgmbYVWMXhZk=.73972253-253b-474e-8fdb-6f0299d7a4f5@github.com>
 <6Kw6Ru9SrYWI-LSJdF7KPFDb8FSsNIn-DZ1WJS5atI8=.bf89382e-4898-4dde-bb27-7d85a2b4a018@github.com>
Message-ID: <9tSBtQPK61nw2GgnzbzFOqpa1HOIHvvwt1EX3mwNQuU=.d25a0b61-d100-418a-a950-62482cf36de0@github.com>

On Wed, 18 Sep 2024 06:17:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/fs/WindowsLinkSupport.java line 308:
>> 
>>> 306:                 String filename = null;
>>> 307:                 try {
>>> 308:                     filename = GetFinalPathNameByHandle(handle);
>> 
>> One question is whether the string returned by `GetFinalPathNameByHandle` should be used as is, or converted to some other form.
>
> I think you just need to use the path that is passed to the readLink method, just pass it readLinkImpl.

I agree. What I did was lame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21047#discussion_r1765317556

From bpb at openjdk.org  Wed Sep 18 16:20:25 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 18 Sep 2024 16:20:25 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win) [v2]
In-Reply-To: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
Message-ID: <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com>

> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.

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

  8340329: Pass the path into readLinkImpl instead of calling GetFinalPathNameByHandle

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21047/files
  - new: https://git.openjdk.org/jdk/pull/21047/files/a1b7e2d0..a117766b

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

  Stats: 33 lines in 2 files changed: 2 ins; 23 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21047.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21047/head:pull/21047

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

From alanb at openjdk.org  Wed Sep 18 17:41:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 18 Sep 2024 17:41:04 GMT
Subject: RFR: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win) [v2]
In-Reply-To: <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
 <8PleEftjQAWyxrJ2WerTeC90aJxo5JaZc2ikkz4tFxk=.80fd0ad6-25f5-4d6b-8974-b9d8c666bfeb@github.com>
Message-ID: <dyrC1EHiqw0dmH_qgZybBCyjWbR3uT2vA7Vjruipsww=.17fffbdb-74ac-4013-91aa-552cd60c951c@github.com>

On Wed, 18 Sep 2024 16:20:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8340329: Pass the path into readLinkImpl instead of calling GetFinalPathNameByHandle

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21047#pullrequestreview-2313356574

From jlu at openjdk.org  Wed Sep 18 17:59:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:40 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

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

  reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21046/files
  - new: https://git.openjdk.org/jdk/pull/21046/files/731e4ee1..19d6b725

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

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

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

From jlu at openjdk.org  Wed Sep 18 17:59:40 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:40 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <4uL4p4Ckg28qaZoageWVexondIh3H0qj-Ja5oid94mA=.bd7dca24-28ed-4e36-b527-35c08939bb59@github.com>
 <ioWhEOOPmKwjkZdzCOi5j7eFdzt6EFzL1pk-FJUtBy0=.bc3e2a44-52bf-4ff6-814c-68e1295c306f@github.com>
 <8TE8V8dQSm8L8BRmW3hnAUmK36L_hfUZlIcglIHr9r0=.6437c81a-0b29-43d0-94ed-434c5feb730e@github.com>
Message-ID: <G8zQH_nwQnDcM9yl9hT1_qcO4jUcZ662fONQQfzPrs8=.e5f57506-7f88-4dc3-b981-995769d87e83@github.com>

On Wed, 18 Sep 2024 06:52:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `repaint()` could be substituted with another arbitrary method name to highlight some work this thread has to perform.
>> 
>> given the thread name `blink`, perhaps we could just use `blink()` in this example.
>
> Don't waste too much time on the "Java Thread Primitive Deprecation" page. The last remnant is the no-arg Thread.stop method which throws UOE unconditionally. Once that is removed then the doc-file pages will be removed too.

Kept it simple and simply replaced with Sean's suggestion of `blink()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481816

From jlu at openjdk.org  Wed Sep 18 17:59:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 18 Sep 2024 17:59:41 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <jji2cBznsQxB3R4AhXAcrpB4VjoBZM9FnHvPm1W23mI=.455655bc-617a-48c4-bb48-59c6d111d48d@github.com>
Message-ID: <DezYxErxpnSftJWX_8ZgzPEiMetyuwIsjXsst4NMiYg=.c6248404-5be4-4c0b-9793-5bce8040f93e@github.com>

On Wed, 18 Sep 2024 06:53:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reflect review comments
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 39:
> 
>> 37:  * implementation classes.  Charset providers may be installed in an instance
>> 38:  * of the Java platform as extensions.  Providers may also be made available by
>> 39:  * adding them to the application class path or by some other
> 
> They can also be deployed on the application module path, maybe need a separate JBS issue to clarify that part of the spec, and add a test.

Filed https://bugs.openjdk.org/browse/JDK-8340404 to handle this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21046#discussion_r1765481753

From coffeys at openjdk.org  Wed Sep 18 18:27:05 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 18 Sep 2024 18:27:05 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <RaZVwywXR8TW4czxCx9GxZaOBxDRpuMgcSqqhrLtqpE=.51210f45-79e3-4b28-9be8-acdeea9446cf@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by coffeys (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313447275

From naoto at openjdk.org  Wed Sep 18 19:57:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 18 Sep 2024 19:57:04 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <kGTXCt-AVa41xlO984dfN8qO-Mws1F6OVaHnbVQ73sY=.e54d9472-fd20-4d61-b3dd-8c7b583e89e1@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313649127

From iris at openjdk.org  Wed Sep 18 20:28:01 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 18 Sep 2024 20:28:01 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <HXJW7fwPt_TU0EkmwIi_336Mc-gdWZmcjhhjZ2Dr82U=.a6ae8354-a081-4669-af24-944fa009370c@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Happy to see us getting one step closer to removing Applets.

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

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313706558

From rriggs at openjdk.org  Wed Sep 18 20:48:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 18 Sep 2024 20:48:41 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <Hf2A8l2jlnSoGop98pzLuq4XVQB_bkrU0zc8kMWV354=.121d823c-a9e7-47cd-b2bd-c79586588f3e@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

LGTM

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313767821

From lancea at openjdk.org  Wed Sep 18 21:01:43 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 18 Sep 2024 21:01:43 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <rfMAUPrDYAlvr8WyIFHKjaK1TxLX96vsaT7Ui5nToxI=.8f3e36d9-996d-4f73-80f1-855fbc2b11db@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2313789102

From jlu at openjdk.org  Thu Sep 19 00:13:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 00:13:05 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application module
 path
Message-ID: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>

Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.

This came as a result from a comment on the PR of JDK-8339735. 

I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.

An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

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

Commit messages:
 - newline in module-info.java
 - init

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

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

From alanb at openjdk.org  Thu Sep 19 05:43:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Sep 2024 05:43:39 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>

On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 45:

> 43:         } else {
> 44:             bazCs = cs.get("BAZ");
> 45:             var aliases = bazCs.aliases();

I think this needs to test that bazCs.getClass().getModule() is a named module.

test/jdk/java/nio/charset/spi/provider/module-info.java line 24:

> 22:  */
> 23: module provider {
> 24:     exports spi;

It's a bit of anti pattern for service provider modules to export an API, can you drop this? I don't think it's possible to check the test setup while that is there.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766189848
PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766188958

From alanb at openjdk.org  Thu Sep 19 05:51:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 19 Sep 2024 05:51:42 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <9WJ7po2vi2C27VDTtEd4Sba-F_k9co56B6_fciZ5t7U=.0c85e8a3-5c90-4577-b95a-343514ad8269@github.com>

On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 28:

> 26:  * @bug 8340404
> 27:  * @summary Check that a CharsetProvider SPI can be deployed as a module
> 28:  * @modules provider

The `@modules` tag is used for test selection, I don't know what L28 does.

test/jdk/java/nio/charset/spi/CharsetProviderAsModuleTest.java line 29:

> 27:  * @summary Check that a CharsetProvider SPI can be deployed as a module
> 28:  * @modules provider
> 29:  * @build provider/module-info provider/spi.BazProvider

You can use `@build provider/*` here and jtreg will do the right thing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766196688
PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1766195932

From mullan at openjdk.org  Thu Sep 19 11:47:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 19 Sep 2024 11:47:37 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <Ce0xsi9ecGi48Qxcu4fWSM1vweRNQhWy9Vz00Dywql4=.3b86fe3b-e556-476d-a9e1-57a1194af17d@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21046#pullrequestreview-2315289461

From bpb at openjdk.org  Thu Sep 19 15:27:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 19 Sep 2024 15:27:40 GMT
Subject: Integrated: 8340329: (fs) Message of NotLinkException thrown by
 FIles.readSymbolicLink does not include file name (win)
In-Reply-To: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
References: <fA8MglgAzcBl3dn4sjI8o1llHXuu7mDECKaTY6Jzpj0=.3f32dc39-4713-4ea7-98f2-f2285d8bb617@github.com>
Message-ID: <PZF_Scur_kobOjHjZT0li1NCakCfbl2_GE3DLfm2mZ4=.80277a7c-1699-48fe-ab23-c650e8547c3d@github.com>

On Tue, 17 Sep 2024 23:37:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Add the file name of the Path passed to `Files.readSymbolicLink` to the message of the `NotLinkException` thrown when the path is not a reparse point which represents a symbolic link.

This pull request has now been integrated.

Changeset: 2ada313c
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ada313cdd9a20ed33f7e0a7298c8a0e69a81c6f
Stats:     34 lines in 2 files changed: 23 ins; 0 del; 11 mod

8340329: (fs) Message of NotLinkException thrown by FIles.readSymbolicLink does not include file name (win)

Reviewed-by: alanb

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

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

From jlu at openjdk.org  Thu Sep 19 16:21:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 16:21:43 GMT
Subject: RFR: 8339735: Remove references to Applet in core-libs/security
 APIs [v2]
In-Reply-To: <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
 <RZcWEssMBXCqGyE_bkOM9STabLVpVyhHZcka-IEYN1Y=.f071c3a6-926c-4317-b324-b0be0357dc18@github.com>
Message-ID: <8vbEWScGpsDLSyqFV_wVIsJOGtYFHIvXVGOqh5n0pUA=.3faedb46-eed4-43b9-8ad8-435ba8f320e2@github.com>

On Wed, 18 Sep 2024 17:59:40 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
>> 
>> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
>> This change does not include removal of usages in a historical sense. For example, something such as 
>> 
>> 
>>  * @apiNote
>>  * Thread groups provided a way in early Java releases to group threads and provide
>>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>>  * of applets and defined methods intended for diagnostic purposes. It should be
>>  * rare for new applications to create ThreadGroups and interact with this API.
>> 
>> 
>> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
>> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review comments

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21046#issuecomment-2361455381

From jlu at openjdk.org  Thu Sep 19 16:21:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 16:21:43 GMT
Subject: Integrated: 8339735: Remove references to Applet in core-libs/security
 APIs
In-Reply-To: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
References: <vQVRBAVX4AjlABQ4MUnH4GIXSYLyqUIFqFSYgZ8j4VM=.c2fbc804-3478-443c-8725-8202ee7254d4@github.com>
Message-ID: <4Jni6WhPBSkweDV1MOhkafn9oCwETZ4Ly2Z5qmr9ZB4=.5c7f9170-82a1-478f-85bb-1f6f60b945bb@github.com>

On Tue, 17 Sep 2024 23:14:16 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes occurrences of 'applet' within the corelibs specification. Applet has been deprecated since JDK9, and may be a confusing term for new Java developers, so it should be removed from the documentation.
> 
> Primarily, usages where 'applet' is used interchangeably with 'application' are removed.
> This change does not include removal of usages in a historical sense. For example, something such as 
> 
> 
>  * @apiNote
>  * Thread groups provided a way in early Java releases to group threads and provide
>  * a form of <i>job control</i> for threads. Thread groups supported the isolation
>  * of applets and defined methods intended for diagnostic purposes. It should be
>  * rare for new applications to create ThreadGroups and interact with this API.
> 
> 
> in _src/java.base/share/classes/java/lang/ThreadGroup.java_. 
> Please see the JBS issue comments for further reasoning on why other occurrences were not removed.

This pull request has now been integrated.

Changeset: 5f3e7aa8
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5f3e7aa83348edafb83480ce67d0c58c46e11b24
Stats:     19 lines in 7 files changed: 0 ins; 1 del; 18 mod

8339735: Remove references to Applet in core-libs/security APIs

Reviewed-by: coffeys, naoto, iris, rriggs, lancea, mullan

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

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

From jlu at openjdk.org  Thu Sep 19 16:55:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 16:55:49 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v2]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <cpcPn2MPWa4xVEmw2HWtrRxlrXr2k9EiaMtKMqXerzw=.2e935c30-e092-492c-ad06-3ac911e2a0f8@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

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

 - merge master, resolve conflicts
 - reflect review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21076/files
  - new: https://git.openjdk.org/jdk/pull/21076/files/a9cb9db1..6aff4f3f

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

  Stats: 1651 lines in 75 files changed: 1360 ins; 36 del; 255 mod
  Patch: https://git.openjdk.org/jdk/pull/21076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076

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

From jlu at openjdk.org  Thu Sep 19 17:03:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 17:03:02 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v3]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <Mv4iKMGm3nu49F6Fq0yI2nxzdOV5cBUEfg1u7wmSlDM=.44289311-c7d5-459e-b81b-2b3beb6458f2@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - resolve conflicts; list deployment as module first
 - merge master, resolve conflicts
 - reflect review comments
 - newline in module-info.java
 - init

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

Changes: https://git.openjdk.org/jdk/pull/21076/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21076&range=02
  Stats: 154 lines in 4 files changed: 145 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21076.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21076/head:pull/21076

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

From naoto at openjdk.org  Thu Sep 19 17:03:02 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 19 Sep 2024 17:03:02 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v3]
In-Reply-To: <Mv4iKMGm3nu49F6Fq0yI2nxzdOV5cBUEfg1u7wmSlDM=.44289311-c7d5-459e-b81b-2b3beb6458f2@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <Mv4iKMGm3nu49F6Fq0yI2nxzdOV5cBUEfg1u7wmSlDM=.44289311-c7d5-459e-b81b-2b3beb6458f2@github.com>
Message-ID: <7yNQ7OyM4lcRBPGSr0xtMR3GQWXMS6GObAH_cMBfPQY=.135d687e-8b1e-4b01-a5f8-fd23a13f1c4c@github.com>

On Thu, 19 Sep 2024 16:59:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>
> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - resolve conflicts; list deployment as module first
>  - merge master, resolve conflicts
>  - reflect review comments
>  - newline in module-info.java
>  - init

src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38:

> 36:  * zero-argument constructor and some number of associated charset
> 37:  * implementation classes.  Charset providers may be installed in an instance
> 38:  * of the Java platform as extensions.  Providers may also be made available by

It is not related to module path, but taking this opportunity, let's amend this sentence that refers to "extensions" which is obsolete.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1767244764

From jlu at openjdk.org  Thu Sep 19 17:03:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 17:03:02 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v3]
In-Reply-To: <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
Message-ID: <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>

On Thu, 19 Sep 2024 05:39:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
>> 
>>  - resolve conflicts; list deployment as module first
>>  - merge master, resolve conflicts
>>  - reflect review comments
>>  - newline in module-info.java
>>  - init
>
> test/jdk/java/nio/charset/spi/provider/module-info.java line 24:
> 
>> 22:  */
>> 23: module provider {
>> 24:     exports spi;
> 
> It's a bit of anti pattern for service provider modules to export an API, can you drop this? I don't think it's possible to check the test setup while that is there.

Thanks for taking a look Alan. Your test comments should be addressed in https://github.com/openjdk/jdk/pull/21076/commits/790abd039dd08ca1e0575feca29f681a2507d902.
Did you have any comments on the current doc change?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1767246756

From jlu at openjdk.org  Thu Sep 19 17:05:49 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 19 Sep 2024 17:05:49 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v4]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <OBA0hfGu14w0Bt8GnNfKS3Ox7CBIeb-9rbqNGLMiJzA=.1ec4c803-77ef-41e2-9fad-a37bcdcb701f@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

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

  drop obsolete 'extensions' sentence

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21076/files
  - new: https://git.openjdk.org/jdk/pull/21076/files/13626924..b7b5044f

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

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

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

From pminborg at openjdk.org  Fri Sep 20 07:28:40 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 07:28:40 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v5]
In-Reply-To: <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <o--l6IC9JxuNJ9SvI7YURxiImmj-vqRd0pWC2nWWBRc=.6f3881df-6e7e-4446-9255-e6fe1a5b6b57@github.com>
Message-ID: <qvfATZGAgXd4MoiELFmkP9icMRWjYiRpUOiqPbB3RhQ=.ae059d0a-dd94-4295-91ef-c9b180f71552@github.com>

On Tue, 17 Sep 2024 14:25:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg 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 nine additional commits since the last revision:
> 
>  - Merge branch 'master' into internal-mh-util
>  - Rename class and shorten JavaDoc
>  - Update javadoc
>  - Rename utility class
>  - Move to new package and add overload
>  - Merge branch 'master' into internal-mh-util
>  - Rename and reformat
>  - Fix copyright headers
>  - Introduce MethodHandlesInternal

I've experimented a bit with using the `ConstantBoostraps::fieldVarHandle` method and here is what it looks like at a call site (example from `CompletableFuture`):


RESULT = ConstantBootstraps.fieldVarHandle(l, "result", VarHandle.class, CompletableFuture.class, Object.class);


Compared to:


RESULT = MhUtil.findVarHandle(l,  "result", Object.class);


One advantage is that we can remove two methods from the `MhUtil` class but the drawback is we need to add a lot of more parameters at the call sites. Eventually, both methods will work the same except from the exception handling. So, I think it is better to use the proposed `MhUtil` rather than `ConstantBootstraps`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2363013810

From pminborg at openjdk.org  Fri Sep 20 07:36:18 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 07:36:18 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v6]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <zN1MFo09uYUSr_-AdSvFEIh2_QqQTHdZWW6U7wsIBhM=.ccbbc5fa-6dd5-48b4-8123-2e8957b86304@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

Per Minborg 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 11 additional commits since the last revision:

 - Simplify calls
 - Merge branch 'master' into internal-mh-util
 - Merge branch 'master' into internal-mh-util
 - Rename class and shorten JavaDoc
 - Update javadoc
 - Rename utility class
 - Move to new package and add overload
 - Merge branch 'master' into internal-mh-util
 - Rename and reformat
 - Fix copyright headers
 - ... and 1 more: https://git.openjdk.org/jdk/compare/85e28c70...5d9f1be9

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/a1444c28..5d9f1be9

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

  Stats: 20508 lines in 294 files changed: 18484 ins; 277 del; 1747 mod
  Patch: https://git.openjdk.org/jdk/pull/20972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20972/head:pull/20972

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

From pminborg at openjdk.org  Fri Sep 20 08:14:04 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 20 Sep 2024 08:14:04 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v7]
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

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

  Revert change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20972/files
  - new: https://git.openjdk.org/jdk/pull/20972/files/5d9f1be9..67f90de7

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

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

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

From duke at openjdk.org  Fri Sep 20 11:52:35 2024
From: duke at openjdk.org (xpbob)
Date: Fri, 20 Sep 2024 11:52:35 GMT
Subject: RFR: 8340087: (fs) Files.copy include symbolic link detailed
 message for NoSuchFileException [v2]
In-Reply-To: <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>
References: <5y8-RkvWw8TbPVCM_LLdg9nFQ9ydcHkLlLlVN8JWYfI=.7a039946-bc43-41e8-bbca-224375e9c6e8@github.com>
 <XQIV52T2oM4tepBXVoY91WDBE7U6wgdbe4R8dhNAUB4=.82c0bcc4-c89f-4b94-a17d-d9d24416f79b@github.com>
Message-ID: <8mVK7spKMbxnKn6pp4IWnE9CELvHUUDuSYVrZTOxzi8=.875b39a2-584e-4064-8ec9-c2064e4de2fb@github.com>

On Fri, 13 Sep 2024 07:19:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> xpbob has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reimport package
>
> src/java.base/unix/classes/sun/nio/fs/UnixFileSystem.java line 1013:
> 
>> 1011:                     if (symbolicLink != null) {
>> 1012:                         throw new NoSuchFileException(source.toString(), null, "due to " + symbolicLink);
>> 1013:                     }
> 
> The default provider implementation can't use Files.* methods, otherwise you end up with recursive usage.
> 
> In any case, I think the starting out to decide if anything should change as the existing NoSuchFileException is not wrong.

@AlanBateman @bplb 
sorry for late,Thanks for guiding the process

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20984#discussion_r1768462153

From alanb at openjdk.org  Fri Sep 20 13:01:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Sep 2024 13:01:39 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v4]
In-Reply-To: <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
 <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>
Message-ID: <Qm2kX9A6EU_HE6G8ESJhMmaJl0SoY5JN5Rrt6pR80Uk=.bd03262b-eb70-40b4-ab2f-f1cd631f1e5b@github.com>

On Thu, 19 Sep 2024 16:59:50 GMT, Justin Lu <jlu at openjdk.org> wrote:

>  Did you have any comments on the current doc change?

I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1768577156

From alanb at openjdk.org  Fri Sep 20 13:09:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 20 Sep 2024 13:09:36 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v4]
In-Reply-To: <OBA0hfGu14w0Bt8GnNfKS3Ox7CBIeb-9rbqNGLMiJzA=.1ec4c803-77ef-41e2-9fad-a37bcdcb701f@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <OBA0hfGu14w0Bt8GnNfKS3Ox7CBIeb-9rbqNGLMiJzA=.1ec4c803-77ef-41e2-9fad-a37bcdcb701f@github.com>
Message-ID: <fqoEpJoe-7VFfs5a3ap400fbCZvTA1iZcJSgtRrRTSw=.49570523-e240-4d2e-b4d6-6b48bdd6b94c@github.com>

On Thu, 19 Sep 2024 17:05:49 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   drop obsolete 'extensions' sentence

src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 43:

> 41:  * loader}. See {@link java.util.ServiceLoader##developing-service-providers
> 42:  * Deploying Service Providers} for further detail on deploying a charset
> 43:  * provider as a module or on the class path.

I think it would better to say "deployed" rather than "available" here, that will align with the later text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1768587575

From rriggs at openjdk.org  Fri Sep 20 16:14:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 20 Sep 2024 16:14:38 GMT
Subject: RFR: 8325949: Create an internal utility method for creating
 VarHandle instances [v7]
In-Reply-To: <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
 <RA9VMXnwmsFAOcCscNjIs2dmx3hYPQAbbJ0HfUje5SY=.e2de3ec3-41cc-4627-a3b3-265f9c96be1c@github.com>
Message-ID: <7MJxg_rS9YTysPR7WLIMT7SF__DNazV5DtgNqh0goyU=.3117eb70-70aa-4029-90c3-432175c5aece@github.com>

On Fri, 20 Sep 2024 08:14:04 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
>> 
>> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
>> 
>> | Class File                                      | Base [Bytes] | Patch [Byte] |
>> | --------------------------------| ------------- | ------------ |
>> | FutureTask.class                          |            10,255 |          10,123 |
>> | AtomicBoolean.class                   |             5,364 |            5,134 |
>> |AtomicMarkableReference.class |             3,890 |           3,660 |
>> 
>> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
>> 
>> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
>> 
>> In total for `java.base` we have:
>> 
>> | Build map "jdk"  | Size [Bytes] |
>> | ---------------| ------------- |
>> | Base                 |     5,906,457 |
>> | Patch                |     5,905,487 |
>> | Delta                 |                940|
>> 
>> For 60 billion instances, this represents > 50 TB.
>> 
>> Tried and passed tier1-3
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert change

Looks good.

The current (MhUtil) source is easier to read. 
So unless ConstantBootstraps could have an equivalent (simple) API that evaluates to a DynamicConstant, keep what you have.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20972#pullrequestreview-2318714294
PR Comment: https://git.openjdk.org/jdk/pull/20972#issuecomment-2364070043

From dhanalla at openjdk.org  Fri Sep 20 22:14:40 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Fri, 20 Sep 2024 22:14:40 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
Message-ID: <tcyj49lfOduyQcEi8Y4B-Xf1hBohppLg_ZKX-KodAaA=.5a51fcf3-9f9d-420d-8dc9-647b403a07c3@github.com>

On Thu, 22 Aug 2024 18:18:57 GMT, Dhamoder Nalla <dhanalla at openjdk.org> wrote:

> The `wepoll` code has been ported from opensource repo [`wepoll`](https://github.com/piscisaureus/wepoll) to OpenJDK in PR [pull/3816](https://github.com/openjdk/jdk/pull/3816), which incorporated undocumented Windows APIs (NtCreateKeyedEvent, NtReleaseKeyedEvent, NtWaitForKeyedEvent). 
> 
> This PR aims to replace these undocumented APIs with documented synchronization APIs. 
> 
> Test Performed:
> 1. All 12 tests in wepoll repo passed 
>            test-auto-drop-on-close PASS
>            test-connect-fail-events PASS
>            test-connect-success-events PASS
>            test-ctl-fuzz PASS
>            test-error PASS
>            test-leak-1 PASS
>            test-mixed-socket-types PASS
>            test-multi-poll PASS
>            test-oneshot-and-hangup PASS
>            test-reflock PASS
>            test-tree PASS
>            test-udp-pings PASS
>         DONE - 12 PASSED, 0 FAILED
> 
> 2. No new failure in JTreg test
> 3. Micro bench results: similar performance score before and after the changes
> 
> without change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/c784d00e-3f0a-483d-b60a-c7a46aba885c)
> 
> With the change in this PR:
> 
> ![image](https://github.com/user-attachments/assets/5e6a68bc-48ae-475f-891e-395941068f6e)

> I understand that this is a like-for-like replacement, where `reflock__signal_event` waits for another thread to call `reflock__await_event`, because that's what `NtReleaseKeyedEvent` did, even if that is not necessary from the perspective of the calling code. It looks OK, but it doesn't make the code easier to follow.
> 
> I think if we're going to touch this code, we should make it more readable than the original. We could replace the whole reflock structure with SRW locks; `reflock_ref` is semantically equivalent to `AcquireSRWLockShared`, `reflock_unref` is equivalent to `ReleaseSRWLockShared`, and `reflock_unref_and_destroy` is equivalent to `ReleaseSRWLockShared` followed by `AcquireSRWLockExclusive`.
> 
> Also, I'd very much like to avoid forking wepoll here. We keep our own copy to simplify the build system, but we don't want to maintain our own fork. @dhanalla if the [piscisaureus/wepoll#37](https://github.com/piscisaureus/wepoll/pull/37) request is not accepted, do you plan to maintain a fork of wepoll? Or is wepoll officially dead?
> 
> Finally, this PR claims to replace the undocumented APIs, but does nothing about the usage of AFD. Is there a plan to remove the AFD too?

Thank you @djelinski, At this time, we don?t have the bandwidth to fork and maintain wepoll. If this presents a challenge for the PR, we completely understand and will proceed by closing it. We will make the necessary changes directly in our downstream distribution.

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

PR Comment: https://git.openjdk.org/jdk/pull/20682#issuecomment-2364687200

From jlu at openjdk.org  Fri Sep 20 23:41:10 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Sep 2024 23:41:10 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v5]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <sg5R7o0z6ocLMyVcJOfAtKMWPEWw9lNjuKJxD5BcgEI=.b0aa18d0-0e41-4b14-a1f6-3311d7487916@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

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

  review: 'available' -> 'deployed'

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21076/files
  - new: https://git.openjdk.org/jdk/pull/21076/files/b7b5044f..c4056ba8

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

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

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

From jlu at openjdk.org  Fri Sep 20 23:41:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Sep 2024 23:41:11 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v4]
In-Reply-To: <fqoEpJoe-7VFfs5a3ap400fbCZvTA1iZcJSgtRrRTSw=.49570523-e240-4d2e-b4d6-6b48bdd6b94c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <OBA0hfGu14w0Bt8GnNfKS3Ox7CBIeb-9rbqNGLMiJzA=.1ec4c803-77ef-41e2-9fad-a37bcdcb701f@github.com>
 <fqoEpJoe-7VFfs5a3ap400fbCZvTA1iZcJSgtRrRTSw=.49570523-e240-4d2e-b4d6-6b48bdd6b94c@github.com>
Message-ID: <FUDcwBF48D6xFMgseVh1gKGd5MdhpuiCwmpfBq_kHQ8=.7b23b128-64f8-42b3-b189-9ae7dfea9c5a@github.com>

On Fri, 20 Sep 2024 13:07:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   drop obsolete 'extensions' sentence
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 43:
> 
>> 41:  * loader}. See {@link java.util.ServiceLoader##developing-service-providers
>> 42:  * Deploying Service Providers} for further detail on deploying a charset
>> 43:  * provider as a module or on the class path.
> 
> I think it would better to say "deployed" rather than "available" here, that will align with the later text.

I presume you meant the "available" on line 37 should be "deployed" and changed as such.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769354962

From jlu at openjdk.org  Fri Sep 20 23:41:11 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 20 Sep 2024 23:41:11 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v5]
In-Reply-To: <Qm2kX9A6EU_HE6G8ESJhMmaJl0SoY5JN5Rrt6pR80Uk=.bd03262b-eb70-40b4-ab2f-f1cd631f1e5b@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
 <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>
 <Qm2kX9A6EU_HE6G8ESJhMmaJl0SoY5JN5Rrt6pR80Uk=.bd03262b-eb70-40b4-ab2f-f1cd631f1e5b@github.com>
Message-ID: <dwAvO0c_LOFVXYCe1Yu2gxls-63VHULtAkxes3ABdis=.91b6c461-e392-4297-b552-b475ef625ea6@github.com>

On Fri, 20 Sep 2024 12:58:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for taking a look Alan. Your test comments should be addressed in https://github.com/openjdk/jdk/pull/21076/commits/790abd039dd08ca1e0575feca29f681a2507d902.
>> Did you have any comments on the current doc change?
>
>>  Did you have any comments on the current doc change?
> 
> I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets.

Hi Alan,

I think you're right that the CCL is not used.

The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below,


// Assert default context class loader is the system class loader
Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93

// Change the default context class loader
Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system

// Check the class loaders for the various Charsets
Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null
Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1
Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc


Can we simply omit the line: 

"_Charset providers are looked up via the current thread's context class loader_".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769354840

From alanb at openjdk.org  Sat Sep 21 05:58:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 21 Sep 2024 05:58:38 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v5]
In-Reply-To: <dwAvO0c_LOFVXYCe1Yu2gxls-63VHULtAkxes3ABdis=.91b6c461-e392-4297-b552-b475ef625ea6@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
 <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>
 <Qm2kX9A6EU_HE6G8ESJhMmaJl0SoY5JN5Rrt6pR80Uk=.bd03262b-eb70-40b4-ab2f-f1cd631f1e5b@github.com>
 <dwAvO0c_LOFVXYCe1Yu2gxls-63VHULtAkxes3ABdis=.91b6c461-e392-4297-b552-b475ef625ea6@github.com>
Message-ID: <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com>

On Fri, 20 Sep 2024 23:37:18 GMT, Justin Lu <jlu at openjdk.org> wrote:

>>>  Did you have any comments on the current doc change?
>> 
>> I've been slow to reply on that because I'm not 100% sure if the spec is correct. Can you double check that the CCL is actually used. I think it uses the system class loader, and maybe the platform class loader for the extended charsets.
>
> Hi Alan,
> 
> I think you're right that the CCL is not used.
> 
> The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below,
> 
> 
> // Assert default context class loader is the system class loader
> Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
> ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
> 
> // Change the default context class loader
> Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system
> 
> // Check the class loaders for the various Charsets
> Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null
> Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1
> Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
> Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc
> 
> 
> Can we simply omit the line: 
> 
> "_Charset providers are looked up via the current thread's context class loader_".

Thanks for checking. I remember [JDK-4619777 ](https://bugs.openjdk.org/browse/JDK-4619777) and it's possible there are one or two other JBS issue on the topic.  It may be been interesting to include a charset provider with a dynamically loaded application at one point but seems less interesting in 2024. So I think we should just update the spec to align with the long standing behavior, meaning specify that the charset provider must be visible to the system class loader. I think "by some other platform-specific means" by can be dropped too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769483298

From duke at openjdk.org  Sat Sep 21 15:49:36 2024
From: duke at openjdk.org (Markus KARG)
Date: Sat, 21 Sep 2024 15:49:36 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <ewZ5JgD5ew1OWC999ZiZCBkVm8nGlAElVdogQGhM2is=.012e005f-158b-4c93-9409-1c0e66923c6e@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <ewZ5JgD5ew1OWC999ZiZCBkVm8nGlAElVdogQGhM2is=.012e005f-158b-4c93-9409-1c0e66923c6e@github.com>
Message-ID: <WBxgrK6hZTAcfweSArRnVA9LtyXXGwbJhx_0WAnKUw0=.df7eb0a2-46d6-4700-ab09-b4994f6c06a3@github.com>

On Tue, 13 Aug 2024 11:08:11 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think the Socket and Pipe changes need to be separated and the merits of each discussed separately.

I understand your intention, and that should be possible on Linux, but on Windows this is impossible as the Pipe implementation on Windows actually is just a wrapper around the Socker implementation. As all OS share common code, in fact I do not see the possibility to separate Sockets and Pipes hence. Possible I missed an obvious solution to that interrelation, then please tell me.

> Starting with the changes to improve InputStream.skip when connected to a socket seems okay. There are two implementations, one is the SocketImpl implementation used by the Socket API (not changed here), the other is implementation returned by SocketChannel::socket which is changed here. It seems plausible that improving skip will help some use-cases. My initial reaction to touching this area is that will likely require clarifications to the specification of Socket.getInputStream, e.g. this method doesn't specify how show skip behaves when a timeout is set, doesn't specify IllegalBlockingModeException when the channel is non-blocking, and doesn't specify how it behaves when the Thread is interrupted.

Thank you for your kind review. I will look into adding some JavaDocs to better express the behavior of the changed classes.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2365232471

From jlu at openjdk.org  Sat Sep 21 18:13:12 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 21 Sep 2024 18:13:12 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v6]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.

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

  review: spec correction - system class loader used, not context

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21076/files
  - new: https://git.openjdk.org/jdk/pull/21076/files/c4056ba8..d90f6ca0

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

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

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

From jlu at openjdk.org  Sat Sep 21 18:15:34 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 21 Sep 2024 18:15:34 GMT
Subject: RFR: 8340404: Clarify CharsetProvider deployment on application
 module path [v6]
In-Reply-To: <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1l7W-6ledngWeCzQEAnVDX6w4NKSxduKWEf2lmu3C1I=.ec784266-f39b-41d2-a668-a5e21b752b3b@github.com>
 <nzF6gxI6Dj7ZWsM3KGt8ssRLzOglQgAxXPN2Jyh5Me4=.0846a715-7549-485b-a3e0-a002889be521@github.com>
 <Qm2kX9A6EU_HE6G8ESJhMmaJl0SoY5JN5Rrt6pR80Uk=.bd03262b-eb70-40b4-ab2f-f1cd631f1e5b@github.com>
 <dwAvO0c_LOFVXYCe1Yu2gxls-63VHULtAkxes3ABdis=.91b6c461-e392-4297-b552-b475ef625ea6@github.com>
 <-U9GTEry_sU8-ivH74GzV59gTCqwJLM2rbt7rZqFYZg=.389fc9a2-eba1-4250-bbb7-5501831c23d2@github.com>
Message-ID: <Fjwt-nPSgwgmqDsB5jWkkApZRrPRROvsKOQwQGWDLBQ=.72ecfec8-403f-4450-90b1-b7b37bd7069f@github.com>

On Sat, 21 Sep 2024 05:55:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Hi Alan,
>> 
>> I think you're right that the CCL is not used.
>> 
>> The standard charsets are loaded via the SystemClassLoader, the extended are loaded via the platformClassLoader, and BazProvider does appear to be loaded via the SystemClassLoader. See below,
>> 
>> 
>> // Assert default context class loader is the system class loader
>> Thread.currentThread().getContextClassLoader(); // default context class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
>> ClassLoader.getSystemClassLoader(); // system class loader -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
>> 
>> // Change the default context class loader
>> Thread.currentThread().setContextClassLoader(new FooLoader()); // Change default context class loader to not be the system
>> 
>> // Check the class loaders for the various Charsets
>> Charset.availableCharsets().get("utf-8").getClassLoader(); // standard -> null
>> Charset.availableCharsets().get("Big5").getClassLoader(); // extended -> jdk.internal.loader.ClassLoaders$PlatformClassLoader at 55a95ab1
>> Charset.availableCharsets().get("BAZ").getClassLoader(); // provider -> jdk.internal.loader.ClassLoaders$AppClassLoader at 1d81eb93
>> Thread.currentThread().getContextClassLoader(); // context class loader -> CharsetProviderAsModuleTest$FooLoader at 1d15c6cc
>> 
>> 
>> Can we simply omit the line: 
>> 
>> "_Charset providers are looked up via the current thread's context class loader_".
>
> Thanks for checking. I remember [JDK-4619777 ](https://bugs.openjdk.org/browse/JDK-4619777) and it's possible there are one or two other JBS issue on the topic.  It may be been interesting to include a charset provider with a dynamically loaded application at one point but seems less interesting in 2024. So I think we should just update the spec to align with the long standing behavior, meaning specify that the charset provider must be visible to the system class loader. I think "by some other platform-specific means" by can be dropped too.

Updated in https://github.com/openjdk/jdk/pull/21076/commits/d90f6ca0dcc1f5fd6d74af58c4cb2b0d14d1666e.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1769632649

From alanb at openjdk.org  Sun Sep 22 07:50:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 22 Sep 2024 07:50:42 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v6]
In-Reply-To: <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com>
Message-ID: <eUBM4bfyjC4KiKA3iP2SYWh0VHfe8eORYf2gcfKkv3c=.532e06d0-0e2a-4aa6-9f5e-c58abf1dd99c@github.com>

On Sat, 21 Sep 2024 18:13:12 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>> 
>> Additionally some outdated info is corrected as part of this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: spec correction - system class loader used, not context

src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38:

> 36:  * zero-argument constructor and some number of associated {@code Charset}
> 37:  * implementation classes.  Charset providers are deployed by adding them to either
> 38:  * the application module path or the application class path. In order to be looked

The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...".

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1770051344

From pminborg at openjdk.org  Mon Sep 23 11:00:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 23 Sep 2024 11:00:48 GMT
Subject: Integrated: 8325949: Create an internal utility method for creating
 VarHandle instances
In-Reply-To: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
References: <WFwGIihse2wANd4E7Dl2RxUYg1NTwwOISQrqL6otEEw=.41f65692-f09f-4fd6-9036-eb6df92050fa@github.com>
Message-ID: <C5QomCzTwznd3fbyem4Qw5a0sAbSZz4sP6voo078awM=.1566116d-8921-47a9-b87e-bf6d2ee3f0ed@github.com>

On Thu, 12 Sep 2024 17:38:44 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR suggests introducing an internal class in `java.base` to simplify the use of some `MethodHandles.Lookup` operations.
> 
> While the utility of the methods might appear to be limited in classes with many static `VarHandle`/`MethodHandle` variables, it should be noted that the class files become smaller and simpler. Here are some examples:
> 
> | Class File                                      | Base [Bytes] | Patch [Byte] |
> | --------------------------------| ------------- | ------------ |
> | FutureTask.class                          |            10,255 |          10,123 |
> | AtomicBoolean.class                   |             5,364 |            5,134 |
> |AtomicMarkableReference.class |             3,890 |           3,660 |
> 
> ![image](https://github.com/user-attachments/assets/fdcbbdfe-c906-4e50-a48c-4944c53c08cc)
> 
> The new `MethodHandlesInternal.class` file is of size 1,952 bytes.
> 
> In total for `java.base` we have:
> 
> | Build map "jdk"  | Size [Bytes] |
> | ---------------| ------------- |
> | Base                 |     5,906,457 |
> | Patch                |     5,905,487 |
> | Delta                 |                940|
> 
> For 60 billion instances, this represents > 50 TB.
> 
> Tried and passed tier1-3

This pull request has now been integrated.

Changeset: 384deda6
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/384deda65fd63e23d4caaaa9762f2ac80de78029
Stats:     442 lines in 31 files changed: 125 ins; 210 del; 107 mod

8325949: Create an internal utility method for creating VarHandle instances

Reviewed-by: rriggs

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

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

From jlu at openjdk.org  Mon Sep 23 17:20:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Sep 2024 17:20:52 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v7]
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
> 
> Additionally some outdated info is corrected as part of this change.

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

  review: simplify wording

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21076/files
  - new: https://git.openjdk.org/jdk/pull/21076/files/d90f6ca0..08e8161c

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

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

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

From jlu at openjdk.org  Mon Sep 23 17:20:52 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Sep 2024 17:20:52 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v6]
In-Reply-To: <eUBM4bfyjC4KiKA3iP2SYWh0VHfe8eORYf2gcfKkv3c=.532e06d0-0e2a-4aa6-9f5e-c58abf1dd99c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com>
 <eUBM4bfyjC4KiKA3iP2SYWh0VHfe8eORYf2gcfKkv3c=.532e06d0-0e2a-4aa6-9f5e-c58abf1dd99c@github.com>
Message-ID: <oL6zblQxXIqfhGawPcc3vN2bilUhvCguOwIGNmkBn_U=.0b7ed8c1-a74a-4147-b0b6-1e3a01a48ab4@github.com>

On Sun, 22 Sep 2024 07:48:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: spec correction - system class loader used, not context
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38:
> 
>> 36:  * zero-argument constructor and some number of associated {@code Charset}
>> 37:  * implementation classes.  Charset providers are deployed by adding them to either
>> 38:  * the application module path or the application class path. In order to be looked
> 
> The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...".

Fixed in https://github.com/openjdk/jdk/pull/21076/commits/08e8161c3d9a6c2efca7b5f578a72060537495e9

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1771819878

From alanb at openjdk.org  Mon Sep 23 17:24:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 23 Sep 2024 17:24:39 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v7]
In-Reply-To: <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
Message-ID: <uhuW3GxbaDdZmKLKRR_4zKyeNqzmvTgJ2qemsB9f3L0=.c5813cab-907e-46f9-b3fd-09509435af50@github.com>

On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>> 
>> Additionally some outdated info is corrected as part of this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: simplify wording

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21076#pullrequestreview-2322889142

From jlu at openjdk.org  Mon Sep 23 18:42:38 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 23 Sep 2024 18:42:38 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v6]
In-Reply-To: <eUBM4bfyjC4KiKA3iP2SYWh0VHfe8eORYf2gcfKkv3c=.532e06d0-0e2a-4aa6-9f5e-c58abf1dd99c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <1J824jNqjjAw-bd6wMBxP-gH5JfSrQT6b10B2BKS_Og=.26102276-59bd-40ea-9de7-5d77d614943a@github.com>
 <eUBM4bfyjC4KiKA3iP2SYWh0VHfe8eORYf2gcfKkv3c=.532e06d0-0e2a-4aa6-9f5e-c58abf1dd99c@github.com>
Message-ID: <owtS6gLsO5Inx4oR2wqvqqW_bJe1tavGBzF3wMzFR7w=.e0efb7bb-b3d8-4581-95c5-ae995ae4f649@github.com>

On Sun, 22 Sep 2024 07:48:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review: spec correction - system class loader used, not context
>
> src/java.base/share/classes/java/nio/charset/spi/CharsetProvider.java line 38:
> 
>> 36:  * zero-argument constructor and some number of associated {@code Charset}
>> 37:  * implementation classes.  Charset providers are deployed by adding them to either
>> 38:  * the application module path or the application class path. In order to be looked
> 
> The latest update to the class description looks quite good. I think this sentence can be simplified down to "Charset provider are deployed on the application module path ...".

Thanks for the approval @AlanBateman . Could you also review the [CSR](https://bugs.openjdk.org/browse/JDK-8340412) when you get the chance.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21076#discussion_r1771916116

From naoto at openjdk.org  Mon Sep 23 23:04:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 23 Sep 2024 23:04:35 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v7]
In-Reply-To: <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
Message-ID: <WBwD1QJGcZEGUx5ZzlbS16LMeSca5_irrpjy69vcbSI=.fe030b67-2c01-4677-ac09-23d96965d5a5@github.com>

On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>> 
>> Additionally some outdated info is corrected as part of this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: simplify wording

Marked as reviewed by naoto (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21076#pullrequestreview-2323665232

From alanb at openjdk.org  Fri Sep 27 07:39:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 27 Sep 2024 07:39:36 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <WBxgrK6hZTAcfweSArRnVA9LtyXXGwbJhx_0WAnKUw0=.df7eb0a2-46d6-4700-ab09-b4994f6c06a3@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <ewZ5JgD5ew1OWC999ZiZCBkVm8nGlAElVdogQGhM2is=.012e005f-158b-4c93-9409-1c0e66923c6e@github.com>
 <WBxgrK6hZTAcfweSArRnVA9LtyXXGwbJhx_0WAnKUw0=.df7eb0a2-46d6-4700-ab09-b4994f6c06a3@github.com>
Message-ID: <HEmAPpif2jJWjGikk-bWUmq0CW4GLShRr3gXKDCv3Jg=.9c5b332f-ab01-47da-82cd-fd875311dbc6@github.com>

On Sat, 21 Sep 2024 15:47:05 GMT, Markus KARG <duke at openjdk.org> wrote:

> I will look into adding some JavaDocs to better express the behavior of the changed classes.

In addition to skip, the other methods that may be implemented with more than one read are the transferTo, readAllBytes, readNBytes, ... all methods added since JDK 1.0. It may be that Socket's class level description or the setSoTimeout method will need wording to say that it is implementation specific as to how the configured timeouts works with these methods. It may apply to the entire operation or ports of, tricky to word.

The issue of skip or any of the other methods throwing IllegalBlockingModeException can probably be confined to the Socket.getInputStream's API docs where it already documents this exception as possible when reading.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2378612632

From jlu at openjdk.org  Fri Sep 27 18:28:42 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Sep 2024 18:28:42 GMT
Subject: RFR: 8340404: CharsetProvider specification updates [v7]
In-Reply-To: <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
 <IVpvq7YiZVIdsJ7WziFtaNJNxa6cVcvxaYltqNXp-b0=.cd018a79-4885-4f76-8331-83577daceffb@github.com>
Message-ID: <c_ZjzNlvF8l8Auq5cq9nUOY4gsYQY9FRFVCYdmufHmw=.b0c29f9a-b08d-4319-a3a7-ef1d6bf8e629@github.com>

On Mon, 23 Sep 2024 17:20:52 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
>> 
>> This came as a result from a comment on the PR of JDK-8339735. 
>> 
>> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
>> 
>> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
>> 
>> Additionally some outdated info is corrected as part of this change.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review: simplify wording

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/21076#issuecomment-2379831212

From jlu at openjdk.org  Fri Sep 27 18:28:43 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 27 Sep 2024 18:28:43 GMT
Subject: Integrated: 8340404: CharsetProvider specification updates
In-Reply-To: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
References: <c8a0UYbJILfgdmAWWUHHnUYSSRRYgIDPiQE2DQ-2Mws=.b65beff6-0b11-43ef-bcee-9fbe35d15d2c@github.com>
Message-ID: <nXSURJAsq_TyD2-UkKHGjLeha0dQe_ibe7iS1-gJoWY=.936ffdc4-985d-4535-89d8-dd75b517223d@github.com>

On Thu, 19 Sep 2024 00:07:30 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and [CSR](https://bugs.openjdk.org/browse/JDK-8340412) which clarifies that a CharsetProvider SPI can be provided via the application module path.
> 
> This came as a result from a comment on the PR of JDK-8339735. 
> 
> I included some minor wording on deploying as a module, with a link to `Service Loader's` _Developing Service Providers section_ to handle the heavy lifting. However, I am happy to adjust as needed, if it is felt that more info should be laid out directly on `CharsetProvider's` class description itself.
> 
> An associated test is provided to confirm that a `CharsetProvider` _can_ be deployed as a module.
> 
> Additionally some outdated info is corrected as part of this change.

This pull request has now been integrated.

Changeset: 082125d6
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/082125d61e4b7e0fd53528c0271ca8be621f242b
Stats:     157 lines in 4 files changed: 143 ins; 1 del; 13 mod

8340404: CharsetProvider specification updates

Reviewed-by: alanb, naoto

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

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

From eirbjo at openjdk.org  Mon Sep 30 19:14:45 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 30 Sep 2024 19:14:45 GMT
Subject: RFR: 8341243: Use ArraySupport.SOFT_MAX_ARRAY_LENGTH for max array
 size in java.base
Message-ID: <J20B4RlNiMR80hwrnp8AaUVvxia7dEEyFxKiYt_EsYY=.8e5327d5-e0f4-4d35-91a2-a469368bf2cb@github.com>

Please review this cleanup PR which updates code and tests in `java.base` to consistently use  `jdk.internal.util.ArraySupport.SOFT_MAX_ARRAY_LENGTH` when referring to the JVM's maximum array size implementation limit. Currently, instances of `Integer.MAX_VALUE - 8` are found across the code base, with varying degrees of documentation. It would be good to consolidate on a single source of truth, with proper documentation.

This PR is a follow-up to #20905 where the same change was requested in `java.util.zip`.

My understanding is that javac will fold this constant value into the byte code of the compiled use sites, as such this change should not affect class loading or cause startup issues. 

Instances selected for this PR were found searching for "Integer.MAX_VALUE - 8". The PR replaces these with `ArraySupport.SOFT_MAX_ARRAY_LENGTH`, while trimming or amending some code comments where appropriate. (`SOFT_MAX_ARRAY_LENGTH` already has a good explainer which does not need repetition at each use site).

I also searched for instances of `Integer.MAX_VALUE - 1` and `Integer.MAX_VALUE - 2`, no convincing candidates were found.

Instances outside `java.base` were deliberately left out to limit the scope and review cost of this PR.

Tests updated to use `SOFT_MAX_ARRAY_LENGTH` are updated with the jtreg tag `@modules java.base/jdk.internal.util`.

Testing: No new tests are added in this PR, the `noreg-cleanup` label is added to the JBS. The five affected tests have been run manually. GHA tests run green.

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

Commit messages:
 - Add @modules jtreg tag to XcodeOverflow test, required to use ArraysSupport.SOFT_MAX_ARRAY_LENGTH
 - Consolidate and use ArraysSupport.SOFT_MAX_ARRAY_LENGTH in place of Integer.MAX_VALUE - 8

Changes: https://git.openjdk.org/jdk/pull/21268/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341243
  Stats: 64 lines in 15 files changed: 23 ins; 9 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/21268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21268/head:pull/21268

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

From bpb at openjdk.org  Mon Sep 30 23:02:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Sep 2024 23:02:05 GMT
Subject: RFR: 8341282: (fs) Move creation time fallback logic to Java layer
 (Linux)
Message-ID: <ooVjh4i2Tu6gez3wTOr-Uf8P4PvTQcjJmbCKsRHR_HE=.01a4018b-8fc6-42c2-b4a0-d8453125cc39@github.com>

Move the decision as to whether `BasicFileAttributes.creationTime()` falls back to the modified time from the native layer to the Java layer.

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

Commit messages:
 - 8341282: (fs) Move creation time fallback logic to Java layer (Linux)

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

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

From bpb at openjdk.org  Mon Sep 30 23:24:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 30 Sep 2024 23:24:37 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <Nl_T14imLwJ1TtF5f3cAYYzWDrf3eHDGoxBoLW7RiCM=.d6e45f31-5937-493e-a860-59350a0ca9ee@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
 <8uO3dA3UYD5UDVb9FrNf-JSACS86o-5dZKMcZ7KD-hA=.d67b5ab1-c7df-40ed-9da4-01efc359e651@github.com>
 <5oOvufswuiCF1In92xBLABrpWdrZVuP0d_dRD-rjVl0=.b21ac190-5f2f-447f-bc71-ddc599288004@github.com>
 <2GcDA0gVCJbmu1qieXHdev877w-UopfpKOZ8MlpfzUs=.eb5cea48-6192-40a7-a3be-9827eb159069@github.com>
 <dg-AoMVCvyPY0RLj5cBk7-g9IMjwUpHFAy7Y5IvMldc=.1720a693-40f2-4488-bd0e-aaf767c8ed7a@github.com>
 <Nl_T14imLwJ1TtF5f3cAYYzWDrf3eHDGoxBoLW7RiCM=.d6e45f31-5937-493e-a860-59350a0ca9ee@github.com>
Message-ID: <G2dX1xsSYZMeaUKos3a5DOFoVPAgfoxM5CJolrvsMjI=.35b86d80-fd8f-401c-9042-656f0a2c18e2@github.com>

On Wed, 21 Aug 2024 16:29:59 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> It should have as there was a behavioral change: creation time changed from last modified time to epoch when the birth time is not available.
>
> Fair enough.

> I guess is okay although I think I'd much prefer to decide this in the Java code. Maybe we can re-examine this again in the future.

This is addressed by [JDK-8341282](https://bugs.openjdk.org/browse/JDK-8341282).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1781905311