Mailing-List: contact dev-help@harmony.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@harmony.apache.org
Received-SPF: pass (athena.apache.org: domain of alexei.fedotov@gmail.com
 designates 66.249.92.169 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=BJiyATSVzATg3O6OMVUxDkdeKB2H0KXOt7TgqMaoWZjDbupyxAKTefymIE1yRqeFMfeA+ahwlKvLiZF3B+U668OZO3n2fWvMPYIEGBitsQzSk0BbLP/SREW/VvyHuSj9VZ/IxITUpEEETkM4nFDkDePRRGzovakY/PoMQJo2SIo=
Message-ID: <c30d70960710080250i38bb604h2f60b434461ace00@mail.gmail.com>
Date: Mon, 8 Oct 2007 13:50:10 +0400
From: "Alexei Fedotov" <alexei.fedotov@gmail.com>
To: dev@harmony.apache.org
Subject: Re: [classlib][nio] epoll()-based Selector
In-Reply-To: <5c8e69f0710080146u6a53e1b9hed1ccdab5781c466@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <4bebff790710010849q3116964br7d85dc5a5b5f20a7@mail.gmail.com>
	 <4bebff790710040356s77a3200el7e6ce03a80222c6b@mail.gmail.com>
	 <5c8e69f0710080146u6a53e1b9hed1ccdab5781c466@mail.gmail.com>

Hello Jimmy,

> However I have a concern that, shall we offer a build for the
> users with a previous version of Linux kernel 2.6 (maybe there's a lot
> of them who also require JDK)?

I believe we need to look forward and take advantage of new OS and
hardware features. We offer stable releases (harmony trunks) of older
versions and may support and patch them if a customer requests. But
generally we should be going forward and becoming more effective.

Thanks!

On 10/8/07, Jimmy,Jing Lv <firepure@gmail.com> wrote:
> Hi,
>
>    It's really cool ! :)
>
>    However I have a concern that, shall we offer a build for the
> users with a previous version of Linux kernel 2.6 (maybe there's a lot
> of them who also require JDK)? IMHO, at least we can reserve a copy of
> previous implementation of select for that?
>    We may modify the makefile or build.xml for that?
>
> 2007/10/4, Aleksey Shipilev <aleksey.shipilev@gmail.com>:
> > Hi again,
> >
> > I have updated the JIRA [1] with the final patch, all known
> > performance issues were resolved. I have also run extensive experiment
> > for measuring the performance of Selector.selectNow() operation on
> > current and epoll-based implementations comparing to Sun 1.6.0. You
> > might find the results in the JIRA attachment: comparison of current
> > and epoll-based implementation [2].
> >
> > This implementation successfully passes JUnit tests and simple
> > workloads. It's also does not change anything in the classlib (not
> > saying about makefiles), additional option should be specified to
> > enable epoll functionality, so it's safe to apply this patch at any
> > time.
> >
> > BTW, as I found not so long ago, epoll-based Selector is the main
> > improvement for java.nio.* in Sun 1.6.0 classlib [3], and we're going
> > neck and neck with them [4] :)
> >
> > Thanks,
> > Aleksey Shipilev,
> > ESSD, Intel
> >
> > [1] https://issues.apache.org/jira/browse/HARMONY-4879
> > [2] https://issues.apache.org/jira/secure/attachment/12367060/2000-all.png
> > [3] http://java.sun.com/javase/6/docs/technotes/guides/io/enhancements.html
> > [4] https://issues.apache.org/jira/secure/attachment/12367060/2000-best.png
> >
> > On 10/1/07, Aleksey Shipilev <aleksey.shipilev@gmail.com> wrote:
> > > Hi all,
> > >
> > > I would like to present the epoll()-based java.nio.channels.Selector
> > > for Harmony. Epoll facility [1] was developed as the part on Linux
> > > Kernel starting from version 2.5.44, and its interface was finalized
> > > starting before 2.6.x kernels. Epoll is generally driven by callbacks
> > > inside the kernel and thus it strives to be O(1), whereas legacy
> > > poll() and select() are driven by traversing linked lists and thus
> > > being O(n).
> > >
> > > You can find draft implementation at HARMONY-4879 [2]. This version is
> > > ready to play, but not intended for inclusion, since there are a
> > > couple of performance problems persist (like possible O(n^2) at
> > > processSelectResults()). I will try to eliminate them in several days.
> > > However, this patch successfully passes JUnit tests and might be ready
> > > to be tried on some networking-heavy workloads.
> > >
> > > Speaking about performance results, simple test which registers 2000
> > > channels on one Selector and then continuously calls selectNow()
> > > reveals this:
> > >
> > > Harmony-r576670:
> > >  connect time: 100538 msecs
> > >  selectNow() time (10000 times): 27777 msecs
> > >
> > > Harmony-r576670 + HARMONY-4879:
> > >  connect time: 832 msecs
> > >  selectNow() time (10000 times): 87 msecs
> > >
> > > Speedups:
> > >  connect: 120x
> > >  selectNow(): 320x
> > >
> > > More details are in JIRA.
> > >
> > > Is someone interested in the topic?
> > > I would like to collaborate with you then - to prevent duplication of work :)
> > >
> > > [1] http://lse.sourceforge.net/epoll/index.html
> > > [2] https://issues.apache.org/jira/browse/HARMONY-4879
> > >
> >
>
>
> --
>
> Best Regards!
>
> Jimmy, Jing Lv
> China Software Development Lab, IBM
>


-- 
With best regards,
Alexei,
ESSD, Intel