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

[Michael McMahon]

The change looks good to me.

- Michael.

On 12/04/12 12:08, Alan Bateman wrote:
>
> 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