Regression in EPollArrayWrapper causes NPE when fd > 64 * 1024

[Alan Bateman]

On 18/09/2013 11:20, Norman Maurer wrote:
> Hi Alan,
>
> I tried to find one of those "existing stress-tests" but was not able 
> yet. Can you just tell me where I can find one so I can actually write 
> a test-case based on one of them.
>
Yeah, the Selector tests in the jdk/test tree are a bit of mixed bag 
tests for various long fixed issues.

One thing that I remembered after our exchange is that the Selector 
implementations that we have for Solaris use the same approach for 
queuing updates. This came about when we re-worked the /dev/poll 
Selector to fix a number of performance and reliability issues. It's 
also in the relatively new port based Selector which I'd like to see 
made the default on Solaris at some point.

So while only the epoll Selector has the problem (due to the kill logic) 
then I think it would be best if we provide a way to test all of the 
Selectors. To that end, I've added a special property to select the 
limit that we can use for testing. Your suggestion to use reflection 
would work too, as would having a test that adds to sun.nio.ch. The 
first approach seems the simplest so I've put a webrev here with the 
changes:

http://cr.openjdk.java.net/~alanb/8024883/webrev/

It means we can run jtreg with 
-vmoption:-Dsun.nio.ch.maxUpdateArraySize=N and it will run all of the 
tests with this setting. This is the same approach when you want to test 
with an alternative Selector implementation. To ensure that there is at 
least some coverage in normal test runs then I've modified the test 
description of two tests so that they re-run with this property set to a 
smallish value.

Let me know if you are agree with this. I realize this is extending the 
scope of your original bug report and patch a bit.

-Alan



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.openjdk.java.net/pipermail/nio-dev/attachments/20130918/5daca6f1/attachment-0001.html