RFR: 8330077: Allow max number of events to be buffered to be configurable to avoid OVERFLOW_EVENT [v10]

[Alan Bateman]

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