Date: Sat, 30 Jan 2010 19:58:59 +0100 From: Pieter de Goeje <pieter@degoeje.nl> To: Nicklas Johnson <freebsd@spatula.net> Cc: freebsd-java@freebsd.org Subject: Re: OpenJDK 6/7 kqueue based NIO provider Message-ID: <201001301958.59731.pieter@degoeje.nl> In-Reply-To: <be800d231001301015x6cb564ednce1fdb8a6380a2cb@mail.gmail.com> References: <201001301816.16987.pieter@degoeje.nl> <be800d231001301015x6cb564ednce1fdb8a6380a2cb@mail.gmail.com>
index | next in thread | previous in thread | raw e-mail
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@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@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-java > > To unsubscribe, send any mail to "freebsd-java-unsubscribe@freebsd.org"help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001301958.59731.pieter>