From alanb at openjdk.org  Thu Aug  1 06:22:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 1 Aug 2024 06:22:32 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v3]
In-Reply-To: <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
Message-ID: <YQkJGY5rkY37_qVvi6y0Bn4UuUMcbdYuFgEj_67JQ5o=.809f7cd4-b87e-4899-93f6-8eeea8205ef2@github.com>

On Wed, 31 Jul 2024 18:45:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace differences of milliseconds vs. epoch to differences of nanoseconds per the JVM's high-resolution time source.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8334405: Update limits on expected duration as suggested

I think this is looks okay and the tolerances are good. There is course a risk that the timer used by the OS (for timed poll) may have issues but their isn't anything we do about that.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2211741226

From dfuchs at openjdk.org  Thu Aug  1 09:26:40 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Aug 2024 09:26:40 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v3]
In-Reply-To: <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
Message-ID: <Qnx7tJA0lF9F2LApuH0F185x4htTG42RoPwkaxU3LHY=.a629d7e6-8fd8-4879-8813-60ba8d88183e@github.com>

On Wed, 31 Jul 2024 18:45:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace differences of milliseconds vs. epoch to differences of nanoseconds per the JVM's high-resolution time source.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8334405: Update limits on expected duration as suggested

Marked as reviewed by dfuchs (Reviewer).

Looks OK to me. I see that the time bound changes correspond to what has been requested by Alan.

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

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2212207993
PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2262570592

From vtewari at openjdk.org  Thu Aug  1 11:40:39 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Thu, 1 Aug 2024 11:40:39 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v3]
In-Reply-To: <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
Message-ID: <tuREd8wRxvujV8bUzXvEfD22XZa4uGYLqi-WIu6x5sw=.fe715b65-a4bb-4649-9672-1945483e3427@github.com>

On Wed, 31 Jul 2024 18:45:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace differences of milliseconds vs. epoch to differences of nanoseconds per the JVM's high-resolution time source.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8334405: Update limits on expected duration as suggested

Looks OK to me.

test/jdk/java/nio/channels/Selector/SelectWithConsumer.java line 766:

> 764:     private static long millisTime() {
> 765:         long now = System.nanoTime();
> 766:         return TimeUnit.MILLISECONDS.convert(now, TimeUnit.NANOSECONDS);

you can get rid of local variable now as follows.
return TimeUnit.MILLISECONDS.convert(System.nanoTime(), TimeUnit.NANOSECONDS);

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2212486249
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1699996130

From bpb at openjdk.org  Thu Aug  1 15:36:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 Aug 2024 15:36:34 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v3]
In-Reply-To: <tuREd8wRxvujV8bUzXvEfD22XZa4uGYLqi-WIu6x5sw=.fe715b65-a4bb-4649-9672-1945483e3427@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>
 <tuREd8wRxvujV8bUzXvEfD22XZa4uGYLqi-WIu6x5sw=.fe715b65-a4bb-4649-9672-1945483e3427@github.com>
Message-ID: <XqavuC0BD2w2QgKtef3oNMecQ7MjJkvmmIVe5O8nNwE=.fe60c85d-e234-4a33-b3e3-72232ab01f34@github.com>

On Thu, 1 Aug 2024 11:38:09 GMT, Vyom Tewari <vtewari at openjdk.org> wrote:

> [...] you can get rid of local variable now as follows.

I think I'll forego this change for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1700403484

From dfuchs at openjdk.org  Thu Aug  1 15:36:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 1 Aug 2024 15:36:54 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v3]
In-Reply-To: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
Message-ID: <QC8T_4VynA4jHVLwZ8OlHvJS8MsX7FIXi9gtdTMwnxc=.464143c7-9c8c-4be1-84fb-aed1725f5055@github.com>

> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
> 
> The most common source of intermittent failures are:
> 
>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>  - failure to disconnect due to interference of concurrent running tests
>  - failure due to reception of unexpected stray datagrams
> 
> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.

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

  Review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20050/files
  - new: https://git.openjdk.org/jdk/pull/20050/files/6695360d..64fccfb6

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

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

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

From bpb at openjdk.org  Thu Aug  1 19:05:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 1 Aug 2024 19:05:35 GMT
Subject: Integrated: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
Message-ID: <fWoidxvVRNQBnOz8RFNcUAOGxfhLpafJLW_pxRQtTfo=.cceccf9e-b6ea-4fee-a417-7705e648c530@github.com>

On Tue, 30 Jul 2024 23:54:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace differences of milliseconds vs. epoch to differences of nanoseconds per the JVM's high-resolution time source.

This pull request has now been integrated.

Changeset: 21e86d10
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/21e86d10a726fe707febb0111f5b80d8d1d29f03
Stats:     42 lines in 1 file changed: 28 ins; 5 del; 9 mod

8334405: java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in testWakeupDuringSelect

Reviewed-by: dfuchs, alanb, vtewari

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

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

From bpb at openjdk.org  Fri Aug  2 18:09:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 2 Aug 2024 18:09:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
Message-ID: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>

Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.

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

Commit messages:
 - 8324048: Replace SharedSecrets with fdval and handleval native functions
 - 8324048: Unix cleanup
 - 8324048: Windows implementation
 - 8324048: (fc) Make FileKey fields final

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

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

From duke at openjdk.org  Sat Aug  3 19:09:46 2024
From: duke at openjdk.org (duke)
Date: Sat, 3 Aug 2024 19:09:46 GMT
Subject: RFR: 8321279: Implement hashCode() in Heap-X-Buffer.java.template
 [v7]
In-Reply-To: <YIlpFSIUqBm0SEW9yiiR50IRwiTj8fqoHAtvOBSVNYo=.ead23e22-a085-479f-bf9d-9e015605e42e@github.com>
References: <i4935he_WvZeVJQ80PDexHUCgOqBg1Cmb731mNk-itM=.40521796-bea2-4387-a63b-3536c95807e0@github.com>
 <YIlpFSIUqBm0SEW9yiiR50IRwiTj8fqoHAtvOBSVNYo=.ead23e22-a085-479f-bf9d-9e015605e42e@github.com>
Message-ID: <b6_gq4AT2LgLmzv6Q5SQN1jj6eJvlqgVdu6bQzgqpgs=.90d9d677-e37c-43cd-9017-3b57be3f1fd6@github.com>

On Tue, 12 Dec 2023 08:01:47 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently `Heap*Buffer.hashCode()` is inherited from `*Buffer` and implemented as 
>> 
>> public int hashCode() {
>>     int h = 1;
>>     int p = position();
>>     for (int i = limit() - 1; i >= p; i--)
>>         h = 31 * h + (int)get(i);
>>     return h;
>> }
>> 
>> This can be improved using `ArraysSupport.vectorizedHashCode()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Rename method

@stsypanov 
Your change (at version d91925374ba3eaef3203a8d583c56c6a3e5b8485) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/16992#issuecomment-1852797705

From alanb at openjdk.org  Sat Aug  3 19:09:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Aug 2024 19:09:46 GMT
Subject: RFR: 8321279: Implement hashCode() in Heap-X-Buffer.java.template
 [v7]
In-Reply-To: <YIlpFSIUqBm0SEW9yiiR50IRwiTj8fqoHAtvOBSVNYo=.ead23e22-a085-479f-bf9d-9e015605e42e@github.com>
References: <i4935he_WvZeVJQ80PDexHUCgOqBg1Cmb731mNk-itM=.40521796-bea2-4387-a63b-3536c95807e0@github.com>
 <YIlpFSIUqBm0SEW9yiiR50IRwiTj8fqoHAtvOBSVNYo=.ead23e22-a085-479f-bf9d-9e015605e42e@github.com>
Message-ID: <OO2rRfo5edEGkKts0HUF-4-38ToLoD0mS3wHIJHjMuw=.c1170234-d932-433a-989b-e0b5e18b5329@github.com>

On Tue, 12 Dec 2023 08:01:47 GMT, Sergey Tsypanov <stsypanov at openjdk.org> wrote:

>> Currently `Heap*Buffer.hashCode()` is inherited from `*Buffer` and implemented as 
>> 
>> public int hashCode() {
>>     int h = 1;
>>     int p = position();
>>     for (int i = limit() - 1; i >= p; i--)
>>         h = 31 * h + (int)get(i);
>>     return h;
>> }
>> 
>> This can be improved using `ArraysSupport.vectorizedHashCode()`
>
> Sergey Tsypanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8320971: Rename method

This change created a regression and will be reverted with JDK-8337716.

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

PR Comment: https://git.openjdk.org/jdk/pull/16992#issuecomment-2267103701

From bpb at openjdk.org  Sat Aug  3 19:12:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 3 Aug 2024 19:12:02 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
Message-ID: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>

Revert the changes made in #16992 and add some test coverage.

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

Commit messages:
 - 8337716: ByteBuffer hashCode implementations are inconsistent

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

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

From alanb at openjdk.org  Sat Aug  3 19:12:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 3 Aug 2024 19:12:02 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
In-Reply-To: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
Message-ID: <nBZEIPFJ_TlLbyNbT64jRp_K9C8D6aJ8yFCfcUx2kq0=.e7830bf2-a48b-4439-b52a-2325eef34cbc@github.com>

On Sat, 3 Aug 2024 19:04:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revert the changes made in #16992 and add some test coverage.

Marked as reviewed by alanb (Reviewer).

Thanks for jumping on this, it's unfortunate this issue slipped through.

test/jdk/java/nio/Buffer/EqualsCompareTest.java line 732:

> 730:         Files.write(path, bytes);
> 731:         try (FileChannel fc = FileChannel.open(path, StandardOpenOption.READ,
> 732:             StandardOpenOption.DELETE_ON_CLOSE)) {

If you statically import StandardOpenOption then it might be more readable.

test/jdk/java/nio/Buffer/EqualsCompareTest.java line 734:

> 732:             StandardOpenOption.DELETE_ON_CLOSE)) {
> 733:             MappedByteBuffer one =
> 734:                 fc.map(FileChannel.MapMode.READ_ONLY, 0, bytes.length);

Spurious line break here.

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

PR Review: https://git.openjdk.org/jdk/pull/20451#pullrequestreview-2217170884
PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267104521
PR Review Comment: https://git.openjdk.org/jdk/pull/20451#discussion_r1702862687
PR Review Comment: https://git.openjdk.org/jdk/pull/20451#discussion_r1702862733

From bpb at openjdk.org  Sat Aug  3 19:19:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 3 Aug 2024 19:19:04 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
Message-ID: <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>

> Revert the changes made in #16992 and add some test coverage.

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

  8337716: Statically import StandardOpenOption; rem remove spurious line break

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20451/files
  - new: https://git.openjdk.org/jdk/pull/20451/files/c257988f..ba25d550

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

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

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

From bpb at openjdk.org  Sat Aug  3 19:19:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 3 Aug 2024 19:19:04 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <nBZEIPFJ_TlLbyNbT64jRp_K9C8D6aJ8yFCfcUx2kq0=.e7830bf2-a48b-4439-b52a-2325eef34cbc@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <nBZEIPFJ_TlLbyNbT64jRp_K9C8D6aJ8yFCfcUx2kq0=.e7830bf2-a48b-4439-b52a-2325eef34cbc@github.com>
Message-ID: <3iGwY0lq5luGzO76SfMrN0AAdyVqctcOSBX_JrWI6P0=.7866c2d0-e6f5-4fe5-acbb-94e0ef6c9e61@github.com>

On Sat, 3 Aug 2024 19:08:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8337716: Statically import StandardOpenOption; rem remove spurious line break
>
> test/jdk/java/nio/Buffer/EqualsCompareTest.java line 732:
> 
>> 730:         Files.write(path, bytes);
>> 731:         try (FileChannel fc = FileChannel.open(path, StandardOpenOption.READ,
>> 732:             StandardOpenOption.DELETE_ON_CLOSE)) {
> 
> If you statically import StandardOpenOption then it might be more readable.

Fixed in ba25d55.

> test/jdk/java/nio/Buffer/EqualsCompareTest.java line 734:
> 
>> 732:             StandardOpenOption.DELETE_ON_CLOSE)) {
>> 733:             MappedByteBuffer one =
>> 734:                 fc.map(FileChannel.MapMode.READ_ONLY, 0, bytes.length);
> 
> Spurious line break here.

Fixed in ba25d55.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20451#discussion_r1702863682
PR Review Comment: https://git.openjdk.org/jdk/pull/20451#discussion_r1702863701

From liach at openjdk.org  Sat Aug  3 22:56:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 3 Aug 2024 22:56:35 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
Message-ID: <2UkHVo1SjBqjsoCtxsOColiDW6PcM6S3wPqOjuaoaxc=.6b2287fa-0b0c-4134-9cb5-e7cdac6bce1f@github.com>

On Sat, 3 Aug 2024 19:19:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revert the changes made in #16992 and add some test coverage.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337716: Statically import StandardOpenOption; rem remove spurious line break

Thanks. The wrong implementation was computing the hash code backwards, it seems.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20451#pullrequestreview-2217239127

From bpb at openjdk.org  Sun Aug  4 03:37:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sun, 4 Aug 2024 03:37:30 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <2UkHVo1SjBqjsoCtxsOColiDW6PcM6S3wPqOjuaoaxc=.6b2287fa-0b0c-4134-9cb5-e7cdac6bce1f@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
 <2UkHVo1SjBqjsoCtxsOColiDW6PcM6S3wPqOjuaoaxc=.6b2287fa-0b0c-4134-9cb5-e7cdac6bce1f@github.com>
Message-ID: <BU78QaKrW2nFnfUuNgOAlI9hECThSAhHEsL1JRmWwcU=.5d2ae1c3-5f1f-439b-be9f-118265e78dac@github.com>

On Sat, 3 Aug 2024 22:53:32 GMT, Chen Liang <liach at openjdk.org> wrote:

> Thanks. The wrong implementation was computing the hash code backwards, it seems.

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267278403

From alanb at openjdk.org  Sun Aug  4 05:41:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 4 Aug 2024 05:41:40 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
Message-ID: <7eBwRVxFlWiAgz6Y4cGyn_SnXYVA42HGWPCg0TFn5eQ=.0a1ab05b-7fd8-4705-99a5-98590e3212fe@github.com>

On Sat, 3 Aug 2024 19:19:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revert the changes made in #16992 and add some test coverage.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337716: Statically import StandardOpenOption; rem remove spurious line break

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20451#pullrequestreview-2217424334

From bpb at openjdk.org  Sun Aug  4 15:46:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sun, 4 Aug 2024 15:46:36 GMT
Subject: Integrated: 8337716: ByteBuffer hashCode implementations are
 inconsistent
In-Reply-To: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
Message-ID: <Qer7Ek_HvdwrfSfipqkH7HHkkE9O3ojo2Lb493X7VgI=.adacabeb-1b3e-45eb-92bf-246261685ed6@github.com>

On Sat, 3 Aug 2024 19:04:10 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Revert the changes made in #16992 and add some test coverage.

This pull request has now been integrated.

Changeset: 8bd3cd51
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8bd3cd51562ff9e76fa0e3d49d38e6e19210f878
Stats:     36 lines in 3 files changed: 22 ins; 12 del; 2 mod

8337716: ByteBuffer hashCode implementations are inconsistent

Reviewed-by: alanb, liach

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

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

From bpb at openjdk.org  Sun Aug  4 15:46:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sun, 4 Aug 2024 15:46:35 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
Message-ID: <zVIy160pHyIyghnsfiTKKEr8YwgzL3slAPY9PeEE4Dw=.8e5d7103-c1f2-495d-9847-30154a44770c@github.com>

On Sat, 3 Aug 2024 19:19:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revert the changes made in #16992 and add some test coverage.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337716: Statically import StandardOpenOption; rem remove spurious line break

All tier 1-3 tests passed on the usual platforms, except one irrelevant client test timeout.

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

PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267585376

From duke at openjdk.org  Sun Aug  4 17:37:35 2024
From: duke at openjdk.org (Bernd)
Date: Sun, 4 Aug 2024 17:37:35 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
Message-ID: <n-KkzM5XMW_ocAa9ncUJkGPsQS-rjLSinoh9xgR80uI=.65386c7d-f3c7-422e-b0d6-07185020f931@github.com>

On Sat, 3 Aug 2024 19:19:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Revert the changes made in #16992 and add some test coverage.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337716: Statically import StandardOpenOption; rem remove spurious line break

Is it only planned to revert this or also provide a new more optimized (but consistent) hash implementation?

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

PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267614754

From bpb at openjdk.org  Sun Aug  4 18:44:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sun, 4 Aug 2024 18:44:34 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <n-KkzM5XMW_ocAa9ncUJkGPsQS-rjLSinoh9xgR80uI=.65386c7d-f3c7-422e-b0d6-07185020f931@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
 <n-KkzM5XMW_ocAa9ncUJkGPsQS-rjLSinoh9xgR80uI=.65386c7d-f3c7-422e-b0d6-07185020f931@github.com>
Message-ID: <dI21iDBfM6AGkF7kvCczWE4G3ty0SJYYGJacWEly7eQ=.224aa839-9c21-4a86-b7a1-e8eb758bdb25@github.com>

On Sun, 4 Aug 2024 17:34:57 GMT, Bernd <duke at openjdk.org> wrote:

> Is it only planned to revert this or also provide a new more optimized (but consistent) hash implementation?

For this week, only the reversion is planned. We intend to investigate whether an updated implementation would be worthwhile. If so, an issue will be filed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267632671

From liach at openjdk.org  Sun Aug  4 22:06:35 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 4 Aug 2024 22:06:35 GMT
Subject: RFR: 8337716: ByteBuffer hashCode implementations are inconsistent
 [v2]
In-Reply-To: <dI21iDBfM6AGkF7kvCczWE4G3ty0SJYYGJacWEly7eQ=.224aa839-9c21-4a86-b7a1-e8eb758bdb25@github.com>
References: <4JWbott8HzYEQ3Qv0kG56qG95k95Xwfl0UNkVgrhzzo=.af729cd3-d450-4e6c-8461-e752a12549d1@github.com>
 <hDUDM1PH4PUct3MZGH-HraZTgPNnomJthgb9F3vIx4U=.f318a774-e2ef-4337-89d1-86e20f2eb7ab@github.com>
 <n-KkzM5XMW_ocAa9ncUJkGPsQS-rjLSinoh9xgR80uI=.65386c7d-f3c7-422e-b0d6-07185020f931@github.com>
 <dI21iDBfM6AGkF7kvCczWE4G3ty0SJYYGJacWEly7eQ=.224aa839-9c21-4a86-b7a1-e8eb758bdb25@github.com>
Message-ID: <FdAJV4ewE5mV1FkBsi5N-ol_Qk9pjrcL7lsWxNO23bc=.ad19c655-8a7e-4868-97d6-4c1c56d6c204@github.com>

On Sun, 4 Aug 2024 18:41:29 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Is it only planned to revert this or also provide a new more optimized (but consistent) hash implementation?

This is version dependent; we plan to revert this both on 23 (in stabilization, no PR yet) and 24 (current mainline, this PR), but we definitely won't consider a new implementation on 23 for stability concerns. We are open to enhancements for the mainline.

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

PR Comment: https://git.openjdk.org/jdk/pull/20451#issuecomment-2267760056

From bpb at openjdk.org  Mon Aug  5 07:08:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Aug 2024 07:08:03 GMT
Subject: [jdk23] RFR: 8337716: ByteBuffer hashCode implementations are
 inconsistent
Message-ID: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>

Backport to JDK 23 of JDK 24 ```8337716: ByteBuffer hashCode implementations are inconsistent```

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

Commit messages:
 - Backport 8bd3cd51562ff9e76fa0e3d49d38e6e19210f878

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

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

From jpai at openjdk.org  Mon Aug  5 07:15:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 5 Aug 2024 07:15:30 GMT
Subject: [jdk23] RFR: 8337716: ByteBuffer hashCode implementations are
 inconsistent
In-Reply-To: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
References: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
Message-ID: <VOYuu8CDoLw77Zqe3eCjGU3lGKU-uILy_99obQVfUpY=.0f315fca-a3e5-4d8f-9047-3914be9e9d48@github.com>

On Mon, 5 Aug 2024 05:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Backport to JDK 23 of JDK 24 ```8337716: ByteBuffer hashCode implementations are inconsistent```

This is a clean backport of the fix that was done in master branch. Alan has approved for this change to go into jdk23 during the current RDP2 and the issue has a `jdk23-fix-yes` label.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20461#pullrequestreview-2218204527

From alanb at openjdk.org  Mon Aug  5 11:07:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 5 Aug 2024 11:07:32 GMT
Subject: [jdk23] RFR: 8337716: ByteBuffer hashCode implementations are
 inconsistent
In-Reply-To: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
References: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
Message-ID: <9E1rr9lRsNggdpbvTxHMeKFxrZNwr2ZgIDHqZWTVI7c=.78c2930c-f1a5-48fb-be15-23d3a64a1d06@github.com>

On Mon, 5 Aug 2024 05:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Backport to JDK 23 of JDK 24 ```8337716: ByteBuffer hashCode implementations are inconsistent```

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20461#pullrequestreview-2218707097

From bpb at openjdk.org  Mon Aug  5 15:15:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Aug 2024 15:15:37 GMT
Subject: [jdk23] Integrated: 8337716: ByteBuffer hashCode implementations are
 inconsistent
In-Reply-To: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
References: <g-ySVGcX7m0RBon-CNObcKxCs9T_AFS_AA5qXQ6rV1U=.98181744-1c2a-4d83-a9bf-df7327e4138b@github.com>
Message-ID: <U9zZ-Vt2pnAaeYpPZOo6LySWimFJ2bGADNwlu6GHYak=.18fb2a5f-3f6f-4935-8060-deb069fb8c42@github.com>

On Mon, 5 Aug 2024 05:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Backport to JDK 23 of JDK 24 ```8337716: ByteBuffer hashCode implementations are inconsistent```

This pull request has now been integrated.

Changeset: b7ede41a
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b7ede41a2d3a51851f0a139f821f05a10168cbe3
Stats:     36 lines in 3 files changed: 22 ins; 12 del; 2 mod

8337716: ByteBuffer hashCode implementations are inconsistent

Reviewed-by: jpai, alanb
Backport-of: 8bd3cd51562ff9e76fa0e3d49d38e6e19210f878

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

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

From ihse at openjdk.org  Mon Aug  5 15:22:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 5 Aug 2024 15:22:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>

On Fri, 26 Jul 2024 19:40:24 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: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

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

> 55:     OPTIMIZATION := HIGH, \
> 56:     EXTRA_HEADER_DIRS := \
> 57:         libnio/ch, \

This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 

Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.

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

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

Please keep libraries alphabetically sorted.

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

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

From bpb at openjdk.org  Mon Aug  5 15:40:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 5 Aug 2024 15:40:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
Message-ID: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>

On Mon, 5 Aug 2024 15:19:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.

I'll look into improving it.

> make/modules/java.base/lib/CoreLibraries.gmk line 71:
> 
>> 69:         -framework Foundation \
>> 70:         -framework SystemConfiguration, \
>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
> 
> Please keep libraries alphabetically sorted.

Thanks for pointing this out; I will fix it.

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

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

From abakhtin at openjdk.org  Wed Aug  7 04:24:43 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 7 Aug 2024 04:24:43 GMT
Subject: RFR: 8337966: Verify statx permissions
Message-ID: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>

Please review the fix for regression on the old docker versions (before v18.04)

Suggest to verify if statx is permitted during initialization

statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise

Fallback to stat() if statx() not permitted

Related  jtreg tests passed

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

Commit messages:
 - 8337966: Verify statx permissions

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

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

From duke at openjdk.org  Wed Aug  7 09:46:59 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Aug 2024 09:46:59 GMT
Subject: RFR: JDK-8337974 - Implementing ChannelInputStream::skip using splice
 on Linux and C-loops elsewhere
Message-ID: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>

# Targets

The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.

A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.

An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.


# Non-Targets

It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.

It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.

It is not a target to improve other source types besides pipes and sockets.


# Description

What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.

For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.

Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.


# Implementation

The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.

Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferred from the source into the OS kernel, nor from the OS kernel into neither the JVM's off- nor on-heap memory.

For the latter, `/dev/null` is kept open permanently, as dynamically closing and reopening it imposes a considerable performance penalty, while keeping it open imposes only neglectable overhead.

Note: The implementation is mostly copied from existing code of the `read` case and of the `transferTo` test suite. I deliberately tried to modify only the very essential pieces, so the code stays comparable with `read` and the `transferTo` test suite, and hence, stays easiliy maintainable together with that origins.

# Benchmarking

## Case Selection
Benchmarking was performed for pipes only, and only on Linux (Debian on WSL2) and Windows (W2K Pro), but on the exact same hardware. Linux and Windows are assumed to be not only the most used operating systems, but to also cover a big diversity of I/O performance behaviors (Linux is know to be rather fast, Windows is known to be rather slow). On Windows, NIO pipes are actually utilizing OS sockets in OpenJDK 23, so effectively sockets are benchmarked implicitly by the pipes benchmark).

Benchmarking was performed on the optimized branch and on OpenJDK 23 main branch as a baseline.

## Results
The charts below indicate that on both tested operating systems and on both tested source types, performance should in no case be noticable slower than the baseline.

There is clear evidence, that in some many cases, the optimization is faster than the baseline, and in few cases, it is even considerably faster.

In particular, pipes on Linux showed up to 17.5 times the baseline throughput), and "pipes" (effectively: sockets) on Windows reached up to 1.54 times the baseline.

Note: X-axis is logarithmic. Candlesticks reflect error range.

![grafik](https://github.com/user-attachments/assets/5a8c81c2-cced-465a-84b8-bd4f5382689e)

![grafik](https://github.com/user-attachments/assets/21ff33c3-91d7-4acb-8b9f-0a531f0e7d6c)

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

Commit messages:
 - Removed trailing whitespace
 - Corrected issue ID: 8337974
 - JDK-8337974 Implementing ChannelInputStream::skip using splice on Linux and C-loops elsewhere

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

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

From alanb at openjdk.org  Wed Aug  7 11:23:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 7 Aug 2024 11:23:31 GMT
Subject: RFR: 8337966: Verify statx permissions
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <Krg0Y-Zogzd2tJ40vjETEdXxW1952c-SHfdI2d_r_cs=.5070756b-d12e-4d5c-af70-5216e9df0cca@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

I've moved the JBS issue to the right place and changed the description to make it clear what this issue is about. Would it be possible to change the PR title to match the description.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2273236706

From bpb at openjdk.org  Wed Aug  7 15:34:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v3]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <vfXDNsXH6ayjYSajCqItlH5E0k9DXhNrcRHhQboKF4Y=.03249396-b128-46e2-bf01-3373de8c3f78@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: Removed dependency of libjava on headers in libnio/ch

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/48519737..7e8a02e3

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

  Stats: 305 lines in 17 files changed: 141 ins; 151 del; 13 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  Wed Aug  7 15:34:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:34:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
Message-ID: <7wiOsnhOQIZL7-64yFcJYwWS95gOM7NeaU3IcOZUCUo=.b65933fd-ce5c-4c81-8f39-395f4b4ee33b@github.com>

On Fri, 26 Jul 2024 19:40:24 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: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

As part of 7e8a02e, the `nio_util.h` header files were modified. One unused symbolic constant was removed. Symbolic constants used in only one file were moved to that file. Function declarations that were only used where the function is defined were removed. Function declarations used in only one file other than the one where the function is defined were moved to an `extern` in that file. On Unix, one function declaration used in three files was moved to a new header file `Net.h`.

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

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

From bpb at openjdk.org  Wed Aug  7 15:59:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@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 incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - 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:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/7e8a02e3..e28a4f57

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

  Stats: 23454 lines in 774 files changed: 12481 ins; 7665 del; 3308 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  Wed Aug  7 15:59:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@github.com>
 <SwXug6F4BisDdJjJs1Wel3evwd0AbnYyWS-1sL_sjvs=.3a66f702-9a2f-4ab1-8932-59208c3871c0@github.com>
 <BiQ_TBNl7VkHlTgdLT6pjZCoVEkpjwgynx-ZT0b51Aw=.3a6df22f-a074-40a6-8291-c2f4452980a0@github.com>
Message-ID: <pDyI_GgnI1YL8jKxJm8g8ffaF7vWPMXjRgG_TElQhfI=.d93950b5-c588-49d3-82ea-901cf6d158aa@github.com>

On Mon, 5 Aug 2024 15:37:46 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> make/modules/java.base/lib/CoreLibraries.gmk line 57:
>> 
>>> 55:     OPTIMIZATION := HIGH, \
>>> 56:     EXTRA_HEADER_DIRS := \
>>> 57:         libnio/ch, \
>> 
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this. 
>> 
>> Maybe the libnio/ch code also should move to libjava? Or, perhaps at least the header files. Conceptually, I'd feel better about having a dependency on libnio as a "downstream" library on libjava source code, than the other way around.
>
>> This will introduce a source code dependency from libjava to libnio. It might be the correct thing to do, but I just want to highlight this.
> 
> I'll look into improving it.

Fixed in 7e8a02e

>> make/modules/java.base/lib/CoreLibraries.gmk line 71:
>> 
>>> 69:         -framework Foundation \
>>> 70:         -framework SystemConfiguration, \
>>> 71:     LIBS_windows := advapi32.lib ole32.lib shell32.lib version.lib mswsock.lib ws2_32.lib, \
>> 
>> Please keep libraries alphabetically sorted.
>
> Thanks for pointing this out; I will fix it.

Fixed in 7e8a02e.

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

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

From ihse at openjdk.org  Wed Aug  7 15:59:15 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 7 Aug 2024 15:59:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>

On Wed, 7 Aug 2024 15:56:06 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 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

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, \

Are these libraries still required to build libnio, or can they be removed from that library now?

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

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

From bpb at openjdk.org  Wed Aug  7 16:03:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:03:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
Message-ID: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>

On Wed, 7 Aug 2024 15:56:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 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
>
> 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, \
> 
> Are these libraries still required to build libnio, or can they be removed from that library now?

I will check. Thanks for noticing it.

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

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

From bpb at openjdk.org  Wed Aug  7 16:06:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:06:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
Message-ID: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>

On Wed, 7 Aug 2024 16:00:26 GMT, Brian Burkhalter <bpb 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, \
>> 
>> Are these libraries still required to build libnio, or can they be removed from that library now?
>
> I will check. Thanks for noticing it.

`CoreServices` is still necessary.

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

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

From duke at openjdk.org  Wed Aug  7 16:26:32 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Aug 2024 16:26:32 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
Message-ID: <fnYlWVxj7flc8pYoDvreI--qmxs4OXl3m7RjBNWIpyE=.cf0d9129-5f55-4f1c-ac60-39826a78e9f7@github.com>

On Wed, 7 Aug 2024 09:36:46 GMT, Markus KARG <duke at openjdk.org> wrote:

> # Targets
> 
> The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
> 
> A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.
> 
> An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.
> 
> 
> # Non-Targets
> 
> It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
> 
> It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.
> 
> It is not a target to improve other source types besides pipes and sockets.
> 
> 
> # Description
> 
> What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.
> 
> For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.
> 
> Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.
> 
> 
> # Implementation
> 
> The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.
> 
> Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
> 1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
> 2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferred from the source into the OS kernel, nor from the OS kernel into n...

@bplb Kindly asking for review! :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2273851228

From bpb at openjdk.org  Wed Aug  7 16:26:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 16:26:32 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <fnYlWVxj7flc8pYoDvreI--qmxs4OXl3m7RjBNWIpyE=.cf0d9129-5f55-4f1c-ac60-39826a78e9f7@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <fnYlWVxj7flc8pYoDvreI--qmxs4OXl3m7RjBNWIpyE=.cf0d9129-5f55-4f1c-ac60-39826a78e9f7@github.com>
Message-ID: <h-a1lXiAja-hPj0AWeWiE0zD4LjW8onLuZ7gw7_IL9k=.58547e1b-74d1-4a83-8aa3-b8854e8f1326@github.com>

On Wed, 7 Aug 2024 16:22:07 GMT, Markus KARG <duke at openjdk.org> wrote:

> @bplb Kindly asking for review! :-)

It's JVMLS and OpenJDK Committer's Workshop this week and the review will take some care and time.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2273854532

From duke at openjdk.org  Wed Aug  7 16:52:30 2024
From: duke at openjdk.org (Markus KARG)
Date: Wed, 7 Aug 2024 16:52:30 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <h-a1lXiAja-hPj0AWeWiE0zD4LjW8onLuZ7gw7_IL9k=.58547e1b-74d1-4a83-8aa3-b8854e8f1326@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <fnYlWVxj7flc8pYoDvreI--qmxs4OXl3m7RjBNWIpyE=.cf0d9129-5f55-4f1c-ac60-39826a78e9f7@github.com>
 <h-a1lXiAja-hPj0AWeWiE0zD4LjW8onLuZ7gw7_IL9k=.58547e1b-74d1-4a83-8aa3-b8854e8f1326@github.com>
Message-ID: <xFsRqz-JlxLoQSXvdx2kKDzv78eaGKJicxqUgQwttDQ=.078c28f6-ae12-421e-9fb5-4295b355ca70@github.com>

On Wed, 7 Aug 2024 16:24:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > @bplb Kindly asking for review! :-)
> 
> It's JVMLS and OpenJDK Committer's Workshop this week and the review will take some care and time.

No need to hurry, and have much fun at the summit and workshop! :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2273899668

From bpb at openjdk.org  Wed Aug  7 18:16:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 18:16:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
Message-ID: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>

On Wed, 7 Aug 2024 16:03:33 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check. Thanks for noticing it.
>
> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).

The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:

- ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
- ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

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

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

From bpb at openjdk.org  Wed Aug  7 18:24:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 7 Aug 2024 18:24:34 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <xFsRqz-JlxLoQSXvdx2kKDzv78eaGKJicxqUgQwttDQ=.078c28f6-ae12-421e-9fb5-4295b355ca70@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
 <fnYlWVxj7flc8pYoDvreI--qmxs4OXl3m7RjBNWIpyE=.cf0d9129-5f55-4f1c-ac60-39826a78e9f7@github.com>
 <h-a1lXiAja-hPj0AWeWiE0zD4LjW8onLuZ7gw7_IL9k=.58547e1b-74d1-4a83-8aa3-b8854e8f1326@github.com>
 <xFsRqz-JlxLoQSXvdx2kKDzv78eaGKJicxqUgQwttDQ=.078c28f6-ae12-421e-9fb5-4295b355ca70@github.com>
Message-ID: <id0dkKweB9jtT6YeZtiIBr6E_MPoDWbxXJIG3Q2UrBQ=.d13bedc2-d4f0-48e5-95a2-df3ce57e6ab4@github.com>

On Wed, 7 Aug 2024 16:50:04 GMT, Markus KARG <duke at openjdk.org> wrote:

> No need to hurry,

Indeed, it's four months until rampdown.

> and have much fun at the summit and workshop! :-)

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2274064406

From dfuchs at openjdk.org  Thu Aug  8 09:19:41 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 09:19:41 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
Message-ID: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>

On Wed, 7 Aug 2024 15:59:14 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 with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge
>  - 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

Disclaimer: I have not tried to understand the proposed change in details. However I have spotted a small oddity.

src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:

> 152:     static {
> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
> 154:     }

I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

src/java.base/windows/native/libjava/IOUtil.c line 37:

> 35: #include "nio.h"
> 36: #include "nio_util.h"
> 37: /* #include "net_util.h" */

Is this change intended or is this a left over from some experimentation?

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

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2227299000
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709024031
PR Review Comment: https://git.openjdk.org/jdk/pull/20317#discussion_r1709029492

From ihse at openjdk.org  Thu Aug  8 12:20:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 8 Aug 2024 12:20:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
Message-ID: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>

On Wed, 7 Aug 2024 18:13:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> `CoreServices` is still necessary ([Uniform Type Identifier](https://developer.apple.com/documentation/uniformtypeidentifiers)s).
>
> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
> 
> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```

And pthread?

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

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

From bpb at openjdk.org  Thu Aug  8 14:35:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
Message-ID: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>

On Thu, 8 Aug 2024 12:18:04 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> The Windows libs are also still required for `TransmitFile` and `WSAGetLastError`:
>> 
>> - ```mswsock.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol TransmitFile```
>> - ```ws2_32.lib: FileDispatcherImpl.obj : error LNK2019: unresolved external symbol __imp_WSAGetLastError```
>
> And pthread?

I will check.

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

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

From bpb at openjdk.org  Thu Aug  8 14:35:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 14:35:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
Message-ID: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>

On Thu, 8 Aug 2024 09:11:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - 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
>
> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
> 
>> 152:     static {
>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>> 154:     }
> 
> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?

I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

> src/java.base/windows/native/libjava/IOUtil.c line 37:
> 
>> 35: #include "nio.h"
>> 36: #include "nio_util.h"
>> 37: /* #include "net_util.h" */
> 
> Is this change intended or is this a left over from some experimentation?

It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

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

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

From dfuchs at openjdk.org  Thu Aug  8 15:19:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 15:19:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>

On Thu, 8 Aug 2024 14:32:25 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/java/net/Inet6AddressImpl.java line 154:
>> 
>>> 152:     static {
>>> 153:         jdk.internal.loader.BootLoader.loadLibrary("net");
>>> 154:     }
>> 
>> I am curious about this change - wouldn't it be needed in Inet4AddressImpl as well?
>
> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?

It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

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

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

From bpb at openjdk.org  Thu Aug  8 16:12:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:12:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
Message-ID: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>

On Thu, 8 Aug 2024 15:16:14 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I have not seen any failures in CI testing. Is there a specific test that would reveal whether this is a problem?
>
> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.

How would you suggest testing this?

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

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

From dfuchs at openjdk.org  Thu Aug  8 16:24:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
Message-ID: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>

On Thu, 8 Aug 2024 16:09:55 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> It may be because we have no IPv4 only machine in the CI? It seems strange that IPv6 is treated differently than IPv4 in that respect.
>
> How would you suggest testing this?

I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

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

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

From bpb at openjdk.org  Thu Aug  8 16:24:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:24:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
Message-ID: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>

On Thu, 8 Aug 2024 16:18:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> How would you suggest testing this?
>
> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.

I'll have to investigate.

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

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

From bpb at openjdk.org  Thu Aug  8 16:31:37 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:31:37 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
Message-ID: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>

On Thu, 8 Aug 2024 14:31:09 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> And pthread?
>
> I will check.

`pthread` is still needed:

open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

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

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

From dfuchs at openjdk.org  Thu Aug  8 16:42:38 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 8 Aug 2024 16:42:38 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
Message-ID: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>

On Thu, 8 Aug 2024 16:21:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I don't know - you added that code to Inet6AddressImpl - so presumably a test was failing without that code?
>> Which test was that? It wasn't obvious to me that adding code to load the "net" library would be required here.
>
> I'll have to investigate.

Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 

InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.

And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.

I am not an expert on library loading though :-(

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

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

From bpb at openjdk.org  Thu Aug  8 16:51:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 16:51:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
Message-ID: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>

On Thu, 8 Aug 2024 16:39:33 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'll have to investigate.
>
> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
> 
> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
> 
> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
> 
> I am not an expert on library loading though :-(

Thanks for the suggestions. I will look into it.

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

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

From bpb at openjdk.org  Thu Aug  8 21:28:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 8 Aug 2024 21:28:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
Message-ID: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>

On Thu, 8 Aug 2024 16:48:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Possibly - if you made isIPv6Supported() in InetAddress.c return false, you might be able to see the issue in the same test that you observed failing without your change. 
>> 
>> InetAddress has a static block that will load the "net" library, and an other static block that will create the InetAddressImpl. It's a bit curious because I would expect the block that loads the "net" library to be executed before.
>> 
>> And the only place where I see Inet6AddressImpl being used is in that second static block in InetAddress.
>> 
>> I am not an expert on library loading though :-(
>
> Thanks for the suggestions. I will look into it.

Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:

java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)

This is on Unix (Linux, macOS) only, not on Windows.

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

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

From dfuchs at openjdk.org  Fri Aug  9 09:08:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 09:08:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
Message-ID: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>

On Thu, 8 Aug 2024 21:23:58 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Thanks for the suggestions. I will look into it.
>
> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
> 
> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
> 
> This is on Unix (Linux, macOS) only, not on Windows.

OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.

            var impl = new Inet6AddressImpl();

It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

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

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

From ihse at openjdk.org  Fri Aug  9 09:43:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 9 Aug 2024 09:43:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
Message-ID: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>

On Thu, 8 Aug 2024 16:29:18 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I will check.
>
> `pthread` is still needed:
> 
> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'

Ok then. Thank you for your thorough checking!

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

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

From bpb at openjdk.org  Fri Aug  9 15:08:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:08:42 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <OrZP7GUaZLU0t-4ivqKMGZFVFq4qYtAdbaeWNc9FQ88=.d3479e27-23c1-4ece-beb6-5607c2e32962@github.com>
 <Yt9i_65eIs601GREAa-qNdnS4_XPOfKyNE0I-oX-pp4=.07a38476-724e-4bab-8caf-c8da7edda1c6@github.com>
 <P35iqF_IyLkqkNbBrdWpuvNqfLQp2n-Es2LkK8HIECw=.529a2848-e65d-4bb7-b18d-628c2b3abbc3@github.com>
 <3svWg4OOtXThIl3WVV4kwOafudlnHmlREaqFSAfR9mI=.a9ce7e75-3275-4ab1-bbf7-f75f91788a6d@github.com>
 <v9EWejZCkBwRGhgfKKdOetI97OVPY0iJTNRwU7hVduc=.b01458ec-7d81-4106-b1cc-6afd2386e4c3@github.com>
 <HyrQmrzQq9myZPqB-8lL4YOrACVeYok4uigsEZVnRTs=.21a95877-9510-4d2e-8bcb-776208a2f8f1@github.com>
 <VnTkRAzUaGsFv3VihUxdyyE7r7lo4RGBE6DDSqKWhgQ=.c9a7f7ed-7116-448d-aaee-4c8c8a4f7447@github.com>
 <ym1ehC2spLARIgv3ALJkdINukIEgJ4rTjt9EvXnvj5A=.6169748e-ce16-4b5c-a865-6d64f62940f4@github.com>
Message-ID: <mrZPe0z2rhoHe3rKhS5bqy6-2wZCFJrUDDQ_ktdUnu4=.7e35f805-21e1-48ca-b819-3fd9bc542485@github.com>

On Fri, 9 Aug 2024 09:40:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> `pthread` is still needed:
>> 
>> open/src/java.base/unix/native/libjava/nio/ch/NativeThread.c:83: error: undefined reference to 'pthread_kill'
>
> Ok then. Thank you for your thorough checking!

Thank you for suggesting it!

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

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

From bpb at openjdk.org  Fri Aug  9 15:11:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 15:11:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
Message-ID: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>

On Fri, 9 Aug 2024 09:05:49 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Without loading libnet in Inet6AddressImpl, the test java/net/InetAddress/NullCharInHostnameDriver.java fails with UnsatisfiedLinkError:
>> 
>> java.lang.UnsatisfiedLinkError: 'java.net.InetAddress[] java.net.Inet6AddressImpl.lookupAllHostAddr(java.lang.String, int)'
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Native Method)
>> 	at java.base/java.net.Inet6AddressImpl.lookupAllHostAddr(Inet6AddressImpl.java:52)
>> 	at java.base/java.net.NullCharInHostname.main(NullCharInHostname.java:37)
>> 
>> This is on Unix (Linux, macOS) only, not on Windows.
>
> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
> 
>             var impl = new Inet6AddressImpl();
> 
> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?

Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

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

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

From dfuchs at openjdk.org  Fri Aug  9 15:51:36 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 9 Aug 2024 15:51:36 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
Message-ID: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>

On Fri, 9 Aug 2024 15:09:08 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> OK, this test uses a private API to create an instance of Inet6AddressImpl; This explain why in this test Inet6AddressImpl gets loaded before InetAddress.
>> 
>>             var impl = new Inet6AddressImpl();
>> 
>> It should never happen outside of this test. Now the tricky question: what in your proposed changes caused "net" not to be loaded before the test created new Inet6AddressImpl(); ?
>
> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.

I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.

In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.

The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.

So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

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

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

From bpb at openjdk.org  Fri Aug  9 16:01:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 16:01:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
Message-ID: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>

On Fri, 9 Aug 2024 15:47:07 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Loading "net" was removed from IOUtil so I am thinking that IOUtil must have been initialized somewhere before constructing Inet6AddressImpl, but I've not identified where just yet.
>
> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
> 
> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
> 
> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
> 
> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.

Thanks. I'll try adding it to the test.

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

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

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@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: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20317/files
  - new: https://git.openjdk.org/jdk/pull/20317/files/e28a4f57..f57b6f13

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

  Stats: 11 lines in 3 files changed: 4 ins; 5 del; 2 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 Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
 <eIu5Tijrziidj-gGQ62Rj221K7YZagkqDSzqil0bgVk=.c00978c4-4c83-4779-b774-069cb3711811@github.com>
 <SUMpZIiwIn0AwAgk0DeQabqr1bvc_rbKVgGCp5AljTo=.524c66c5-c293-47df-b9f9-fe93272d5dbc@github.com>
 <2qxPna1f2Z5bLWKo4e302rK-ilKKtSa48qw62PKFOdU=.12cdf575-2a46-43d0-896b-d363fbf94acc@github.com>
 <fzWiAyjb79KDakXOCiWypGx2T_zwZFSqOslHYPnKHH0=.957a21ca-e2c7-4ca6-9907-249ee83dfb08@github.com>
 <uRxY93sZR5pLjDAz3Mr7aqBs49WlRxJz2m9zqhf-m4E=.48e8fdf1-fff5-4b0a-93ff-211781580819@github.com>
 <hAoCaRlDcgwxRP6dU-hRludNiLY-X_26Pa5EwLCeEYo=.462f95c8-7a43-4733-9679-6a1a9c6e879c@github.com>
 <tcqxKkyaWyoahFSab9fo-pEmijLf-e30cF0
 UGBdwP4A=.63a4cc04-e92d-419b-9f10-7b4918fc223f@github.com>
 <ewBEFtyyzXm9KDbu9xzEAwo1xuPNhL9PJDTuLwLJP8Y=.9e5c8ef3-f51b-484e-989d-b8507a7fdf90@github.com>
 <aq18fO2SC1t_PMgNF8zX1gxjPZvLZljsLe1SCVNhzSE=.aa134c08-3740-4b08-afc2-244d6d2db182@github.com>
 <kWuaxuPTlbHyj1xGdl4j6kvnvxpQUeUdQjsfM-Dx8fA=.cb09c1bb-63ca-41d8-a753-ece8601eb5f8@github.com>
 <eSowRvzxxpfIxVy3MmfC9pxFlrY73wBgPLrbWbw7E5o=.0e9d3a5f-c16e-4f12-bdf5-94a58ba2f84c@github.com>
Message-ID: <3uXhrkj0U16cG1Lf-JGCkagHJD0MLFcbcEI6ZsBxBiw=.774775bc-3ddf-4882-872a-29292daea008@github.com>

On Fri, 9 Aug 2024 15:58:50 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I see. Inet6AddressImpl and Inet4AddressImpl are symetric classes implementing InetAddressImpl. Both will make native calls to the "net" library - so both require the library to be loaded.
>> 
>> In the JDK, these two classes are only loaded by InetAddress, after the "net" library has been loaded.
>> 
>> The test test java/net/InetAddress/NullCharInHostnameDriver.java seems to be an outlier (@AlekseiEfimov ?) which for some reason uses a private API (the test is injected in java.base) and create a new instance of Inet6AddressImpl before InetAddress is loaded. This is why without this change to Inet6AddressImpl we get the UnsatisfiedLinkError. We would have gotten the same from Inet4AddressImpl if the test had first required access to Inet4AddressImpl instead.
>> 
>> So it seems that we should either add the call to load the "net" library to both Inet6AddressImpl and Inet4AddressImpl for symetry (there doesn't seem to be any reason why Inet6AddressImpl would be preferred in this respect),  or remove this call from Inet6AddressImpl and add it to the test instead. Adding the call to jdk.internal.loader.BootLoader.loadLibrary("net"); in the test should work since the actual test class (NullCharInHostname.java) is injected in java.base.
>
> Thanks. I'll try adding it to the test.

In f57b6f1 I reverted the Inet6AddressImpl change and added the "net" library load to NullCharInHostname.java. With this change the test passed on Unix.

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

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

From bpb at openjdk.org  Fri Aug  9 17:59:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 17:59:12 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v4]
In-Reply-To: <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <Dvy1OfidTf-jrbsQskqzmuJDX2ORBg_MmSQfG4GU4rY=.46523ea5-354e-44c5-9434-7b429642fbde@github.com>
 <lVxf4Y-L_gd5QZGe4eEHOCXL7WUYneIFh41Y8NspzZ4=.3f9871f8-d26d-46d8-8c44-88e64c9e29df@github.com>
 <QJfZQB_4rW8hixWes1TpPD9rn1sVS0ma5K19Sbe9fwg=.dabaed1d-ed94-4317-82d4-0b20feb951a3@github.com>
Message-ID: <a7W6SwWulATRx-mtErRTwW-ZznoeuYwXKDIwzUBoVys=.afa3463d-053c-4340-adb0-17139ff35391@github.com>

On Thu, 8 Aug 2024 14:33:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/native/libjava/IOUtil.c line 37:
>> 
>>> 35: #include "nio.h"
>>> 36: #include "nio_util.h"
>>> 37: /* #include "net_util.h" */
>> 
>> Is this change intended or is this a left over from some experimentation?
>
> It could be leftover. There was a lot of wrangling in this. Probably line 37 could just be deleted.

Line 37 deleted in f57b6f1.

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

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

From bpb at openjdk.org  Fri Aug  9 21:25:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 9 Aug 2024 21:25:43 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>
 <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>
Message-ID: <CMEneLagY0Ru5EeggWc3pS5swtt6RUP5573Wx_hsGvI=.56996229-57ca-4c1f-ade6-502f99ab2e3f@github.com>

On Fri, 26 Jul 2024 21:34:07 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use.
> 
> Maybe `NIOUtil` should be `NetUtil` as its methods appear to be invoked only by classes involved in networking?

Another option is `NIONetUtil` but the `NIO` prefix is redundant with the package name.

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

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

From dfuchs at openjdk.org  Mon Aug 12 15:14:34 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 12 Aug 2024 15:14:34 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: <jeA6snOedvNP-wP-5Aw4RWMKAqJZ_SGFOZYTHCrDoNE=.27f8f41e-0637-446c-b2e7-7b0b98fa73a0@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

The changes to the java/net code look OK to me now. Thanks Brian. I am approving these changes - but please also get a Reviewer for the NIO and build side of these.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233341338

From ihse at openjdk.org  Mon Aug 12 15:35:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 12 Aug 2024 15:35:35 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: <be3LT-XgLWSRAmNaJgWOEwhpTXZsHDYvrO1T8tg4tsw=.1f73b219-19d7-4222-8163-1e71d1de574f@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

Build changes look good.

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20317#pullrequestreview-2233398100

From alanb at openjdk.org  Mon Aug 12 15:48:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 12 Aug 2024 15:48:33 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: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@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

I plan to review this, please do not integrate this change until I get time to make sure that the placement and naming is workable in these areas.

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

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

From bpb at openjdk.org  Mon Aug 12 17:14:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 12 Aug 2024 17:14:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v5]
In-Reply-To: <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <1ddJi8U9YT2NoNXmgUGnUHXBD7brqNzPUytrQ-RluvI=.d6bafcef-8a76-4b75-af15-09e401e1bdec@github.com>
 <SpMnbnugG9ZKlNltWcPJ9_fBoUbYST6O70QgpNqNKsE=.702b4843-4d2a-4216-a659-b88085af6b39@github.com>
Message-ID: <oaXC9bmYWzhk0cmHn2O7K8SySeDsjNCsK-3h790GtTs=.20455ccb-59a5-4264-9818-072ae6d42fc4@github.com>

On Mon, 12 Aug 2024 15:46:13 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> please do not integrate this change until I get time

Sure, of course I will not.

Thanks to @magicus and @dfuch for helping to make it better.

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

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

From alanb at openjdk.org  Tue Aug 13 10:31:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 10:31:57 GMT
Subject: RFR: 8338142: (dc) DatagramChannelImpl.blockingReceive can use
 untimed-park when no timeout set
Message-ID: <GJyF4-tnYiqIiYNKh5KUVlx388auS2gRJ77RgxHkSQY=.045c9dfa-cf55-4d54-af0c-0896f2432b6e@github.com>

When no timeout is set, DatagramSocket.receive on a virtual thread is currently implemented as a timed receive and a timeout of Long.MAX_VALUE. This came about when this code was changed to avoid pinning issues when calling this method on a virtual thread. It would be better to use an untimed-park for this case, and this would also avoid a long standing issue with overflow in STPE (JDK-8338104).

All tests in tier2 (which has the tests for this API) are passing on all platforms. I don't propose to add further tests at this time.

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

Commit messages:
 - Merge
 - Merge
 - Initial commit

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

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

From alanb at openjdk.org  Tue Aug 13 11:10:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 11:10:48 GMT
Subject: RFR: JDK-8337974 - ChannelInputStream::skip can use splice (linux)
In-Reply-To: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
References: <MEN1AimCe7UIPrljI4kqDxHYCeHgBAoEtRenGS1Y784=.271f94e0-cea6-4774-95a8-5d9f194cb6df@github.com>
Message-ID: <ewZ5JgD5ew1OWC999ZiZCBkVm8nGlAElVdogQGhM2is=.012e005f-158b-4c93-9409-1c0e66923c6e@github.com>

On Wed, 7 Aug 2024 09:36:46 GMT, Markus KARG <duke at openjdk.org> wrote:

> # Targets
> 
> The major target of this issue is to reduce execution time of `ChannelInputStream::skip(long)`. In particular, make `skip(n)` run noticable faster than `read(new byte[n])` on pipes and sockets in the optimal case, but don't run noticable slower in the worst case.
> 
> A side target of this issue is to provide unit testing for `ChannelInputStream::skip(long)`. In particular, provide unit testing for files, pipes and sockets.
> 
> An appreciated benefit of this issue is reduced resource consumption (in the sense of CPU cycles, Java Heap, power consumption, CO2 footprint, etc.) of `ChannelInputStream::skip(long)`. Albeit, as it is not a target, this was not acitvely monitored.
> 
> 
> # Non-Targets
> 
> It is not a target to improve any other methods of the mentioned or any other class. Such changes should go in separate issues.
> 
> It is not a target to add any new *public* APIs. The public API shall be kept unchanged. All changes implied by the current improvement shall be purely *internal* to OpenJDK.
> 
> It is not a target to improve other source types besides pipes and sockets.
> 
> 
> # Description
> 
> What users expect from `InputStream::skip`, besides comfort, is "at least some" measurable benefit over `InputStream::read`. Otherwise skipping instead of reading makes no sense to users.
> 
> For files, OpenJDK already applies an effective `seek`-based optimization. For pipes and sockets, benefits were neglectible so far, as `skip` more or less was simply an alias for `read`.
> 
> Hence, this issue proposes optimized implementations for `ChannelInputStream::skip` in the pipes and sockets cases.
> 
> 
> # Implementation
> 
> The abstract idea behind this issue is to prevent transmission of skipped data into the JVM's on-heap memory in the pipes and socket cases. As a Java application obviously is not interested in skipped data, copying it into the Java heap is a waste of both, time and heap, and induces (albeit neglectible) GC stress without any benefit.
> 
> Hence, this pull request changes the implementation of `ChannelInputStream::skip` in the following aspects:
> 1. On *all* operating systems, for pipe and socket channels, `skip` is implemented in C. While the data *still is* transferred form the source into the OS kernel and from the OS kernel into the JVM's off-heap memory, it is *not* transferred into the JVM's on-heap memory.
> 2. For *Linux* pipes only, `splice` is used with `/dev/null` as the target. Data is neither transferred from the source into the OS kernel, nor from the OS kernel into n...

I think the Socket and Pipe changes need to be separated and the merits of each discussed separately.

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.

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

PR Comment: https://git.openjdk.org/jdk/pull/20489#issuecomment-2285981102

From dfuchs at openjdk.org  Tue Aug 13 12:57:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 13 Aug 2024 12:57:48 GMT
Subject: RFR: 8338142: (dc) DatagramChannelImpl.blockingReceive can use
 untimed-park when no timeout set
In-Reply-To: <GJyF4-tnYiqIiYNKh5KUVlx388auS2gRJ77RgxHkSQY=.045c9dfa-cf55-4d54-af0c-0896f2432b6e@github.com>
References: <GJyF4-tnYiqIiYNKh5KUVlx388auS2gRJ77RgxHkSQY=.045c9dfa-cf55-4d54-af0c-0896f2432b6e@github.com>
Message-ID: <A4qqvSg6ep8oRRM2dxiF1HDLWdFKXIEUsTDyFHpRs0Q=.56c0ed31-87d9-4057-b28d-ec3d1b54aa33@github.com>

On Tue, 13 Aug 2024 10:22:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When no timeout is set, DatagramSocket.receive on a virtual thread is currently implemented as a timed receive and a timeout of Long.MAX_VALUE. This came about when this code was changed to avoid pinning issues when calling this method on a virtual thread. It would be better to use an untimed-park for this case, and this would also avoid a long standing issue with overflow in STPE (JDK-8338104).
> 
> All tests in tier2 (which has the tests for this API) are passing on all platforms. I don't propose to add further tests at this time.

Look reasonable to me

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20565#pullrequestreview-2235479382

From alanb at openjdk.org  Tue Aug 13 16:08:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 13 Aug 2024 16:08:54 GMT
Subject: Integrated: 8338142: (dc) DatagramChannelImpl.blockingReceive can use
 untimed-park when no timeout set
In-Reply-To: <GJyF4-tnYiqIiYNKh5KUVlx388auS2gRJ77RgxHkSQY=.045c9dfa-cf55-4d54-af0c-0896f2432b6e@github.com>
References: <GJyF4-tnYiqIiYNKh5KUVlx388auS2gRJ77RgxHkSQY=.045c9dfa-cf55-4d54-af0c-0896f2432b6e@github.com>
Message-ID: <5ALuVDzxlBYgDhd-G0bW3dxMRpIK-OyJ78nHXpYc3SU=.942e919b-e806-4c15-b1ae-6b8f29f4fbf5@github.com>

On Tue, 13 Aug 2024 10:22:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> When no timeout is set, DatagramSocket.receive on a virtual thread is currently implemented as a timed receive and a timeout of Long.MAX_VALUE. This came about when this code was changed to avoid pinning issues when calling this method on a virtual thread. It would be better to use an untimed-park for this case, and this would also avoid a long standing issue with overflow in STPE (JDK-8338104).
> 
> All tests in tier2 (which has the tests for this API) are passing on all platforms. I don't propose to add further tests at this time.

This pull request has now been integrated.

Changeset: 58b95705
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/58b957054437edee7d0abc365133985ac30a6af4
Stats:     13 lines in 1 file changed: 7 ins; 2 del; 4 mod

8338142: (dc) DatagramChannelImpl.blockingReceive can use untimed-park when no timeout set

Reviewed-by: dfuchs

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

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

From bpb at openjdk.org  Tue Aug 13 19:18:55 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 13 Aug 2024 19:18:55 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: <jdyjjNH-sZpEERM94VE0wCsJyfkVRD9FHzwIIxB7hO8=.f825823a-cb13-454f-95d4-56d13d255c36@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-2286960850

From dfuchs at openjdk.org  Wed Aug 14 09:43:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 14 Aug 2024 09:43:28 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v4]
In-Reply-To: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
Message-ID: <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>

> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
> 
> The most common source of intermittent failures are:
> 
>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>  - failure to disconnect due to interference of concurrent running tests
>  - failure due to reception of unexpected stray datagrams
> 
> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.

Daniel Fuchs 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:

 - Merge branch 'master' into JDK-8335771
 - Review feedback
 - Review feedback: avoid continue
 - Review feedback
 - 8335771

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20050/files
  - new: https://git.openjdk.org/jdk/pull/20050/files/64fccfb6..14c607fe

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

  Stats: 45890 lines in 1489 files changed: 25205 ins; 14342 del; 6343 mod
  Patch: https://git.openjdk.org/jdk/pull/20050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20050/head:pull/20050

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

From alanb at openjdk.org  Thu Aug 15 13:44:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 13:44:53 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <gntQDJh_BSEeKUG2glzRexHBIfb9bgTwZYtKYDJRe1Q=.bbf51f5b-9ded-40f7-a2bb-5ccc37067fb9@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
 <gntQDJh_BSEeKUG2glzRexHBIfb9bgTwZYtKYDJRe1Q=.bbf51f5b-9ded-40f7-a2bb-5ccc37067fb9@github.com>
Message-ID: <OTdWZ4ZicR4rVPBnJzKvAwjvnPCMyazXWh7ceEkzjbI=.e3c31336-f066-49f9-b075-0a12b0a3dd1c@github.com>

On Thu, 18 Jul 2024 17:25:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Vladimir Petko 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:
>> 
>>  - review comments: add ifdef, rename function
>>  - Merge branch 'master' into JDK-8336529
>>  - typo: remove extra whitespace
>>  - fix typo: missing whitespace
>>  - try to use 64 bit function if sizeof(time_t) > 4
>
> I don't object to putting in a patch to deal with this porting challenge, we just need to make sure that it don't disrupt other builds or platforms.  To that end, I think it would be better to only compile in lookup_time_t_function on Linux, you can put it after statx_wrapper. I assume you can reduce it to:
> 
>     if (sizeof(time_t) > 4) {
>         return dlsym(RTLD_DEFAULT, symbol64);
>     } else {
>         return dlsym(RTLD_DEFAULT, symbol32);
>     }
> 
> In Java_sun_nio_fs_UnixNativeDispatcher_init think you can use something like this to avoid changing what is compiled in on other platforms. 
> 
> #if defined(__linux)
>     my_futimesat_func = ..
> #elif defined(_ALLBSD_SOURCE)
>     my_futimesat_func = ..
> #else
>    my_futimesat_func = ..
> #endif

> @AlanBateman I am still a bit afraid of breaking the non-glibc armhf port. E.g. musl does not provide 64 bit symbol, but instead has `__futimens_time32`.
> This is a bit longer, but does not break for musl.

I don't have a sense on who builds arm32 in this configuration but what you suggest looks okay.

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2291290297

From alanb at openjdk.org  Thu Aug 15 14:13:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 14:13:53 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v4]
In-Reply-To: <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
Message-ID: <3d3WH-SOlr-5Y6188pc7xtJI2IBMvwzyfjvlKeRPikw=.8954a33f-f62c-46e5-b4fd-279e5deda619@github.com>

On Wed, 14 Aug 2024 09:43:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
>> 
>> The most common source of intermittent failures are:
>> 
>>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>>  - failure to disconnect due to interference of concurrent running tests
>>  - failure due to reception of unexpected stray datagrams
>> 
>> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.
>
> Daniel Fuchs 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:
> 
>  - Merge branch 'master' into JDK-8335771
>  - Review feedback
>  - Review feedback: avoid continue
>  - Review feedback
>  - 8335771

test/jdk/java/nio/channels/DatagramChannel/AfterDisconnect.java line 67:

> 65:      * may occur. In which case we want to retry the test.
> 66:      */
> 67:     public class BindExceptionOnDisconnect extends BindException {

I assume these interfaces don't need to be public.

test/jdk/java/nio/channels/DatagramChannel/AfterDisconnect.java line 127:

> 125:                 if (i < max -1 && retryOn.test(t)) {
> 126:                     System.out.println("Got " + t + "; will retry");
> 127:                 } else throw t;

What you would think about renaming this to "testWithRetry" so that it's clearer what it does? It could move up to the be the interface declarations so it is easier to find.

test/jdk/java/nio/channels/DatagramChannel/Connect.java line 128:

> 126:                 // To avoid this, when on macOS, we preemptively bind `dc` to the
> 127:                 // specific address instead of letting it bind to the wildcard.
> 128:                 if (Platform.isOSX()) {

Okay, but does feel like we are working around a macOS bug.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1718453128
PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1718455945
PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1718457881

From alanb at openjdk.org  Thu Aug 15 14:23:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 15 Aug 2024 14:23:53 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v4]
In-Reply-To: <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
Message-ID: <6tYI8qQTzPXBLppPiq2iigbu1RbLdUV9Z4bG_2TWfEk=.93013b45-47bd-45d7-9dc5-2262e449c6bb@github.com>

On Wed, 14 Aug 2024 09:43:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
>> 
>> The most common source of intermittent failures are:
>> 
>>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>>  - failure to disconnect due to interference of concurrent running tests
>>  - failure due to reception of unexpected stray datagrams
>> 
>> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.
>
> Daniel Fuchs 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:
> 
>  - Merge branch 'master' into JDK-8335771
>  - Review feedback
>  - Review feedback: avoid continue
>  - Review feedback
>  - 8335771

I think this is okay, a bit annoying to see the workarounds for macOS issues but it should help test stability.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20050#pullrequestreview-2240499705

From dfuchs at openjdk.org  Thu Aug 15 14:58:04 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Aug 2024 14:58:04 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v5]
In-Reply-To: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
Message-ID: <qyCXaelb-B9eyygUPgz5Vi6DZRx9pZ1uUnnj-my2IhI=.e0e52482-eb8d-410e-ad46-704a8a9dd955@github.com>

> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
> 
> The most common source of intermittent failures are:
> 
>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>  - failure to disconnect due to interference of concurrent running tests
>  - failure due to reception of unexpected stray datagrams
> 
> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.

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

  Integrated more review feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20050/files
  - new: https://git.openjdk.org/jdk/pull/20050/files/14c607fe..b9c2a7f7

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

  Stats: 38 lines in 1 file changed: 17 ins; 16 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20050.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20050/head:pull/20050

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

From dfuchs at openjdk.org  Thu Aug 15 15:13:52 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Aug 2024 15:13:52 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v4]
In-Reply-To: <3d3WH-SOlr-5Y6188pc7xtJI2IBMvwzyfjvlKeRPikw=.8954a33f-f62c-46e5-b4fd-279e5deda619@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
 <3d3WH-SOlr-5Y6188pc7xtJI2IBMvwzyfjvlKeRPikw=.8954a33f-f62c-46e5-b4fd-279e5deda619@github.com>
Message-ID: <jBm8VC5T-A16oyAvBoiX4O3DOgqtU4lfq6exKjO3I0U=.7517afd7-f3a9-4155-a44c-471a4cdf5728@github.com>

On Thu, 15 Aug 2024 14:10:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Daniel Fuchs 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:
>> 
>>  - Merge branch 'master' into JDK-8335771
>>  - Review feedback
>>  - Review feedback: avoid continue
>>  - Review feedback
>>  - 8335771
>
> test/jdk/java/nio/channels/DatagramChannel/Connect.java line 128:
> 
>> 126:                 // To avoid this, when on macOS, we preemptively bind `dc` to the
>> 127:                 // specific address instead of letting it bind to the wildcard.
>> 128:                 if (Platform.isOSX()) {
> 
> Okay, but does feel like we are working around a macOS bug.

Well - yes it kind of is. But it would be a shame to problem list the test just for this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1718473288

From dfuchs at openjdk.org  Thu Aug 15 15:16:52 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 15 Aug 2024 15:16:52 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v4]
In-Reply-To: <6tYI8qQTzPXBLppPiq2iigbu1RbLdUV9Z4bG_2TWfEk=.93013b45-47bd-45d7-9dc5-2262e449c6bb@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <8Ku5EXmGbA3g58fDMps6SytvFWqVWY7UcxFKlUI60uk=.9d26beee-8604-49ba-bf9e-99ff27814091@github.com>
 <6tYI8qQTzPXBLppPiq2iigbu1RbLdUV9Z4bG_2TWfEk=.93013b45-47bd-45d7-9dc5-2262e449c6bb@github.com>
Message-ID: <EV3xWcc1egr1gUvOAMrAUA1_Nd3kxgpiFG96Q0iXDRg=.f9a2dc85-9d8d-4363-b0fe-fa664aa61738@github.com>

On Thu, 15 Aug 2024 14:20:43 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think this is okay, a bit annoying to see the workarounds for macOS issues but it should help test stability.

Thanks. Unfortunately it doesn't remove these intermittent issues completely but it does reduce their frequency.
You may have to re-review as I pushed a commit including your later feedback.

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

PR Comment: https://git.openjdk.org/jdk/pull/20050#issuecomment-2291498278

From vpetko at openjdk.org  Thu Aug 15 20:23:23 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 15 Aug 2024 20:23:23 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v6]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>

> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
> 
> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
> Using the function directly correctly calls 64 bit versions. 
> 
> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
> 
> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
> 
> Testing:
> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>                                                          1     1     0     0   
>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java
>             ...

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

  lookup symbol as a fallback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20208/files
  - new: https://git.openjdk.org/jdk/pull/20208/files/5cddee11..33436b53

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

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

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

From alanb at openjdk.org  Fri Aug 16 06:51:51 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Aug 2024 06:51:51 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v6]
In-Reply-To: <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
Message-ID: <Ek_9fBB7COpWZ3m2SX8cpM_7P7IgoSoNpEP424IuhVk=.e11ed23c-6efa-442e-97eb-cab3568ab23e@github.com>

On Thu, 15 Aug 2024 20:23:23 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lookup symbol as a fallback

This looks okay. I hope. that maintainers of various ports/builds will be able to quickly check that this change doesn't cause any issues with their builds.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20208#pullrequestreview-2242037461

From alanb at openjdk.org  Fri Aug 16 06:52:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Aug 2024 06:52:49 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v5]
In-Reply-To: <qyCXaelb-B9eyygUPgz5Vi6DZRx9pZ1uUnnj-my2IhI=.e0e52482-eb8d-410e-ad46-704a8a9dd955@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <qyCXaelb-B9eyygUPgz5Vi6DZRx9pZ1uUnnj-my2IhI=.e0e52482-eb8d-410e-ad46-704a8a9dd955@github.com>
Message-ID: <4Q9MSgOQD2fhZ3n_3lOe13_gZ5sh2vOpg9yofMJFtGo=.711216ae-b7f1-42f4-aa88-63ad8c35054a@github.com>

On Thu, 15 Aug 2024 14:58:04 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
>> 
>> The most common source of intermittent failures are:
>> 
>>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>>  - failure to disconnect due to interference of concurrent running tests
>>  - failure due to reception of unexpected stray datagrams
>> 
>> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Integrated more review feedback

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20050#pullrequestreview-2242039214

From duke at openjdk.org  Fri Aug 16 07:05:55 2024
From: duke at openjdk.org (duke)
Date: Fri, 16 Aug 2024 07:05:55 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v6]
In-Reply-To: <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
Message-ID: <wE9kX2L2dDhKw2s-3dU6e1I0us26b1CNStrAC-En9lg=.1eb8589b-0880-4c8e-b8db-8feb24da9b11@github.com>

On Thu, 15 Aug 2024 20:23:23 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lookup symbol as a fallback

@vpa1977 
Your change (at version 33436b53b0a6b378560f806276d941cf48706dbd) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2292942668

From alanb at openjdk.org  Fri Aug 16 07:11:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Aug 2024 07:11:52 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v6]
In-Reply-To: <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
Message-ID: <FI4YLghncpJZ1e7kj9FECQ_jnVEeshqd5bKt14ndJko=.c4f739d9-7e6d-41ad-bacf-20f6574fdd81@github.com>

On Thu, 15 Aug 2024 20:23:23 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lookup symbol as a fallback

I think @bplb will review + sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2292949198

From alanb at openjdk.org  Fri Aug 16 09:00:19 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 16 Aug 2024 09:00:19 GMT
Subject: RFR: 8338452: (dc) DatagramChannelImpl.blockingReceive with timeout
 may block indefinitely if all datagrams blocked by SecurityManager
Message-ID: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>

A small regression from JDK-8338142 that arises with DatagramSocket.receive with a timeout and a SecurityManager, or when using a really small timeout (like 1ms). In these cases, the remaining time may be computed as negative which causes the receive to block indefinitely waiting for a datagram. 

Timed receive requires timeout adjustment in two places (outer and inner loops). This complexity will go away when the SecurityManager implementation is removed. For now, I've kept the changes as small as possible so that the adjustment in the outer loop is only done when the datagram is denied by the security manager.

The test java/net/DatagramSocket/TimeoutWithSM.java exercises this code. It has failed at least once since JDK-8338142 was integrated.

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

Commit messages:
 - Initial commit

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

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

From dfuchs at openjdk.org  Fri Aug 16 10:03:49 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 16 Aug 2024 10:03:49 GMT
Subject: RFR: 8338452: (dc) DatagramChannelImpl.blockingReceive with
 timeout may block indefinitely if all datagrams blocked by SecurityManager
In-Reply-To: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
References: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
Message-ID: <tqRPPmc9xPWL2yX0jONSyp45_8bLPg-5uI-snk8W7eE=.d426210a-7df2-4ffc-a59a-483d67c52fe6@github.com>

On Fri, 16 Aug 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small regression from JDK-8338142 that arises with DatagramSocket.receive with a timeout and a SecurityManager, or when using a really small timeout (like 1ms). In these cases, the remaining time may be computed as negative which causes the receive to block indefinitely waiting for a datagram. 
> 
> Timed receive requires timeout adjustment in two places (outer and inner loops). This complexity will go away when the SecurityManager implementation is removed. For now, I've kept the changes as small as possible so that the adjustment in the outer loop is only done when the datagram is denied by the security manager.
> 
> The test java/net/DatagramSocket/TimeoutWithSM.java exercises this code. It has failed at least once since JDK-8338142 was integrated.

OK - looks reasonable

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20609#pullrequestreview-2242374344

From bpb at openjdk.org  Fri Aug 16 20:50:51 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 16 Aug 2024 20:50:51 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v6]
In-Reply-To: <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <LyjFTEtRY65SoU5AoahlPCVxJeXgZBl9_2DrMMa66CY=.33eabf99-e131-4a9c-8493-98cdee95ad84@github.com>
Message-ID: <wqVdxsFZI-MSnORYgZtQYOKcAzXpGu_J8Juh_qC0iCk=.a6fdf3d9-72fe-4355-8dc8-65505eeac99e@github.com>

On Thu, 15 Aug 2024 20:23:23 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
> 
>   lookup symbol as a fallback

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 265:

> 263:     void *func_ptr = NULL;
> 264:     if (sizeof(time_t) > 4) {
> 265:         func_ptr =  dlsym(RTLD_DEFAULT, symbol64);

Nitpick: extra space before `dlsym`.

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 267:

> 265:         func_ptr =  dlsym(RTLD_DEFAULT, symbol64);
> 266:     }
> 267:     if (func_ptr == NULL)

It might be more readable if both `if` blocks had either no brackets or both had brackets.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20208#discussion_r1720332587
PR Review Comment: https://git.openjdk.org/jdk/pull/20208#discussion_r1720333650

From vpetko at openjdk.org  Sun Aug 18 09:22:32 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Sun, 18 Aug 2024 09:22:32 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v7]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <9-9KfKGnnvsb6W4IexxF4OZUvAOTelZT643WJ7kQml0=.59d05358-2694-4cb5-b6f0-b1e1227724a3@github.com>

> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
> 
> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
> Using the function directly correctly calls 64 bit versions. 
> 
> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
> 
> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
> 
> Testing:
> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>                                                          1     1     0     0   
>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java
>             ...

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

 - Merge branch 'master' into JDK-8336529
 - fix curly braces
 - remove spurious whitespace
 - lookup symbol as a fallback
 - move function after statx_wrapper
 - move lookup function and set guard condtions
 - review comments: use a separate ifdef statement.
 - review comments: add ifdef, rename function
 - Merge branch 'master' into JDK-8336529
 - typo: remove extra whitespace
 - ... and 2 more: https://git.openjdk.org/jdk/compare/5fd24b77...d922d60e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20208/files
  - new: https://git.openjdk.org/jdk/pull/20208/files/33436b53..d922d60e

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

  Stats: 19469 lines in 635 files changed: 11784 ins; 5146 del; 2539 mod
  Patch: https://git.openjdk.org/jdk/pull/20208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20208/head:pull/20208

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

From jpai at openjdk.org  Mon Aug 19 12:59:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 19 Aug 2024 12:59:55 GMT
Subject: RFR: 8338452: (dc) DatagramChannelImpl.blockingReceive with
 timeout may block indefinitely if all datagrams blocked by SecurityManager
In-Reply-To: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
References: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
Message-ID: <-qAJCDGyXN86SITEacbWnZ4AsNm7Ge0BYOmd2PE75Sk=.62916efc-dd1b-4ddd-b069-7ca90b78e25e@github.com>

On Fri, 16 Aug 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small regression from JDK-8338142 that arises with DatagramSocket.receive with a timeout and a SecurityManager, or when using a really small timeout (like 1ms). In these cases, the remaining time may be computed as negative which causes the receive to block indefinitely waiting for a datagram. 
> 
> Timed receive requires timeout adjustment in two places (outer and inner loops). This complexity will go away when the SecurityManager implementation is removed. For now, I've kept the changes as small as possible so that the adjustment in the outer loop is only done when the datagram is denied by the security manager.
> 
> The test java/net/DatagramSocket/TimeoutWithSM.java exercises this code. It has failed at least once since JDK-8338142 was integrated.

I see that Alan has delegated this integration and the PR has been approved. I also checked that tier2 testing was done against this change in the CI. I will go ahead and integrate this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20609#issuecomment-2296513946

From alanb at openjdk.org  Mon Aug 19 12:59:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 19 Aug 2024 12:59:55 GMT
Subject: Integrated: 8338452: (dc) DatagramChannelImpl.blockingReceive with
 timeout may block indefinitely if all datagrams blocked by SecurityManager
In-Reply-To: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
References: <6z4eAcpGu1V0fi9tchNLJh52_JpCsXt_wrU4KUklUO8=.362dc736-dc40-4ae6-a435-f46016ac54bd@github.com>
Message-ID: <lEQULaWcBANXdm_4BPuRMQC4ptGhuSIxv5LifGJMpAo=.5ece8d4e-0e49-4e2f-9863-588878fca68a@github.com>

On Fri, 16 Aug 2024 08:27:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> A small regression from JDK-8338142 that arises with DatagramSocket.receive with a timeout and a SecurityManager, or when using a really small timeout (like 1ms). In these cases, the remaining time may be computed as negative which causes the receive to block indefinitely waiting for a datagram. 
> 
> Timed receive requires timeout adjustment in two places (outer and inner loops). This complexity will go away when the SecurityManager implementation is removed. For now, I've kept the changes as small as possible so that the adjustment in the outer loop is only done when the datagram is denied by the security manager.
> 
> The test java/net/DatagramSocket/TimeoutWithSM.java exercises this code. It has failed at least once since JDK-8338142 was integrated.

This pull request has now been integrated.

Changeset: 2766b09e
Author:    Alan Bateman <alanb at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2766b09e29d7c1c31fdef20f016a181eedb2d429
Stats:     15 lines in 1 file changed: 11 ins; 4 del; 0 mod

8338452: (dc) DatagramChannelImpl.blockingReceive with timeout may block indefinitely if all datagrams blocked by SecurityManager

Reviewed-by: dfuchs

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

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

From dfuchs at openjdk.org  Mon Aug 19 13:50:54 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 19 Aug 2024 13:50:54 GMT
Subject: Integrated: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests
In-Reply-To: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
Message-ID: <B7CZpqgziPeKEmFzGEYJE9qBXGSyoyFSV0er58RUtlA=.5ff22546-7905-498f-8ec9-ef02bb421029@github.com>

On Fri, 5 Jul 2024 10:50:56 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Several `java/nio/channels/DatagramChannel` tests fail intermittently. Though it seems difficult to fix all intermittent failures due to the nature of what some of these attempt to test, the stability can still be improved.
> 
> The most common source of intermittent failures are:
> 
>  - not receiving a datagram due to port conflict or interference of concurrent running tests
>  - failure to disconnect due to interference of concurrent running tests
>  - failure due to reception of unexpected stray datagrams
> 
> Avoiding to bind on the wildcard address, filtering unexpected datagram, and some retrying can aleviate some of the issues and greatly reduce the frequency of intermittent failures.

This pull request has now been integrated.

Changeset: 3ca359ad
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3ca359ad224b07f283c99eb43bed02eb93ef2dc7
Stats:     385 lines in 11 files changed: 273 ins; 20 del; 92 mod

8335771: Improve stability of java/nio/channels/DatagramChannel tests

Reviewed-by: alanb

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

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

From bpb at openjdk.org  Mon Aug 19 22:05:54 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 19 Aug 2024 22:05:54 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v7]
In-Reply-To: <9-9KfKGnnvsb6W4IexxF4OZUvAOTelZT643WJ7kQml0=.59d05358-2694-4cb5-b6f0-b1e1227724a3@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <9-9KfKGnnvsb6W4IexxF4OZUvAOTelZT643WJ7kQml0=.59d05358-2694-4cb5-b6f0-b1e1227724a3@github.com>
Message-ID: <CI6qmYOUPn3V77DhoOqhKqQp-9PUkK72oZTrL4k16lE=.1ac640e4-22c2-4194-b51d-6420202227c6@github.com>

On Sun, 18 Aug 2024 09:22:32 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8336529
>  - fix curly braces
>  - remove spurious whitespace
>  - lookup symbol as a fallback
>  - move function after statx_wrapper
>  - move lookup function and set guard condtions
>  - review comments: use a separate ifdef statement.
>  - review comments: add ifdef, rename function
>  - Merge branch 'master' into JDK-8336529
>  - typo: remove extra whitespace
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/28701465...d922d60e

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20208#pullrequestreview-2246541965

From duke at openjdk.org  Tue Aug 20 02:32:59 2024
From: duke at openjdk.org (duke)
Date: Tue, 20 Aug 2024 02:32:59 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v7]
In-Reply-To: <9-9KfKGnnvsb6W4IexxF4OZUvAOTelZT643WJ7kQml0=.59d05358-2694-4cb5-b6f0-b1e1227724a3@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <9-9KfKGnnvsb6W4IexxF4OZUvAOTelZT643WJ7kQml0=.59d05358-2694-4cb5-b6f0-b1e1227724a3@github.com>
Message-ID: <ZVBQZFbVd9v0ovkOgQe_30d-nRvzQM1OJMKmvGImpQ8=.1f9e24c9-fcd9-4050-a102-6fa217510c8b@github.com>

On Sun, 18 Aug 2024 09:22:32 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
>> 
>> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
>> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
>> Using the function directly correctly calls 64 bit versions. 
>> 
>> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
>> 
>> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
>> 
>> Testing:
>> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR   
>>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>>                                                          1     1     0     0   
>>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>>                                                          1     1     0     0   
>>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>>                                                          1     1     0     0   
>>    jtreg:test/...
>
> Vladimir Petko has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8336529
>  - fix curly braces
>  - remove spurious whitespace
>  - lookup symbol as a fallback
>  - move function after statx_wrapper
>  - move lookup function and set guard condtions
>  - review comments: use a separate ifdef statement.
>  - review comments: add ifdef, rename function
>  - Merge branch 'master' into JDK-8336529
>  - typo: remove extra whitespace
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/dd39aad4...d922d60e

@vpa1977 
Your change (at version d922d60e96b471fc356ab040f35b9d4c29a50cff) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2297847881

From vpetko at openjdk.org  Tue Aug 20 15:54:58 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Tue, 20 Aug 2024 15:54:58 GMT
Subject: Integrated: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <CMNNtoHnCOhu7Ls1uNpnDo7uNCAjX1eB89FiuT8VL60=.6bdf170f-12b0-4e1d-b910-65f23186a285@github.com>

On Wed, 17 Jul 2024 00:52:56 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> time_t transition in Debian/Ubuntu left 32 bit time_t  symbols in glibc. 
> 
> Looking up 'futimens' via dlsym returns 32 bit version of the function.  
> This is causing failure to set last modified time (e.g. instead of year 2017 we get 1976 in the test).
> Using the function directly correctly calls 64 bit versions. 
> 
> When we lookup functions with time_t arguments through dlsym() calls we should use 64 bit versions.
> 
> This MR adds a function to lookup 64 bit functions when time_t size is greater than 32 bit in line with the existing [time_t patch](https://evolvis.org/plugins/scmgit/cgi-bin/gitweb.cgi?p=alioth/openjdk-8.git;a=blob;f=debian/patches/t64-dlsyms.diff;h=b2cc8f8a00244bc44900366ed08d7f246ad09904;hb=4c5085cd49fcdc04405e9039705935fde08644a7)
> 
> Testing:
> `` sh configure --with-debug-level=fastdebug --enable-fallback-linker --with-jtreg=../jtreg/build/images/jtreg``
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR   
>    jtreg:test/jdk/jdk/nio/zipfs/CopyMoveTests.java       1     1     0     0   
>    jtreg:test/jdk/jdk/nio/zipfs/TestPosix.java           1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/Basic.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SetLastModifiedTime.java
>                                                          1     1     0     0   
>    jtreg:test/jdk/java/nio/file/Files/SymlinkTime.java
>                                                          1     1     0     0   
>    jtreg:test/langtools/tools/javac/modules/MOptionTest.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/dynamicArchive/DynamicSharedSymbols.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestDynamicDump.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestFileSafety.java
>                                                          1     1     0     0   
>    jtreg:test/hotspot/jtreg/runtime/cds/appcds/jcmd/JCmdTestStaticDump.java
>             ...

This pull request has now been integrated.

Changeset: 285ceb9e
Author:    Vladimir Petko <vpetko at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/285ceb9ee51e064687da6fc3fbed984e34cf02e6
Stats:     26 lines in 1 file changed: 26 ins; 0 del; 0 mod

8336529: (fs) UnixFileAttributeViews setTimes() failing on armhf, Ubuntu noble

Reviewed-by: bpb, alanb

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

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

From bpb at openjdk.org  Tue Aug 20 21:28:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 Aug 2024 21:28:33 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back to
 epoch if birth time is unavailable (Linux)
Message-ID: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>

Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

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

Commit messages:
 - 8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)

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

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

From bpb at openjdk.org  Tue Aug 20 21:32:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 20 Aug 2024 21:32:03 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux)
In-Reply-To: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
Message-ID: <y8nI5tsjR3eyIDCN-nXuG-oJBJSaUM_R_Iy5AcOI83A=.bb884d9e-9f51-4bb2-bc5b-b75fa805c30b@github.com>

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

> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

The PR #15792 that resolved [JDK-8316304](https://bugs.openjdk.org/browse/JDK-8316304) changed the creation  time to be set to the birth time retrieved by the `statx(2)` system call, if that call is available, but failed to check the `stx_mask` field of the returned `struct statx` structure to see whether the `STATX_BTIME` bit had been set, indicating that the birth time had been filled in. This is a behavioral change from prior versions. Also, the deprecated constant `STATX_ALL` was used.

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

PR Comment: https://git.openjdk.org/jdk/pull/20655#issuecomment-2299797746

From syan at openjdk.org  Wed Aug 21 06:53:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Aug 2024 06:53:03 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <KkxrEG08keyUoVK9vNUG41m1i3o13SnuJNbAYDkKqbc=.bf4b7008-3e9b-4c11-85df-21b6e0e379b3@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

> /label remove core-libs /label add nio

Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2301266156

From syan at openjdk.org  Wed Aug 21 06:58:02 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Aug 2024 06:58:02 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <u0y01SEj7Gu69rjkaUvYFj1rl0X2FZbPhuz91DJ1TRQ=.84ef7273-f434-44ce-b13d-b0203532f66e@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

The GHA test runner report macos-aarch64 `runtime/cds/DeterministicDump.java` failure, I hava create a new [jbs](https://bugs.openjdk.org/browse/JDK-8338712) to record this issue. I think the failure is unrelated to this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2301275247

From sgehwolf at openjdk.org  Wed Aug 21 08:19:03 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 08:19:03 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux)
In-Reply-To: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
Message-ID: <4g5OAsAQ-J7UD9qjPsEeMRXozw_3YDMoRkHn8kJJYrg=.7f0a7a5e-4414-44a5-8d0e-48b58bf49b1b@github.com>

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

> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

Seems OK to me.

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

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20655#pullrequestreview-2250114393

From alanb at openjdk.org  Wed Aug 21 09:51:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Aug 2024 09:51:08 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux)
In-Reply-To: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
Message-ID: <8uO3dA3UYD5UDVb9FrNf-JSACS86o-5dZKMcZ7KD-hA=.d67b5ab1-c7df-40ed-9da4-01efc359e651@github.com>

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

> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

Marked as reviewed by alanb (Reviewer).

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 608:

> 606:         //
> 607:         //  Birth time was not filled in: fall back to last modification time
> 608:         //

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.

Minor nit, can you use the same comment style as the other comments in the code, meaning drop the empty comment lines, only to keep it consistent with the other comments in this function and elsewhere.

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

PR Review: https://git.openjdk.org/jdk/pull/20655#pullrequestreview-2250329493
PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1724769397

From dfuchs at openjdk.org  Wed Aug 21 11:45:02 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Aug 2024 11:45:02 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <ak43Uncz8T40H-BZOxtNf0K8giFULbO10dAz0rYvQ_0=.c94c5670-840a-4a5f-bf93-b71aada9a0fc@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

This looks good to me. Since I suggested the patch maybe someone else should officially approve?
@jaikiran or @djelinski maybe? See the JBS issue for more details.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2301847828

From djelinski at openjdk.org  Wed Aug 21 12:01:09 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Aug 2024 12:01:09 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <hnBsyguCQtFJccP9xyqpn73K_GBpit4NajC3-6mcz5A=.2bce217e-cb70-4ddb-aa5e-7bf78fcf5939@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20658#pullrequestreview-2250597987

From jpai at openjdk.org  Wed Aug 21 12:15:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 21 Aug 2024 12:15:03 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <Qur2UWCH07bYtUpCC25PRQbzcy0SHPOmGonDKg_TZSM=.27a1c256-1f77-4c93-8fa8-91a231154856@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

Looks OK to me. Should we be adding that check even within the `if (Platform.isOSX()) {` a few lines above? I suspect even macos can have `docker0` interface?

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2301902868

From syan at openjdk.org  Wed Aug 21 12:45:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Aug 2024 12:45:22 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.

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

 - macos may have docker0 interface
 - macos may have docker0 interface

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20658/files
  - new: https://git.openjdk.org/jdk/pull/20658/files/583aaa1a..d5c3f695

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

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

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

From syan at openjdk.org  Wed Aug 21 12:45:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 21 Aug 2024 12:45:22 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <Qur2UWCH07bYtUpCC25PRQbzcy0SHPOmGonDKg_TZSM=.27a1c256-1f77-4c93-8fa8-91a231154856@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <Qur2UWCH07bYtUpCC25PRQbzcy0SHPOmGonDKg_TZSM=.27a1c256-1f77-4c93-8fa8-91a231154856@github.com>
Message-ID: <8hjzrH0VbrS6M4z3hdv46bwMK4_XKOlKNG7MDghgyb8=.71cefa6d-6579-463b-8022-8d0af6faae43@github.com>

On Wed, 21 Aug 2024 12:12:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Looks OK to me. Should we be adding that check even within the `if (Platform.isOSX()) {` a few lines above? I suspect even macos can have `docker0` interface?

I am not sure macos can have `docker0` interface or not, but add that check on macos will not harmful. The check has been added.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2301962545

From djelinski at openjdk.org  Wed Aug 21 13:32:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Aug 2024 13:32:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
Message-ID: <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>

On Thu, 1 Aug 2024 18:09:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.

src/java.base/unix/native/libnio/ch/FileKey.c line 39:

> 37:     struct stat fbuf;
> 38:     int res;
> 39:     long deviceAndInode[2];

Suggestion:

    jlong deviceAndInode[2];

src/java.base/windows/classes/sun/nio/ch/FileKey.java line 67:

> 65: 
> 66:     static {
> 67:         IOUtil.load();

I assume you verified that `IOUtil.load()` won't be needed, correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725042382
PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725057005

From dfuchs at openjdk.org  Wed Aug 21 14:17:04 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 21 Aug 2024 14:17:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <9bjuL69UcTgrfZU_crHVtREatJEmgy5M9yV9fpYCjb4=.4db02544-88be-4f2d-a527-977cfcdb930e@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

I'd rather avoid adding exceptions until it's proven necessary. I don't know if `docker` uses the same techniques on macOs and Linux to configure private networks between instances. But since it's unlikely that the name `docker0` would be reused for something else then maybe we can keep this change.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2302161322

From bpb at openjdk.org  Wed Aug 21 14:50:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 14:50:21 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
Message-ID: <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>

> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

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

  8338696: Delete empty comment lines

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20655/files
  - new: https://git.openjdk.org/jdk/pull/20655/files/2c604eb8..347e9060

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

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

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

From bpb at openjdk.org  Wed Aug 21 14:50:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 14:50:21 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <8uO3dA3UYD5UDVb9FrNf-JSACS86o-5dZKMcZ7KD-hA=.d67b5ab1-c7df-40ed-9da4-01efc359e651@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
 <8uO3dA3UYD5UDVb9FrNf-JSACS86o-5dZKMcZ7KD-hA=.d67b5ab1-c7df-40ed-9da4-01efc359e651@github.com>
Message-ID: <5oOvufswuiCF1In92xBLABrpWdrZVuP0d_dRD-rjVl0=.b21ac190-5f2f-447f-bc71-ddc599288004@github.com>

On Wed, 21 Aug 2024 09:48:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> 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.

Sure. I think it would be good to get this in now, however, due to backward compatibility.

> Minor nit, can you use the same comment style as the other comments in the code, meaning drop the empty comment lines, only to keep it consistent with the other comments in this function and elsewhere.

Fixed in 347e906.

Do you agree that a CSR is warranted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1725190816

From bpb at openjdk.org  Wed Aug 21 16:08:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 16:08:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
Message-ID: <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>

On Wed, 21 Aug 2024 13:28:27 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> src/java.base/windows/classes/sun/nio/ch/FileKey.java line 67:
> 
>> 65: 
>> 66:     static {
>> 67:         IOUtil.load();
> 
> I assume you verified that `IOUtil.load()` won't be needed, correct?

I tested back before I opened this PR but will test again. There is no longer any code in these classes which uses upcalls from native code. The only native functions remaining from what I can see are `fdval()` and `handleval()` which are defined in `libjava` {`libjava.so`, `libjava.dylib`, `java.dll`}.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725356549

From sgehwolf at openjdk.org  Wed Aug 21 16:10:03 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:10:03 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
 <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
Message-ID: <JXU0SnQrDvt7whRljEILB-uNxL4Hp-gHaL2PBHNX3t0=.bcdaf85c-e170-43c4-9f2c-de27302c4838@github.com>

On Wed, 21 Aug 2024 14:50:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8338696: Delete empty comment lines

Marked as reviewed by sgehwolf (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20655#pullrequestreview-2251291681

From sgehwolf at openjdk.org  Wed Aug 21 16:10:04 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:10:04 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <5oOvufswuiCF1In92xBLABrpWdrZVuP0d_dRD-rjVl0=.b21ac190-5f2f-447f-bc71-ddc599288004@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>
Message-ID: <2GcDA0gVCJbmu1qieXHdev877w-UopfpKOZ8MlpfzUs=.eb5cea48-6192-40a7-a3be-9827eb159069@github.com>

On Wed, 21 Aug 2024 14:47:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Do you agree that a CSR is warranted?

FWIW, the original change didn't have a CSR (only had a release note), so I'm somewhat confused this would need one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1725359992

From bpb at openjdk.org  Wed Aug 21 16:33:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 16:33:02 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <2GcDA0gVCJbmu1qieXHdev877w-UopfpKOZ8MlpfzUs=.eb5cea48-6192-40a7-a3be-9827eb159069@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>
Message-ID: <dg-AoMVCvyPY0RLj5cBk7-g9IMjwUpHFAy7Y5IvMldc=.1720a693-40f2-4488-bd0e-aaf767c8ed7a@github.com>

On Wed, 21 Aug 2024 16:07:49 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>>> 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.
>> 
>> Sure. I think it would be good to get this in now, however, due to backward compatibility.
>> 
>>> Minor nit, can you use the same comment style as the other comments in the code, meaning drop the empty comment lines, only to keep it consistent with the other comments in this function and elsewhere.
>> 
>> Fixed in 347e906.
>> 
>> Do you agree that a CSR is warranted?
>
>> Do you agree that a CSR is warranted?
> 
> FWIW, the original change didn't have a CSR (only had a release note), so I'm somewhat confused this would need one.

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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1725385972

From sgehwolf at openjdk.org  Wed Aug 21 16:33:02 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 21 Aug 2024 16:33:02 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <dg-AoMVCvyPY0RLj5cBk7-g9IMjwUpHFAy7Y5IvMldc=.1720a693-40f2-4488-bd0e-aaf767c8ed7a@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>
Message-ID: <Nl_T14imLwJ1TtF5f3cAYYzWDrf3eHDGoxBoLW7RiCM=.d6e45f31-5937-493e-a860-59350a0ca9ee@github.com>

On Wed, 21 Aug 2024 16:28:14 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Do you agree that a CSR is warranted?
>> 
>> FWIW, the original change didn't have a CSR (only had a release note), so I'm somewhat confused this would need one.
>
> 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.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20655#discussion_r1725388240

From alanb at openjdk.org  Wed Aug 21 17:42:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Aug 2024 17:42:05 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
 <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
Message-ID: <zLO4o8VHkwHtxXOQqKNYl0BeXULylF5CljJkR0DNDNI=.96e2e526-7fe8-4358-b05b-e94042554e86@github.com>

On Wed, 21 Aug 2024 14:50:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8338696: Delete empty comment lines

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20655#pullrequestreview-2251498785

From alanb at openjdk.org  Wed Aug 21 17:50:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 21 Aug 2024 17:50:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
Message-ID: <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>

On Wed, 21 Aug 2024 16:05:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/windows/classes/sun/nio/ch/FileKey.java line 67:
>> 
>>> 65: 
>>> 66:     static {
>>> 67:         IOUtil.load();
>> 
>> I assume you verified that `IOUtil.load()` won't be needed, correct?
>
> I tested back before I opened this PR but will test again. There is no longer any code in these classes which uses upcalls from native code. The only native functions remaining from what I can see are `fdval()` and `handleval()` which are defined in `libjava` {`libjava.so`, `libjava.dylib`, `java.dll`}.

I assume a System.loadLibrary (by way of IOUtil.load) is needed, otherwise dependent on something else loading the native library.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725485042

From bpb at openjdk.org  Wed Aug 21 18:29:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 18:29:04 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
Message-ID: <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>

On Wed, 21 Aug 2024 17:47:42 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I assume a System.loadLibrary (by way of IOUtil.load) is needed, otherwise dependent on something else loading the native library.

I think that is correct after all. It should load the NIO native library, which defines `fdval()` and `handleval()`. I must have confounded this with #20317 wherein those symbols are moved to `libjava`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725532993

From djelinski at openjdk.org  Wed Aug 21 18:39:06 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Aug 2024 18:39:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
 <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
Message-ID: <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>

On Wed, 21 Aug 2024 18:26:43 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I assume a System.loadLibrary (by way of IOUtil.load) is needed, otherwise dependent on something else loading the native library.
>
>> I assume a System.loadLibrary (by way of IOUtil.load) is needed, otherwise dependent on something else loading the native library.
> 
> I think that is correct after all. It should load the NIO native library, which defines `fdval()` and `handleval()`. I must have confounded this with #20317 wherein those symbols are moved to `libjava`.

I think the important part here is that libnio defines `Java_sun_nio_ch_FileKey_init`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725543353

From bpb at openjdk.org  Wed Aug 21 19:21:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 19:21:04 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final
In-Reply-To: <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
 <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
 <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>
Message-ID: <-SPnnCu-T7knApBI8ImEfgw1Pw4MV-H0jV3odSaEXfY=.d3816422-6b31-4f63-bb21-de0ca25ce339@github.com>

On Wed, 21 Aug 2024 18:36:04 GMT, Daniel Jeli?ski <djelinski at openjdk.org> wrote:

>>> I assume a System.loadLibrary (by way of IOUtil.load) is needed, otherwise dependent on something else loading the native library.
>> 
>> I think that is correct after all. It should load the NIO native library, which defines `fdval()` and `handleval()`. I must have confounded this with #20317 wherein those symbols are moved to `libjava`.
>
> I think the important part here is that libnio defines `Java_sun_nio_ch_FileKey_init`.

Something must be loading the library but I don't know what. I did some testing which does not use any NIO classes other than `FileKey`, and the class worked without the explicit load, on both Unix and Windows. I think, however, that I need to add it on Unix and restore it on Windows to be safe.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725641628

From bpb at openjdk.org  Wed Aug 21 19:36:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 19:36:03 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
Message-ID: <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>

> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.

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

  8324048: Add and reinstate IOUtil.load(); change long to jlong

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20429/files
  - new: https://git.openjdk.org/jdk/pull/20429/files/0c5f4603..378d7006

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

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

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

From bpb at openjdk.org  Wed Aug 21 19:36:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 19:36:04 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
Message-ID: <Lx8TGUOA7x1uO4C5AjnBJVWPWts-Id_NSJ7Ohrr4Mas=.9d4bc11c-8233-4a1f-9a4c-bbb589181c66@github.com>

On Wed, 21 Aug 2024 13:19:21 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:
>> 
>>   8324048: Add and reinstate IOUtil.load(); change long to jlong
>
> src/java.base/unix/native/libnio/ch/FileKey.c line 39:
> 
>> 37:     struct stat fbuf;
>> 38:     int res;
>> 39:     long deviceAndInode[2];
> 
> Suggestion:
> 
>     jlong deviceAndInode[2];

Fixed in 378d700.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725653758

From bpb at openjdk.org  Wed Aug 21 19:36:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 19:36:05 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <-SPnnCu-T7knApBI8ImEfgw1Pw4MV-H0jV3odSaEXfY=.d3816422-6b31-4f63-bb21-de0ca25ce339@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
 <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
 <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>
 <-SPnnCu-T7knApBI8ImEfgw1Pw4MV-H0jV3odSaEXfY=.d3816422-6b31-4f63-bb21-de0ca25ce339@github.com>
Message-ID: <MG694TcDFjS7Beb-k6vwJIoHJQXxIe40i9hjZfsep0I=.15f2e1a3-9dfc-4224-8839-f42bdf180b70@github.com>

On Wed, 21 Aug 2024 19:18:28 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I think the important part here is that libnio defines `Java_sun_nio_ch_FileKey_init`.
>
> Something must be loading the library but I don't know what. I did some testing which does not use any NIO classes other than `FileKey`, and the class worked without the explicit load, on both Unix and Windows. I think, however, that I need to add it on Unix and restore it on Windows to be safe.

Added / reinstated `IOUtil.load()` in 378d700.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1725654386

From djelinski at openjdk.org  Wed Aug 21 19:41:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Wed, 21 Aug 2024 19:41:07 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>
Message-ID: <Ru-ju1RacVk-VcWs3ZTNboz6SIKpr6sVhFRwDeG-hU8=.1ecaae0f-f0b0-4e15-a332-83a7d48a359a@github.com>

On Wed, 21 Aug 2024 19:36:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8324048: Add and reinstate IOUtil.load(); change long to jlong

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20429#pullrequestreview-2251790522

From bpb at openjdk.org  Wed Aug 21 21:49:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 21 Aug 2024 21:49:04 GMT
Subject: RFR: 8338696: (fs) BasicFileAttributes.creationTime() falls back
 to epoch if birth time is unavailable (Linux) [v2]
In-Reply-To: <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
 <9Y16dgiwhIAVtRcQ6ewwhEPhN8NXsLTlot0wp31oaR0=.7149a207-928e-43fb-8d21-5fa790deaae0@github.com>
Message-ID: <NKydY_aOm7YCuT_2KlCObuSzMAQmIruQED0xTqz6scc=.6eb43d30-5cbf-425b-873f-a9240345144c@github.com>

On Wed, 21 Aug 2024 14:50:21 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8338696: Delete empty comment lines

Thanks for the approvals. I have filed a CSR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20655#issuecomment-2303065320

From syan at openjdk.org  Thu Aug 22 01:23:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Aug 2024 01:23:06 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <zEAgYmAxmyFxKmyf7PAbZbVn9XkgkITabkTOjRHq6X4=.efcaba9d-724b-4d73-a220-faab0f8d4d5a@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

I think the name `docker0` will not reused for something else, so keep this change seems to be acceptable.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2303388320

From alanb at openjdk.org  Thu Aug 22 06:55:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Aug 2024 06:55:07 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>
Message-ID: <NwE5VuP3_77Ohl85mrnO6f68BoEAEHrZRRS2gXqu57U=.a397b4c6-b80d-49b0-94f2-4832c3f6c8d5@github.com>

On Wed, 21 Aug 2024 19:36:03 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8324048: Add and reinstate IOUtil.load(); change long to jlong

Thanks for restoring the IOUtil.load, having loadLibrary be explicit in native code beyond libjava is useful to avoid surprises.

src/java.base/windows/native/libnio/ch/FileKey.c line 35:

> 33: JNIEXPORT void JNICALL
> 34: Java_sun_nio_ch_FileKey_init(JNIEnv *env, jclass clazz, jobject fdo,
> 35:     jintArray finfo)

Minor nit, no need for the line break in the function declaration.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20429#pullrequestreview-2253612305
PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1726429330

From jpai at openjdk.org  Thu Aug 22 07:28:06 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Aug 2024 07:28:06 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <MG694TcDFjS7Beb-k6vwJIoHJQXxIe40i9hjZfsep0I=.15f2e1a3-9dfc-4224-8839-f42bdf180b70@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
 <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
 <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>
 <-SPnnCu-T7knApBI8ImEfgw1Pw4MV-H0jV3odSaEXfY=.d3816422-6b31-4f63-bb21-de0ca25ce339@github.com>
 <MG694TcDFjS7Beb-k6vwJIoHJQXxIe40i9hjZfsep0I=.15f2e1a3-9dfc-4224-8839-f42bdf180b70@github.com>
Message-ID: <gA1QMuYXPio7caJx-sNJMq2sxXn3H5Hb2T63h9_ngZQ=.b6cef503-7bdf-4be3-9265-a0bb0ee81992@github.com>

On Wed, 21 Aug 2024 19:31:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Something must be loading the library but I don't know what. I did some testing which does not use any NIO classes other than `FileKey`, and the class worked without the explicit load, on both Unix and Windows. I think, however, that I need to add it on Unix and restore it on Windows to be safe.
>
> Added / reinstated `IOUtil.load()` in 378d700.

> Something must be loading the library but I don't know what.

I was curious, so gave this program a try against a JDK version which doesn't have this PR's change:


import java.nio.file.*;
import java.nio.channels.*;

public class FileChannelTest {
    public static void main(final String[] args) throws Exception {
        try(FileChannel fc = FileChannel.open(Path.of("/tmp/foo.txt"), StandardOpenOption.WRITE)) {
            System.out.println("opened filechannel " + fc);
            try(final FileLock lock = fc.lock()) {
                System.out.println("obtained lock " + lock);
            }
        }
    }
}


Launched it as follows with `-Xlog` logging:


java "-Xlog:class+init=trace,library=trace" FileChannelTest.java


The generated log (snippet) looks like:


[0.103s][debug][class,init] Thread "main" is initializing sun.nio.ch.FileDispatcherImpl
[0.103s][debug][class,init] Thread "main" is initializing sun.nio.ch.UnixFileDispatcherImpl
[0.103s][debug][class,init] Thread "main" is initializing sun.nio.ch.FileDispatcher
[0.103s][debug][class,init] Thread "main" is initializing sun.nio.ch.NativeDispatcher
[0.103s][info ][class,init] 618 Initializing 'sun/nio/ch/NativeDispatcher'(no method) (0x000001f001046d90) by thread "main"
[0.103s][info ][class,init] 619 Initializing 'sun/nio/ch/FileDispatcher'(no method) (0x000001f001046fe0) by thread "main"
[0.103s][info ][class,init] 620 Initializing 'sun/nio/ch/UnixFileDispatcherImpl' (0x000001f0010472b8) by thread "main"
[0.104s][debug][class,init] Thread "main" linking sun.nio.ch.IOUtil
[0.104s][debug][class,init] Thread "main" is initializing sun.nio.ch.IOUtil
[0.104s][info ][class,init] 621 Initializing 'sun/nio/ch/IOUtil' (0x000001f001047a00) by thread "main"
[0.104s][debug][class,init] Thread "main" recursively initializing sun.nio.ch.IOUtil
[0.104s][debug][class,init] Thread "main" recursively initializing sun.nio.ch.IOUtil
[0.104s][info ][library   ] Failed to find JNI_OnLoad_net in library with handle 0xfffffffffffffffb
[0.104s][info ][library   ] Loaded library /jdk-22.jdk/Contents/Home/lib/libnet.dylib, handle 0x0000000099b0b070
[0.104s][info ][library   ] Found JNI_OnLoad in library with handle 0x0000000099b0b070
[0.104s][info ][library   ] Found inet_pton in library with handle 0xfffffffffffffffe
[0.104s][info ][library   ] Failed to find JNI_OnLoad_nio in library with handle 0xfffffffffffffffb
[0.104s][debug][class,init] Thread "main" recursively initializing sun.nio.ch.IOUtil
[0.104s][info ][library   ] Found Java_sun_nio_ch_IOUtil_initIDs in library with handle 0x0000000099b0ae10

So it looks like `IOUtil.load()` gets called from the static initializer of `sun.nio.ch.UnixFileDispatcherImpl` here https://github.com/openjdk/jdk/blob/master/src/java.base/unix/classes/sun/nio/ch/UnixFileDispatcherImpl.java#L40 which then triggers the loading of the net and nio libraries.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1726498606

From dfuchs at openjdk.org  Thu Aug 22 08:22:04 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 22 Aug 2024 08:22:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <AduwmJ75K6Nel0_X6n9m0blw6bTz3b-hfYfQurb_39k=.54c63e69-51a1-4673-af0d-f57a6f7ce196@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20658#pullrequestreview-2253819679

From syan at openjdk.org  Thu Aug 22 08:36:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Aug 2024 08:36:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <sLyJyUN1RW6qf4lslDD80po82hh1ES6_kJz4kdOTb3w=.4e62f4d2-e6b9-42f6-9c54-b9772a781f9b@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

Thanks for the approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2304089795

From jpai at openjdk.org  Thu Aug 22 11:34:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 22 Aug 2024 11:34:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <Ji-hXxUYTQtAb24l7wvDLf5purZp4GDxBAL1P-kI67Y=.11351d25-34fe-4aa8-a4e2-3b65313d55f5@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

Hello @sendaoYan, this looks OK to me. Given that this is changing a test library class and not just a specific test, I'm guessing you have run at least tier1, tier2 (and perhaps even tier3) with these changes?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20658#pullrequestreview-2254261439

From syan at openjdk.org  Thu Aug 22 12:48:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 22 Aug 2024 12:48:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <sLyJyUN1RW6qf4lslDD80po82hh1ES6_kJz4kdOTb3w=.4e62f4d2-e6b9-42f6-9c54-b9772a781f9b@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
 <sLyJyUN1RW6qf4lslDD80po82hh1ES6_kJz4kdOTb3w=.4e62f4d2-e6b9-42f6-9c54-b9772a781f9b@github.com>
Message-ID: <tMnmMTeFZtqTJ1KGzS_zE0vKviJ0RNvqs1utxCk80Hs=.7505c2ac-55db-4430-9c35-f5c7fdb5f8fc@github.com>

On Thu, 22 Aug 2024 08:33:05 GMT, SendaoYan <syan at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - macos may have docker0 interface
>>  - macos may have docker0 interface
>
> Thanks for the approved.

> Hello @sendaoYan, this looks OK to me. Given that this is changing a test library class and not just a specific test, I'm guessing you have run at least tier1, tier2 (and perhaps even tier3) with these changes?

Thanks for your reminding, I will verify this chang by full jtreg tests on linux x64 and linux aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2304581049

From bpb at openjdk.org  Thu Aug 22 15:02:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Aug 2024 15:02:20 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v3]
In-Reply-To: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
Message-ID: <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>

> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.

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

  8324048: Remove line break

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20429/files
  - new: https://git.openjdk.org/jdk/pull/20429/files/378d7006..eafff235

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

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

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

From bpb at openjdk.org  Thu Aug 22 15:02:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Aug 2024 15:02:21 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v2]
In-Reply-To: <NwE5VuP3_77Ohl85mrnO6f68BoEAEHrZRRS2gXqu57U=.a397b4c6-b80d-49b0-94f2-4832c3f6c8d5@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <Eb6vD6JvdU3WZKmACoS2OYFv0wQ6zHErDCTBV9kStdc=.4da67966-384a-4362-81b7-d507228b0304@github.com>
 <NwE5VuP3_77Ohl85mrnO6f68BoEAEHrZRRS2gXqu57U=.a397b4c6-b80d-49b0-94f2-4832c3f6c8d5@github.com>
Message-ID: <vYOtwxTMQZgPn-pgQafF1xRxIYFaeBpq7frRfDUsRao=.e19673e6-f1b6-4aef-a868-8ba66dc0afee@github.com>

On Thu, 22 Aug 2024 06:52:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Thanks for restoring the IOUtil.load, having loadLibrary be explicit in native code beyond libjava is useful to avoid surprises.

It will be removed if #20317 goes in.

> src/java.base/windows/native/libnio/ch/FileKey.c line 35:
> 
>> 33: JNIEXPORT void JNICALL
>> 34: Java_sun_nio_ch_FileKey_init(JNIEnv *env, jclass clazz, jobject fdo,
>> 35:     jintArray finfo)
> 
> Minor nit, no need for the line break in the function declaration.

Removed in [eafff23](https://github.com/openjdk/jdk/pull/20429/commits/eafff235646c70d72952c40928776b69c1bb33c9).

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

PR Comment: https://git.openjdk.org/jdk/pull/20429#issuecomment-2304881620
PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1727229076

From bpb at openjdk.org  Thu Aug 22 16:04:09 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Aug 2024 16:04:09 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v3]
In-Reply-To: <gA1QMuYXPio7caJx-sNJMq2sxXn3H5Hb2T63h9_ngZQ=.b6cef503-7bdf-4be3-9265-a0bb0ee81992@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <rQ5_DDJU1y9eQkVVWZEs-E2hYHPYj_DlU5q1WU2yRG4=.30da8939-2c45-43e9-88c2-27efa4fc948e@github.com>
 <jV_Yneu401S0XLDyXH-yEx5ImlwjNUb-de4zdAJt7m0=.ad873ada-31e1-40cf-8667-1ea48b23bdfc@github.com>
 <ztxTgOdUTOnMKnfujxRHFqAzQxUr-9zmdpp5C8YkrJA=.408362fd-9c5f-4290-938b-0b76e1387337@github.com>
 <PvHg9tvRSySWhwe3zWMVSy0xv5HfpYj3ou2TGaWd8co=.7e0525a4-c366-4cbd-ac8a-3b66f4b4d53d@github.com>
 <9T3ab7QgsKXw4MsuLw59kdSsUMRqr3JxllcuyjEgbF8=.932f0520-a050-48aa-93ef-440cf7fd9cf3@github.com>
 <-SPnnCu-T7knApBI8ImEfgw1Pw4MV-H0jV3odSaEXfY=.d3816422-6b31-4f63-bb21-de0ca25ce339@github.com>
 <MG694TcDFjS7Beb-k6vwJIoHJQXxIe40i9hjZfsep0I=.15f2e1a3-9dfc-4224-8839-f42bdf180b70@github.com>
 <gA1QMuYXPio7caJx-sNJMq2sxXn3H5Hb2T63h9_ngZQ=.b6cef503-7bdf-4be3-9265-a0bb0ee81992@github.com>
Message-ID: <TiQdls3a1luGmHiAlKZyX7tK5wixQgLJ6p1UB2l-3fQ=.492e5526-093f-45c8-ad6a-800ec142083c@github.com>

On Thu, 22 Aug 2024 07:25:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> So it looks like `IOUtil.load()` gets called from the static initializer of `sun.nio.ch.UnixFileDispatcherImpl`

That's pretty much what I would expect. Thanks for running it down!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20429#discussion_r1727421400

From dhanalla at openjdk.org  Thu Aug 22 18:28:12 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 22 Aug 2024 18:28:12 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in the
 OpenJDK
Message-ID: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>

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)

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

Commit messages:
 - 8338858:Replace undocumented APIs with documented APIs in the OpenJDK

Changes: https://git.openjdk.org/jdk/pull/20682/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20682&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338858
  Stats: 84 lines in 2 files changed: 32 ins; 32 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/20682.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20682/head:pull/20682

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

From alanb at openjdk.org  Thu Aug 22 18:58:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 22 Aug 2024 18:58:02 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: <qSIAcog3k2IacnVZyaKqlbCKI4C9XCRU65MoygPrx_Q=.537c8334-c1a1-4afe-9f64-66db0b6cc231@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)

Is there is a PR open in piscisaureus/wepoll to propose these changes upstream?

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

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

From dhanalla at openjdk.org  Thu Aug 22 19:14:03 2024
From: dhanalla at openjdk.org (Dhamoder Nalla)
Date: Thu, 22 Aug 2024 19:14:03 GMT
Subject: RFR: 8338858: Replace undocumented APIs with documented APIs in
 the OpenJDK
In-Reply-To: <qSIAcog3k2IacnVZyaKqlbCKI4C9XCRU65MoygPrx_Q=.537c8334-c1a1-4afe-9f64-66db0b6cc231@github.com>
References: <STp3UHcRiMHG88TkUUrA6FZvb-3zS_kmHbI8JOy277E=.ab281c84-8c27-4ab6-8b27-4ed1efd232ca@github.com>
 <qSIAcog3k2IacnVZyaKqlbCKI4C9XCRU65MoygPrx_Q=.537c8334-c1a1-4afe-9f64-66db0b6cc231@github.com>
Message-ID: <XeRH2r3skjiiBnpmKhA0eO20g8o1nQQDH1KaoI0KyBY=.cef191d0-39a2-4134-a311-41e46675185d@github.com>

On Thu, 22 Aug 2024 18:55:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is there is a PR open in piscisaureus/wepoll to propose these changes upstream?

Thanks @AlanBateman for reviewing this PR.
here is the wepoll PR https://github.com/piscisaureus/wepoll/pull/37

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

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

From bpb at openjdk.org  Thu Aug 22 21:44:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 22 Aug 2024 21:44:06 GMT
Subject: Integrated: 8338696: (fs) BasicFileAttributes.creationTime() falls
 back to epoch if birth time is unavailable (Linux)
In-Reply-To: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
References: <so035zWIy4YiY6G7XGw5UJJ11V3TYKxD448mIJwh3rY=.9ae0e9f2-789a-40f5-9176-33e15573eefb@github.com>
Message-ID: <AKuEFZEio96MelBJsINVMmzpEh8PGKlJelgnuOcqRPo=.d58e0d35-f00a-492b-993a-ca0fdae9470e@github.com>

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

> Set the value returned by `BasicFileAttributes.creationTime()` on Linux to the birth time, if available, otherwise return the last modified time.

This pull request has now been integrated.

Changeset: c89a1c35
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c89a1c35bda9002ee687b3fa267f3ef9cba78b00
Stats:     21 lines in 1 file changed: 12 ins; 0 del; 9 mod

8338696: (fs) BasicFileAttributes.creationTime() falls back to epoch if birth time is unavailable (Linux)

Reviewed-by: sgehwolf, alanb

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

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

From syan at openjdk.org  Fri Aug 23 01:35:12 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 01:35:12 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <snhhre5-GqcsDoApakMop6Qgi0fDqdDq5zZX2GBi8a0=.021effdd-48c7-4353-a94f-ebb187a6c103@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>> 
>> Additional testing
>> 
>> - [x] full jtreg test on linux x64
>> - [x] full jtreg test on linux aarch64
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

This PR has been verified by full jtreg tests(include tier1/tier2/tier3/tier4 etc.) on linux x64 and linux aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2306011773

From duke at openjdk.org  Fri Aug 23 01:35:13 2024
From: duke at openjdk.org (duke)
Date: Fri, 23 Aug 2024 01:35:13 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <ZXJvUXeIeMwDVe5cgozCN6pG6Dk7VNoeTM0AHgtSKhs=.ee66ce59-c060-4315-9f49-1c539956bf51@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>> 
>> Additional testing
>> 
>> - [x] full jtreg test on linux x64
>> - [x] full jtreg test on linux aarch64
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

@sendaoYan 
Your change (at version d5c3f695f76c8b513be4f3e2b651e8e051693f87) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2306012378

From syan at openjdk.org  Fri Aug 23 04:03:41 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 04:03:41 GMT
Subject: RFR: 8338884: Test BasicFileAttributeView/CreationTime.java#tmp fails
 on alinux3 after JDK-8338696
Message-ID: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@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.

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

Commit messages:
 - 8338884: Test BasicFileAttributeView/CreationTime.java#tmp fails on alinux3 after JDK-8338696

Changes: https://git.openjdk.org/jdk/pull/20687/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20687&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338884
  Stats: 4 lines in 1 file changed: 4 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 alanb at openjdk.org  Fri Aug 23 06:12:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 23 Aug 2024 06:12:10 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v3]
In-Reply-To: <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
Message-ID: <bRC2MXjXf2jghf9UG0_AOOYygmgpTY7HvLK-qngzZPA=.130dab0d-f217-440c-8f12-ae9f6736cacd@github.com>

On Thu, 22 Aug 2024 15:02:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8324048: Remove line break

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20429#pullrequestreview-2256433220

From jpai at openjdk.org  Fri Aug 23 06:26:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Aug 2024 06:26:04 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
Message-ID: <788oU75V5wKedUe7LTb2iX2imonDD9tUgYSd5jBTLyw=.9b0387c2-0c52-4d3e-8053-cb1ef50b09b9@github.com>

On Wed, 21 Aug 2024 12:45:22 GMT, SendaoYan <syan at openjdk.org> wrote:

>> Hi,
>> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
>> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
>> Change has been verified, test fix only, the risk is low.
>> 
>> Additional testing
>> 
>> - [x] full jtreg test on linux x64
>> - [x] full jtreg test on linux aarch64
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - macos may have docker0 interface
>  - macos may have docker0 interface

Thank you for running those tests. I ran tier1, tier2 and tier3 in our CI too with these changes and it looks fine. I'll go ahead and sponsor this now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2306376326

From syan at openjdk.org  Fri Aug 23 06:29:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 06:29:06 GMT
Subject: Integrated: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout
In-Reply-To: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
Message-ID: <eX4-8v35VbLBj1g0jQedKqz09mx2BNblXXYIkfIU05c=.3066646a-09ad-4aac-a7e0-ff5fd7ded27a@github.com>

On Wed, 21 Aug 2024 03:45:24 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi,
> On linux test environments which has docker service, `ifconfig` shows that `docker0` appears to be a virtual ethernet bridge which is created by the docker host. And the `docker0` virtual ethernet bridge may cause test `java/nio/channels/DatagramChannel/SendReceiveMaxSize.java` bind `docker0` ander network port. 
> I think we should just skip "docker0" interfaces when looking for an IPv4 address for tests.
> Change has been verified, test fix only, the risk is low.
> 
> Additional testing
> 
> - [x] full jtreg test on linux x64
> - [x] full jtreg test on linux aarch64

This pull request has now been integrated.

Changeset: 8e0d0190
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8e0d0190ed19bc1a9d4ec0c6ee3aa6454542989f
Stats:     10 lines in 1 file changed: 7 ins; 0 del; 3 mod

8338630: Test java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout

Reviewed-by: dfuchs, jpai, djelinski

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

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

From syan at openjdk.org  Fri Aug 23 06:47:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 06:47:06 GMT
Subject: RFR: 8338630: Test
 java/nio/channels/DatagramChannel/SendReceiveMaxSize.java timeout [v2]
In-Reply-To: <788oU75V5wKedUe7LTb2iX2imonDD9tUgYSd5jBTLyw=.9b0387c2-0c52-4d3e-8053-cb1ef50b09b9@github.com>
References: <TJldWZw9ZmE0PQl-0kODuN2j8aIb7HAec5MGr8_tkT0=.98563b28-1752-492d-970c-d01ca54a9f3c@github.com>
 <LFBJI9WV5AanwFEeVGK2TBcXSuvVLfoaZSCOaWgiN0k=.eaab12f5-b03f-4fd7-af54-fc53dc5c770a@github.com>
 <788oU75V5wKedUe7LTb2iX2imonDD9tUgYSd5jBTLyw=.9b0387c2-0c52-4d3e-8053-cb1ef50b09b9@github.com>
Message-ID: <Da7bYwPo41v6EviBuk1f6PZwY1i_uqWw-EXlmRqPEgw=.4d2dcc8c-fa2a-4ccd-94d2-db863450907f@github.com>

On Fri, 23 Aug 2024 06:23:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Thank you for running those tests. I ran tier1, tier2 and tier3 in our CI too with these changes and it looks fine. I'll go ahead and sponsor this now.

Thanks for the verified and sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/20658#issuecomment-2306401056

From jpai at openjdk.org  Fri Aug 23 10:18:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Aug 2024 10:18:11 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v3]
In-Reply-To: <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
Message-ID: <qsdAI1MxxrapcaA1xkzULm-n8CFaUEKBvj4W1XAxY68=.a35c7841-2bd3-403f-bbd1-159285bc3f86@github.com>

On Thu, 22 Aug 2024 15:02:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8324048: Remove line break

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20429#pullrequestreview-2256886131

From duke at openjdk.org  Fri Aug 23 10:43:30 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Fri, 23 Aug 2024 10:43:30 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
Message-ID: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>

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

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

Commit messages:
 - Mapping ISO-8859-8-I charset to ISO-8859-8.

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

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

From djelinski at openjdk.org  Fri Aug 23 10:55:07 2024
From: djelinski at openjdk.org (Daniel =?UTF-8?B?SmVsacWEc2tp?=)
Date: Fri, 23 Aug 2024 10:55:07 GMT
Subject: RFR: 8324048: (fc) Make FileKey fields final [v3]
In-Reply-To: <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
 <EtZLvS0RiTinFNVlfg5T0DI1jH-uVPPr9v1ZS3iaCHs=.ebecb457-1c54-488e-9964-15d52df5fa80@github.com>
Message-ID: <qd_Rg6Jy50vBceGRkxmeSyNitgaHhEcponc5p0Z3_8s=.c8d5d92c-c880-4427-8eac-7a45e777e72b@github.com>

On Thu, 22 Aug 2024 15:02:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8324048: Remove line break

Marked as reviewed by djelinski (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20429#pullrequestreview-2256950201

From duke at openjdk.org  Fri Aug 23 11:10:03 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Fri, 23 Aug 2024 11:10:03 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: <cFfYFo52RgmzeWDMUV6Nm2I6-zURQCzJId23YdrHH3M=.1e844acb-3337-4407-86da-6e15b606885a@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

I have attached a test case for the charset issue.

Without the charset fix, below issue is seen:

ISO-8859-8I charset testing
ISO-8859-8 bytes: 1C 1E DF FE 3F FD 
Exception in thread "main" java.io.UnsupportedEncodingException: ISO-8859-8-I
	at java.base/java.lang.String.lookupCharset(String.java:861)
	at java.base/java.lang.String.getBytes(String.java:1795)
	at iso88598.main(iso88598.java:8)


After applying the fix, able to decode characters using **ISO-8859-8-I** charset.

ISO-8859-8I charset testing
ISO-8859-8 bytes: 1C 1E DF FE 3F FD 
ISO-8859-8-I bytes: 1C 1E DF FE 3F FD 
ISO8859-8-I bytes: 1C 1E DF FE 3F FD

[iso88598.txt](https://github.com/user-attachments/files/16727747/iso88598.txt)

@jaikiran, could you please review my PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306856630
PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306859247

From jpai at openjdk.org  Fri Aug 23 11:19:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 23 Aug 2024 11:19: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: <Bqww1CSew8sO9kERs-FX6DB7lk4fB9Lzt2cOqZtgrdA=.c81dad01-f849-4e7e-8a25-b50d13029d65@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

Hello Pratiksha, this is not an area that I have knowledge in. Naoto and Justin review changes in this area and I believe they will take a look at this when they are around.

Having said that, I notice that in your comment you mention that you ran a test with this change that fixes the issue. It looks like that was tested as a standalone application? Could you add that as a jtreg test to reproduce the issue and verify the fix?

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2306873563

From bpb at openjdk.org  Fri Aug 23 15:53:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Aug 2024 15:53:03 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
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: <mWYbcteVeyzaAPaqOJx32FzadpBrNevLw-tPpG6sQeY=.16179241-c9c4-4153-b432-ba9c278c1309@github.com>

On Fri, 23 Aug 2024 03:58:37 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.
> 
> Test fix only, the change has been verified, no risk.

What happens in the test without this change if the fix for [JDK-8338696](https://bugs.openjdk.org/browse/JDK-8338696) is applied?

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

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

From bpb at openjdk.org  Fri Aug 23 16:31:07 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Aug 2024 16:31:07 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <q8GzKKN8wZQREAopgyXDlPBNhBMUQTVxC-rfiHwNlBs=.93f80845-28a8-48b4-af50-93cfcc9d4192@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <q8GzKKN8wZQREAopgyXDlPBNhBMUQTVxC-rfiHwNlBs=.93f80845-28a8-48b4-af50-93cfcc9d4192@github.com>
Message-ID: <so96H7iT2Cdo9M3B_rDJNy9w6dHGKGhCQGMw2huy_2Y=.9a04dc4f-9991-40fe-bfa8-c24246c05b95@github.com>

On Fri, 23 Aug 2024 16:24:08 GMT, SendaoYan <syan at openjdk.org> wrote:

> Without this change after the fix [JDK-8338696](https://bugs.openjdk.org/browse/JDK-8338696) is applied, the `SkippedException` do not throw any more, and the `supportsCreationTimeRead` set to true, actually on alinux3 the file in /tmp partition doesn't support create time(birth time), and create time always equals to modified time, then this test report [fails](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L126).

So you are saying that with the fix for JDK-8338696 applied, this test fails with `RuntimeException`?

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

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

From syan at openjdk.org  Fri Aug 23 16:31:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 16:31:06 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
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: <q8GzKKN8wZQREAopgyXDlPBNhBMUQTVxC-rfiHwNlBs=.93f80845-28a8-48b4-af50-93cfcc9d4192@github.com>

On Fri, 23 Aug 2024 03:58:37 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.
> 
> Test fix only, the change has been verified, no risk.

As descript in [JDK-8338884](https://bugs.openjdk.org/browse/JDK-8338884), this test will report fails `java.lang.RuntimeException: Creation time should not have changed` without this change.
On alinux3(alibaba cloud system v3) the /tmp disk partition is mounted as tmpfs filesystem, and linux doesn't support birth time with this type filesystem. 
Without this change before the fix [JDK-8338696](https://bugs.openjdk.org/browse/JDK-8338696) is applied, `then the creation time is set to the epoch (1970-01-01T00:00:00Z)` so this test will [throw](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L84) `SkippedException`. 
Without this change after the fix [JDK-8338696](https://bugs.openjdk.org/browse/JDK-8338696) is applied, the `SkippedException` do not throw any more, and the `supportsCreationTimeRead` set to true, actually on alinux3 the file in /tmp partition doesn't support create time(birth time), and create time always equals to modified time, then this test report [fails](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L126).

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

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

From bpb at openjdk.org  Fri Aug 23 16:35:17 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Aug 2024 16:35:17 GMT
Subject: Integrated: 8324048: (fc) Make FileKey fields final
In-Reply-To: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
References: <z2zjGLfXkxTPI11F-3W6IpyukVF8WK_eYgADRTAIdsQ=.89f47c97-ae51-4484-b3cb-bdc44854386a@github.com>
Message-ID: <1pfLIi0pRjIOHHQe8rRaEmqVhZgXThYncdYulN6dulA=.9ed228b8-482b-496e-966d-4de8853611c9@github.com>

On Thu, 1 Aug 2024 18:09:30 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Replace use of IDs to set FileKey fields from native with passing down an array, at the expense of an array allocation.

This pull request has now been integrated.

Changeset: 23dc3b02
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/23dc3b02468836f4c9b4303f2c7c0a7305461ce1
Stats:     70 lines in 4 files changed: 14 ins; 27 del; 29 mod

8324048: (fc) Make FileKey fields final

Reviewed-by: djelinski, alanb, jpai

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

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

From naoto at openjdk.org  Fri Aug 23 16:46:08 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 23 Aug 2024 16:46: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: <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@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

Hi,
Could you please elaborate the rationale to implement this encoding? As ISO-8859 encodings are pretty much obsolete, not sure it is worth adding this encoding now.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2307443250

From syan at openjdk.org  Fri Aug 23 16:49:06 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 16:49:06 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
In-Reply-To: <so96H7iT2Cdo9M3B_rDJNy9w6dHGKGhCQGMw2huy_2Y=.9a04dc4f-9991-40fe-bfa8-c24246c05b95@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <q8GzKKN8wZQREAopgyXDlPBNhBMUQTVxC-rfiHwNlBs=.93f80845-28a8-48b4-af50-93cfcc9d4192@github.com>
 <so96H7iT2Cdo9M3B_rDJNy9w6dHGKGhCQGMw2huy_2Y=.9a04dc4f-9991-40fe-bfa8-c24246c05b95@github.com>
Message-ID: <5WqEby6NR0zz1Cjc0I-CEOKOS2L5za0UDpNc5MsZ24Q=.b9aeb64b-51b4-4cbb-b00c-fced12a4c5ba@github.com>

On Fri, 23 Aug 2024 16:28:53 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> So you are saying that with the fix for JDK-8338696 applied, this test fails with `RuntimeException`?

Yes, without this change, with the fix for JDK-8338696 applied, this test fails with `[RuntimeException](https://github.com/openjdk/jdk/blob/master/test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#L126)`

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

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

From syan at openjdk.org  Fri Aug 23 16:54:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Fri, 23 Aug 2024 16:54:04 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
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: <a3xBEWL9XPGtyysrchVz3ovFZa5CwQzoKJ6aU7Uqcwg=.40ac17b4-9b39-4adc-9ee0-1e4ee5df9b1b@github.com>

On Fri, 23 Aug 2024 03:58:37 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.
> 
> Test fix only, the change has been verified, no risk.

To reproduce the fails, test command on most linux system:

rm -rf /dev/shm/tmp/ ; jtreg -v:fail,error -w /dev/shm/tmp -nr test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#cwd

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

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

From bpb at openjdk.org  Fri Aug 23 17:05:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 23 Aug 2024 17:05:04 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3
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: <UylcAnWLvQkebUlnibtGWDhMiJKlRvUaD37xBL2fUoQ=.05555985-3f35-4451-a923-4c7852277b69@github.com>

On Fri, 23 Aug 2024 03:58:37 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.
> 
> Test fix only, the change has been verified, no risk.

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

> 110:             supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
> 111:             // Linux system doesn't support birth time on tmpfs filesystem for now
> 112:             if( Files.getFileStore(file).type().contentEquals("tmpfs") ) {

`if( ` should be `if (` but I would suggest instead:


// Creation time read depends on statx system call support and on the file
// system storing the birth time. The tmpfs file system type does not store
// the birth time.
boolean statxIsPresent = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
if (statxIsPresent && !Files.getFileStore(file).type().contentEquals("tmpfs")) {
    supportsCreationTimeRead = true;
}

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

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

From duke at openjdk.org  Sat Aug 24 02:02:15 2024
From: duke at openjdk.org (Jason Mehrens)
Date: Sat, 24 Aug 2024 02:02:15 GMT
Subject: RFR: 8195686: ISO-8859-8-i charset cannot be decoded,
 should be mapped to ISO-8859-8
In-Reply-To: <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@github.com>
References: <kZr_o-N_jfT0QV8IP49dgVcJDaQyOfXI-2jHmQln0mU=.4b7a086e-b4a8-4089-859b-2e8599fd3fd8@github.com>
 <I0cEy87rro0hjAa2VpDP-S2RChLoruawBg4oh4qg8tw=.3a50d346-4f6b-4fc0-b275-943f356bb96f@github.com>
Message-ID: <fytEl6_pY7w-gIehGFn6yUhNopa7aMDt5swff9PYmh0=.8b1c7c10-d3a7-46d7-9b27-e39c60c299a0@github.com>

On Fri, 23 Aug 2024 16:43:18 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
>
> Hi,
> Could you please elaborate the rationale to implement this encoding? As ISO-8859 encodings are pretty much obsolete, not sure it is worth adding this encoding now.

@naotoj The origin comes from an old JavaMail ticket that Bill Shannon was working on.  The link is here: https://github.com/jakartaee/mail-api/issues/302

I'm picking up where Bill left off and @psawant19 is just addressing the matching jdk bug.  I can add the mappings to JakaraMail but Bill wanted the evaluation of root issue in the JDK before doing that. The history is in the linked ticket.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2307990303

From syan at openjdk.org  Sat Aug 24 10:50:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 24 Aug 2024 10:50:36 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
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: <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@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:

  merge Linker.nativeLinker().defaultLookup().find("statx").isPresent() and !Files.getFileStore(file).type().contentEquals("tmpfs")

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20687/files
  - new: https://git.openjdk.org/jdk/pull/20687/files/128e686d..25694d76

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

  Stats: 6 lines in 1 file changed: 1 ins; 0 del; 5 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 Aug 24 10:50:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Sat, 24 Aug 2024 10:50:36 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
In-Reply-To: <UylcAnWLvQkebUlnibtGWDhMiJKlRvUaD37xBL2fUoQ=.05555985-3f35-4451-a923-4c7852277b69@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <UylcAnWLvQkebUlnibtGWDhMiJKlRvUaD37xBL2fUoQ=.05555985-3f35-4451-a923-4c7852277b69@github.com>
Message-ID: <-26FcfR2R110LqpYM4PAW778JIyn4JCF_gmv9IS_QsY=.d3c79c8d-c37c-44ef-b385-8a6f8df7f35b@github.com>

On Fri, 23 Aug 2024 17:02:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge Linker.nativeLinker().defaultLookup().find("statx").isPresent() and !Files.getFileStore(file).type().contentEquals("tmpfs")
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 112:
> 
>> 110:             supportsCreationTimeRead = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
>> 111:             // Linux system doesn't support birth time on tmpfs filesystem for now
>> 112:             if( Files.getFileStore(file).type().contentEquals("tmpfs") ) {
> 
> `if( ` should be `if (` but I would suggest instead:
> 
> 
> // Creation time read depends on statx system call support and on the file
> // system storing the birth time. The tmpfs file system type does not store
> // the birth time.
> boolean statxIsPresent = Linker.nativeLinker().defaultLookup().find("statx").isPresent();
> if (statxIsPresent && !Files.getFileStore(file).type().contentEquals("tmpfs")) {
>     supportsCreationTimeRead = true;
> }

Thanks for your review and suggestion. The code has been updated accroding your suggestion.

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

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

From alanb at openjdk.org  Sun Aug 25 07:24:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Aug 2024 07:24: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: <Na8UyyWw50w06OmA82DKBlPb8DafD4XTLbtI5bO4PTM=.2bd106b9-66de-44ac-be69-9c4a34425e8a@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

I've added the "csr" label as this is adding support for "ISO8859-8-I".

Naoto asked me about it but I'm not 100% sure if it's an alias or a different charset. I think this topic may require input from those more familiar with charsets in environment that require bidi processing.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2308711172

From alanb at openjdk.org  Sun Aug 25 15:28:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 25 Aug 2024 15:28:03 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <_c34jkNnUaZ9qtJgMGzNWyP2npaHmuMrNzbNFEPuwik=.4d36c313-5921-49ca-b1a6-de558a47afd0@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

@bplb You may wish to comment on this. From what I can tell, this is working around seccomp config so maybe should be argued that the issue is elsewhere.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2308895336

From sgehwolf at openjdk.org  Mon Aug 26 08:06:03 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 26 Aug 2024 08:06:03 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
In-Reply-To: <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@github.com>
Message-ID: <khpiWknIfnvDxAtuyevxDsOUwb0HA_6PoZ9X3DXNuT0=.5eef60c7-9afa-4c16-8f1f-c54c563f8804@github.com>

On Sat, 24 Aug 2024 10:50:36 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.
>> 
>> 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:
> 
>   merge Linker.nativeLinker().defaultLookup().find("statx").isPresent() and !Files.getFileStore(file).type().contentEquals("tmpfs")

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

> 113:             if (statxIsPresent && !Files.getFileStore(file).type().contentEquals("tmpfs")) {
> 114:                 supportsCreationTimeRead = true;
> 115:             }

Noting here that the test could still fail on some other filesystem which might not support birth time. For example `nfs` on Linux (IIRC).

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

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

From syan at openjdk.org  Mon Aug 26 09:57:05 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 09:57:05 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
In-Reply-To: <khpiWknIfnvDxAtuyevxDsOUwb0HA_6PoZ9X3DXNuT0=.5eef60c7-9afa-4c16-8f1f-c54c563f8804@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@github.com>
 <khpiWknIfnvDxAtuyevxDsOUwb0HA_6PoZ9X3DXNuT0=.5eef60c7-9afa-4c16-8f1f-c54c563f8804@github.com>
Message-ID: <htHY2oaGBU2BBv9NB4N2Yq60wn4UpWqEhx7uexHJvik=.b5dbf897-f088-48f3-9053-5b7b9806347b@github.com>

On Mon, 26 Aug 2024 08:03:31 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   merge Linker.nativeLinker().defaultLookup().find("statx").isPresent() and !Files.getFileStore(file).type().contentEquals("tmpfs")
>
> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 115:
> 
>> 113:             if (statxIsPresent && !Files.getFileStore(file).type().contentEquals("tmpfs")) {
>> 114:                 supportsCreationTimeRead = true;
>> 115:             }
> 
> Noting here that the test could still fail on some other filesystem which might not support birth time. For example `nfs` on Linux (IIRC).

It is difficult to enumerate which file types in Linux do and do not support creation time.
How about add a function that use `stat -c` linux command line to determise support or not.


+    /**
+     * read the output of linux command `stat -c "%w" file`, if the output is "-",
+     * then the file system doesn't support birth time
+     */
+    public static boolean supportBirthTimeOnLinux(Path file) {
+        try {
+            String filePath = file.toAbsolutePath().toString();
+            ProcessBuilder pb = new ProcessBuilder("stat", "-c", "%w", filePath);
+            pb.redirectErrorStream(true);
+            Process p = pb.start();
+            BufferedReader b = new BufferedReader(new InputStreamReader(p.getInputStream()));
+            String l = b.readLine();
+            if (l != null && l.equals("-")) { return false; }
+        } catch(Exception e) {
+        }
+        return true;
+    }

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

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

From sgehwolf at openjdk.org  Mon Aug 26 10:08:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 26 Aug 2024 10:08:05 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
In-Reply-To: <htHY2oaGBU2BBv9NB4N2Yq60wn4UpWqEhx7uexHJvik=.b5dbf897-f088-48f3-9053-5b7b9806347b@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@github.com>
 <khpiWknIfnvDxAtuyevxDsOUwb0HA_6PoZ9X3DXNuT0=.5eef60c7-9afa-4c16-8f1f-c54c563f8804@github.com>
 <htHY2oaGBU2BBv9NB4N2Yq60wn4UpWqEhx7uexHJvik=.b5dbf897-f088-48f3-9053-5b7b9806347b@github.com>
Message-ID: <A2pQJO0VJeSPtZfPmLfunnD2aios9FZ6se-1qw9JFFY=.6b683f08-c841-4625-ad20-94c453ca8417@github.com>

On Mon, 26 Aug 2024 09:53:57 GMT, SendaoYan <syan at openjdk.org> wrote:

>> test/jdk/java/nio/file/attribute/BasicFileAttributeView/CreationTime.java line 115:
>> 
>>> 113:             if (statxIsPresent && !Files.getFileStore(file).type().contentEquals("tmpfs")) {
>>> 114:                 supportsCreationTimeRead = true;
>>> 115:             }
>> 
>> Noting here that the test could still fail on some other filesystem which might not support birth time. For example `nfs` on Linux (IIRC).
>
> It is difficult to enumerate which file types in Linux do and do not support creation time.
> How about add a function that use `stat -c` linux command line to determise support or not.
> 
> 
> +    /**
> +     * read the output of linux command `stat -c "%w" file`, if the output is "-",
> +     * then the file system doesn't support birth time
> +     */
> +    public static boolean supportBirthTimeOnLinux(Path file) {
> +        try {
> +            String filePath = file.toAbsolutePath().toString();
> +            ProcessBuilder pb = new ProcessBuilder("stat", "-c", "%w", filePath);
> +            pb.redirectErrorStream(true);
> +            Process p = pb.start();
> +            BufferedReader b = new BufferedReader(new InputStreamReader(p.getInputStream()));
> +            String l = b.readLine();
> +            if (l != null && l.equals("-")) { return false; }
> +        } catch(Exception e) {
> +        }
> +        return true;
> +    }

It's a possibility. I'm fine with the current "tmpfs" special case in the test, but I guess what you proposed above would be more robust. So if others are OK with such an approach, that would be fine with me as well.

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

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

From syan at openjdk.org  Mon Aug 26 12:17:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 12:17:36 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v3]
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: <YYCd-A-s7Zkgzh92CsWC9Q5asHsB7MwgAy4IIyDRe8g=.3dfeae45-a20b-471a-93ad-f1d7d0c9c1ef@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/25694d76..1614f8ee

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

  Stats: 23 lines in 1 file changed: 21 ins; 0 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  Mon Aug 26 12:17:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 12:17:36 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v2]
In-Reply-To: <A2pQJO0VJeSPtZfPmLfunnD2aios9FZ6se-1qw9JFFY=.6b683f08-c841-4625-ad20-94c453ca8417@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <4l3BYL0ma4dEi4mCtftqwJt8go0poREuxPY75_4M8wg=.7a4ef10f-b5e7-46ef-bfca-cfa7f4930235@github.com>
 <khpiWknIfnvDxAtuyevxDsOUwb0HA_6PoZ9X3DXNuT0=.5eef60c7-9afa-4c16-8f1f-c54c563f8804@github.com>
 <htHY2oaGBU2BBv9NB4N2Yq60wn4UpWqEhx7uexHJvik=.b5dbf897-f088-48f3-9053-5b7b9806347b@github.com>
 <A2pQJO0VJeSPtZfPmLfunnD2aios9FZ6se-1qw9JFFY=.6b683f08-c841-4625-ad20-94c453ca8417@github.com>
Message-ID: <118ePJ1m3gxFneDeqpMF8vks7h5E4t6E0ZSBdZddE10=.c3c3ae77-1994-4a9b-9bb1-ad46ecaa98bc@github.com>

On Mon, 26 Aug 2024 10:05:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> It is difficult to enumerate which file types in Linux do and do not support creation time.
>> How about add a function that use `stat -c` linux command line to determise support or not.
>> 
>> 
>> +    /**
>> +     * read the output of linux command `stat -c "%w" file`, if the output is "-",
>> +     * then the file system doesn't support birth time
>> +     */
>> +    public static boolean supportBirthTimeOnLinux(Path file) {
>> +        try {
>> +            String filePath = file.toAbsolutePath().toString();
>> +            ProcessBuilder pb = new ProcessBuilder("stat", "-c", "%w", filePath);
>> +            pb.redirectErrorStream(true);
>> +            Process p = pb.start();
>> +            BufferedReader b = new BufferedReader(new InputStreamReader(p.getInputStream()));
>> +            String l = b.readLine();
>> +            if (l != null && l.equals("-")) { return false; }
>> +        } catch(Exception e) {
>> +        }
>> +        return true;
>> +    }
>
> It's a possibility. I'm fine with the current "tmpfs" special case in the test, but I guess what you proposed above would be more robust. So if others are OK with such an approach, that would be fine with me as well.

Use `stat -c` linux command line to determise support `create time` or not.

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

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

From alanb at openjdk.org  Mon Aug 26 12:25:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 12:25:04 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v3]
In-Reply-To: <YYCd-A-s7Zkgzh92CsWC9Q5asHsB7MwgAy4IIyDRe8g=.3dfeae45-a20b-471a-93ad-f1d7d0c9c1ef@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <YYCd-A-s7Zkgzh92CsWC9Q5asHsB7MwgAy4IIyDRe8g=.3dfeae45-a20b-471a-93ad-f1d7d0c9c1ef@github.com>
Message-ID: <ilH3-a4cb64kyoME5ki6_DLosLBlRDg0iXjgPg5JIcc=.edc38873-0c96-4896-ba4d-163629a548fa@github.com>

On Mon, 26 Aug 2024 12:17:36 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.
>> 
>> 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 166:

> 164:             if (l != null && l.equals("-")) { return false; }
> 165:         } catch(Exception e) {
> 166:         }

This has several bugs, there is test is test infrastructure to do this correctly. My preference would be not include a launch of "stat" if possible.

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

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

From duke at openjdk.org  Mon Aug 26 13:06:03 2024
From: duke at openjdk.org (Pratiksha.Sawant)
Date: Mon, 26 Aug 2024 13:06:03 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: <pouzOQuLYjKVFeJs9bra1176CdhEAFB-N9bYBP0Jx4A=.3b7fd602-2471-4fba-b7ca-b84f5a1a8665@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

"ISO-8859-8-I" is a charset name for character encoding "ISO-8859-8".(https://en.wikipedia.org/wiki/ISO-8859-8-I).

We had found 2 files where the aliases for charsets are added in jdk code base.

?src/java.xml/share/classes/com/sun/org/apache/xerces/internal/util/EncodingMap.java?
?/make/data/charsetmapping/charsets?


?ISO-8859-8-I? charset is referenced in the headers as the charset of the email contents in few clients when the email is generated from Middle East and China. As it is supposed to be a duplicate of ISO-8859-8, and we are supporting this ISO-8859-8-I in EncodingMap.java, supporting this encoding in charsets file also makes the behaviour consistent through the JDK.

There is a ticket raised in angus-mail for similar issue :- https://github.com/eclipse-ee4j/angus-mail/issues/147

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2310164523

From syan at openjdk.org  Mon Aug 26 13:17:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 13:17:45 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v4]
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: <Tv8zhw3IibLQlRHVGICJm4eXp9pnqpfAFglWbdYuLbA=.82d97c86-807f-4b1d-b375-cadfc799f237@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 two additional commits since the last revision:

 - delete import java.io.BufferedReader; and -import java.io.InputStreamReader;
 - revert "use stat -c linux command line to determise support create time or not", and set nfs not suoport create time

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

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

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

  Stats: 25 lines in 1 file changed: 2 ins; 21 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  Mon Aug 26 13:17:45 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 13:17:45 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v3]
In-Reply-To: <ilH3-a4cb64kyoME5ki6_DLosLBlRDg0iXjgPg5JIcc=.edc38873-0c96-4896-ba4d-163629a548fa@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <YYCd-A-s7Zkgzh92CsWC9Q5asHsB7MwgAy4IIyDRe8g=.3dfeae45-a20b-471a-93ad-f1d7d0c9c1ef@github.com>
 <ilH3-a4cb64kyoME5ki6_DLosLBlRDg0iXjgPg5JIcc=.edc38873-0c96-4896-ba4d-163629a548fa@github.com>
Message-ID: <P2Wvd1wJhE1YCEsR1bEEw02d8fIMqPFoNUT-FTfMfg4=.aa60202c-25ba-4a81-b98b-eb340d8d4ac5@github.com>

On Mon, 26 Aug 2024 12:22:49 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 166:
> 
>> 164:             if (l != null && l.equals("-")) { return false; }
>> 165:         } catch(Exception e) {
>> 166:         }
> 
> This has several bugs, there is test is test infrastructure to do this correctly. My preference would be not include a launch of "stat" if possible.

The code of `launch of "stat"` has been reverted.

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

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

From syan at openjdk.org  Mon Aug 26 15:16:04 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 26 Aug 2024 15:16:04 GMT
Subject: RFR: 8338884:
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java#tmp fails on
 alinux3 [v4]
In-Reply-To: <Tv8zhw3IibLQlRHVGICJm4eXp9pnqpfAFglWbdYuLbA=.82d97c86-807f-4b1d-b375-cadfc799f237@github.com>
References: <sm4elkBd2RMX2n_F_zmTfflUYeJMjq2FHx9nbMSNHT8=.f78dfaf0-88a8-459f-b528-378e09b5b8de@github.com>
 <Tv8zhw3IibLQlRHVGICJm4eXp9pnqpfAFglWbdYuLbA=.82d97c86-807f-4b1d-b375-cadfc799f237@github.com>
Message-ID: <_qhITMigaSh5Cg1NzfI_QvKA5pi2C2sxozP3oCDWU5o=.eb1f9031-d447-44da-9c3b-515d19903509@github.com>

On Mon, 26 Aug 2024 13:17:45 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.
>> 
>> Test fix only, the change has been verified, no risk.
>
> SendaoYan has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - delete import java.io.BufferedReader; and -import java.io.InputStreamReader;
>  - revert "use stat -c linux command line to determise support create time or not", and set nfs not suoport create time

`nfs` on linux also doesn't support create time:

> mount | grep "/vmfarm "
pepsi.jvm.alibaba.net:/vmfarm on /vmfarm type nfs4 (rw,relatime,vers=4.1,rsize=1048576,wsize=1048576,namlen=255,hard,proto=tcp,port=0,timeo=600,retrans=2,sec=sys,clientaddr=11.165.41.2,local_lock=none,addr=11.158.137.189)
> stat /vmfarm/mountVmFarm.sh 
  File: ?/vmfarm/mountVmFarm.sh?
  Size: 71              Blocks: 8          IO Block: 1048576 regular file
Device: 3ch/60d Inode: 12          Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2024-02-28 17:03:54.713251462 +0800
Modify: 2020-03-03 11:56:41.548038922 +0800
Change: 2020-03-03 11:56:41.548038922 +0800
 Birth: -

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

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

From bpb at openjdk.org  Mon Aug 26 16:21:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 16:21:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <Xg0UhEELi89mTDXxO2flzvIZH1QP6jCtiTuyRXH-C14=.eff7830f-d7d5-4c11-839f-b468b48d1b3a@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Please note that this change is not based on the latest version of the file in question (c89a1c35bda9002ee687b3fa267f3ef9cba78b00).

Could you please check the Docker `seccomp` profile to verify that the filter is not obsolete?

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310582583

From abakhtin at openjdk.org  Mon Aug 26 18:12:04 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 26 Aug 2024 18:12:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <Xg0UhEELi89mTDXxO2flzvIZH1QP6jCtiTuyRXH-C14=.eff7830f-d7d5-4c11-839f-b468b48d1b3a@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <Xg0UhEELi89mTDXxO2flzvIZH1QP6jCtiTuyRXH-C14=.eff7830f-d7d5-4c11-839f-b468b48d1b3a@github.com>
Message-ID: <2drFLAJcKB4KeUgyPaac5XtONAGdS5isreb4L80GtB8=.5f3d4eb5-0ec3-4d6f-b0ec-72f24709cf58@github.com>

On Mon, 26 Aug 2024 16:18:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Please review the fix for regression on the old docker versions (before v18.04)
>> 
>> Suggest to verify if statx is permitted during initialization
>> 
>> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
>> 
>> Fallback to stat() if statx() not permitted
>> 
>> Related  jtreg tests passed
>
> Please note that this change is not based on the latest version of the file in question (c89a1c35bda9002ee687b3fa267f3ef9cba78b00).
> 
> Could you please check the Docker `seccomp` profile to verify that the filter is not obsolete?

@bplb Rebasing to the latest master does not change the situation: `statx` exists in the kernel, and `my_statx_func` is initialized by `UnixNativeDispatcher::init`. The old Docker version (Docker v17.06, in my case) does not permit statx in the default seccomp profile. As a result, any calls to statx_wrapper fail with EPERM.

I think it is some kind of regression for old Docker versions, but it could be easily fixed. I understand there is a workaround with an updated seccomp profile, but it is not easy to do in some environments.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310779181

From bpb at openjdk.org  Mon Aug 26 18:36:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 18:36:02 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <2drFLAJcKB4KeUgyPaac5XtONAGdS5isreb4L80GtB8=.5f3d4eb5-0ec3-4d6f-b0ec-72f24709cf58@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <Xg0UhEELi89mTDXxO2flzvIZH1QP6jCtiTuyRXH-C14=.eff7830f-d7d5-4c11-839f-b468b48d1b3a@github.com>
 <2drFLAJcKB4KeUgyPaac5XtONAGdS5isreb4L80GtB8=.5f3d4eb5-0ec3-4d6f-b0ec-72f24709cf58@github.com>
Message-ID: <jKMP757rMAghHAswjdR9fzJiL1ZutSzIC3nbJuXMvqs=.7d30dbb0-1edf-40e4-aefa-a7c781e08755@github.com>

On Mon, 26 Aug 2024 18:09:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please note that this change is not based on the latest version of the file in question (c89a1c35bda9002ee687b3fa267f3ef9cba78b00).
>> 
>> Could you please check the Docker `seccomp` profile to verify that the filter is not obsolete?
>
> @bplb Rebasing to the latest master does not change the situation: `statx` exists in the kernel, and `my_statx_func` is initialized by `UnixNativeDispatcher::init`. The old Docker version (Docker v17.06, in my case) does not permit statx in the default seccomp profile. As a result, any calls to statx_wrapper fail with EPERM.
> 
> I think it is some kind of regression for old Docker versions, but it could be easily fixed. I understand there is a workaround with an updated seccomp profile, but it is not easy to do in some environments.

@alexeybakhtin  It probably won't work due to seccomp, but could you maybe try reverting your change and modifying `statx_wrapper` to replace

    return (*my_statx_func)(dirfd, pathname, flags, mask, statxbuf);

with

    return syscall(__NR_statx, dirfd, pathname, flags, mask, statxbuf);


Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310822224

From abakhtin at openjdk.org  Mon Aug 26 18:55:04 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 26 Aug 2024 18:55:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Sorry, but calling __NR_statx directly also does not work, primarily because of seccomp. The native statx test (https://github.com/torvalds/linux/blob/master/samples/vfs/test-statx.c) fails exactly the same:

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310856240

From bpb at openjdk.org  Mon Aug 26 19:00:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 19:00:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>
Message-ID: <XwzjtYCaJGK9vLRogKUlfOJ6jUMD2EVedjHG1wxmMWs=.a5f224a3-2ad2-4854-b2dc-7dc9b65de3ea@github.com>

On Mon, 26 Aug 2024 18:52:41 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Sorry, but calling __NR_statx directly also does not work, primarily because of seccomp.

Thanks for verifying.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310864301

From bpb at openjdk.org  Mon Aug 26 19:27:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 19:27:03 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>
Message-ID: <CSfIJPMTojmlQgqitrcCs4D-UQvnr3BP58_4WN0C850=.99099974-8741-4f71-9951-ca9eb1054a0a@github.com>

On Mon, 26 Aug 2024 18:52:41 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Issue can be simulated on the latest docker version by removing `statx` from the syscalls.names section of the seccomp profile and run docker with modified perofile: `--security-opt seccomp=<path to seccomp.json>`

So that rather verifies that the seccomp file in question is incorrect / not current.

> Actually, there is a similar problem with `copy_file_range` added by JDK-8264744 in my environment, but is reproducible in EE docker version only

I added that one.

With respect to the current PR, one thing that is problematic is invoking statx() during the initialization of `UnixNativeDispatcher`. It would be better if the`EPERM` check were done elsewhere, although that would add more code. For example, in `stat0()`:

         // Prefer statx over stat on Linux if it's available
         RESTARTABLE(statx_wrapper(AT_FDCWD, path, flags, mask, &statx_buf), err);
         if (err == 0) {
             copy_statx_attributes(env, &statx_buf, attrs);
             return 0;
+        } else if (errno == EPERM) {
+            my_statx_func = NULL; // fall back to stat()
         } else {
             return errno;
         }
     }

This does not update the Java layer `capabilities`, however, and a similar change would be needed in several places.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310913789

From abakhtin at openjdk.org  Mon Aug 26 19:49:13 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Mon, 26 Aug 2024 19:49:13 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <3zHoFGJRXHHX8LHOyFRrCzrmCuNMF5YkSSJDrmOWYK4=.22ac2528-524d-42c1-ab77-cbae6fa55b12@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Doesn't it cause issues in concurrent calls statx_wrapper?

What is the problem with syscall during initialization? We should complete quickly because of the wrong argument

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310954224

From bpb at openjdk.org  Mon Aug 26 19:55:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 19:55:03 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <3zHoFGJRXHHX8LHOyFRrCzrmCuNMF5YkSSJDrmOWYK4=.22ac2528-524d-42c1-ab77-cbae6fa55b12@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <3zHoFGJRXHHX8LHOyFRrCzrmCuNMF5YkSSJDrmOWYK4=.22ac2528-524d-42c1-ab77-cbae6fa55b12@github.com>
Message-ID: <EuxtKMwaX9plPrKuoKmo0iq_rmpy9Fj520g6I6VIOfo=.256a043b-f0a4-4bcf-a182-34bf7de49483@github.com>

On Mon, 26 Aug 2024 19:46:07 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Doesn't it cause issues in concurrent calls statx_wrapper?

I suppose it could. I did not investigate it.

> What is the problem with syscall during initialization? We should complete quickly because of the wrong argument

It's not something that is normally desirable during initialization.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2310963740

From aturbanov at openjdk.org  Mon Aug 26 20:06:32 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Mon, 26 Aug 2024 20:06:32 GMT
Subject: RFR: 8339017: Make a couple of fields in DoubleByte static
Message-ID: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>

3 fields in `sun.nio.cs.DoubleByte.{Encoder,Decoder}` could be made 'static':
1. SS2
2. SS3
3. MAX_SINGLEBYTE

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

Commit messages:
 - [PATCH] Make a couple of fields in DoubleByte static

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

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

From alanb at openjdk.org  Mon Aug 26 20:06:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 26 Aug 2024 20:06:32 GMT
Subject: RFR: 8339017: Make a couple of fields in DoubleByte static
In-Reply-To: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
References: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
Message-ID: <XBULKfgXnUhgP1i4iWVaEBh1f4o7oa4vzfkexozUtIU=.12654240-666c-4b96-b766-53949e5260de@github.com>

On Thu, 25 Jul 2024 11:42:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in `sun.nio.cs.DoubleByte.{Encoder,Decoder}` could be made 'static':
> 1. SS2
> 2. SS3
> 3. MAX_SINGLEBYTE

src/java.base/share/classes/sun/nio/cs/DoubleByte.java line 559:

> 557:                                 implements ArrayEncoder
> 558:     {
> 559:         protected static final int MAX_SINGLEBYTE = 0xff;

Yes it can be static.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20329#discussion_r1730982985

From bpb at openjdk.org  Mon Aug 26 23:09:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 26 Aug 2024 23:09:04 GMT
Subject: RFR: 8339017: Make a couple of fields in DoubleByte static
In-Reply-To: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
References: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
Message-ID: <QSjxAPQqRm8H0OsyDt6jZUmDP2r_v_ZNksDS-DSqedM=.59fc4a92-250b-4dcf-baca-d4d1a12fb058@github.com>

On Thu, 25 Jul 2024 11:42:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in `sun.nio.cs.DoubleByte.{Encoder,Decoder}` could be made 'static':
> 1. SS2
> 2. SS3
> 3. MAX_SINGLEBYTE

Looks all right but I think @naotoj might like to review it as well.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20329#pullrequestreview-2261800387

From alanb at openjdk.org  Tue Aug 27 06:23:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 06:23:03 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <EuxtKMwaX9plPrKuoKmo0iq_rmpy9Fj520g6I6VIOfo=.256a043b-f0a4-4bcf-a182-34bf7de49483@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <3zHoFGJRXHHX8LHOyFRrCzrmCuNMF5YkSSJDrmOWYK4=.22ac2528-524d-42c1-ab77-cbae6fa55b12@github.com>
 <EuxtKMwaX9plPrKuoKmo0iq_rmpy9Fj520g6I6VIOfo=.256a043b-f0a4-4bcf-a182-34bf7de49483@github.com>
Message-ID: <dsfn_lxhMGKaxDjXPkUhxtwlcYx37wU2tWkI9HbhQ3Y=.7b8ce0f0-ece0-4803-9acf-48b2021f468b@github.com>

On Mon, 26 Aug 2024 19:51:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> What is the problem with syscall during initialization? We should complete quickly because of the wrong argument

The issue is that the proposal here is to workaround an issue that is somewhere else. In general the JDK just can't work if some system calls are blocked. Has the seccomp issue being fixed in a new docker release?

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2311665345

From abakhtin at openjdk.org  Tue Aug 27 14:43:02 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 27 Aug 2024 14:43:02 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Yes, This issue is for old Docker versions only. Seccomp profile is updated for the Docker v18.4 and up.
The current implementation allows working without `statx` if it is unavailable in the kernel and fallback to other syscalls. I suggest an additional check to verify if syscall is permitted in the system. If syscall at initialization is not allowed I can check error code at runtime and fallback to previous implementation if statx is not permitted

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2312758816

From bpb at openjdk.org  Tue Aug 27 16:01:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Aug 2024 16:01:03 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
Message-ID: <oIBycqbZSnCFux5GheB2iNfVy-Dh4EEBZJfdpQi6Bg0=.4ef1afb4-1e30-4111-bc63-35e7ac34ab82@github.com>

On Tue, 27 Aug 2024 14:40:00 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> If syscall at initialization is not allowed I can check error code at runtime and fallback to previous implementation if statx is not permitted

To avoid contention in `statx_wrapper`, perhaps you could change to using

    return syscall(__NR_statx, dirfd, pathname, flags, mask, statxbuf);

as previously suggested, and also change `my_statx_func` to be a `jboolean` which could be set to `JNI_FALSE` if the syscall gets `EPERM`? If the flag were unset twice, it might not matter.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2312952018

From alanb at openjdk.org  Tue Aug 27 16:07:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 27 Aug 2024 16:07:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
Message-ID: <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>

On Tue, 27 Aug 2024 14:40:00 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Yes, This issue is for old Docker versions only. Seccomp profile is updated for the Docker v18.4 and up. 

In that case then maybe it's better to not put a workaround into the JDK for this.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2312966391

From bpb at openjdk.org  Tue Aug 27 16:20:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Aug 2024 16:20:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <CSfIJPMTojmlQgqitrcCs4D-UQvnr3BP58_4WN0C850=.99099974-8741-4f71-9951-ca9eb1054a0a@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <kbblNIbqjYfwCglAe8nRtW5z36SJRo04jKodBvECbqU=.82c75c37-68a1-4b0f-bf63-76046d26ba02@github.com>
 <CSfIJPMTojmlQgqitrcCs4D-UQvnr3BP58_4WN0C850=.99099974-8741-4f71-9951-ca9eb1054a0a@github.com>
Message-ID: <opVUrZePhNeBprUpnaqOW8OKI2NggqYDbpDEWM3splM=.d4724988-3bd9-4c98-ac8a-c05a72d3a397@github.com>

On Mon, 26 Aug 2024 19:24:20 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Actually, there is a similar problem with `copy_file_range` added by JDK-8264744 in my environment, but is reproducible in EE docker version only

By way of comparison, we do not do any `EPERM` checks for `copy_file_range` either.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2312998568

From naoto at openjdk.org  Tue Aug 27 17:04:04 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 17:04:04 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: <kB-VZf1Utvcw8idcMTCqRjxS_E9upkH7stjwJlpEeV8=.21577be3-bcbb-4218-b804-d42c8f7bfcdb@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

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.

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

PR Comment: https://git.openjdk.org/jdk/pull/20690#issuecomment-2313086694

From naoto at openjdk.org  Tue Aug 27 17:27:09 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 27 Aug 2024 17:27:09 GMT
Subject: RFR: 8339017: Make a couple of fields in DoubleByte static
In-Reply-To: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
References: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
Message-ID: <iHl1Jnfy5ZQLQNYInUPpiuaBJT0oTlnFdJMGfhodRxg=.a1757b20-5c05-4ce3-9c06-6ded6b0dec8c@github.com>

On Thu, 25 Jul 2024 11:42:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in `sun.nio.cs.DoubleByte.{Encoder,Decoder}` could be made 'static':
> 1. SS2
> 2. SS3
> 3. MAX_SINGLEBYTE

LGTM

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20329#pullrequestreview-2264053381

From abakhtin at openjdk.org  Tue Aug 27 18:31:04 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 27 Aug 2024 18:31:04 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
Message-ID: <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>

On Tue, 27 Aug 2024 16:04:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> In that case then maybe it's better to not put a workaround into the JDK for this.

I'm not sure it is a workaround. There is a similar code for `copy_file_range` syscall, which checks errno and fallback to `sendfile` in particular cases: https://github.com/openjdk/jdk/blob/master/src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c#L189

I suggest to rewrite this PR the same way. Verify `statx` and `copy_file_range` for EPERM error code and fallback to existing alternative implementation.

It may not be so important for the jdk project, but it is critical for `statx` and `copy_file_range` backports to previous jdk versions because it causes regression in a particular environment.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2313241212

From bpb at openjdk.org  Tue Aug 27 20:14:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Aug 2024 20:14:05 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
Message-ID: <4Vm7OmbrQYG-v1Y2cPoxroNlNb15HG7SEy0BheUZcRM=.1ea567f2-9495-4dc5-ac36-34e20074a7a2@github.com>

On Tue, 27 Aug 2024 18:28:23 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Verify `statx` and `copy_file_range` for EPERM error code and fallback to existing alternative implementation.

I suppose that for copy_file_range you are suggesting to add EPERM to the switch statement at line 192 of LinuxNativeDispatcher as linked above.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2313419312

From abakhtin at openjdk.org  Tue Aug 27 21:29:18 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Tue, 27 Aug 2024 21:29:18 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <dWp-fs9LJlMM1RVk_f3YDSuI2ilJ82tTCIUOeZ3IN5w=.0903960a-560f-4d2c-babc-9e6012572828@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Right. And add a similar code for statx calls.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2313609250

From bpb at openjdk.org  Tue Aug 27 21:56:26 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 27 Aug 2024 21:56:26 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <bSUTcwKTE-MUSsX-THtXeOaOukdSp7P_73xgjOTdoVM=.280678d7-5c90-4cfe-915f-11e73513770e@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

Note also that an `EPERM` in the if-block here

https://github.com/openjdk/jdk/blob/b1b4cd429a4135840966975dd0c068fe428e2ee6/src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c#L63

would imply returning `IOS_UNSUPPORTED`.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2313644588

From alanb at openjdk.org  Wed Aug 28 09:14:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 28 Aug 2024 09:14:32 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
Message-ID: <rAPa5FamV4xDuQaEj5SNy5M7y7OaYS0Fj3NP63AOuHc=.c0aa26aa-5d9e-4091-8ff7-37bacb57749f@github.com>

On Tue, 27 Aug 2024 18:28:23 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> It may not be so important for the jdk project, but it is critical for statx and copy_file_range backports to previous jdk versions because it causes regression in a particular environment.

Is your issue with main line or with builds of JDK 21u (or 17u)? Asking because it was very surprising to see that JDK-8316304 was back ported to those releases due to the compatibility impact.

For main line and this PR, I don't think we should be testing statx in UnixNativeDispatcher.init. It's not the same thing the copy_file_range usage in the FileChannel.transferTo implementation as there it is file descriptor specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2314770435

From abakhtin at openjdk.org  Wed Aug 28 14:22:20 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Aug 2024 14:22:20 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <rAPa5FamV4xDuQaEj5SNy5M7y7OaYS0Fj3NP63AOuHc=.c0aa26aa-5d9e-4091-8ff7-37bacb57749f@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
 <rAPa5FamV4xDuQaEj5SNy5M7y7OaYS0Fj3NP63AOuHc=.c0aa26aa-5d9e-4091-8ff7-37bacb57749f@github.com>
Message-ID: <AD9LHdIGXyvtKP7pItuGdu28m8iJvhRcX0z_V00liYY=.b6fd5a56-e9d8-4d9a-932c-702d60bec61f@github.com>

On Wed, 28 Aug 2024 09:11:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Is your issue with main line or with builds of JDK 21u (or 17u)? Asking because it was very surprising to see that JDK-8316304 was back ported to those releases due to the compatibility impact.

I have this issue on JDK21u and JDK17u.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2315473392

From bpb at openjdk.org  Wed Aug 28 16:21:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 16:21:20 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
Message-ID: <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>

On Tue, 27 Aug 2024 16:04:02 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Yes, This issue is for old Docker versions only. Seccomp profile is updated for the Docker v18.4 and up.

Is it not possible to file a bug / issue against the Docker versions before v18.4?

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2315778762

From bpb at openjdk.org  Wed Aug 28 16:26:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 28 Aug 2024 16:26:19 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <rAPa5FamV4xDuQaEj5SNy5M7y7OaYS0Fj3NP63AOuHc=.c0aa26aa-5d9e-4091-8ff7-37bacb57749f@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <k5EF7eOZYQdZo6ANckiH-RGGg6rrhTwkbvhHgQTxx2I=.dcebe82d-3a03-485f-b997-11d51b1348cb@github.com>
 <rAPa5FamV4xDuQaEj5SNy5M7y7OaYS0Fj3NP63AOuHc=.c0aa26aa-5d9e-4091-8ff7-37bacb57749f@github.com>
Message-ID: <aJ5JufRxYEXRIo7jiGeRaQH7eZoxfnTyCLmaRGrEhT8=.94dda329-0f3f-4ae4-a420-58d2d0236730@github.com>

On Wed, 28 Aug 2024 09:11:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> For main line and this PR, I don't think we should be testing statx in UnixNativeDispatcher.init.

I concur.

> It's not the same thing the copy_file_range usage in the FileChannel.transferTo implementation as there it is file descriptor specific.

I'm not sure about this. If `copy_file_range` fails with `EPERM`, then I think there will be a failure instead of falling back to something else, such as the read-write loop.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2315787142

From abakhtin at openjdk.org  Wed Aug 28 23:44:37 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Aug 2024 23:44:37 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases [v2]
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <gGwd089dLew_r0HK5rPXnOV8r7lmVuFg6jzczmbyPQg=.303329a3-b70b-48e8-ac08-f522acb7dd0e@github.com>

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

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

  Verify EPERM at runtime

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20484/files
  - new: https://git.openjdk.org/jdk/pull/20484/files/fe5e07c9..ae988a25

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

  Stats: 28 lines in 3 files changed: 10 ins; 13 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/20484.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20484/head:pull/20484

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

From abakhtin at openjdk.org  Wed Aug 28 23:44:37 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Wed, 28 Aug 2024 23:44:37 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <peAWiFABYxoOqYwxa_bBk-HgtCjPc6WvdiXdR5PK8kk=.83c1e8de-fda2-4b42-acd9-7dc38561d7ae@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

I have updated the patch to verify EPERM at runtime for statx and copy_file_range syscalls

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2316414927

From bpb at openjdk.org  Thu Aug 29 00:04:19 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Aug 2024 00:04:19 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <peAWiFABYxoOqYwxa_bBk-HgtCjPc6WvdiXdR5PK8kk=.83c1e8de-fda2-4b42-acd9-7dc38561d7ae@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <peAWiFABYxoOqYwxa_bBk-HgtCjPc6WvdiXdR5PK8kk=.83c1e8de-fda2-4b42-acd9-7dc38561d7ae@github.com>
Message-ID: <Q1HNLHm7nfBrxhJxBAVGL2i8vKhiWPxqxSDNdK8Vrgg=.4ecaf6cd-7873-45d9-a228-84b22c414830@github.com>

On Wed, 28 Aug 2024 23:41:52 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> I have updated the patch to verify EPERM at runtime for statx and copy_file_range syscalls

I don't see any problems with this, assuming we need to do it in the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2316456688

From alanb at openjdk.org  Thu Aug 29 06:34:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 29 Aug 2024 06:34:20 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <Q1HNLHm7nfBrxhJxBAVGL2i8vKhiWPxqxSDNdK8Vrgg=.4ecaf6cd-7873-45d9-a228-84b22c414830@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <peAWiFABYxoOqYwxa_bBk-HgtCjPc6WvdiXdR5PK8kk=.83c1e8de-fda2-4b42-acd9-7dc38561d7ae@github.com>
 <Q1HNLHm7nfBrxhJxBAVGL2i8vKhiWPxqxSDNdK8Vrgg=.4ecaf6cd-7873-45d9-a228-84b22c414830@github.com>
Message-ID: <-ilUoeU31GCOtoeNaYCuUryZnCX1znFZ_JaC4N6XJGI=.8cc794d7-80bb-4737-815c-88589a77c2c3@github.com>

On Thu, 29 Aug 2024 00:02:02 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I have updated the patch to verify EPERM at runtime for statx and copy_file_range syscalls

Why are you changing the copy_file_range usages? Is this the same docker or seccomp config issue or is it something else? The man page for copy_file_range documents EPERM for "fd_out refers to an immutable file".  I don't know if it meant to say non-writable, in which case I assume a JDK bug if that were to happen.

As regards UnixNativeDispatcher_fstat0 and UnixNativeDispatcher_lstat0 to allow statx return EPERM. This is an undocumented error. My personal view is that we should not put this patch into the main line but if does go in then it needs a comment to explain why it handling an undocumented error.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2316814125

From aturbanov at openjdk.org  Thu Aug 29 10:00:24 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 29 Aug 2024 10:00:24 GMT
Subject: Integrated: 8339017: Make a couple of fields in DoubleByte static
In-Reply-To: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
References: <JkBh9ttZO3odu8ZDCPjoZCaeLBGlsc4adH2z2eTC8rc=.909454c7-def6-469d-9d4e-15c40a77357c@github.com>
Message-ID: <rfqakFL84zUUNqgQocadgRhXiHUmxe6PuZR7bKLwtuw=.b6bef8bb-c6a3-42a8-b550-b21356dee572@github.com>

On Thu, 25 Jul 2024 11:42:58 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> 3 fields in `sun.nio.cs.DoubleByte.{Encoder,Decoder}` could be made 'static':
> 1. SS2
> 2. SS3
> 3. MAX_SINGLEBYTE

This pull request has now been integrated.

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

8339017: Make a couple of fields in DoubleByte static

Reviewed-by: bpb, naoto

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

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

From bpb at openjdk.org  Thu Aug 29 14:49:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Aug 2024 14:49:20 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
Message-ID: <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>

On Wed, 28 Aug 2024 16:19:06 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Is it not possible to file a bug / issue against the Docker versions before v18.4?

Do we have an answer for this, i.e., filing such an issue vs. modifying the JDK?

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2317941405

From bpb at openjdk.org  Thu Aug 29 14:49:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Aug 2024 14:49:22 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases [v2]
In-Reply-To: <gGwd089dLew_r0HK5rPXnOV8r7lmVuFg6jzczmbyPQg=.303329a3-b70b-48e8-ac08-f522acb7dd0e@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <gGwd089dLew_r0HK5rPXnOV8r7lmVuFg6jzczmbyPQg=.303329a3-b70b-48e8-ac08-f522acb7dd0e@github.com>
Message-ID: <TlwKubFep8GI4frJ8S4d-G_euiMoa8zd4vVHiEFKVEs=.d1709ae0-805d-42e8-8c30-149ff7a25fa3@github.com>

On Wed, 28 Aug 2024 23:44:37 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

>> Please review the fix for regression on the old docker versions (before v18.04)
>> 
>> Suggest to verify if statx is permitted during initialization
>> 
>> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
>> 
>> Fallback to stat() if statx() not permitted
>> 
>> Related  jtreg tests passed
>
> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Verify EPERM at runtime

src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 691:

> 689:             copy_statx_attributes(env, &statx_buf, attrs);
> 690:             return;
> 691:         } else if (errno != ENOSYS && errno != EPERM) {

Why is `ENOSYS` added here? Has this also been observed?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20484#discussion_r1736379289

From abakhtin at openjdk.org  Thu Aug 29 16:13:21 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 29 Aug 2024 16:13:21 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases [v2]
In-Reply-To: <TlwKubFep8GI4frJ8S4d-G_euiMoa8zd4vVHiEFKVEs=.d1709ae0-805d-42e8-8c30-149ff7a25fa3@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <gGwd089dLew_r0HK5rPXnOV8r7lmVuFg6jzczmbyPQg=.303329a3-b70b-48e8-ac08-f522acb7dd0e@github.com>
 <TlwKubFep8GI4frJ8S4d-G_euiMoa8zd4vVHiEFKVEs=.d1709ae0-805d-42e8-8c30-149ff7a25fa3@github.com>
Message-ID: <x2NdDCY5dEElqwE9tLSiChKr5p9NHiUYUoT97zqsPh8=.59a66a88-cd19-4b2a-8bce-b415a5b279b8@github.com>

On Thu, 29 Aug 2024 14:44:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Alexey Bakhtin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Verify EPERM at runtime
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 691:
> 
>> 689:             copy_statx_attributes(env, &statx_buf, attrs);
>> 690:             return;
>> 691:         } else if (errno != ENOSYS && errno != EPERM) {
> 
> Why is `ENOSYS` added here? Has this also been observed?

No, I do not observe `ENOSYS`, but it is a common error code for an unsupported syscall. It is similar to copy_file_range.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20484#discussion_r1736609427

From abakhtin at openjdk.org  Thu Aug 29 16:24:25 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 29 Aug 2024 16:24:25 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
 <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
Message-ID: <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>

On Thu, 29 Aug 2024 14:46:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > Is it not possible to file a bug / issue against the Docker versions before v18.4?
> 
> Do we have an answer for this, i.e., filing such an issue vs. modifying the JDK?

In my case, upgrading or updating Docker version is not possible on the system. So, submitting a bug against v18 or 17 or even 16 does not make sense.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2318283205

From bpb at openjdk.org  Thu Aug 29 16:27:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 29 Aug 2024 16:27:20 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
 <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
 <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>
Message-ID: <DR6JRapqQ_KyIO7we1LaAi1Cp0RUe9SQ3AdfCurEaWo=.f7ca6f62-f599-4947-b9a9-c8feb6f969a7@github.com>

On Thu, 29 Aug 2024 16:21:21 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> In my case, upgrading or updating Docker version is not possible on the system. So, submitting a bug against v18 or 17 or even 16 does not make sense.

Okay. You mentioned a workaround:

> I think it is some kind of regression for old Docker versions, but it could be easily fixed. I understand there is a workaround with an updated seccomp profile, but it is not easy to do in some environments.

Is this not possible on the problematic system(s)?

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2318291622

From abakhtin at openjdk.org  Thu Aug 29 16:36:21 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Thu, 29 Aug 2024 16:36:21 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <DR6JRapqQ_KyIO7we1LaAi1Cp0RUe9SQ3AdfCurEaWo=.f7ca6f62-f599-4947-b9a9-c8feb6f969a7@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
 <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
 <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>
 <DR6JRapqQ_KyIO7we1LaAi1Cp0RUe9SQ3AdfCurEaWo=.f7ca6f62-f599-4947-b9a9-c8feb6f969a7@github.com>
Message-ID: <0O1ua2Msv3eKGDoLoJ55JJbq11J3cD3cHseR_H5b3v8=.e14d64c7-8a80-45e7-bd22-8716c0a25c75@github.com>

On Thu, 29 Aug 2024 16:24:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I think it is some kind of regression for old Docker versions, but it could be easily fixed. I understand there is a workaround with an updated seccomp profile, but it is not easy to do in some environments.
> 
> Is this not possible on the problematic system(s)?

According to our customer, it is problematic. This is a reason for proposing a fix in OpenJDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2318308790

From alanb at openjdk.org  Fri Aug 30 10:51:25 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 30 Aug 2024 10:51:25 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <0O1ua2Msv3eKGDoLoJ55JJbq11J3cD3cHseR_H5b3v8=.e14d64c7-8a80-45e7-bd22-8716c0a25c75@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
 <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
 <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>
 <DR6JRapqQ_KyIO7we1LaAi1Cp0RUe9SQ3AdfCurEaWo=.f7ca6f62-f599-4947-b9a9-c8feb6f969a7@github.com>
 <0O1ua2Msv3eKGDoLoJ55JJbq11J3cD3cHseR_H5b3v8=.e14d64c7-8a80-45e7-bd22-8716c0a25c75@github.com>
Message-ID: <HQHKPiqbkEnM3YO9T17jTPd6wbHK6DGMG1zEHiV83bc=.0dd0c203-b374-472c-b501-1006318b04f5@github.com>

On Thu, 29 Aug 2024 16:32:19 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> According to our customer, it is problematic. This is a reason for proposing a fix in OpenJDK.

@bplb and I discussed this yesterday and agreed that the proposal here isn't the right thing for main line. There will be other opinions but I think your options are:

- Use a newer release of docker and/or the seccomp configuration where this is fixed. You mentioned that it was fixed in v19 which appears to have been released in 2019.
- Request to jdk update maintainers to backout JDK-8338696 from 17u and 21u.
- Propose the change to 17u and 21u to allow it work in seccomp config that blocks this sys call.

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2320826202

From abakhtin at openjdk.org  Fri Aug 30 16:44:27 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 30 Aug 2024 16:44:27 GMT
Subject: RFR: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <HQHKPiqbkEnM3YO9T17jTPd6wbHK6DGMG1zEHiV83bc=.0dd0c203-b374-472c-b501-1006318b04f5@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
 <tL1jAIgvOFRmbC5Lu5W6px0CkXCJ3_EU9JbINLTv3pc=.23b69abc-fb54-44fc-9734-d68566585cae@github.com>
 <QcAndvUWQYeb4KG7AOgK-gDtpi4JWHOfBzE5z8RvsFs=.7a911618-e267-43fd-89a4-89caf880e8bf@github.com>
 <ycnto72rZiUN3hO3O6eKyqNGqN-LCLwNmuA8f9qmNpA=.06228b4e-6fd6-4a9f-bdda-5541aa0ccd49@github.com>
 <U6SUxtOa7LfEunLbTg4hfpQ68Xyl28v5bYAOdYy3_Os=.94ccc1cc-0adc-4cb8-884f-7074f01b4c8e@github.com>
 <eADg1m5BwS1bWIH1U4uKN7NFdxZYIsw5Ohiu-NgjSHQ=.41f33ac1-c190-4f8a-8702-129999223516@github.com>
 <DR6JRapqQ_KyIO7we1LaAi1Cp0RUe9SQ3AdfCurEaWo=.f7ca6f62-f599-4947-b9a9-c8feb6f969a7@github.com>
 <0O1ua2Msv3eKGDoLoJ55JJbq11J3cD3cHseR_H5b3v8=.e14d64c7-8a80-45e7-bd22-8716c0a25c75@github.com>
 <HQHKPiqbkEnM3YO9T17jTPd6wbHK6DGMG1zEHiV83bc=.0dd0c203-b374-472c-b501-1006318b04f5@github.com>
Message-ID: <3mZDYgDklabkEQO6StgRzLidrzJQih6ou38ZHCVI_A8=.19dace59-d185-4c93-9b39-c11d2aee5eaf@github.com>

On Fri, 30 Aug 2024 10:48:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> > I think it is some kind of regression for old Docker versions, but it could be easily fixed. I understand there is a workaround with an updated seccomp profile, but it is not easy to do in some environments.
>>> 
>>> Is this not possible on the problematic system(s)?
>> 
>> According to our customer, it is problematic. This is a reason for proposing a fix in OpenJDK.
>
>> According to our customer, it is problematic. This is a reason for proposing a fix in OpenJDK.
> 
> @bplb and I discussed this yesterday and agreed that the proposal here isn't the right thing for main line. There will be other opinions but I think your options are:
> 
> - Use a newer release of docker and/or the seccomp configuration where this is fixed. You mentioned that it was fixed in v19 which appears to have been released in 2019.
> - Request to jdk update maintainers to backout JDK-8338696 from 17u and 21u.
> - Propose the change to 17u and 21u to allow it work in seccomp config that blocks this sys call.

Hi @AlanBateman , @bplb 
Thank you very much for your review and suggestions. I'll try to propose the changes to 21u and 17u

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

PR Comment: https://git.openjdk.org/jdk/pull/20484#issuecomment-2321939318

From abakhtin at openjdk.org  Fri Aug 30 16:44:28 2024
From: abakhtin at openjdk.org (Alexey Bakhtin)
Date: Fri, 30 Aug 2024 16:44:28 GMT
Subject: Withdrawn: 8337966: (fs) Files.readAttributes fails with Operation not
 permitted on older docker releases
In-Reply-To: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
References: <O7rOP3pf-7yQm-Q3Regdik05LRLIjFGiv9s80OZBS6Y=.2e219926-5662-4045-8a5a-5304ae1575aa@github.com>
Message-ID: <s1J1tfVCvHMVc9v9Xw8F-tPSBgnLv6yIcqL6WE4e_ro=.7ab04e44-9f4e-4371-9798-9a7be1df6bb9@github.com>

On Wed, 7 Aug 2024 04:20:29 GMT, Alexey Bakhtin <abakhtin at openjdk.org> wrote:

> Please review the fix for regression on the old docker versions (before v18.04)
> 
> Suggest to verify if statx is permitted during initialization
> 
> statx(-1, "", AT_EMPTY_PATH, 0, &statx_buf) return EPERM if statx syscall not permitted and EBADF otherwise
> 
> Fallback to stat() if statx() not permitted
> 
> Related  jtreg tests passed

This pull request has been closed without being integrated.

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

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