Alan Bateman

« java.io.Console is... | Main | Two fine demos »

http://blogs.sun.com/alanb/date/20051103 Thursday November 03, 2005

To poll or epoll: that is the question:

One of the updates in build 59 of Mustang (JavaTM SE 6) is that the New I/O Selector implementation will use the epoll event notification facility when running on the Linux 2.6 kernel. The epoll event mechanism is much more scalable than the traditional poll when there are thousands of file descriptors in the interest set. The work done by poll depends on the size of the interest set whereas with epoll (like Solaris /dev/poll) the registration of interest is separated from the retrieval of the events. A lot has been written on the topic. The C10K problem has been documenting I/O frameworks and strategies for several years. One relatively recent paper on Comparing and Evaluating epoll, select, and poll Event Mechanisms makes it clear the workloads where epoll performs a lot better than poll.

This isn't the first NIO Selector implementation to use epoll. The Blackdown folks added epoll support in their 1.4.x release. On Solaris, the /dev/poll based Selector has been default on Solaris 8 (and newer) since the original implementation of New I/O in J2SETM 1.4.

So if you are running on a Linux 2.6 system with an application that handles lots of simultaneous connections you might want to give b59 a test-run. The weekly builds have been appearing like clockwork on the binary snapshot release site so b59 should be available tomorrow (November 4). Will you see a difference? It depends on the workload. If you've registered lots of SelectableChannels with a Selector and you notice a lot of time spent in the kernel due to poll then you should see a difference. If you are doing test runs and you want to do a direct comparison with poll then you can set the java.nio.channels.spi.SelectorProvider system property to sun.nio.ch.PollSelectorProvider. This will select the poll-based Selector that will continue to be the default on 2.4 kernels. There is an epoll patch for 2.4 kernels but at this time anyway, the NIO implementation doesn't attempt to detect this.

[Update 08/04/2006: The epoll SelectorProvider will be included in 5.0 update 9. To enable it requires setting the system property java.nio.channels.spi.SelectorProvider to the value sun.nio.ch.EPollSelectorProvider. Sorry, it won't be the default in 5.0 but we must be very careful when changing anything in an update release.]

Posted at 04:19AM Nov 03, 2005 by alanb in Java  |  Comments[10]

Comments:

works great for me. With b59, on one of our perf tests, I am seeing system CPU go down from 40% with JDK 1.5.0_05 to 6-7% system in b59 with 10000 connections.

Posted by anandp on November 05, 2005 at 09:06 AM PST #

Anand - thanks for giving it test run and reporting your results. Managing 10k connections with the system only 6-7% busy is impressive. I assume a lot of the connections must be idle or stalled - that is a case where epoll is a clear winner over the traditional poll.

Posted by alanb on November 06, 2005 at 10:57 AM PST #

I'd love to see an ability to enable epoll on patched 1.4 kernels. I'm happy to trick you into it via -Dsomething.

Posted by Alex Lloyd on November 15, 2005 at 09:50 PM PST #

This might be the -Dsomething: 
-Djava.nio.channels.spi.SelectorProvider=sun.nio.ch.EPollSelectorProvider

Posted by Arnold Burns on November 17, 2005 at 05:35 PM PST #

The implementation uses dlsym to get the addresses of the epoll_create, epoll_ctl, and epoll_wait functions. If you patch the kernel and don't update glibc then the lookup will still fail. You could use an interposer library and have the interposer functions uses syscall. If you do try it then let us know your results.

Posted by alanb on November 22, 2005 at 02:01 PM PST #

Is it possible for you to provide a epoll provider patch for jdk1.5.0_08? I have an application that's using the default SelectorProvider under linux 2.6 kernel and it seems to be taking really lots of CPU time...

Posted by Hank on September 16, 2006 at 12:46 AM PDT #

Hi Alan, It appears that Java 1.6 fixes a bug in the Linux version of select that exists in 1.5_08 whereby NIO select() returns 0 when absolutely nothing is ready to be selected and when wakeup has not been called in the event that a client disconnects while a read/write is in progress. I am not sure if it's because EPoll is being used in 1.6 or not. All that matters to me is that the bug is fixed in 1.6. With that said, is the Epoll and Selector functionality that will be coming out in 1.5_09 (as you infer) the same as what's in 1.6? If so, my problems will be solved with 1.5_09 (and thankfully). Do you know when 1.5_09 will be released?

Posted by Eric on September 26, 2006 at 03:02 PM PDT #

Eric - the epoll based SelectorProvider that has been putback for the 5.0 update is identical to jdk6. It's hard to say what issue you are seeing - one possibility is 6403933 that arises when the interset set is 0 and a connection is abruptly terminated.

Hank - bug fixes and other changes are batched into update releases and there isn't patches available for specific changes.

Posted by 192.18.1.4 on September 27, 2006 at 03:08 AM PDT #

Release 9 is now available, but the release notes posted here http://java.sun.com/j2se/1.5.0/ReleaseNotes.html don't seem to suggest that the epoll feature is included. Can you provide any further details?

Posted by Paul on October 03, 2006 at 05:18 AM PDT #

Paul - there were some swing issue in the last 5.0 update that needed to be fixed in a hurry. This means that all the fixes that were in 5.0u9 have been moved to 5.0u10. Sorry, but these things happen.

Posted by 192.18.1.4 on October 03, 2006 at 05:27 AM PDT #

Post a Comment:
Comments are closed for this entry.

Valid HTML! Valid CSS!

This is a personal weblog, I do not speak for my employer.