7143744: (se) Stabilize KQueue SelectorProvider and make default on MacOSX

Alan Bateman Alan.Bateman at oracle.com
Thu Apr 12 04:08:43 PDT 2012


I need a reviewer for a patch that fixes several issues with the kqueue 
SelectorProvider. It also restores it to be the default SelectorProvider 
on MacOSX. Note that these changes are for jdk8. Once they have baked 
for a while in 8 then we should consider them for jdk7u too.

As background, Apple contributed their kqueue SelectorProvider to the 
macosx-port project [1] as it's more scalable than the poll based 
SelectorProvider that the bsd-port project was using. Unfortunately the 
kqueue SelectorProvider had a few issues and there were several test 
failures. In the end the default was switched back to the poll 
SelectorProvider [2], pending resolution of these issues.

I've finally got a chance to look at the issues and have a webrev with 
the changes here:
   http://cr.openjdk.java.net/~alanb/7143744/webrev

The main issue is the SelectorProvider didn't work correctly with 
channels that are registered for more than one op at a time (OP_READ | 
OP_WRITE for example). If more than one event was retrieved for the same 
file descriptor then the ready ops were replaced rather than updated. 
This stems from having the same file descriptor associated with more 
than one filter. The return from the select or selectNow methods was 
incorrect for these cases too (double accounting). There were also 
intermittent CancelledKeyException issues when keys were canceled or 
channels closed at around the same time as a select. There was also an 
intermittent NullPointerException during wakeup.

With these changes then all tests are passing. There is further clean-up 
that is required but it's not critical. In particular, the 
AsynchronousChannelProvider implementation [2] is also based on kqueue 
(in ONESHOT rather than level triggered mode) so there is an opportunity 
to remove some code, native code and wrapper in particular. I've 
deliberately not included this refactoring in this patch as it's more 
appropriate for jdk8. As I mentioned above, we will likely want to push 
this patch to jdk7u in the future so the changes have been kept to a 
minimum.

Thank you,
Alan.

[1] http://hg.openjdk.java.net/macosx-port/macosx-port/jdk/rev/cb5ebc902d33
[2] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/98564f184614
[3] http://hg.openjdk.java.net/jdk7u/jdk7u/jdk/rev/5599aa5a4a51


More information about the nio-dev mailing list