From dfuchs at openjdk.org  Mon Jul  1 07:58:23 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 1 Jul 2024 07:58:23 GMT
Subject: [jdk23] Integrated: 8333849: (dc) DatagramChannel send/receive fails
 with UOE if buffer backed by memory segment allocated from shared
 arena
In-Reply-To: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
References: <weEme9slwIUDeHKp5CoO6B9atjDrBX4OCLiB1xhT9go=.3104125f-ef57-4e8f-a9eb-f34174650a74@github.com>
Message-ID: <T9dNj6pBCpQs38pjcVU-rYfh1VBGjQvnJJdpFB2cmbw=.1bffc4ce-2a84-4f2e-8acc-5368592e91cf@github.com>

On Fri, 28 Jun 2024 14:03:06 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> Hi, this is a clean backport of [JDK-8333849](https://bugs.openjdk.org/browse/JDK-8333849) to JDK 23.
> 
> JDK-8333849 fixes a bug that prevents using ByteBuffers derived from MemorySegments allocated from a shared arena with DatagramChannel. I believe the fix is important enough to justify backporting it to JDK 23 in this phase.
> 
> The fix, and test, have soaked in the mainline for two weeks already - without causing any regression.

This pull request has now been integrated.

Changeset: e78c6821
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e78c6821429c7e769b2c73ceb3c9bd366851012c
Stats:     509 lines in 2 files changed: 506 ins; 0 del; 3 mod

8333849: (dc) DatagramChannel send/receive fails with UOE if buffer backed by memory segment allocated from shared arena

Reviewed-by: alanb
Backport-of: e7dc76b5776e05082281fb640d1592479cfe9e6b

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

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

From jpai at openjdk.org  Tue Jul  2 12:54:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Jul 2024 12:54:25 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
Message-ID: <bXzxHkA82QjqInsfwxbwx1wUT9Jtt-qxFCIQw9ybqDE=.e1b53c7a-ceca-49e2-9023-2a8593336f0f@github.com>

On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Marked as reviewed by jpai (Reviewer).

Hello Eirik, the latest changes in this PR (`292d6801`) look good to me. However, these changes cause some (expected) compilation failures in some of the internal classes within some Oracle specific JDK classes. Those tests aren't accessible for external contributors. I will be updating that code to address those failures. That would mean that the integration of this PR will have to be co-ordinated. 

Can you issue a `/integrate delegate` command on this PR so that it then allows me to do the actual integration along with the Oracle side of changes?

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

PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-2153714037
PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2203081198

From lancea at openjdk.org  Tue Jul  2 18:35:26 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 2 Jul 2024 18:35:26 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
Message-ID: <thXc7_Xh5_KpBk66SWuo2AV8Tr9w3aqic3N2Bp978XM=.b2ee8851-2ae8-40fe-9fcc-b5a09a836923@github.com>

On Sat, 29 Jun 2024 18:24:46 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
>> 
>> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
>> 
>> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
>> 
>> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
>> 
>> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
>> 
>> As a note to reviewers, this PR includes the following intended updates:
>> 
>> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
>> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
>> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
>> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
>> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
>> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
>> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
>> - Updated copyright in all affected files
>> 
>> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
>> 
>> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
>> 
>> 
>> make test TEST="test/jdk/java/util/jar"
>> make test TEST="test/jdk/java/util/zip"
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename SymlinkTest.verifyExternalAttrs to verifyExternalFileAttributes
>  - Rename ZipFileSystem.Entry.posixPerms to externalFileAttributes
>  - For clarity, use "externalFileAttributes" instead of "externalAttributes"
>  - Merge branch 'master' into zipentry-external-attributes
>  - Update copyright years for 2024
>  - Merge branch 'master' into zipentry-external-attributes
>  - Rename ZipEntry.extraAttributes to ZipEntry.externalAttributes

Marked as reviewed by lancea (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/16952#pullrequestreview-2154579839

From eirbjo at openjdk.org  Tue Jul  2 18:41:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 2 Jul 2024 18:41:19 GMT
Subject: RFR: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes [v5]
In-Reply-To: <bXzxHkA82QjqInsfwxbwx1wUT9Jtt-qxFCIQw9ybqDE=.e1b53c7a-ceca-49e2-9023-2a8593336f0f@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
 <NNWjbsxwx1b3OLHAN6avmyid8euK7RbjqYx-6VJHLN0=.6cdcaba3-1e9d-4053-9a05-31c72676ec38@github.com>
 <bXzxHkA82QjqInsfwxbwx1wUT9Jtt-qxFCIQw9ybqDE=.e1b53c7a-ceca-49e2-9023-2a8593336f0f@github.com>
Message-ID: <h3VsPV16PFLI7Ep4tW9GOckuUB5rX17fPqpmqeysDVI=.8e7de5bf-cfb3-4e62-acd1-de5bbe19f665@github.com>

On Tue, 2 Jul 2024 12:51:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can you issue a `/integrate delegate` command on this PR so that it then allows me to do the actual integration along with the Oracle side of changes?

Done. And big thanks for your help getting this long-lasting change across the finish line!

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

PR Comment: https://git.openjdk.org/jdk/pull/16952#issuecomment-2204042346

From eirbjo at openjdk.org  Wed Jul  3 04:39:23 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 3 Jul 2024 04:39:23 GMT
Subject: Integrated: 8321274: Rename ZipEntry.extraAttributes to
 ZipEntry.externalFileAttributes
In-Reply-To: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
References: <EcxkA01kaWJwev-16dqYXi7rODrgCBzWJRHL5A4rjA0=.7e65e59b-3086-463a-9558-04abfe1b0782@github.com>
Message-ID: <MO4f7X0U2H7gxex_u7bePP6jq2q2Q2-557NkGNlUv4Q=.af9ce0f2-b778-4ed9-9d89-e3463d053f90@github.com>

On Mon, 4 Dec 2023 15:34:34 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please consider this PR which suggests we rename `ZipEntry.extraAttributes` to `ZipEntry.externalFileAttributes`.
> 
> This field was introduced in [JDK-8218021](https://bugs.openjdk.org/browse/JDK-8218021), originally under the name `ZipEntry.posixPerms`. [JDK-8250968](https://bugs.openjdk.org/browse/JDK-8250968) later renamed the field to `ZipEntry.extraAttributes` and extended its semantics to hold the full two-byte value of the `external file attributes` field, as defined by `APPNOTE.TXT`
> 
> The name `extraAttributes` is misleading. It has nothing to do with the `extra field` (an unrelated structure defined in `APPNOTE.TXT`), although the name indicates it does.
> 
> To prevent confusion and make life easier for future maintainers, I suggest we rename this field to `ZipEntry.externalFileAttributes` and update related methods, parameters and comments accordingly.
> 
> While this change is a straightforward renaming, reviewers should consider whether it carries its weight, especially considering it might complicate future backports. 
> 
> As a note to reviewers, this PR includes the following intended updates:
> 
> - Rename `ZipEntry.extraAttributes` and any references to this field to `ZipEntry.externalFileAttributes`
> - Update `JavaUtilZipFileAccess` to similarly rename methods to `setExternalFileAttributes` and `getExternalFileAttributes` 
> - Rename the field `JarSigner.extraAttrsDetected` to `JarSigner.externalFileAttrsDetected`
> - Rename a local variable in `JarSigner.writeEntry` to `externalFileAttributes`
> - Rename `s.s.t.jarsigner.Main.extraAttrsDetected` to `externalFileAttributesDetected`
> - Rename resource string key names in `s.s.t.jarsigner.Resources` from `extra.attributes.detected` to `external.file.attributes.detected`
> - Rename method `SymlinkTest.verifyExtraAttrs` to `verifyExternalFileAttributes`, also updated two references to 'extra attributes' in this method
> - Updated copyright in all affected files
> 
> If the resource file changes should be dropped and instead handled via `msgdop` updates, let me know and I can revert the non-default files.
> 
> I did a search across the code base to find 'extraAttrs', 'extra.attr' after these updates, and found nothing related to zip/jar. The `zip` and `jar` tests run clean:
> 
> 
> make test TEST="test/jdk/java/util/jar"
> make test TEST="test/jdk/java/util/zip"

This pull request has now been integrated.

Changeset: d51141e5
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d51141e5fc84f9f933e78d0eb25af86e41798ad5
Stats:     56 lines in 12 files changed: 0 ins; 4 del; 52 mod

8321274: Rename ZipEntry.extraAttributes to ZipEntry.externalFileAttributes

Reviewed-by: lancea, jpai

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

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

From clanger at openjdk.org  Fri Jul  5 05:29:44 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Fri, 5 Jul 2024 05:29:44 GMT
Subject: [jdk23] RFR: 8334297: (so)
 java/nio/channels/SocketChannel/OpenLeak.java should not depend on
 SecurityManager
Message-ID: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>

Hi all,

This pull request contains a backport of [JDK-8334297](https://bugs.openjdk.org/browse/JDK-8334297), commit [50bed6c6](https://github.com/openjdk/jdk/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.

The commit being backported was authored by Daniel Fuchs on 19 Jun 2024 and was reviewed by Alan Bateman.

Thanks!

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

Commit messages:
 - Backport 50bed6c67b1edd7736bdf79308d135a4e1047ff0

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

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

From mbaesken at openjdk.org  Fri Jul  5 07:10:17 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 5 Jul 2024 07:10:17 GMT
Subject: [jdk23] RFR: 8334297: (so)
 java/nio/channels/SocketChannel/OpenLeak.java should not depend on
 SecurityManager
In-Reply-To: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
References: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
Message-ID: <CE320-MB02bGJxW4AxYsNvJVYoJ9EHQFhNv981cF-ik=.27e506e6-d6e3-48e2-93c0-96813b56408c@github.com>

On Fri, 5 Jul 2024 05:24:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8334297](https://bugs.openjdk.org/browse/JDK-8334297), commit [50bed6c6](https://github.com/openjdk/jdk/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 19 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Marked as reviewed by mbaesken (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20045#pullrequestreview-2160088681

From dfuchs at openjdk.org  Fri Jul  5 07:52:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 Jul 2024 07:52:18 GMT
Subject: [jdk23] RFR: 8334297: (so)
 java/nio/channels/SocketChannel/OpenLeak.java should not depend on
 SecurityManager
In-Reply-To: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
References: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
Message-ID: <k9A0V5C_g3Jd2AQxvsj8W05FYSYk8AlBhiSRkW37kRU=.9de69790-3847-49ca-8863-516d6ac470cc@github.com>

On Fri, 5 Jul 2024 05:24:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8334297](https://bugs.openjdk.org/browse/JDK-8334297), commit [50bed6c6](https://github.com/openjdk/jdk/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 19 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Marked as reviewed by dfuchs (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20045#pullrequestreview-2160157340

From dfuchs at openjdk.org  Fri Jul  5 10:56:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 5 Jul 2024 10:56:29 GMT
Subject: RFR: 8335771: Improve stability of java/nio/channels/DatagramChannel
 tests
Message-ID: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@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.

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

Commit messages:
 - 8335771

Changes: https://git.openjdk.org/jdk/pull/20050/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20050&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8335771
  Stats: 367 lines in 11 files changed: 264 ins; 20 del; 83 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 clanger at openjdk.org  Sat Jul  6 20:03:41 2024
From: clanger at openjdk.org (Christoph Langer)
Date: Sat, 6 Jul 2024 20:03:41 GMT
Subject: [jdk23] Integrated: 8334297: (so)
 java/nio/channels/SocketChannel/OpenLeak.java should not depend on
 SecurityManager
In-Reply-To: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
References: <Y6KYjucG9rLCpgcqwTD_uHKs9H8PS9B1SLA3v3EppXE=.c2b29038-4e4f-423c-842c-ec226ef97796@github.com>
Message-ID: <7RTwS8oopCi3kEGcEWPmhtBgBWYnX0HLvP_XvQU1e6g=.cdce2251-3d61-4459-887c-95e1a848a25f@github.com>

On Fri, 5 Jul 2024 05:24:09 GMT, Christoph Langer <clanger at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of [JDK-8334297](https://bugs.openjdk.org/browse/JDK-8334297), commit [50bed6c6](https://github.com/openjdk/jdk/commit/50bed6c67b1edd7736bdf79308d135a4e1047ff0) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by Daniel Fuchs on 19 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: b415b981
Author:    Christoph Langer <clanger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b415b981397395eac298dfc841d1a9d012f62501
Stats:     93 lines in 1 file changed: 82 ins; 0 del; 11 mod

8334297: (so) java/nio/channels/SocketChannel/OpenLeak.java should not depend on SecurityManager

Reviewed-by: mbaesken, dfuchs
Backport-of: 50bed6c67b1edd7736bdf79308d135a4e1047ff0

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

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

From alanb at openjdk.org  Mon Jul  8 11:35:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Jul 2024 11:35:33 GMT
Subject: RFR: 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: <OshZ9h3WrAa8VxUjdnf69QZM4IJjFYjl71VIpbCUVUE=.ba62f5e0-d6bc-4a5f-975b-9ad6c7505b9e@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.

There are several tests modified to introduce some awkward control flow, specifically there are now condition and then code in the body conditionally doing "continue".  It would be a lot more readable to have the condition in one place in each of these loops.

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

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

From alanb at openjdk.org  Mon Jul  8 11:40:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 8 Jul 2024 11:40:33 GMT
Subject: RFR: 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: <2wQ2eZdysOKperNxyxxY-tSasCl3EOueFe8BwaN3Uk8=.0593ed0e-eb71-47a3-a154-dba6e2ece960@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.

test/jdk/java/nio/channels/DatagramChannel/NotBound.java line 29:

> 27:  *     the channel's socket to be bound to a local address. This test may fail
> 28:  *     intermittently on macOS if other datagram channel tests are running
> 29:  *     concurrently on the same host.

I don't think we should add this comment. Instead, if there is interference possible on the same host then we should create a TEST.properties in this directory with `exclusiveAccess.dirs=.` so that the tests don't run concurrently.

test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 65:

> 63:             if (((InetSocketAddress)dc.getLocalAddress()).getPort() == port) {
> 64:                 if (i < MAX_TRIES - 1) {
> 65:                     System.out.format("Refuser port has been reused by dc: %s, retrying...%n",

I think this test is a JUnit test, in which case trace messages should probably go to System.err so that they are inlined with other test output rather than in a separate section of the .jtr file.

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

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

From dfuchs at openjdk.org  Mon Jul  8 15:10:33 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 8 Jul 2024 15:10:33 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests
In-Reply-To: <2wQ2eZdysOKperNxyxxY-tSasCl3EOueFe8BwaN3Uk8=.0593ed0e-eb71-47a3-a154-dba6e2ece960@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <2wQ2eZdysOKperNxyxxY-tSasCl3EOueFe8BwaN3Uk8=.0593ed0e-eb71-47a3-a154-dba6e2ece960@github.com>
Message-ID: <ALi7Phgs2Vo92twuSQ9zSHrmX6StEdzf7Zvj_CrRQlM=.7c572f19-77b0-403e-958c-62fcd8cacc86@github.com>

On Mon, 8 Jul 2024 11:36:01 GMT, Alan Bateman <alanb 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.
>
> test/jdk/java/nio/channels/DatagramChannel/NotBound.java line 29:
> 
>> 27:  *     the channel's socket to be bound to a local address. This test may fail
>> 28:  *     intermittently on macOS if other datagram channel tests are running
>> 29:  *     concurrently on the same host.
> 
> I don't think we should add this comment. Instead, if there is interference possible on the same host then we should create a TEST.properties in this directory with `exclusiveAccess.dirs=.` so that the tests don't run concurrently.

OK. Note that interference can also come from other tests in other directories (like DatagramSocket tests in jdk/java/net/..) or from system processes (like syslogd on macOS which binds to an ephemeral port).

> test/jdk/java/nio/channels/DatagramChannel/SelectWhenRefused.java line 65:
> 
>> 63:             if (((InetSocketAddress)dc.getLocalAddress()).getPort() == port) {
>> 64:                 if (i < MAX_TRIES - 1) {
>> 65:                     System.out.format("Refuser port has been reused by dc: %s, retrying...%n",
> 
> I think this test is a JUnit test, in which case trace messages should probably go to System.err so that they are inlined with other test output rather than in a separate section of the .jtr file.

Good point.

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

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

From aturbanov at openjdk.org  Tue Jul  9 19:51:23 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 9 Jul 2024 19:51:23 GMT
Subject: RFR: 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: <FK2tUEr4B1pRU9qvDtXOh9EyglBdLObLcZtRsYO-b0I=.31babb3d-6227-480f-a279-94f226658343@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.

test/jdk/java/nio/channels/DatagramChannel/MulticastSendReceiveTests.java line 115:

> 113:                 if (sa == null) {
> 114:                     if (expectedSender != null) {
> 115:                         if (elapsed  > 4800) {

Suggestion:

                        if (elapsed > 4800) {

test/jdk/java/nio/channels/DatagramChannel/Promiscuous.java line 115:

> 113:                 if (sa == null) {
> 114:                     if (datagramExpected) {
> 115:                         if (elapsed  > 4800) {

Suggestion:

                        if (elapsed > 4800) {

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

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

From dfuchs at openjdk.org  Wed Jul 10 20:09:58 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jul 2024 20:09:58 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v2]
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: <h8rfZAFSSlaHpF_sPNl5qwRMJsZ3grTYMMcmgpgCGHo=.6622aa52-8fca-4889-8b4c-97fe36947166@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 two additional commits since the last revision:

 - Review feedback: avoid continue
 - Review feedback

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

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

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

  Stats: 49 lines in 6 files changed: 16 ins; 11 del; 22 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  Wed Jul 10 20:10:00 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 10 Jul 2024 20:10:00 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests
In-Reply-To: <OshZ9h3WrAa8VxUjdnf69QZM4IJjFYjl71VIpbCUVUE=.ba62f5e0-d6bc-4a5f-975b-9ad6c7505b9e@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <OshZ9h3WrAa8VxUjdnf69QZM4IJjFYjl71VIpbCUVUE=.ba62f5e0-d6bc-4a5f-975b-9ad6c7505b9e@github.com>
Message-ID: <NB7FNADlh2qeigHBzrlMFVHtWw7l_4NWkf9SwIIlBCQ=.4b2ddebf-76b6-41c7-9849-8f0c686a1dd6@github.com>

On Mon, 8 Jul 2024 11:33:24 GMT, Alan Bateman <alanb 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.
>
> There are several tests modified to introduce some awkward control flow, specifically there are now condition and then code in the body conditionally doing "continue".  It would be a lot more readable to have the condition in one place in each of these loops.

@AlanBateman I have pushed an updated which hopefully will make things a bit better.

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

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

From jpai at openjdk.org  Fri Jul 12 12:00:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Jul 2024 12:00:01 GMT
Subject: RFR: 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java
 leaves around a FIFO file upon test completion
Message-ID: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>

Can I please get a review of this test-only change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8336301?

The update in this PR, marks the FIFO file to be deleted upon JVM exit so that it isn't left around causing any subsequent process reading that file to block forever.

After this change, I've locally verified that this file isn't left around irrespective of whether or not the test passes.

The test continues to pass with this change. tier2 testing with this change is currently in progress.

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

Commit messages:
 - 8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion

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

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

From alanb at openjdk.org  Fri Jul 12 12:08:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Jul 2024 12:08:54 GMT
Subject: RFR: 8336301:
 test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO
 file upon test completion
In-Reply-To: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
References: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
Message-ID: <sAc7zHjlDo5X78gE2-ihlfjn26fdWX8kv8wz73YKrXQ=.90e55cac-b135-4608-9f93-bb797a0e1e82@github.com>

On Fri, 12 Jul 2024 11:55:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8336301?
> 
> The update in this PR, marks the FIFO file to be deleted upon JVM exit so that it isn't left around causing any subsequent process reading that file to block forever.
> 
> After this change, I've locally verified that this file isn't left around irrespective of whether or not the test passes.
> 
> The test continues to pass with this change. tier2 testing with this change is currently in progress.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20156#pullrequestreview-2174571597

From jpai at openjdk.org  Fri Jul 12 12:57:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 12 Jul 2024 12:57:51 GMT
Subject: [jdk23] RFR: 8334719: (se) Deferred close of SelectableChannel may
 result in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
References: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
Message-ID: <S5yUq97j-uX1oPHYZAzxIXYWpeEPvSJj25gRDFBsA_c=.7f83c632-2b4f-4bd4-ae6d-767bc320138c@github.com>

On Thu, 27 Jun 2024 04:46:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would like to backport this bug fix for a P3 issue into jdk23 branch. The backport is clean and the original fix was reviewed in mainline https://github.com/openjdk/jdk/pull/19879.

I plan to integrate this jdk23 backport on Monday before RDP2 starts later next week. I've been watching for any failures in this area after this fix in master branch and so far haven't seen any.

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

PR Comment: https://git.openjdk.org/jdk/pull/19920#issuecomment-2225519148

From konstantin.nisht at jetbrains.com  Fri Jul 12 15:06:21 2024
From: konstantin.nisht at jetbrains.com (Konstantin Nisht)
Date: Fri, 12 Jul 2024 17:06:21 +0200
Subject: Using NIO FS in java.util.zip.ZipFile
Message-ID: <CAMQu2QCWb2m65OuRO5R7QLE7tT6PWezdqPHpxWdMXhnFq=tYoA@mail.gmail.com>

Hello everyone,

In JetBrains, we are working on the improvement of interaction with WSL.
Due to a bug in Windows, certain interaction with WSL filesystem is
unreasonably slow:
https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL
The reproducer uses plain Java IO API, so the problem is not in our
codebase. We think that it is possible to fix it by using Java NIO with a
custom `java.nio.file.spi.FileSystemProvider` (which we also need for other
purposes), but there is no way of currently doing it for
`java.util.zip.ZipFile`.

We have an idea of a fix: one can observe that `ZipFile` uses
`java.io.RandomAccessFile` internally, which has a similar interface to
`SeekableByteChannel`. We attempted to patch JDK in order for `ZipFile` to
use `FileChannel` (https://github.com/JetBrains/JetBrainsRuntime/pull/413),
and noticed the following issues:
1. On Windows, `RandomAccessFile` opens a file without `FILE_SHARE_DELETE`
mode. `FileChannel`, on the contrary, does open a file in this mode, which
results in subtle differences reflected in the test `TestZipError.java`.
See more in
https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753
. I suspect that it is possible to fix by the use of
`ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more
complicated.
2. A more serious issue, `FileChannel` performs reading and writing using
direct buffers. It breaks an (implicit?) contract that by default JVM does
not allocate memory-mapped files, as reflected by the test
`LimitDirectMemory.java`.

Currently, we are going to apply the proposed patch to our builds, but we
would like to hear your thoughts on whether it is possible to include it in
the upstream of OpenJDK.

Best regards,
Konstantin Nisht,
JetBrains.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240712/fc6005ee/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jul 12 16:11:24 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Jul 2024 17:11:24 +0100
Subject: Using NIO FS in java.util.zip.ZipFile
In-Reply-To: <CAMQu2QCWb2m65OuRO5R7QLE7tT6PWezdqPHpxWdMXhnFq=tYoA@mail.gmail.com>
References: <CAMQu2QCWb2m65OuRO5R7QLE7tT6PWezdqPHpxWdMXhnFq=tYoA@mail.gmail.com>
Message-ID: <b6a0d742-dca0-4908-803b-cd7dbee55d82@oracle.com>



On 12/07/2024 16:06, Konstantin Nisht wrote:
> Hello everyone,
>
> In JetBrains, we are working on the improvement of interaction with 
> WSL. Due to a bug in Windows, certain interaction with WSL filesystem 
> is unreasonably slow: 
> https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL

Is there a brief summary on what the performance is?


> The reproducer uses plain Java IO API, so the problem is not in our 
> codebase. We think that it is possible to fix it by using Java NIO 
> with a custom `java.nio.file.spi.FileSystemProvider` (which we also 
> need for other purposes), but there is no way of currently doing it 
> for `java.util.zip.ZipFile`.
>
> We have an idea of a fix: one can observe that `ZipFile` uses 
> `java.io.RandomAccessFile` internally, which has a similar interface 
> to `SeekableByteChannel`. We attempted to patch JDK in order for 
> `ZipFile` to use `FileChannel` 
> (https://github.com/JetBrains/JetBrainsRuntime/pull/413), and noticed 
> the following issues:
> 1. On Windows, `RandomAccessFile` opens a file without 
> `FILE_SHARE_DELETE` mode. `FileChannel`, on the contrary, does open a 
> file in this mode, which results in subtle differences reflected in 
> the test `TestZipError.java`. See more in 
> https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753 
> . I suspect that it is possible to fix by the use of 
> `ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more 
> complicated.

As it happens, Brian Burkhalter and I have been noodling on a 
re-implementation of java.io, including RandomFileAccess that sits on 
FileChannel. It sets up the FileChannel to not be interruptible as that 
java.io is not interruptible. We also have prototype changes to ZipFile 
to cleanup how OPEN_DELETE works. The motive for these prototypes is 
virtual threads. The main hurdle is startup performance, we still have 
some regressions due to some additional class loading + code executed 
that need to be worked on. The prototype we have handles 
FILE_SHARE_DELETE so there are no observable behavioral differences.


> 2. A more serious issue, `FileChannel` performs reading and writing 
> using direct buffers. It breaks an (implicit?) contract that by 
> default JVM does not allocate memory-mapped files, as reflected by the 
> test `LimitDirectMemory.java`.
There is nothing to prohibit JDK classes from using direct buffers or do 
memory mapping, there are several examples of this already.

-Alan

From konstantin.nisht at jetbrains.com  Fri Jul 12 16:46:36 2024
From: konstantin.nisht at jetbrains.com (Konstantin Nisht)
Date: Fri, 12 Jul 2024 18:46:36 +0200
Subject: Using NIO FS in java.util.zip.ZipFile
In-Reply-To: <b6a0d742-dca0-4908-803b-cd7dbee55d82@oracle.com>
References: <CAMQu2QCWb2m65OuRO5R7QLE7tT6PWezdqPHpxWdMXhnFq=tYoA@mail.gmail.com>
 <b6a0d742-dca0-4908-803b-cd7dbee55d82@oracle.com>
Message-ID: <CAMQu2QBhh_Y0YHjVWhmx+7hnM70K3EUiNy+=U9ahYPnmUtSB1g@mail.gmail.com>

> Is there a brief summary on what the performance is?
It takes 1 minute 20 seconds to open a 12 kb zip file located on the Linux
side of WSL from Windows. The same file can be opened in 0.02 seconds if
located on Windows.
This problem is in the implementation of 9P by Microsoft, but it is quite
difficult to workaround it, especially when we have clients that use pure
java.io.

> The motive for these prototypes is virtual threads.
Could you clarify how FileChannel helps here?


On Fri, Jul 12, 2024 at 6:11?PM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 12/07/2024 16:06, Konstantin Nisht wrote:
> > Hello everyone,
> >
> > In JetBrains, we are working on the improvement of interaction with
> > WSL. Due to a bug in Windows, certain interaction with WSL filesystem
> > is unreasonably slow:
> >
> https://youtrack.jetbrains.com/issue/IJPL-149160/java.util.zip.ZipFile-is-slow-on-WSL
>
> Is there a brief summary on what the performance is?
>
>
> > The reproducer uses plain Java IO API, so the problem is not in our
> > codebase. We think that it is possible to fix it by using Java NIO
> > with a custom `java.nio.file.spi.FileSystemProvider` (which we also
> > need for other purposes), but there is no way of currently doing it
> > for `java.util.zip.ZipFile`.
> >
> > We have an idea of a fix: one can observe that `ZipFile` uses
> > `java.io.RandomAccessFile` internally, which has a similar interface
> > to `SeekableByteChannel`. We attempted to patch JDK in order for
> > `ZipFile` to use `FileChannel`
> > (https://github.com/JetBrains/JetBrainsRuntime/pull/413), and noticed
> > the following issues:
> > 1. On Windows, `RandomAccessFile` opens a file without
> > `FILE_SHARE_DELETE` mode. `FileChannel`, on the contrary, does open a
> > file in this mode, which results in subtle differences reflected in
> > the test `TestZipError.java`. See more in
> >
> https://github.com/JetBrains/JetBrainsRuntime/pull/413#issuecomment-2218299753
> > . I suspect that it is possible to fix by the use of
> > `ExtendedOpenOption.NOSHARE_DELETE`, but the patch would be more
> > complicated.
>
> As it happens, Brian Burkhalter and I have been noodling on a
> re-implementation of java.io, including RandomFileAccess that sits on
> FileChannel. It sets up the FileChannel to not be interruptible as that
> java.io is not interruptible. We also have prototype changes to ZipFile
> to cleanup how OPEN_DELETE works. The motive for these prototypes is
> virtual threads. The main hurdle is startup performance, we still have
> some regressions due to some additional class loading + code executed
> that need to be worked on. The prototype we have handles
> FILE_SHARE_DELETE so there are no observable behavioral differences.
>
>
> > 2. A more serious issue, `FileChannel` performs reading and writing
> > using direct buffers. It breaks an (implicit?) contract that by
> > default JVM does not allocate memory-mapped files, as reflected by the
> > test `LimitDirectMemory.java`.
> There is nothing to prohibit JDK classes from using direct buffers or do
> memory mapping, there are several examples of this already.
>
> -Alan
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240712/e01a5315/attachment.htm>

From Alan.Bateman at oracle.com  Fri Jul 12 16:58:07 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Jul 2024 17:58:07 +0100
Subject: Using NIO FS in java.util.zip.ZipFile
In-Reply-To: <CAMQu2QBhh_Y0YHjVWhmx+7hnM70K3EUiNy+=U9ahYPnmUtSB1g@mail.gmail.com>
References: <CAMQu2QCWb2m65OuRO5R7QLE7tT6PWezdqPHpxWdMXhnFq=tYoA@mail.gmail.com>
 <b6a0d742-dca0-4908-803b-cd7dbee55d82@oracle.com>
 <CAMQu2QBhh_Y0YHjVWhmx+7hnM70K3EUiNy+=U9ahYPnmUtSB1g@mail.gmail.com>
Message-ID: <47ac5d34-43e1-41d9-9a06-b302a38e4f5f@oracle.com>



On 12/07/2024 17:46, Konstantin Nisht wrote:
> > Is there a brief summary on what the performance is?
> It takes 1 minute 20 seconds to open a 12 kb zip file located on the 
> Linux side of WSL from Windows. The same file can be opened in 0.02 
> seconds if located on Windows.
> This problem is in the implementation of 9P by Microsoft, but it is 
> quite difficult to workaround it, especially when we have clients that 
> use pure java.io 
> <https://urldefense.com/v3/__http://java.io__;!!ACWV5N9M2RV99hQ!KowmBF66mgxvmW_n3a0ATp5w0P9Go4mGHYtZF_iLFsfLWCc9J3qA4t8f_BiQ-1OBthJeiIMQ4dNkEG9w11sY0eQ7gcRsqZg$>. 
>
>
> > The motive for these prototypes is virtual threads.
> Could you clarify how FileChannel helps here?

Essentially the same reason that Socket, DatagramSocket etc. were 
changed to use NIO with JEP 353 JEP 373. There is significant surgery 
requirement to allow virtual threads relase their carrier for file 
operations. This is not something for the short term of course, I'm just 
pointing out other efforts to re-implement RAF that is not observable 
except a very small startup regression at this point.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240712/ba5b5e34/attachment.htm>

From jpai at openjdk.org  Sat Jul 13 02:21:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 13 Jul 2024 02:21:55 GMT
Subject: RFR: 8336301:
 test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO
 file upon test completion
In-Reply-To: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
References: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
Message-ID: <_FREAEJWz7LoTnJTBPt-3R-C3xlLJz8E0nsYsLDglDU=.23338694-a9a1-4961-9209-9fce2407215e@github.com>

On Fri, 12 Jul 2024 11:55:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8336301?
> 
> The update in this PR, marks the FIFO file to be deleted upon JVM exit so that it isn't left around causing any subsequent process reading that file to block forever.
> 
> After this change, I've locally verified that this file isn't left around irrespective of whether or not the test passes.
> 
> The test continues to pass with this change. tier2 testing with this change is currently in progress.

Thank you Alan for the review. tier2 testing went fine, plus I intentionally introduced a failure in this test (a local change) and then triggered a run of this test and this time the logs and artifacts were correctly collected and archived as a post failure step.

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

PR Comment: https://git.openjdk.org/jdk/pull/20156#issuecomment-2226724067

From jpai at openjdk.org  Sat Jul 13 02:21:55 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 13 Jul 2024 02:21:55 GMT
Subject: Integrated: 8336301:
 test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO
 file upon test completion
In-Reply-To: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
References: <0pcU2wlJ_shd5fCPVyby_fU5c7ZW7Wp-E5gw3MSCyuM=.bc702b81-d40a-4873-9f08-a9d458445fb3@github.com>
Message-ID: <drUBX2dV1PwY7MHiLzV-ECXu6JsE18chz29IAXdE58w=.f095e443-4de3-4efa-8e01-d2afebeee489@github.com>

On Fri, 12 Jul 2024 11:55:14 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this test-only change which proposes to address the issue noted in https://bugs.openjdk.org/browse/JDK-8336301?
> 
> The update in this PR, marks the FIFO file to be deleted upon JVM exit so that it isn't left around causing any subsequent process reading that file to block forever.
> 
> After this change, I've locally verified that this file isn't left around irrespective of whether or not the test passes.
> 
> The test continues to pass with this change. tier2 testing with this change is currently in progress.

This pull request has now been integrated.

Changeset: ae9f318f
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ae9f318fc35eeab497e546ebab9faed6ec774ec5
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8336301: test/jdk/java/nio/channels/AsyncCloseAndInterrupt.java leaves around a FIFO file upon test completion

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Mon Jul 15 01:40:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Jul 2024 01:40:04 GMT
Subject: [jdk23] RFR: 8334719: (se) Deferred close of SelectableChannel may
 result in a Selector doing the final close before concurrent I/O on channel
 has completed
In-Reply-To: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
References: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
Message-ID: <z3jWPXcydLkKT60ordEmOR6WgncnSSE-6uLOXUKExnw=.4565f288-33f7-49d0-b84d-a313e0e3c35a@github.com>

On Thu, 27 Jun 2024 04:46:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would like to backport this bug fix for a P3 issue into jdk23 branch. The backport is clean and the original fix was reviewed in mainline https://github.com/openjdk/jdk/pull/19879.

Thank you Alan for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19920#issuecomment-2227576298

From jpai at openjdk.org  Mon Jul 15 01:40:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 15 Jul 2024 01:40:05 GMT
Subject: [jdk23] Integrated: 8334719: (se) Deferred close of SelectableChannel
 may result in a Selector doing the final close before concurrent I/O
 on channel has completed
In-Reply-To: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
References: <qHPJD9RLoxe_QUDDQj-ihtKv-Rc6KWA9TtatkEG8Cwk=.c2979dab-964e-4ac4-98b3-942c1c35822c@github.com>
Message-ID: <qSXyVxVbaTn-YWFqERWwoK_lRJrB4oaisIAX_fuzGu4=.9d412671-a60e-47c2-87fe-d02acd00b1fe@github.com>

On Thu, 27 Jun 2024 04:46:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> I would like to backport this bug fix for a P3 issue into jdk23 branch. The backport is clean and the original fix was reviewed in mainline https://github.com/openjdk/jdk/pull/19879.

This pull request has now been integrated.

Changeset: 7cc50a18
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7cc50a181a31e0347445d59c91309c8f1058a985
Stats:     705 lines in 7 files changed: 705 ins; 0 del; 0 mod

8334719: (se) Deferred close of SelectableChannel may result in a Selector doing the final close before concurrent I/O on channel has completed

Reviewed-by: alanb
Backport-of: 9bb675f89dd1eeec423ca96cb3f96d29f5de477c

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

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

From alanb at openjdk.org  Tue Jul 16 14:29:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Jul 2024 14:29:54 GMT
Subject: RFR: 8335771: Improve stability of
 java/nio/channels/DatagramChannel tests [v2]
In-Reply-To: <h8rfZAFSSlaHpF_sPNl5qwRMJsZ3grTYMMcmgpgCGHo=.6622aa52-8fca-4889-8b4c-97fe36947166@github.com>
References: <JbbyzDs2GImo562VaXi8LHVxa0xGLd0LSV6QpD-F-Go=.ad2d83e5-03b5-485d-b02e-ce03d6e2739b@github.com>
 <h8rfZAFSSlaHpF_sPNl5qwRMJsZ3grTYMMcmgpgCGHo=.6622aa52-8fca-4889-8b4c-97fe36947166@github.com>
Message-ID: <lMmTgeJuvhyApFk3gJAXoBKlbzrESXF8c5l3AG_gMro=.dff52a34-761b-4157-b7dc-af0c112dd82e@github.com>

On Wed, 10 Jul 2024 20:09:58 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 two additional commits since the last revision:
> 
>  - Review feedback: avoid continue
>  - Review feedback

test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 433:

> 431:             p = new DatagramPacket(new byte[1024], 100);
> 432:             s.receive(p);
> 433:             if (getPort(p.getSocketAddress()) == getPort(s.getLocalSocketAddress())) {

I assume this can be simplified to `if (p.getPort() == s.getLocalPort())`, meaning no need to use SocketAddress here.

test/jdk/java/nio/channels/DatagramChannel/AdaptorMulticasting.java line 445:

> 443:                 System.out.println("Received message sender doesn't match - skipping: " + p.getSocketAddress());
> 444:             }
> 445:         } while(true);

`do { ... } while(true);` looks a bit odd here, any reason now to use `while (true) { .. }` ?

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

> 119:                 bb.put(bytes);
> 120:                 bb.flip();
> 121:                 if (Platform.isOSX()) {

If we look at this test next year then we will wonder why the bind is macOS specific, I think this needs a comment.

test/jdk/java/nio/channels/DatagramChannel/NotBound.java line 112:

> 110:         dc = DatagramChannel.open();
> 111:         try {
> 112:             System.out.println("Checks that connect() binds the socket");

I assume the trace message should be "Check" rather than "Checks" here (same thing for the other messages)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1679510532
PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1679512922
PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1679515830
PR Review Comment: https://git.openjdk.org/jdk/pull/20050#discussion_r1679519642

From syan at openjdk.org  Tue Jul 16 15:10:52 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 16 Jul 2024 15:10:52 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <woJyisMqwMdxPlhDUTKrjeK7ePvFMMhXVHeEUqbdSJ8=.91b1451d-6df0-4252-a07f-3399398471e9@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

Clean backport from jdk-tip to jdk23, can anyone take look this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/19936#issuecomment-2231166124

From bpb at openjdk.org  Tue Jul 16 17:52:05 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 16 Jul 2024 17:52:05 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v9]
In-Reply-To: <0EGVPkz4pGwAiB2QNJyS3blAE9EyrZK5Di6bT0Ia53Y=.769b8f47-d61a-4902-8f78-72736d3b1cc6@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <0EGVPkz4pGwAiB2QNJyS3blAE9EyrZK5Di6bT0Ia53Y=.769b8f47-d61a-4902-8f78-72736d3b1cc6@github.com>
Message-ID: <d7o7IDwPKB_UI-Yu_6mSJnnFogRx7WV3iveTYYjZS4Y=.a1f003d4-0ad1-4c51-adf1-03ed5230ec09@github.com>

On Fri, 7 Jun 2024 20:37:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Add to `java.nio.file.Path` a method `getExtension` to retrieve the `Path`'s extension, and companion methods `removeExtension` and `addExtension`.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:
> 
>  - 8298318: Update @since tags
>  - Merge
>  - 8298318: Add parameter checks for withExtension
>  - 8298318: Revise handling of leading periods
>  - 8298318: corretions to commit 030a250aaf4c309d515507527932b233f210501e
>  - 8298318: Address reviewer comments
>  - 8298318: Remove vestigial trim() call and commented out methods
>  - 8298318: Refine specification of extension; replace addExtension/removeExtension with withExtension/withoutExtension; update test
>  - Merge
>  - 8298318: Correct type in path.getExtension spec
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/f7a18a5f...b27cf346

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/16226#issuecomment-2231485202

From bpb at openjdk.org  Tue Jul 16 17:52:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 16 Jul 2024 17:52:59 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: <wV9COPq7z_22cB_6gilkwW7whG7k1Sk4f-CNHT2EcJw=.c06f0ab5-abb5-4cde-9e11-c46797e58f3a@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-2231485705

From syan at openjdk.org  Wed Jul 17 01:00:52 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Jul 2024 01:00:52 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <az2aY8pcC9qoepkXRSLiMlwsHMAUwLIhSM_FNKPUSus=.0b27559f-1427-465a-bf90-8e9dd75ff49a@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

Clean backport to fix the testcase bug and solve the intermittent failure, no risk.

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

PR Comment: https://git.openjdk.org/jdk/pull/19936#issuecomment-2232093201

From jpai at openjdk.org  Wed Jul 17 01:15:56 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 17 Jul 2024 01:15:56 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <dQLpf5HRrVQcIuSURIM7Z1EO22FaxYzMPYY71WvDZSU=.79d5cd7e-38e9-4673-9b03-94b42de4fa1a@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

This is a clean backport of a test-only fix that was integrated into master branch 3 weeks back. Looks OK to me for JDK 23.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19936#pullrequestreview-2181582753

From syan at openjdk.org  Wed Jul 17 01:29:03 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Jul 2024 01:29:03 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <dQLpf5HRrVQcIuSURIM7Z1EO22FaxYzMPYY71WvDZSU=.79d5cd7e-38e9-4673-9b03-94b42de4fa1a@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
 <dQLpf5HRrVQcIuSURIM7Z1EO22FaxYzMPYY71WvDZSU=.79d5cd7e-38e9-4673-9b03-94b42de4fa1a@github.com>
Message-ID: <47khUX3yKw1iazL1-NCYrpsDu0uwsuUy7ED0mxtAvmc=.31b153f7-82f9-474d-a2d6-b1170561c396@github.com>

On Wed, 17 Jul 2024 01:13:39 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> is a clean backport of a test-only fix that was integrated into master

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/19936#issuecomment-2232125736

From duke at openjdk.org  Wed Jul 17 01:29:03 2024
From: duke at openjdk.org (duke)
Date: Wed, 17 Jul 2024 01:29:03 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <ShN3KR7ozAW9tNT4swceipLn8-Q4gCghr7Qehei-0aI=.0201d089-a3aa-43b9-93c8-ac82cd0eb913@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

@sendaoYan 
Your change (at version 68e34ccd4b55f3a01026fc30396a9f82f1a481f2) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19936#issuecomment-2232127264

From vpetko at openjdk.org  Wed Jul 17 04:03:04 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 17 Jul 2024 04:03:04 GMT
Subject: RFR: 8336529: [arm32, Ubuntu noble] sun.nio.fs.UnixFileAttributeViews
 setTimes() fail
Message-ID: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@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
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/runtime/cds/appcds/RelativePath.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/runtime/jcmd/JcmdCmdLine.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/serviceability/attach/AttachNegativePidTest.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/serviceability/attach/RemovingUnixDomainSocketTest.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/serviceability/HeapDump/DuplicateArrayClassesTest.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/serviceability/HeapDump/FieldsInInstanceTest.java
                                                         1     1     0     0   
   jtreg:test/hotspot/jtreg/serviceability/attach/ConcAttachTest.java
                                                         0     0     0     0   
==============================
TEST SUCCESS

Finished building target 'test' in configuration 'linux-arm-server-fastdebug'

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

Commit messages:
 - typo: remove extra whitespace
 - fix typo: missing whitespace
 - try to use 64 bit function if sizeof(time_t) > 4

Changes: https://git.openjdk.org/jdk/pull/20208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336529
  Stats: 20 lines in 1 file changed: 17 ins; 0 del; 3 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  Wed Jul 17 05:27:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jul 2024 05:27:53 GMT
Subject: RFR: 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: <0iDshuvMuLq7R4z4JSlm9dJucpMwZlelIPSZaQ-VJHs=.87057be6-d9c5-46cc-bfed-c18c825701b3@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
>             ...

Would it be possible to rename the title on the PR to match the JBS issue?

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

> 251:  * Lookup time functions symbols, trying 64 bit version first
> 252:  */
> 253: static void* lookup_time_function(const char* symbol64, const char* symbol) {

This function is not specific to "time functions" so will need to be renamed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2232441593
PR Review Comment: https://git.openjdk.org/jdk/pull/20208#discussion_r1680421661

From vpetko at openjdk.org  Wed Jul 17 05:27:54 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 17 Jul 2024 05:27:54 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble
In-Reply-To: <0iDshuvMuLq7R4z4JSlm9dJucpMwZlelIPSZaQ-VJHs=.87057be6-d9c5-46cc-bfed-c18c825701b3@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <0iDshuvMuLq7R4z4JSlm9dJucpMwZlelIPSZaQ-VJHs=.87057be6-d9c5-46cc-bfed-c18c825701b3@github.com>
Message-ID: <W5Dq8ZiLwnm03esYgI98fPs86G9xHGlD52t-5BfS_oQ=.cd0932f3-67fc-418a-9846-5f2bc972229f@github.com>

On Wed, 17 Jul 2024 05:22:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Would it be possible to rename the title on the PR to match the JBS issue?

Done.

> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 253:
> 
>> 251:  * Lookup time functions symbols, trying 64 bit version first
>> 252:  */
>> 253: static void* lookup_time_function(const char* symbol64, const char* symbol) {
> 
> This function is not specific to "time functions" so will need to be renamed.

There is a check for time_t size inside it. Maybe `lookup_time_t_function` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/20208#issuecomment-2232443372
PR Review Comment: https://git.openjdk.org/jdk/pull/20208#discussion_r1680423838

From syan at openjdk.org  Wed Jul 17 06:14:58 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Jul 2024 06:14:58 GMT
Subject: [jdk23] Integrated: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <ZPoC8f5ns5LX06V-j9TguZ2SmkrlDDmvFogYVbj4JsE=.43257d65-c1b1-4d3a-98b2-97d217f6bdbe@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 024b39c3
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/024b39c36b2dae072c91de83fb063e5dd4ed44e8
Stats:     11 lines in 1 file changed: 8 ins; 0 del; 3 mod

8269657: Test java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message

Reviewed-by: jpai
Backport-of: c798316bc4cb33fd902f926030d8a0b6870d661a

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

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

From syan at openjdk.org  Wed Jul 17 06:21:56 2024
From: syan at openjdk.org (SendaoYan)
Date: Wed, 17 Jul 2024 06:21:56 GMT
Subject: [jdk23] RFR: 8269657: Test
 java/nio/channels/DatagramChannel/Loopback.java failed: Unexpected message
In-Reply-To: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
References: <3QUO_M8NEzkEK4BNsgfErU2eGd7A_dV-5fDATjiN9oE=.42c9cfe3-609f-4358-97d4-bc4f4dbff026@github.com>
Message-ID: <wRD51UgEi_IFqyzdEpPcSqlIsbexoNqzA4ChsoiOIJ4=.d0f87b1d-ac6b-4c5b-a7a8-39044144decd@github.com>

On Fri, 28 Jun 2024 09:47:37 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [c798316b](https://github.com/openjdk/jdk/commit/c798316bc4cb33fd902f926030d8a0b6870d661a) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 28 Jun 2024 and was reviewed by Daniel Fuchs.
> 
> Thanks!

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19936#issuecomment-2232516337

From alanb at openjdk.org  Wed Jul 17 13:10:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jul 2024 13:10:50 GMT
Subject: RFR: 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: <-TEBdkrT6PCSkOJgeovUrlvkMEgeGO98d8PkiXQhpNI=.841bcc18-b0d0-4b11-9dc7-542e5ff62da3@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
>             ...

If this patch goes ahead then I think it will need to use `#if defined(__linux__)` to avoid touching other platforms. That is, two symbols for Linux, one for the other platforms.

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

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

From aturbanov at openjdk.org  Wed Jul 17 19:38:57 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 17 Jul 2024 19:38:57 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
Message-ID: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>

Implementation of both methods is the same.
https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135

https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179

`UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.

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

Commit messages:
 - [PATCH] Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath
 - [PATCH] Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath

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

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

From aturbanov at openjdk.org  Wed Jul 17 19:38:57 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 17 Jul 2024 19:38:57 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <HWHW4iAXZYW3huu7OvD3hUEw-dTUGWLwOu45Sa8c77A=.25104bbe-04bc-4b04-8ec6-30fb6c651f24@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.

BTW, after my changes, implementations of `sun.nio.fs.UnixFileSystemProvider#newFileChannel` and `sun.nio.fs.UnixFileSystemProvider#newByteChannel` are now identical too. Should we just call `newFileChannel` from `newByteChannel` ?

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

PR Comment: https://git.openjdk.org/jdk/pull/20155#issuecomment-2225429645

From alanb at openjdk.org  Wed Jul 17 19:38:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jul 2024 19:38:58 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <HWHW4iAXZYW3huu7OvD3hUEw-dTUGWLwOu45Sa8c77A=.25104bbe-04bc-4b04-8ec6-30fb6c651f24@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
 <HWHW4iAXZYW3huu7OvD3hUEw-dTUGWLwOu45Sa8c77A=.25104bbe-04bc-4b04-8ec6-30fb6c651f24@github.com>
Message-ID: <yoXi9W51CL_Gu64t8LVIAL2qDjoXr_qWhj-G1H1c7dM=.c6b8234a-616d-44a0-903b-9ea4bc8a34c4@github.com>

On Fri, 12 Jul 2024 11:57:33 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> BTW, after my changes, implementations of `sun.nio.fs.UnixFileSystemProvider#newFileChannel` and `sun.nio.fs.UnixFileSystemProvider#newByteChannel` are now identical too. Should we just call `newFileChannel` from `newByteChannel` ?

The other way around, meaning it would okay for newByteChannel to call newFileChannel.

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

PR Comment: https://git.openjdk.org/jdk/pull/20155#issuecomment-2227231187

From alanb at openjdk.org  Wed Jul 17 19:38:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 17 Jul 2024 19:38:58 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <wVi9n5OXmSwMJgO3v07eJMFnE1nl1uM1uv2b3q8yhQo=.9533c40e-9b16-4565-a3c8-0d70c12817c0@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.

Are you planning to create a JBS issue for this cleanup?

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

PR Comment: https://git.openjdk.org/jdk/pull/20155#issuecomment-2230942430

From vpetko at openjdk.org  Wed Jul 17 22:43:47 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 17 Jul 2024 22:43:47 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@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 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20208/files
  - new: https://git.openjdk.org/jdk/pull/20208/files/19ae073c..29953d48

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

  Stats: 658 lines in 53 files changed: 371 ins; 106 del; 181 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  Thu Jul 18 06:30:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Jul 2024 06:30:34 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
Message-ID: <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>

On Wed, 17 Jul 2024 22:43:47 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 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

Hello Vladimir, 

> time_t transition in Debian/Ubuntu left 32 bit time_t symbols in glibc.

Do you know if this was intentional? Is there any link which explains that transition? I am just curious why this is specific to Debian/Ubuntu and not to other Linux systems.

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

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

From jpai at openjdk.org  Thu Jul 18 06:40:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Jul 2024 06:40:30 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <rJ62aE41mPe5UA_U3iVAx_Z0u76jCpml9YNQjWBEKUs=.a03fe76e-37e5-40cf-bc48-c37c9255383f@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.

Looks OK to me, but please wait for another review from someone in this area.
Have relevant tier tests been run after this change?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20155#pullrequestreview-2184848066

From alanb at openjdk.org  Thu Jul 18 06:46:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jul 2024 06:46:32 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <rJ62aE41mPe5UA_U3iVAx_Z0u76jCpml9YNQjWBEKUs=.a03fe76e-37e5-40cf-bc48-c37c9255383f@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
 <rJ62aE41mPe5UA_U3iVAx_Z0u76jCpml9YNQjWBEKUs=.a03fe76e-37e5-40cf-bc48-c37c9255383f@github.com>
Message-ID: <aGOP1IA2N_q8SoFp_Q4CUcevLg4dJzImaXVE0dQresI=.ddc1d085-f766-4efe-8ef0-dc9b075b7007@github.com>

On Thu, 18 Jul 2024 06:37:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Have relevant tier tests been run after this change?

I'm running the tests with the change because I don't know if Andrey is able to run tier2 on Linux/macOS (which are impacted by the change).

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

PR Comment: https://git.openjdk.org/jdk/pull/20155#issuecomment-2235747625

From vpetko at openjdk.org  Thu Jul 18 07:21:31 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 18 Jul 2024 07:21:31 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
 <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>
Message-ID: <Bh65lUUqZoi8X7qWfIt5j7UR9jVcOvG28eBYc5t8n3Q=.30ce8f8b-fa40-4b07-8cf2-70734d1ef2f7@github.com>

On Thu, 18 Jul 2024 06:27:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Vladimir,
> 
> > time_t transition in Debian/Ubuntu left 32 bit time_t symbols in glibc.
> 
> Do you know if this was intentional? Is there any link which explains that transition? I am just curious why this is specific to Debian/Ubuntu and not to other Linux systems.
Hi, 

 I believe it was an intentional effort to resolve 2038 problem for ARM devices in Debian/Ubuntu[1]

Best Regards, 
 Vladimir.

[1] https://wiki.debian.org/ReleaseGoals/64bit-time

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

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

From alanb at openjdk.org  Thu Jul 18 07:55:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jul 2024 07:55:31 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <7w-lRiFTWrcoSJMlGUZUkeOkGhDoLNo4JU933tfMeu8=.4e9c3033-210e-4d67-a6da-c5510bb6ccd4@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20155#pullrequestreview-2185006430

From jpai at openjdk.org  Thu Jul 18 12:25:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 18 Jul 2024 12:25:33 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <Bh65lUUqZoi8X7qWfIt5j7UR9jVcOvG28eBYc5t8n3Q=.30ce8f8b-fa40-4b07-8cf2-70734d1ef2f7@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
 <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>
 <Bh65lUUqZoi8X7qWfIt5j7UR9jVcOvG28eBYc5t8n3Q=.30ce8f8b-fa40-4b07-8cf2-70734d1ef2f7@github.com>
Message-ID: <yU8ZP0-iFJC3BRTZJgEhfYXCDOdF23xiKn6ybZqGoj4=.b66765ca-3ffd-48c5-bf78-f3ebc703f943@github.com>

On Thu, 18 Jul 2024 07:18:48 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

> [1] https://wiki.debian.org/ReleaseGoals/64bit-time

Thank you for that link. Reading through it, it leads to https://sourceware.org/glibc/wiki/Y2038ProofnessDesign. The summary of that, if I understood correctly, is that the `time_t` related functions and types for 32 bit systems will have 64 bit equivalents (with newer type names and API names). The 64 bit variants will get used when built with `_TIME_BITS=64`. The glibc project appears to try and keep this as seamless as possible, to user code, by internally `#define`ing 32 bit API and type names to their corresponding 64 bit names, when `_TIME_BITS=64` is set.

Looking at the JBS issue where you reported these test failures, they seem to be happening on `armhf` architecture, which after reading up a bit, appears to be a 32 bit architecture. Ubuntu recently appears to have switched to use `_TIME_BITS=64` for this architecture. This, if I understand correctly, wouldn't have been a problem for the JDK code, had those symbols be referenced statically in the JDK code, since then the (glibc) `#define` would have translated it to the 64 bit counterpart. In the code which is being updated in this PR, we reference those symbols as strings to do a dynamic symbol lookup and that ends up giving back 32 bit variant of this API.

Did I understand this correctly?

The one unanswered question is - on this 32 bit system, how were these tests passing previously, when `_TIME_BITS=64` wasn't set. Perhaps, in the absence of the `_TIME_BITS=64`, the symbols were being mapped to 64 bit counterparts? Would you be able to verify that somehow on a `armhf` system where these tests pass?

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

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

From aturbanov at openjdk.org  Thu Jul 18 15:50:00 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 Jul 2024 15:50:00 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
Message-ID: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>

Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.

List of affected classes:
`DirectCharBufferS`, `DirectCharBufferU`,
`DirectDoubleBufferS`, `DirectDoubleBufferU`,
`DirectFloatBufferS`, `DirectFloatBufferU`,
`DirectIntBufferS`, `DirectIntBufferU`,
`DirectLongBufferS`, `DirectLongBufferU`,
`DirectShortBufferS`, `DirectShortBufferU`

Tested `test/jdk/java/nio` on Linux x64 release.

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

Commit messages:
 - remove 'protected' modifier
 - [PATCH] Remove unused 'static boolean UNALIGNED' field from non-byte Buffers implementations

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

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

From liach at openjdk.org  Thu Jul 18 15:50:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Jul 2024 15:50:00 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <BOYc1-wBxVJEEcB2EYlwrSTZV4TFj70US5EDLulUNDE=.853223c7-c24f-44b4-b5d2-ac5412e3bb50@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

Created https://bugs.openjdk.org/browse/JDK-8336755 for you.

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

PR Comment: https://git.openjdk.org/jdk/pull/20233#issuecomment-2236751548

From alanb at openjdk.org  Thu Jul 18 15:50:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jul 2024 15:50:01 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <_qNyKEgLPysxc6jkk7FivZHDA8RLc_21HeD-Klf8-G8=.82426a5b-b0e4-4ace-abaf-a8581014df96@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 70:

> 68: #if[byte]
> 69:     // Cached unaligned-access capability
> 70:     protected static final boolean UNALIGNED = Bits.unaligned();

Can you drop the protected modifier and check that it builds?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20233#discussion_r1682738373

From aturbanov at openjdk.org  Thu Jul 18 15:50:01 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 18 Jul 2024 15:50:01 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
In-Reply-To: <_qNyKEgLPysxc6jkk7FivZHDA8RLc_21HeD-Klf8-G8=.82426a5b-b0e4-4ace-abaf-a8581014df96@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
 <_qNyKEgLPysxc6jkk7FivZHDA8RLc_21HeD-Klf8-G8=.82426a5b-b0e4-4ace-abaf-a8581014df96@github.com>
Message-ID: <IxbaNZrono1gxILFh-RYwROAqSP18EnvEajvUxYPP0E=.14649a1f-99b2-45f1-af73-0e894c8e2488@github.com>

On Thu, 18 Jul 2024 12:18:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
>> 
>> List of affected classes:
>> `DirectCharBufferS`, `DirectCharBufferU`,
>> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
>> `DirectFloatBufferS`, `DirectFloatBufferU`,
>> `DirectIntBufferS`, `DirectIntBufferU`,
>> `DirectLongBufferS`, `DirectLongBufferU`,
>> `DirectShortBufferS`, `DirectShortBufferU`
>> 
>> Tested `test/jdk/java/nio` on Linux x64 release.
>
> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 70:
> 
>> 68: #if[byte]
>> 69:     // Cached unaligned-access capability
>> 70:     protected static final boolean UNALIGNED = Bits.unaligned();
> 
> Can you drop the protected modifier and check that it builds?

Yes, it builds when I drop modifier.

    // Cached unaligned-access capability
    static final boolean UNALIGNED = Bits.unaligned();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20233#discussion_r1682742640

From liach at openjdk.org  Thu Jul 18 15:50:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Jul 2024 15:50:01 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
In-Reply-To: <IxbaNZrono1gxILFh-RYwROAqSP18EnvEajvUxYPP0E=.14649a1f-99b2-45f1-af73-0e894c8e2488@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
 <_qNyKEgLPysxc6jkk7FivZHDA8RLc_21HeD-Klf8-G8=.82426a5b-b0e4-4ace-abaf-a8581014df96@github.com>
 <IxbaNZrono1gxILFh-RYwROAqSP18EnvEajvUxYPP0E=.14649a1f-99b2-45f1-af73-0e894c8e2488@github.com>
Message-ID: <rx6cDCynMEoLxHRq1WzvIgaeW-B8dB5dJmk5dZe1rHM=.d733daf6-9f1c-4339-b648-7d82bad54025@github.com>

On Thu, 18 Jul 2024 12:21:39 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/Direct-X-Buffer.java.template line 70:
>> 
>>> 68: #if[byte]
>>> 69:     // Cached unaligned-access capability
>>> 70:     protected static final boolean UNALIGNED = Bits.unaligned();
>> 
>> Can you drop the protected modifier and check that it builds?
>
> Yes, it builds when I drop modifier.
> 
>     // Cached unaligned-access capability
>     static final boolean UNALIGNED = Bits.unaligned();

Indeed, we should remove the protected modifier in a package-private class.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20233#discussion_r1682748975

From alanb at openjdk.org  Thu Jul 18 16:54:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jul 2024 16:54:30 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from Direct non-byte
 Buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <BSl8dT5EHacz9EWkpg8obHuXqbUnQQZw_vHr06s5Gxo=.a9f3bac0-ccb7-4084-a26b-38790dfdd6f2@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

Change looks fine. I've fixed the title of the JBS issue as this is because a field in view buffers, I assume you can fix the PR title to match.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20233#pullrequestreview-2186408647

From liach at openjdk.org  Thu Jul 18 17:12:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 18 Jul 2024 17:12:33 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from view buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <OBe-yYwNudzNONGxdEC3K1-2M1rIHR6ZCF7ANuNcJfY=.885e38ba-635a-4e19-8fd9-74168db03612@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

tier 1-3 tests look good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20233#pullrequestreview-2186439959

From alanb at openjdk.org  Thu Jul 18 17:28:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Jul 2024 17:28:32 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
Message-ID: <gntQDJh_BSEeKUG2glzRexHBIfb9bgTwZYtKYDJRe1Q=.bbf51f5b-9ded-40f7-a2bb-5ccc37067fb9@github.com>

On Wed, 17 Jul 2024 22:43:47 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 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

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

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

From bpb at openjdk.org  Thu Jul 18 20:03:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Jul 2024 20:03:32 GMT
Subject: RFR: 8336675: Remove UnixFileSystemProvider.checkPath in favor of
 UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <l9tDun2V6Kenh48hc0wweaJPa6Y-SLrvaguje97dsBs=.158592fc-b49c-4769-aabf-034fc5823d14@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.
> 
> Tested on linux x64 `test/jdk/java/nio` + `test/jdk/java/io`

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20155#pullrequestreview-2186753286

From bpb at openjdk.org  Thu Jul 18 20:13:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Jul 2024 20:13:33 GMT
Subject: RFR: 8336755: Remove unused UNALIGNED field from view buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <nVrusOrLgbKvFduv8CILc2eAq-hYpa_9RGYDaTue-8A=.ae053b6c-4612-47c7-9035-a98d41aac769@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20233#pullrequestreview-2186768568

From vpetko at openjdk.org  Thu Jul 18 21:51:32 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Thu, 18 Jul 2024 21:51:32 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <yU8ZP0-iFJC3BRTZJgEhfYXCDOdF23xiKn6ybZqGoj4=.b66765ca-3ffd-48c5-bf78-f3ebc703f943@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
 <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>
 <Bh65lUUqZoi8X7qWfIt5j7UR9jVcOvG28eBYc5t8n3Q=.30ce8f8b-fa40-4b07-8cf2-70734d1ef2f7@github.com>
 <yU8ZP0-iFJC3BRTZJgEhfYXCDOdF23xiKn6ybZqGoj4=.b66765ca-3ffd-48c5-bf78-f3ebc703f943@github.com>
Message-ID: <G2WkReISX6tjkaBS04Dniwa7ITQuYaOSxiiT-YagDuQ=.12e86c7c-e33b-495a-9ba7-656bf7c6e12c@github.com>

On Thu, 18 Jul 2024 12:23:06 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Looking at the JBS issue where you reported these test failures, they seem to be happening on `armhf` architecture, which after reading up a bit, appears to be a 32 bit architecture. Ubuntu recently appears to have switched to use `_TIME_BITS=64` for this architecture. This, if I understand correctly, wouldn't have been a problem for the JDK code, had those symbols be referenced statically in the JDK code, since then the (glibc) `#define` would have translated it to the 64 bit counterpart. In the code which is being updated in this PR, we reference those symbols as strings to do a dynamic symbol lookup and that ends up giving back 32 bit variant of this API.
> 
> Did I understand this correctly?

Yes exactly. 
 
> The one unanswered question is - on this 32 bit system, how were these tests passing previously, when `_TIME_BITS=64` wasn't set. Perhaps, in the absence of the `_TIME_BITS=64`, the symbols were being mapped to 64 bit counterparts? Would you be able to verify that somehow on a `armhf` system where these tests pass?

Oh, thank you!!! 
This is a really good point - instead of doing an extra function I should go `#if  defined(__linux__) && _TIME_BITS==64` to look up 64 bit version.

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

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

From jpai at openjdk.org  Fri Jul 19 04:01:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 19 Jul 2024 04:01:36 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <G2WkReISX6tjkaBS04Dniwa7ITQuYaOSxiiT-YagDuQ=.12e86c7c-e33b-495a-9ba7-656bf7c6e12c@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
 <7xRSPVKuxEnC87vBCt9xMt4FQD4azLxQpnW8V1LHrNs=.dae645c2-0eb7-4855-ad6f-95f3652e8e35@github.com>
 <Bh65lUUqZoi8X7qWfIt5j7UR9jVcOvG28eBYc5t8n3Q=.30ce8f8b-fa40-4b07-8cf2-70734d1ef2f7@github.com>
 <yU8ZP0-iFJC3BRTZJgEhfYXCDOdF23xiKn6ybZqGoj4=.b66765ca-3ffd-48c5-bf78-f3ebc703f943@github.com>
 <G2WkReISX6tjkaBS04Dniwa7ITQuYaOSxiiT-YagDuQ=.12e86c7c-e33b-495a-9ba7-656bf7c6e12c@github.com>
Message-ID: <3VbEQEfq9K_58GDHxf2ICxGc14_Ii929xKe9wJDZ_ts=.71777a37-6554-49d3-9987-56f82a5a4de7@github.com>

On Thu, 18 Jul 2024 21:48:46 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>  instead of doing an extra function I should go #if  defined(__linux__) && _TIME_BITS==64 to look up 64 bit version.

I think using the (build time) `_TIME_BITS==64` for deciding whether or not to include code which does a lookup at runtime for the 64 bit variant of these symbols, may not be correct. Merely relying on `__linux__` I think should be enough. Alan's recent suggested example will make it simpler without the necessity of introducing a new function.

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

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

From vpetko at openjdk.org  Fri Jul 19 04:25:36 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 19 Jul 2024 04:25:36 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v2]
In-Reply-To: <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <-yjhWaSuu38XTKRiQv_r_DZdGCLtPVoGD5J_ITtctJY=.f46e0545-6648-4c85-b398-6e13903a57b5@github.com>
Message-ID: <J2ngMn90As9ltmmDJLtKA9qMQXEdafNzMy9NvweXpMk=.148a5fd5-549c-4988-afdd-5fdfb6c330c5@github.com>

On Wed, 17 Jul 2024 22:43:47 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 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

> > instead of doing an extra function I should go #if  defined(**linux**) && _TIME_BITS==64 to look up 64 bit version.
> 
> I think using the (build time) `_TIME_BITS==64` for deciding whether or not to include code which does a lookup at runtime for the 64 bit variant of these symbols,

I believe sizeof() is also evaluated at compile time so this is more of  a style choice. 

>may not be correct. Merely relying on `__linux__` I think should be enough. Alan's recent suggested example will make it simpler without the necessity of introducing a new function.

Yes, I believe it would be a little bit more readable without introducing too many #ifdef branches in the code.

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

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

From aturbanov at openjdk.org  Fri Jul 19 05:57:44 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 19 Jul 2024 05:57:44 GMT
Subject: Integrated: 8336675: Remove UnixFileSystemProvider.checkPath in favor
 of UnixPath.toUnixPath
In-Reply-To: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
References: <DnD2pPd5Duuc8fcxTfOSfSk7W9huqd4nCzhtqGxfD20=.0caf1d8b-a3ad-4b5f-95fc-8aa35afb54ab@github.com>
Message-ID: <_E1hiO8mkCfRWU4tjVgyFLw9WBXg3_OPlMdkpuvrk-Y=.14d5aff9-2967-4664-b3e3-daad79b46568@github.com>

On Fri, 12 Jul 2024 11:54:15 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Implementation of both methods is the same.
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixFileSystemProvider.java#L129-L135
> 
> https://github.com/openjdk/jdk/blob/9b6f6c5c9dd6d0fbb056e8d84c3a0888a3320edf/src/java.base/unix/classes/sun/nio/fs/UnixPath.java#L172-L179
> 
> `UnixPath.toUnixPath` is already used by UnixFileSystemProvider in multiple places. Two more usages shouldn't cause problems.
> 
> Tested on linux x64 `test/jdk/java/nio` + `test/jdk/java/io`

This pull request has now been integrated.

Changeset: f5871df2
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f5871df25c60990825babb3bbae38c5ade93f097
Stats:     21 lines in 1 file changed: 0 ins; 17 del; 4 mod

8336675: Remove UnixFileSystemProvider.checkPath in favor of UnixPath.toUnixPath

Reviewed-by: jpai, alanb, bpb

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

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

From vpetko at openjdk.org  Fri Jul 19 07:59:11 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 19 Jul 2024 07:59:11 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v3]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <kMhsLwpCJA5O9qWdgKOAQ2c0pz7_NC78FLw0QBtKoBQ=.bd554a24-5852-4241-8a6b-1f7d2b5bf35b@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:

  review comments: use a separate ifdef statement.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20208/files
  - new: https://git.openjdk.org/jdk/pull/20208/files/29953d48..551532d7

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

  Stats: 18 lines in 1 file changed: 9 ins; 5 del; 4 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 Jul 19 08:36:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Jul 2024 08:36:33 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v3]
In-Reply-To: <kMhsLwpCJA5O9qWdgKOAQ2c0pz7_NC78FLw0QBtKoBQ=.bd554a24-5852-4241-8a6b-1f7d2b5bf35b@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <kMhsLwpCJA5O9qWdgKOAQ2c0pz7_NC78FLw0QBtKoBQ=.bd554a24-5852-4241-8a6b-1f7d2b5bf35b@github.com>
Message-ID: <0Pt-K7q3BFiuQ1EEHDbkFRwDyixQXQPGF8M5_DmmjKw=.28933710-4710-4e1b-bcec-b6d2c22d6a65@github.com>

On Fri, 19 Jul 2024 07:59:11 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:
> 
>   review comments: use a separate ifdef statement.

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

> 263:     return ret;
> 264: }
> 265: #endif

I assume you will move to after statx_wrapper and just replace the body with a simple if-then-else.

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

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

From vpetko at openjdk.org  Fri Jul 19 09:08:33 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 19 Jul 2024 09:08:33 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v3]
In-Reply-To: <0Pt-K7q3BFiuQ1EEHDbkFRwDyixQXQPGF8M5_DmmjKw=.28933710-4710-4e1b-bcec-b6d2c22d6a65@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <kMhsLwpCJA5O9qWdgKOAQ2c0pz7_NC78FLw0QBtKoBQ=.bd554a24-5852-4241-8a6b-1f7d2b5bf35b@github.com>
 <0Pt-K7q3BFiuQ1EEHDbkFRwDyixQXQPGF8M5_DmmjKw=.28933710-4710-4e1b-bcec-b6d2c22d6a65@github.com>
Message-ID: <kw7Cu3a2iS02WPdFJePHd30aBXidspOFJtl5qE0lKEg=.02da3291-1bea-442c-9f44-2c469333817d@github.com>

On Fri, 19 Jul 2024 08:34:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Vladimir Petko has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   review comments: use a separate ifdef statement.
>
> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 265:
> 
>> 263:     return ret;
>> 264: }
>> 265: #endif
> 
> I assume you will move to after statx_wrapper and just replace the body with a simple if-then-else.

if/else will not work in a general case, even in Debian where x32 arch has 64 bit time_t but no 64 bit functions, so I have to lookup 64 bit one and, if it fails, fall back to a general symbol. I can make this change, but it might cause an issue in some edge cases.

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

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

From vpetko at openjdk.org  Fri Jul 19 10:19:02 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Fri, 19 Jul 2024 10:19:02 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v4]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <YSWZKps9GX7gkp24_hnU8FKCieb0zBE4dWK5pCOa9mg=.9ea96e02-15f0-471c-bf87-7a7c6d909e05@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:

  move lookup function and set guard condtions

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20208/files
  - new: https://git.openjdk.org/jdk/pull/20208/files/551532d7..3c417362

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

  Stats: 26 lines in 1 file changed: 8 ins; 11 del; 7 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 cushon at openjdk.org  Fri Jul 19 19:39:58 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Fri, 19 Jul 2024 19:39:58 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants ZIP64_EXTID
 and EXTID_ZIP64
Message-ID: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>

This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).

I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.

I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.

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

Commit messages:
 - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64.

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

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

From jpai at openjdk.org  Sat Jul 20 01:36:32 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Jul 2024 01:36:32 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID
In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
Message-ID: <jLYLjB0cPGoLba2tciQ9lOZg0RP1HQAuaFnUwWPQHMA=.ec4df935-8865-4b13-b9b1-9c626b11be51@github.com>

On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
> 
> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
> 
> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.

Hello Liam, the changes look fine to me. Choosing `EXTID_ZIP64` constant in preference of the other seems OK too, since that constant is more closer in code location with the other extra field header ids.

Some of these files require a copyright year update. Please update those before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189609923

From cushon at openjdk.org  Sat Jul 20 02:18:11 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 20 Jul 2024 02:18:11 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID [v2]
In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
Message-ID: <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>

> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
> 
> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
> 
> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.

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

 - Merge remote-tracking branch 'origin/master' into zip64_extid
 - Update copyright year
 - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20264/files
  - new: https://git.openjdk.org/jdk/pull/20264/files/3b975c24..48bb222e

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

  Stats: 889 lines in 46 files changed: 673 ins; 101 del; 115 mod
  Patch: https://git.openjdk.org/jdk/pull/20264.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20264/head:pull/20264

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

From cushon at openjdk.org  Sat Jul 20 02:18:12 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Sat, 20 Jul 2024 02:18:12 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID
In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
Message-ID: <rOwpyl8g8KOqpB8fHu62mK9LGWUoT4ENt9lI8XOx2Us=.531535e4-3ad5-431a-8aac-d6b4052a0dc5@github.com>

On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
> 
> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
> 
> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.

I updated the copyright dates. Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/20264#issuecomment-2240861834

From jpai at openjdk.org  Sat Jul 20 06:30:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 20 Jul 2024 06:30:31 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID [v2]
In-Reply-To: <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
 <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
Message-ID: <p4uceDjrsbDDOUE_IMX90ATxWf6gdYMgBsyIMu46xio=.2e4afdbd-dd7c-4b1a-8484-12b1b001c8f1@github.com>

On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
>> 
>> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
>> 
>> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into zip64_extid
>  - Update copyright year
>  - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64.

The changes look good to me. Although a trivial change, it would be good to wait for Lance to review this before integrating.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189766637

From vtewari at openjdk.org  Sat Jul 20 06:41:32 2024
From: vtewari at openjdk.org (Vyom Tewari)
Date: Sat, 20 Jul 2024 06:41:32 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID [v2]
In-Reply-To: <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
 <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
Message-ID: <vBn5sOzhIzcA6iWSZymOFLncIDdNZsOPUQBmSMj4nXk=.cd8f19eb-b48a-43d0-b1d7-9fd8246249e7@github.com>

On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
>> 
>> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
>> 
>> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into zip64_extid
>  - Update copyright year
>  - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64.

Looks OK to me.

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

Marked as reviewed by vtewari (Committer).

PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2189770126

From alanb at openjdk.org  Sat Jul 20 15:35:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 20 Jul 2024 15:35:05 GMT
Subject: RFR: 8336339: (se) SelectionKey.interestOps(int) should not throw
 ClosedSelectorException
Message-ID: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>

If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.

The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.

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

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/20269/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20269&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336339
  Stats: 162 lines in 8 files changed: 128 ins; 25 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/20269.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20269/head:pull/20269

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

From alanb at openjdk.org  Sun Jul 21 06:58:01 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Jul 2024 06:58:01 GMT
Subject: RFR: 8336339: (se) SelectionKey.interestOps(int) should not throw
 ClosedSelectorException [v2]
In-Reply-To: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
References: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
Message-ID: <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>

> If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.
> 
> The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.

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

  raceRegisterAndClose fix

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20269/files
  - new: https://git.openjdk.org/jdk/pull/20269/files/94aafe8e..b91839fb

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

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

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

From alanb at openjdk.org  Sun Jul 21 07:35:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Jul 2024 07:35:39 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v3]
In-Reply-To: <kw7Cu3a2iS02WPdFJePHd30aBXidspOFJtl5qE0lKEg=.02da3291-1bea-442c-9f44-2c469333817d@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <kMhsLwpCJA5O9qWdgKOAQ2c0pz7_NC78FLw0QBtKoBQ=.bd554a24-5852-4241-8a6b-1f7d2b5bf35b@github.com>
 <0Pt-K7q3BFiuQ1EEHDbkFRwDyixQXQPGF8M5_DmmjKw=.28933710-4710-4e1b-bcec-b6d2c22d6a65@github.com>
 <kw7Cu3a2iS02WPdFJePHd30aBXidspOFJtl5qE0lKEg=.02da3291-1bea-442c-9f44-2c469333817d@github.com>
Message-ID: <3m8FNAfBtN2sQUEMAT9fQk6ua0gMGozuNor7Gj1mYGU=.287e2603-5e81-4ca0-8231-c6664b7b60bc@github.com>

On Fri, 19 Jul 2024 09:02:00 GMT, Vladimir Petko <vpetko at openjdk.org> wrote:

>> src/java.base/unix/native/libnio/fs/UnixNativeDispatcher.c line 265:
>> 
>>> 263:     return ret;
>>> 264: }
>>> 265: #endif
>> 
>> I assume you will move to after statx_wrapper and just replace the body with a simply if-then-else.
>
> I should also add ARM32 guard in addition to linux. This will limit impact further and i can use if/else
> 
> This if/else will not work in a general case, even in Debian where x86_64 arch has 64 bit time_t but no __futimens64  function, so without an arch specific guard I have to lookup 64 bit one and, if it fails, fall back to a general symbol. 
> 
> ```` 
> $objdump -T /lib/x86_64-linux-gnu/libc.so.6 | grep futimens
> 000000000011a3e0  w   DF .text	000000000000002c  GLIBC_2.6   futimens
> 
> $objdump -T /lib/arm-linux-gnueabihf/libc.so.6 | grep futimens 
> 000a7f58  w   DF .text	00000080  GLIBC_2.6   futimens
> 000a7f30 g    DF .text	00000028  GLIBC_2.34  __futimens64

Starting out with this limited to ARM32 is okay, it reduces the risk as this code is compiled to many platforms and with many different toolchains. Can you move it after statx_wrapper as right now it is a bit annoying to have in the middle of the XXX_wrapper functions.

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

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

From lancea at openjdk.org  Sun Jul 21 12:28:36 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sun, 21 Jul 2024 12:28:36 GMT
Subject: RFR: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID [v2]
In-Reply-To: <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
 <O1w3kLRnf69dJ2CB5ouzOvX7eO7mq-VYOdlDqj_Z98w=.ed3691d2-3bb3-471d-9e75-01090db94925@github.com>
Message-ID: <iv3PI6h6-Wjc_XOCvN9xx_hVaHstn85ZOXp914LE11I=.d5acf258-b6d1-4c45-bfac-990d1832a130@github.com>

On Sat, 20 Jul 2024 02:18:11 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
>> 
>> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
>> 
>> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into zip64_extid
>  - Update copyright year
>  - 8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and EXTID_ZIP64.

The change looks fine.

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

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20264#pullrequestreview-2190317457

From duke at openjdk.org  Sun Jul 21 13:34:05 2024
From: duke at openjdk.org (Technici4n)
Date: Sun, 21 Jul 2024 13:34:05 GMT
Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt
Message-ID: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>

Hi,

Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example.

There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2]

[1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
[2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html

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

Commit messages:
 - 8316882: Do not close ZipFileSystem on interrupt

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

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

From alanb at openjdk.org  Sun Jul 21 16:24:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 21 Jul 2024 16:24:30 GMT
Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt
In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
Message-ID: <ytA1seSNAx0VggtICr_ZiVoTLLNLPBEHudaDHAeNzkE=.d462a5d0-914b-40d9-97b6-72ef1aa0e4bf@github.com>

On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n <duke at openjdk.org> wrote:

> Hi,
> 
> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example.
> 
> There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2]
> 
> [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
> [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html

Did you check with Lance before taking this? Asking because in the discussion threads cited we didn't come to a conclusion on this topic yet.

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

PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2241702813

From duke at openjdk.org  Sun Jul 21 16:34:31 2024
From: duke at openjdk.org (Technici4n)
Date: Sun, 21 Jul 2024 16:34:31 GMT
Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt
In-Reply-To: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
Message-ID: <EcLC4-zm4KprFMHyEm0B0_NLmHl-iM9dmjU4MiIxnZM=.27b4a758-a7f5-4dbe-a007-2c8b931ced3a@github.com>

On Sun, 21 Jul 2024 13:29:36 GMT, Technici4n <duke at openjdk.org> wrote:

> Hi,
> 
> Here is a fix for https://bugs.openjdk.org/browse/JDK-8316882, following the `FileChannelImpl#setUninterruptible` pattern used in `Files.readAllBytes` for example.
> 
> There has been some discussion on nio-dev about more broadly rethinking the interrupt handling for `FileChannels`, for example by adding a new open option. This PR is just meant to fix the ZipFS issue in the meanwhile. (Maybe I will tackle the more general issue?). [1] [2]
> 
> [1]: https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
> [2]: https://mail.openjdk.org/pipermail/nio-dev/2024-April/016147.html

Oh, I missed the assignment and did not check with @LanceAndersen.

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

PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2241705889

From syan at openjdk.org  Mon Jul 22 07:40:32 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Jul 2024 07:40:32 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <bB5TyiE1L6ppNlooHn-1YVIe4PDAG-DNlLyV4jXoBPo=.10cdf3bc-0bdb-4f0e-8b9b-cfca3372408c@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Hi, can anyone take look this PR. It's clean bakcport to jdk23u.

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

PR Comment: https://git.openjdk.org/jdk/pull/19848#issuecomment-2242290083

From alanb at openjdk.org  Mon Jul 22 09:01:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Jul 2024 09:01:33 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <YpJZ6tIdisC3xxPvoYGVUjCL3Zy0UhGFwy11z0Y3ytw=.f618199c-a3bc-49e6-b793-164b31185b00@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/19848#pullrequestreview-2191021954

From syan at openjdk.org  Mon Jul 22 11:19:31 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Jul 2024 11:19:31 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <xFwZmcsTm2XBB7HEOUWbCnGpZf-yLW-ad2iMZqKYa10=.218f4ce1-f4cc-4c4c-a78c-88a6637996cb@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Thanks for the review and approved.

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

PR Comment: https://git.openjdk.org/jdk/pull/19848#issuecomment-2242707469

From duke at openjdk.org  Mon Jul 22 11:19:31 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jul 2024 11:19:31 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <kisUjc-uyp94gNsaquSO6z7ARFJxGXVwxhfRll0cXr0=.fe220777-37aa-4b63-a0de-2249eded9ad6@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

@sendaoYan 
Your change (at version 4696870738fbee110bb262d8fd980a0ec68faf39) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/19848#issuecomment-2242710382

From syan at openjdk.org  Mon Jul 22 12:36:36 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Jul 2024 12:36:36 GMT
Subject: [jdk23] Integrated: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <A2YOq4vT4E0HwvEktuBItfkhOqFdCGJTWWXFzWxr0iw=.cd5f7ddb-56ae-459e-8d9d-970cda35518e@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

This pull request has now been integrated.

Changeset: 2288c052
Author:    SendaoYan <syan at openjdk.org>
Committer: Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2288c052e6b05147f6b4312bd231d299a2966aa1
Stats:     29 lines in 1 file changed: 21 ins; 0 del; 8 mod

8334339: Test java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on alinux3

Reviewed-by: alanb
Backport-of: 7baddc202a9ab2b85401aa05f827678b514ebf55

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

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

From jpai at openjdk.org  Mon Jul 22 13:42:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 22 Jul 2024 13:42:34 GMT
Subject: RFR: 8336339: (se) SelectionKey.interestOps(int) should not throw
 ClosedSelectorException [v2]
In-Reply-To: <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
References: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
 <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
Message-ID: <wtnU0QADhCDh7U241G1FN9Gu9bCpqnM120BGTQdQR8c=.20d6eed1-70f1-4696-8cd2-3144f0400812@github.com>

On Sun, 21 Jul 2024 06:58:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.
>> 
>> The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   raceRegisterAndClose fix

Based on the provided context, the changes look OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20269#pullrequestreview-2191612272

From lancea at openjdk.org  Mon Jul 22 14:09:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 22 Jul 2024 14:09:31 GMT
Subject: RFR: 8316882: Do not close ZipFileSystem on interrupt
In-Reply-To: <EcLC4-zm4KprFMHyEm0B0_NLmHl-iM9dmjU4MiIxnZM=.27b4a758-a7f5-4dbe-a007-2c8b931ced3a@github.com>
References: <5gK0b28ngntHphrDGwbgRkVsZEyr3LWbCEWVPXCQhk0=.37d1ea25-a6cb-4146-afc4-f63f9956aa86@github.com>
 <EcLC4-zm4KprFMHyEm0B0_NLmHl-iM9dmjU4MiIxnZM=.27b4a758-a7f5-4dbe-a007-2c8b931ced3a@github.com>
Message-ID: <pNX1sOtRclrYILx3lY4gX_jEcpTNVFYavoAsDH0APfw=.abd35331-c7c3-4286-9488-03e3b7ca8074@github.com>

On Sun, 21 Jul 2024 16:32:09 GMT, Technici4n <duke at openjdk.org> wrote:

> Oh, I missed the assignment and did not check with @LanceAndersen.

I don't have a problem with you or someone else taking ownership of this issue once the discussion that Alan points out comes to a conclusion.  Until the overall path forward is agreed, I would suggest that we hold off on any changes to ZipFS

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

PR Comment: https://git.openjdk.org/jdk/pull/20274#issuecomment-2243055981

From syan at openjdk.org  Mon Jul 22 14:34:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 22 Jul 2024 14:34:37 GMT
Subject: [jdk23] RFR: 8334339: Test
 java/nio/file/attribute/BasicFileAttributeView/CreationTime.java fails on
 alinux3
In-Reply-To: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
References: <vJh2TCmq_eOfNsSeHrid0wUOVgdr8JEoYVwMjX95tZo=.04b650d1-4f72-4658-a5b8-21e464b58eb5@github.com>
Message-ID: <2UP12Tfi5vGWCYACONjOUutDEaObI21OyVZD76sO0q0=.21e5ff7f-6545-4410-9599-8c54c1c25607@github.com>

On Mon, 24 Jun 2024 03:07:50 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> This pull request contains a backport of commit [7baddc20](https://github.com/openjdk/jdk/commit/7baddc202a9ab2b85401aa05f827678b514ebf55) from the [openjdk/jdk](https://git.openjdk.org/jdk) repository.
> 
> The commit being backported was authored by SendaoYan on 23 Jun 2024 and was reviewed by Alan Bateman.
> 
> Thanks!

Thanks for the sponsor.

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

PR Comment: https://git.openjdk.org/jdk/pull/19848#issuecomment-2243110934

From cushon at openjdk.org  Mon Jul 22 17:23:34 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 22 Jul 2024 17:23:34 GMT
Subject: Integrated: 8336844: ZipConstants64 defines duplicate constants
 EXTID_ZIP64 and ZIP64_EXTID
In-Reply-To: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
References: <_-UoH1ZpeHfkVaU6v58EGQJlHhP7VwyoZStSlcqqCc0=.4cc2e5c3-cebe-42cf-921d-196799b50469@github.com>
Message-ID: <5FxLuelH1WYNHvkVOgyvfVxwWL_ts-A28QkAWRtw3Mc=.2a98c664-c484-483b-8df6-65d48acee574@github.com>

On Fri, 19 Jul 2024 19:35:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change deduplicates constants in ZipConstants64 for the Zip64 Extended Information Extra Field Header ID (see APPNOTE.TXT 4.5.3).
> 
> I think there are arguments for consolidating on either `EXTID_ZIP64` or `ZIP64_EXTID`. The PR currently consolidates on `EXTID_ZIP64`, `ZIP64_EXTID` is also an option if there's a preference for that.
> 
> I noticed this while working on a zip64 bug in [JDK-8328995](https://bugs.openjdk.org/browse/JDK-8328995), I was reviewing places that handled zip64 extra fields and initially missed some because I was only looking at one of the constants.

This pull request has now been integrated.

Changeset: 8438c585
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8438c5853f4ae5cef4e861cd0b3952371c886f45
Stats:     12 lines in 6 files changed: 0 ins; 2 del; 10 mod

8336844: ZipConstants64 defines duplicate constants EXTID_ZIP64 and ZIP64_EXTID

Reviewed-by: jpai, vtewari, lancea

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

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

From duke at openjdk.org  Mon Jul 22 19:10:41 2024
From: duke at openjdk.org (duke)
Date: Mon, 22 Jul 2024 19:10:41 GMT
Subject: Withdrawn: 8332623: Remove setTTL()/getTTL() methods from
 DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket,
 byte)
In-Reply-To: <BdR7zzp1Dgzy2az6NLnfps7WQTbQmlqip0lY_xbI2is=.c25f26a8-29b1-4d49-81d3-c2a94d587fb9@github.com>
References: <BdR7zzp1Dgzy2az6NLnfps7WQTbQmlqip0lY_xbI2is=.c25f26a8-29b1-4d49-81d3-c2a94d587fb9@github.com>
Message-ID: <6mOQJiV64tTsgt19uGZ3ynsjBKfnLfiGDXMiRxR95hs=.76f6349a-7d0b-4260-9735-7616a24465f0@github.com>

On Sun, 26 May 2024 08:22:44 GMT, Lei Zhu <duke at openjdk.org> wrote:

> Remove setTTL()/getTTL() methods from DatagramSocketImpl/MulticastSocket and MulticastSocket.send(DatagramPacket, byte)

This pull request has been closed without being integrated.

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

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

From bpb at openjdk.org  Tue Jul 23 00:06:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Jul 2024 00:06:34 GMT
Subject: RFR: 8336339: (se) SelectionKey.interestOps(int) should not throw
 ClosedSelectorException [v2]
In-Reply-To: <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
References: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
 <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
Message-ID: <uToHJHYaGTFiyNsteClOjNF1G4b5wg9fI37hFMNbEkA=.388a535d-bd47-4080-b4ce-1531043140f5@github.com>

On Sun, 21 Jul 2024 06:58:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.
>> 
>> The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   raceRegisterAndClose fix

Looks all right to me.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20269#pullrequestreview-2192741168

From alanb at openjdk.org  Tue Jul 23 05:16:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Jul 2024 05:16:38 GMT
Subject: RFR: 8336339: (se) SelectionKey.interestOps(int) should not throw
 ClosedSelectorException [v2]
In-Reply-To: <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
References: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
 <LmJsKcfyg8A6sF3hFx2e4rfKlDMcfCz9Pp1dXvGOH80=.c34f96a0-0519-4214-83f7-1a7e47cb02d7@github.com>
Message-ID: <CQrBqfz0TkUdToOrv5wzasEokBpCOP0byd5NaTn8JFc=.d0517c61-5894-4128-a0d4-cecfc15eac73@github.com>

On Sun, 21 Jul 2024 06:58:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.
>> 
>> The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.
>
> Alan Bateman has updated the pull request incrementally with one additional commit since the last revision:
> 
>   raceRegisterAndClose fix

Thanks for the review.

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

PR Comment: https://git.openjdk.org/jdk/pull/20269#issuecomment-2244267723

From alanb at openjdk.org  Tue Jul 23 05:16:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Jul 2024 05:16:39 GMT
Subject: Integrated: 8336339: (se) SelectionKey.interestOps(int) should not
 throw ClosedSelectorException
In-Reply-To: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
References: <7uKE4IaLjKN2QFxgWtj5h-HpGNh8xZO4V6ZAmZxFj28=.57ee7274-9a34-49c9-b173-8b3762d01212@github.com>
Message-ID: <uTap_zNbBb9Xr9VoQER-MQteDc-Tzvj_ae2KAv-K3Sw=.71a495b4-f67b-4b00-b54d-102ece848271@github.com>

On Sat, 20 Jul 2024 12:52:09 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If a Selector is closed at around the same time that a registered key's interestOps (or variants) are used to change the interest ops then interestOps may (incorrectly) throw ClosedSelectorException (CSE) These methods are only specified to throw IAE or CancelledKeyException. Related is that closing a Selector ay around the same time that a channel is initially registered that can with NPE when attempting to remove the key for the channel's registration with the selector.
> 
> The issue with interestOps dates from JDK 11 when the Selector were mostly re-implemented. The issue with register racing with close may date back further.  The Selector implementations are updated to just queue the update so that CSE is not thrown. An option here would be to not queue or remove the update when racing with close but it's not worth it. For the NPE, the AbstractSelectableChannel.removeKey checks if the keys array has been initialized, which is consistent with other access.

This pull request has now been integrated.

Changeset: 9f03f687
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9f03f687556ee61436a1cb8c89ff063a7cbeaa51
Stats:     161 lines in 8 files changed: 127 ins; 25 del; 9 mod

8336339: (se) SelectionKey.interestOps(int) should not throw ClosedSelectorException

Reviewed-by: jpai, bpb

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

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

From jkratochvil at openjdk.org  Tue Jul 23 09:26:58 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Tue, 23 Jul 2024 09:26:58 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
Message-ID: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>

Alpine Linux 3.20 x86_64 compilation error:


.../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
.../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
  117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
      | ^~~~~~~~~~
      | sendfile
cc1: all warnings being treated as errors
* For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
                 from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
.../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
.../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
  214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
      | ^~~~~~~~~~
.../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
   31 | _result = _cmd; \
      | ^~~~
cc1: all warnings being treated as errors

`make/autoconf/flags-cflags.m4`

  if test "x$OPENJDK_TARGET_OS" = xlinux; then
    CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
    CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"

`sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

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

Commit messages:
 - 8336966: Alpine Linux x86_64 compilation error: sendfile64

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

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

From bpb at openjdk.org  Tue Jul 23 17:50:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Jul 2024 17:50:32 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <WgSNJC0xQbpMfpJOlpsdpZSOrhk3wxapMLhi3YNU8o8=.b76fb545-6331-4d3b-8f57-ba5ae94f4125@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

This change builds on linux-x64 and linux-aarch64 in our CI system and passed 10 repeats of the `java/nio/file` tests.

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2245871817

From alanb at openjdk.org  Tue Jul 23 17:59:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Jul 2024 17:59:31 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <QjIYTH-ysbU9ub6AAxCQdS493Iag0wvwKpLNm6wwwJE=.0b231dcc-e788-499a-9c59-9ba927103f37@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

I wonder if this can be tested on linux-x86 with glibc and file offsets > 2GB.

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2245891216

From vpetko at openjdk.org  Wed Jul 24 06:20:02 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 24 Jul 2024 06:20:02 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v5]
In-Reply-To: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
Message-ID: <mJw2Eu6gBZMy4bK986UHz5ZzKTW4CSICwyIvlrPyXW4=.7aef7f01-dd57-4f9a-97e1-2d4aa97c75fa@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:

  move function after statx_wrapper

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

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

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

  Stats: 28 lines in 1 file changed: 14 ins; 14 del; 0 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  Wed Jul 24 18:53:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 24 Jul 2024 18:53:38 GMT
Subject: RFR: 8336529: (fs) UnixFileAttributeViews setTimes() failing on
 armhf, Ubuntu noble [v5]
In-Reply-To: <mJw2Eu6gBZMy4bK986UHz5ZzKTW4CSICwyIvlrPyXW4=.7aef7f01-dd57-4f9a-97e1-2d4aa97c75fa@github.com>
References: <ZvkOuvXlJlltrG4JiJXvRBMgl64-uewiqagW8q5Uz10=.b48c90da-e94c-4d76-8632-3bebaf8cd515@github.com>
 <mJw2Eu6gBZMy4bK986UHz5ZzKTW4CSICwyIvlrPyXW4=.7aef7f01-dd57-4f9a-97e1-2d4aa97c75fa@github.com>
Message-ID: <A4UHUTqQRKQAvQfSOJEOEJNz_qn4PmzJV6LMhYmgdPs=.f69968a5-4338-451b-a63e-87e29bda273a@github.com>

On Wed, 24 Jul 2024 06:20:02 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:
> 
>   move function after statx_wrapper

Marked as reviewed by alanb (Reviewer).

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

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

From bpb at openjdk.org  Wed Jul 24 19:19:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Jul 2024 19:19:01 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
Message-ID: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@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.

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

Commit messages:
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337143
  Stats: 1265 lines in 75 files changed: 631 ins; 523 del; 111 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 Jul 24 19:19:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Jul 2024 19:19:01 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <3SJ0NGEh2LCiNc6XEAUta-0MR7aPIJvjw9NIW-xySNo=.9fba6440-4c7a-4e84-806d-12a6a522146f@github.com>

On Wed, 24 Jul 2024 19:11:42 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.

This change passes CI tiers 1-5 jobs on all platforms. With the change in place, one can remove `libnio` from the JDK and still be able to copy a file using FileChannel. Without the change, doing this will result in throwing a `java.lang.UnsatisfiedLinkError`.

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

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

From vpetko at openjdk.org  Wed Jul 24 20:21:34 2024
From: vpetko at openjdk.org (Vladimir Petko)
Date: Wed, 24 Jul 2024 20:21:34 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: <KGL5NzIfFDAV_pqiLQ3JOQqo-M5_2pEAZ05zpNmjUKU=.ffb63712-d9c9-4dd8-b9e7-0d43ccd6e5c1@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`. Maybe it would be better to have 

#if defined(__linux__) && defined(__arm__)
/**
 * Lookup functions with time_t parameter. Try to use 64 bit symbol
 * if sizeof(time_t) exceeds 32 bit.
 */
static void* lookup_time_t_function(const char* symbol, const char* symbol64) {
    void *func_ptr = NULL;
    if (sizeof(time_t) > 4) {
        func_ptr =  dlsym(RTLD_DEFAULT, symbol64);
    } 
    if (func_ptr == NULL)
        return dlsym(RTLD_DEFAULT, symbol);
   return func_ptr;
}
#endif

This is a bit longer, but does not break for musl.

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

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

From aturbanov at openjdk.org  Wed Jul 24 20:28:35 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 24 Jul 2024 20:28:35 GMT
Subject: Integrated: 8336755: Remove unused UNALIGNED field from view buffers
In-Reply-To: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
References: <2FdI3-WFR-IbniXJKjBYKoijAqshzQgEqhgPlHxf6pA=.0e163665-90a0-4447-ac37-28e22bcfb00e@github.com>
Message-ID: <D4S3Qe2Nnl011vXYthKn7B8z8723urnlsxpLuHlby04=.31a4ed1f-deb6-4490-8a21-abf4affa8add@github.com>

On Thu, 18 Jul 2024 11:58:30 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Actually it's used only by `DirectByteBuffer` and `DirectByteBufferR` classes.
> 
> List of affected classes:
> `DirectCharBufferS`, `DirectCharBufferU`,
> `DirectDoubleBufferS`, `DirectDoubleBufferU`,
> `DirectFloatBufferS`, `DirectFloatBufferU`,
> `DirectIntBufferS`, `DirectIntBufferU`,
> `DirectLongBufferS`, `DirectLongBufferU`,
> `DirectShortBufferS`, `DirectShortBufferU`
> 
> Tested `test/jdk/java/nio` on Linux x64 release.

This pull request has now been integrated.

Changeset: e716f5ed
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e716f5ed53c20f4235787e2d6927a16ebcf67b8f
Stats:     10 lines in 1 file changed: 2 ins; 8 del; 0 mod

8336755: Remove unused UNALIGNED field from view buffers

Reviewed-by: alanb, liach, bpb

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

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

From bpb at openjdk.org  Wed Jul 24 23:53:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Jul 2024 23:53:40 GMT
Subject: RFR: 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should
 pin when continuations supported
Message-ID: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>

In `sun.nio.fs.WindowsSecurity.enablePrivilege`, change `PreviewFeatures.isEnabled` to `ContinuationSupport.isSupported`.

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

Commit messages:
 - 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should pin when continuations supported

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

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

From bpb at openjdk.org  Wed Jul 24 23:53:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Jul 2024 23:53:40 GMT
Subject: RFR: 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege
 should pin when continuations supported
In-Reply-To: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
References: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
Message-ID: <MauDQtz8YvSuXXXdZR136LrxMS6wmxGLHgytMtD6vV0=.a69f5844-dfcd-440e-a28f-6ad0f15d9b76@github.com>

On Wed, 24 Jul 2024 23:49:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `sun.nio.fs.WindowsSecurity.enablePrivilege`, change `PreviewFeatures.isEnabled` to `ContinuationSupport.isSupported`.

CI tiers 1-3 passed.

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

PR Comment: https://git.openjdk.org/jdk/pull/20319#issuecomment-2249077416

From bpb at openjdk.org  Thu Jul 25 00:21:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Jul 2024 00:21:33 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <a7InmHyiws4GUFN8oY_qmUN8pHHA7QVRWJ_-ne23PSw=.f00de277-6f64-4f72-98f3-8e8becc7d85d@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

The change looks okay and does not break our 64-bit Linux implementations.
Has it been tested on 32-bit Linux?

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

PR Review: https://git.openjdk.org/jdk/pull/20295#pullrequestreview-2198011881

From jpai at openjdk.org  Thu Jul 25 05:02:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 25 Jul 2024 05:02:31 GMT
Subject: RFR: 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege
 should pin when continuations supported
In-Reply-To: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
References: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
Message-ID: <sGdnTQ5s0MvQpMBOFITmCcQZN4kQV8viFRvTlsnziyA=.7ac2f9fe-1018-4e3b-bc94-d7ff857532b8@github.com>

On Wed, 24 Jul 2024 23:49:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `sun.nio.fs.WindowsSecurity.enablePrivilege`, change `PreviewFeatures.isEnabled` to `ContinuationSupport.isSupported`.

The change looks OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20319#pullrequestreview-2198313793

From alanb at openjdk.org  Thu Jul 25 05:46:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Jul 2024 05:46:31 GMT
Subject: RFR: 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege
 should pin when continuations supported
In-Reply-To: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
References: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
Message-ID: <pZC6nW_Bh9qLnhnfvbWaM2lkenFnZvZgvzmrab5UnYc=.6ee75b60-7d94-492b-aa06-5ce24d99db6f@github.com>

On Wed, 24 Jul 2024 23:49:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `sun.nio.fs.WindowsSecurity.enablePrivilege`, change `PreviewFeatures.isEnabled` to `ContinuationSupport.isSupported`.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20319#pullrequestreview-2198358414

From alanb at openjdk.org  Thu Jul 25 10:07:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 25 Jul 2024 10:07:32 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>

On Wed, 24 Jul 2024 19:11:42 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.

I think this will require thinking about how to organize the native code in native/libjava as it hard to maintain if everything is in the same directory. We may have to create subdirectories, as we do in native/libnio.

Also think to work through some naming on IOUtil vs. NIOUtil as it won't be obvious to maintainers which class to use.

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

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

From bpb at openjdk.org  Thu Jul 25 15:21:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Jul 2024 15:21:31 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <ap4yj9gKbnRAOaJREauDAV5Ml8YnUroON21O05bZefk=.90ae7bf0-efef-4028-8fb9-b6ed1f6c8bcd@github.com>

On Wed, 24 Jul 2024 19:11:42 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.

Yes, I was wondering about changing the organization of the native code files. It's not great to have them all in `<platform>/libjava`.

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

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

From bpb at openjdk.org  Thu Jul 25 16:26:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Jul 2024 16:26:34 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <dU262HcWVwYqSuhqx3baNummFUV9Y_BMIvHlUaCkZW4=.d590410c-e36c-4efd-919e-20df9c7e38d7@github.com>

On Wed, 24 Jul 2024 19:11:42 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.

Perhaps `<platform>/native/libjava/nio/ch` and `<platform>/native/libjava/nio/fs`?

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

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

From bpb at openjdk.org  Thu Jul 25 21:02:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 25 Jul 2024 21:02:34 GMT
Subject: Integrated: 8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege
 should pin when continuations supported
In-Reply-To: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
References: <sHF_e5O1NbOOvE9DYXHQngHDbSEfZNiXxQlXWYDfki8=.ebe3769d-85bd-431f-8bcb-25cd39b78706@github.com>
Message-ID: <3D9kY0WYONtPAxsIcvBbiVAwESfY8fAsUhPgOxLMMf4=.409c6fa9-4cc5-48a6-8bc0-725daeb06ef6@github.com>

On Wed, 24 Jul 2024 23:49:32 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> In `sun.nio.fs.WindowsSecurity.enablePrivilege`, change `PreviewFeatures.isEnabled` to `ContinuationSupport.isSupported`.

This pull request has now been integrated.

Changeset: 8c28f25e
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8c28f25e1383f10a78b05e47ccf1cc4262069e69
Stats:     5 lines in 1 file changed: 1 ins; 1 del; 3 mod

8337124: (fs) sun.nio.fs.WindowsSecurity.enablePrivilege should pin when continuations supported

Reviewed-by: jpai, alanb

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

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

From jkratochvil at openjdk.org  Fri Jul 26 10:59:30 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Fri, 26 Jul 2024 10:59:30 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <iAj0pEMQoSsmLxRXno_H4fL-CL94dvpjaBIttMJm0-A=.135c72aa-0f43-45c5-82de-33d2f699288f@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

I have tested on x86 Debian trixies/sid that a file compiled with the same options works for `sendfile`. Is that sufficient?

(set -ex;rm -f in out;echo -n X|dd of=in bs=1 count=1 seek=$[5*1024*1024*1024];gcc -MMD -MF run.d.tmp -fvisibility=hidden -pipe -fstack-protector -DLIBC=gnu -D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64 -DLINUX -DDEBUG -g -gdwarf-4 -std=c11 -fno-strict-aliasing -Wall -Wextra -Wformat=2 -Wpointer-arith -Wsign-compare -Wunused-function -Wundef -Wunused-value -Wreturn-type -Wtrampolines -m32 -D_LITTLE_ENDIAN '-DARCH="i586"' -Di586 -march=i586 -fno-omit-frame-pointer -fno-lifetime-dse -fPIC -I/home/azul/azul/openjdk-git/src/java.base/linux/native/libnio -I/home/azul/azul/openjdk-git/src/java.base/unix/native/libnio -I/home/azul/azul/openjdk-git/src/java.base/share/native/libnio -I/home/azul/azul/openjdk-git/build/linux-x86-server-fastdebug/support/headers/java.base -I/home/azul/azul/openjdk-git/src/java.base/linux/native/libnio/ch -I/home/azul/azul/openjdk-git/src/java.base/unix/native/libnio/ch -I/home/azul/azul/openjdk-git/src/java.base/share/native/libnio/ch -I/home/azul/azul/open
 jdk-git/src/java.base/linux/native/libnio/fs -I/home/azul/azul/openjdk-git/src/java.base/unix/native/libnio/fs -I/home/azul/azul/openjdk-git/src/hotspot/share/include -I/home/azul/azul/openjdk-git/src/hotspot/os/posix/include -I/home/azul/azul/openjdk-git/src/java.base/linux/native/libjava -I/home/azul/azul/openjdk-git/src/java.base/unix/native/libjava -I/home/azul/azul/openjdk-git/src/java.base/share/native/libjava -I/home/azul/azul/openjdk-git/src/java.base/unix/native/libnet -I/home/azul/azul/openjdk-git/src/java.base/share/native/libnet -I/home/azul/azul/openjdk-git/build/linux-x86-server-fastdebug/support/modules_include/java.base -I/home/azul/azul/openjdk-git/src/java.base/unix/native/include -I/home/azul/azul/openjdk-git/src/java.base/share/native/include -g -gdwarf-4 -Wno-unused-parameter -Wno-unused -Werror -O2 -D_FORTIFY_SOURCE=2 -c -o run.o run.c -frandom-seed=run.c;gcc -o run run.o -Wall;./run;echo done;ls -l out;cat out;echo) 

#include <sys/sendfile.h>
#include <fcntl.h>
#include <assert.h>
#include <unistd.h>
int main() {
  int in_fd=open("in",O_RDONLY);
  assert(in_fd!=-1);
  int out_fd=open("out",O_WRONLY|O_CREAT|O_TRUNC,0644);
  assert(out_fd!=-1);
  off_t offset = 5LL*1024*1024*1024;
  ssize_t got=sendfile(out_fd,in_fd,&offset,1/*count*/);
  assert(got==1);
  int err;
  err=close(in_fd);
  assert(!err);
  err=close(out_fd);
  assert(!err);
  return 0;
}

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2252511077

From bpb at openjdk.org  Fri Jul 26 17:25:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Jul 2024 17:25:30 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <MI4zTcNcUlI0NrgUHzcqyY00l-AbYNqTcF5OR8l4wyA=.4c16f342-2e71-4298-b480-57b4a9ac486e@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

Marked as reviewed by bpb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20295#pullrequestreview-2202341997

From bpb at openjdk.org  Fri Jul 26 17:25:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Jul 2024 17:25:31 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <iAj0pEMQoSsmLxRXno_H4fL-CL94dvpjaBIttMJm0-A=.135c72aa-0f43-45c5-82de-33d2f699288f@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
 <iAj0pEMQoSsmLxRXno_H4fL-CL94dvpjaBIttMJm0-A=.135c72aa-0f43-45c5-82de-33d2f699288f@github.com>
Message-ID: <Tv5kFAGh7nqI3t1_vxEDUFpfnD03h3WfbwaFpgyNubM=.e6e2a794-237b-4cc6-a30f-dee3df3e44e3@github.com>

On Fri, 26 Jul 2024 10:56:40 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> I have tested on x86 Debian trixies/sid that a file compiled with the same options works for `sendfile`. Is that sufficient?

Looks all right to me.

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2253176411

From bpb at openjdk.org  Fri Jul 26 19:40:24 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Jul 2024 19:40:24 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v2]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <o8AMwn0LgrRO6D1WfU89F7xPTwt08LdsZKzsEijFfyg=.4fa9126b-98de-4878-b601-d02b03050e2b@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: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio

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

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

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

  Stats: 0 lines in 21 files changed: 0 ins; 0 del; 0 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 Jul 26 21:36:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Jul 2024 21:36:33 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava
In-Reply-To: <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9Hav9cYqe9BCvB8L4WOxBvTHydeiHrqKfmZhl_5nTSo=.1e4b8663-475c-489e-a757-88d248ce0fae@github.com>
Message-ID: <yq20lmGByFHXOtnDypoqB9IBiKA4MtpWciynkRd8rQs=.14028583-b497-4102-a3aa-597dd4820122@github.com>

On Thu, 25 Jul 2024 10:05:03 GMT, Alan Bateman <alanb 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?

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

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

From jkratochvil at openjdk.org  Sat Jul 27 02:03:35 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Sat, 27 Jul 2024 02:03:35 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <kbLiLT7cnCIzeydp_6x19hxOaQ2sMVNsXSziZse-WoQ=.50cd14af-3a88-4979-81d7-0cd98ffdd9ab@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

I have also tested my artificial testcase on Alpine Linux x86 3.20.2. I could not build OpenJDK trunk on Alpine Linux x86 as I haven't found any binary Boot JDK 22 build for 32-bit x86 musl (Alpine Linux has no Java builds). The only 32-bit x86 build I have found was BellSoft Liberica but that was glibc, not musl.

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2253707000

From duke at openjdk.org  Sat Jul 27 02:07:32 2024
From: duke at openjdk.org (duke)
Date: Sat, 27 Jul 2024 02:07:32 GMT
Subject: RFR: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <glpur_5B0fBK4M38_GJB-g4zmoKSuRjMTQEKUCK238Y=.cf6cf610-9b60-4abc-8b84-b9dd93242b2b@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

@jankratochvil 
Your change (at version 8408acc767d33cb801d66edb4afc36b1e3bc8957) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/20295#issuecomment-2253708230

From jkratochvil at openjdk.org  Mon Jul 29 09:21:39 2024
From: jkratochvil at openjdk.org (Jan Kratochvil)
Date: Mon, 29 Jul 2024 09:21:39 GMT
Subject: Integrated: 8336966: Alpine Linux x86_64 compilation error: sendfile64
In-Reply-To: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
References: <kjUOfy_XiIINV4ip07lssXBQWdn9w-rCfS32NfaaFmg=.7410ae2a-97f3-419f-8820-c7520dafc169@github.com>
Message-ID: <jkqEPkP23O7UnppglqCJsfkanrNskROkeDEE7wKQlp8=.2f45bbc9-380e-4353-8df0-29cb3a0258b7@github.com>

On Tue, 23 Jul 2024 09:22:05 GMT, Jan Kratochvil <jkratochvil at openjdk.org> wrote:

> Alpine Linux 3.20 x86_64 compilation error:
> 
> 
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c: In function 'Java_sun_nio_ch_FileDispatcherImpl_transferTo0':
> .../src/java.base/linux/native/libnio/ch/FileDispatcherImpl.c:117:9: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   117 | n = sendfile64(dstFD, srcFD, &offset, (size_t)count);
>       | ^~~~~~~~~~
>       | sendfile
> cc1: all warnings being treated as errors
> * For target support_native_java.base_libnio_LinuxNativeDispatcher.o:
> In file included from .../src/java.base/share/native/libjava/jni_util.h:30,
>                  from .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:27:
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c: In function 'Java_sun_nio_fs_LinuxNativeDispatcher_directCopy0':
> .../src/java.base/linux/native/libnio/fs/LinuxNativeDispatcher.c:214:21: error: implicit declaration of function 'sendfile64'; did you mean 'sendfile'? [-Werror=implicit-function-declaration]
>   214 | RESTARTABLE(sendfile64(dst, src, NULL, count), bytes_sent);
>       | ^~~~~~~~~~
> .../src/java.base/unix/native/libjava/jni_util_md.h:31:15: note: in definition of macro 'RESTARTABLE'
>    31 | _result = _cmd; \
>       | ^~~~
> cc1: all warnings being treated as errors
> 
> `make/autoconf/flags-cflags.m4`
> 
>   if test "x$OPENJDK_TARGET_OS" = xlinux; then
>     CFLAGS_OS_DEF_JVM="-DLINUX -D_FILE_OFFSET_BITS=64"
>     CFLAGS_OS_DEF_JDK="-D_GNU_SOURCE -D_REENTRANT -D_FILE_OFFSET_BITS=64"
> 
> `sendfile64` were introduced by: #10154 and inherited from https://github.com/openjdk/jdk/commit/a449cd08d7475215fe50218312a5d858068c694c

This pull request has now been integrated.

Changeset: db168d9e
Author:    Jan Kratochvil <jkratochvil at openjdk.org>
Committer: Yuri Nesterenko <yan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db168d9e10c4a302b743ee208e24ba7303fec582
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8336966: Alpine Linux x86_64 compilation error: sendfile64

Reviewed-by: bpb

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

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

From bpb at openjdk.org  Tue Jul 30 23:57:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Jul 2024 23:57:38 GMT
Subject: RFR: 8334405: java/nio/channels/Selector/SelectWithConsumer.java#id0
 failed in testWakeupDuringSelect
Message-ID: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>

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

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

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

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

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

From bpb at openjdk.org  Tue Jul 30 23:57:38 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Jul 2024 23:57:38 GMT
Subject: RFR: 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: <aPdbFrWQeRNOMtCojszva1YHP7zQ_KR698REN1-45cI=.f46eb88f-85f6-445b-ad73-6bdc443669ac@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.

There were no failures in a preliminary run of 50 test repeats on macOS Aarch64.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2259385450

From alanb at openjdk.org  Wed Jul 31 08:17:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Jul 2024 08:17:31 GMT
Subject: RFR: 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: <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@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.

Changing the test to use System.nanoTimes is good. I think I'd prefer if the assert message included both the expected and actual to make failure analysis a bit easier, only because these tests run with several VM modes that significantly slow execution, in addition to the clock changing. Also it usually a bit easier to see durations presented in millis, look at the tests that use expectDuration for examples.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2259929595

From dfuchs at openjdk.org  Wed Jul 31 10:03:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 31 Jul 2024 10:03:32 GMT
Subject: RFR: 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: <yyhJVUY5Nd2KI0kyaOX1ku8tU4YYP-uhTiIXRee42gQ=.893e3fcb-6870-4323-afd6-a91125ac0dbe@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.

Using `System.nanoTime` instead of `System.currentTimeMillis` looks like the right thing to do. I suggested some formatting edits to make the big power of tens more readable.

Oh I see Alan's comment now - I agree that printing millis would be more readable too.

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

> 313:             long duration = System.nanoTime() - start;
> 314:             assertTrue(n == 0);
> 315:             assertTrue(duration > 500000000, "select took " + duration + " ns");

Suggestion:

            assertTrue(duration > 500_000_000L, "select took " + duration + " ns");

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

> 337:             long duration = System.nanoTime() - start;
> 338:             assertTrue(n == 0);
> 339:             assertTrue(duration < 5000000000L, "select took " + duration + " ns");

Suggestion:

            assertTrue(duration < 5000_000_000L, "select took " + duration + " ns");

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

> 359:             long duration = System.nanoTime() - start;
> 360:             assertTrue(n == 0);
> 361:             assertTrue(duration > 500000000L && duration < 10*1000000000L,

Suggestion:

            assertTrue(duration > 500_000_000L && duration < 10_000_000_000L,

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

> 386:             long duration = System.nanoTime() - start;
> 387:             assertTrue(n == 0);
> 388:             assertTrue(duration < 5000000000L, "select took " + duration + " ns");

Suggestion:

            assertTrue(duration < 5000_000_000L, "select took " + duration + " ns");

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

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2209710555
PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2260137166
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698237118
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698241167
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698241279
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698242540

From bpb at openjdk.org  Wed Jul 31 15:18:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 15:18:31 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <yyhJVUY5Nd2KI0kyaOX1ku8tU4YYP-uhTiIXRee42gQ=.893e3fcb-6870-4323-afd6-a91125ac0dbe@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <yyhJVUY5Nd2KI0kyaOX1ku8tU4YYP-uhTiIXRee42gQ=.893e3fcb-6870-4323-afd6-a91125ac0dbe@github.com>
Message-ID: <xZIBYLLGmcSMY1RLDOjMHL_Wq1YtUCZG3hMmmhWpWdM=.951e0847-072f-45ee-840f-b8e89f481910@github.com>

On Wed, 31 Jul 2024 09:59:01 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> I suggested some formatting edits to make the big power of tens more readable.

Thanks. I have a mental block about remembering to use underscores in numbers.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2260769710

From bpb at openjdk.org  Wed Jul 31 17:55:06 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 17:55:06 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v2]
In-Reply-To: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
Message-ID: <FEv67jOU9M3l9Y3BynyCOtPZH3cCkMkZRNA2EHDSiA8=.b6ebb689-d096-4c27-866c-c59240b897a8@github.com>

> 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: Add and use expectDuration() in ms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20398/files
  - new: https://git.openjdk.org/jdk/pull/20398/files/3c1cdc83..e8914f75

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

  Stats: 41 lines in 1 file changed: 28 ins; 5 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/20398.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20398/head:pull/20398

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

From bpb at openjdk.org  Wed Jul 31 17:58:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 17:58:32 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@github.com>
Message-ID: <ERC3VsOdz0325oRX-71eZDEhb4Zd3HCbG7cKJ-FLapg=.70b52400-1530-4cf2-9e4f-b9ccab15cb7f@github.com>

On Wed, 31 Jul 2024 08:14:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Also it usually a bit easier to see durations presented in millis, look at the tests that use expectDuration for examples.

In [8914f7](https://github.com/openjdk/jdk/pull/20398/commits/e8914f7546e53d0c49b3ea4722038abfe3582551) I copied `expectDuration()` from `SelectorOps` and modified accordingly. If this looks reasonable, then `expectDuration()` should probably be factored out into a test library.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2261057265

From bpb at openjdk.org  Wed Jul 31 17:58:32 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 17:58:32 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v2]
In-Reply-To: <xZIBYLLGmcSMY1RLDOjMHL_Wq1YtUCZG3hMmmhWpWdM=.951e0847-072f-45ee-840f-b8e89f481910@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <yyhJVUY5Nd2KI0kyaOX1ku8tU4YYP-uhTiIXRee42gQ=.893e3fcb-6870-4323-afd6-a91125ac0dbe@github.com>
 <xZIBYLLGmcSMY1RLDOjMHL_Wq1YtUCZG3hMmmhWpWdM=.951e0847-072f-45ee-840f-b8e89f481910@github.com>
Message-ID: <XZ9cIWFnlyScVfqJTEcZV3RkPFmowL0bhlE-EqCrDGA=.5971b8a3-4db7-4bd4-9fd8-f9500227014a@github.com>

On Wed, 31 Jul 2024 15:16:24 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> > I suggested some formatting edits to make the big power of tens more readable.
> 
> Thanks. I have a mental block about remembering to use underscores in numbers.

If the `expectDuration()` approach is approved, then there is no need to change the ms to ns.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2261058832

From alanb at openjdk.org  Wed Jul 31 18:08:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Jul 2024 18:08:42 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v2]
In-Reply-To: <FEv67jOU9M3l9Y3BynyCOtPZH3cCkMkZRNA2EHDSiA8=.b6ebb689-d096-4c27-866c-c59240b897a8@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <FEv67jOU9M3l9Y3BynyCOtPZH3cCkMkZRNA2EHDSiA8=.b6ebb689-d096-4c27-866c-c59240b897a8@github.com>
Message-ID: <4hsBldAtaMmTIvovDuXUk3EZOmUtyeZDrnH3xIEfXFg=.1dbf020b-56aa-4715-bdb7-5d64a55191a1@github.com>

On Wed, 31 Jul 2024 17:55:06 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: Add and use expectDuration() in ms

Marked as reviewed by alanb (Reviewer).

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

> 311:             long start = millisTime();
> 312:             int n = sel.select(k -> assertTrue(false), 1000L);
> 313:             expectDuration(start, 501, Long.MAX_VALUE);

501 looks a bit strange here, I realise it's the same as > 500 that was there, just may be less surprising to see 500.

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

> 334:             long start = millisTime();
> 335:             int n = sel.select(k -> assertTrue(false), 60*1000);
> 336:             expectDuration(start, 0, 4999);

Maybe use 20_000 instead 4999 here, only to deal with really slow machines.

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

> 355:             long start = millisTime();
> 356:             int n = sel.select(k -> assertTrue(false), 60*1000);
> 357:             expectDuration(start, 501, 10*1000 - 1);

I think I would make this one 0, 20_000, again for slow machines and also because the test is about select rather than the accuracy of scheduleWakeup.

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

> 380:             long start = millisTime();
> 381:             int n = sel.select(k -> assertTrue(false), 60*1000);
> 382:             expectDuration(start, 0, 4999);

I would use 20_000 here too.

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

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2210810266
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698902303
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698902907
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698906013
PR Review Comment: https://git.openjdk.org/jdk/pull/20398#discussion_r1698906896

From alanb at openjdk.org  Wed Jul 31 18:08:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Jul 2024 18:08:43 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <ERC3VsOdz0325oRX-71eZDEhb4Zd3HCbG7cKJ-FLapg=.70b52400-1530-4cf2-9e4f-b9ccab15cb7f@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@github.com>
 <ERC3VsOdz0325oRX-71eZDEhb4Zd3HCbG7cKJ-FLapg=.70b52400-1530-4cf2-9e4f-b9ccab15cb7f@github.com>
Message-ID: <i9FuepZLTT1hVgfemqbdBulgacCWt0bs5Ra28e01-dM=.c1941598-9687-4f3d-9ef0-0a1df5c5f41e@github.com>

On Wed, 31 Jul 2024 17:55:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>  then `expectDuration()` should probably be factored out into a test library.

Potentially yes, we there are many tests that have to measure the duration of timed ops.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2261087311

From alanb at openjdk.org  Wed Jul 31 18:11:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Jul 2024 18:11:36 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v2]
In-Reply-To: <FEv67jOU9M3l9Y3BynyCOtPZH3cCkMkZRNA2EHDSiA8=.b6ebb689-d096-4c27-866c-c59240b897a8@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <FEv67jOU9M3l9Y3BynyCOtPZH3cCkMkZRNA2EHDSiA8=.b6ebb689-d096-4c27-866c-c59240b897a8@github.com>
Message-ID: <gBJAEZMVveP9HWwEJP9ZxDu1XVxYv7sZvQsCvD9wHmQ=.d886ee44-6d1c-49b5-83ee-240c557bc9f4@github.com>

On Wed, 31 Jul 2024 17:55:06 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: Add and use expectDuration() in ms

a

a

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

PR Review: https://git.openjdk.org/jdk/pull/20398#pullrequestreview-2210825618
Changes requested by alanb (Reviewer).

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

From bpb at openjdk.org  Wed Jul 31 18:21:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 18:21:31 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <i9FuepZLTT1hVgfemqbdBulgacCWt0bs5Ra28e01-dM=.c1941598-9687-4f3d-9ef0-0a1df5c5f41e@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@github.com>
 <ERC3VsOdz0325oRX-71eZDEhb4Zd3HCbG7cKJ-FLapg=.70b52400-1530-4cf2-9e4f-b9ccab15cb7f@github.com>
 <i9FuepZLTT1hVgfemqbdBulgacCWt0bs5Ra28e01-dM=.c1941598-9687-4f3d-9ef0-0a1df5c5f41e@github.com>
Message-ID: <vUAWamIJvwa-vTD-S40_We8pe3_g_fwjIEstmWrmhn4=.7f212873-9e6e-42a4-9dfc-6e38fa0884da@github.com>

On Wed, 31 Jul 2024 18:05:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > then `expectDuration()` should probably be factored out into a test library.
> 
> Potentially yes, we there are many tests that have to measure the duration of timed ops.

If this is to be done, I would prefer to handle this in a separate PR, possibly including some other tests to be identified.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2261131432

From alanb at openjdk.org  Wed Jul 31 18:21:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 31 Jul 2024 18:21:31 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect
In-Reply-To: <vUAWamIJvwa-vTD-S40_We8pe3_g_fwjIEstmWrmhn4=.7f212873-9e6e-42a4-9dfc-6e38fa0884da@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
 <39GUgPCKdi9SuSKrW0JntxggVdzJXKCYy7FE7tVft4I=.d58e051c-bd43-4c84-9662-f9b8a58b8d3d@github.com>
 <ERC3VsOdz0325oRX-71eZDEhb4Zd3HCbG7cKJ-FLapg=.70b52400-1530-4cf2-9e4f-b9ccab15cb7f@github.com>
 <i9FuepZLTT1hVgfemqbdBulgacCWt0bs5Ra28e01-dM=.c1941598-9687-4f3d-9ef0-0a1df5c5f41e@github.com>
 <vUAWamIJvwa-vTD-S40_We8pe3_g_fwjIEstmWrmhn4=.7f212873-9e6e-42a4-9dfc-6e38fa0884da@github.com>
Message-ID: <ewmP70DbVryAqlayQAO_m73jiLt-Z5AL8B_m42WMQOA=.663cadea-23fd-4539-bbb1-13143b161b71@github.com>

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

> If this is to be done, I would prefer to handle this in a separate PR, possibly including some other tests to be identified.

I agree.

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

PR Comment: https://git.openjdk.org/jdk/pull/20398#issuecomment-2261140432

From bpb at openjdk.org  Wed Jul 31 18:45:02 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 31 Jul 2024 18:45:02 GMT
Subject: RFR: 8334405:
 java/nio/channels/Selector/SelectWithConsumer.java#id0 failed in
 testWakeupDuringSelect [v3]
In-Reply-To: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
References: <9b50b-fnF9I8WIQqBZs2BvdaeWNSLb44qzUzm72wm2A=.aa370154-46ca-44e6-bffa-956f3be7f9bc@github.com>
Message-ID: <DukT5Z7a4NshzOiaQCdYJSfCqGqJcDYJqBjypOi8z9c=.cd8d2e69-0ed2-4572-84c5-4be49d502c01@github.com>

> 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

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20398/files
  - new: https://git.openjdk.org/jdk/pull/20398/files/e8914f75..b85bc381

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

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

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