[9] PING: RFC on 8165823 & 8168500: (se) EPollArrayWrapper optimization for large file descriptors

[Jon V.]

Does anyone know why the OPEN_MAX “optimization” was added to begin with?
Java must already be able to handle failed file opens already.  This seems
unnecessary.  Maybe I’m missing something.


On Thu, Nov 10, 2016 at 8:28 PM, Brian Burkhalter <
brian.burkhalter at oracle.com> wrote:

> On Nov 5, 2016, at 1:31 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
>
> Changing eventsHigh to final and always initializing it to an empty
> HashMap should be fine. However I do think we are just guessing that the
> nfiles is changing dynamically, hopefully the original submitter will come
> back to say more about the environment.
>
>
> I have re-contacted the original submitter but as yet have had no
> response. I was however able to reproduce the problem by modifying the
> LotsOfChannels test and the EPollArrayWrapper constructor to sleep at two
> particular places during which I executed the prlimit command as
>
> $ prlimit --nofile=512:512 --pid PID // before EPollArrayWrapper
> constructed
> $ sudo prlimit --nofile=2048:2048 --pid PID // at end of EPollArrayWrapper
> constructor after eventsHigh NOT initialized
>
> where PID is the process ID of the Java process executing LotsOfChannels.
> While this does not confirm that the RLIMIT_NOFILE resource changed
> dynamically in the submitter’s use case, it does verify that the scenario
> is plausible. It would seem therefore that always initializing a final
> eventsHigh to an empty HashMap is a reasonable defensive solution.
>
> Brian
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161110/f54f5646/attachment.html>