From owner-freebsd-java@FreeBSD.ORG Sat Jan 30 18:59:13 2010 Return-Path: Delivered-To: freebsd-java@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id DB75F1065670 for ; Sat, 30 Jan 2010 18:59:12 +0000 (UTC) (envelope-from pieter@degoeje.nl) Received: from smtp.utwente.nl (smtp2.utsp.utwente.nl [130.89.2.9]) by mx1.freebsd.org (Postfix) with ESMTP id 7A7278FC15 for ; Sat, 30 Jan 2010 18:59:12 +0000 (UTC) Received: from nox.student.utwente.nl (nox.student.utwente.nl [130.89.165.91]) by smtp.utwente.nl (8.12.10/SuSE Linux 0.7) with ESMTP id o0UIwxDT020507; Sat, 30 Jan 2010 19:59:00 +0100 From: Pieter de Goeje To: Nicklas Johnson Date: Sat, 30 Jan 2010 19:58:59 +0100 User-Agent: KMail/1.9.10 References: <201001301816.16987.pieter@degoeje.nl> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-15" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <201001301958.59731.pieter@degoeje.nl> X-UTwente-MailScanner-Information: Scanned by MailScanner. Contact icts.servicedesk@utwente.nl for more information. X-UTwente-MailScanner: Found to be clean X-UTwente-MailScanner-From: pieter@degoeje.nl X-Spam-Status: No Cc: freebsd-java@freebsd.org Subject: Re: OpenJDK 6/7 kqueue based NIO provider X-BeenThere: freebsd-java@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting Java to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jan 2010 18:59:13 -0000 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 > > > 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"