From owner-freebsd-java@FreeBSD.ORG Tue Aug 28 15:11:22 2007 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 3CB2E16A420 for ; Tue, 28 Aug 2007 15:11:22 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (gerbercreations.com [71.39.140.16]) by mx1.freebsd.org (Postfix) with ESMTP id BB16413C4D0 for ; Tue, 28 Aug 2007 15:11:21 +0000 (UTC) (envelope-from glewis@eyesbeyond.com) Received: from misty.eyesbeyond.com (localhost.eyesbeyond.com [127.0.0.1]) by misty.eyesbeyond.com (8.13.1/8.13.3) with ESMTP id l7SFBKLe007346; Tue, 28 Aug 2007 08:11:20 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) Received: (from glewis@localhost) by misty.eyesbeyond.com (8.13.1/8.13.3/Submit) id l7SFBJuh007345; Tue, 28 Aug 2007 08:11:19 -0700 (PDT) (envelope-from glewis@eyesbeyond.com) X-Authentication-Warning: misty.eyesbeyond.com: glewis set sender to glewis@eyesbeyond.com using -f Date: Tue, 28 Aug 2007 08:11:19 -0700 From: Greg Lewis To: Nick Johnson Message-ID: <20070828151119.GA7309@misty.eyesbeyond.com> References: <20070823111051.N82369@turing> <20070823114932.C82369@turing> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070823114932.C82369@turing> User-Agent: Mutt/1.4.2.2i Cc: freebsd-java@freebsd.org Subject: Re: making nio use kevent/kqueue 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: Tue, 28 Aug 2007 15:11:22 -0000 G'day Nick, On Thu, Aug 23, 2007 at 12:12:55PM -0700, Nick Johnson wrote: > Looking at it a bit more, it looks like the "right" thing to do is to > create a KeventArrayWrapper, possibly based on the EPollArrayWrapper.c so > that multiple ready FDs can be returned at one time. > > That means creating a KeventArrayWrapper.java based on > j2se/src/solaris/classes/sun/nio/ch/EPollArrayWrapper.java as well as a > KeventSelectorImpl.java based on EPollSelectorImpl.java and > KeventSelectorProvider.java based on EPollSelectorProvider.java. > > It also means modifying > src/solaris/classes/sun/nio/ch/DefaultSelectorProvider.java to select the > KeventSelectorProvider and possibly tweaking some makefiles to ensure that > everything gets built, including: > > make/java/nio/Makefile > make/java/nio/mapfile* (do we end up using mapfile-linux or > mapfile-solaris?) Ummm mapfile-bsd :). FWIW, I think this would be a great addition to the BSD port of the JDK. I'd really encourage you to give it a try. If you get something going to the point where you want to place it under version control then please feel free to talk to me about access to the porting team's repo. > On Thu, 23 Aug 2007, Nick Johnson wrote: > > > I think there could be a considerable performance gain if java.nio were > > tweaked to use kevent/kqueue(2) as opposed to poll(2). > > > > It looks like the files that would need to be touched for this are: > > > > j2se/src/solaris/native/sun/nio/ch/ > > DevPollArrayWrapper.c (not sure about this one actually since > > FreeBSD doesn't use /dev/poll) > > PollArrayWrapper.c > > SocketChannelImpl.c > > > > Does that sound about right? I see select(2) and poll(2) used in other > > places as well, though outside of nio where they're likely to show the > > greatest benefit. > > > > Are there any caveats or "gotchas" I should be aware if should I decide to > > take some free time to try to come up with a kevent patch for nio? > > > > Also, is there a quicker way to build a JVM when just changing a file or > > two like this? It would be lousy to have to wait 2 hours to build after > > every minor change... The build process is mostly smart enough to just rebuild the affected files. You might want to convince it that you don't want to build a release image every time though (I forget what controls this). If you wanted to you could also set up the appropriate environment variables and just build in the specific "make" directory for your changes. -- Greg Lewis Email : glewis@eyesbeyond.com Eyes Beyond Web : http://www.eyesbeyond.com Information Technology FreeBSD : glewis@FreeBSD.org