RFC on 8165823: (se) EPollArrayWrapper throws NPE if limits.conf set to 65536 and fd=65536

[Brian Burkhalter]

I contacted the original submitter of this issue more than two weeks ago about whether a dynamically changing resource limit on file descriptor number could be the cause of the problem in their workload. Thus far I have received no response and have marked the issue [1] as Resolved -> Incomplete.

Prior to that I posted a webrev [2] in which the eventsHigh HashMap would be lazily initialized and hopefully avert this problem defensively.

As an alternative, and probably this idea will be rejected, but instead of adding relatively complex lazy initialization could we not just unconditionally allocate eventsHigh at line 121 of [3]?
    private Map<Integer,Byte> eventsHigh = new HashMap<>();
Yes, there would be a footprint and performance penalty but perhaps it is so small as to be in the “noise” category. According to JOL [4] for JDK 9 the footprint of the default HashMap is 48 bytes (see below) and according to JMH [5] the time to construct the instance is about 20 nanoseconds on my MacBookPro11,1.

Also I noticed that this issue [1] was observed in another use case which is discussed in [6].

Thanks,

Brian
T
Tha
$ java -jar jol-cli/target/jol-cli.jar footprint java.util.HashMap

Running 64-bit HotSpot VM.
Using compressed references with 3-bit shift.
Objects are 8 bytes aligned.
Field sizes by type: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]
Array element sizes: 4, 1, 1, 2, 2, 4, 4, 8, 8 [bytes]

java.util.HashMap at 2893de87d footprint:
     COUNT       AVG       SUM   DESCRIPTION
         1        48        48   java.util.HashMap
         1                  48   (total)


[1] https://bugs.openjdk.java.net/browse/JDK-8165823
[2] http://cr.openjdk.java.net/~bpb/8165823/webrev.00/
[3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/7b0b28ceca62/src/java.base/linux/classes/sun/nio/ch/EPollArrayWrapper.java
[4] http://openjdk.java.net/projects/code-tools/jol/
[5] http://openjdk.java.net/projects/code-tools/jmh/
[6] https://github.com/elastic/elasticsearch/issues/11706
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20161021/36308703/attachment.html>