OpenJDK 6/7 kqueue based NIO provider

[Pieter de Goeje]

Hi Nick,

Compilation time is not really an issue because the API is pluggable. It 
should be possible to create a standalone SelectionProvider. The only change 
to the JDK would then be to switch to a different default provider. In the 
mean time I can test my implementation using 
java -Djava.nio.channels.spi.SelectorProvider=myprovider

From a cursory read of the code it can be seen that the existing Sun 
implementations (even the shared part of the code) assumes poll like 
back-ends. This is not a very good match for kqueue because it differs (in a 
good way IMHO) from epoll, /dev/poll and poll way of doing thins. In fact 
this coupling is so strong that the epoll code doesn't even attempt to 
convert between poll events (POLLIN, POLLOUT) as used by the shared code and 
epoll events (EPOLLIN, EPOLLOUT). So some translation between the two models 
is needed, unless I also (partially) rewrite SocketChannel, 
ServerSocketChannel etc, which I am not planning to do.

Theoretically speaking, I think it is possible to make a kqueue back-end that 
runs faster than the epoll version due to broken epoll (system call per 
changed interest) design :-). Actually I still can't believe why the linux 
folks didn't simply implement kqueue in their kernel.

Regards,

Pieter

On Saturday 30 January 2010 19:15:07 Nicklas Johnson wrote:
> I looked into this a long time ago and opened a PR for it for the regular
> JDK port, for exactly the reasons you cited.  At the time I looked into
> what it would take but I lacked the time and expertise to make the changes
> myself.  Specifically I never figured out how to build the JDK without a
> multi-hour compilation cycle when I was just making one or two lines of
> code changes.  I was too busy to invest much time in figuring it out
> unfortunately.
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=java/115773  is the PR.  It'd be
> great if you were able to make it happen and if it could be backported to
> the regular JDK port.
>
>    Nick
>
> 2010/1/30 Pieter de Goeje <pieter at degoeje.nl>
>
> > Hi,
> >
> > I'm looking for a kqueue based implementation of java.nio.Selector.
> >
> > If it doesn't exit yet, I'll have to create it myself. I've already
> > looked at
> > the code for the EPoll provider and it doesn't seem too hard to create a
> > kqueue based one. I will have to figure out how to interface with native
> > libraries though.
> >
> > The reason is obviously performance. I created a simple nio based echo
> > server
> > and a kqueue client in C, which creates about 50K simultaneous
> > connections. Java is completely CPU bound and can only reply to about 100
> > connections per
> > second due to immense poll(2) overhead, and it takes ages for all 50K
> > connections to be accepted by the server.
> >
> > Input welcome :-)
> >
> > --
> > Pieter
> >
> > _______________________________________________
> > freebsd-java at freebsd.org mailing list
> > http://lists.freebsd.org/mailman/listinfo/freebsd-java
> > To unsubscribe, send any mail to "freebsd-java-unsubscribe at freebsd.org"