From rriggs at openjdk.org  Mon Apr  1 14:22:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 1 Apr 2024 14:22:38 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8]
In-Reply-To: <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
Message-ID: <OXmJyIewO9j_7EQRuVe3asRTbdAwei0Nd6ZXyfmHHP4=.b633e7bb-465c-4f2c-862d-86e4211193e3@github.com>

On Wed, 13 Mar 2024 23:12:50 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 incrementally with one additional commit since the last revision:
> 
>   8298318: Add parameter checks for withExtension

A couple of points toward simplicity...
- the API needs to be intuitive and avoid system dependencies; a developer should not have to anticipate how the behavior is different on different operating systems; we used to call this write-once-run-anywhere; its still a good feature of most APIs. Especially, when it covers all of the common use cases.
- the use of Optional creates additional complexity that the developer has to code around; what could be a two state result becomes three.

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

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

From duke at openjdk.org  Mon Apr  1 21:02:02 2024
From: duke at openjdk.org (Anthony Vanelverdinghe)
Date: Mon, 1 Apr 2024 21:02:02 GMT
Subject: RFR: 8298318: (fs) APIs for handling filename extensions [v8]
In-Reply-To: <OXmJyIewO9j_7EQRuVe3asRTbdAwei0Nd6ZXyfmHHP4=.b633e7bb-465c-4f2c-862d-86e4211193e3@github.com>
References: <k_qwkU7LMQL-sl7NnyRSgz-oyFjzf1peir6OJ2htO2w=.da3406df-0cb3-4320-a432-6b21432dcc1c@github.com>
 <Tu8mCc9BKBsemBicfy1Aq8fiqhm5E1_FjiqBxuxrkSo=.db381f69-6d69-4a19-9eab-5a89fa53c0b3@github.com>
 <OXmJyIewO9j_7EQRuVe3asRTbdAwei0Nd6ZXyfmHHP4=.b633e7bb-465c-4f2c-862d-86e4211193e3@github.com>
Message-ID: <eeCImr1wjgtvMZyJzyH59VV6_N1Ur7UcbozpCZJIFsc=.ba630876-0c79-44fe-b1a4-8b516c8233f7@github.com>

On Mon, 1 Apr 2024 14:20:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> A couple of points toward simplicity...

Obviously I'm unable to get my arguments across, so let's agree to disagree.

> * the API needs to be intuitive and avoid system dependencies; a developer should not have to anticipate how the behavior is different on different operating systems; we used to call this write-once-run-anywhere; its still a good feature of most APIs. Especially, when it covers all of the common use cases.

We're all in favor of intuitive APIs, we just have different definitions of "intuitive". In my opinion, an intuitive file extension API would work like `System.lineSeparator()`, where the result differs on different OSes, but is the intuitive response on any given OS.

> * the use of Optional creates additional complexity that the developer has to code around; what could be a two state result becomes three.

None of my API proposals used `Optional` to return file extensions, so we agree that introducing `Optional` would be suboptimal.

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

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

From tprinzing at openjdk.org  Mon Apr  1 23:37:21 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 1 Apr 2024 23:37:21 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  Add support for AsynchronousFileChannel.force().

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/005db0df..8e20527e

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

  Stats: 124 lines in 5 files changed: 111 ins; 3 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

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

From alanb at openjdk.org  Tue Apr  2 04:51:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 04:51:04 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
Message-ID: <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>

On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for AsynchronousFileChannel.force().

src/java.base/share/classes/jdk/internal/event/FileForceEvent.java line 35:

> 33:  * {@link #commit(long, long, String, boolean)} method
> 34:  * must be the same as the order of the fields.
> 35:  */

You may have to re-word this comment to avoid confusion with the metaData parameter. That is, there is event metaData and there is file metaData, if you see what I mean.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547136136

From alanb at openjdk.org  Tue Apr  2 04:58:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 04:58:00 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
Message-ID: <Voj05vqYWf71oQ8xC9o2VU93cPVbJ5XS3oo5yprutHE=.a9904013-20df-434f-9887-62d088138481@github.com>

On Mon, 1 Apr 2024 23:37:21 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add support for AsynchronousFileChannel.force().

test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:

> 48: 
> 49:     public static void main(String[] args) throws Throwable {
> 50:         File blah = File.createTempFile("blah", null);

Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the recording is available in the event that the test fails.

test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:

> 62: 
> 63:             data.flip();
> 64:             ch.write(data, 0);

This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547139762
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1547138525

From alanb at openjdk.org  Tue Apr  2 07:50:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 2 Apr 2024 07:50:00 GMT
Subject: RFR: 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java
 should be able to test across file systems
In-Reply-To: <X1a36Ozx8HJetp-yQCJjTtL9eKUIhidWLz4UMBRafwI=.edbe8a3e-c3dd-485e-92ca-5d16ac7e0f64@github.com>
References: <X1a36Ozx8HJetp-yQCJjTtL9eKUIhidWLz4UMBRafwI=.edbe8a3e-c3dd-485e-92ca-5d16ac7e0f64@github.com>
Message-ID: <GphLbv9AeEM2nAi7S-snbKqxwTZS4FC_4BbErqGqK2E=.7c9e54ef-dc9d-4f27-b789-7457cf64fb02@github.com>

On Thu, 29 Feb 2024 01:19:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 1. Modify the test to allow specifying the location of the temporary directory to be distinct from that of the working directory.
> 2. Correctly handle the responses to `AccessDeniedException`s which occur when a move across different file systems fails.

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18052#pullrequestreview-1972914112

From jpai at openjdk.org  Tue Apr  2 14:49:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:49:12 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <tqTfOs3OsGnGuNjeZSyKn94BHNFvqLtSx9ulVZceDJw=.09a55777-5bd4-49a7-a588-1595841c010a@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

test/jdk/java/nio/channels/unixdomain/NonBlockingAccept.java line 68:

> 66:             // or exception could be thrown otherwise
> 67:         } finally {
> 68:             Files.deleteIfExists(addr.getPath());

Hello Bill, `addr` can be `null` here, so this has a potential of a `NullPointerException`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548038473

From jpai at openjdk.org  Tue Apr  2 14:56:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 2 Apr 2024 14:56:01 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v4]
In-Reply-To: <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <ap2euz_9D71i7sETBoE0v0XcvG6BLOhr-M-6lZ724mI=.43b029d0-afa5-4a9f-b5f3-d83d53859faf@github.com>
Message-ID: <hjGGd5cVG-hz1bHQi2Idj1sEPFmbGAPJtPe9c0B41OU=.057d651f-3341-47c9-94df-1102eaa32fbf@github.com>

On Tue, 26 Mar 2024 18:18:39 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/nio/channels/unixdomain/Bind.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

For the changes in `test/jdk/java/nio/file/Files/CheckPermissions.java` it would be good to have Alan and/or Brian's inputs. The test documentation says that the test relates to SecurityManager checks (and not filesystem permission checks), so the proposed changes in this PR to use a different parent directory for the temporary file(s) should be OK, but I am not familiar with that area to be certain about it.

test/jdk/sun/security/pkcs12/P12SecretKey.java line 69:

> 67: 
> 68:         File ksFile = File.createTempFile("test", ".test");
> 69:         ksFile.deleteOnExit();

Is there a reason why this change is done differently than the rest of the changes in this PR? Can we delete the `File` in a try/finally instead of enrolling a shutdown hook to delete it?

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

PR Comment: https://git.openjdk.org/jdk/pull/18352#issuecomment-2032269381
PR Review Comment: https://git.openjdk.org/jdk/pull/18352#discussion_r1548045308

From bhuang at openjdk.org  Tue Apr  2 16:29:21 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Tue, 2 Apr 2024 16:29:21 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

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

  Implemented review comments.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18352/files
  - new: https://git.openjdk.org/jdk/pull/18352/files/0f4130a9..81244609

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

  Stats: 30 lines in 2 files changed: 12 ins; 5 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/18352.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352

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

From bpb at openjdk.org  Tue Apr  2 17:16:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 2 Apr 2024 17:16:12 GMT
Subject: Integrated: 8327002: (fs) java/nio/file/Files/CopyMoveVariations.java
 should be able to test across file systems
In-Reply-To: <X1a36Ozx8HJetp-yQCJjTtL9eKUIhidWLz4UMBRafwI=.edbe8a3e-c3dd-485e-92ca-5d16ac7e0f64@github.com>
References: <X1a36Ozx8HJetp-yQCJjTtL9eKUIhidWLz4UMBRafwI=.edbe8a3e-c3dd-485e-92ca-5d16ac7e0f64@github.com>
Message-ID: <ZzfUsu4PDsh1psC9F-LkVlqsi8j8thLh2Ha-aKDztao=.c92cc3b3-a2b8-4e70-b01d-26ec15d0a4e7@github.com>

On Thu, 29 Feb 2024 01:19:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> 1. Modify the test to allow specifying the location of the temporary directory to be distinct from that of the working directory.
> 2. Correctly handle the responses to `AccessDeniedException`s which occur when a move across different file systems fails.

This pull request has now been integrated.

Changeset: dd5d7d07
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dd5d7d0770609a414438041f40a69f8770afe25c
Stats:     39 lines in 1 file changed: 27 ins; 0 del; 12 mod

8327002: (fs) java/nio/file/Files/CopyMoveVariations.java should be able to test across file systems

Reviewed-by: alanb

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

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

From jpai at openjdk.org  Wed Apr  3 01:00:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 3 Apr 2024 01:00:16 GMT
Subject: RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests [v5]
In-Reply-To: <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
 <OKHx2MPKdD8KfHo8DrMsVNIASU461yiCgH2_JB0A3CM=.6038dd44-085b-415f-970a-a33e3d6c29f0@github.com>
Message-ID: <kgWfaiFMCrvzhuGiWqxLcTEAdH5Tr-n31QeprERgKnA=.df1f42ef-6069-46ff-9985-f0731bb1c5b3@github.com>

On Tue, 2 Apr 2024 16:29:21 GMT, Bill Huang <bhuang at openjdk.org> wrote:

>> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
>> 
>> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
>> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
>> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.
>
> Bill Huang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implemented review comments.

Thank you for the update, Bill. The latest changes look OK to me.
I also heard from Bill that Alan has approved the changes too.

Before integrating, please run tier1, tier2 and tier3 (I haven't checked which tiers these changed tests belong to) to make sure nothing breaks unexpectedly.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18352#pullrequestreview-1975307573

From bhuang at openjdk.org  Wed Apr  3 17:07:12 2024
From: bhuang at openjdk.org (Bill Huang)
Date: Wed, 3 Apr 2024 17:07:12 GMT
Subject: Integrated: JDK-8327474 Review use of java.io.tmpdir in jdk tests
In-Reply-To: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
References: <Opl4N4uLMspuX-coReej6krdvLRd7A_TwiAdsDTCb9A=.a45dab6c-be3d-4cb1-875d-f0f1782ec4ed@github.com>
Message-ID: <4fPL8biQ1uu8AMKMNmt3x0yLRKa01iDp6OL5MXQgasM=.bc20a303-65dc-48b2-80eb-b9ef6cd15b00@github.com>

On Mon, 18 Mar 2024 16:47:24 GMT, Bill Huang <bhuang at openjdk.org> wrote:

> This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs.
> 
> Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. 
> - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup.
> - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use.

This pull request has now been integrated.

Changeset: 375bfac8
Author:    Bill Huang <bhuang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/375bfac8e7ff3f871e2d986876f91a5fba200c83
Stats:     193 lines in 11 files changed: 66 ins; 13 del; 114 mod

8327474: Review use of java.io.tmpdir in jdk tests

Reviewed-by: michaelm, jpai

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

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

From alanb at openjdk.org  Thu Apr  4 10:14:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 4 Apr 2024 10:14:29 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
Message-ID: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>

This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.

In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.

The changes have been baking in the loom repo for several months.

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

Commit messages:
 - Merge
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/18598/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18598&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8329593
  Stats: 1069 lines in 28 files changed: 221 ins; 623 del; 225 mod
  Patch: https://git.openjdk.org/jdk/pull/18598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18598/head:pull/18598

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

From jpai at openjdk.org  Tue Apr  9 13:56:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 13:56:11 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/java/lang/System.java line 2279:

> 2277:         }
> 2278: 
> 2279:         public void write(int b) throws IOException {

Nit - missing an `@Override`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557670428

From jpai at openjdk.org  Tue Apr  9 14:01:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:01:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/java/lang/System.java line 2262:

> 2260:         @Override
> 2261:         public long transferTo(OutputStream out) throws IOException {
> 2262:             boolean attempted = Blocker.begin();

Hello Alan, why do we mark transferTo as potentially blocking operation which might need compensation? As far as I can see in the underlying implementation of `FileInputStream.transferTo()` it either calls the `FileChannel.transferTo()` or does a `in.read()` followed by `out.write()`. In either of those cases wouldn't the underlying `InputStream/OutputStream` already have the necessary `Blocker` calls?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557679570

From jpai at openjdk.org  Tue Apr  9 14:17:00 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:17:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <P3M_aQvocA4ztcQhv_aoY2TcbRMVZjF7QEVsCcmtAm8=.38eddeb5-c89e-4396-a47a-4ccd70a63f75@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 104:

> 102:         if (compensating == COMPENSATING) {
> 103:             ForkJoinPools.endCompensatedBlock(getPool(), compensateValue);
> 104:             compensating = NOT_COMPENSATING;

For the sake for consistency between the state and the `compensateValue`, would it be good to reset `compensateValue` to `0` when we switch to `NOT_COMPENSATING`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557714608

From jpai at openjdk.org  Tue Apr  9 14:23:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 14:23:13 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 304:

> 302:                     return 0;
> 303:                 do {
> 304:                     boolean attempted = Blocker.begin(sync | direct);

Is the use of the bitwise operator `|` instead of `||` on `boolean` fields, here and other places, intentional?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557727112

From alanb at openjdk.org  Tue Apr  9 14:41:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:41:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <QdsRmmoGMwsfN8r9R063sk-YxfysfPNyRSCb9Iv1TH4=.025603ce-ff23-4791-a931-a6404b218922@github.com>
Message-ID: <h5V94FY4uI7Ydl-F9Q94ck1fh_cJSxgYkW0cEplYCxs=.2de09ef8-6b68-449e-af63-9a57a5dda745@github.com>

On Tue, 9 Apr 2024 14:20:51 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/sun/nio/ch/FileChannelImpl.java line 304:
> 
>> 302:                     return 0;
>> 303:                 do {
>> 304:                     boolean attempted = Blocker.begin(sync | direct);
> 
> Is the use of the bitwise operator `|` instead of `||` on `boolean` fields, here and other places, intentional?

Well spotted, these should be ||.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557761764

From alanb at openjdk.org  Tue Apr  9 14:46:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:46:00 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <LgTSy0w9XD0ENJDnIbKrZrQ4VV0Fv5-htKytWg1C4c0=.3b00a837-f7b6-4022-b8ce-b8168f6c5eb2@github.com>
Message-ID: <OH7P6lYcgVFp3jCc1zqe1nd_LbjTxAIG5lqK9F4-b_0=.8211a47f-83cf-407a-a0a0-58c31142fa18@github.com>

On Tue, 9 Apr 2024 13:53:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/java/lang/System.java line 2279:
> 
>> 2277:         }
>> 2278: 
>> 2279:         public void write(int b) throws IOException {
> 
> Nit - missing an `@Override`

Okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557769608

From alanb at openjdk.org  Tue Apr  9 14:53:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 14:53:12 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
Message-ID: <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>

On Tue, 9 Apr 2024 13:58:31 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/java/lang/System.java line 2262:
> 
>> 2260:         @Override
>> 2261:         public long transferTo(OutputStream out) throws IOException {
>> 2262:             boolean attempted = Blocker.begin();
> 
> Hello Alan, why do we mark transferTo as potentially blocking operation which might need compensation? As far as I can see in the underlying implementation of `FileInputStream.transferTo()` it either calls the `FileChannel.transferTo()` or does a `in.read()` followed by `out.write()`. In either of those cases wouldn't the underlying `InputStream/OutputStream` already have the necessary `Blocker` calls?

It's to increase the target parallelism for the duration of the transfer rather than specific read operations. System.in.transferTo(out) should be rare so it's not super important of course.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557786640

From jpai at openjdk.org  Tue Apr  9 15:02:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:02:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/Blocker.java line 79:

> 77:      * Marks the beginning of a possibly blocking operation.
> 78:      * @param blocking true if the operation may block, otherwise false
> 79:      * @return true if tryCompensate attempted

Was the use the word `tryCompensate` intentional here? I don't see that method in this class or in the implementation of `CarrierThread.beginBlocking()`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557805449

From jpai at openjdk.org  Tue Apr  9 15:10:09 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:10:09 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <d6GRU4vzFdWFvXBKJ4pBkzn8s4SQSn54hNSdORHDDwI=.daeb33bb-e31a-48ce-8a06-731ca9bd2533@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes.

What I understand of these changes overall is that, we no longer consider most of the file operations that work against an actual file as needing to be compensated by the ForkJoinPool. It doesn't matter even if the read() is being done with a large buffer - we still consider it an operation that doesn't deserve a compensation. 

The only file operations where we do appear to compensate is certain `write` operations which are backed by `O_SYNC`, `O_DSYNC` or direct IO writes.

The places where `FileOutputStream` is used against a file descriptor which isn't a file have been update to continue to using the `Blocker` to potentially compensate the operations.

Overall, based on my limited knowledge of this area, the changes look OK to me. There are a few questions I had which I've added inline. The copyright years on many of the files will need an update.

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

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2045417779

From alanb at openjdk.org  Tue Apr  9 15:10:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 15:10:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <FL2QV9WLto_qdVAm5QDAukEOHOj3wHoqFahokLR88nQ=.4b9aca70-46d0-4fdd-a8a6-3d20e8afb436@github.com>
Message-ID: <zzjRaseVQ0vvIKuwcB-oVLQLlplz_F4v7WJX3UbiuWA=.613d6131-0d4d-402a-8840-6f289372c765@github.com>

On Tue, 9 Apr 2024 14:59:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Was the use the word `tryCompensate` intentional here? I don't see that method in this class or in the implementation of `CarrierThread.beginBlocking()`

The FJP method is named tryCompensate and the same method name was used here at one point.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557814857

From jpai at openjdk.org  Tue Apr  9 15:18:10 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:18:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 81:

> 79:                 value = ForkJoinPools.beginCompensatedBlock(getPool());
> 80:             } catch (Throwable e) {
> 81:                 if (compensating == COMPENSATE_IN_PROGRESS) {

I don't fully follow these checks `if (compensating == COMPENSATE_IN_PROGRESS) {`. Surely it's not for concurrent access (given the `assert` at the start of this method, this code path happens in a single thread). So I think these checks are about the re-entrancy that is mentioned in the description of this PR.
In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level `if` block. When a thread enters the top level `if` block it immediately sets the `compensating` to `COMPENSATE_IN_PROGRESS`:


if (compensating == NOT_COMPENSATING) {
    compensating = COMPENSATE_IN_PROGRESS;
...

So a subsequent re-entrant call would never enter that top level `if` block again. Which leads me to question the need of these additional `if (compensating == COMPENSATE_IN_PROGRESS) {` checks. I feel like I am missing something in this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557834582

From jpai at openjdk.org  Tue Apr  9 15:22:08 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 9 Apr 2024 15:22:08 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <C0LCNaIZIWUc-tlb7oVcHSboIfVhkTFaTkF_KkM9YZ8=.500c781e-647b-4137-9938-873f370eb5ac@github.com>
 <E42flQwU68H3wf1wawnq7S5HURoh62icAA7DOHlbDH0=.6eae52ce-5a53-479c-809d-0a9c30fa7e45@github.com>
Message-ID: <DzazV7lzXkuR-GEBoV34UwxAEbpva5AkcM4MxyPh2Uw=.1594bcef-37b7-4606-b60c-ecc4b912b6c8@github.com>

On Tue, 9 Apr 2024 14:50:00 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> It's to increase the target parallelism for the duration of the transfer rather than specific read operations.

Do you think we would need to do something similar in`PipeInputStream` that belongs to `Process`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557842319

From alanb at openjdk.org  Tue Apr  9 16:25:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 9 Apr 2024 16:25:10 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <RCQwidP2djVhYAyfUdjmxC-psNb06IGNCK15ip46Cg4=.e8a29ba0-3fb1-4b6a-a206-8f6d5bf0f2f6@github.com>
Message-ID: <5lg4y7d6bB8Ukdegw2K2wwFR_g2gb8gwy5eQwFMsTug=.d580be20-7220-4159-9979-ecf923a231f3@github.com>

On Tue, 9 Apr 2024 15:15:52 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in the loom repo for several months.
>
> src/java.base/share/classes/jdk/internal/misc/CarrierThread.java line 81:
> 
>> 79:                 value = ForkJoinPools.beginCompensatedBlock(getPool());
>> 80:             } catch (Throwable e) {
>> 81:                 if (compensating == COMPENSATE_IN_PROGRESS) {
> 
> I don't fully follow these checks `if (compensating == COMPENSATE_IN_PROGRESS) {`. Surely it's not for concurrent access (given the `assert` at the start of this method, this code path happens in a single thread). So I think these checks are about the re-entrancy that is mentioned in the description of this PR.
> In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level `if` block. When a thread enters the top level `if` block it immediately sets the `compensating` to `COMPENSATE_IN_PROGRESS`:
> 
> 
> if (compensating == NOT_COMPENSATING) {
>     compensating = COMPENSATE_IN_PROGRESS;
> ...
> 
> So a subsequent re-entrant call would never enter that top level `if` block again. Which leads me to question the need of these additional `if (compensating == COMPENSATE_IN_PROGRESS) {` checks. I feel like I am missing something in this code.

> In the context of re-entrancy, if I am reading the code correctly, I don't see how a re-entrant call would end up on this line (and other similar lines) in this top level if block. When a thread enters the top level if block it immediately sets the compensating to COMPENSATE_IN_PROGRESS: I feel like I am missing something in this code.

These are fields on the carrier. If a virtual thread is preempted when compensating (or in the progress of) then it may continue on a different carrier or the original carrier may execute the task for a different virtual thread that does I/O. These are the cases that are handled here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1557950295

From bpb at openjdk.org  Wed Apr 10 00:44:13 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 10 Apr 2024 00:44:13 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

The `CarrierThread` changes look to be the most complicated here but I don't see any problems. Otherwise, I don't have any comments aside from some that @jaikiran already made hence not worth repeating.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-1990512527

From alanb at openjdk.org  Wed Apr 10 06:22:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Apr 2024 06:22:02 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <-Zea7R_YyTjfcZl140hcu3dXQiG132FP9Q__a447BgQ=.8237cc56-a0dd-413b-85a9-5c2115d956b5@github.com>
Message-ID: <hlRJCBsL83-Zqo_ruIuRinMCMV-ek40t0YRNc-Te9t8=.6b196b39-0360-4cea-9f0c-90ef8b8945c6@github.com>

On Wed, 10 Apr 2024 00:41:39 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> changes look to be the most complicated here but I don't see any problems. 

I have some changes come that should make this easier to read, I'll update the PR in a few days.

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

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2046613420

From alanb at openjdk.org  Wed Apr 10 06:26:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 10 Apr 2024 06:26:13 GMT
Subject: Withdrawn: 8329593: Drop adjustments to target parallelism when
 virtual threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <TJLEqj1uamveRWOCEQ9NAl3YN9J3O_SXEGKhDC_jM9Q=.2d7b6c98-c03a-4a94-849b-1ea96fd6cad4@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy as can happen if debugging code is added to ForkJoinPool, if there is preemption when attempting to compensate, or potentially forced preemption in the future. This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in the loom repo for several months.

This pull request has been closed without being integrated.

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

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

From fabian at buildbuddy.io  Wed Apr 10 15:35:15 2024
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Wed, 10 Apr 2024 17:35:15 +0200
Subject: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable
Message-ID: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>

When using WatchService to watch a directory, the
AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so that
e.g. creating 1000 files in a single watched directory inevitably results
in an OVERFLOW event.

The build system Bazel (https://github.com/bazelbuild/bazel) relies on the
JVM's WatchService mechanism for all its file system watches on Linux.
Since many Bazel users work with big monorepos, they tend to get into
situations where switching Git branches causes the hard-coded limit to be
hit frequently.

The constant comes with a comment saying "(in the future this may be
tunable)". Would a contribution be welcome that makes this limit tunable
via a system property (or some other mechanism)?

Fabian
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240410/208231ac/attachment-0001.htm>

From brian.burkhalter at oracle.com  Wed Apr 10 16:07:44 2024
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 10 Apr 2024 16:07:44 +0000
Subject: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable
In-Reply-To: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
References: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
Message-ID: <289EDDFE-3790-4A03-B7A1-A3E0DDFF75DE@oracle.com>

Hello Fabian,

Do you have any idea of how you might want to implement this or of how we might do it if we were to pick up the task? In any case, an enhancement issue should be filed [1].

Thanks,

Brian

[1] https://openjdk.org/guide/#filing-an-issue

On Apr 10, 2024, at 8:35?AM, Fabian Meumertzheim <fabian at buildbuddy.io> wrote:

When using WatchService to watch a directory, the AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so that e.g. creating 1000 files in a single watched directory inevitably results in an OVERFLOW event.

The build system Bazel (https://github.com/bazelbuild/bazel) relies on the JVM's WatchService mechanism for all its file system watches on Linux. Since many Bazel users work with big monorepos, they tend to get into situations where switching Git branches causes the hard-coded limit to be hit frequently.

The constant comes with a comment saying "(in the future this may be tunable)". Would a contribution be welcome that makes this limit tunable via a system property (or some other mechanism)?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240410/07f5aae3/attachment.htm>

From tprinzing at openjdk.org  Wed Apr 10 23:51:34 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 10 Apr 2024 23:51:34 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  remove selector spin event attempt and associated test.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/2e11e84a..d10be83e

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

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

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

From duke at openjdk.org  Thu Apr 11 00:14:55 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 11 Apr 2024 00:14:55 GMT
Subject: RFR: 8326951: Missing `@since` tags [v5]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <F9hstn9Pda5BuTsAIUGOZelo_b83H_DLOkQI2EyMhno=.11e0b618-2dd6-4ea7-8c34-454360a3eae6@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  Update full name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/7d6e969e..97f4c946

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

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

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

From Alan.Bateman at oracle.com  Thu Apr 11 06:14:18 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 11 Apr 2024 07:14:18 +0100
Subject: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable
In-Reply-To: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
References: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
Message-ID: <8428cfb6-bf01-4ded-9ebf-d078251bd6d7@oracle.com>



On 10/04/2024 16:35, Fabian Meumertzheim wrote:
> When using WatchService to watch a directory, the 
> AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so 
> that e.g. creating 1000 files in a single watched directory inevitably 
> results in an OVERFLOW event.

BTW: Do you handle the OVERFLOW event and use it to re-scan the directory?

-Alan

From alanb at openjdk.org  Thu Apr 11 06:42:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 06:42:46 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <vkAfGBcCwA134bS_a_-bKcz7a1NZSjQ81fUvuscEbaU=.4016c271-f0b7-4f4c-bf97-7dc38933f61a@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 40:

> 38: 
> 39:     @Label("SelectionKey Count")
> 40:     @Description("Number of channels ready for I/O or added to ready set")

We'll need to give you a better description for this. The value is the number of selection keys were updated by the selection operation. In many usages this will be the same as the number of keys added to the selected-key set (not "ready set") but they can be different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560501216

From egahlin at openjdk.org  Thu Apr 11 07:39:44 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 11 Apr 2024 07:39:44 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <KP4S1ke5frFQRlgdWqIvgX-o903FEspmLRsD_Dge4bk=.0ca033ef-62ad-4698-8435-18973fd7be56@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 33:

> 31: 
> 32: @Name(Type.EVENT_NAME_PREFIX + "SelectorSelect")
> 33: @Label("SelectorSelect")

This label should "Selector Select" and the description could be dropped as it doesn't add information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560574399

From egahlin at openjdk.org  Thu Apr 11 07:47:47 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 11 Apr 2024 07:47:47 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v6]
In-Reply-To: <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ZV8zUMeYhae1n645gAH-qySJOsIsUoqquiktYoN89nI=.829eee79-e941-44d7-b67a-6a8453fab5f0@github.com>
Message-ID: <utjR_oV2LV-NdTdhuX8AdZ5HboeEOEZ7JKToTUCAiJ8=.2a084b03-b842-4565-98c5-fdf98aae7fde@github.com>

On Wed, 10 Apr 2024 23:51:34 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove selector spin event attempt and associated test.

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:

> 42: 
> 43:     @Label("Timeout Value")
> 44:     @Description("Milliseconds to block, or zero to block indefinitely")

The unit should not be mentioned. A GUI will typically convert it from the TimeSpan information and it will just look confusing if the descriptions says milliseconds when it's, for instance, displayed as 1 s.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560583317

From dfuchs at openjdk.org  Thu Apr 11 09:15:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 09:15:42 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
Message-ID: <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>

On Mon, 26 Feb 2024 17:40:59 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Is n == 0 intended to detect a spinning condition where the selector goes back into select when the event has not been handled?
>> 
>> In that case should we still emit an event if a timeout is present and the duration is greater than the timeout? For instance, in the HttpClient, we have a selector thread that will wake up at regular interval - we set up a timeout which is the min between the next expected timer event and 1500ms. So that could potentially fire an event every 1500ms if for instance the connection threshold is less than 1500ms and the connection is idle.
>> 
>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
>> 
>> Or should it be ((n == 0 && durationToMillis(duration) < timeoutToMillis(timeout)) || ...)) (duration and timeout probably are not in the same unit of time) - also if shouldCommit return false will the event actually be emitted down the road? Because if not then the ( n== 0 || ...) won't work.
>
>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
> 
> The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout.

We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
@AlanBateman what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1560693482

From fabian at buildbuddy.io  Thu Apr 11 12:27:28 2024
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 14:27:28 +0200
Subject: Fwd: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable
In-Reply-To: <CAHY-eHsesT=JTGWYwcsUrNk0L4BcwwWnqrVtbNN7yjG2HqCEAw@mail.gmail.com>
References: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
 <289EDDFE-3790-4A03-B7A1-A3E0DDFF75DE@oracle.com>
 <CAHY-eHsesT=JTGWYwcsUrNk0L4BcwwWnqrVtbNN7yjG2HqCEAw@mail.gmail.com>
Message-ID: <CAHY-eHtDD+5EFCbJhZjo-XZVBwWDsbeNOLVU3L+_6GAavP9NnQ@mail.gmail.com>

(forwarding for posterity as I didn't reply all)

Hi Brian,

I filed an enhancement issue with internal review ID 9076868.

I would consider introducing a system property that, if set, is used to
populate the limit, with the default remaining at 512. This is because:
* File system watching often already requires user configuration (e.g.
bumping the default inotify limits on Linux).
* The end user of a JVM-based application knows which scale they operate
the application on and what the IO/CPU capabilities of the machine running
the application are.

An alternative could be to make this configurable on a per-WatchService
basis, but that would also require code changes before end users get to
benefit from the ability to increase the limit.

(This is my first enhancement request, so I apologize for not knowing the
processes that well. Thanks for the link!)

Best,
Fabian

On Wed, Apr 10, 2024 at 6:07?PM Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> Hello Fabian,
>
> Do you have any idea of how you might want to implement this or of how we
> might do it if we were to pick up the task? In any case, an enhancement
> issue should be filed [1].
>
> Thanks,
>
> Brian
>
> [1] https://openjdk.org/guide/#filing-an-issue
>
> On Apr 10, 2024, at 8:35?AM, Fabian Meumertzheim <fabian at buildbuddy.io>
> wrote:
>
> When using WatchService to watch a directory, the
> AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so that
> e.g. creating 1000 files in a single watched directory inevitably results
> in an OVERFLOW event.
>
> The build system Bazel (https://github.com/bazelbuild/bazel) relies on
> the JVM's WatchService mechanism for all its file system watches on Linux.
> Since many Bazel users work with big monorepos, they tend to get into
> situations where switching Git branches causes the hard-coded limit to be
> hit frequently.
>
> The constant comes with a comment saying "(in the future this may be
> tunable)". Would a contribution be welcome that makes this limit tunable
> via a system property (or some other mechanism)?
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240411/684bdc8d/attachment.htm>

From duke at openjdk.org  Thu Apr 11 12:27:55 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 12:27:55 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT
Message-ID: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>

? to avoid OVERFLOW_EVENT

The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

Commit messages:
 - 8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT

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

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

From fabian at buildbuddy.io  Thu Apr 11 12:30:31 2024
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 14:30:31 +0200
Subject: Fwd: Making AbstractWatchKey#MAX_EVENT_LIST_SIZE tunable
In-Reply-To: <CAHY-eHsS73ht2ypDekJmuRWbKOw=wc8SCPPJ6gW3H3PJOBV_Nw@mail.gmail.com>
References: <CAHY-eHuuWNgW=hHN_KEDqzNMPxdqcmBMpDxgofmdHjvh9c9LtA@mail.gmail.com>
 <8428cfb6-bf01-4ded-9ebf-d078251bd6d7@oracle.com>
 <CAHY-eHsS73ht2ypDekJmuRWbKOw=wc8SCPPJ6gW3H3PJOBV_Nw@mail.gmail.com>
Message-ID: <CAHY-eHv0-_hhpLU3RjqV==CyJpdGBZPYk7ESShvSHYX8gTUrMw@mail.gmail.com>

(forwarding for posterity as I didn't reply all)

On Thu, Apr 11, 2024 at 8:14?AM Alan Bateman <Alan.Bateman at oracle.com>
wrote:

>
>
> On 10/04/2024 16:35, Fabian Meumertzheim wrote:
> > When using WatchService to watch a directory, the
> > AbstractWatchKey#MAX_EVENT_LIST_SIZE constant (value: 512) makes it so
> > that e.g. creating 1000 files in a single watched directory inevitably
> > results in an OVERFLOW event.
>
> BTW: Do you handle the OVERFLOW event and use it to re-scan the directory?
>

Yes, the implementation in Bazel discards all incremental information on an
OVERFLOW event and non-incrementally rescans the directories. In fact, at
the moment it goes as far as disabling file watching capabilities entirely
when that happens, presumably to prevent flip-flopping between watching and
non-incremental scanning.


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

From alanb at openjdk.org  Thu Apr 11 12:41:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 12:41:41 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <BC3yA5FC5zZXeqkvBo-wQ3DJMWmf8g7k7PLfCIsP1DI=.c3b09aa2-9987-40fc-8715-e213ad6c5ec2@github.com>

On Thu, 11 Apr 2024 12:22:56 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 44:

> 42:     static final int MAX_EVENT_LIST_SIZE =
> 43:         AccessController.doPrivileged((PrivilegedAction<Integer>) () ->
> 44:                 Integer.getInteger("sun.nio.fs.maxWatchEvents", 512));

If this system property is going to be used outside of the JDK testing then it will need to be renamed to a jdk.* property and we'll need to create a CSR.

Also the implementation should use GetPropertyAction.privilegedGetProperty.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1560959614

From alanb at openjdk.org  Thu Apr 11 12:44:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 12:44:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <WUaFl6w2VplUgW_D-NC6x6156Jj95sQq1PlAx1HvyuM=.8a37e9fa-372f-4677-bdc7-c33883321627@github.com>

On Thu, 11 Apr 2024 12:22:56 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 39:

> 37: import java.util.stream.Collectors;
> 38: 
> 39: public class LotsOfEntries {

What platforms have you tested this on? I'm concerned that it may fail intermittently on some platforms/configurations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1560963365

From duke at openjdk.org  Thu Apr 11 13:06:56 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 13:06:56 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Rename property and use GetPropertyAction

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/4b11461c..26fc0111

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

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

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

From duke at openjdk.org  Thu Apr 11 14:04:43 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 14:04:43 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <BC3yA5FC5zZXeqkvBo-wQ3DJMWmf8g7k7PLfCIsP1DI=.c3b09aa2-9987-40fc-8715-e213ad6c5ec2@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <BC3yA5FC5zZXeqkvBo-wQ3DJMWmf8g7k7PLfCIsP1DI=.c3b09aa2-9987-40fc-8715-e213ad6c5ec2@github.com>
Message-ID: <MFxIyEdG8us1GHUuLpf7M7SjkC74cyb3JMic_yh1UZ4=.f5e24164-fa9b-4786-89a2-72d4e7a685b8@github.com>

On Thu, 11 Apr 2024 12:38:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> If this system property is going to be used outside of the JDK testing then it will need to be renamed to a jdk.* property and we'll need to create a CSR.

I renamed it to `jdk.nio.file.maxWatchEvents`, is that what you would expect?

Is a CSR something I can create myself? I followed the linked docs but it looks like I can't to do much without an OpenJDK account.

> Also the implementation should use GetPropertyAction.privilegedGetProperty.

Done.

> test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 39:
> 
>> 37: import java.util.stream.Collectors;
>> 38: 
>> 39: public class LotsOfEntries {
> 
> What platforms have you tested this on? I'm concerned that it may fail intermittently on some platforms/configurations.

It passes on Linux and macOS, I am in the process of testing it on Windows.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561074799
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561075354

From alanb at openjdk.org  Thu Apr 11 16:10:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 11 Apr 2024 16:10:45 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
Message-ID: <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>

On Thu, 11 Apr 2024 09:12:30 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>>> Maybe that's OK - and maybe in that case the onus is on the user to set a threshold greater than 1500ms?
>> 
>> The threshold is 20ms so these timed-select ops in the HTTP client will record an event when they timeout.
>
> We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
> @AlanBateman what do you think?

I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1561279163

From bpb at openjdk.org  Thu Apr 11 16:16:46 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 16:16:46 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: <GKZgWKS6xKJnaUoMyNrxkz7-MnZu1t6ucS8sTqAh1IM=.7968b48c-c839-4349-b7e5-3525fb1234c8@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-2050050747

From dfuchs at openjdk.org  Thu Apr 11 16:41:44 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 11 Apr 2024 16:41:44 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
Message-ID: <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>

On Thu, 11 Apr 2024 16:08:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> We should probably find a way to not emit the event if n == 0 and the operation was interrupted by `Selector.wakeUp`. Since we have another issue logged to emit a spin event, I wonder if we should only commit the event here if `n != 0`? The case where n == 0 would be handled by the spin event (added later) 
>> @AlanBateman what do you think?
>
> I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.

OK. I am a little concerned about how often this event will be fired when using the HttpClient - given that it's enabled by default. Idle connections sitting in the pool will fire it at least once per connection every 1500ms. That may not be too bad.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1561313983

From duke at openjdk.org  Thu Apr 11 17:25:42 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 17:25:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <MFxIyEdG8us1GHUuLpf7M7SjkC74cyb3JMic_yh1UZ4=.f5e24164-fa9b-4786-89a2-72d4e7a685b8@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <BC3yA5FC5zZXeqkvBo-wQ3DJMWmf8g7k7PLfCIsP1DI=.c3b09aa2-9987-40fc-8715-e213ad6c5ec2@github.com>
 <MFxIyEdG8us1GHUuLpf7M7SjkC74cyb3JMic_yh1UZ4=.f5e24164-fa9b-4786-89a2-72d4e7a685b8@github.com>
Message-ID: <ZI41ugGaqT6bCxy1O14jLiMHniMheYi0j_hGYOoCF2g=.2c1d1aa9-709a-481d-9dd3-314326b256e3@github.com>

On Thu, 11 Apr 2024 14:02:04 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 39:
>> 
>>> 37: import java.util.stream.Collectors;
>>> 38: 
>>> 39: public class LotsOfEntries {
>> 
>> What platforms have you tested this on? I'm concerned that it may fail intermittently on some platforms/configurations.
>
> It passes on Linux and macOS, I am in the process of testing it on Windows.

It also passes on Windows 11.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561359626

From bpb at openjdk.org  Thu Apr 11 19:43:40 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 19:43:40 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <MFxIyEdG8us1GHUuLpf7M7SjkC74cyb3JMic_yh1UZ4=.f5e24164-fa9b-4786-89a2-72d4e7a685b8@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <BC3yA5FC5zZXeqkvBo-wQ3DJMWmf8g7k7PLfCIsP1DI=.c3b09aa2-9987-40fc-8715-e213ad6c5ec2@github.com>
 <MFxIyEdG8us1GHUuLpf7M7SjkC74cyb3JMic_yh1UZ4=.f5e24164-fa9b-4786-89a2-72d4e7a685b8@github.com>
Message-ID: <39bNHgB8NO6vIREYycNHbFKLKNZwiJxWi7-w-ubZcq8=.c8e0e181-d983-4b70-9dcc-c02e30eae408@github.com>

On Thu, 11 Apr 2024 14:01:41 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> Is a CSR something I can create myself? I followed the linked docs but it looks like I can't to do much without an OpenJDK account.

Yes, I think that you would need an OpenJDK account. Failing that, we could create a CSR for you. It is often less work to create one only after there is consensus in the PR conversation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561559732

From bpb at openjdk.org  Thu Apr 11 19:54:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 19:54:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
Message-ID: <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>

On Thu, 11 Apr 2024 13:06:56 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename property and use GetPropertyAction

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 53:

> 51:             intValue = 512;
> 52:         }
> 53:         MAX_EVENT_LIST_SIZE = intValue;

What if `intValue` turns on to be non-positive for some reason? Should the value also be clamped to some maximum positive value, perhaps determined by some characteristic of the system on which the code is running?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561570713

From bpb at openjdk.org  Thu Apr 11 21:06:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 21:06:41 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
Message-ID: <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>

On Thu, 11 Apr 2024 19:51:57 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename property and use GetPropertyAction
>
> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 53:
> 
>> 51:             intValue = 512;
>> 52:         }
>> 53:         MAX_EVENT_LIST_SIZE = intValue;
> 
> What if `intValue` turns on to be non-positive for some reason? Should the value also be clamped to some maximum positive value, perhaps determined by some characteristic of the system on which the code is running?

If you are going the system property route, then something like this (not tested) might be in order:


    private static final int SYSTEM_MAX_EVENT_LIST_SIZE = 100_000; // value TBD
    private static final int DEFAULT_MAX_EVENT_LIST_SIZE = 512;

    static final int MAX_EVENT_LIST_SIZE;
    static {
        String rawValue = GetPropertyAction.privilegedGetProperty
            ("jdk.nio.file.maxWatchEvents",
            String.valueOf(DEFAULT_MAX_EVENT_LIST_SIZE));
        int intValue;
        try {
            intValue = Math.min(Math.max(Math.toIntExact(Long.decode(rawValue)),
                                         DEFAULT_MAX_EVENT_LIST_SIZE),
                                SYSTEM_MAX_EVENT_LIST_SIZE);
        } catch (NumberFormatException nfe) {
            intValue = DEFAULT_MAX_EVENT_LIST_SIZE;
        } catch (ArithmeticException ae) { // rawValue overflowed an int
            intValue = SYSTEM_MAX_EVENT_LIST_SIZE;
        }
        MAX_EVENT_LIST_SIZE = intValue;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561717151

From duke at openjdk.org  Thu Apr 11 21:50:57 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 21:50:57 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v3]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <V-4VPZeL23JHUb7b46qkrDoPXIqmweq__llclf4su9M=.4ba86d70-81f0-4d45-9e51-5c0af3270355@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Clamp to [512, Integer.MAX_VALUE]

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/26fc0111..aadce74b

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

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

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

From bpb at openjdk.org  Thu Apr 11 21:55:41 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 21:55:41 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v3]
In-Reply-To: <V-4VPZeL23JHUb7b46qkrDoPXIqmweq__llclf4su9M=.4ba86d70-81f0-4d45-9e51-5c0af3270355@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <V-4VPZeL23JHUb7b46qkrDoPXIqmweq__llclf4su9M=.4ba86d70-81f0-4d45-9e51-5c0af3270355@github.com>
Message-ID: <OWcHrKIB89MSSyvJhtcLzkm6Io3z0Pe0RSBzvXf-Zhw=.2313c04d-34d6-4011-a099-ed95347ac9c1@github.com>

On Thu, 11 Apr 2024 21:50:57 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Clamp to [512, Integer.MAX_VALUE]

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 52:

> 50:         int intValue;
> 51:         try {
> 52:             intValue = Math.clamp(

`Math.clamp` is definitely better than the bloated nonsense I had: good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561796726

From duke at openjdk.org  Thu Apr 11 21:55:42 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 11 Apr 2024 21:55:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
Message-ID: <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>

On Thu, 11 Apr 2024 21:04:13 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 53:
>> 
>>> 51:             intValue = 512;
>>> 52:         }
>>> 53:         MAX_EVENT_LIST_SIZE = intValue;
>> 
>> What if `intValue` turns on to be non-positive for some reason? Should the value also be clamped to some maximum positive value, perhaps determined by some characteristic of the system on which the code is running?
>
> If you are going the system property route, then something like this (not tested) might be in order:
> 
> 
>     private static final int SYSTEM_MAX_EVENT_LIST_SIZE = 100_000; // value TBD
>     private static final int DEFAULT_MAX_EVENT_LIST_SIZE = 512;
> 
>     static final int MAX_EVENT_LIST_SIZE;
>     static {
>         String rawValue = GetPropertyAction.privilegedGetProperty
>             ("jdk.nio.file.maxWatchEvents",
>             String.valueOf(DEFAULT_MAX_EVENT_LIST_SIZE));
>         int intValue;
>         try {
>             intValue = Math.min(Math.max(Math.toIntExact(Long.decode(rawValue)),
>                                          DEFAULT_MAX_EVENT_LIST_SIZE),
>                                 SYSTEM_MAX_EVENT_LIST_SIZE);
>         } catch (NumberFormatException nfe) {
>             intValue = DEFAULT_MAX_EVENT_LIST_SIZE;
>         } catch (ArithmeticException ae) { // rawValue overflowed an int
>             intValue = SYSTEM_MAX_EVENT_LIST_SIZE;
>         }
>         MAX_EVENT_LIST_SIZE = intValue;
>     }

Thanks for the suggestion, the validation was definitely lacking. I pushed a new version that uses `Math.clamp` to clamp to `[512, Integer.MAX_VALUE]` and thus at least cover the lower bound. 

I learned that e.g. NTFS allows up to 2^32 entries per directory (in theory, of course), so I don't see a strong argument in favor of an upper bound motivated by hardware. Do you have a particular bottleneck or problematic use case in mind?

What about the case where the event size reaches `Integer.MAX_SIZE`? An OVERFLOW event could be better than an OOM due to the list size getting too large, what do you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561797225

From bpb at openjdk.org  Thu Apr 11 22:03:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 11 Apr 2024 22:03:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
 <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
Message-ID: <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>

On Thu, 11 Apr 2024 21:53:14 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> If you are going the system property route, then something like this (not tested) might be in order:
>> 
>> 
>>     private static final int SYSTEM_MAX_EVENT_LIST_SIZE = 100_000; // value TBD
>>     private static final int DEFAULT_MAX_EVENT_LIST_SIZE = 512;
>> 
>>     static final int MAX_EVENT_LIST_SIZE;
>>     static {
>>         String rawValue = GetPropertyAction.privilegedGetProperty
>>             ("jdk.nio.file.maxWatchEvents",
>>             String.valueOf(DEFAULT_MAX_EVENT_LIST_SIZE));
>>         int intValue;
>>         try {
>>             intValue = Math.min(Math.max(Math.toIntExact(Long.decode(rawValue)),
>>                                          DEFAULT_MAX_EVENT_LIST_SIZE),
>>                                 SYSTEM_MAX_EVENT_LIST_SIZE);
>>         } catch (NumberFormatException nfe) {
>>             intValue = DEFAULT_MAX_EVENT_LIST_SIZE;
>>         } catch (ArithmeticException ae) { // rawValue overflowed an int
>>             intValue = SYSTEM_MAX_EVENT_LIST_SIZE;
>>         }
>>         MAX_EVENT_LIST_SIZE = intValue;
>>     }
>
> Thanks for the suggestion, the validation was definitely lacking. I pushed a new version that uses `Math.clamp` to clamp to `[512, Integer.MAX_VALUE]` and thus at least cover the lower bound. 
> 
> I learned that e.g. NTFS allows up to 2^32 entries per directory (in theory, of course), so I don't see a strong argument in favor of an upper bound motivated by hardware. Do you have a particular bottleneck or problematic use case in mind?
> 
> What about the case where the event size reaches `Integer.MAX_SIZE`? An OVERFLOW event could be better than an OOM due to the list size getting too large, what do you think?

I wrote a prototype of `WatchService` for macOS that used `kqueue(2)` and it ultimately was inviable because it used up all the file descriptors. That was what prompted my comment, but it is irrelevant, really.

In the absence of such a real world system constraint, possibly some moderately large upper bound could be established based on empirical observation. It you are reacting to the OVERFLOW events already, I doubt we need to get to `Integer.MAX_VALUE`. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1561802263

From duke at openjdk.org  Fri Apr 12 07:27:14 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 12 Apr 2024 07:27:14 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v4]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <nU4xlGvoT2nwOsFfA9XqVwRsxpeo64B5FSnBHWvL-DY=.592c501a-80d8-4f8b-9104-a1a1142b88df@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Clamp to Integer.MAX_VALUE - 1 and add docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/aadce74b..a56a780b

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

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

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

From duke at openjdk.org  Fri Apr 12 07:38:57 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 12 Apr 2024 07:38:57 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Use SOFT_MAX_ARRAY_LENGTH

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/a56a780b..280619d5

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

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

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

From duke at openjdk.org  Fri Apr 12 07:38:57 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 12 Apr 2024 07:38:57 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
 <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
 <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>
Message-ID: <ilwAyhCWEov5psdX1iyZa6Ernzgkx1ueec941ICGZkg=.935cf504-6496-42c7-964c-fa67abd61233@github.com>

On Thu, 11 Apr 2024 22:00:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> It you are reacting to the OVERFLOW events already, I doubt we need to get to Integer.MAX_VALUE. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.

I searched for usage reports and found users trying to watch "billions" of files at a time. Given that the actual limit is still user-configurable and the default remains at 512, I'm not sure whether there is any reasonable hard limit I could come up with that doesn't unnecessarily restrict users. After all, *if* a user sets this limit so high that they run into e.g. memory issues due to a large event list, wouldn't we consider them responsible for this?

In lieu of an actual upper bound I could justify, I went with `ArraySupport.SOFT_MAX_ARRAY_LENGTH` for now so that an OVERFLOW event is likely to. be sent before the list OOMs when trying to grow.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1562153021

From alanb at openjdk.org  Fri Apr 12 09:43:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 12 Apr 2024 09:43:43 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <ilwAyhCWEov5psdX1iyZa6Ernzgkx1ueec941ICGZkg=.935cf504-6496-42c7-964c-fa67abd61233@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
 <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
 <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>
 <ilwAyhCWEov5psdX1iyZa6Ernzgkx1ueec941ICGZkg=.935cf504-6496-42c7-964c-fa67abd61233@github.com>
Message-ID: <kKF9mlxLL406-TafY3LYBxlbJ236Yd3rOKXSsUR4CYE=.c88ae9c5-b30a-404b-a9e7-9537a87db186@github.com>

On Fri, 12 Apr 2024 07:36:09 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> I wrote a prototype of `WatchService` for macOS that used `kqueue(2)` and it ultimately was inviable because it used up all the file descriptors. That was what prompted my comment, but it is irrelevant, really.
>> 
>> In the absence of such a real world system constraint, possibly some moderately large upper bound could be established based on empirical observation. It you are reacting to the OVERFLOW events already, I doubt we need to get to `Integer.MAX_VALUE`. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.
>
>> It you are reacting to the OVERFLOW events already, I doubt we need to get to Integer.MAX_VALUE. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.
> 
> I searched for usage reports and found users trying to watch "billions" of files at a time. Given that the actual limit is still user-configurable and the default remains at 512, I'm not sure whether there is any reasonable hard limit I could come up with that doesn't unnecessarily restrict users. After all, *if* a user sets this limit so high that they run into e.g. memory issues due to a large event list, wouldn't we consider them responsible for this?
> 
> In lieu of an actual upper bound I could justify, I went with `ArraySupport.SOFT_MAX_ARRAY_LENGTH` for now so that an OVERFLOW event is likely to. be sent before the list OOMs when trying to grow.

The proposed change looks overly complicated. If the property is property is set to garbage or a numeric value < 1 then there may be an argument to use the default but it seems very strange to disallow setting it to a value such as 128.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1562313150

From duke at openjdk.org  Fri Apr 12 10:08:43 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 12 Apr 2024 10:08:43 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <kKF9mlxLL406-TafY3LYBxlbJ236Yd3rOKXSsUR4CYE=.c88ae9c5-b30a-404b-a9e7-9537a87db186@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
 <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
 <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>
 <ilwAyhCWEov5psdX1iyZa6Ernzgkx1ueec941ICGZkg=.935cf504-6496-42c7-964c-fa67abd61233@github.com>
 <kKF9mlxLL406-TafY3LYBxlbJ236Yd3rOKXSsUR4CYE=.c88ae9c5-b30a-404b-a9e7-9537a87db186@github.com>
Message-ID: <4ax2Nu-MrnlhObIp-i4efJWsojhUV9xVYaz7J2D1OdI=.f0b13958-2ff1-4dbb-9bfb-694b4a3ed472@github.com>

On Fri, 12 Apr 2024 09:41:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> It you are reacting to the OVERFLOW events already, I doubt we need to get to Integer.MAX_VALUE. Maybe all that's needed is something large enough to reduce the frequency of OVERFLOW events. I don't have any insight into that.
>> 
>> I searched for usage reports and found users trying to watch "billions" of files at a time. Given that the actual limit is still user-configurable and the default remains at 512, I'm not sure whether there is any reasonable hard limit I could come up with that doesn't unnecessarily restrict users. After all, *if* a user sets this limit so high that they run into e.g. memory issues due to a large event list, wouldn't we consider them responsible for this?
>> 
>> In lieu of an actual upper bound I could justify, I went with `ArraySupport.SOFT_MAX_ARRAY_LENGTH` for now so that an OVERFLOW event is likely to. be sent before the list OOMs when trying to grow.
>
> The proposed change looks overly complicated. If the property is set to garbage or a numeric value < 1 then there may be an argument to use the default but it seems very strange to disallow setting it to a value such as 128.

I'm fully open to changing it so that the default is only used if `intValue <= 0`. 

An argument I could see in favor of enforcing a minimum of 512 is backwards compatibility: It's possible that there are applications out there relying on being able to receive at least 512 file system events without an (automatic) OVERFLOW. If users of those applications set a lower limit, this could result in subtle thrashing issues that may not be directly attributable to this setting. 

But this is just theory and I'm not sure what the right balance between this concern and simplicity is. @AlanBateman Curious to hear your thoughts on this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1562342768

From bpb at openjdk.org  Fri Apr 12 15:26:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Apr 2024 15:26:43 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v2]
In-Reply-To: <4ax2Nu-MrnlhObIp-i4efJWsojhUV9xVYaz7J2D1OdI=.f0b13958-2ff1-4dbb-9bfb-694b4a3ed472@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kHPWdMOcIIp_O46WwrqRMdm5Bw67ZVvOESCK-X1Wdmw=.d1d8a73d-7ae0-40dc-af10-4f8feba7f09c@github.com>
 <MUnOHhrtqCoswiZnTwaa06MD_6rUdO2Bk76cHM-wS2Y=.0e4dffbf-4664-4a33-b012-2aa75a163543@github.com>
 <uuDzH1Iti-2u2Mtol9R00cZvWC4KTKsBKTtrFVmdk94=.9185eba0-0bdd-4e7c-98e4-e57c47124a0d@github.com>
 <aWBp3TRTMAGkaSQVL5-_aXXuIdEdMj_rXzFpToNFilo=.a60bfbd3-7b13-4951-91ec-0a68b63c148f@github.com>
 <FabS6kzCTCo0oGQXDBsYRnNCB9Xn-8AhMhmYMPyfFn0=.429a968a-85a0-428e-a44a-5f9d7f388c66@github.com>
 <ilwAyhCWEov5psdX1iyZa6Ernzgkx1ueec941ICGZkg=.935cf504-6496-42c7-964c-fa67abd61233@github.com>
 <kKF9mlxLL406-TafY3LYBxlbJ236Yd3rOKXSsUR4CYE=.c88ae9c5-b30a-404b-a9e7-9537a87db186@github.com>
 <4ax2Nu-MrnlhObIp-i4efJWsojhUV9xVYaz7J2D1OdI=.f0b13958-2ff1-4dbb-9bfb-694b4a3ed472@github.com>
Message-ID: <zQwtclYDBGIumj-L8P5MO2eBJSAoxgbt4_3ftKPl0kE=.56348da1-a594-4d65-b794-58f8ab9f3b99@github.com>

On Fri, 12 Apr 2024 10:06:23 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> An argument I could see in favor of enforcing a minimum of 512 is backwards compatibility

That was my thinking on this topic, but I would be okay with a minimum of 1.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1562707693

From bruno.ploumhans at gmail.com  Fri Apr 12 17:42:02 2024
From: bruno.ploumhans at gmail.com (Bruno Ploumhans)
Date: Fri, 12 Apr 2024 19:42:02 +0200
Subject: Thread interruption while reading from a ZipFS entry will close the
 entire FS
Message-ID: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>

 Hi,

When reading from a zip file on the disk, ZipFileSystem uses a
SeekableByteChannel internally to read from the zip file. Unfortunately,
this channel is interruptible, and therefore a single thread interruption
while reading from a ZipPath will make the entire ZipFS unusable. This is
problematic for long-lived ZipFileSystems that can be used by multiple
threads. I suppose that this is a bug?

One workaround is to use deep reflection to call `setUninterruptible()` on
the underlying file channel if supported, however I am not sure of the
side-effects. It does seem to fix this issue though.

I couldn't get https://bugreport.java.com to work so I'm posting this here
instead. Thanks in advance.

Regards,
Bruno Ploumhans

PS: Here is a snippet that consistently reproduces the issue on my machine:
it crashes on the second read attempt with a `ClosedChannelException`.

import java.io.*;
import java.nio.file.*;
import java.util.zip.*;

public class nio_repro {
    public static void main(String[] args) throws Exception {
        // Create a dummy test.zip
        File f = new File("test.zip");
        try (ZipOutputStream out = new ZipOutputStream(new
FileOutputStream(f))) {
            ZipEntry e = new ZipEntry("entry1.txt");
            out.putNextEntry(e);

            byte[] data1 = "Text1".repeat(100000000).getBytes(); // Large
entry so it takes time to read
            out.write(data1, 0, data1.length);
            out.closeEntry();
        }

        // Open zip FS
        FileSystem fs = FileSystems.newFileSystem(f.toPath());
        // Start reading on second thread
        Thread secondThread = Thread.ofPlatform().start(() -> {
            try {
                byte[] contents =
Files.readAllBytes(fs.getPath("entry1.txt"));
            } catch (IOException ex) {
                throw new UncheckedIOException(ex);
            }
        });
        Thread.sleep(1);
        // Interrupt read
        secondThread.interrupt();
        // Try to read again - this should crash with a
ClosedChannelException
        byte[] contents = Files.readAllBytes(fs.getPath("entry1.txt"));

        System.out.println("Successfully read " + contents.length + "
bytes.");
    }
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240412/ba32aa0b/attachment.htm>

From Alan.Bateman at oracle.com  Fri Apr 12 17:49:05 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Fri, 12 Apr 2024 18:49:05 +0100
Subject: Thread interruption while reading from a ZipFS entry will close
 the entire FS
In-Reply-To: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
Message-ID: <04377785-23aa-4254-b215-43457aed0f34@oracle.com>



On 12/04/2024 18:42, Bruno Ploumhans wrote:
> Hi,
>
> When reading from a zip file on the disk, ZipFileSystem uses a 
> SeekableByteChannel internally to read from the zip file. 
> Unfortunately, this channel is interruptible, and therefore a single 
> thread interruption while reading from a ZipPath will make the entire 
> ZipFS unusable. This is problematic for long-lived ZipFileSystems that 
> can be used by multiple threads. I suppose that this is a bug?

There are a couple of issues on this, JDK-8316882 [1]. We had proposals 
in the past to allow a FileChannel be created as "uninterruptible" but 
there wasn't consensus on moving forward on that.

-Alan

[1] https://bugs.openjdk.org/browse/JDK-8316882
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240412/22939c2e/attachment-0001.htm>

From bruno.ploumhans at gmail.com  Fri Apr 12 19:34:04 2024
From: bruno.ploumhans at gmail.com (Bruno Ploumhans)
Date: Fri, 12 Apr 2024 21:34:04 +0200
Subject: Fwd: Thread interruption while reading from a ZipFS entry will close
 the entire FS
In-Reply-To: <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
Message-ID: <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>

Thanks Alan, I had missed that issue.

There are a few places in NIO with code similar to:
if (channel instanceof FileChannelImpl channel) {
   channel.setUninterruptible();
}
For example, FileSystemProvider.newInputStream or Files.readAllBytes.
This change seems to have been introduced (by you!) in [1] to fix a
similar issue with these functions.

I am inclined to believe that Files.readAllBytes is doing the right
thing, so I would propose 3 fix strategies:
1. Change Files.newByteChannel to call setUninterruptible() on FileChannelImpl.
2. Call setUninterruptible() on FileChannelImpl from ZipFS.
3. Same as 2. but with the addition of a new API method for
setUninterruptible, to expose the same functionality to other FS
implementations.

I think that 2. would be the simplest fix (no new API, no change of
contract), and would not prevent going with 1. or 3. in the future if
desired. Should I work on a patch?

Regards,
Bruno

[1] https://github.com/openjdk/jdk/commit/807c4ae4a378f14b6912fa848eaf59af20b99e22


Le ven. 12 avr. 2024 ? 19:49, Alan Bateman <Alan.Bateman at oracle.com> a ?crit :
>
>
>
> On 12/04/2024 18:42, Bruno Ploumhans wrote:
>
> Hi,
>
> When reading from a zip file on the disk, ZipFileSystem uses a SeekableByteChannel internally to read from the zip file. Unfortunately, this channel is interruptible, and therefore a single thread interruption while reading from a ZipPath will make the entire ZipFS unusable. This is problematic for long-lived ZipFileSystems that can be used by multiple threads. I suppose that this is a bug?
>
>
> There are a couple of issues on this, JDK-8316882 [1]. We had proposals in the past to allow a FileChannel be created as "uninterruptible" but there wasn't consensus on moving forward on that.
>
> -Alan
>
> [1] https://bugs.openjdk.org/browse/JDK-8316882

From bpb at openjdk.org  Fri Apr 12 20:16:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 12 Apr 2024 20:16:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
Message-ID: <GFX1TKbKlT2DK_51-I-J05L81w-NPzTg1-_F8CMY2tU=.f69336d2-7eb2-485e-88f2-bcbfde05c09f@github.com>

On Fri, 12 Apr 2024 07:38:57 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SOFT_MAX_ARRAY_LENGTH

A build of the current JDK mainline patched with this change (webrev 04 diff) passed 300 repeats of the test on linux-aarch64, macosx-x64, and windows-x64.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2052461396

From Alan.Bateman at oracle.com  Sat Apr 13 06:57:43 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sat, 13 Apr 2024 07:57:43 +0100
Subject: Fwd: Thread interruption while reading from a ZipFS entry will
 close the entire FS
In-Reply-To: <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
 <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
Message-ID: <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>

On 12/04/2024 20:34, Bruno Ploumhans wrote:
> :
>
> I am inclined to believe that Files.readAllBytes is doing the right
> thing, so I would propose 3 fix strategies:
> 1. Change Files.newByteChannel to call setUninterruptible() on FileChannelImpl.
> 2. Call setUninterruptible() on FileChannelImpl from ZipFS.
> 3. Same as 2. but with the addition of a new API method for
> setUninterruptible, to expose the same functionality to other FS
> implementations.
We've had previous discussion on this topic [1], it may be time to think 
about this again.

-Alan

[1] https://mail.openjdk.org/pipermail/nio-dev/2018-February/004756.html
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240413/af587540/attachment.htm>

From bruno.ploumhans at gmail.com  Sat Apr 13 16:09:21 2024
From: bruno.ploumhans at gmail.com (Bruno Ploumhans)
Date: Sat, 13 Apr 2024 18:09:21 +0200
Subject: Fwd: Thread interruption while reading from a ZipFS entry will
 close the entire FS
In-Reply-To: <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
 <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
 <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>
Message-ID: <CAH225Xhwz0sYyN=bnaFEHEVmCBiUPNnNphYLVjBLCVtG+FKCJA@mail.gmail.com>

> (maybe StandardOpenOption.UNINTERRUPTIBLE)

That sounds reasonable. `Files.newInputStream` already chooses to make
the input stream uninterruptible. Should it ignore the option then? Or
forward it, potentially breaking code that is not passing the option
but expecting the channel to be uninterruptible?

If there is a well-specified API for uninterruptible channels, it
might be worth moving the logic for `beginBlocking` and `endBlocking`
to `AbstractInterruptibleChannel`. This raises the question of how a
child class should set `uninterruptible`, and if it should be settable
later.

From Alan.Bateman at oracle.com  Sun Apr 14 06:16:29 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Sun, 14 Apr 2024 07:16:29 +0100
Subject: Fwd: Thread interruption while reading from a ZipFS entry will
 close the entire FS
In-Reply-To: <CAH225Xhwz0sYyN=bnaFEHEVmCBiUPNnNphYLVjBLCVtG+FKCJA@mail.gmail.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
 <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
 <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>
 <CAH225Xhwz0sYyN=bnaFEHEVmCBiUPNnNphYLVjBLCVtG+FKCJA@mail.gmail.com>
Message-ID: <ef73eb49-cd2a-4abb-8255-aea27ca80d70@oracle.com>

On 13/04/2024 17:09, Bruno Ploumhans wrote:
> If there is a well-specified API for uninterruptible channels, it
> might be worth moving the logic for `beginBlocking` and `endBlocking`
> to `AbstractInterruptibleChannel`.

I don't think that would make sense. The reason the thread has been 
interrupted is because something wants to cancel what it are doing as 
quickly as possible. It's important that operations on network channels 
that block indefinitely are interruptible. The discussion is focused on 
FileChannel as it is somewhat questionable whether it should have been 
an InterruptibleChannel in the first place. It's not always feasible, 
plus you get into issues where a FileChannel is part of low level 
infrastructure and used by concurrent threads accessing different parts 
of the file. Also when wrapped as InputStream/OutputStream then the 
result I/O streams are interruptible which can be surprising.

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

From bpb at openjdk.org  Mon Apr 15 17:34:42 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 15 Apr 2024 17:34:42 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
Message-ID: <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>

On Fri, 12 Apr 2024 07:38:57 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use SOFT_MAX_ARRAY_LENGTH

An `@implNote` about the property and its behavior could be added in `WatchService`.

Once the property name, its behavior, and the `@implNote` are decided I can file the CSR.

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 49:

> 47:     static {
> 48:         String rawValue = GetPropertyAction.privilegedGetProperty(
> 49:             "jdk.nio.file.maxWatchEvents",

What about `"jdk.nio.file.WatchService.maxEventsPerPoll"` instead?

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 57:

> 55:             intValue = Math.clamp(
> 56:                 Long.decode(rawValue),
> 57:                 DEFAULT_MAX_EVENT_LIST_SIZE,

Probably we should allow positive values with no minimum. If it's zero or negative then I am not sure whether that would be an error.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2057454337
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1566201273
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1566203428

From tprinzing at openjdk.org  Mon Apr 15 20:44:16 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 20:44:16 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v3]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <Givs1GzHovxqZGXwDIZfuCAclLZPlhnVAe7Zw-DmWXQ=.07b177dd-a641-4992-a00e-33999ff05719@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  requested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/8e20527e..6903c823

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

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

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

From tprinzing at openjdk.org  Mon Apr 15 20:44:17 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 20:44:17 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
Message-ID: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>

On Tue, 2 Apr 2024 04:48:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add support for AsynchronousFileChannel.force().
>
> src/java.base/share/classes/jdk/internal/event/FileForceEvent.java line 35:
> 
>> 33:  * {@link #commit(long, long, String, boolean)} method
>> 34:  * must be the same as the order of the fields.
>> 35:  */
> 
> You may have to re-word this comment to avoid confusion with the metaData parameter. That is, there is event meta data and there is file metaData, if you see what I mean.

I see what you mean.  I reworded the javadoc.

> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:
> 
>> 48: 
>> 49:     public static void main(String[] args) throws Throwable {
>> 50:         File blah = File.createTempFile("blah", null);
> 
> Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the recording is available in the event that the test fails.

I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.

> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
> 
>> 62: 
>> 63:             data.flip();
>> 64:             ch.write(data, 0);
> 
> This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.

I do realize the write doesn't wait.  I was under the impression that flush() does wait until everything has been flushed to disk.  I went ahead and added .get() as requested.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566405842
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566413683
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566409791

From tprinzing at openjdk.org  Mon Apr 15 21:37:15 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 15 Apr 2024 21:37:15 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v7]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  cleanup of annotations

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/d10be83e..9ece2ff5

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

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

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

From tprinzing at openjdk.org  Tue Apr 16 00:05:33 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 16 Apr 2024 00:05:33 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v4]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <hNgZeptMgkWYNe3gJhtLygsAJ-KCcsCss-I7dLn3Le8=.6316cbb9-c745-49fb-bedd-93369665f22a@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  fix windows build issue

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/6903c823..70815943

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

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

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

From duke at openjdk.org  Tue Apr 16 06:13:31 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Tue, 16 Apr 2024 06:13:31 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v6]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <XhkeA_2VN_cQuVFGJ_QBY_9WJqDV4Zo5pnnc0BFjfuw=.a92ddb8e-2106-4e5d-92a7-41dd85e29963@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Rename property, add implNote and allow arbitrary positive values

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/280619d5..fc9be282

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

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

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

From duke at openjdk.org  Tue Apr 16 06:13:31 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Tue, 16 Apr 2024 06:13:31 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
 <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
Message-ID: <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>

On Mon, 15 Apr 2024 17:29:22 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> An `@implNote` about the property and its behavior could be added in `WatchService`.

I added the note to `WatchKey#poll` since that is what returns the list, but can also move it to `WatchService` as it is the more canonical API entrypoint.

> Once the property name, its behavior, and the `@implNote` are decided I can file the CSR.

Thanks!

> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 57:
> 
>> 55:             intValue = Math.clamp(
>> 56:                 Long.decode(rawValue),
>> 57:                 DEFAULT_MAX_EVENT_LIST_SIZE,
> 
> Probably we should allow positive values with no minimum. If it's zero or negative then I am not sure whether that would be an error.

Since 0 or -1 seem like pretty clear intent to "disable" watching as far as possible, I went with a clamp to 1 in that case. But I'm open to making that a hard error instead if you prefer that.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2058302426
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1566757762

From alanb at openjdk.org  Tue Apr 16 06:34:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 06:34:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
Message-ID: <R3CAyklgZnD8Oyoq8bOz5JB6RMfPm4YEFdDItA6sUa4=.36d763b8-5f78-45c7-8e55-a0158c90f7ca@github.com>

On Mon, 15 Apr 2024 20:39:26 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 64:
>> 
>>> 62: 
>>> 63:             data.flip();
>>> 64:             ch.write(data, 0);
>> 
>> This just initiates the write operation, it doesn't wait until it completes. It returns a Future so adding .get() will ensure that it waits and that there is potentially data to write back to the file system.
>
> I do realize the write doesn't wait.  I was under the impression that flush() does wait until everything has been flushed to disk.  I went ahead and added .get() as requested.

In this API, the read/write methods are asynchronous, the force method is synchronous.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1566784789

From alanb at openjdk.org  Tue Apr 16 08:12:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 08:12:45 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v2]
In-Reply-To: <xS9K67Z8jHZw0kpxWe33CzhQQBpJ3EX2W183pbCQqxA=.8877bbe1-0a62-42e8-83da-2f1214abefc0@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <ykUHh71hzDHZPZl4_Pp0ZUC94c0HZeXiqu0FDY9OkSI=.9d98a8b1-8b46-45a7-b799-715fa3d7d0fe@github.com>
 <cllaSnL5ysKqFUGUVec3sz3WR8tuQUgy0YhKYhCsq4A=.72d15d51-a7ab-4441-8ca8-14e9e773f42e@github.com>
 <xS9K67Z8jHZw0kpxWe33CzhQQBpJ3EX2W183pbCQqxA=.8877bbe1-0a62-42e8-83da-2f1214abefc0@github.com>
Message-ID: <XKOsWkXgkV5uyIMZKTmAB0ok8UAvXVYy8JokHoG5OlY=.ed2412fc-b7ed-47fc-8d14-14a57f4e4cf9@github.com>

On Mon, 26 Feb 2024 14:17:09 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 44:
>> 
>>> 42:     @Label("SelectionKey Count")
>>> 43:     @Description("Number of channels ready for I/O or added to ready set")
>>> 44:     public int selectionKeyCount;
>> 
>> same here
>
> Thanks for adding the timeout.

I think the description should be changed to say that it's the number of unique keys updated, nothing more. This covers the selection operations that add or update keys to the selected key set, and also the selection operations that update keys and invoke an action to consume.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1566922400

From egahlin at openjdk.org  Tue Apr 16 09:57:43 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 16 Apr 2024 09:57:43 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v7]
In-Reply-To: <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <b2td9S009wlsZCvjFRuodbTtrt6on3H5miCCwuK_qmo=.4491bab8-096e-4dc5-9864-66a8d45bb150@github.com>
Message-ID: <2e7U55ctKvbrJFOR7c4eVqBMQSQZUKDeyCI-3cl7cHg=.9acd2a67-a426-4db5-83ae-2642423b1f61@github.com>

On Mon, 15 Apr 2024 21:37:15 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
>> 
>> Emit the event from SelectorImpl::lockAndDoSelect
>> 
>> Test at jdk.jfr.event.io.TestSelectionEvents
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   cleanup of annotations

src/jdk.jfr/share/classes/jdk/jfr/events/SelectorSelectEvent.java line 43:

> 41: 
> 42:     @Label("Timeout Value")
> 43:     @Description("time to block, or zero to block indefinitely")

Sentence should start with a capital letter. I think "Timeout" is sufficient, no need to have "Value" in the label.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1567082204

From msheppar at openjdk.org  Tue Apr 16 12:10:26 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 16 Apr 2024 12:10:26 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
Message-ID: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>

Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 

This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.

The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel

The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

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

Commit messages:
 - JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel - changes to ensure that a ClosedChannelException is consistently thrown when after a DatagramChannel has been closed via an asynchronous closed, or via interruption of calling thread. Thus, a DatagramChannel::receive call may throw an AsynchronousCloseException when another thread has closed the DatagramChannel, and it may throw a ClosedByInterruptException if its calling thread has been interrupted. In such scenario, a subsequent receive call on the DatagramChannel instance should result in a ClosedChannelException being thrown. The proposed changes (provided by Alan Bateman) strive to ensure that a ClosedChannelException is consistently thrown. The changes elevate the ensureOpen() method call, checking that the channel is open, to very early in the processing call flow of the read/write send/receive methods, in a number of Channel classes.

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

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

From tprinzing at openjdk.org  Tue Apr 16 12:17:57 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 16 Apr 2024 12:17:57 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v8]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <_ul2bqHU83nbOfCRBRRMtOYwohfbdbuPelFYmCGXJDU=.50e0eea5-a0e1-4258-bb40-054d0b1d6012@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

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

  more annotation fixup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/16710/files
  - new: https://git.openjdk.org/jdk/pull/16710/files/9ece2ff5..e896c4ec

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

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

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

From jpai at openjdk.org  Tue Apr 16 12:55:41 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 12:55:41 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 395:

> 393:         acceptLock.lock();
> 394:         try {
> 395:             ensureOpen();

Hello Mark, I think this may not be needed, especially since it's being called without synchronizing on `stateLock`. A couple of lines below this line, there's a call to `begin(blocking)` and the implementation of `begin()` already calls the `ensureOpen()` after acquiring a `stateLock` first.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 958:

> 956:                 writeLock.lock();
> 957:                 try {
> 958:                     ensureOpen();

Similar comment as that for `ServerSocketChannelImpl`, the `beginConnect()` call a few lines below already does a `ensureOpen()` after acquiring the `stateLock` monitor.

src/java.base/share/classes/sun/nio/ch/SocketChannelImpl.java line 1057:

> 1055:                         return true;
> 1056: 
> 1057:                     ensureOpen();

Likewise, `beginFinishConnect()` already has the ensureOpen()

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567303316
PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567307989
PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567308912

From jpai at openjdk.org  Tue Apr 16 13:01:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 13:01:03 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
Message-ID: <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>

On Tue, 16 Apr 2024 12:49:45 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
>> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
>> 
>> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
>> 
>> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
>> 
>> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.
>
> src/java.base/share/classes/sun/nio/ch/ServerSocketChannelImpl.java line 395:
> 
>> 393:         acceptLock.lock();
>> 394:         try {
>> 395:             ensureOpen();
> 
> Hello Mark, I think this may not be needed, especially since it's being called without synchronizing on `stateLock`. A couple of lines below this line, there's a call to `begin(blocking)` and the implementation of `begin()` already calls the `ensureOpen()` after acquiring a `stateLock` first.

Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567315542

From alanb at openjdk.org  Tue Apr 16 13:25:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 13:25:59 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <BwGtZsikkcN0RuXeJ7THP9f-IDU69Xmz4Z1Ep5VcH70=.23e63043-8ffe-4692-89fc-a66d80c77494@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

Thanks for taking this one. The changes look fine but I can't be the Reviewer as I provided the changes.

As background, the refactoring in JDK 11 means that the AsynchronousCloseException (a sub-class of ClosedChannelException) is thrown when an operation is invoked on a closed network channel. No tests were failing because it's not a correctness issue, but confusing all the same. The test added here will ensure that we don't regress in this area again.

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

PR Comment: https://git.openjdk.org/jdk/pull/18796#issuecomment-2059079184

From alanb at openjdk.org  Tue Apr 16 13:25:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 13:25:59 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
 <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>
Message-ID: <FP69bcA8HjHfUPPtS8eGunKVJMxcjogns7CjAorNylg=.f7f3216e-6056-4e56-84f9-6740c37dbe05@github.com>

On Tue, 16 Apr 2024 12:57:50 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).

Right, there has been quite a bit of back and forth on this. The channel state needs to checked before "beginning" the I/O operation. If asynchronously closed while in the block then the more specific AsynchronousCloseException will be thrown.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567354457

From jpai at openjdk.org  Tue Apr 16 13:38:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 13:38:02 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <FP69bcA8HjHfUPPtS8eGunKVJMxcjogns7CjAorNylg=.f7f3216e-6056-4e56-84f9-6740c37dbe05@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
 <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>
 <FP69bcA8HjHfUPPtS8eGunKVJMxcjogns7CjAorNylg=.f7f3216e-6056-4e56-84f9-6740c37dbe05@github.com>
Message-ID: <94AbYOSk3gTtkEVUQPBHEnSooWY3pUAhQcfRhcHRLjw=.66c4b692-4ce3-4013-9fae-0c45bcfa6e44@github.com>

On Tue, 16 Apr 2024 13:22:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).
>
>> Please ignore these review comments for now. I might have mistaken what this change is proposing to do, partly because I missed some of the discussion in the JBS issue (the comments were auto-hidden and I now see the "load additional comments" option).
> 
> Right, there has been quite a bit of back and forth on this. The channel state needs to checked before "beginning" the I/O operation. If asynchronously closed while in the block then the more specific AsynchronousCloseException will be thrown.

Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.

I found it a bit odd that the existing calls to `ensureOpen()` are being invoked with a `stateLock` which as per its comment states that it is to be used for checking the `state` field, whereas the `ensureOpen()` itself just checks a separate `closed` field which is volatile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567375706

From alanb at openjdk.org  Tue Apr 16 13:48:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 16 Apr 2024 13:48:59 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <94AbYOSk3gTtkEVUQPBHEnSooWY3pUAhQcfRhcHRLjw=.66c4b692-4ce3-4013-9fae-0c45bcfa6e44@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
 <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>
 <FP69bcA8HjHfUPPtS8eGunKVJMxcjogns7CjAorNylg=.f7f3216e-6056-4e56-84f9-6740c37dbe05@github.com>
 <94AbYOSk3gTtkEVUQPBHEnSooWY3pUAhQcfRhcHRLjw=.66c4b692-4ce3-4013-9fae-0c45bcfa6e44@github.com>
Message-ID: <U88xWtulTrLo04Grcx6j14cneBdpznONWWU-14IhQOs=.cf329717-9bbd-4c9f-809b-f0d0227a3dbb@github.com>

On Tue, 16 Apr 2024 13:35:22 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.

No, that would lead to contention when doing non-blocking I/O. The cases where you see ensureOpen called while holding the stateLock are blocking I/O ops or non-I/O ops that require more complex coordination with close.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567395321

From jpai at openjdk.org  Tue Apr 16 13:54:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 13:54:02 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <U88xWtulTrLo04Grcx6j14cneBdpznONWWU-14IhQOs=.cf329717-9bbd-4c9f-809b-f0d0227a3dbb@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <64GSF5kgHdy9mwv7VaveJjCQ-FQFjozsIbJz4xlx09I=.654613e0-713b-46c8-aa3a-654beefffed7@github.com>
 <CTGrBJksySCLBKZ9d0txGqcM6ID6VEvu9TZ7QijbRd8=.6e3e0d07-ccc4-499c-b848-6d8957417b14@github.com>
 <FP69bcA8HjHfUPPtS8eGunKVJMxcjogns7CjAorNylg=.f7f3216e-6056-4e56-84f9-6740c37dbe05@github.com>
 <94AbYOSk3gTtkEVUQPBHEnSooWY3pUAhQcfRhcHRLjw=.66c4b692-4ce3-4013-9fae-0c45bcfa6e44@github.com>
 <U88xWtulTrLo04Grcx6j14cneBdpznONWWU-14IhQOs=.cf329717-9bbd-4c9f-809b-f0d0227a3dbb@github.com>
Message-ID: <gudFWzgLk22t516ueQav_g_5hv3CjbS3vj5aFCOfvyM=.02e83485-d7a0-4dc2-ac27-124cb8d9a36e@github.com>

On Tue, 16 Apr 2024 13:46:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.
>> 
>> I found it a bit odd that the existing calls to `ensureOpen()` are being invoked with a `stateLock` which as per its comment states that it is to be used for checking the `state` field, whereas the `ensureOpen()` itself just checks a separate `closed` field which is volatile.
>
>> Do you think this additional `ensureOpen()` that we introduce here would need to be called while holding the `stateLock` monitor? I don't think it would be needed given the implementation of ensureOpen() checks a volatile field but then I see that existing calls to ensureOpen() are done while holding the monitor on `stateLock`.
> 
> No, that would lead to contention when doing non-blocking I/O. The cases where you see ensureOpen called while holding the stateLock are blocking I/O ops or non-I/O ops that require more complex coordination with close.

OK, thank you Alan for that detail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567403444

From jpai at openjdk.org  Tue Apr 16 14:08:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 14:08:03 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <WPBC8-A1QDaD5ibh58p2OSbso3Q1Hy69eCb_bikdRWs=.b07d0ec0-122a-4bef-bcbc-52287dcd2b55@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

test/jdk/java/nio/channels/Channels/ClosedNetworkChannels.java line 64:

> 62:             fail();
> 63:         } catch (AsynchronousCloseException e) {
> 64:             fail(e + " thrown");

I think for debugging any unexpected failures, it might be better to include the original exception too in the failure. Like:

fail(e + " thrown", e);

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567426208

From jpai at openjdk.org  Tue Apr 16 14:17:02 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 14:17:02 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <UDj_pX-yN1X_dGyQKpcLEoJHavMxNaLJkTTY4heCFI0=.38822765-1167-45f8-9634-f8687f5fa676@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

I've added a trivial review comment in the test, but other than that these changes look OK to me.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18796#pullrequestreview-2003782071

From michaelm at openjdk.org  Tue Apr 16 15:09:42 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Tue, 16 Apr 2024 15:09:42 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <gi0HeLS0PymV4Hk-Ig295lOuVvrsdH4o_aNItct0coA=.dc04914d-f6d8-48d8-abfe-d83e05d7e7b3@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

LGTM too.

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

Marked as reviewed by michaelm (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18796#pullrequestreview-2003926774

From msheppar at openjdk.org  Tue Apr 16 15:35:00 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 16 Apr 2024 15:35:00 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <WPBC8-A1QDaD5ibh58p2OSbso3Q1Hy69eCb_bikdRWs=.b07d0ec0-122a-4bef-bcbc-52287dcd2b55@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <WPBC8-A1QDaD5ibh58p2OSbso3Q1Hy69eCb_bikdRWs=.b07d0ec0-122a-4bef-bcbc-52287dcd2b55@github.com>
Message-ID: <o_toUbGQJP3UZt3PQDjIKYNoAUiz9yj4sef06AofnU0=.b78b9941-7a32-438d-b553-fa69f4f92f89@github.com>

On Tue, 16 Apr 2024 14:04:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
>> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
>> 
>> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
>> 
>> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
>> 
>> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.
>
> test/jdk/java/nio/channels/Channels/ClosedNetworkChannels.java line 64:
> 
>> 62:             fail();
>> 63:         } catch (AsynchronousCloseException e) {
>> 64:             fail(e + " thrown");
> 
> I think for debugging any unexpected failures, it might be better to include the original exception too in the failure. Like:
> 
> fail(e + " thrown", e);

yes, that is a reasonable suggestion. I will, if you don't mind, leave things as is, for the simple reason, I would need to submit such a change on repeat mode through MACH5, as it's for unexpected exceptions, and this can take 5/6 days for the job to get through MACH5, depending on resource availability, and I have gone through that cycle three times already for this fix

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567570119

From jpai at openjdk.org  Tue Apr 16 15:37:45 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 16 Apr 2024 15:37:45 GMT
Subject: RFR: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <o_toUbGQJP3UZt3PQDjIKYNoAUiz9yj4sef06AofnU0=.b78b9941-7a32-438d-b553-fa69f4f92f89@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
 <WPBC8-A1QDaD5ibh58p2OSbso3Q1Hy69eCb_bikdRWs=.b07d0ec0-122a-4bef-bcbc-52287dcd2b55@github.com>
 <o_toUbGQJP3UZt3PQDjIKYNoAUiz9yj4sef06AofnU0=.b78b9941-7a32-438d-b553-fa69f4f92f89@github.com>
Message-ID: <yLszmhvcJfuEUuuB9C6suZ3MWmD4e5JkVy2bP8WjISg=.04ca6cf7-0541-4fb0-b715-b89750c5eb49@github.com>

On Tue, 16 Apr 2024 15:32:24 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

>> test/jdk/java/nio/channels/Channels/ClosedNetworkChannels.java line 64:
>> 
>>> 62:             fail();
>>> 63:         } catch (AsynchronousCloseException e) {
>>> 64:             fail(e + " thrown");
>> 
>> I think for debugging any unexpected failures, it might be better to include the original exception too in the failure. Like:
>> 
>> fail(e + " thrown", e);
>
> yes, that is a reasonable suggestion. I will, if you don't mind, leave things as is, for the simple reason, I would need to submit such a change on repeat mode through MACH5, as it's for unexpected exceptions, and this can take 5/6 days for the job to get through MACH5, depending on resource availability, and I have gone through that cycle three times already for this fix

Leaving it in the current form is OK with me. We can revisit that line if/when we modify this test later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18796#discussion_r1567576750

From msheppar at openjdk.org  Tue Apr 16 15:47:03 2024
From: msheppar at openjdk.org (Mark Sheppard)
Date: Tue, 16 Apr 2024 15:47:03 GMT
Subject: Integrated: 8329190: (ch) DatagramChannel.receive should throw
 ClosedChannelException when called on closed channel
In-Reply-To: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
References: <18a2yp6i8VZsW7g1-XMB4YkijnVWTV978uBtLS_X19Q=.1b8af87a-294a-4e69-ae52-61edddb1b071@github.com>
Message-ID: <kfDu3clFn1mjrX2CbT04BMVliyepqduOJHGyyvnyky4=.cdfbfd12-b086-4f5c-82bc-7406f42352c0@github.com>

On Tue, 16 Apr 2024 12:03:07 GMT, Mark Sheppard <msheppar at openjdk.org> wrote:

> Please oblige and review the following changes (provided by Alan Bateman) which addresses the issue outlined in
> JDK-8329190: DatagramChannel.receive should throw ClosedChannelException when called on closed channel 
> 
> This ensures that a ClosedChannelException is consistently thrown from DatagramChannel send and receive methods, especially in the context of asynchronous closure and calling thread interruption.
> 
> The change is to move the ensureOpen() method call, which checks that a channel has not been closed, to the start of read/write send/receive methods on the DatagramChannel
> 
> The regression suites for jdk_nio and jdk_net and the JCK tests for api/java_nio api/java_net have been executed in repeat mode, multiple times, without any observed relevant failures.

This pull request has now been integrated.

Changeset: 90df3b7f
Author:    Mark Sheppard <msheppar at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/90df3b7fbb87f816f0bb688aa122cb3480399aee
Stats:     226 lines in 6 files changed: 223 ins; 0 del; 3 mod

8329190: (ch) DatagramChannel.receive should throw ClosedChannelException when called on closed channel

Co-authored-by: Alan Bateman <alanb at openjdk.org>
Reviewed-by: jpai, michaelm

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

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

From dfuchs at openjdk.org  Tue Apr 16 15:52:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 16 Apr 2024 15:52:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
Message-ID: <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>

On Mon, 15 Apr 2024 20:41:10 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/io/TestAsynchronousFileChannelEvents.java line 50:
>> 
>>> 48: 
>>> 49:     public static void main(String[] args) throws Throwable {
>>> 50:         File blah = File.createTempFile("blah", null);
>> 
>> Can you change this to use the tests's scratch rather that /tmp, meaning `Files.createTempFile(Path.of("."), "blah", "jfr")`. That way the file is available in the event that the test fails.
>
> I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.

It's anyway better to create temporary files in the test scratch directory rather than in /tmp. This way the temp files get cleaned up with the test, and there less chances of conflicts if several tests are running concurrently (and less chances on slowly filling up /tmp onthe machine if clean up actions fail)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1567596755

From duke at openjdk.org  Tue Apr 16 15:59:27 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Tue, 16 Apr 2024 15:59:27 GMT
Subject: RFR: 8326951: Missing `@since` tags [v6]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <I2ZFj5-LA3hPsv2Z7cfc4FbNWeH5MV3Wjp73HdoPrsU=.3ca00bb7-e692-4127-aff7-294229ba9f58@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  removed change

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/97f4c946..390a21f9

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

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

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

From tprinzing at openjdk.org  Wed Apr 17 01:34:07 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 17 Apr 2024 01:34:07 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  test file local to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/70815943..366fca19

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

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

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

From tprinzing at openjdk.org  Wed Apr 17 01:37:04 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 17 Apr 2024 01:37:04 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v2]
In-Reply-To: <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <AWpCtDoz8poqURLXjxHBIvKESd19UCuy3RgxPfG6wD0=.6403f6a1-ea40-4136-bd7d-725923c188a7@github.com>
 <BxAn5rgS50CDoeB6qyMoQUhqM_a8jz4IV5Rdhh7iukQ=.22bb0cad-230a-4521-914d-5426559650f2@github.com>
 <KKEc-1Ry1b9--CjbWijhMCoYNk1TcK2WgTlIxI62HXU=.617273a4-a780-48d3-bcd5-587466a16af9@github.com>
 <Hir2Q2tiv3y9Kqp1KN3RcqjApN7NgFkxfXZFbX0BWkU=.546adb1f-094c-4ad6-bffb-4294c0dde3e5@github.com>
Message-ID: <jiZV9LPAaKdne7ejuuUUwMEg1x6jyR88pWVSAg6Og1I=.1f6ff88a-6f76-4e50-b262-115f5f96a57c@github.com>

On Tue, 16 Apr 2024 15:49:08 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I'm not sure what you mean about the recording.  The file is the AsynchronousFileChannel under test and does not contain the event recording.
>
> It's anyway better to create temporary files in the test scratch directory rather than in /tmp. This way the temp files get cleaned up with the test, and there less chances of conflicts if several tests are running concurrently (and less chances on slowly filling up /tmp onthe machine if clean up actions fail)

I moved it to the tests scratch area

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1568102079

From bpb at openjdk.org  Wed Apr 17 01:47:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Apr 2024 01:47:00 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
 <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
 <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
Message-ID: <IU1jNkCTPzJP67VVfFWUncvQ0qODU3AUuPKMrXGnSRU=.21a5765f-2924-4a21-913a-c5d370ddcc97@github.com>

On Tue, 16 Apr 2024 06:10:28 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

> I added the note to `WatchKey#poll` since that is what returns the list, but can also move it to `WatchService` as it is the more canonical API entrypoint.

I think that it might be better to add it to the class level doc of `WatchService`.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2060188775

From duke at openjdk.org  Wed Apr 17 06:49:16 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Wed, 17 Apr 2024 06:49:16 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v7]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Move `@implNote`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/fc9be282..39559793

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

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

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

From duke at openjdk.org  Wed Apr 17 06:49:16 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Wed, 17 Apr 2024 06:49:16 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <IU1jNkCTPzJP67VVfFWUncvQ0qODU3AUuPKMrXGnSRU=.21a5765f-2924-4a21-913a-c5d370ddcc97@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
 <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
 <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
 <IU1jNkCTPzJP67VVfFWUncvQ0qODU3AUuPKMrXGnSRU=.21a5765f-2924-4a21-913a-c5d370ddcc97@github.com>
Message-ID: <F5B-3fEet9Lv9NncK5AO8MPEFoNMR7jW4KmVRHmpg7Y=.e3d5d5c2-104a-4b55-b7df-33d9ea7f5dc6@github.com>

On Wed, 17 Apr 2024 01:44:16 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think that it might be better to add it to the class level doc of `WatchService`.

I moved it.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2060498335

From bpb at openjdk.org  Wed Apr 17 20:33:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 17 Apr 2024 20:33:01 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v7]
In-Reply-To: <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>
Message-ID: <PamHjpp4oKH7VF8BvkshG5Nl-PrLg0oNu8prvYp0ID4=.5a9d703f-f3a5-4fb6-a628-41143517cb54@github.com>

On Wed, 17 Apr 2024 06:49:16 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move `@implNote`

src/java.base/share/classes/java/nio/file/WatchService.java line 111:

> 109:  * StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
> 110:  *
> 111:  * @since 1.7

@fmeum What do you think of this slightly modified version of the implementation note?


 * @implNote
 * In the reference implementation, the maximum size of the list of events
 * returned by {@link WatchKey#pollEvents() WatchKey.pollEvents} is controlled
 * by the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}.
 * If this property is not set or cannot be parsed as an integer, then the
 * maximum event list size will be set to 512; if the property is parsed as a
 * non-positive integer, then the maximum event size will be {@code 1} (unity).
 * If more events occur than the maximum size of the event list, the pending
 * events are cleared and replaced with a single
 * {@link StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
 *

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1569499903

From duke at openjdk.org  Thu Apr 18 07:20:27 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 07:20:27 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Rephrase implNote

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/39559793..2278153d

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

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

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

From duke at openjdk.org  Thu Apr 18 07:20:27 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 07:20:27 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v7]
In-Reply-To: <PamHjpp4oKH7VF8BvkshG5Nl-PrLg0oNu8prvYp0ID4=.5a9d703f-f3a5-4fb6-a628-41143517cb54@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>
 <PamHjpp4oKH7VF8BvkshG5Nl-PrLg0oNu8prvYp0ID4=.5a9d703f-f3a5-4fb6-a628-41143517cb54@github.com>
Message-ID: <2XMzz-YhSmXlr__CLoGaL7oM0g99yHg-xU8iV_VWic8=.38cfa8eb-16fc-4fd5-b44d-ecd98eeee361@github.com>

On Wed, 17 Apr 2024 20:30:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move `@implNote`
>
> src/java.base/share/classes/java/nio/file/WatchService.java line 111:
> 
>> 109:  * StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
>> 110:  *
>> 111:  * @since 1.7
> 
> @fmeum What do you think of this slightly modified version of the implementation note?
> 
> 
>  * @implNote
>  * In the reference implementation, the maximum size of the list of events
>  * returned by {@link WatchKey#pollEvents() WatchKey.pollEvents} is controlled
>  * by the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}.
>  * If this property is not set or cannot be parsed as an integer, then the
>  * maximum event list size will be set to 512; if the property is parsed as a
>  * non-positive integer, then the maximum event size will be {@code 1} (unity).
>  * If more events occur than the maximum size of the event list, the pending
>  * events are cleared and replaced with a single
>  * {@link StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
>  *

I like it, pushed the change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1570138432

From alanb at openjdk.org  Thu Apr 18 13:42:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 18 Apr 2024 13:42:05 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
Message-ID: <R_Vs8LUQUHD3EOqf8ZKHXCcwW1Sbgoeh2AoVgJudy0s=.ca8c7bed-e5da-4594-9424-e9e3d414b458@github.com>

On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test file local to test

My comments have been addressed and I don't have any else to add. I assume @egahlin will cast an eye over this too.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2008938324

From dfuchs at openjdk.org  Thu Apr 18 14:36:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 18 Apr 2024 14:36:05 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
Message-ID: <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>

On Wed, 17 Apr 2024 01:34:07 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   test file local to test

Sorry - just noticed this comment has been pending for a few days...

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:

> 64:         FileWriteEvent.class,
> 65:         SocketReadEvent.class,
> 66:         SocketWriteEvent.class,

I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
Just wanted to double check it was intended as it doesn't seem to be related to file events.

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

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2006152864
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1568907662

From egahlin at openjdk.org  Thu Apr 18 14:36:06 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 14:36:06 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
Message-ID: <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>

On Wed, 17 Apr 2024 14:05:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   test file local to test
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
> 
>> 64:         FileWriteEvent.class,
>> 65:         SocketReadEvent.class,
>> 66:         SocketWriteEvent.class,
> 
> I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
> Just wanted to double check it was intended as it doesn't seem to be related to file events.

Yes, and I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I will send out a PR to remove those separately (in 30 minutes) so a fix can be backported.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570887596

From tprinzing at openjdk.org  Thu Apr 18 15:16:59 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 15:16:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
 <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
Message-ID: <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>

On Thu, 18 Apr 2024 14:32:28 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 66:
>> 
>>> 64:         FileWriteEvent.class,
>>> 65:         SocketReadEvent.class,
>>> 66:         SocketWriteEvent.class,
>> 
>> I'm guessing that this change which remove these two event classes is a drive-by-cleanup that should actually have been done with some previous fix in this area?
>> Just wanted to double check it was intended as it doesn't seem to be related to file events.
>
> I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove those separately so the fix can be backported. https://github.com/openjdk/jdk/pull/18843

That's correct, it is an unrelated cleanup (other than it seems to cause tests to fail now).  @egahlin, do you want me to remove those from this PR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570953838

From egahlin at openjdk.org  Thu Apr 18 15:32:59 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 15:32:59 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v5]
In-Reply-To: <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <NOf97K5e4piZG_5fYDnFAOcKqwcLdD1kILRRwt5rWyw=.017604db-6c48-47eb-81ba-ea9123e12222@github.com>
 <xsC3NR7AL-7ESVOFn-kqrTRBDhSPkA1aM9W_oovVj6Y=.2c62a488-53a0-41b2-8fc9-432063d88309@github.com>
 <mWvpzGy55Wcpt2mKkw1pjcskXHlnwt1cD-uokTaOvVQ=.779e0a1c-14c8-447f-91dd-997f052ade5f@github.com>
 <Diw63vvC4QjixiAiro7K67dfv8j0A5GspEvK4CHDafY=.1941cf21-5988-466b-b94c-939041af49e5@github.com>
Message-ID: <LXvPcPy2C1C4H5_WM9rKdSQrOYdoYcpv7sbdgOWPDZ8=.fc06f0aa-5ffc-4afe-a633-7df36e703ed9@github.com>

On Thu, 18 Apr 2024 15:14:10 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> I think it might be the cause for https://bugs.openjdk.org/browse/JDK-8329330 I have sent out a PR to remove those separately so the fix can be backported. https://github.com/openjdk/jdk/pull/18843
>
> That's correct, it is an unrelated cleanup (other than it seems to cause tests to fail now).  @egahlin, do you want me to remove those from this PR?

Yes, it would be good if you could remove those changes, so it can be handled separately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1570979943

From bpb at openjdk.org  Thu Apr 18 15:33:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Apr 2024 15:33:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v7]
In-Reply-To: <2XMzz-YhSmXlr__CLoGaL7oM0g99yHg-xU8iV_VWic8=.38cfa8eb-16fc-4fd5-b44d-ecd98eeee361@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>
 <PamHjpp4oKH7VF8BvkshG5Nl-PrLg0oNu8prvYp0ID4=.5a9d703f-f3a5-4fb6-a628-41143517cb54@github.com>
 <2XMzz-YhSmXlr__CLoGaL7oM0g99yHg-xU8iV_VWic8=.38cfa8eb-16fc-4fd5-b44d-ecd98eeee361@github.com>
Message-ID: <iBrGlcsOkElJwGi3YhT_FXDm8Z7gBnIiZlWzVWWduUA=.fbd52cd8-9920-4588-bc82-a7b9cf4198ca@github.com>

On Thu, 18 Apr 2024 07:16:51 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/WatchService.java line 111:
>> 
>>> 109:  * StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
>>> 110:  *
>>> 111:  * @since 1.7
>> 
>> @fmeum What do you think of this slightly modified version of the implementation note?
>> 
>> 
>>  * @implNote
>>  * In the reference implementation, the maximum size of the list of events
>>  * returned by {@link WatchKey#pollEvents() WatchKey.pollEvents} is controlled
>>  * by the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}.
>>  * If this property is not set or cannot be parsed as an integer, then the
>>  * maximum event list size will be set to 512; if the property is parsed as a
>>  * non-positive integer, then the maximum event size will be {@code 1} (unity).
>>  * If more events occur than the maximum size of the event list, the pending
>>  * events are cleared and replaced with a single
>>  * {@link StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
>>  *
>
> I like it, pushed the change.

Thanks. @alan and @fmeum , does this look sufficiently good now to create a CSR?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1570980697

From bpb at openjdk.org  Thu Apr 18 15:33:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Apr 2024 15:33:59 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
 <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
 <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
Message-ID: <R1xCaa7atpPT4AWT5yIYViS_eYSetqgqKZKK6JGKpeU=.a3cec2df-e77a-4f5d-a597-a6d40fd14526@github.com>

On Tue, 16 Apr 2024 06:09:24 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 57:
>> 
>>> 55:             intValue = Math.clamp(
>>> 56:                 Long.decode(rawValue),
>>> 57:                 DEFAULT_MAX_EVENT_LIST_SIZE,
>> 
>> Probably we should allow positive values with no minimum. If it's zero or negative then I am not sure whether that would be an error.
>
> Since 0 or -1 seem like pretty clear intent to "disable" watching as far as possible, I went with a clamp to 1 in that case. But I'm open to making that a hard error instead if you prefer that.

I think clamping to 1 is fine. An error hear might be awkward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1570979183

From bpb at openjdk.org  Thu Apr 18 15:40:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Apr 2024 15:40:56 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v5]
In-Reply-To: <F5B-3fEet9Lv9NncK5AO8MPEFoNMR7jW4KmVRHmpg7Y=.e3d5d5c2-104a-4b55-b7df-33d9ea7f5dc6@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Z83GHpoIeNAIbfIBDrx_3MJ28QGSV73lub5aVulFUd4=.02976bad-aa08-4381-befc-afecaf3c2bb9@github.com>
 <5vyxOPnd77WtWn7aG_RaTy3uDALUeVhdmJzFqxSZ9M0=.e6245836-6245-430b-b8dd-746aa8e42e54@github.com>
 <wzNJP2EsRNtJ5efj1ag5s1yllrJu2G_DONy1mAxY7oQ=.ca1b4c20-19a1-4599-9a2a-52dbbce44e6c@github.com>
 <IU1jNkCTPzJP67VVfFWUncvQ0qODU3AUuPKMrXGnSRU=.21a5765f-2924-4a21-913a-c5d370ddcc97@github.com>
 <F5B-3fEet9Lv9NncK5AO8MPEFoNMR7jW4KmVRHmpg7Y=.e3d5d5c2-104a-4b55-b7df-33d9ea7f5dc6@github.com>
Message-ID: <VjZCPsbs8xK9I1HJ2g1EZbKmVvnsIeK4MTBA0BA-lS4=.5d46fb39-c5e2-4498-8247-cb313f1d6151@github.com>

On Wed, 17 Apr 2024 06:46:25 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>>> I added the note to `WatchKey#poll` since that is what returns the list, but can also move it to `WatchService` as it is the more canonical API entrypoint.
>> 
>> I think that it might be better to add it to the class level doc of `WatchService`.
>
>> I think that it might be better to add it to the class level doc of `WatchService`.
> 
> I moved it.

@fmeum The second copyright year in the two source files needs to be update dto 2024. If you wrote the test this year, it should have only one copyright year, 2024. Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2064274709

From bpb at openjdk.org  Thu Apr 18 17:26:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Apr 2024 17:26:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
Message-ID: <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>

On Thu, 18 Apr 2024 07:20:27 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rephrase implNote

test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 32:

> 30:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=invalid LotsOfEntries 600 fail
> 31:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=-5 LotsOfEntries 5 fail
> 32:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass

I ran 100 repeats of this test on each of four different platforms. 398 executions passed, but two failed, both in the sub-test at line 32. I do not know what happened in these two cases for the sub-tests at lines 33-35 as these were not run. The output was like:


jtreg_open_test_jdk_java_nio_file_WatchService_LotsOfEntries_java/tmp/name7869734652501521174/entry1]
	at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
	at LotsOfEntries.main(LotsOfEntries.java:96)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected events on: [multiple flle names omitted]

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571124810

From duke at openjdk.org  Thu Apr 18 17:35:00 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 17:35:00 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v7]
In-Reply-To: <iBrGlcsOkElJwGi3YhT_FXDm8Z7gBnIiZlWzVWWduUA=.fbd52cd8-9920-4588-bc82-a7b9cf4198ca@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <aGxeLsyXFtckpfdCFqmXKSiag4nn_wAj01-QgzeHE0M=.1bfa7f27-3eef-4fec-9bc5-9c46048d0ede@github.com>
 <PamHjpp4oKH7VF8BvkshG5Nl-PrLg0oNu8prvYp0ID4=.5a9d703f-f3a5-4fb6-a628-41143517cb54@github.com>
 <2XMzz-YhSmXlr__CLoGaL7oM0g99yHg-xU8iV_VWic8=.38cfa8eb-16fc-4fd5-b44d-ecd98eeee361@github.com>
 <iBrGlcsOkElJwGi3YhT_FXDm8Z7gBnIiZlWzVWWduUA=.fbd52cd8-9920-4588-bc82-a7b9cf4198ca@github.com>
Message-ID: <ZxCjhL3K8a7i1UOESdEoJUYh6Bw5QuoVSfO-juTbP74=.948561ce-4376-492f-9284-84d28be384cc@github.com>

On Thu, 18 Apr 2024 15:31:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I like it, pushed the change.
>
> Thanks. @alan and @fmeum , does this look sufficiently good now to create a CSR?

It does to me.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571135465

From duke at openjdk.org  Thu Apr 18 17:39:15 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 17:39:15 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v9]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <_1VUC-0V6lzxruba69i_Q5zXPisVTtdPDtQ6Ue62e0g=.38adddd9-7002-4b1c-b4e7-dd05fcc5ca30@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Update copyright and attempt to deflake tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/2278153d..ddec662e

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

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

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

From duke at openjdk.org  Thu Apr 18 17:39:15 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 17:39:15 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
Message-ID: <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>

On Thu, 18 Apr 2024 17:24:04 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rephrase implNote
>
> test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 32:
> 
>> 30:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=invalid LotsOfEntries 600 fail
>> 31:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=-5 LotsOfEntries 5 fail
>> 32:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass
> 
> I ran 100 repeats of this test on each of four different platforms. 398 executions passed, but two failed, both in the sub-test at line 32. I do not know what happened in these two cases for the sub-tests at lines 33-35 as these were not run. The output was like:
> 
> 
> jtreg_open_test_jdk_java_nio_file_WatchService_LotsOfEntries_java/tmp/name7869734652501521174/entry1]
> 	at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
> 	at LotsOfEntries.main(LotsOfEntries.java:96)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> 	at java.base/java.lang.Thread.run(Thread.java:1575)
> 
> JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected events on: [multiple flle names omitted]

I slightly lowered/raised the numbers of files to be created. We can tune this more if needed, I don't think fully precise control over the number of events is required.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571139359

From bpb at openjdk.org  Thu Apr 18 18:24:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 18 Apr 2024 18:24:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
Message-ID: <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>

On Thu, 18 Apr 2024 17:36:02 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> test/jdk/java/nio/file/WatchService/LotsOfEntries.java line 32:
>> 
>>> 30:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=invalid LotsOfEntries 600 fail
>>> 31:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=-5 LotsOfEntries 5 fail
>>> 32:  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass
>> 
>> I ran 100 repeats of this test on each of four different platforms. 398 executions passed, but two failed, both in the sub-test at line 32. I do not know what happened in these two cases for the sub-tests at lines 33-35 as these were not run. The output was like:
>> 
>> 
>> jtreg_open_test_jdk_java_nio_file_WatchService_LotsOfEntries_java/tmp/name7869734652501521174/entry1]
>> 	at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
>> 	at LotsOfEntries.main(LotsOfEntries.java:96)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>> 	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>> 	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> 	at java.base/java.lang.Thread.run(Thread.java:1575)
>> 
>> JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected events on: [multiple flle names omitted]
>
> I slightly lowered/raised the numbers of files to be created. We can tune this more if needed, I don't think fully precise control over the number of events is required.

We just don't want to have random failures creating noise. Tests are run many times each day. I think the problematic line here is

 32  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass

This failed I think in only 3 of 300 repeats on linux-aarch64.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571188501

From duke at openjdk.org  Thu Apr 18 18:45:59 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Thu, 18 Apr 2024 18:45:59 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
Message-ID: <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>

On Thu, 18 Apr 2024 18:22:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I slightly lowered/raised the numbers of files to be created. We can tune this more if needed, I don't think fully precise control over the number of events is required.
>
> We just don't want to have random failures creating noise. Tests are run many times each day. I think the problematic line here is
> 
>  32  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass
> 
> This failed I think in only 3 of 300 repeats on linux-aarch64.

Yes what I meant is that the numbers in the test are essentially arbitrary. Now that they are further away from the limit, I would expect failures to be less likely. But if there are still failures, I can make the difference even larger.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571209754

From tprinzing at openjdk.org  Thu Apr 18 18:46:36 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:46:36 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v6]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  undo fix being handled in JDK-8329330.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/366fca19..28bf429d

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

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

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

From tprinzing at openjdk.org  Thu Apr 18 18:53:01 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:53:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v6]
In-Reply-To: <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <7NawxjXo9zY9pqD8kgVIziuap_YEzFyxZCl2CTHfvIA=.0097b568-8a89-4690-9ce7-0790905a4f35@github.com>
Message-ID: <hRGMlUMEH970DP4gjFdt54b3zCrjXawLM1N2iDGY38w=.d62b3b6f-2adb-4476-be89-af49a932c333@github.com>

On Thu, 18 Apr 2024 18:46:36 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   undo fix being handled in JDK-8329330.

Prior to the last commit, this passed all tests tier 1-3 on all platform.  It should be ready.

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

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2064929545

From tprinzing at openjdk.org  Thu Apr 18 18:59:20 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 18:59:20 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v7]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  IntelliJ trying to help

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/28bf429d..17b0be7b

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

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

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

From egahlin at openjdk.org  Thu Apr 18 20:34:01 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 18 Apr 2024 20:34:01 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v7]
In-Reply-To: <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <lUvx-v8l-jFO15FSfIOkX7HYqgYmf7fc7tIrj5E4Trk=.b048c6f3-b787-4004-95aa-995e2c9a2056@github.com>
Message-ID: <4uMJ5_MknLkJoEaY8wE52Mf4K7zW1_ftcknW_zWUPzo=.edf4b3d9-8d82-4573-a33f-0d4dfdec9fca@github.com>

On Thu, 18 Apr 2024 18:59:20 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   IntelliJ trying to help

Marked as reviewed by egahlin (Reviewer).

src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java line 46:

> 44: import jdk.jfr.events.FileWriteEvent;
> 45: import jdk.jfr.events.InitialSecurityPropertyEvent;
> 46: 

Unnecessary blank line added.

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

PR Review: https://git.openjdk.org/jdk/pull/18542#pullrequestreview-2009830262
PR Review Comment: https://git.openjdk.org/jdk/pull/18542#discussion_r1571335968

From tprinzing at openjdk.org  Thu Apr 18 20:40:23 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Thu, 18 Apr 2024 20:40:23 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v8]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <WT2hAeQyi2UTyGaTiqlWtpNLyzZExqt-8ZUPskVLgUI=.9f6c3614-ce7d-45e9-9c65-f6bedd57c9ae@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  remove unecessary blank line

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/17b0be7b..f7859fc4

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

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

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

From jjg at openjdk.org  Thu Apr 18 20:48:04 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 18 Apr 2024 20:48:04 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in `java.base`
Message-ID: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>

Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.

There are various categories of update:

* "Box comments" beginning with `/**`
* Misplaced doc comments before package or import statements
* Misplaced doc comments after the annotations for a declaration
* Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
* Use of `/**` for the legal header at or near the top of the file

In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

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

Commit messages:
 - JDK-8330178: Clean up non-standard use of /** comments in `java.base`

Changes: https://git.openjdk.org/jdk/pull/18846/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18846&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8330178
  Stats: 134 lines in 23 files changed: 50 ins; 56 del; 28 mod
  Patch: https://git.openjdk.org/jdk/pull/18846.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18846/head:pull/18846

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

From mpowers at openjdk.org  Thu Apr 18 21:19:56 2024
From: mpowers at openjdk.org (Mark Powers)
Date: Thu, 18 Apr 2024 21:19:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <dmHUQtRTvpmJO4yhZvDJFjFCxtZMXJcJb45ZQ-Lxdlw=.00c6c3b8-960f-4ddb-bb32-0848fc1bad83@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Should the copyright be updated?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2065339389

From darcy at openjdk.org  Thu Apr 18 22:50:56 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 18 Apr 2024 22:50:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <CCg0siue0vsMT0R1LJ9Qgr5BN7eORlS-sqNih3qh2Tg=.8df332ee-d15a-4678-8bbd-9baf26c0e257@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010059355

From iris at openjdk.org  Thu Apr 18 22:59:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 18 Apr 2024 22:59:55 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <0ffUuhd3mqnGetQ_dn60M7NrftiL02UD7zbITanAuJc=.b4ac0b9d-01c0-47be-a315-903e9ed6424f@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2010068091

From bpb at openjdk.org  Fri Apr 19 00:52:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 00:52:56 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
Message-ID: <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>

On Thu, 18 Apr 2024 18:43:02 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> We just don't want to have random failures creating noise. Tests are run many times each day. I think the problematic line here is
>> 
>>  32  * @run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=5 LotsOfEntries 5 pass
>> 
>> This failed I think in only 3 of 300 repeats on linux-aarch64.
>
> Yes what I meant is that the numbers in the test are essentially arbitrary. Now that they are further away from the limit, I would expect failures to be less likely. But if there are still failures, I can make the difference even larger.

It would be good to know why the failures happened so they can be prevented.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571566402

From duke at openjdk.org  Fri Apr 19 07:07:58 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 07:07:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
Message-ID: <jCf2d_lwLYGw3Z_jLbJkcICyGNbvP5OPsm3PbAiEuPU=.a202f60e-c54e-4ed6-b71c-3bb4a161111c@github.com>

On Fri, 19 Apr 2024 00:50:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes what I meant is that the numbers in the test are essentially arbitrary. Now that they are further away from the limit, I would expect failures to be less likely. But if there are still failures, I can make the difference even larger.
>
> It would be good to know why the failures happened so they can be prevented.

Could you share the omitted list of files? The error message should give us the diff, which would be helpful in figuring out what went wrong.

I don't have access to a linux-aarch64 machine, but I will also try to stress test this test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571925658

From duke at openjdk.org  Fri Apr 19 07:23:12 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 07:23:12 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v10]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <f_7-q1NPS5zAEnhYhiZp8EOaoS972HM_Ay7JNtEOtnA=.e7751e92-6ea2-48e0-b46f-9757fbcf2f3b@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Revert test parameters and add debug output to test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/ddec662e..61e46d66

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

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

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

From duke at openjdk.org  Fri Apr 19 07:23:12 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 07:23:12 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
Message-ID: <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>

On Fri, 19 Apr 2024 00:50:15 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Yes what I meant is that the numbers in the test are essentially arbitrary. Now that they are further away from the limit, I would expect failures to be less likely. But if there are still failures, I can make the difference even larger.
>
> It would be good to know why the failures happened so they can be prevented.

I pushed a new change that reverts to the original test cases, but adds more debug output. @bplb Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1571941655

From aivanov at openjdk.org  Fri Apr 19 10:55:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 10:55:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:

> 31: /*
> 32:  * The Apple Security Provider.
> 33:  */

Does it make sense to incorporate this comment into the following javadoc comment?


/**
 * Defines the (an) Apple security provider.
 * ...
 */
@SuppressWarnings("serial") // JDK implementation class

src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:

> 35: import static sun.security.util.SecurityProviderConstants.*;
> 36: 
> 37: /*

Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.

The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:

> 36: 
> 37: /**
> 38:  * Open an file input stream given a URL.

Suggestion:

 * Open a file input stream given a URL.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572192780
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572184441
PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572189001

From aivanov at openjdk.org  Fri Apr 19 11:04:56 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 11:04:56 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <-ZdPijmlx_H98EC5meigkk-QBEQawMNWEQi-Y-dyHgo=.469f84c6-9897-49c3-ba55-872d13939555@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?


/**
 * This is a class.
 */
public class A {}


or


/**
 * This is a class.
 */

public class A {}


Which is the most common? Which is preferred?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066337900

From dfuchs at openjdk.org  Fri Apr 19 11:29:57 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Fri, 19 Apr 2024 11:29:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <c4-wxoGocaNumdyy8fUX4fVZBsSZxtJcKNmWXGbswiU=.d7e14e40-5057-473b-87af-fae5864be982@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

Changes to networking code looks good. I didn't spot any issue with the rest but I'm usually not a reviewer there.

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

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2011186056

From prappo at openjdk.org  Fri Apr 19 11:35:58 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 19 Apr 2024 11:35:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:

    /**
     * @test TestSmallHeap
     * @bug 8067438 8152239
     * @summary Verify that starting the VM with a small heap works
     * @library /test/lib
     * @modules java.base/jdk.internal.misc
     * @build jdk.test.whitebox.WhiteBox
     * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
     * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
     */

I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2066383735

From alanb at openjdk.org  Fri Apr 19 12:02:05 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 19 Apr 2024 12:02:05 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v10]
In-Reply-To: <f_7-q1NPS5zAEnhYhiZp8EOaoS972HM_Ay7JNtEOtnA=.e7751e92-6ea2-48e0-b46f-9757fbcf2f3b@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <f_7-q1NPS5zAEnhYhiZp8EOaoS972HM_Ay7JNtEOtnA=.e7751e92-6ea2-48e0-b46f-9757fbcf2f3b@github.com>
Message-ID: <GJbDOB7hJaAMQFn0BPHEdgZshDK1Gb65xCptUaJamD4=.fa1de60b-50fb-458c-8e97-2c2fb00beb2f@github.com>

On Fri, 19 Apr 2024 07:23:12 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert test parameters and add debug output to test

src/java.base/share/classes/java/nio/file/WatchService.java line 110:

> 108:  * If more events occur than the maximum size of the event list, the pending
> 109:  * events are cleared and replaced with a single
> 110:  * {@link StandardWatchEventKinds#OVERFLOW OVERFLOW} event.

I think the implNote needs a bit more intro wording to explain the limit, maybe this would help:

The JDK's WatchService implementations buffer up to 512 pending events for each registered watchable object. If this limit is exceeded then pending events are discarded and the special OVERFLOW event is queued. This special event is the trigger to re-examine the state of the object, e.g. scan a watched directory to get an updated list of the files in the directory. The limit for the pending events can be changed from its default with the system property jdk.nio.file.WatchService.maxEventsPerPoll set to a value that parses as a positive integer. This may be useful in environments where there is a high volume of changes and where the impact of discard events is high.

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 45:

> 43:      * Maximum size of event list before dropping events and signalling OVERFLOW
> 44:      */
> 45:     @SuppressWarnings("removal")

Is the SupressWarnings left over from a previous iteration?

src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 58:

> 56:                 Long.decode(rawValue),
> 57:                 1,
> 58:                 ArraysSupport.SOFT_MAX_ARRAY_LENGTH);

The use of ArraysSupport.SOFT_MAX_ARRAY_LENGTH to limit the value seems a bit overkill here. It's okay, just overkill.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572260605
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572260925
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572261472

From duke at openjdk.org  Fri Apr 19 12:29:31 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 12:29:31 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v11]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <Eh0lCRp7T89RfapfOH-7XgCZuxc8QCmmzKjL_R8SIBc=.6fb26e38-ba8d-4190-9f71-f470e6539122@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Change implNote and remove leftover annotation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/61e46d66..2a17cee9

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

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

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

From duke at openjdk.org  Fri Apr 19 12:29:31 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 12:29:31 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v10]
In-Reply-To: <GJbDOB7hJaAMQFn0BPHEdgZshDK1Gb65xCptUaJamD4=.fa1de60b-50fb-458c-8e97-2c2fb00beb2f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <f_7-q1NPS5zAEnhYhiZp8EOaoS972HM_Ay7JNtEOtnA=.e7751e92-6ea2-48e0-b46f-9757fbcf2f3b@github.com>
 <GJbDOB7hJaAMQFn0BPHEdgZshDK1Gb65xCptUaJamD4=.fa1de60b-50fb-458c-8e97-2c2fb00beb2f@github.com>
Message-ID: <-QScj5r3aHQVwaLrLwj9LNwFG6QEKpqu9ErUqGP4cWc=.e9d5000b-8e5d-4d9d-b0b5-8d8c6514b778@github.com>

On Fri, 19 Apr 2024 11:57:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert test parameters and add debug output to test
>
> src/java.base/share/classes/java/nio/file/WatchService.java line 110:
> 
>> 108:  * If more events occur than the maximum size of the event list, the pending
>> 109:  * events are cleared and replaced with a single
>> 110:  * {@link StandardWatchEventKinds#OVERFLOW OVERFLOW} event.
> 
> I think the implNote needs a bit more intro wording to explain the limit, maybe this would help:
> 
> The JDK's WatchService implementations buffer up to 512 pending events for each registered watchable object. If this limit is exceeded then pending events are discarded and the special OVERFLOW event is queued. This special event is the trigger to re-examine the state of the object, e.g. scan a watched directory to get an updated list of the files in the directory. The limit for the pending events can be changed from its default with the system property jdk.nio.file.WatchService.maxEventsPerPoll set to a value that parses as a positive integer. This may be useful in environments where there is a high volume of changes and where the impact of discard events is high.

Thanks, I like the additional explanations. I added it.

In the process, I removed the specification for what happens if the property doesn't parse as a positive integer. It seems fine to me not to specify this, but I can add it back if you think it's needed.

> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 45:
> 
>> 43:      * Maximum size of event list before dropping events and signalling OVERFLOW
>> 44:      */
>> 45:     @SuppressWarnings("removal")
> 
> Is the SupressWarnings left over from a previous iteration?

It was, I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572290389
PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572290593

From bpb at openjdk.org  Fri Apr 19 14:47:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 14:47:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
Message-ID: <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>

On Fri, 19 Apr 2024 07:20:16 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> It would be good to know why the failures happened so they can be prevented.
>
> I pushed a new change that reverts to the original test cases, but adds more debug output. @bplb Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?

> Could you share the omitted list of files? The error message should give us the diff, which would be helpful in figuring out what went wrong.

Voila:

java.lang.RuntimeException: Expected events on: [entry1, entry0, entry3, entry2, entry4], got: [entry1, entry0]
        at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
        at LotsOfEntries.main(LotsOfEntries.java:96)
        at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
        at java.base/java.lang.reflect.Method.invoke(Method.java:580)
        at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
        at java.base/java.lang.Thread.run(Thread.java:1575)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572486606

From bpb at openjdk.org  Fri Apr 19 14:47:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 14:47:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
Message-ID: <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>

On Fri, 19 Apr 2024 14:44:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I pushed a new change that reverts to the original test cases, but adds more debug output. @bplb Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?
>
>> Could you share the omitted list of files? The error message should give us the diff, which would be helpful in figuring out what went wrong.
> 
> Voila:
> 
> java.lang.RuntimeException: Expected events on: [entry1, entry0, entry3, entry2, entry4], got: [entry1, entry0]
>         at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
>         at LotsOfEntries.main(LotsOfEntries.java:96)
>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>         at java.base/java.lang.Thread.run(Thread.java:1575)

> Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?

@fmeum Will initiate in the next few minutes. Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572487566

From bpb at openjdk.org  Fri Apr 19 14:58:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 14:58:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
 <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
Message-ID: <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlIt9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>

On Fri, 19 Apr 2024 14:45:23 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Could you share the omitted list of files? The error message should give us the diff, which would be helpful in figuring out what went wrong.
>> 
>> Voila:
>> 
>> java.lang.RuntimeException: Expected events on: [entry1, entry0, entry3, entry2, entry4], got: [entry1, entry0]
>>         at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:84)
>>         at LotsOfEntries.main(LotsOfEntries.java:96)
>>         at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
>>         at java.base/java.lang.reflect.Method.invoke(Method.java:580)
>>         at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>>         at java.base/java.lang.Thread.run(Thread.java:1575)
>
>> Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?
> 
> @fmeum Will initiate in the next few minutes. Thanks.

I am seeing a build error now:

jdk/open/src/java.base/share/classes/java/nio/file/WatchService.java:105: error: reference not found
 * {@link StandardWatchEventKind#OVERFLOW OVERFLOW} event is queued. This
          ^
1 error

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572505418

From duke at openjdk.org  Fri Apr 19 15:42:27 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 15:42:27 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Fix typo

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/2a17cee9..6b3b2436

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

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

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

From bpb at openjdk.org  Fri Apr 19 15:42:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 15:42:27 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlIt9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
 <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
 <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlI
 t9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>
Message-ID: <86bvaCKFi6nW8U2DcyhjgxoWvzElfJtr0HHGsiKBviQ=.ddc2502e-41d2-4d95-b6b1-16ae05fea33f@github.com>

On Fri, 19 Apr 2024 14:56:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> Could you perhaps run the test again on linux-aarch64 now that we will get to see all events that were sent?
>> 
>> @fmeum Will initiate in the next few minutes. Thanks.
>
> I am seeing a build error now:
> 
> jdk/open/src/java.base/share/classes/java/nio/file/WatchService.java:105: error: reference not found
>  * {@link StandardWatchEventKind#OVERFLOW OVERFLOW} event is queued. This
>           ^
> 1 error

`StandardWatchEventKind` needs to be `StandardWatchEventKinds` (plural).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572558317

From duke at openjdk.org  Fri Apr 19 15:42:27 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Fri, 19 Apr 2024 15:42:27 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <86bvaCKFi6nW8U2DcyhjgxoWvzElfJtr0HHGsiKBviQ=.ddc2502e-41d2-4d95-b6b1-16ae05fea33f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
 <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
 <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlI
 t9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>
 <86bvaCKFi6nW8U2DcyhjgxoWvzElfJtr0HHGsiKBviQ=.ddc2502e-41d2-4d95-b6b1-16ae05fea33f@github.com>
Message-ID: <lTHgEukzG_srHx0NFtGyBez9b0YyGIgikz1wRSpEtoE=.00ea6bbe-03a8-4516-8ef5-34a88d28072c@github.com>

On Fri, 19 Apr 2024 15:36:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I am seeing a build error now:
>> 
>> jdk/open/src/java.base/share/classes/java/nio/file/WatchService.java:105: error: reference not found
>>  * {@link StandardWatchEventKind#OVERFLOW OVERFLOW} event is queued. This
>>           ^
>> 1 error
>
> `StandardWatchEventKind` needs to be `StandardWatchEventKinds` (plural).

Thanks, fixed the typo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572560939

From bpb at openjdk.org  Fri Apr 19 16:22:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 16:22:58 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <lTHgEukzG_srHx0NFtGyBez9b0YyGIgikz1wRSpEtoE=.00ea6bbe-03a8-4516-8ef5-34a88d28072c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
 <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
 <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlI
 t9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>
 <86bvaCKFi6nW8U2DcyhjgxoWvzElfJtr0HHGsiKBviQ=.ddc2502e-41d2-4d95-b6b1-16ae05fea33f@github.com>
 <lTHgEukzG_srHx0NFtGyBez9b0YyGIgikz1wRSpEtoE=.00ea6bbe-03a8-4516-8ef5-34a88d28072c@github.com>
Message-ID: <BMREGc9hYuA6FGzpR-enz14hMYbCSnTUwb7CIuAL-h4=.e201433d-9889-4607-b181-25a58be95086@github.com>

On Fri, 19 Apr 2024 15:39:00 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> `StandardWatchEventKind` needs to be `StandardWatchEventKinds` (plural).
>
> Thanks, fixed the typo.

Running tests now with locally fixed typo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572625258

From bpb at openjdk.org  Fri Apr 19 16:36:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 19 Apr 2024 16:36:01 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v8]
In-Reply-To: <BMREGc9hYuA6FGzpR-enz14hMYbCSnTUwb7CIuAL-h4=.e201433d-9889-4607-b181-25a58be95086@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <z8EeET1nxlYSJqAEyBqcl32D398PVuW7zj4LnFYqLic=.a8f336dc-8e0d-42b7-a211-7261910b4956@github.com>
 <HW8vuhcZlJS-IkqmjEU9pGD92fLrHQ7LN21Erj-VKAE=.14252796-4460-4e1e-8cad-6fed73314bbc@github.com>
 <qF2dunyDIhde2ExfuBdF24nZFtbGDPy__iz0dlGDqAI=.3eab64a8-b7e1-4552-ba77-284f6bb48c31@github.com>
 <UZ3bZrf5aaDwjvMgPsrC7iukDHAtuT0Gq9F4VokXqTM=.ba938453-b1e9-44e1-89cf-7b8a4b254d02@github.com>
 <QoHrWHwpLGrMv7ieBmlqBxKaKihsukttOZ1tAqHqqT0=.8d9d2e5f-4cbd-48d7-bfc5-d2bb7ef9a95c@github.com>
 <4yn64CjDpOkAQi68iXZ0VBf3MSZ6rFm2iQkWOH_sDG0=.e466fd07-9c67-446b-a9d3-e3ae45df2f0b@github.com>
 <-WrTxi7AEelIJUBD2mJJzfK-n28Oov9txUaRo6Z58ag=.0c376962-519b-4417-8eba-1a66d5a4d3bf@github.com>
 <0nGUp2yXZ66nIhqTRX46l6kOo_e8MkLHG-R1DPIPfdE=.95464f2f-1979-45f9-ab71-aa7a60461381@github.com>
 <h-mRsx-QmhIj24yylHsV54Y1TLD6PwSOv7_EYFFPUps=.6f63c494-137f-490a-a87c-ff86fbe61e8b@github.com>
 <tTkxG2D0s_G9sMjL8hc2LnaeCONKfEhYqlI
 t9ZXVzbc=.a2f2efe1-89d9-4be9-be06-94cf9cb56e81@github.com>
 <86bvaCKFi6nW8U2DcyhjgxoWvzElfJtr0HHGsiKBviQ=.ddc2502e-41d2-4d95-b6b1-16ae05fea33f@github.com>
 <lTHgEukzG_srHx0NFtGyBez9b0YyGIgikz1wRSpEtoE=.00ea6bbe-03a8-4516-8ef5-34a88d28072c@github.com>
 <BMREGc9hYuA6FGzpR-enz14hMYbCSnTUwb7CIuAL-h4=.e201433d-9889-4607-b181-25a58be95086@github.com>
Message-ID: <n0xaRTQWgzOm_j5fdS56R8iNxnfSpIEsOUhDt_g_nYY=.7ef57417-2111-434c-b1e5-710049f6f835@github.com>

On Fri, 19 Apr 2024 16:20:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Thanks, fixed the typo.
>
> Running tests now with locally fixed typo.

Still seeing failures

;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.

#section:main
----------messages:(6/343)----------
command: main -Djdk.nio.file.WatchService.maxEventsPerPoll=-5 LotsOfEntries 5 fail
reason: User specified action: run main/othervm -Djdk.nio.file.WatchService.maxEventsPerPoll=-5 LotsOfEntries 5 fail 
started: Fri Apr 19 16:27:35 UTC 2024
Mode: othervm [/othervm specified]
finished: Fri Apr 19 16:27:35 UTC 2024
elapsed time (seconds): 0.233
----------configuration:(0/0)----------
----------System.out:(4/418)----------
register name13539591746028431398 for events
create 5 entries
poll watcher...
poll expecting overflow...
----------System.err:(12/689)----------
java.lang.RuntimeException: Expected overflow event
	at LotsOfEntries.testCreateLotsOfEntries(LotsOfEntries.java:74)
	at LotsOfEntries.main(LotsOfEntries.java:104)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:103)
	at java.base/java.lang.reflect.Method.invoke(Method.java:580)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1575)

JavaTest Message: Test threw exception: java.lang.RuntimeException: Expected overflow event

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1572638089

From jjg at openjdk.org  Fri Apr 19 19:10:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:10:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <ed4aAlPaZnpFM_HVp75esTjXxSCzwKem2HqiWHPwcvM=.8264f272-6ffe-453f-940c-f0db3225adb1@github.com>

On Fri, 19 Apr 2024 10:53:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/macosx/classes/apple/security/AppleProvider.java line 33:
> 
>> 31: /*
>> 32:  * The Apple Security Provider.
>> 33:  */
> 
> Does it make sense to incorporate this comment into the following javadoc comment?
> 
> 
> /**
>  * Defines the (an) Apple security provider.
>  * ...
>  */
> @SuppressWarnings("serial") // JDK implementation class

Maybe, but only maybe, and if so, it would be out of scope for this work. That would be up to the relevant component team.

That being said, neither comment is part of any public API, and this comment is effectively already present in the first sentence of the actual doc comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572813320

From jjg at openjdk.org  Fri Apr 19 19:14:59 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:14:59 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <EyFdhhhVPa0ZjxN9MNwl--5bvRDGYrZJR8miOOgOBZ0=.513db9e4-6a6f-49b2-a0c8-3baa05cf5cf0@github.com>

On Fri, 19 Apr 2024 10:44:27 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> src/java.base/share/classes/com/sun/crypto/provider/SunJCE.java line 37:
> 
>> 35: import static sun.security.util.SecurityProviderConstants.*;
>> 36: 
>> 37: /*
> 
> Should this be included in the main javadoc comment? The `@author` tags belong in the javadoc comment.
> 
> The javadoc itself is likely unreadable, when processed the entire comment becomes one very long paragraph.

That would be up to the relevant component to decide how to improve these comments. The goal here is proactively fix any warnings that may be generated about multiple doc comments on a declaration.

I note that neither comment contributes to the public API, and that `@author` tags are generally obsolete these days. The VCS metadata is a more accurate reflection of individual contributions.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572818078

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

> It is somewhat off-topic. Yet I noticed javadoc comments in some files are followed a blank line, and others aren't. Out of my curiosity, is there a convention about the blank line between the javadoc comment and the class or interface declaration? Should there be one?
> 
> ```java
> /**
>  * This is a class.
>  */
> public class A {}
> ```
> 
> or
> 
> ```java
> /**
>  * This is a class.
>  */
> 
> public class A {}
> ```
> 
> Which is the most common? Which is preferred?

We do not have an overall style guide.   The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067156407

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <uNUsKyDQ7OPEfqBR08XGiC1UC-kdCHlS_Cht98Lvbrk=.4ee91d28-3db0-456e-814d-4d5359852994@github.com>
Message-ID: <plSw9jOH-0xxK5ZFqpYVa_RdLe0jGTIrrmOije3GV2c=.8c3f6569-fdfb-4fe8-b501-78f5da7fdf74@github.com>

On Fri, 19 Apr 2024 10:49:11 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>>   
>>   Fix grammatical typo
>>   
>>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>
>
> src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java line 38:
> 
>> 36: 
>> 37: /**
>> 38:  * Open an file input stream given a URL.
> 
> Suggestion:
> 
>  * Open a file input stream given a URL.

OK, I'll accept this as a minor typo mixup, that does not in itself need a CSR. But generally, it is not a goal to fix issues in the content of doc comments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18846#discussion_r1572821973

From jjg at openjdk.org  Fri Apr 19 19:21:13 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:21:13 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

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

  Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
  
  Fix grammatical typo
  
  Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18846/files
  - new: https://git.openjdk.org/jdk/pull/18846/files/fcbe02d5..d7b46a85

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

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

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

From jjg at openjdk.org  Fri Apr 19 19:27:58 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 19:27:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <4SE6Te42WtJEGKl4vTUxUTJqq1yQKnmsGHr_ZRu3tOc=.c1044ac8-17e1-4e32-b177-a897d5923a33@github.com>
Message-ID: <-fG_aheP9IBZLBq6GVU_1peVxqhpa7cQB0cpYK7cdDY=.b81305e0-56d5-4df2-9ac2-ca73e6433177@github.com>

On Fri, 19 Apr 2024 11:32:55 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

> This comment is not a review. I simply use the opportunity provided by this PR to suggest that we stop making new `/** ... */` and separately fix old jtreg comments like this:
> 
> ```
> /**
>  * @test TestSmallHeap
>  * @bug 8067438 8152239
>  * @summary Verify that starting the VM with a small heap works
>  * @library /test/lib
>  * @modules java.base/jdk.internal.misc
>  * @build jdk.test.whitebox.WhiteBox
>  * @run driver jdk.test.lib.helpers.ClassFileInstaller jdk.test.whitebox.WhiteBox
>  * @run main/othervm -Xbootclasspath/a:. -XX:+UnlockDiagnosticVMOptions -XX:+WhiteBoxAPI     gc.TestSmallHeap
>  */
> ```
> 
> I know that those comments only appear in tests, and that tests are never documented. Still, it is confusing to see such comments and IDEs might frown upon them too. Generally, it is a good rule of thumb that `/** ... */` should be reserved only for javadoc.

I agree we should not be using `/**` for test description comments.
IntelliJ tells me there are 103+ matches in 97+ files, so this would be a non-trivial cleanup. 
I note there are 22 issues in `test/langtools/jdk` tests (i.e. javadoc tests), so let's start there ;-)

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067164929

From aivanov at openjdk.org  Fri Apr 19 19:32:57 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:57 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <Lq-Q7ZUwaTVlfO51UDbEwlePabsWtebfX4r-DIObVwU=.fd2569b7-0595-4661-a841-aa890b9c3daa@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by aivanov (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012219677

From aivanov at openjdk.org  Fri Apr 19 19:32:58 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 19 Apr 2024 19:32:58 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
Message-ID: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>

On Fri, 19 Apr 2024 19:18:31 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.

That's what I do.

I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067169319

From naoto at openjdk.org  Fri Apr 19 19:51:06 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 19:51:06 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067190364

From jjg at openjdk.org  Fri Apr 19 20:36:30 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 20:36:30 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <w-JG6haR8WjwzphxoqnFE6p0yUuMEkexVLeGza3oUqA=.a02400cd-ba05-41a3-a8be-6772dcf40aac@github.com>
Message-ID: <H9YDeHC1vbzTbg9fB2HdGaLMDU1BuKqekRT-kLMyGKU=.2d7b6fc4-b059-4944-89b3-67004dac6ea0@github.com>

On Fri, 19 Apr 2024 19:47:20 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Unless it is absolutely necessary, I would not fix comments in `jdk.internal.icu` sources, as they are in the upstream code, and would like to minimize the merging effort.

@naotoj Given the policy and strong desire to compile `java.base` with all lint warnings enabled and `-Werror`, all of the proposed changes in this PR will each individually break the build if/when the warning is added to `javac` and we continue to compile `java.base` with the current build settings.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067246948

From naoto at openjdk.org  Fri Apr 19 20:40:31 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 19 Apr 2024 20:40:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

OK, fair enough. Approving for the `icu` part

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

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2012372872

From jjg at openjdk.org  Fri Apr 19 21:07:02 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Fri, 19 Apr 2024 21:07:02 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
 <G8U3LtxA7NYIKDj_y2_1OZ5l_yZlbfrUIScENzcI27A=.d474508a-a30e-4235-8876-23986222b518@github.com>
Message-ID: <7LlnKXolx2fp1kJEq5_UYjcC-q0Y8AF2hidczf7kPl8=.bcfb39c9-9992-44ee-9cec-8bfcda42dd9b@github.com>

On Fri, 19 Apr 2024 20:38:05 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> OK, fair enough. Approving for the `icu` part

Thank you.

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2067280359

From bruno.ploumhans at gmail.com  Fri Apr 19 21:46:50 2024
From: bruno.ploumhans at gmail.com (Bruno Ploumhans)
Date: Fri, 19 Apr 2024 23:46:50 +0200
Subject: Fwd: Thread interruption while reading from a ZipFS entry will
 close the entire FS
In-Reply-To: <ef73eb49-cd2a-4abb-8255-aea27ca80d70@oracle.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
 <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
 <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>
 <CAH225Xhwz0sYyN=bnaFEHEVmCBiUPNnNphYLVjBLCVtG+FKCJA@mail.gmail.com>
 <ef73eb49-cd2a-4abb-8255-aea27ca80d70@oracle.com>
Message-ID: <CAH225Xj_GoBMM0RT60jZ7EV_oXvsBnYgrnNX9k4V2v=QL6bkNg@mail.gmail.com>

> I don't think that would make sense. The reason the thread has been interrupted is because something wants to cancel what it are doing as quickly as possible. It's important that operations on network channels that block indefinitely are interruptible.

Would the same hold say for a file that is accessed via the network?
Maybe in those cases the file access is actually a network operation
in disguise.

> The discussion is focused on FileChannel as it is somewhat questionable whether it should have been an InterruptibleChannel in the first place.

It sounds questionable, yes. Is this something that can be changed now?

Bruno

From Alan.Bateman at oracle.com  Mon Apr 22 06:20:32 2024
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Mon, 22 Apr 2024 07:20:32 +0100
Subject: Fwd: Thread interruption while reading from a ZipFS entry will
 close the entire FS
In-Reply-To: <CAH225Xj_GoBMM0RT60jZ7EV_oXvsBnYgrnNX9k4V2v=QL6bkNg@mail.gmail.com>
References: <CAH225Xi-vNxVbhsq5h2o+Hmm_JFPcZ=wfuQ80b-ffx4aALOcuQ@mail.gmail.com>
 <04377785-23aa-4254-b215-43457aed0f34@oracle.com>
 <CAH225Xiw2wQ6Jn1C-N+A_67Ssaxd1w9qfOk0Gfk3cKFrwG2drw@mail.gmail.com>
 <CAH225XjOpE73QEEqfj6d+uFEGK9r+oxHCdjmMs37_-6hZwj7Dw@mail.gmail.com>
 <d93068b9-bd51-41ea-95db-a12c97f43611@oracle.com>
 <CAH225Xhwz0sYyN=bnaFEHEVmCBiUPNnNphYLVjBLCVtG+FKCJA@mail.gmail.com>
 <ef73eb49-cd2a-4abb-8255-aea27ca80d70@oracle.com>
 <CAH225Xj_GoBMM0RT60jZ7EV_oXvsBnYgrnNX9k4V2v=QL6bkNg@mail.gmail.com>
Message-ID: <edb310e9-91d1-4865-aad6-a2249843c6c4@oracle.com>



On 19/04/2024 22:46, Bruno Ploumhans wrote:
> Would the same hold say for a file that is accessed via the network?
> Maybe in those cases the file access is actually a network operation
> in disguise.
It might although the user of the API or the implementation may have no 
knowledge that the file is "remote".

>> The discussion is focused on FileChannel as it is somewhat questionable whether it should have been an InterruptibleChannel in the first place.
> It sounds questionable, yes. Is this something that can be changed now?
>
The discussion that I linked to didn't go very far, it would need energy 
to try to move it forward, more likely as an option when opening a file.

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

From alanb at openjdk.org  Mon Apr 22 12:11:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:11:30 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
Message-ID: <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>

On Fri, 19 Apr 2024 15:42:27 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

The implNote in WatchService looks okay. The change to AbstractWatchKey looks okay, just a bit overkill in the clamping. The test looks like it will take a few iterations to be stable so I'll stay out of that for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2069231056

From alanb at openjdk.org  Mon Apr 22 12:45:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:45:53 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

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

 - Merge
 - Sync up from loom repo, update copyright headers
 - Merge
 - Merge
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18598/files
  - new: https://git.openjdk.org/jdk/pull/18598/files/a21a8d6b..0d99fe0c

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

  Stats: 35845 lines in 976 files changed: 19000 ins; 10527 del; 6318 mod
  Patch: https://git.openjdk.org/jdk/pull/18598.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18598/head:pull/18598

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

From alanb at openjdk.org  Mon Apr 22 12:45:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 22 Apr 2024 12:45:53 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <1A4v-0RIqCwLMUTCZ4XUEC0uV4Qwegh5JGZZOvVeauo=.c15ac785-d844-461f-97cf-da4ea890f220@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

The changes are updated to pin when attempting to increase parallelism. That removes the possibility of preemption in begingBlocking for now so hopefully this is easier to understand. Also removed the transferTo overloads for now, that would make it easier too but we may want to come back to them in the future.

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

PR Comment: https://git.openjdk.org/jdk/pull/18598#issuecomment-2069298348

From jjg at openjdk.org  Mon Apr 22 17:41:28 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Mon, 22 Apr 2024 17:41:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
Message-ID: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>

On Fri, 19 Apr 2024 19:29:31 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > We do not have an overall style guide. The conventional wisdom for editing any existing file is to follow the style in that file, if such a style can be discerned.
> 
> That's what I do.
> 
> I saw either style used in JDK. Yet I didn't check which style is more common? to decide which style I should use when creating new files with javadoc comments. [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) doesn't have a blank line between the javadoc comment and class declaration; nor do javadoc comments for fields and methods.

The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

>Footnotes
>
> [1] At Java Software, we use @version for the SCCS version. See "man sccs-get" for details. The consensus seems to be the following:

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070379608

From aivanov at openjdk.org  Mon Apr 22 17:56:28 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 22 Apr 2024 17:56:28 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <TdwzsypvcWNa9TjWpONMyW8E2F6F_k2Hr3pq7kB3Y70=.1bf87a16-4e4e-4415-b0ae-6d21f46a71fa@github.com>
 <9igTsGRXv9_iiCqKHxNbYuRYJTTqd2lHv13HONETAHQ=.d3d92bd2-6d22-4145-bbcf-ba4e9396ef11@github.com>
 <_1IYuCIT-Mt531EpGoMHvmM5vtvsPj2kQ6yEmkCnyms=.ead0b11d-789c-4215-9897-cf878b3b8cff@github.com>
Message-ID: <00Gbr5mrPAEDVFsF8tkDSasn1qIk1OftDX9nvExC9mg=.c3313acd-0939-4af8-9c36-e9c8b7e6e518@github.com>

On Mon, 22 Apr 2024 17:38:59 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The document [How to Write Doc Comments for the Javadoc Tool](https://www.oracle.com/uk/technical-resources/articles/java/javadoc-tool.html) is depressingly obsolete, as indicated by this text towards the end:

I know. Yet there's nothing newer, is there?

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

PR Comment: https://git.openjdk.org/jdk/pull/18846#issuecomment-2070433346

From bpb at openjdk.org  Mon Apr 22 18:39:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Apr 2024 18:39:31 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <GeLsrCnZslRDkk9mEXYNa2KXVLARMEFAGJqaymusVuY=.7799ca07-5479-4ae1-b93a-5545c93a54e4@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

Looks fine. I think dropping the `transferTo` overloads for now is good.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-2015549163

From bpb at openjdk.org  Mon Apr 22 18:42:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 22 Apr 2024 18:42:33 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
 <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>
Message-ID: <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>

On Mon, 22 Apr 2024 12:08:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The test looks like it will take a few iterations to be stable so I'll stay out of that for now.

Yes, I think it needs to be ascertained why the test has been failing in some cases and actually fix it as opposed to just tweaking the parameters.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2070595866

From duke at openjdk.org  Mon Apr 22 19:53:59 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 22 Apr 2024 19:53:59 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v13]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <Na4F95zeMnuvL6pXnhv1A--XUYX83L-MXBw4qXbxBmk=.c08813a0-67da-418a-99e0-3f3c33c51856@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `sun.nio.fs.maxWatchEvents`.

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

  Attemp to deflake test and add better output on failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/6b3b2436..dc920736

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

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

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

From duke at openjdk.org  Mon Apr 22 19:53:59 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Mon, 22 Apr 2024 19:53:59 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
 <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>
 <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>
Message-ID: <WGVsPYHIeyqhqbrzf4qWdWPTHgAQobsxMYKcBmooBUA=.d15ad82c-7457-405a-b17d-de6b88acc951@github.com>

On Mon, 22 Apr 2024 18:39:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Yes, I think it needs to be ascertained why the test has been failing in some cases and actually fix it as opposed to just tweaking the parameters.

I pushed a new version with better debug output and, crucially, logic that repeatedly polls the `WatchService` until no new events are reported. I suspect that the failures may not really be due to a bug in the non-test code, but rather caused by a single `poll` only seeing a subset of all events, with later `poll`s seeing all of them.

@bplb If you think that this approach is reasonable, could you rerun the test?

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2070827004

From bpb at openjdk.org  Tue Apr 23 01:33:39 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 01:33:39 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
 <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>
 <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>
Message-ID: <TPsO5I1vRG5mqSvNwuMqxA5DhBNjG5oVaPHFDmjx6Fk=.48eceba4-f58e-437d-b59b-5c45723769bf@github.com>

On Mon, 22 Apr 2024 18:39:26 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> The implNote in WatchService looks okay. The change to AbstractWatchKey looks okay, just a bit overkill in the clamping. The test looks like it will take a few iterations to be stable so I'll stay out of that for now.
>
>> The test looks like it will take a few iterations to be stable so I'll stay out of that for now.
> 
> Yes, I think it needs to be ascertained why the test has been failing in some cases and actually fix it as opposed to just tweaking the parameters.

> @bplb If you think that this approach is reasonable, could you rerun the test?

This update passed 400 iterations on linux-aarch64 and 100 on each of linux-x64, macosx-x64, and windows-x64.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2071246418

From darcy at openjdk.org  Tue Apr 23 02:29:31 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 23 Apr 2024 02:29:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <S6J882dLjdmFPXHVRQm77lTy73k9FIGC_-kDiBLael4=.0191a2c7-4f55-41b8-a389-e238c8b63f84@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by darcy (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016121831

From iris at openjdk.org  Tue Apr 23 02:35:31 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 23 Apr 2024 02:35:31 GMT
Subject: RFR: 8330178: Clean up non-standard use of /** comments in
 `java.base` [v2]
In-Reply-To: <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
 <KjhEVF9Kp6y6TtfwaoEqsrr76XFjyfn4gzqJitgrFKk=.e3d456a0-03db-4566-b15b-c0e5781cd6d1@github.com>
Message-ID: <QuHZeejL48phB87kuWRWzlunHQ6KGRSVvyNNCVjTFzk=.1edeb3eb-3cd6-4ed3-a0b5-1a39937dd7e3@github.com>

On Fri, 19 Apr 2024 19:21:13 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

>> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
>> 
>> There are various categories of update:
>> 
>> * "Box comments" beginning with `/**`
>> * Misplaced doc comments before package or import statements
>> * Misplaced doc comments after the annotations for a declaration
>> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
>> * Use of `/**` for the legal header at or near the top of the file
>> 
>> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.
>
> Jonathan Gibbons has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/sun/net/www/protocol/file/FileURLConnection.java
>   
>   Fix grammatical typo
>   
>   Co-authored-by: Alexey Ivanov <alexey.ivanov at oracle.com>

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/18846#pullrequestreview-2016126206

From jpai at openjdk.org  Tue Apr 23 07:09:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 23 Apr 2024 07:09:31 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <DSv2hEvDDW4oLhKV1wRyoT916V_3V7DeyjudVKSikAc=.e7c227d6-093b-407e-965d-958d5f4c28a9@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

Hello Alan, the latest changes look fine to me. They also address the review comments from the previous iteration.

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/18598#pullrequestreview-2016427528

From vklang at openjdk.org  Tue Apr 23 08:07:35 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 23 Apr 2024 08:07:35 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
Message-ID: <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>

On Mon, 22 Apr 2024 12:45:53 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
>> 
>> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
>> 
>> The changes have been baking in loom repo for some time.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge
>  - Sync up from loom repo, update copyright headers
>  - Merge
>  - Merge
>  - Initial commit

src/java.base/share/classes/java/io/FileInputStream.java line 211:

> 209:      * @param name the name of the file
> 210:      */
> 211:     private void open(String name) throws FileNotFoundException {

If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1575825688

From alanb at openjdk.org  Tue Apr 23 08:11:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 08:11:30 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
 <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
Message-ID: <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>

On Tue, 23 Apr 2024 08:04:54 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
>> 
>>  - Merge
>>  - Sync up from loom repo, update copyright headers
>>  - Merge
>>  - Merge
>>  - Initial commit
>
> src/java.base/share/classes/java/io/FileInputStream.java line 211:
> 
>> 209:      * @param name the name of the file
>> 210:      */
>> 211:     private void open(String name) throws FileNotFoundException {
> 
> If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?

Historically these native methods were wrapped in order to support instrumentation, I didn't want to touch in this PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1575831563

From duke at openjdk.org  Tue Apr 23 08:48:29 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Tue, 23 Apr 2024 08:48:29 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v12]
In-Reply-To: <TPsO5I1vRG5mqSvNwuMqxA5DhBNjG5oVaPHFDmjx6Fk=.48eceba4-f58e-437d-b59b-5c45723769bf@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <kQrSHlp5RTG2YXegBMhvDjI_G4GYh6Rr_L_9GM_EYwY=.316bc738-d4e8-49ea-b282-14ef41a8cb30@github.com>
 <lGcjyIVtFkFu9aQkxUddUGU_111VjhFOKYJTgU--mDs=.8623ea07-e125-44a0-b757-54c3e19b921f@github.com>
 <KuhWH0dwSrbolVaBbOF05auMkqZpA6g-NRByu2dZVxE=.efdf2541-3927-419d-b4f7-6853882d7bea@github.com>
 <TPsO5I1vRG5mqSvNwuMqxA5DhBNjG5oVaPHFDmjx6Fk=.48eceba4-f58e-437d-b59b-5c45723769bf@github.com>
Message-ID: <IxLmFxyOUubUYSsbsaZuuerOdXrocjnK8F6XqmlBkjM=.0a1ca870-c80c-4cb8-948f-d31efa823242@github.com>

On Tue, 23 Apr 2024 01:30:45 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>>> The test looks like it will take a few iterations to be stable so I'll stay out of that for now.
>> 
>> Yes, I think it needs to be ascertained why the test has been failing in some cases and actually fix it as opposed to just tweaking the parameters.
>
>> @bplb If you think that this approach is reasonable, could you rerun the test?
> 
> This update passed 400 iterations on linux-aarch64 and 100 on each of linux-x64, macosx-x64, and windows-x64.

@bplb Thanks! Is there anything else you would want me to change or test?

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2071753732

From alanb at openjdk.org  Tue Apr 23 16:12:34 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 23 Apr 2024 16:12:34 GMT
Subject: Integrated: 8329593: Drop adjustments to target parallelism when
 virtual threads do I/O on files opened for buffered I/O
In-Reply-To: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
Message-ID: <QVHrpvn_QcrlxtgtnNksCzYq5HfWB5hbS2lYAdCeR9o=.3ae2fd39-7131-439b-ab7a-78a4ab80d51f@github.com>

On Wed, 3 Apr 2024 10:04:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This change drops the adjustments to the virtual thread scheduler's target parallelism when virtual threads do file operations on files that are opened for buffered I/O. These operations are usually just too short to have any benefit and may have a negative benefit when reading/writing a small number of bytes. There is no change for read/write operations on files opened for direct I/O or when writing to files that are opened with options for synchronized I/O file integrity (O_SYNC/O_DSYNC and equivalents). Sergery Kuksenko is polishing benchmarks that includes this area, this is for a future PR.
> 
> In addition, the blocker mechanism is updated to handle reentrancy (as can happen if debugging code is added to ForkJoinPool) and preemption when compensating (as can happen when substituting a heap buffer with a direct buffer in some I/O operations).  This part is a pre-requisite to the changes to better support object monitor there are more places where preemption is possible and this quickly leads to unbalanced begin/end.
> 
> The changes have been baking in loom repo for some time.

This pull request has now been integrated.

Changeset: 412e306d
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/412e306d81209c05f55aee7663f7abb80286e361
Stats:     1084 lines in 28 files changed: 215 ins; 624 del; 245 mod

8329593: Drop adjustments to target parallelism when virtual threads do I/O on files opened for buffered I/O

Reviewed-by: bpb, jpai

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

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

From bpb at openjdk.org  Tue Apr 23 16:40:33 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 16:40:33 GMT
Subject: RFR: 8329593: Drop adjustments to target parallelism when virtual
 threads do I/O on files opened for buffered I/O [v2]
In-Reply-To: <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>
References: <PvBqu9EoOFEleNjog9gAEZcGChEks0x6Gys3pg_W_B8=.d1d44ca8-af3a-4f3d-83fe-45b5ffd48ac9@github.com>
 <Iwqt6qDPbtjxgOhn8y8cbg807julge72CJ88TEvgBaM=.a656696d-7881-48dc-873a-346f9ec6e263@github.com>
 <03havZuXU3rRqqFBvZbQBiPCEZqGiNAZhosgXPmsBOs=.9ede81af-6aa9-4167-9fc5-5c9cd98969c2@github.com>
 <ELfitihzx8ne8twVUMqNfB3704i0le6CkUpcBwuONuI=.fb4c9d46-a6e8-412e-9100-340c3aea8ff7@github.com>
Message-ID: <03_OsWfkX-FXOY2u43wIHhSvJZ3rF3CqV5VJfdnA-ao=.113839a2-147e-42c1-8e7b-5e0d2ca02aa7@github.com>

On Tue, 23 Apr 2024 08:09:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/FileInputStream.java line 211:
>> 
>>> 209:      * @param name the name of the file
>>> 210:      */
>>> 211:     private void open(String name) throws FileNotFoundException {
>> 
>> If method such as this is private, and only delegates to the 0-suffixed native method, would't it be better to just call the 0-suffixed method directly?
>
> Historically these native methods were wrapped in order to support instrumentation, I didn't want to touch in this PR.

And presumably all these 0-suffixed methods will eventually be replaced with FFM calls anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18598#discussion_r1576561165

From bpb at openjdk.org  Tue Apr 23 17:56:30 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 23 Apr 2024 17:56:30 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v13]
In-Reply-To: <Na4F95zeMnuvL6pXnhv1A--XUYX83L-MXBw4qXbxBmk=.c08813a0-67da-418a-99e0-3f3c33c51856@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Na4F95zeMnuvL6pXnhv1A--XUYX83L-MXBw4qXbxBmk=.c08813a0-67da-418a-99e0-3f3c33c51856@github.com>
Message-ID: <UXR4AUOOhs3gxbvPgnfnwjz3pJSybQMNm7piyyhCpIU=.49afa1d0-d13f-493e-9d02-cc26d1d4db35@github.com>

On Mon, 22 Apr 2024 19:53:59 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `jdk.nio.file.WatchService.maxEventsPerPoll`.
>
> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Attemp to deflake test and add better output on failures

src/java.base/share/classes/java/nio/file/WatchService.java line 109:

> 107:  * scan a watched directory to get an updated list of the files in the
> 108:  * directory. The limit for the pending events can be changed from its default
> 109:  * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}

@fmeum On this line 109, would you please change `@code` to `@systemProperty`?


--- a/src/java.base/share/classes/java/nio/file/WatchService.java
+++ b/src/java.base/share/classes/java/nio/file/WatchService.java
@@ -106,7 +106,8 @@
  * special event is the trigger to re-examine the state of the object, e.g.
  * scan a watched directory to get an updated list of the files in the
  * directory. The limit for the pending events can be changed from its default
- * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}
+ * with the system property
+ * {@systemProperty jdk.nio.file.WatchService.maxEventsPerPoll}
  * set to a value that parses as a positive integer. This may be useful in
  * environments where there is a high volume of changes and where the impact
  * of discarded events is high.
  * ```

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1576664904

From jjg at openjdk.org  Tue Apr 23 18:46:34 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Tue, 23 Apr 2024 18:46:34 GMT
Subject: Integrated: 8330178: Clean up non-standard use of /** comments in
 `java.base`
In-Reply-To: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
References: <s-0CLqa3HMzqT4vNqpmpKJg40Uuapr4hrdEpTz_QisA=.321fc177-dd1e-4f5a-8959-33e798c7823c@github.com>
Message-ID: <Hf-QMEmB4eLr-CA0UEIiWRwxxplcD-ZKUVbOJ44BPsc=.20073ab8-4ece-463c-a4e4-afdba6586f28@github.com>

On Thu, 18 Apr 2024 20:44:00 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> Please review a set of updates to clean up use of `/**` comments in the vicinity of declarations.
> 
> There are various categories of update:
> 
> * "Box comments" beginning with `/**`
> * Misplaced doc comments before package or import statements
> * Misplaced doc comments after the annotations for a declaration
> * Dangling `/**` comments relating to a group of declarations, separate from the doc comments for each of those declarations
> * Use of `/**` for the legal header at or near the top of the file
> 
> In one case, two doc comments before a declaration were merged, which fixes a bug/omission in the documented serialized form.

This pull request has now been integrated.

Changeset: 9cc163a9
Author:    Jonathan Gibbons <jjg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9cc163a999eb8e9597d45b095b642c25071043bd
Stats:     134 lines in 23 files changed: 50 ins; 56 del; 28 mod

8330178: Clean up non-standard use of /** comments in `java.base`

Reviewed-by: darcy, iris, dfuchs, aivanov, naoto

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

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

From duke at openjdk.org  Wed Apr 24 08:18:03 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Wed, 24 Apr 2024 08:18:03 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v14]
In-Reply-To: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
Message-ID: <g_AnqNKE21_flrSVU6PcnF_G335l6Oo6_fU-ZdemdwU=.d9487533-2259-4b92-a451-7473e69ff25c@github.com>

> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `jdk.nio.file.WatchService.maxEventsPerPoll`.

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

 - Reflow
 - Use `@systemProperty`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18739/files
  - new: https://git.openjdk.org/jdk/pull/18739/files/dc920736..0703b3f4

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

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

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

From duke at openjdk.org  Wed Apr 24 08:21:32 2024
From: duke at openjdk.org (Fabian Meumertzheim)
Date: Wed, 24 Apr 2024 08:21:32 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v13]
In-Reply-To: <UXR4AUOOhs3gxbvPgnfnwjz3pJSybQMNm7piyyhCpIU=.49afa1d0-d13f-493e-9d02-cc26d1d4db35@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Na4F95zeMnuvL6pXnhv1A--XUYX83L-MXBw4qXbxBmk=.c08813a0-67da-418a-99e0-3f3c33c51856@github.com>
 <UXR4AUOOhs3gxbvPgnfnwjz3pJSybQMNm7piyyhCpIU=.49afa1d0-d13f-493e-9d02-cc26d1d4db35@github.com>
Message-ID: <QwtYMPgW_Gp5JKi3SWo-XYcurKnnrSFf-_DZuLyeVdk=.9b1eaed5-d577-4f63-be63-edd04258580f@github.com>

On Tue, 23 Apr 2024 17:53:52 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Attemp to deflake test and add better output on failures
>
> src/java.base/share/classes/java/nio/file/WatchService.java line 109:
> 
>> 107:  * scan a watched directory to get an updated list of the files in the
>> 108:  * directory. The limit for the pending events can be changed from its default
>> 109:  * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}
> 
> @fmeum On this line 109, would you please change `@code` to `@systemProperty`?
> 
> 
> --- a/src/java.base/share/classes/java/nio/file/WatchService.java
> +++ b/src/java.base/share/classes/java/nio/file/WatchService.java
> @@ -106,7 +106,8 @@
>   * special event is the trigger to re-examine the state of the object, e.g.
>   * scan a watched directory to get an updated list of the files in the
>   * directory. The limit for the pending events can be changed from its default
> - * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}
> + * with the system property
> + * {@systemProperty jdk.nio.file.WatchService.maxEventsPerPoll}
>   * set to a value that parses as a positive integer. This may be useful in
>   * environments where there is a high volume of changes and where the impact
>   * of discarded events is high.
>   * ```

Thanks, I didn't even know about this tag.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1577482151

From bpb at openjdk.org  Wed Apr 24 15:39:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 24 Apr 2024 15:39:31 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v13]
In-Reply-To: <QwtYMPgW_Gp5JKi3SWo-XYcurKnnrSFf-_DZuLyeVdk=.9b1eaed5-d577-4f63-be63-edd04258580f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <Na4F95zeMnuvL6pXnhv1A--XUYX83L-MXBw4qXbxBmk=.c08813a0-67da-418a-99e0-3f3c33c51856@github.com>
 <UXR4AUOOhs3gxbvPgnfnwjz3pJSybQMNm7piyyhCpIU=.49afa1d0-d13f-493e-9d02-cc26d1d4db35@github.com>
 <QwtYMPgW_Gp5JKi3SWo-XYcurKnnrSFf-_DZuLyeVdk=.9b1eaed5-d577-4f63-be63-edd04258580f@github.com>
Message-ID: <_iPyWvJ04YeO8pTXtpDsR5URZw7qWkaN4Q4tR6Z1Xb8=.295a3c36-27fe-4588-8ed8-35891ec98936@github.com>

On Wed, 24 Apr 2024 08:18:23 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/nio/file/WatchService.java line 109:
>> 
>>> 107:  * scan a watched directory to get an updated list of the files in the
>>> 108:  * directory. The limit for the pending events can be changed from its default
>>> 109:  * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}
>> 
>> @fmeum On this line 109, would you please change `@code` to `@systemProperty`?
>> 
>> 
>> --- a/src/java.base/share/classes/java/nio/file/WatchService.java
>> +++ b/src/java.base/share/classes/java/nio/file/WatchService.java
>> @@ -106,7 +106,8 @@
>>   * special event is the trigger to re-examine the state of the object, e.g.
>>   * scan a watched directory to get an updated list of the files in the
>>   * directory. The limit for the pending events can be changed from its default
>> - * with the system property {@code jdk.nio.file.WatchService.maxEventsPerPoll}
>> + * with the system property
>> + * {@systemProperty jdk.nio.file.WatchService.maxEventsPerPoll}
>>   * set to a value that parses as a positive integer. This may be useful in
>>   * environments where there is a high volume of changes and where the impact
>>   * of discarded events is high.
>>   * ```
>
> Thanks, I didn't even know about this tag.

Neither did I, until @AlanBateman made me aware of it.

I will run some more tests and file the CSR.

Thanks.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1578101555

From duke at openjdk.org  Thu Apr 25 14:32:56 2024
From: duke at openjdk.org (Nizar Benalla)
Date: Thu, 25 Apr 2024 14:32:56 GMT
Subject: RFR: 8326951: Missing `@since` tags [v7]
In-Reply-To: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
References: <_iA0CxGgaa8nA5AlNfT1IfG3Y6Wx7tcdiv3oJQNYCjQ=.5fb84060-0490-4b18-8995-cc534e1c22f5@github.com>
Message-ID: <uxcHyxMQujj7fdLTM-k6ctt1CtD5BWSomXi6eD0yp7M=.87b40f9e-cf37-401c-a9e5-197e89395761@github.com>

> I added `@since` tags for methods/constructors that do not match the `@since` of the enclosing class.
> 
> The `write` method already existed in `PrintStream` in earlier versions and instances of it could always call this method, since it extends `FilterOutputStream` [which has the method](https://github.com/openjdk/jdk6/blob/3e49aa876353eaa215cde71eb21acc9b7f9872a0/jdk/src/share/classes/java/io/FilterOutputStream.java#L96).
> 
> This is similar to #18032 and #18373 
> 
> For context, I am writing tests to check for accurate use of `@since` tags in documentation comments in source code.
> We're following these rules for now:
> 
> ### Rule 1: Introduction of New Elements
> 
> - If an element is new in JDK N, with no equivalent in JDK N-1, it must include `@since N`.
>   - Exception: Member elements (fields, methods, nested classes) may omit `@since` if their version matches the value specified for the enclosing class or interface.
> 
> ### Rule 2: Existing Elements in Subsequent JDK Versions
> 
> - If an element exists in JDK N, with an equivalent in JDK N-1, it should not include `@since N`.
> 
> ### Rule 3: Handling Missing `@since` Tags in methods if there is no `@since`
> 
> - When inspecting methods, prioritize the `@since` annotation of the supertype's overridden method.
> - If unavailable or if the enclosing class's `@since` is newer, use the enclosing element's `@since`.
> 
>   I.e. if A extends B, and we add a method to B in JDK N, and add an override of the method to A in JDK M (M > N), we will use N as the effective `@since` for the method.

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

  deal with methods with different return types - added some spaces for readability

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18055/files
  - new: https://git.openjdk.org/jdk/pull/18055/files/390a21f9..670acaec

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

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

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

From imediava at gmail.com  Thu Apr 25 15:23:41 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 25 Apr 2024 17:23:41 +0200
Subject: Contribution to JDK - 8313674
Message-ID: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>

Hello,

For my first contribution to OpenJDK, I've started looking into JDK-8313674.

Elif Aslan, I see that you've been assigned to this ticket, would you mind
if I try to propose a solution for it ?

If Elif is OK with it, I'd like to find a sponsor, since this would be my
first time contributing to OpenJDK. Would anyone be available to sponsor my
contribution ?

Thanks in advance

??igo Mediavilla Saiz
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240425/63fe0045/attachment.htm>

From imediava at gmail.com  Thu Apr 25 21:14:39 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Thu, 25 Apr 2024 23:14:39 +0200
Subject: Contribution to JDK - 8313674
In-Reply-To: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>
References: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>
Message-ID: <CA+wBRWA+CddCUHiDZRRzvCTB4yW3fFgzF6mFU-4EDx0pMADvow@mail.gmail.com>

After looking at JDK-8313674 I'm wondering what is the current impact:

- Is it affecting the CI or the CI is always running in linux systems with
sda devices ?
- Is it that local tests fail when they?re run from a linux device that
doesn?t have a sda device ?

In terms of possible fixes, I think that a quick fix would be to add a nvm*
device in the list of hard-coded devices to be tested. The test could
iterate over the list of devices to test skipping devices that don't exist
but running the checks on the first existing device.

As an alternative I also considered adding logic to list existing block
devices and picking one to run the test, however I've not being able to
figure out a way to do this in a simple way:

- There are libraries like (https://github.com/jnr/jnr-posix/) that
implement that logic, but I feel like it?s not worth incorporating such
library only for the purpose of this test.
- I see that there are parts of the native code in the JDK repo that use
S_ISBLK to check if a device is a block device, but I haven?t been able to
find that information surfaced to Java.

Happy to hear the thoughts of people with more background on the topic :)

??igo Mediavilla Saiz

On Thu, Apr 25, 2024 at 5:23?PM I?igo Mediavilla <imediava at gmail.com> wrote:

> Hello,
>
> For my first contribution to OpenJDK, I've started looking into
> JDK-8313674.
>
> Elif Aslan, I see that you've been assigned to this ticket, would you mind
> if I try to propose a solution for it ?
>
> If Elif is OK with it, I'd like to find a sponsor, since this would be my
> first time contributing to OpenJDK. Would anyone be available to sponsor my
> contribution ?
>
> Thanks in advance
>
> ??igo Mediavilla Saiz
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240425/e519d2e0/attachment.htm>

From bpb at openjdk.org  Fri Apr 26 00:33:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 26 Apr 2024 00:33:35 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v14]
In-Reply-To: <g_AnqNKE21_flrSVU6PcnF_G335l6Oo6_fU-ZdemdwU=.d9487533-2259-4b92-a451-7473e69ff25c@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <g_AnqNKE21_flrSVU6PcnF_G335l6Oo6_fU-ZdemdwU=.d9487533-2259-4b92-a451-7473e69ff25c@github.com>
Message-ID: <vprLIGxGwE0roKUj2j1HLv829sx76WFKgxTYkNmrPJo=.cca2b420-8c6b-405f-b977-639799b2c4d7@github.com>

On Wed, 24 Apr 2024 08:18:03 GMT, Fabian Meumertzheim <duke at openjdk.org> wrote:

>> The limit on the number of events buffered for a single `j.n.f.WatchKey` is now configurable via the `jdk.nio.file.WatchService.maxEventsPerPoll`.
>
> Fabian Meumertzheim has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Reflow
>  - Use `@systemProperty`

CSR filed.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2078390821

From alanb at openjdk.org  Fri Apr 26 07:40:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 26 Apr 2024 07:40:36 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v14]
In-Reply-To: <vprLIGxGwE0roKUj2j1HLv829sx76WFKgxTYkNmrPJo=.cca2b420-8c6b-405f-b977-639799b2c4d7@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <g_AnqNKE21_flrSVU6PcnF_G335l6Oo6_fU-ZdemdwU=.d9487533-2259-4b92-a451-7473e69ff25c@github.com>
 <vprLIGxGwE0roKUj2j1HLv829sx76WFKgxTYkNmrPJo=.cca2b420-8c6b-405f-b977-639799b2c4d7@github.com>
Message-ID: <OBSF06Qx7sD2oAhmjRedz51LwrUIvmanW52-v2rccfE=.8b9f95ac-288a-49a7-94a9-9aa1dba5fd38@github.com>

On Fri, 26 Apr 2024 00:30:40 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> CSR filed.

I've reviewed CSR, should be able to finalize now. We'll need to add a release note for this update too.

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

PR Comment: https://git.openjdk.org/jdk/pull/18739#issuecomment-2078808838

From tprinzing at openjdk.org  Mon Apr 29 19:57:32 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 19:57:32 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v9]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <3XIRqaNWkthCK1SsNZup_b-nFBkLR98tKGOEcJm60KM=.10f00ced-6145-4337-b1a5-c26a7fd9c707@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'refs/heads/master' into JDK-8329138
 - remove unecessary blank line
 - IntelliJ trying to help
 - undo fix being handled in JDK-8329330.
 - test file local to test
 - fix windows build issue
 - requested changes
 - Add support for AsynchronousFileChannel.force().
 - javadoc fixup
 - remove mirrors from JDKEvents
 - ... and 1 more: https://git.openjdk.org/jdk/compare/819f3d6f...743b92a6

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

Changes: https://git.openjdk.org/jdk/pull/18542/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=08
  Stats: 279 lines in 12 files changed: 238 ins; 27 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/18542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542

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

From tprinzing at openjdk.org  Mon Apr 29 20:01:38 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 20:01:38 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v10]
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

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

  fix mistake in merge

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/18542/files
  - new: https://git.openjdk.org/jdk/pull/18542/files/743b92a6..8bc34431

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

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

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

From tprinzing at openjdk.org  Mon Apr 29 21:33:24 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 21:33:24 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v9]
In-Reply-To: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
Message-ID: <IS6zbEDQPUEB5-z-2hyoFpD_SgPVGlpmgP31PQ23R24=.e9422ae5-8819-4307-be2e-46d3a91e2dfb@github.com>

> Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available.
> 
> Emit the event from SelectorImpl::lockAndDoSelect
> 
> Test at jdk.jfr.event.io.TestSelectionEvents

Tim Prinzing has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - fix merge
 - Merge branch 'refs/heads/master' into JDK-8310994
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
 - more annotation fixup
 - cleanup of annotations
 - remove selector spin event attempt and associated test.
 - update copyright dates
 - Merge branch 'master' into JDK-8310994
   
   # Conflicts:
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/MirrorEvents.java
   #	src/jdk.jfr/share/classes/jdk/jfr/internal/instrument/JDKEvents.java
 - comment fixup
 - add select timeout field to the event
 - Change event generation:
   
   - selectNow is filtered out
   - select that times out is always sent
   - select without timeout uses duration test
 - ... and 11 more: https://git.openjdk.org/jdk/compare/819f3d6f...dd43f4fa

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

Changes: https://git.openjdk.org/jdk/pull/16710/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=08
  Stats: 277 lines in 9 files changed: 273 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/16710.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710

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

From tprinzing at openjdk.org  Mon Apr 29 21:56:10 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Mon, 29 Apr 2024 21:56:10 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
 <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
Message-ID: <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>

On Thu, 11 Apr 2024 16:39:24 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> I think it's okay for now. If there is another phase of this work to help diagnose spinning issues then it will need to re-visited. I'm very concerned about the possible changes for that second phase, but this first phase of instrumentation is not disruptive.
>
> OK. I am a little concerned about how often this event will be fired when using the HttpClient - given that it's enabled by default. Idle connections sitting in the pool will fire it at least once per connection every 1500ms. That may not be too bad.

Should I set the default to be fairly high (like maybe 1600ms)?  I think to be useful people will have to set the threshold to something that fits their needs anyway.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1583825215

From tprinzing at openjdk.org  Tue Apr 30 00:34:07 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 30 Apr 2024 00:34:07 GMT
Subject: RFR: 8329138: Convert JFR FileForceEvent to static mirror event
 [v10]
In-Reply-To: <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
 <oVKR1hsexF2OE1bdPcMncpczH3_E7mHK0MiWBaCuJn8=.f64c8069-eee9-48ea-a807-6fe21d68d0c0@github.com>
Message-ID: <-tjL8Ax2C7Hr_DMe1tmNGBMAO8sjZxugPaFw3csRsQQ=.638b72e5-d88b-4a77-9e12-7cd93d3e6ea5@github.com>

On Mon, 29 Apr 2024 20:01:38 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
>> 
>> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
>> 
>> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
>> 
>> Uses the existing tests.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix mistake in merge

I went ahead and ran teir1 through teir3 tests on everything after the merge.  Everything passes so this is ready for integration.

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

PR Comment: https://git.openjdk.org/jdk/pull/18542#issuecomment-2083946114

From bpb at openjdk.org  Tue Apr 30 01:42:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 30 Apr 2024 01:42:15 GMT
Subject: RFR: 8330077: Allow max number of events to be buffered to be
 configurable to avoid OVERFLOW_EVENT [v10]
In-Reply-To: <GJbDOB7hJaAMQFn0BPHEdgZshDK1Gb65xCptUaJamD4=.fa1de60b-50fb-458c-8e97-2c2fb00beb2f@github.com>
References: <bRWsQGnNxGQivcgAOWHEcHYaS0gLBSeFz4x2gZQmMIk=.b7f97fef-8b8b-4397-af14-b2d24cd54e01@github.com>
 <f_7-q1NPS5zAEnhYhiZp8EOaoS972HM_Ay7JNtEOtnA=.e7751e92-6ea2-48e0-b46f-9757fbcf2f3b@github.com>
 <GJbDOB7hJaAMQFn0BPHEdgZshDK1Gb65xCptUaJamD4=.fa1de60b-50fb-458c-8e97-2c2fb00beb2f@github.com>
Message-ID: <XN_bwQRFIvqK1hGxSKizsl-sUd6MRNmsemjeMLgLKhE=.dd53777f-37fd-4137-b0ef-28d049235cb3@github.com>

On Fri, 19 Apr 2024 11:58:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Fabian Meumertzheim has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert test parameters and add debug output to test
>
> src/java.base/share/classes/sun/nio/fs/AbstractWatchKey.java line 58:
> 
>> 56:                 Long.decode(rawValue),
>> 57:                 1,
>> 58:                 ArraysSupport.SOFT_MAX_ARRAY_LENGTH);
> 
> The use of ArraysSupport.SOFT_MAX_ARRAY_LENGTH to limit the value seems a bit overkill here. It's okay, just overkill.

I am also okay with it. This might be a little simpler, however:

    static final int MAX_EVENT_LIST_SIZE;
    static {
        int intValue = DEFAULT_MAX_EVENT_LIST_SIZE;
        String rawValue = GetPropertyAction.privilegedGetProperty
            ("jdk.nio.file.WatchService.maxEventsPerPoll");
        if (rawValue != null) {
            try {
                intValue = Integer.decode(rawValue);
                if (intValue <= 0)
                    intValue = 1;
            } catch (NumberFormatException ignored) {
            }
        }
        MAX_EVENT_LIST_SIZE = intValue;
    }

Given that a lot of tests have already been run, it might be better just to go with 0703b3f499ee32a7efd780745c42b42131dfef85. I will plan to approve that tomorrow unless there is an objection.

As the CSR was approved, once the review is done, this can be integrated and then we will sponsor it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/18739#discussion_r1584020339

From duke at openjdk.org  Tue Apr 30 13:28:15 2024
From: duke at openjdk.org (Inigo Mediavilla Saiz)
Date: Tue, 30 Apr 2024 13:28:15 GMT
Subject: RFR: 8313674: Add nvme0n1 device to BlockDeviceSize test
Message-ID: <yvYwfjDrBdInc7LbizZIhF4476sG9O3je5GvcS4x3OI=.aae1d265-662d-4301-bf0c-755d6fcc4dd9@github.com>

8313674: Add nvme0n1 device to BlockDeviceSize test

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

Commit messages:
 - 8313674: Add nvme0n1 device to BlockDeviceSize test

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

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

From imediava at gmail.com  Tue Apr 30 13:36:00 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Tue, 30 Apr 2024 15:36:00 +0200
Subject: Contribution to JDK - 8313674
In-Reply-To: <CA+wBRWA+CddCUHiDZRRzvCTB4yW3fFgzF6mFU-4EDx0pMADvow@mail.gmail.com>
References: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>
 <CA+wBRWA+CddCUHiDZRRzvCTB4yW3fFgzF6mFU-4EDx0pMADvow@mail.gmail.com>
Message-ID: <CA+wBRWBXvnSh7-ohbOHU7A6o=N5MEEqyzcjD+FacEsszAhkkHw@mail.gmail.com>

I went ahead and created a proposal PR to tackle this issue:
https://github.com/openjdk/jdk/pull/19021.

I'd be happy to hear anyone's thoughts on the proposed solution, and to
hopefully get a sponsor on my first attempt to contribute to openjdk.

Thanks in advance

??igo

On Thu, Apr 25, 2024 at 11:14?PM I?igo Mediavilla <imediava at gmail.com>
wrote:

> After looking at JDK-8313674 I'm wondering what is the current impact:
>
> - Is it affecting the CI or the CI is always running in linux systems with
> sda devices ?
> - Is it that local tests fail when they?re run from a linux device that
> doesn?t have a sda device ?
>
> In terms of possible fixes, I think that a quick fix would be to add a
> nvm* device in the list of hard-coded devices to be tested. The test could
> iterate over the list of devices to test skipping devices that don't exist
> but running the checks on the first existing device.
>
> As an alternative I also considered adding logic to list existing block
> devices and picking one to run the test, however I've not being able to
> figure out a way to do this in a simple way:
>
> - There are libraries like (https://github.com/jnr/jnr-posix/) that
> implement that logic, but I feel like it?s not worth incorporating such
> library only for the purpose of this test.
> - I see that there are parts of the native code in the JDK repo that use
> S_ISBLK to check if a device is a block device, but I haven?t been able to
> find that information surfaced to Java.
>
> Happy to hear the thoughts of people with more background on the topic :)
>
> ??igo Mediavilla Saiz
>
> On Thu, Apr 25, 2024 at 5:23?PM I?igo Mediavilla <imediava at gmail.com>
> wrote:
>
>> Hello,
>>
>> For my first contribution to OpenJDK, I've started looking into
>> JDK-8313674.
>>
>> Elif Aslan, I see that you've been assigned to this ticket, would you
>> mind if I try to propose a solution for it ?
>>
>> If Elif is OK with it, I'd like to find a sponsor, since this would be my
>> first time contributing to OpenJDK. Would anyone be available to sponsor my
>> contribution ?
>>
>> Thanks in advance
>>
>> ??igo Mediavilla Saiz
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240430/6bbe2120/attachment-0001.htm>

From thomas.stuefe at gmail.com  Tue Apr 30 14:21:27 2024
From: thomas.stuefe at gmail.com (=?UTF-8?Q?Thomas_St=C3=BCfe?=)
Date: Tue, 30 Apr 2024 16:21:27 +0200
Subject: Contribution to JDK - 8313674
In-Reply-To: <CA+wBRWBXvnSh7-ohbOHU7A6o=N5MEEqyzcjD+FacEsszAhkkHw@mail.gmail.com>
References: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>
 <CA+wBRWA+CddCUHiDZRRzvCTB4yW3fFgzF6mFU-4EDx0pMADvow@mail.gmail.com>
 <CA+wBRWBXvnSh7-ohbOHU7A6o=N5MEEqyzcjD+FacEsszAhkkHw@mail.gmail.com>
Message-ID: <CAA-vtUx2D=x7JPH-1ST+xAr6+JDmnPabQvA7=WobXzB=MtGkpw@mail.gmail.com>

Hi I?igo,

as others have mentioned, the normal way to do this would be to ping the
owner of the issue. They may already be planning a different fix or have a
different solution in mind.

I am cc'ing Aleksey; he can chime in if Elif does not react.

..Thomas

On Tue, Apr 30, 2024 at 4:15?PM I?igo Mediavilla <imediava at gmail.com> wrote:

> I went ahead and created a proposal PR to tackle this issue:
> https://github.com/openjdk/jdk/pull/19021.
>
> I'd be happy to hear anyone's thoughts on the proposed solution, and to
> hopefully get a sponsor on my first attempt to contribute to openjdk.
>
> Thanks in advance
>
> ??igo
>
> On Thu, Apr 25, 2024 at 11:14?PM I?igo Mediavilla <imediava at gmail.com>
> wrote:
>
>> After looking at JDK-8313674 I'm wondering what is the current impact:
>>
>> - Is it affecting the CI or the CI is always running in linux systems
>> with sda devices ?
>> - Is it that local tests fail when they?re run from a linux device that
>> doesn?t have a sda device ?
>>
>> In terms of possible fixes, I think that a quick fix would be to add a
>> nvm* device in the list of hard-coded devices to be tested. The test could
>> iterate over the list of devices to test skipping devices that don't exist
>> but running the checks on the first existing device.
>>
>> As an alternative I also considered adding logic to list existing block
>> devices and picking one to run the test, however I've not being able to
>> figure out a way to do this in a simple way:
>>
>> - There are libraries like (https://github.com/jnr/jnr-posix/) that
>> implement that logic, but I feel like it?s not worth incorporating such
>> library only for the purpose of this test.
>> - I see that there are parts of the native code in the JDK repo that use
>> S_ISBLK to check if a device is a block device, but I haven?t been able to
>> find that information surfaced to Java.
>>
>> Happy to hear the thoughts of people with more background on the topic :)
>>
>> ??igo Mediavilla Saiz
>>
>> On Thu, Apr 25, 2024 at 5:23?PM I?igo Mediavilla <imediava at gmail.com>
>> wrote:
>>
>>> Hello,
>>>
>>> For my first contribution to OpenJDK, I've started looking into
>>> JDK-8313674.
>>>
>>> Elif Aslan, I see that you've been assigned to this ticket, would you
>>> mind if I try to propose a solution for it ?
>>>
>>> If Elif is OK with it, I'd like to find a sponsor, since this would be
>>> my first time contributing to OpenJDK. Would anyone be available to sponsor
>>> my contribution ?
>>>
>>> Thanks in advance
>>>
>>> ??igo Mediavilla Saiz
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240430/d9d63306/attachment.htm>

From imediava at gmail.com  Tue Apr 30 14:29:08 2024
From: imediava at gmail.com (=?UTF-8?Q?I=C3=B1igo_Mediavilla?=)
Date: Tue, 30 Apr 2024 16:29:08 +0200
Subject: Contribution to JDK - 8313674
In-Reply-To: <CAA-vtUx2D=x7JPH-1ST+xAr6+JDmnPabQvA7=WobXzB=MtGkpw@mail.gmail.com>
References: <CA+wBRWABh69ZQAqz6Mmg07MYWgMgsnYU5z0vf31DApzSSgD__A@mail.gmail.com>
 <CA+wBRWA+CddCUHiDZRRzvCTB4yW3fFgzF6mFU-4EDx0pMADvow@mail.gmail.com>
 <CA+wBRWBXvnSh7-ohbOHU7A6o=N5MEEqyzcjD+FacEsszAhkkHw@mail.gmail.com>
 <CAA-vtUx2D=x7JPH-1ST+xAr6+JDmnPabQvA7=WobXzB=MtGkpw@mail.gmail.com>
Message-ID: <CA+wBRWBD+OgeGRZ9ogjMMgCvG6_njfE4+GEgg6Y+5f9zmo6f4w@mail.gmail.com>

Thanks for cc'ing Aleksey, Thomas.

Sorry if I went ahead and created a PR because I hadn't received a response
for a few days. I apologize if I stepped on someone's toes, I just wanted
to show an example of a possible solution and run it through people in this
mailing list.





On Tue, Apr 30, 2024 at 4:21?PM Thomas St?fe <thomas.stuefe at gmail.com>
wrote:

> Hi I?igo,
>
> as others have mentioned, the normal way to do this would be to ping the
> owner of the issue. They may already be planning a different fix or have a
> different solution in mind.
>
> I am cc'ing Aleksey; he can chime in if Elif does not react.
>
> ..Thomas
>
> On Tue, Apr 30, 2024 at 4:15?PM I?igo Mediavilla <imediava at gmail.com>
> wrote:
>
>> I went ahead and created a proposal PR to tackle this issue:
>> https://github.com/openjdk/jdk/pull/19021.
>>
>> I'd be happy to hear anyone's thoughts on the proposed solution, and to
>> hopefully get a sponsor on my first attempt to contribute to openjdk.
>>
>> Thanks in advance
>>
>> ??igo
>>
>> On Thu, Apr 25, 2024 at 11:14?PM I?igo Mediavilla <imediava at gmail.com>
>> wrote:
>>
>>> After looking at JDK-8313674 I'm wondering what is the current impact:
>>>
>>> - Is it affecting the CI or the CI is always running in linux systems
>>> with sda devices ?
>>> - Is it that local tests fail when they?re run from a linux device that
>>> doesn?t have a sda device ?
>>>
>>> In terms of possible fixes, I think that a quick fix would be to add a
>>> nvm* device in the list of hard-coded devices to be tested. The test could
>>> iterate over the list of devices to test skipping devices that don't exist
>>> but running the checks on the first existing device.
>>>
>>> As an alternative I also considered adding logic to list existing block
>>> devices and picking one to run the test, however I've not being able to
>>> figure out a way to do this in a simple way:
>>>
>>> - There are libraries like (https://github.com/jnr/jnr-posix/) that
>>> implement that logic, but I feel like it?s not worth incorporating such
>>> library only for the purpose of this test.
>>> - I see that there are parts of the native code in the JDK repo that use
>>> S_ISBLK to check if a device is a block device, but I haven?t been able to
>>> find that information surfaced to Java.
>>>
>>> Happy to hear the thoughts of people with more background on the topic :)
>>>
>>> ??igo Mediavilla Saiz
>>>
>>> On Thu, Apr 25, 2024 at 5:23?PM I?igo Mediavilla <imediava at gmail.com>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> For my first contribution to OpenJDK, I've started looking into
>>>> JDK-8313674.
>>>>
>>>> Elif Aslan, I see that you've been assigned to this ticket, would you
>>>> mind if I try to propose a solution for it ?
>>>>
>>>> If Elif is OK with it, I'd like to find a sponsor, since this would be
>>>> my first time contributing to OpenJDK. Would anyone be available to sponsor
>>>> my contribution ?
>>>>
>>>> Thanks in advance
>>>>
>>>> ??igo Mediavilla Saiz
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/nio-dev/attachments/20240430/ef5dfc45/attachment.htm>

From tprinzing at openjdk.org  Tue Apr 30 15:42:15 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 30 Apr 2024 15:42:15 GMT
Subject: Integrated: 8329138: Convert JFR FileForceEvent to static mirror event
In-Reply-To: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
References: <pK5qmnL1zo3Lp9jfM4LsDk_-DU2MbMzH0HdeK0XBI_o=.494a7711-b5e8-4f8e-a191-21757bc83a52@github.com>
Message-ID: <HasaqnpphS9XAn2WFGK11MNvLJeA9i2q51z19WCj1ds=.dbbe5e5d-ee14-4845-a58c-5849ec11bbee@github.com>

On Fri, 29 Mar 2024 00:52:46 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods.
> 
> Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event.
> 
> Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor.
> 
> Uses the existing tests.

This pull request has now been integrated.

Changeset: f4caac8d
Author:    Tim Prinzing <tprinzing at openjdk.org>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f4caac8dea1c95234743712386cb28a1ecb11197
Stats:     280 lines in 12 files changed: 238 ins; 28 del; 14 mod

8329138: Convert JFR FileForceEvent to static mirror event

Reviewed-by: alanb, egahlin

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

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

From alanb at openjdk.org  Tue Apr 30 16:00:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 30 Apr 2024 16:00:07 GMT
Subject: RFR: 8310994: Add JFR event for selection operations [v3]
In-Reply-To: <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>
References: <CIXVl1EZwFuMVS3r_nPQAQ7Xw-2dDz6f2iR2p913Y3I=.a6d6e26f-4d68-4400-a5b2-28c50039ca27@github.com>
 <8lBiUxq1EYaux0j6rOnzmScfwFWfBRbYYT1IwEvSQWQ=.bc31666d-4f00-4ac9-a4f2-242abe231db1@github.com>
 <tRuTsEsT2D_pRiTZUtrMYspsGQxbhcEzScN1tneBETQ=.98ab14ef-da1f-487c-bf4f-86e5114ac817@github.com>
 <rGwGrg_ODwU9wVA3MLTNJNwoo8VMtl9dfQdDuaDXn7o=.a4891c46-5cfb-4038-a9df-934101896de0@github.com>
 <APKtHvpmmsfNAZmRTFGKBCOzbyaayMVNZkK_op34-gk=.5a1575e9-5ccc-4d61-8fb4-384ee923fc9c@github.com>
 <T2Y4u7ozra3uLFrfps4b_2YdFmV714CtK8-Nig5ZM4Q=.f4b3e66c-9874-4136-b57f-56c1d5edef3b@github.com>
 <3oHX0rWFc22Z859QnlbjLvKEd5GFGoEmOtpKeXpFwB4=.d023df3f-dfa5-4706-8319-818b9af522ec@github.com>
 <_5zaiminpkaaX8Bwx4BhcULhyii-W0zCUswNab-aQVg=.19a2551a-b69c-4238-9aab-cffc3d9e9751@github.com>
 <TpIMJnCm76IYCVYaWfjm33Oj4lcUp2TmDs7ZVQF1Jog=.737e20ee-289f-4c9c-bdec-d7d9fd186f95@github.com>
Message-ID: <NgmecIALcnWDgow3gT1_aNsmNiQUmWUoxIpeNdxhQRY=.27919331-b39c-403d-8d17-0cde3b5d8e49@github.com>

On Mon, 29 Apr 2024 21:53:02 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

> Should I set the default to be fairly high (like maybe 1600ms)? I think to be useful people will have to set the threshold to something that fits their needs anyway.

I wonder about the usefulness of this event if the default threshold is so high. My guess is that it's rare to change the default threshold. To your question then I suppose this comes back to how this event might be used. Maybe it's worth writing down a few possible usages and that might help to inform if the threshold should be 20ms or something else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/16710#discussion_r1585104188