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

[Alan Bateman]

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