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>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Nick, Compilation time is not really an issue because the API is pluggable. It=20 should be possible to create a standalone SelectionProvider. The only chang= e=20 to the JDK would then be to switch to a different default provider. In the= =20 mean time I can test my implementation using=20 java -Djava.nio.channels.spi.SelectorProvider=3Dmyprovider =46rom a cursory read of the code it can be seen that the existing Sun=20 implementations (even the shared part of the code) assumes poll like=20 back-ends. This is not a very good match for kqueue because it differs (in = a=20 good way IMHO) from epoll, /dev/poll and poll way of doing thins. In fact=20 this coupling is so strong that the epoll code doesn't even attempt to=20 convert between poll events (POLLIN, POLLOUT) as used by the shared code an= d=20 epoll events (EPOLLIN, EPOLLOUT). So some translation between the two model= s=20 is needed, unless I also (partially) rewrite SocketChannel,=20 ServerSocketChannel etc, which I am not planning to do. Theoretically speaking, I think it is possible to make a kqueue back-end th= at=20 runs faster than the epoll version due to broken epoll (system call per=20 changed interest) design :-). Actually I still can't believe why the linux= =20 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=3Djava/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 1= 00 > > 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"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201001301958.59731.pieter>