RFR: 8285956: (fs) Excessive default poll interval in PollingWatchService [v4]

[Tyler Steele]

On Tue, 3 May 2022 00:46:37 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> I agree it is good to consider whether or not the design makes it easy to load up so many changes that performance degrades. But I think we're well clear of that point even with 1s. I think it helps that [scheduleAtFixedRate](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/util/concurrent/ScheduledExecutorService.html#scheduleAtFixedRate(java.lang.Runnable,long,long,java.util.concurrent.TimeUnit)) guarantees that the tasks will not run concurrently and [Watchable](https://docs.oracle.com/en/java/javase/17/docs/api/java.base/java/nio/file/Watchable.html#register(java.nio.file.WatchService,java.nio.file.WatchEvent.Kind%5B%5D,java.nio.file.WatchEvent.Modifier...)) specifies that the key should only be created if one doesn't already exist.
>> 
>> If a user were to register enough unique Watchable objects to degrade the performance of their system, I am hopeful that the reason for the slow down would be clear to them.
>> 
>> An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s.
>
>> An alternative would be to keep the initial wait at 1s and increase the default polling interval to 2s.
> 
> That might be better.
> 
> A more ideal way to fix this would be to implement something on top of `inotify()`, `kqueue()`, or whatever similar native system mechanism exists on AIX.

Thanks for your comments @bplb and @AlanBateman.

If you have no further comments, and are happy with the ones I've resolved, please finalize your reviews so that I may merge (I am eager to get this one in so that I can backport it).

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

PR: https://git.openjdk.java.net/jdk/pull/8479